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

[Volker Simonis]

Thanks for looking at the change!

Regards,
Volker


On Mon, Aug 20, 2018 at 4:44 PM, Schmidt, Lutz <lutz.schmidt at sap.com> wrote:
> 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
>     > >
>
>