RFR: 8299570: [JVMCI] Insufficient error handling when CodeBuffer is exhausted [v2]

[Andrew Dinn]

On Wed, 18 Jan 2023 10:24:14 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>>>The if (stub == null) test below should be the else branch of this if which I think makes it clearer
>> 
>> I'm suspecting this is indeed a dormant bug. I will investigate further.
>> 
>> @theRealAph any chance you recall the intended logic here?
>
> I've pushed https://github.com/openjdk/jdk/pull/11945/commits/0e4fb6501dbff8259c7ae131bf81e03e7e362b94 which attempts to clear up the logic in this method. It would be great if some aarch64 experts could help review it (cc @adinn @theRealAph).

@dougxc I'm not sure why the above code is written the way it is rather than the way you rewrote it. I cannot see any reason why there should already be a trampoline stub in place when trampoline_jump is called given how it is being called at present. I thought perhaps it might be something to do with the (newly introduced) shared trampoline code but that is not relevant here and, besides, this routine has been thew way it is since it was first introduced. 

I know the trampoline (and related far jump) code has been subject to change over the years so it may be something to do with how this routine was called in an earlier incarnation of the code. Andrew Haley (@aph) will have a better idea than me as he was the original author.

Anyway, if we may need far branches and the call to is_NativeCallTrampolineStub_at fails then it does not seem tome to make any sense to call set_destination (at least null is returned which is correct). So, I think your rewrite looks like it is doing the right thing.

I think you probably need an ok from Andrew Haley here though.

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

PR: https://git.openjdk.org/jdk/pull/11945