[9] RFR (S): 8058892: FILL_ARRAYS and ARRAYS are eagely initialized in MethodHandleImpl

Aleksey Shipilev aleksey.shipilev at oracle.com
Thu Oct 2 17:00:43 UTC 2014

I have three comments:

* Since initialization order is important, why don't put the
initialization in the existing static initializer? This will secure for
inadvertent field reordering in future.

* Any reason two new fields are "private"? All other seem package-private.

* Any performance problems if we actually count FILL_ARRAYS_COUNT in
during the static initialization, instead of putting a magic value?


On 10/02/2014 08:55 PM, Vladimir Ivanov wrote:
> Small update:
> http://cr.openjdk.java.net/~vlivanov/8058892/webrev.01/
> Need to reorder initialization sequence in MHI.Lazy. Initialized
> FILL_ARRAYS and ARRAYS are required for later MH lookups.
> Additional testing:
>   * jck (api/java_lang/invoke)
>   * jdk/java/lang/invoke, jdk/java/util/streams w/ "-ea -esa" and
> Best regards,
> Vladimir Ivanov
> On 10/2/14, 7:52 PM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8058892/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8058892
>> Core j.l.i classes are preloaded during VM startup in order to avoid
>> possible deadlock when accessing JSR292-related functionality from
>> multiple threads. After LF sharing-related changes, FILL_ARRAYS and
>> ARRAYS are initialized too early. It affects startup time & footprint of
>> applications that don't use JSR292.
>> The fix is to move these fields into MHI.Lazy class, thus delaying their
>> initialization to the first usage of JSR292 API.
>> Testing: failing test, manual (measured HelloWorld app startup time;
>> compared -XX:+PrintCompilation logs)
>> Best regards,
>> Vladimir Ivanov
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

More information about the core-libs-dev mailing list