From markus.gronlund at oracle.com  Mon May 12 16:21:05 2025
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Mon, 12 May 2025 16:21:05 +0000
Subject: JEP : Cooperative JFR Sampling (porting work)
In-Reply-To: <IA1PR10MB5971F24110E444E4CB11FC0699BA2@IA1PR10MB5971.namprd10.prod.outlook.com>
References: <IA1PR10MB5971F24110E444E4CB11FC0699BA2@IA1PR10MB5971.namprd10.prod.outlook.com>
Message-ID: <IA1PR10MB59717439BC0D8D2BF61A636B9997A@IA1PR10MB5971.namprd10.prod.outlook.com>

Friendly reminder since the JEP has moved to Candidate.

Thanks
Markus

-----Original Message-----
From: porters-dev <porters-dev-retn at openjdk.org> On Behalf Of Markus Gronlund
Sent: Thursday, 24 April 2025 00:53
To: porters-dev <porters-dev at openjdk.org>
Subject: JEP : Cooperative JFR Sampling (porting work)

Greetings,

I am sending this to the porters-dev list as a heads-up for changes involved in JEP Cooperative JFR Sampling [1], which will affect ports if you support the JDK Flight Recorder (JFR) system.

The TemplateInterpreter will need a few changes; please see the files listed in the PR [2].

Technically, the InterpreterMacroAssembler::remove_activation() function will change to pre-emptively move the frame pointer (fp) to the sender frame before issuing a safepoint poll.

No stubs will be provided because the overall changes are extensive and completely change how the JFR system works regarding sampling.

Please feel free to send me patches, and I will incorporate them into the overall PR, or you can wait for a potential integration.

I appreciate your cooperation.
Markus

[1] https://openjdk.org/jeps/8350338
[2] https://github.com/openjdk/jdk/pull/24296

From markus.gronlund at oracle.com  Mon May 19 15:33:36 2025
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Mon, 19 May 2025 15:33:36 +0000
Subject: JEP : Cooperative JFR Sampling (porting work)
In-Reply-To: <IA1PR10MB59717439BC0D8D2BF61A636B9997A@IA1PR10MB5971.namprd10.prod.outlook.com>
References: <IA1PR10MB5971F24110E444E4CB11FC0699BA2@IA1PR10MB5971.namprd10.prod.outlook.com>
 <IA1PR10MB59717439BC0D8D2BF61A636B9997A@IA1PR10MB5971.namprd10.prod.outlook.com>
Message-ID: <IA1PR10MB59718CC31FF78D556A023C46999CA@IA1PR10MB5971.namprd10.prod.outlook.com>

Greetings again,

A more straightforward implementation has been pushed for JEP Cooperative JFR Sampling [1].

The ambition and the hopes are that the porting work involved will be much more straightforward.

In summary, the original design, premised on a?preemptive move of the FP register in the interpreter, has been abandoned due to the?complexities involved in its?implementation for all platforms.

A more straightforward solution, which should involve significantly less porting work, has therefore been pushed to the PR [2].

Please take a look.

Thanks
Markus

[1] https://openjdk.org/jeps/8350338
[2] https://github.com/openjdk/jdk/pull/24296


-----Original Message-----
From: Markus Gronlund 
Sent: Monday, 12 May 2025 18:21
To: porters-dev <porters-dev at openjdk.org>
Cc: Markus Gronlund <markus.gronlund at oracle.com>
Subject: RE: JEP : Cooperative JFR Sampling (porting work)

Friendly reminder since the JEP has moved to Candidate.

Thanks
Markus

-----Original Message-----
From: porters-dev <porters-dev-retn at openjdk.org> On Behalf Of Markus Gronlund
Sent: Thursday, 24 April 2025 00:53
To: porters-dev <porters-dev at openjdk.org>
Subject: JEP : Cooperative JFR Sampling (porting work)

Greetings,

I am sending this to the porters-dev list as a heads-up for changes involved in JEP Cooperative JFR Sampling [1], which will affect ports if you support the JDK Flight Recorder (JFR) system.

The TemplateInterpreter will need a few changes; please see the files listed in the PR [2].

Technically, the InterpreterMacroAssembler::remove_activation() function will change to pre-emptively move the frame pointer (fp) to the sender frame before issuing a safepoint poll.

No stubs will be provided because the overall changes are extensive and completely change how the JFR system works regarding sampling.

Please feel free to send me patches, and I will incorporate them into the overall PR, or you can wait for a potential integration.

