[GLASSFISH-20298] Loading of HK2 cache data slows down server initialization Created: 12/Apr/13  Updated: 20/Dec/16

Status: Reopened
Project: glassfish
Component/s: hk2
Affects Version/s: 4.0_dev
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: mtaube
Resolution: Unresolved Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

GLASSFISH-20350 Make DescriptorImpl Externalizable in... Sub-task Closed mtaube  
Tags: devx_web


During server startup, the HK2 OSGi adapter reads in a fairly large cache file in the ModuleDefinitionCacheSingleton.loadCachedData method. Typically this is about 400KB of serialized module definition data. This takes anywhere from 100-400 ms and while the server is doing this, it is doing nothing else. The code is started via the bundle start method of the osgi-adapter.jar file.

An idea for improving server start time is to move the reading of the cache file to another thread that runs in parallel with some other initialization work that the server is doing. For example, if it would be possible to initialize just the OSGi bundle(s) that are needed to read this cache first, start the cache-reading thread, and then start then have Felix initialize the rest of the bundles. Then, when the bundles are all initialized, the code that need the cache would already have it available.

Or, if the cache were constructed purely from Java SE objects, then the cache could be read into memory without having to initialize any OSGi bundle.

Comment by Tom Mueller [ 17/Apr/13 ]

I've measured the time required for loadCachedData in both 4.0 and 3.1.2. This is for a subsequent restart, and is an average of 5 runs on a MBP:

4.0: 424 ms ("Felix" start time is 2726 ms), inhabitants size = 516415
3.1.2: 194 ms ("Felix start time is 1615 ms), inhabitants size = 371748

Comment by Tom Mueller [ 30/Apr/13 ]

Note that the only thing fixed here is the GLASSFISH-20350 subtask which reduced the time to read the cache by about 100 ms. This change did not move the cache reading to a parallel thread. It also did not restore the cache reading time to what it was in 3.1.2.

Comment by Tom Mueller [ 01/May/13 ]

Retargeting for 4.0.1 because we have already done what we plan to do in this area for 4.0 via GLASSFISH-20350.

Generated at Sun Jan 22 13:06:54 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.