RFR 4947890 : Minimize JNI upcalls in system-properties initialization

Roger Riggs Roger.Riggs at oracle.com
Wed Nov 14 14:51:13 UTC 2018

Hi Thomas,

I was aiming for a fairly straightforward, easy to maintain technique,
not too far removed from the current implementation.

The strings need to be created sometime and the JNI function to create a 
doesn't suffer from much overhead (compared to java) so I don't think it
would make much of a difference to delay their creation.

The fixed indices have no lookup overhead and with @Native and the
generated .h file there is no code to get out of sync. It might look nicer
in the source code if Java enums supported @Native, but that's a 
different topic.

Thanks for the suggestion, but I think I'll keep the current approach.

Regards, Roger

On 11/13/2018 04:21 PM, Thomas Stüfe wrote:
> Hi Roger,
> I somehow wonder whether that coding could be further simplified and
> maybe made faster by just returning a big byte array or String from
> the hotspot containing a concatenation of key-value pairs, each
> separated by \0, e.g. like this:
> "os.name\0linux\0os.arch\0i386\0java.io.tmpdir\0/tmp\0..."
> instead of a string array, that is.
> That string could be parsed in java, chopped into single string
> key-value pairs, which one could feed it into the Properties.
> For speedups, one could even return an integer array in addition to
> the big string, containing the start indices of the key/value strings.
> That way, one would also not have to maintain named indices in java.
> Just a thought. I may not seeing the whole picture though.
> Best Regards, Thomas
> On Tue, Nov 13, 2018 at 5:03 PM Roger Riggs <Roger.Riggs at oracle.com> wrote:
>> Please review a re-implementation of the initialization of System properties
>> moving some functions from native to Java.
>> The upcalls from native to java for each property are replaced by a
>> mechanism
>> to gather the platform, VM and command line properties and return them
>> from a single JNI call.  The creation of the Properties instance and
>> applying
>> command line overrides is handled in Java instead of native.
>> The JVM_initProperties interface in Hotspot is replaced by
>> JVM_getProperties.
>> Webrev:
>>     http://cr.openjdk.java.net/~rriggs/webrev-props-only-raw/
>> Issue:
>>     https://bugs.openjdk.java.net/browse/JDK-4947890
>> Thanks, Roger

More information about the core-libs-dev mailing list