[foreign-abi] RFR 8228486: Add ABI-specific layout constants
Jorn Vernee
jbvernee at xs4all.nl
Tue Jul 23 13:48:00 UTC 2019
On 2019-07-23 15:40, Jorn Vernee wrote:
> Ok, this is also what we talked about a bit before.
>
> Like you said in your other email; to support varargs on Windows we'd
> need to add some `MemoryLayout asVarArg(MemoryLayout)` method on
> SystemABI that does nothing for the other 2 ABIs, there are other
> points where the ABIs might diverge that are not naturally expressible
> as MemoryLayout constants as well (though we could add a
> Windows.Varargs version of all the constants as well). It seems that
> exposing annotations so that users can add ABI specific annotation to
> an argument layout is a bit cleaner.
Though, actually, we could also put that method in the
MemoryLayouts.WinABI class and that would also be pretty clean :)
Jorn
> This also brings up the discussion of needing to account for
> annotations when checking for layout equality. I think at least for
> checking FunctionDescriptor equality we should take annotations into
> account as well. Then we can e.g. distinguish a function that takes a
> 64 bit float value normally, from one that takes a 64 bit float as a
> vararg on Windows. (similarly with int vs float values perhaps).
>
> Jorn
>
> On 2019-07-23 15:27, Maurizio Cimadamore wrote:
>> On 23/07/2019 14:20, Jorn Vernee wrote:
>>> Also, why aren't annotations exposed at the MemoryLayout level?
>>
>> I wanted to experiment if we could get away w/o exposing them in the
>> API - but having them internally as a more stable basis for
>> implementing things like Layout names.
>>
>> I'd like first to get a sense about how people will be using
>> annotations. Layout names are useful and referenced by the 'path' API;
>> general annotations don't have that kind of visibility in the API, so
>> there's a chance they are just for us/jextract.
>>
>> Maurizio
>>
>>>
>>> Jorn
>>>
>>> On 2019-07-23 15:07, Jorn Vernee wrote:
>>>> The tests pass on Windows. Overall the patch looks good
>>>>
>>>> - in TestUpcall you seem to be using the SysV.C_POINTER constant
>>>> instead of the magic one.
>>>>
>>>> - Do we need to distinguish between POINTER and INTEGER class?
>>>> Shouldn't this just be about in which register it's passed? It looks
>>>> like the isPointer predicate is only used in the tests in order to
>>>> construct dummy arguments, is there another way around this? (e.g.
>>>> checking that the carrier is a MemoryAddress).
>>>>
>>>> Some things that I can look into:
>>>>
>>>> * We can mark vararg arguments with a layout annotation on Windows
>>>> to
>>>> be able to support vargargs on Windows as well.
>>>>
>>>> * I think some of the code in Window's CallingSequenceBuilderImpl
>>>> could be removed at this point (e.g. the x87 stuff), since it's not
>>>> supported by the Windows C ABI any ways.
>>>>
>>>> Jorn
>>>>
>>>> On 2019-07-22 19:23, Maurizio Cimadamore wrote:
>>>>> Hi,
>>>>> the recent push for JDK-8228447, as expected, broke the foreign-abi
>>>>> branch, since that branch depended on the ValueLayout::isIntegral
>>>>> accessor.
>>>>>
>>>>> This patch replaces that logic with the custom layout annotation
>>>>> logic
>>>>> discussed in [1]:
>>>>>
>>>>> http://cr.openjdk.java.net/~mcimadamore/panama/8228486/
>>>>>
>>>>> This patch makes the following changes:
>>>>>
>>>>> * introduces three set of annotated layout constants, one for
>>>>> supported ABI
>>>>> * the annotations point directly at the ABI-specific argument
>>>>> classes
>>>>> * I've consolidated ArgumentClass a bit, so that now there's a
>>>>> common,
>>>>> ABI-agnostic super-interface with some general predicates
>>>>> * AddressLayout has been removed (we can just look for
>>>>> argumentClass::isPointer)
>>>>> * the tests have been tweaked to use the new ABI-specific
>>>>> constants;
>>>>> since the test has to work across platforms, all ABI test use a new
>>>>> interface which imports the 'right' set of constants
>>>>>
>>>>> While the patch might be a bit raw (I've only tested on Linux x64),
>>>>> I
>>>>> like where this is going.
>>>>>
>>>>> Maurizio
More information about the panama-dev
mailing list