[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