8308293: A linker should expose the layouts it supports by mcimadamore · Pull Request #14037 · openjdk/jdk

mcimadamore · 2023-05-17T17:15:06Z

This patch adds an instance method on Linker, namely Linker::canonicalLayouts which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:

jshell> import java.lang.foreign.*;

jshell> Linker.nativeLinker().canonicalLayouts()
$2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}

This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as long double or complex long.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue
Change requires CSR request JDK-8308304 to be approved

Issues

JDK-8308293: A linker should expose the layouts it supports
JDK-8308304: A linker should expose the layouts it supports (CSR)

Reviewers

Paul Sandoz (@PaulSandoz - Reviewer)
Per Minborg (@minborg - Committer) ⚠️ Review applies to dbc8049a

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/14037/head:pull/14037
$ git checkout pull/14037

Update a local copy of the PR:
$ git checkout pull/14037
$ git pull https://git.openjdk.org/jdk.git pull/14037/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 14037

View PR using the GUI difftool:
$ git pr show -t 14037

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/14037.diff

Webrev

Link to Webrev Comment

Add char type

bridgekeeper · 2023-05-17T17:15:54Z

👋 Welcome back mcimadamore! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2023-05-17T17:18:59Z

@mcimadamore The following label will be automatically applied to this pull request:

core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mcimadamore · 2023-05-17T17:20:13Z

src/java.base/share/classes/java/lang/foreign/Linker.java

    SymbolLookup defaultLookup();