I appreciate your cooperation.
Markus

[1] https://openjdk.org/jeps/8350338
[2] https://github.com/openjdk/jdk/pull/24296

From Markus.Duft at ssi-schaefer.com  Mon May 26 05:18:49 2025
From: Markus.Duft at ssi-schaefer.com (Duft Markus)
Date: Mon, 26 May 2025 05:18:49 +0000
Subject: Aarch64 and Cortex A53 - broken since 21.0.7
Message-ID: <DU2PR01MB8813C5A08BB256F3E1EED73EC265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>

Good Morning,

As documented in much detail in the following ticket, 21.0.7 broke Aarch64 support on the Cortex A53 CPU.

https://github.com/adoptium/adoptium-support/issues/1295

There is a reproducer in the Ticket, basically the steps are:


  *
Setup Ubuntu cloud image on qemu-system-aarch64, and use a Cortex A53 CPU
  *
Download and use Java 21.0.7+6 - I tried Temurin, Microsoft and Azul. All misbehave.
  *
"Using" means e.g. running ./gradlew tasks on any freshly downloaded repo, e.g. the gradle sample repo.
  *
... or running any more complex java program, which immediately exhibits strange behavior like these:
     *
java.security.ProviderException: Cannot find aliases for HmacSHA512
        *
Note: It is not a specific algorithm which is not found, it just randomly fails on very different ones.
     *
java.lang.IllegalArgumentException: java.lang.ClassFormatError: Duplicate method name "toString" with signature "()Ljava.lang.String;" in class file jdk/proxy2/$Proxy3
     *
Exception in thread "main" java.lang.annotation.IncompleteAnnotationException: java.lang.annotation.Retention missing element value
     *
... and even more ...
        *
Another note: of course the very same binaries run without any issue on other CPUs, like the A57 for instance.

I first thought that this is an issue with my actual A53 hardware I have here. However since this behavior is the same also on an emulated A53 in QEMU: here I am reporting ?

Versions before 21.0.7(+?) do not expose these problems. I can run any program just fine on 21.0.6+7 and older.

The GitHub issue has a lot of information already present, but I can provide more on demand - both from an emulator as well as the real hardware.

Any help would be greatly appreciated - even if it is a statement that A53 is no longer supported (which would be a bummer, we have a lot of hardware with those CPUs).

Best, Markus

SSI Sch?fer Software Development GmbH | Friesachstra?e 15 | 8114 Friesach | Austria
Registered Office: Friesach | Commercial Register: 617462h | VAT no. ATU80145424
Commercial Court: Landesgericht f?r Zivilrechtssachen Graz
Managing Directors: Manfred Muckenhumer, Barbara Schlosser

Unsere Hinweise zum Umgang mit personenbezogenen Daten finden Sie hier<https://www.ssi-schaefer.com/de-at/datenschutz>.
You can find our information on the handling of personal data here<https://www.ssi-schaefer.com/en-de/privacy>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/porters-dev/attachments/20250526/6999854c/attachment-0001.htm>

From aph-open at littlepinkcloud.com  Mon May 26 08:25:30 2025
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Mon, 26 May 2025 09:25:30 +0100
Subject: Aarch64 and Cortex A53 - broken since 21.0.7
In-Reply-To: <DU2PR01MB8813C5A08BB256F3E1EED73EC265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>
References: <DU2PR01MB8813C5A08BB256F3E1EED73EC265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>
Message-ID: <7a641642-d9e0-4c43-ac02-22e8a9c3d4d9@littlepinkcloud.com>

On 5/26/25 06:18, Duft Markus wrote:
> Good Morning,
> 
> As documented in much detail in the following ticket, 21.0.7 broke Aarch64 support on the Cortex A53 CPU.
> 
> https://github.com/adoptium/adoptium-support/issues/1295
> 
> There is a reproducer in the Ticket, basically the steps are:

If this is `8353237: [AArch64] Incorrect result of VectorizedHashCode 
intrinsic on Cortex-A53`, it's fixed in JDK head. Download it 
[here](https://adoptium.net/en-GB/temurin/nightly/?version=25)

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From Markus.Duft at ssi-schaefer.com  Mon May 26 09:18:35 2025
From: Markus.Duft at ssi-schaefer.com (Duft Markus)
Date: Mon, 26 May 2025 09:18:35 +0000
Subject: Aarch64 and Cortex A53 - broken since 21.0.7
In-Reply-To: <7a641642-d9e0-4c43-ac02-22e8a9c3d4d9@littlepinkcloud.com>
References: <DU2PR01MB8813C5A08BB256F3E1EED73EC265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>
 <7a641642-d9e0-4c43-ac02-22e8a9c3d4d9@littlepinkcloud.com>
Message-ID: <DU2PR01MB88130BED1D741CD5194D4B8AC265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>

Hey,

Thanks for the quick answer. Unfortunately, I'm getting the very same behavior with 25+23 (which is the linked build). So I assume it might be something else not yet fixed. I would have loved to be able to build the aarch64 JDK locally, however that seems to be virtually impossible for me (I do have some experience, but I fail to figure out the build of the binutils in the devkit makefiles...

There are only 3 potential aarch64 hotspot commits I would like to look into, however only one of them seems really impactful enough..:


  *
990859cc327: [REDO] Implement C2 VectorizedHashCode on AArch64
  *
21b76f3f07a: AArch64: VM crashes with SIGILL when prctl is disallowed

The first one being the more dramatic one IMHO ? It is super hard to pinpoint my fingers on something, because the behavior is so erratic that not even the problems stay the same from run to run. One of my applications even gets a NoClassDefFound on the main class, as it seems it fails to evaluate the classpath properly (or find classes in jars, ...). If I rearrange the classpath it finds the class and fails differently.

Open for any ideas and/or advice and also willing to try out some - BUT my actual A53 is a real anti-beast. There is no way I could build something directly on that board - it is simply too weak.

Best, Markus



________________________________
From: porters-dev <porters-dev-retn at openjdk.org> on behalf of Andrew Haley <aph-open at littlepinkcloud.com>
Sent: Monday, 26 May 2025 10:25
To: porters-dev at openjdk.org <porters-dev at openjdk.org>
Subject: Re: Aarch64 and Cortex A53 - broken since 21.0.7

On 5/26/25 06:18, Duft Markus wrote:
> Good Morning,
>
> As documented in much detail in the following ticket, 21.0.7 broke Aarch64 support on the Cortex A53 CPU.
>
> https://github.com/adoptium/adoptium-support/issues/1295
>
> There is a reproducer in the Ticket, basically the steps are:

If this is `8353237: [AArch64] Incorrect result of VectorizedHashCode
intrinsic on Cortex-A53`, it's fixed in JDK head. Download it
[here](https://adoptium.net/en-GB/temurin/nightly/?version=25)

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://eu01.z.antigena.com/l/0sXdfbZmwaKD_wl11rlRJ40KC4NgfkkdkTFF4Bu04M4B6D0grJ1SK_SuD0iXihVB6JGwXPxxREE~dRxdvw3dZ4b6QPaq8NAOa-g9_sUPxtVLNeqGTtQNAR-XOdFL~Rnj5WYLlEPf9K_QVLORNLLti1JCI6CUvDQCK_GF0dr4N~c33-VSMQ~iC9SgC7ba
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


SSI Sch?fer Software Development GmbH | Friesachstra?e 15 | 8114 Friesach | Austria
Registered Office: Friesach | Commercial Register: 617462h | VAT no. ATU80145424
Commercial Court: Landesgericht f?r Zivilrechtssachen Graz
Managing Directors: Manfred Muckenhumer, Barbara Schlosser

Unsere Hinweise zum Umgang mit personenbezogenen Daten finden Sie hier<https://www.ssi-schaefer.com/de-at/datenschutz>.
You can find our information on the handling of personal data here<https://www.ssi-schaefer.com/en-de/privacy>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/porters-dev/attachments/20250526/2a473f1e/attachment-0001.htm>

From aph-open at littlepinkcloud.com  Mon May 26 10:05:06 2025
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Mon, 26 May 2025 11:05:06 +0100
Subject: Aarch64 and Cortex A53 - broken since 21.0.7
In-Reply-To: <DU2PR01MB88130BED1D741CD5194D4B8AC265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>
References: <DU2PR01MB8813C5A08BB256F3E1EED73EC265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>
 <7a641642-d9e0-4c43-ac02-22e8a9c3d4d9@littlepinkcloud.com>
 <DU2PR01MB88130BED1D741CD5194D4B8AC265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>
Message-ID: <e688b228-8ca2-4899-8a7b-99de42a5d59b@littlepinkcloud.com>

On 5/26/25 10:18, Duft Markus wrote:
> Thanks for the quick answer. Unfortunately, I'm getting the very same behavior with 25+23 (which is the linked build).

Your fault is exactly the same symptoms as 8353237. I cannot find the
source tarball for the build you mention, so I can't tell if that bug is
fixed.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From shipilev at amazon.de  Mon May 26 10:11:52 2025
From: shipilev at amazon.de (Aleksey Shipilev)
Date: Mon, 26 May 2025 12:11:52 +0200
Subject: Aarch64 and Cortex A53 - broken since 21.0.7
In-Reply-To: <DU2PR01MB88130BED1D741CD5194D4B8AC265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>
References: <DU2PR01MB8813C5A08BB256F3E1EED73EC265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>
 <7a641642-d9e0-4c43-ac02-22e8a9c3d4d9@littlepinkcloud.com>
 <DU2PR01MB88130BED1D741CD5194D4B8AC265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>
Message-ID: <f59a57b1-a9bc-443e-a964-73a439926fc6@amazon.de>


On 26.05.25 11:18, Duft Markus wrote:
> Thanks for the quick answer. Unfortunately, I'm getting the very same behavior with 25+23 (which is 
> the linked build). So I assume it might be something else not yet fixed. 

https://bugs.openjdk.org/browse/JDK-8353237 says:
   Fix Versions: 25
   Resolved in build: b24

So... jdk-25+24 is supposed to have a fix. jdk-25+23 is the build before it, and it likely does not 
contain it.

Take a build from here:
   https://builds.shipilev.net/openjdk-jdk/

It has the bom-changesets file, which lists exactly what's in the build.

-Aleksey



Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597

From Markus.Duft at ssi-schaefer.com  Mon May 26 10:39:34 2025
From: Markus.Duft at ssi-schaefer.com (Duft Markus)
Date: Mon, 26 May 2025 10:39:34 +0000
Subject: Aarch64 and Cortex A53 - broken since 21.0.7
In-Reply-To: <f59a57b1-a9bc-443e-a964-73a439926fc6@amazon.de>
References: <DU2PR01MB8813C5A08BB256F3E1EED73EC265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>
 <7a641642-d9e0-4c43-ac02-22e8a9c3d4d9@littlepinkcloud.com>
 <DU2PR01MB88130BED1D741CD5194D4B8AC265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>
 <f59a57b1-a9bc-443e-a964-73a439926fc6@amazon.de>
Message-ID: <DU2PR01MB88139F07E52614B61D142123C265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>

Yay, that one works way better ? All my tests are successful with that build. Now I'd need that in 21 LTS xD

But that indeed gives hopes that things will be fixed soon.

Thanks!

Best, Markus
________________________________
From: Aleksey Shipilev <shipilev at amazon.de>
Sent: Monday, 26 May 2025 12:11
To: Duft Markus <Markus.Duft at ssi-schaefer.com>; Andrew Haley <aph-open at littlepinkcloud.com>; porters-dev at openjdk.org <porters-dev at openjdk.org>
Subject: Re: Aarch64 and Cortex A53 - broken since 21.0.7


On 26.05.25 11:18, Duft Markus wrote:
> Thanks for the quick answer. Unfortunately, I'm getting the very same behavior with 25+23 (which is
> the linked build). So I assume it might be something else not yet fixed.

