Thanks Volker! I hadn't been following new development much and this is great! I just checked the latest HS sources [1] and my old code is still there. I'll prepare a webrev to remove that workaround code.
Thanks, Kris [1]: http://hg.openjdk.java.net/jdk/jdk/file/8dfed4387312/src/hotspot/share/c1/c1_Runtime1.cpp#l1380 On Mon, Aug 20, 2018 at 9:28 AM, Volker Simonis <volker.simo...@gmail.com> wrote: > On Mon, Aug 20, 2018 at 6:09 PM, Krystal Mok <rednaxel...@gmail.com> > wrote: > > Hi guys, > > > > Haha this is fun. I actually hit this issue the hard way and had to > tweak a > > bit of my code to accommodate that: I had to return a jint from a > function > > that I wanted to return a jbool at first: > > http://hg.openjdk.java.net/hsx/hsx25/hotspot/diff/ > 8f37087fc13f/src/share/vm/c1/c1_Runtime1.cpp > > > > Interesting, but I think that mis-behavior should have been fixed > meanwhile by the infamous "Better byte behavior" change [1] (which was > a security fix, so you won't find too much information about it). > > So maybe you can remove your workaround and comment now :) > > [1] http://hg.openjdk.java.net/jdk/jdk/rev/291ee208fb72 > > > - Kris > > > > On Mon, Aug 20, 2018 at 8:38 AM Volker Simonis <volker.simo...@gmail.com > > > > wrote: > >> > >> On Mon, Aug 20, 2018 at 4:55 PM, Aleksey Shipilev <sh...@redhat.com> > >> wrote: > >> > On 08/20/2018 12:22 PM, Volker Simonis wrote: > >> >> So to summarize, my current view on this topic is: > >> >> - JNI functions returning a jboolean are only allowed to return > >> >> JNI_TRUE/JNI_FALSE (or 1/0) according to the current JNI > spcification. > >> > > >> > Now *I* am having trouble seeing where exactly the JNI spec says the > >> > domain of jboolean is > >> > (JNI_FALSE, JNI_TRUE). In "Primitive Types" [1] it says "The following > >> > definition is provided for > >> > convenience: JNI_FALSE, JNI_TRUE", but that does not restrict the > >> > domain, because those are > >> > "convenience" defines. And "Description" in the table says jboolean is > >> > "unsigned 8 bits", which > >> > seems to invite interpretation that all 8 bits are usable. > >> > > >> > John says [2]: > >> > > >> > "The JNI documents specify that, at least for returning values from > >> > native methods, a Java boolean > >> > (T_BOOLEAN) value is converted to the value-set 0..1 by first > truncating > >> > to a byte (0..255 or maybe > >> > -128..127) and then testing against zero." > >> > > >> > ...which is what I am looking for, but I cannot find the "JNI > document" > >> > that actually says that. I > >> > can see the idea of that in JVMS [3], but that seems to only apply to > >> > on-heap booleans, does that > >> > also extend to jboolean's? Maybe John can point out the JNI document > >> > where it is said explicitly? > >> > > >> > >> Yes, you're right - there's no exact documentation for neither of the > >> two possible interpretations. A colleague just pointed me to the > >> definition of invokestatic in the JVMS [4] which has the following > >> sentence: > >> > >> "If the native method returns a value, the return value of the > >> platform-dependent code is converted in an implementation-dependent > >> way to the return type of the native method and pushed onto the > >> operand stack." > >> > >> But then again, it has this unfortunate "implementation-dependent" > >> which can be interpreted either way :( > >> > >> [4] > >> https://docs.oracle.com/javase/specs/jvms/se10/html/ > jvms-6.html#jvms-6.5.invokestatic > >> > >> > > >> >> - to code in Java_java_io_Console_echo() should be fixed (as > >> >> confirmed by Sherman later in this thread) > >> > > >> > Yes, that's a bug waiting to happen anyway. > >> > > >> > > >> >> - normalization of native, off-heap 8-bit values to Java booleans as > >> >> currently implemented in the HotSpot (and fixed by JDK-8161720) is > (1) > >> >> only for convenience to simply access to off-heap data in Unsafe, (2) > >> >> to implement better Java/Native integration in projects like Panama > >> >> and (3) to fix legacy JNI code which was developed under the > >> >> assumption that the advice in the "JNI Programmer's Guide & > >> >> Specification" book is specification relevant. > >> > > >> > Yes, the intent seems to be what you describe. But see above about the > >> > spec. > >> > > >> > > >> > -Aleksey > >> > > >> > [1] > >> > https://docs.oracle.com/javase/8/docs/technotes/ > guides/jni/spec/types.html#primitive_types > >> > [2] > >> > http://mail.openjdk.java.net/pipermail/hotspot-compiler- > dev/2016-August/024263.html > >> > [3] > >> > https://docs.oracle.com/javase/specs/jvms/se10/html/ > jvms-2.html#jvms-2.3.4 > >> > >
