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? -Aleksey. 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
