[11u] RFR: 8213845: ARM32: Interpreter doesn't call result handler after native calls

Christoph Göttschkes christoph.goettschkes at microdoc.com
Thu Apr 8 07:39:38 UTC 2021

Thanks for the review and the explanation, Paul.
I knew, that it has been removed, but didn't know the state of it in 11u. I will ignore it then as well.

-- Christoph

On 4/8/21 1:42 AM, Hohensee, Paul wrote:
> Lgtm. The Oracle arm64 port was removed in JDK 12 in favor of the Red Hat aarch64 port, and afaik has not been maintained since. Imo it's not worth the effort to either keep it building or remove it from 11u.
> Thanks,
> Paul
> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> on behalf of Christoph Göttschkes <christoph.goettschkes at microdoc.com>
> Date: Tuesday, April 6, 2021 at 12:21 AM
> To: "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
> Subject: RE: [11u] RFR: 8213845: ARM32: Interpreter doesn't call result handler after native calls
> Gentle reminder.
> On 3/23/21 9:49 AM, Christoph Göttschkes wrote:
>> Hi,
>> please review this backport of JDK-8213845 to 11u:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213845
>> Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/2d795829f39f
>> Webrev: https://cr.openjdk.java.net/~cgo/8213845/webrev.11u.00/
>> This patch fixes the conversion between C and Java boolean types, which value is
>> not 0 or 1 in C on aarch32. This also fixes the test case
>> "runtime/BoolReturn/JNIBooleanTest.java", which is testing this conversion.
>> The backport is not clean, because in 11u, the arm64 CPU type is still present.
>> Adjusting the backport was fairly straight forward. Because of the arm64 CPU type,
>> there are some additional #ifdef present and the changes had to be incoporated
>> into the arm64 port as well. No additional changes have been made, only slight
>> adjustments.
>> I am not able to test the arm64 port, since it doesn't compile anymore and I don't
>> know if this CPU type is still supported, or if the code remains there because it
>> is deemed to complicated to remove it.
>> Tested:
>>    * Hotspot tier1 on linux aarch32
>>    * Hotspot tier1 on linux aarch32 with -XX:+VerifyOops and -Xcheck:jni
>>    * Hotspot tier1 on linux ARMv7-A
>> Thanks,
>> Christoph

More information about the jdk-updates-dev mailing list