RFR: 8283689: Update the foreign linker VM implementation [v23]

[Doug Simon]

On Tue, 17 May 2022 15:53:05 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
>> 
>> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
>> 
>> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
>> 
>> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
>> 
>> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
>> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
>> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
>> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
>> 
>> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
>> 
>> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
>> 
>> Testing: Tier1-4
>> 
>> Thanks,
>> Jorn
>> 
>> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
>> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
>> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
>> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
>> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
>> [6]: https://github....
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits:
> 
>  - Merge branch 'master' into JEP-19-VM-IMPL2
>  - ifdef NOT_PRODUCT -> ifndef PRODUCT
>  - Missing ASSERT -> NOT_PRODUCT
>  - Cleanup UL usage
>  - Fix failure with SPEC disabled (accidentally dropped change)
>  - indentation
>  - fix space
>  - Merge branch 'master' into JEP-19-VM-IMPL2
>  - Undo spurious changes.
>  - Merge branch 'JEP-19-VM-IMPL2' of https://github.com/JornVernee/jdk into JEP-19-VM-IMPL2
>  - ... and 95 more: https://git.openjdk.org/jdk/compare/af07919e...c3c1421b

src/hotspot/cpu/aarch64/universalNativeInvoker_aarch64.cpp line 105:

> 103: 
> 104:   RuntimeStub* stub =
> 105:     RuntimeStub::new_runtime_stub("nep_invoker_blob",

Is it acceptable for a VM fatal error to occur when the `RuntimeStub` cannot be allocated due to a (temporarily?) full code cache? If not, then you may want to do something like I'm doing in https://github.com/openjdk/jdk/pull/15970.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/7959#discussion_r1340644955