On Sun, 11 Jun 2023 17:26:28 GMT, Doug Simon <dnsi...@openjdk.org> wrote:

>> This PR reduces the amount of code executed during libgraal initialization. 
>> This not only improves VM startup overall but all fixes a number of JDK test 
>> failures that are caused by Java code executing "too early". For example, 
>> `java/util/Locale/CompatWarning.java` can fail if 
>> `sun.util.locale.provider.LocaleProviderAdapter` is initialized before the 
>> `CheckWarning` handler is registered.
>> 
>> Instead of serializing `VM.savedProps` via 
>> `VMSupport.serializeSavedPropertiesToByteArray`, the 
>> `jdk.vm.ci.services.Services` class now directly reads 
>> `Arguments::system_properties()` using `Unsafe`. Furthermore, the value of a 
>> system property is lazily converted to a `String` from a C string pointer.
>> 
>> ## Times
>> 
>> The basic benchmarking below shows that this change brings the time for a 
>> nop Java app with eager libgraal initialization (2) down to almost the same 
>> time as lazy libgraal initialization (1). The latter typically means no 
>> libgraal initialization happens as a top tier JIT compilation is never 
>> scheduled in such a short running app.
>> 
>> 
>> public class Nop {
>>     public static void main(String[] args) {}
>> }
>> 
>> 
>> (1) Baseline (no options):
>> 
>>> for i in (seq 10); java Nop; end
>>         0.05 real         0.04 user         0.01 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.03 real         0.03 user         0.00 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.04 real         0.03 user         0.00 sys
>>         0.03 real         0.03 user         0.00 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.03 real         0.03 user         0.00 sys
>> 
>> 
>> (2) Eagerly initialize libgraal (with PR):
>> 
>>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>>         0.06 real         0.04 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>> 
>> 
>> (3) Eagerly initialize libgraal (without PR):
>> 
>>> for i in (seq 10...
>
> Doug Simon has updated the pull request with a new target base due to a merge 
> or a rebase. The incremental webrev excludes the unrelated changes brought in 
> by the merge/rebase. The pull request contains one additional commit since 
> the last revision:
> 
>   copy system properties into libgraal more efficiently

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/Services.java line 314:

> 312:             String key = toJavaString(unsafe, unsafe.getLong(prop + 
> keyOffset));
> 313:             long valueAddress = unsafe.getLong(prop + valueOffset);
> 314:             if (valueAddress != 0) {

Is the lazy value construction really necessary?  It seems like it requires 
quite a bit of extra machinery.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14291#discussion_r1226038627

Reply via email to