RFR: 8266015: Implement AdapterHandlerLibrary lookup fast-path for common adapters

[Ioi Lam]

On Tue, 27 Apr 2021 00:27:56 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch refactors AdapterHandlerLibrary initialization so that we can initialize a handful of commonly used adapters early during bootstrap, and avoid taking the AdapterHandlerLibrary_lock when looking up these adapters.
> 
> Since the 5 most common adapters plus the abstract adapter constitutes roughly 60% of the method shapes loaded and linked on a Hello World, this means a relatively significant startup optimization (~2M insns on Hello World); most of the win is in lookup code that will be a significant part of the cost of class loading even when no adapters need to be generated.
> 
> This enhancement partially recuperates the regression reported in https://bugs.openjdk.java.net/browse/JDK-8265523

Looks good overall, but I think we should avoid changing the `return NULL` to `fatal()`.

Also note to other reviewers: when looking at the "Files changed", add `&w=1` to the URL so GitHub will ignore whitespace changes.

src/hotspot/share/runtime/sharedRuntime.cpp line 2396:

> 2394:       int value = 0;
> 2395:       for (int byte = 0; sig_index < total_args_passed && byte < _basic_types_per_int; byte++) {
> 2396:         int bt = adapter_encoding(sig_bt[sig_index++]);

Why is the above changed? Is it for performance? It seems unrelated to this PR.

src/hotspot/share/runtime/sharedRuntime.cpp line 2883:

> 2881:   NOT_PRODUCT(int insts_size = buffer.insts_size());
> 2882:   if (new_adapter == NULL) {
> 2883:     fatal("No memory to create adapter");

This used to be `return NULL;`, and the JVM is supposed to continue execution (but the linking of the current class will get a VirtualMachineError. I think we should keep the old behavior.

-------------

Changes requested by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3706