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
string
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