[11] RFR(S): 8209637: [s390x] Interpreter doesn't call result handler after native calls

[Schmidt, Lutz]

Hi Volker,

I agree with Goetz's judgement. He was just a bit quicker than me. __ Thanks for tracking this down and fixing it. 

Regards,
Lutz 

On 20.08.18, 16:24, "hotspot-dev on behalf of Lindenmaier, Goetz" <hotspot-dev-bounces at openjdk.java.net on behalf of goetz.lindenmaier at sap.com> wrote:

    Hi Volker, 
    
    the fix looks good to me, but please use mem2reg_opt instead of load_and_test_long.
    The test result is not used.
    
    Maybe you can fix comment in line 1684: "Bandle exception" --> "Handle exception".
    
    Don't need a new webrev.
    
    Thanks and best regards,
      Goetz.
    
    
    > -----Original Message-----
    > From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> On Behalf Of
    > Vladimir Kozlov
    > Sent: Freitag, 17. August 2018 22:33
    > To: Volker Simonis <volker.simonis at gmail.com>; HotSpot Open Source
    > Developers <hotspot-dev at openjdk.java.net>
    > Subject: Re: [11] RFR(S): 8209637: [s390x] Interpreter doesn't call result
    > handler after native calls
    > 
    > Hi Volker,
    > 
    > Someone who is familiar with this s390 code should review it before we can
    > judge if it acceptable fro JDK 11.
    > 
    > Regards,
    > Vladimir
    > 
    > On 8/17/18 7:03 AM, Volker Simonis wrote:
    > > Hi,
    > >
    > > can I please have a review for this small, s390x only bug fix which
    > > I'd like to bring to jdk11:
    > >
    > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8209637/
    > > https://bugs.openjdk.java.net/browse/JDK-8209637
    > >
    > > The problem is that the template interpreter for s390x doesn't call
    > > the result handler in the native entry. This can lead to wrong results
    > > being passed as return values from native calls which return a
    > > jboolean if the value is not exactly '1' or '0' (i.e. a return value
    > > of '2' will be interpreted as 'false'). The result handler usually
    > > normalizes such results and maps any value > 0 to 'true'.
    > >
    > > I'd like to bring this to jdk11 because the bug can lead to incorrect
    > > results for calls to JNI functions with jboolean results. This can
    > > affect not only user coding but also core library functions like
    > > java.io.Console.echo() (which is called from Console.readPassword()).
    > > The malfunction of these methods triggered the discovery of this bug.
    > >
    > > The fix is low risk and only affects the s390x port (except the
    > > regression test - but that shouldn't be harmful either).
    > >
    > > Thank you and best regards,
    > > Volker
    > >