https://bugs.openjdk.org/browse/JDK-8353237 says:
   Fix Versions: 25
   Resolved in build: b24

So... jdk-25+24 is supposed to have a fix. jdk-25+23 is the build before it, and it likely does not
contain it.

Take a build from here:
   https://eu01.z.antigena.com/l/CGXC7qBQxyy58f~FleJPG~~XoqruOmN03IxUSpGTTk6aWvJc-0mi-~m6Npvj--m5MSCSp-0UccicYUiAkLyAQRjySWU4QECUfspRCwYcNbymRQJDnwZPBc-NH-ubOZayL7~vOYzE4AyiAPxZ3Mwu~Y4NMduVcxtVp_rSZzOISB0niAWTvHPEchApavAQm0toyy

It has the bom-changesets file, which lists exactly what's in the build.

-Aleksey



Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597

SSI Sch?fer Software Development GmbH | Friesachstra?e 15 | 8114 Friesach | Austria
Registered Office: Friesach | Commercial Register: 617462h | VAT no. ATU80145424
Commercial Court: Landesgericht f?r Zivilrechtssachen Graz
Managing Directors: Manfred Muckenhumer, Barbara Schlosser

Unsere Hinweise zum Umgang mit personenbezogenen Daten finden Sie hier<https://www.ssi-schaefer.com/de-at/datenschutz>.
You can find our information on the handling of personal data here<https://www.ssi-schaefer.com/en-de/privacy>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/porters-dev/attachments/20250526/2f82fdc3/attachment-0001.htm>

