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

[Vladimir Kozlov]

Testing passed and I approved it.

Please, push fix into jdk11 ASAP - we have one day left.

Thanks,
Vladimir

On 8/20/18 9:08 AM, Volker Simonis wrote:
> 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
>>>>