Re: RFR: Export InitializeEncoding for JVM access
Many thanks Roger, much appreciated. Cheers Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leon...@uk.ibm.com From: Roger Riggs To: Andrew Leonard Cc: core-libs-dev@openjdk.java.net Date: 09/04/2018 19:52 Subject:Re: RFR: Export InitializeEncoding for JVM access Hi Andrew, ok, it turns out the prototype in jni_util.h also needs to be updated to be consistent for Windows and Solaris. And no surprise, there are no test failures. I put an updated webrev in: http://cr.openjdk.java.net/~rriggs/webrev-encoding-8201246/ If there are no more comments, I'll commit tomorrow. Regards, Roger On 4/9/2018 8:57 AM, Andrew Leonard wrote: Thanks for the feedback Roger, Yes, exporting the InitializeEncoding entry point would make sense, keeping it consistent with Canonicalize(). I have attached the new patch below: Many thanks Andrew diff --git a/src/java.base/share/native/libjava/jni_util.c b/src/java.base/share/native/libjava/jni_util.c --- a/src/java.base/share/native/libjava/jni_util.c +++ b/src/java.base/share/native/libjava/jni_util.c @@ -774,8 +774,10 @@ return newSizedStringJava(env, str, len); } -/* Initialize the fast encoding from the encoding name. */ -void +/* Initialize the fast encoding from the encoding name. + * Export InitializeEncoding so that the VM can initialize it if required. + */ +JNIEXPORT void InitializeEncoding(JNIEnv *env, const char *encname) { jclass strClazz = NULL; Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leon...@uk.ibm.com From:Roger Riggs To:Andrew Leonard Cc:core-libs-dev@openjdk.java.net Date:06/04/2018 15:39 Subject: Re: RFR: Export InitializeEncoding for JVM access Hi Andrew, Would it be sufficient to export the InitializeEncoding entry point? Introducing a JNU_xx name may imply a level of support that is unwarranted since it is part of system initialization and may change as needed by the implementation. Simply exporting it would put it on par with Canonicalize. Thanks, Roger p.s. Tracking issue: https://bugs.openjdk.java.net/browse/JDK-8201246 On 4/5/2018 5:49 AM, Andrew Leonard wrote: Hi Roger, The OpenJ9 VM implementation provides its own java.lang.System, which performs similar type early-on VM initialization to the OpenJDK core library classes. The basic reason for invoking the method is to initialize the platform encoding either called from a related core library method, eg.initProperties(), or from the VM in the early stages of initialization. My suggested comparison with canonicalize was based on it's indicated usage: /* * Export the platform dependent path canonicalization so that * VM can find it when loading system classes. * This function is also used by the instrumentation agent. */ extern int canonicalize(char *path, const char *out, int len); JNIEXPORT int Canonicalize(JNIEnv *unused, char *orig, char *out, int len) { /* canonicalize an already natived path */ return canonicalize(orig, out, len); } Many thanks, Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leon...@uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: RFR: Export InitializeEncoding for JVM access
Hi Andrew, ok, it turns out the prototype in jni_util.h also needs to be updated to be consistent for Windows and Solaris. And no surprise, there are no test failures. I put an updated webrev in: http://cr.openjdk.java.net/~rriggs/webrev-encoding-8201246/ If there are no more comments, I'll commit tomorrow. Regards, Roger On 4/9/2018 8:57 AM, Andrew Leonard wrote: Thanks for the feedback Roger, Yes, exporting the InitializeEncoding entry point would make sense, keeping it consistent with Canonicalize(). I have attached the new patch below: Many thanks Andrew diff --git a/src/java.base/share/native/libjava/jni_util.c b/src/java.base/share/native/libjava/jni_util.c --- a/src/java.base/share/native/libjava/jni_util.c +++ b/src/java.base/share/native/libjava/jni_util.c @@ -774,8 +774,10 @@ return newSizedStringJava(env, str, len); } -/* Initialize the fast encoding from the encoding name. */ -void +/* Initialize the fast encoding from the encoding name. + * Export InitializeEncoding so that the VM can initialize it if required. + */ +JNIEXPORT void InitializeEncoding(JNIEnv *env, const char *encname) { jclass strClazz = NULL; Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leon...@uk.ibm.com From: Roger Riggs To: Andrew Leonard Cc: core-libs-dev@openjdk.java.net Date: 06/04/2018 15:39 Subject: Re: RFR: Export InitializeEncoding for JVM access Hi Andrew, Would it be sufficient to export the InitializeEncoding entry point? Introducing a JNU_xx name may imply a level of support that is unwarranted since it is part of system initialization and may change as needed by the implementation. Simply exporting it would put it on par with Canonicalize. Thanks, Roger p.s. Tracking issue: _https://bugs.openjdk.java.net/browse/JDK-8201246_ <https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8201246&d=DwMD-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=p_fQLlNXJvoVJa69tdD-jWziIgb70BegiqN-SuPhUPk&s=Jvw6DlMaepuFnlUKt1l04hqhMaetcEE4PwHYD_9pnrE&e=> On 4/5/2018 5:49 AM, Andrew Leonard wrote: Hi Roger, The OpenJ9 VM implementation provides its own java.lang.System, which performs similar type early-on VM initialization to the OpenJDK core library classes. The basic reason for invoking the method is to initialize the platform encoding either called from a related core library method, eg.initProperties(), or from the VM in the early stages of initialization. My suggested comparison with canonicalize was based on it's indicated usage: /* * Export the platform dependent path canonicalization so that * VM can find it when loading system classes. * This function is also used by the instrumentation agent. */ extern int canonicalize(char *path, const char *out, int len); JNIEXPORT int Canonicalize(JNIEnv *unused, char *orig, char *out, int len) { /* canonicalize an already natived path */ return canonicalize(orig, out, len); } Many thanks, Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: _andrew_m_leon...@uk.ibm.com_ <mailto:andrew_m_leon...@uk.ibm.com> Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: RFR: Export InitializeEncoding for JVM access
Thanks for the feedback Roger, Yes, exporting the InitializeEncoding entry point would make sense, keeping it consistent with Canonicalize(). I have attached the new patch below: Many thanks Andrew diff --git a/src/java.base/share/native/libjava/jni_util.c b/src/java.base/share/native/libjava/jni_util.c --- a/src/java.base/share/native/libjava/jni_util.c +++ b/src/java.base/share/native/libjava/jni_util.c @@ -774,8 +774,10 @@ return newSizedStringJava(env, str, len); } -/* Initialize the fast encoding from the encoding name. */ -void +/* Initialize the fast encoding from the encoding name. + * Export InitializeEncoding so that the VM can initialize it if required. + */ +JNIEXPORT void InitializeEncoding(JNIEnv *env, const char *encname) { jclass strClazz = NULL; Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leon...@uk.ibm.com From: Roger Riggs To: Andrew Leonard Cc: core-libs-dev@openjdk.java.net Date: 06/04/2018 15:39 Subject:Re: RFR: Export InitializeEncoding for JVM access Hi Andrew, Would it be sufficient to export the InitializeEncoding entry point? Introducing a JNU_xx name may imply a level of support that is unwarranted since it is part of system initialization and may change as needed by the implementation. Simply exporting it would put it on par with Canonicalize. Thanks, Roger p.s. Tracking issue: https://bugs.openjdk.java.net/browse/JDK-8201246 On 4/5/2018 5:49 AM, Andrew Leonard wrote: Hi Roger, The OpenJ9 VM implementation provides its own java.lang.System, which performs similar type early-on VM initialization to the OpenJDK core library classes. The basic reason for invoking the method is to initialize the platform encoding either called from a related core library method, eg.initProperties(), or from the VM in the early stages of initialization. My suggested comparison with canonicalize was based on it's indicated usage: /* * Export the platform dependent path canonicalization so that * VM can find it when loading system classes. * This function is also used by the instrumentation agent. */ extern int canonicalize(char *path, const char *out, int len); JNIEXPORT int Canonicalize(JNIEnv *unused, char *orig, char *out, int len) { /* canonicalize an already natived path */ return canonicalize(orig, out, len); } Many thanks, Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leon...@uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: RFR: Export InitializeEncoding for JVM access
Hi Andrew, Would it be sufficient to export the InitializeEncoding entry point? Introducing a JNU_xx name may imply a level of support that is unwarranted since it is part of system initialization and may change as needed by the implementation. Simply exporting it would put it on par with Canonicalize. Thanks, Roger p.s. Tracking issue: https://bugs.openjdk.java.net/browse/JDK-8201246 On 4/5/2018 5:49 AM, Andrew Leonard wrote: Hi Roger, The OpenJ9 VM implementation provides its own java.lang.System, which performs similar type early-on VM initialization to the OpenJDK core library classes. The basic reason for invoking the method is to initialize the platform encoding either called from a related core library method, eg.initProperties(), or from the VM in the early stages of initialization. My suggested comparison with canonicalize was based on it's indicated usage: /* * Export the platform dependent path canonicalization so that * VM can find it when loading system classes. * This function is also used by the instrumentation agent. */ extern int canonicalize(char *path, const char *out, int len); JNIEXPORT int Canonicalize(JNIEnv *unused, char *orig, char *out, int len) { /* canonicalize an already natived path */ return canonicalize(orig, out, len); } Many thanks, Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leon...@uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: RFR: Export InitializeEncoding for JVM access
Hi Roger, The OpenJ9 VM implementation provides its own java.lang.System, which performs similar type early-on VM initialization to the OpenJDK core library classes. The basic reason for invoking the method is to initialize the platform encoding either called from a related core library method, eg.initProperties(), or from the VM in the early stages of initialization. My suggested comparison with canonicalize was based on it's indicated usage: /* * Export the platform dependent path canonicalization so that * VM can find it when loading system classes. * This function is also used by the instrumentation agent. */ extern int canonicalize(char *path, const char *out, int len); JNIEXPORT int Canonicalize(JNIEnv *unused, char *orig, char *out, int len) { /* canonicalize an already natived path */ return canonicalize(orig, out, len); } Many thanks, Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leon...@uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: RFR: Export InitializeEncoding for JVM access
Hi Andrew, The function itself seems straightforward enough. Can you clarify the boundary that you are replacing? The initialization has a lot of intermingled responsibilities and is quite sensitive. What else needs to be said about when it can be called and who should be calling it? I don't see the similarity to Canonicalize, which is not a supported interface, just exported for use within the implementation. Thanks, Roger On 4/4/2018 8:17 AM, Andrew Leonard wrote: Hi, I would like to propose and find a sponsor for this change please, which is is export from libjava the JNU_InitializeEncoding() method, so that a JVM can initialize the platform encoding. Currently Java_java_lang_System_initProperties initializes the encoding, however for a generic JVM that will naturally provide it's own System implementation, the JVM needs a way to initialize this encoding directly. We can thus simply export it as per the change below.. There is precendence for doing this sort of export with Canonicalize(). Thanks Andrew diff --git a/src/java.base/share/native/libjava/jni_util.c b/src/java.base/share/native/libjava/jni_util.c --- a/src/java.base/share/native/libjava/jni_util.c +++ b/src/java.base/share/native/libjava/jni_util.c @@ -840,6 +840,15 @@ String_value_ID = (*env)->GetFieldID(env, strClazz, "value", "[B"); } +/* + * Export this method to allow JVM to initialize platform encoding explicitly. + */ +JNIEXPORT void JNICALL +JNU_InitializeEncoding(JNIEnv *env, const char *encname) +{ + InitializeEncoding(env, encname); +} + JNIEXPORT jstring NewStringPlatform(JNIEnv *env, const char *str) { Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leon...@uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU