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

[Volker Simonis]

On Mon, Aug 20, 2018 at 4:24 PM, Lindenmaier, Goetz
<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.
>

Good catch! I've updated the patch and placed it into our nightly
build and test queue. If the results are still OK (what I expect) and
Vladimir gives us his OK, I'll push it tomorrow.

For reference (and Vladimir :), I've also created a new webrev:

http://cr.openjdk.java.net/~simonis/webrevs/2018/8209637.v1/

> Maybe you can fix comment in line 1684: "Bandle exception" --> "Handle exception".
>

Done.

> 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
>> >