-
Enhancement
-
Resolution: Fixed
-
P4
-
17
-
b22
AdapterHandlerLibrary::get_adapter sees more activity during startup since 17-b13 (JDK-8265523). While re-implementing a cache mechanism to avoid lookups for methods loaded from CDS would address that regression more completely, I noticed that we spend a lot of time grabbing mutexes and parsing signatures of methods that are both trivial and very common.
Refactoring the AdapterHandlerLibrary so that those common handlers can be created earlier in an earlier single-threaded bootstrap phase allows us to move some fast-path checks outside of the AdapterHandlerLibrary_lock. Avoiding spinning up a SignatureStream for these trivial methods also helps.
By special-casing only a handful of such trivial and common adapters we get a 60% reduction in the number of lock operations and SignatureStream operations done in AdapterHandlerLibrary::get_adapter on HelloWorld. A reduction by ~2.4M instructions, which brings us almost back to the number of instructions we saw before 17-b13.
Refactoring the AdapterHandlerLibrary so that those common handlers can be created earlier in an earlier single-threaded bootstrap phase allows us to move some fast-path checks outside of the AdapterHandlerLibrary_lock. Avoiding spinning up a SignatureStream for these trivial methods also helps.
By special-casing only a handful of such trivial and common adapters we get a 60% reduction in the number of lock operations and SignatureStream operations done in AdapterHandlerLibrary::get_adapter on HelloWorld. A reduction by ~2.4M instructions, which brings us almost back to the number of instructions we saw before 17-b13.
- relates to
-
JDK-8268946 [lworld] Re-implement JDK-8266015 after the merge
-
- Resolved
-
-
JDK-8265523 Startup regression in 17-b13 due increase in adapter lookups
-
- Closed
-