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.ri...@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
