RFR: 8323243: JNI invocation of an abstract instance method corrupts the stack [v3]

Aleksey Shipilev shade at openjdk.org
Thu Jan 11 08:50:25 UTC 2024


On Thu, 11 Jan 2024 07:11:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> See JBS for details.
>> 
>> TL;DR - if an instance method is abstract then JNI front-end should throw AbstractMethodError.
>> 
>> Testing:
>>   - new regression test
>>   -  tiers 1-3 (sanity)
>> 
>> Thanks.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added direct Java test per Aleksey's request

This looks good.

Minor nit still: I think we gotta try the Java side first, because that checks the expected behavior. Right now, if JNI fails, we don't really know if that is a product bug (= "JNI failed to throw AME when it should"), or a test bug (= "the way the test is written, even plain Java does not throw AME"). The point of positive test is to verify the test does what it should: if Java test passes and JNI fails, there is a clear indication JNI does something wrong.

Can we also say "Did not get AbstractMethodError from JNI!" and "Did not get AbstractMethodError from Java!" in exception messages, so that it would be abundantly clear which test had failed.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17337#pullrequestreview-1814992826


More information about the hotspot-runtime-dev mailing list