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@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