+    /**
+     * {@return a mapping between the names of data types used by the ABI implemented by this linker and their


Much of the verbiage here is carried over from defaultLookup as we need to do the usual dance of saying that the set of returned types is not specified, but should be (a) sensible and (b) stable.

mcimadamore · 2023-05-17T17:21:12Z

src/java.base/share/classes/java/lang/foreign/Linker.java

 * <p>
- * All the native linker implementations limit the function descriptors that they support to those that contain
- * only so-called <em>canonical</em> layouts. A canonical layout has the following characteristics:
+ * All the native linker implementations can only operate on a subset of memory layouts, called <em>supported layouts</em>.


I revamped this section as I realized that what we had did not cover things in the recursive case - e.g. a struct layout is only supported if it contains other supported layouts. This new text should hopefully capture everything in a more mathematical form.

mcimadamore · 2023-05-17T17:46:07Z

javadoc: https://cr.openjdk.org/~mcimadamore/jdk/8308293/v1/javadoc/java.base/module-summary.html
specdiff: https://cr.openjdk.org/~mcimadamore/jdk/8308293/v1/specdiff_out/overview-summary.html

mlbridge · 2023-05-17T17:52:54Z

Webrevs

openjdk · 2023-05-17T18:12:53Z

@mcimadamore Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information.

PaulSandoz · 2023-05-17T22:08:57Z

src/java.base/share/classes/java/lang/foreign/Linker.java

- * <li>It does not contain padding other than what is strictly required to align its non-padding layout elements,
- * or to satisfy constraint 3</li>
+ * <li>the alignment constraint of {@code G} is set to its <a href="MemoryLayout.html#layout-align">natural alignment</a>;</li>
+ * <li>the size of {@code G} is a multiple of its alignment constraint;</li>


Do you think this is a constraint that will hold across all linker implementations?

All "native linkers" as the text says. Other linkers (e.g. not for C) might obey other rules. These rules are basically constraining struct layouts to what can come out of a native compiler in the absence of pragma pack directives.

Ah, i see now, i missed the relevance of that term, introduced earlier in non-modified text.

PaulSandoz

I wonder if we need to be stronger on the compatibility requirements for the supported canonical layouts. It seems we can make stronger claims than symbols made available by the defaultLookup because the ABI supported by the native linker will make strong (specification) claims.

So maybe this comes down to the linker supporting a subset ABI's data types, and that subset might increase over time, but never decrease? In this respect could we present a table for each supported linker ABI listing the ABI type and its canonical layout type? (in practice it might just be one table with noted adjustments.)

Then there is the possibility that a linker might change the layout corresponding to a data type. Ideally the linker support the prior layout and the new layout. I don't think this will arise with the current support set of supported ABI data types, but it might if we choose to add support for say the optional __int128 data type prior to the platform adding support for a primitive value class of Int128?

[1] https://gitlab.com/x86-psABIs/x86-64-ABI

mcimadamore · 2023-05-17T23:04:30Z

So maybe this comes down to the linker supporting a subset ABI's data types, and that subset might increase over time, but never decrease? In this respect could we present a table for each supported linker ABI listing the ABI type and its canonical layout type? (in practice it might just be one table with noted adjustments.)

I see what you mean and I'm not sure about this. On the one hand, having a set of "trusted" type names would be handy - but I don't know how much commitment we want to put in there? I'm also a bit skeptical at listing all possible ABIs, since I suspect the set of supported platforms will change quickly.

Is what you are after some kind of guarantee of "at least these type names will be available" ?

As for a linker possibly having multiple different layouts for the same ABI type, that is true, and, in a way, already the case with ValueLayout.OfChar/ValueLayout.OfShort. I worked around that by using different type names - e.g. int16_t and char16_t.

For more exotic types which might be modeled initially opaquely with MemorySegment, and later on with some other ValueLayout.OfFooBar, I believe we'd need to provide a way to go from the opaque layout to the less opaque one.

The other option would be to admit that a single ABI type can map to multiple layouts, and have Map<String, List<MemoryLayout>>. It seemed a bit on the convoluted side of things (esp. given that we can get away without it, at least in this patch), but if you think that would be more robust, I can change that.

PaulSandoz · 2023-05-18T16:52:15Z

Here's the crux of what i am wondering about. Can we specify native linker support for a subset of the System V Application Binary Interface (e.g., LP64 and ILP32 programming models for all non-optional scalar types, sequences of, and groups of) such that a developer can write code using the FFM API and it will work across all JDK implementations supporting that native linker?

AFAICT the closest we have to that is the table in the Linker doc, and that table references C type names. Perhaps we can use C type name as the ABI type name for the System V Application Binary Interface? (literally copy the name used in Figure 3.1 C column of the ABI specification).

Then can do we the same and specify the equivalent native linker support for ABIs of Windows 64/32 and ARM?

mcimadamore · 2023-05-18T17:42:28Z

Here's the crux of what i am wondering about. Can we specify native linker support for a subset of the System V Application Binary Interface (e.g., LP64 and ILP32 programming models for all non-optional scalar types, sequences of, and groups of) such that a developer can write code using the FFM API and it will work across all JDK implementations supporting that native linker?

AFAICT the closest we have to that is the table in the Linker doc, and that table references C type names. Perhaps we can use C type name as the ABI type name for the System V Application Binary Interface? (literally copy the name used in Figure 3.1 C column of the ABI specification).

Then can do we the same and specify the equivalent native linker support for ABIs of Windows 64/32 and ARM?

Consider that, at the time of writing we support (or might support soon):

Sysv (Linux and MacOS)
Aarch64(Linux, MacOs, Windows) - these have actually some ABI differences (e.g. variadic calls)
PowerPC (which might come in big/little endian flavors)
RiscV

That's quite a lot of ABIs and tables to have.

Also, if we wanted to tighten up the spec a little bit, what the user cares about is some minimum guarantees about the supported ABI types across platforms. E.g. you don't want a table-per-ABI, precisely because you want to know (I think): "if I call linker.canonicalLayout().get("int")" is this call guaranteed to succeed?

So, pulling on the string, IMHO we should:

define which common subset of C types we support (e.g. list the C type names) - probably the one we use now is a good set;
Give an example, on x64, of how these types might be realized using layouts (e.g. current table)

More pulling, the char16_t type is probably not defined on all ABIs (e.g. I can't find it here [1]). Which seems to suggest that perhaps canonical layout should just return mapping from string to lists of layouts, even if inconvenient?

[1] - https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#arm-c-and-c-language-mappings

PaulSandoz · 2023-05-18T19:31:02Z

I agree focusing on a subset of C types is the way to go. That avoids the unnecessary verbosity of many tables, and we can enumerate the types differing by data model (e.g., LP64 and ILP32).

As a developer i would like to know for all C-based native linkers (which is all native linkers? what else would they be based on?) if:

the C int type etc is supported; and
whether i can use the JAVA_INT layout in my function descriptors, and know it corresponds to a C int.

It seems obvious that i should be able to but AFAICT the specification is more example based, so it's not clear to me if different Java implementations can deviate in such behaviour.

Requiring the use of the C type names in the canonical mapping does help, because then i can more directly ask the C-based linker "Hey what's your canonical layout for the C char type?" .

I don't see char16_t defined either and i believe that type is an alias for uint_least16_t, which is a type of at least 16 bits. We need to use a C type of unsigned short or uint16_t:

Java ValueLayout.JAVA_SHORT <-> C short
Java ValueLayout.JAVA_CHAR <-> C unsigned short

?

For canonical type names we may want to prefer types specified by the C language over those defined by the C library in standard headers?

mcimadamore · 2023-05-18T20:31:19Z

I don't see char16_t defined either and i believe that type is an alias for uint_least16_t, which is a type of at least 16 bits. We need to use a C type of unsigned short or uint16_t:
* Java `ValueLayout.JAVA_SHORT` <-> C `short`

* Java `ValueLayout.JAVA_CHAR` <-> C `unsigned short`
?
Good point on "unsigned short".

For canonical type names we may want to prefer types specified by the C language over those defined by the C library in standard headers?

Yes, I think better to stick with standard C types - IMHO with the exception of size_t which is very ubiquitous.

mcimadamore · 2023-05-19T11:02:53Z

I've addressed the comments and tweaked the javadoc. Now we list all the C types that a linker is guaranteed to support (and state that the canonical layout associated with those types can vary depending on data model). Then we roll in the usual/more concrete table for Linux/x64.

mcimadamore · 2023-05-19T11:06:13Z

Updated javadoc and specdiffs:
javadoc: https://cr.openjdk.org/~mcimadamore/jdk/8308293/v2/javadoc/java.base/java/lang/foreign/Linker.html
specdiff: https://cr.openjdk.org/~mcimadamore/jdk/8308293/v2/specdiff_out/overview-summary.html

PaulSandoz · 2023-05-19T22:20:32Z

src/java.base/share/classes/java/lang/foreign/Linker.java

 * via the generation of {@linkplain #upcallStub(MethodHandle, FunctionDescriptor, Arena, Option...) upcall stubs}.</li>
 * </ul>
+ * A linker provides a way to lookup up the <em>canonical layouts</em> associated with the data types used by the ABI.
+ * For example, the canonical layout for the C {@code size_t} type is equal to {@link ValueLayout#JAVA_LONG}. The canonical


Suggested change

* For example, the canonical layout for the C {@code size_t} type is equal to {@link ValueLayout#JAVA_LONG}. The canonical

* For example, the canonical layout for the C {@code size_t} type is equal to {@link ValueLayout#JAVA_LONG} on 64-bit platforms. The canonical

?

You are correct in calling this out. I think this should be spelled out more (similarly to what we do for default lookup) since we're still in the "general" linker section. E.g.

A linker provides a way to lookup up the <em>canonical layouts</em> associated with the data types used by the ABI. For example, a linker implementing the C ABI might chose to provide a canonical layout for the C {@code size_t} type. On 64-bit platforms, this canonical layout might be equal to {@link ValueLayout#JAVA_LONG}. The canonical layouts supported by a linker are exposed via the {@link #canonicalLayouts()} method, which returns a map from ABI type names to canonical layouts.

PaulSandoz

This look much better. Can we strengthen the specification of canonicalLayouts in accordance with the class specification

mcimadamore · 2023-05-19T22:57:39Z

This look much better. Can we strengthen the specification of canonicalLayouts in accordance with the class specification

We can't do more in that method javadoc, think, as that has to be general enough for all linkers. I think the rules set up in that method javadoc are good - e.g. the set of layouts should be stable (both in terms of names and layout types).

What we can do is to sprinkle some wording in the nativeLinker factory - e.g. the native linker is guaranteed to provide canonical layouts for basic C types <link to the class section>.

PaulSandoz · 2023-05-19T23:08:00Z

This look much better. Can we strengthen the specification of canonicalLayouts in accordance with the class specification

We can't do more in that method javadoc, think, as that has to be general enough for all linkers. I think the rules set up in that method javadoc are good - e.g. the set of layouts should be stable (both in terms of names and layout types).

What we can do is to sprinkle some wording in the nativeLinker factory - e.g. the native linker is guaranteed to provide canonical layouts for basic C types <link to the class section>.

Yes, that's better.

minborg · 2023-05-22T06:45:19Z

src/java.base/share/classes/java/lang/foreign/Linker.java

    SymbolLookup defaultLookup();

+    /**
+     * {@return a mapping between the names of data types used by the ABI implemented by this linker and their


I think we should state we return "an unmodifiable mapping".

minborg

LGTM. Are there any additional types we might consider apart from the basic ones and size_t? Maybe one for an address pointing at errno?

mcimadamore · 2023-05-22T17:03:21Z

LGTM. Are there any additional types we might consider apart from the basic ones and size_t? Maybe one for an address pointing at errno?

I think there is a certain gravitational pull towards keeping the set of guaranteed canonical layouts as minimal as possible. In that sense pointer to errno seems not to meet the bar IMHO. (also note that one could always ask the captureStateLayout, and figure out how to express the errno type from there).

mcimadamore · 2023-05-22T22:24:02Z

@PaulSandoz after thinking some more, it seems a bit ad-hoc to guarantee a canonical for "unsigned short", but not for other unsigned types? Possible alternatives (beside keeping what we have in this PR):

guarantee also all the other unsigned types (e.g. char, int, long and long long)
do not guarantee unsigned short - but provide a mapping for it anyways
do not guarantee unsigned short, and do not provide a mapping for it - this means that JAVA_CHAR will not be usable when linking

What do you think?

PaulSandoz · 2023-05-23T19:44:12Z

On further reflection i think mapping C unsigned short only to Java char is a misleading. Although Java char is an integral type is not really intended to be used generally as an unsigned 16-bit integer, so arguably Java char is not as useful a carrier type for native interoperation as Java short might be even though it is signed.
Thus i am inclined to remove that mapping.

What if we say something to the effect of:

unless explicitly declared in the canonical layouts C's unsigned integral types are mapped to the layouts associated with the required C's signed integral types of the same bit sizes.

?

Arguably C unsigned short could map to carriers Java short or Java char, but i am inclined to say the user should cast between Java short to char in such cases.

FWIW i checked what the FFM API and jextract does today and it maps unsigned C types to signed Java types.

mcimadamore · 2023-05-23T20:32:10Z

On further reflection i think mapping C unsigned short only to Java char is a misleading. Although Java char is an integral type is not really intended to be used generally as an unsigned 16-bit integer, so arguably Java char is not as useful a carrier type for native interoperation as Java short might be even though it is signed. Thus i am inclined to remove that mapping.

What if we say something to the effect of:

unless explicitly declared in the canonical layouts C's unsigned integral types are mapped to the layouts associated with the required C's signed integral types of the same bit sizes.

?

Arguably C unsigned short could map to carriers Java short or Java char, but i am inclined to say the user should cast between Java short to char in such cases.

FWIW i checked what the FFM API and jextract does today and it maps unsigned C types to signed Java types.

I tend to agree with your conclusion. And I confirm that we do not use "char" anywhere in jextract. The only "problem" with that approach is that if we go down that path, JAVA_CHAR is no longer a canonical type, so users cannot mention it in function descriptors. Apart from requiring few test updates, I don't see many other problems with it - if one really really wanted the result of a native call to be converted to char, a MH adapter can be used. Effectively, what you suggest amount at saying: we do have a JAVA_CHAR layout, which is mostly there for Java interop. But a native linker (which only cares about native interop) doesn't really care much about that. Does that sound good?

mcimadamore · 2023-05-23T21:01:19Z

Arguably C unsigned short could map to carriers Java short or Java char, but i am inclined to say the user should cast between Java short to char in such cases.

(Another advantage of this is that, should we get proper unsigned carriers from Valhalla one day, native linkers could be updated to support those en masse - not just for short)

PaulSandoz · 2023-05-23T23:08:51Z

Effectively, what you suggest amount at saying: we do have a JAVA_CHAR layout, which is mostly there for Java interop. But a native linker (which only cares about native interop) doesn't really care much about that. Does that sound good?

Yes.

Beef up javadoc

openjdk · 2023-05-24T09:14:51Z

@mcimadamore this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout linker_types
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

mcimadamore · 2023-05-24T09:17:19Z

Updated javadoc and specdiffs (v3):
javadoc: https://cr.openjdk.org/~mcimadamore/jdk/8308293/v3/javadoc/java.base/java/lang/foreign/Linker.html
specdiff: https://cr.openjdk.org/~mcimadamore/jdk/8308293/v3/specdiff_out/overview-summary.html

ExE-Boss · 2023-05-24T21:25:59Z

test/jdk/java/foreign/normalize/TestNormalize.java

            { JAVA_BYTE,    byteToInt((byte) 42),   BYTE_HOB_MASK,    BYTE_TO_INT,    SAVE_BYTE_AS_INT    },
-            { JAVA_SHORT,   shortToInt((short) 42), SHORT_HOB_MASK,   SHORT_TO_INT,   SAVE_SHORT_AS_INT   },
-            { JAVA_CHAR,    charToInt('a'),         CHAR_HOB_MASK,    CHAR_TO_INT,    SAVE_CHAR_AS_INT    }
+            { JAVA_SHORT,   shortToInt((short) 42), SHORT_HOB_MASK,   SHORT_TO_INT,   SAVE_SHORT_AS_INT   }


Since arrays support trailing commas, this can use that:

Suggested change

{ JAVA_SHORT, shortToInt((short) 42), SHORT_HOB_MASK, SHORT_TO_INT, SAVE_SHORT_AS_INT }

{ JAVA_SHORT, shortToInt((short) 42), SHORT_HOB_MASK, SHORT_TO_INT, SAVE_SHORT_AS_INT },

PaulSandoz

This all looks reasonable. I say let's soak it and then see if we need refine based on feedback and further research (e.g., if we find we need to declare multiple layouts per ABI type for extensibility reasons).

mcimadamore · 2023-05-26T16:30:33Z

Thanks for taking the time to review. After some more consideration, I will withdraw this PR. While this API is largely not problematic, we need to make sure that this API fits with how the FFM API will be evolved to support other types besides the C basic types we know and love (e.g. long double, vectors, complex types). So adding this API point now seems premature.

I will bring over relevant javadoc improvements in the other javadoc PR I have open: https://git.openjdk.org/jdk/pull/14098

mcimadamore added 2 commits May 17, 2023 16:15

Initial push

9e337e0

Tweak javadoc

ee89cdf

Add char type

openjdk bot added the core-libs core-libs-dev@openjdk.org label May 17, 2023

mcimadamore commented May 17, 2023

View reviewed changes

mcimadamore marked this pull request as ready for review May 17, 2023 17:47

openjdk bot added csr Pull request needs approved CSR before integration rfr Pull request is ready for review labels May 17, 2023

Tweak javadoc

955241f

mcimadamore force-pushed the linker_types branch from a6e0abd to 955241f Compare May 17, 2023 18:12

PaulSandoz reviewed May 17, 2023

View reviewed changes

More javadoc tweaks

a07ee13

Address review comments

df92467

PaulSandoz reviewed May 19, 2023

View reviewed changes

minborg reviewed May 22, 2023

View reviewed changes

Address further review comments

dbc8049

minborg approved these changes May 22, 2023

View reviewed changes

Drop "unsigned short"

708f987

Beef up javadoc

openjdk bot added the merge-conflict Pull request has merge conflict with target branch label May 24, 2023

Merge branch 'master' into linker_types

b00239b

openjdk bot removed the merge-conflict Pull request has merge conflict with target branch label May 24, 2023

ExE-Boss reviewed May 24, 2023

View reviewed changes

PaulSandoz approved these changes May 25, 2023

View reviewed changes

mcimadamore closed this May 26, 2023

mcimadamore mentioned this pull request May 26, 2023

8308645: Javadoc of FFM API needs to be refreshed #14098

Closed

3 tasks

mcimadamore mentioned this pull request Jun 15, 2023

8308293: A linker should expose the layouts it supports openjdk/panama-foreign#839

Closed

2 tasks

	* For example, the canonical layout for the C {@code size_t} type is equal to {@link ValueLayout#JAVA_LONG}. The canonical
	* For example, the canonical layout for the C {@code size_t} type is equal to {@link ValueLayout#JAVA_LONG} on 64-bit platforms. The canonical

	{ JAVA_SHORT, shortToInt((short) 42), SHORT_HOB_MASK, SHORT_TO_INT, SAVE_SHORT_AS_INT }
	{ JAVA_SHORT, shortToInt((short) 42), SHORT_HOB_MASK, SHORT_TO_INT, SAVE_SHORT_AS_INT },

Conversation

mcimadamore commented May 17, 2023 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issues

Reviewers

Reviewing

Webrev

Uh oh!

bridgekeeper bot commented May 17, 2023

Uh oh!

openjdk bot commented May 17, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mcimadamore commented May 17, 2023

Uh oh!

mlbridge bot commented May 17, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

openjdk bot commented May 17, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PaulSandoz left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mcimadamore commented May 17, 2023

Uh oh!

PaulSandoz commented May 18, 2023

Uh oh!

mcimadamore commented May 18, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

PaulSandoz commented May 18, 2023

Uh oh!

mcimadamore commented May 18, 2023

Uh oh!

mcimadamore commented May 19, 2023

Uh oh!

mcimadamore commented May 19, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PaulSandoz left a comment

Choose a reason for hiding this comment

Uh oh!

mcimadamore commented May 19, 2023

Uh oh!

PaulSandoz commented May 19, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

minborg left a comment

Choose a reason for hiding this comment

Uh oh!

mcimadamore commented May 22, 2023

Uh oh!

mcimadamore commented May 22, 2023

Uh oh!

PaulSandoz commented May 23, 2023

Uh oh!

mcimadamore commented May 23, 2023

Uh oh!

mcimadamore commented May 23, 2023

Uh oh!

PaulSandoz commented May 23, 2023

Uh oh!

openjdk bot commented May 24, 2023

Uh oh!

mcimadamore commented May 17, 2023 •

edited by openjdk bot

Loading

mlbridge bot commented May 17, 2023 •

edited

Loading

PaulSandoz left a comment •

edited

Loading

mcimadamore commented May 18, 2023 •

edited

Loading

mcimadamore commented May 26, 2023 •

edited

Loading