RFR: 8254693: Add Panama feature to pass heap segments to native code [v8]

Jorn Vernee jvernee at openjdk.org
Fri Oct 20 07:58:37 UTC 2023


On Thu, 19 Oct 2023 22:21:33 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - add stub size stress test for allowHeap
>>  - RISC-V impl
>>  - remove leftover debug log line
>
> This is probably the wrong place to ask this, but the sizing topic leads me to another issue: `RuntimeStub::new_runtime_stub` can return `nullptr` when the code cache is full and we would crash when trying to call `nullptr->print_on(&ls)`. Also, what will the Java code do when `downcallStubAddress` is 0 in the `NativeEntryPoint`?
> Do you want me to file an issue?

@TheRealMDoerr 

> So, we reserve space for 4 instructions, but emit 6 ones.

We could bump up the size per arg.

I think I want to get a review for the rest of the hotspot changes first though, to avoid having to go through that process twice, in case changes to the code gen are needed.

> Would you mind using limit(84) which is the maximum?

Why is 84 the maximum? That would result in 170 Java parameters at most, which is well within the 255 limit imposed by the VM spec.

> `RuntimeStub::new_runtime_stub` can return `nullptr` when the code cache is full

As far as I can see we would hit a `fatal` error when the allocation of the runtime stub fails?

https://github.com/openjdk/jdk/blob/4812cabaa489e99481facddce69686a9fee29c44/src/hotspot/share/code/codeBlob.cpp#L425-L430

Note that `alloc_fail_is_fatal` is true by default, and we don't set it when calling `new_runtime_stub`.

Potentially we could bubble up this allocation failure as a Java exception (and do the same for upcall stubs). That would have the benefit of maybe only bringing down a single Java thread, but is at the same time not really a recoverable error, i.e. we can not just disable the linker, like we can for e.g. the JIT compiler. So I'm not sure if the fatal error is really that problematic. We should probably do the same for upcall stubs either way though. I've filed: https://bugs.openjdk.org/browse/JDK-8318586

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

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1772259563


More information about the core-libs-dev mailing list