On Tue, 17 May 2022 15:53:05 GMT, Jorn Vernee <jver...@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
