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

[Remi Forax]

On 10/02/2014 07:00 PM, Aleksey Shipilev wrote:
> 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.

good idea.

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

They should be package-private otherwise javac generates accessors 
(method access$xxx)

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

Rémi

>
> 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
>> COMPILE_THRESHOLD={0,30}
>>
>> 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
>