From shipilev at amazon.de  Mon May 26 11:15:33 2025
From: shipilev at amazon.de (Aleksey Shipilev)
Date: Mon, 26 May 2025 13:15:33 +0200
Subject: Aarch64 and Cortex A53 - broken since 21.0.7
In-Reply-To: <DU2PR01MB88139F07E52614B61D142123C265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>
References: <DU2PR01MB8813C5A08BB256F3E1EED73EC265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>
 <7a641642-d9e0-4c43-ac02-22e8a9c3d4d9@littlepinkcloud.com>
 <DU2PR01MB88130BED1D741CD5194D4B8AC265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>
 <f59a57b1-a9bc-443e-a964-73a439926fc6@amazon.de>
 <DU2PR01MB88139F07E52614B61D142123C265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>
Message-ID: <17ee769c-d3da-4ea1-8333-36a5f12fdc95@amazon.de>

On 26.05.25 12:39, Duft Markus wrote:
> Yay, that one works way better ? All my tests are successful with that build.

Nice!

> Now I'd need that in 21 LTS xD. But that indeed gives hopes that things will be fixed soon.

21.0.8 (July 2025) rampdown starts tomorrow. I'll take this backport to jdk21u-dev now. Hopefully 
maintainers would agree to accept it -- it is tenuous, because the fix is very young.

-Aleksey



Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597

From Markus.Duft at ssi-schaefer.com  Mon May 26 12:28:41 2025
From: Markus.Duft at ssi-schaefer.com (Duft Markus)
Date: Mon, 26 May 2025 12:28:41 +0000
Subject: Aarch64 and Cortex A53 - broken since 21.0.7
In-Reply-To: <17ee769c-d3da-4ea1-8333-36a5f12fdc95@amazon.de>
References: <DU2PR01MB8813C5A08BB256F3E1EED73EC265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>
 <7a641642-d9e0-4c43-ac02-22e8a9c3d4d9@littlepinkcloud.com>
 <DU2PR01MB88130BED1D741CD5194D4B8AC265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>
 <f59a57b1-a9bc-443e-a964-73a439926fc6@amazon.de>
 <DU2PR01MB88139F07E52614B61D142123C265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>
 <17ee769c-d3da-4ea1-8333-36a5f12fdc95@amazon.de>
Message-ID: <DU2PR01MB88131D6615BB9487E57138BEC265A@DU2PR01MB8813.eurprd01.prod.exchangelabs.com>

Thanks a ton! Would be not too dramatic for us to wait a month or two. The sooner the better of course ?

Best, Markus
________________________________
From: Aleksey Shipilev <shipilev at amazon.de>
Sent: Monday, 26 May 2025 13:15
To: Duft Markus <Markus.Duft at ssi-schaefer.com>; Andrew Haley <aph-open at littlepinkcloud.com>; porters-dev at openjdk.org <porters-dev at openjdk.org>
Subject: Re: Aarch64 and Cortex A53 - broken since 21.0.7

On 26.05.25 12:39, Duft Markus wrote:
> Yay, that one works way better ? All my tests are successful with that build.

Nice!

> Now I'd need that in 21 LTS xD. But that indeed gives hopes that things will be fixed soon.

21.0.8 (July 2025) rampdown starts tomorrow. I'll take this backport to jdk21u-dev now. Hopefully
maintainers would agree to accept it -- it is tenuous, because the fix is very young.

-Aleksey



Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597

SSI Sch?fer Software Development GmbH | Friesachstra?e 15 | 8114 Friesach | Austria
Registered Office: Friesach | Commercial Register: 617462h | VAT no. ATU80145424
Commercial Court: Landesgericht f?r Zivilrechtssachen Graz
Managing Directors: Manfred Muckenhumer, Barbara Schlosser

Unsere Hinweise zum Umgang mit personenbezogenen Daten finden Sie hier<https://www.ssi-schaefer.com/de-at/datenschutz>.
You can find our information on the handling of personal data here<https://www.ssi-schaefer.com/en-de/privacy>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/porters-dev/attachments/20250526/2333f134/attachment.htm>