[foreign-memaccess+abi] RFR: 8302346: Lift upcall sharing mechanism to AbstractLinker
Maurizio Cimadamore
mcimadamore at openjdk.org
Wed Feb 15 15:20:35 UTC 2023
On Tue, 14 Feb 2023 11:21:56 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:
> Lift the upcall sharing mechanism to AbstractLinker, where it can live next to the similar mechanism for down calls. This also allows the fallback linker to use this mechanism.
>
> Instead of an upcall stub, AbstractLinker::arrangeDowncall now return an UpcallStubFactory, which is a callback accepting a target MethodHandle and Arena, which are then used to construct the actual upcall stub.
>
> Perhaps the trickiest part of this patch is that we have to simulate the effects of `SharedUtils::adaptUpcallForIMR` on the target method type. I've added a new method in SharedUtils, called `computeUpcallIMRType` for that, which mimics the shape of the `adaptUpcallForIMR` method.
>
> Since the shape of most of the arrangeUpcall methods was very similar, I factored them out into a helper method in SharedUtils as well.
src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 191:
> 189: UpcallStubFactory factory = UpcallLinker.makeFactory(targetType, abi, callingSequence);
> 190:
> 191: if (isInMemoryReturn) {
Question: does this logic belong here? E.g. we have a method that is used to create an upcall factory, namely `UpcallLinker.makeFactory`, but it turns out that if we have `isInMemoryReturn` some other factory should be used instead. Shouldn't we tweak the code so that `makeFactory` always does the right thing?
-------------
PR: https://git.openjdk.org/panama-foreign/pull/791
More information about the panama-dev
mailing list