[aarch64-port-dev ] hotspot jtreg runtime/BoolReturn/JNIBooleanTest.java failure

[Andrey Petushkov]

Something like this:
http://cr.openjdk.java.net/~apetushkov/jnibooleantest/webrev/ <http://cr.openjdk.java.net/~apetushkov/jnibooleantest/webrev/>

jtreg is good now, both no-arg and Xint

Regards,
Andrey

> On 21 Sep 2018, at 16:33, Andrew Haley <aph at redhat.com> wrote:
> 
> On 09/21/2018 12:02 PM, Andrey Petushkov wrote:
> 
>> Just wanted to ask whether you want this fixed in jdk11. Apparently
>> now raw value of jboolean (i.e. u8) returned by JNI method fed into
>> java code, where it’s treated in different way. (value != 0 vs bit0
>> != 0) Not sure if it is considered to be belonging to BBB domain or
>> just a mere possibility of application developers to shoot
>> themselves into foot. I’d fix it with proper value conversion at
>> http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp#l1925
>> <http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp#l1925>
>> If you’d like I can prepare a patch (although I assume unless it’s
>> BBB-type thing it’s probably too late for jdk11)
> 
> It's been a bug for a long time. I guess the best fix is to define
> c2bool the same as x86 and use it in
> TemplateInterpreterGenerator::generate_result_handler_for and
> SharedRuntime::generate_native_wrapper.
> 
> Mind you, that behaviour is very odd: ignore all but the bottom 8 bits
> of the result register and set the return value, i.e.:
> 
>  return (byte)result != 0 ? 1 : 0
> 
> I guess it makes sense, given that jbool is defined to be an unsigned
> 8-bit integer type.
> 
> -- 
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671