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

[Claes Redestad]

On Thu, 29 Apr 2021 04:18:05 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix as_basic_args_string for adapters with many args, restore NULL-returning behavior
>
> 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.

Performance (fingerprints are calculated on every lookup) but also for simplifying the fingerprint iterator in as_basic_args_string: Once we hit total_args_passed, the previous algorithm would keep shifting and adding zero bits until the int is "filled". Now I stop when the last argument has been processed, which meant that iterating becomes simpler. Since the hash function will xor the last value (which is the only one that can have zeros) as a last step, it should also improve how well trailing arguments shuffles low bits.

I'm adding some comments, and also fixed a bug in as_basic_args_string when > 8 arguments and changed as_string to not include leading zeroes of the last in (0xbbbbbabb0000000b -> 0xbbbbbabbb)

> 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.

Yes, an unintentional result of me breaking the code flow apart and then merging it back together.

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

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