From dholmes at openjdk.org  Thu Aug  1 04:40:32 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 1 Aug 2024 04:40:32 GMT
Subject: RFR: 8331553: Windows JVM leaks Event and Thread handles when
 multiple threads are used [v2]
In-Reply-To: <N2RKkavqm9IzRi05GVFwwW3ZSHevqF2EtVFySXkCXCs=.47d02adb-24df-4a8d-98f1-bf46c58c6c9a@github.com>
References: <TEAz_15hgz1K7MwO8O85d8gVGxuGYLZTuIFzUfeScOc=.d1eaaadc-0649-4b23-a732-b82758d8b5e9@github.com>
 <CfFNcsacEMcHEiTd5kQ4hSTYbbb5LPBAfkI7s8QHZe8=.7b7b9c7e-046d-4614-8b90-4116f1e763e5@github.com>
 <odkM3F48GW3gO4IwyK7xHNnOm8idauTRJxm7pIi-gjo=.09de7917-3826-48e4-8830-c0472a396f28@github.com>
 <N2RKkavqm9IzRi05GVFwwW3ZSHevqF2EtVFySXkCXCs=.47d02adb-24df-4a8d-98f1-bf46c58c6c9a@github.com>
Message-ID: <63Qby3z7NSpJPx7fHK9IxuS1gFhX5SBtxSKc9gH6_O0=.91adac6c-6ba5-4099-b9d8-9b1122aa4fad@github.com>

On Tue, 30 Jul 2024 08:36:25 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> WaitOnAddress is reported to spin before yielding. It might be related.
>
> @djelinski @dholmes-ora Couldn't it be that the producer thread is already scheduled, so it can reacquire the monitor whereas if the consumer was parked then the wake-up "lag" means that statistically it will lose?

@viktorklang-ora the question is why the two APIs seems to be behaving so differently. I would expect `WaitForSingleObject` and `WaitOnAddress` to be very similar internally - though speculation on my part.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19778#issuecomment-2262013623

From abhiscxk at openjdk.org  Thu Aug  1 06:09:31 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 1 Aug 2024 06:09:31 GMT
Subject: RFR: 8329471: Remove GTK2 [v5]
In-Reply-To: <EUtvj17LIouoxAgU-mx7MGfotJwsjJouWFk1jJzY6FI=.aaeb2d6f-a9a7-48a7-9ba2-4e87e4d167de@github.com>
References: <JABMEI4R7RPqCP6MjBvzP-0c3Mb-siUcFJQEQ1aFUJo=.96b6712e-10b3-490b-a57f-c57a130710c8@github.com>
 <EUtvj17LIouoxAgU-mx7MGfotJwsjJouWFk1jJzY6FI=.aaeb2d6f-a9a7-48a7-9ba2-4e87e4d167de@github.com>
Message-ID: <nVqnu-kbK1yik4B_OuXhc39HJauTXDxJ2-OJuBYeNts=.7a2c2e1f-2c62-4dab-935c-e065ffd4aa11@github.com>

On Wed, 31 Jul 2024 19:17:05 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> GTK2 support for Swing/AWT was deprecated for removal in JDK 21. 
>> 
>> It's being removed because no platform that supports the JDK needs it.
>> 
>> Manual and automated testing is green.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more removal of is3()

Changes looks good to me.
Hope you have run all the tests with latest changes.

-------------

Marked as reviewed by abhiscxk (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20378#pullrequestreview-2211709762

From vklang at openjdk.org  Thu Aug  1 09:14:43 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 1 Aug 2024 09:14:43 GMT
Subject: RFR: 8331553: Windows JVM leaks Event and Thread handles when
 multiple threads are used [v2]
In-Reply-To: <63Qby3z7NSpJPx7fHK9IxuS1gFhX5SBtxSKc9gH6_O0=.91adac6c-6ba5-4099-b9d8-9b1122aa4fad@github.com>
References: <TEAz_15hgz1K7MwO8O85d8gVGxuGYLZTuIFzUfeScOc=.d1eaaadc-0649-4b23-a732-b82758d8b5e9@github.com>
 <CfFNcsacEMcHEiTd5kQ4hSTYbbb5LPBAfkI7s8QHZe8=.7b7b9c7e-046d-4614-8b90-4116f1e763e5@github.com>
 <odkM3F48GW3gO4IwyK7xHNnOm8idauTRJxm7pIi-gjo=.09de7917-3826-48e4-8830-c0472a396f28@github.com>
 <N2RKkavqm9IzRi05GVFwwW3ZSHevqF2EtVFySXkCXCs=.47d02adb-24df-4a8d-98f1-bf46c58c6c9a@github.com>
 <63Qby3z7NSpJPx7fHK9IxuS1gFhX5SBtxSKc9gH6_O0=.91adac6c-6ba5-4099-b9d8-9b1122aa4fad@github.com>
Message-ID: <Ixeey9XVQufxOc37GOSuCYUKkzhG-CJ55shqu_eYpX4=.0e391f58-73ea-42a7-bd55-5b3fa3946cd8@github.com>

On Thu, 1 Aug 2024 04:38:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @djelinski @dholmes-ora Couldn't it be that the producer thread is already scheduled, so it can reacquire the monitor whereas if the consumer was parked then the wake-up "lag" means that statistically it will lose?
>
> @viktorklang-ora the question is why the two APIs seems to be behaving so differently. I would expect `WaitForSingleObject` and `WaitOnAddress` to be very similar internally - though speculation on my part.

@dholmes-ora From the [documentation](https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitonaddress) it would seem like WaitOnAddress behaves differently from WaitForSingleObject.

For instance, the following passage: "WaitOnAddress is more efficient [...] because WaitOnAddress does not interfere with the thread scheduler." <-- this suggests (to me) that it is some form of spin-wait.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19778#issuecomment-2262522827

From duke at openjdk.org  Thu Aug  1 14:07:41 2024
From: duke at openjdk.org (duke)
Date: Thu, 1 Aug 2024 14:07:41 GMT
Subject: RFR: 8334166: Enable binary check
In-Reply-To: <cJqLJOBpzGM4atUu5PJ-vnE81UbDp5wzFadQSQIVSOk=.9d64e855-46e1-4602-98f1-8b3979912f01@github.com>
References: <cJqLJOBpzGM4atUu5PJ-vnE81UbDp5wzFadQSQIVSOk=.9d64e855-46e1-4602-98f1-8b3979912f01@github.com>
Message-ID: <xTZcK-tYc2mRxDGH3VBNuV8pexJbZZK9qG3zmu8-3g0=.9339ba9d-e458-494f-9f1c-07811168cfaf@github.com>

On Wed, 12 Jun 2024 22:38:37 GMT, Zhao Song <zsong at openjdk.org> wrote:

> @kevinrushforth said in [SKARA-2289](https://bugs.openjdk.org/browse/SKARA-2289), 'In general, our repositories contain source code and not binary files. There are exceptions to this for images and other similar resources, but otherwise the policy for most repos is to avoid binary files'. Skara is able to identify binary files when executing jcheck, but this check is not enabled.

@zhaosongzs 
Your change (at version 75ae81f6de251b2e414ca32373b354f1629ec2fb) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19683#issuecomment-2181130691

From lmesnik at openjdk.org  Thu Aug  1 18:30:58 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 1 Aug 2024 18:30:58 GMT
Subject: RFR: 8337410: The makefiles should set problemlist and adjust timeout
 basing on the given VM flags
Message-ID: <HSbKJYVYgMPgkPuXFwzDECWYOcfk5d86zp1gNmS5eJM=.38b1c9c5-558c-4584-a3e3-ac23640f7c5c@github.com>

There jtreg tests have several additional problemlists 
ProblemList-Xcomp.txt
ProblemList-generational-zgc.txt
ProblemList-zgc.txt
Each of them is bound to corresponding execution mode (Xcomp/ZGC) and it makes sense to treat them like standard problemlist when tests are executed with -Xcomp or ZGC enabled.
Currently, it is needed to set them manually and it is often forgotten. So engineers waste time analyzing known failures.

Additionally, the **default** timeoutFactor is increased when Xcomp is enabled because of slowness of this mode. 

The jtreg allows to add the same problemlist twice so it is not needed to update any execution system that set problemlists.

Later it might makes sens to set 'JTREG_ALL_OPTIONS' by asking java about actually set mode. So it is possible to adjust  options for fastdebug/slowdebug/product modes and/or different options that are set during compilation (saying different default GC).

-------------

Commit messages:
 - 8337410: The makefiles should set problemlist and adjust timeout basing on the given VM flags

Changes: https://git.openjdk.org/jdk/pull/20430/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20430&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337410
  Stats: 33 lines in 1 file changed: 30 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20430/head:pull/20430

PR: https://git.openjdk.org/jdk/pull/20430

From duke at openjdk.org  Thu Aug  1 18:47:40 2024
From: duke at openjdk.org (duke)
Date: Thu, 1 Aug 2024 18:47:40 GMT
Subject: Withdrawn: 8315113: Print request Chromaticity.MONOCHROME attribute
 does not work on macOS
In-Reply-To: <m_OJNAf9YmC4OJMwtCM5P-eklmNJUymWJjMfo5s_wpI=.7d1c5a1f-2158-49f2-906d-dc074019cb99@github.com>
References: <m_OJNAf9YmC4OJMwtCM5P-eklmNJUymWJjMfo5s_wpI=.7d1c5a1f-2158-49f2-906d-dc074019cb99@github.com>
Message-ID: <5SzsaX2ycHIiRbaSPvMD9OJXmFV8Wr5R3ViXFc-VgOc=.ecb4ab40-cb56-4a3a-856a-f27d36cd8432@github.com>

On Mon, 11 Mar 2024 13:54:02 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> The fix provides ability to print Black & White pages on macOS.
> 
> Cocoa API has [PMSetColorMode](https://developer.apple.com/documentation/applicationservices/core_printing/1805783-pmsetcolormode) function but it is marked as deprecated and really does nothing.
> 
> There is no replacement; this function was included to facilitate porting legacy applications to macOS, 
> but it serves no useful purpose.
> 
> Dumping `NSPrintInfo` print settings which were set by the native print dialog on macOS shows that the keys and values used for Black & White printing depend on the used printer type.
> For example, the tested 
> `HP Color LaserJet MFP M180n` printer uses `ColorModel` key and`Gray` value, and
> `HP Ink Tank 110 series` uses `HPColorMode` key and `grayscale` value.
> 
> Printing all `NSPrintInfo` presets shows that they do not contain key/value pairs  for Black&White settings.
> This is the code snippet used to print `NSPrintInfo` presets:
> 
>     PMPrinter pr;
>     PMPrintSession printSession = (PMPrintSession)[printInfo PMPrintSession];
>     OSStatus status = PMSessionGetCurrentPrinter(printSession, &pr);
>     CFArrayRef presetsList = nil;
>     status = PMPrinterCopyPresets(pr, &presetsList);
>     CFIndex arrayCount = CFArrayGetCount(presetsList);
> 
>     for (CFIndex index = 0; index < arrayCount; index++) {
>         PMPreset preset = (PMPreset)CFArrayGetValueAtIndex(presetsList, index);
>         CFStringRef presetName = nil;
>         if (PMPresetCopyName(preset, &presetName) == noErr && CFStringGetLength(presetName) > 0) {
>             NSLog(@"  presetName: '%@'", presetName);
>             NSDictionary* dict = nil;
>             if (PMPresetGetAttributes(preset, (CFDictionaryRef*)(&dict)) == noErr) {
>                    // print preset dict
> 
> 
> The idea of the proposed fix is to store printer dependent key/value pairs in the `<jdk-home>/conf/printer.properties` property file.
> 
> The property file has the format:
> 
> print-attribute.print-attribute-value.key=value
> 
> where `print-attribute` is the java print attribute, `print-attribute-value` is the corresponding attribute value, and `key` and `value` is the key/value pair used by a specific printer.
> 
> For example, for `Chromaticity` attribute the property file could look like:
> 
> Chromaticity.MONOCHROME.ColorModel=Gray
> Chromaticity.COLOR.ColorModel=CMYK
> Chromaticity.MONOCHROME.HPColorMode=grayscale
> Chromaticity.COLOR.HPColorMode=color
> 
> where `Chromaticity.MONOCHROME` key prefix corresponds to `Chromaticity.MONOCHOROME` print attribute constant  with  (...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/18195

From prr at openjdk.org  Thu Aug  1 22:36:33 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 1 Aug 2024 22:36:33 GMT
Subject: RFR: 8329471: Remove GTK2 [v5]
In-Reply-To: <EUtvj17LIouoxAgU-mx7MGfotJwsjJouWFk1jJzY6FI=.aaeb2d6f-a9a7-48a7-9ba2-4e87e4d167de@github.com>
References: <JABMEI4R7RPqCP6MjBvzP-0c3Mb-siUcFJQEQ1aFUJo=.96b6712e-10b3-490b-a57f-c57a130710c8@github.com>
 <EUtvj17LIouoxAgU-mx7MGfotJwsjJouWFk1jJzY6FI=.aaeb2d6f-a9a7-48a7-9ba2-4e87e4d167de@github.com>
Message-ID: <oWp2FDsOePYziaLuBh5-bRKKzwd-u-a6zcxYRZamEl0=.cb94bc71-2bfb-47fb-a6a3-2b50bbeabada@github.com>

On Wed, 31 Jul 2024 19:17:05 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> GTK2 support for Swing/AWT was deprecated for removal in JDK 21. 
>> 
>> It's being removed because no platform that supports the JDK needs it.
>> 
>> Manual and automated testing is green.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more removal of is3()

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20378#pullrequestreview-2214142837

From dholmes at openjdk.org  Fri Aug  2 06:49:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 2 Aug 2024 06:49:38 GMT
Subject: RFR: 8331553: Windows JVM leaks Event and Thread handles when
 multiple threads are used [v2]
In-Reply-To: <CfFNcsacEMcHEiTd5kQ4hSTYbbb5LPBAfkI7s8QHZe8=.7b7b9c7e-046d-4614-8b90-4116f1e763e5@github.com>
References: <TEAz_15hgz1K7MwO8O85d8gVGxuGYLZTuIFzUfeScOc=.d1eaaadc-0649-4b23-a732-b82758d8b5e9@github.com>
 <CfFNcsacEMcHEiTd5kQ4hSTYbbb5LPBAfkI7s8QHZe8=.7b7b9c7e-046d-4614-8b90-4116f1e763e5@github.com>
Message-ID: <Hbc7JRnzz8H9weKQFgEQRWdKOatU81o4MoqpYIaENLI=.68ce4388-6eea-4b13-a334-f36f4ed8cc01@github.com>

On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never freed, but they are recycled when a thread dies, so the number of live ParkEvent instances is proportional to the maximum number of threads that were live at any time.
>> 
>> On Windows, the ParkEvent object wraps a kernel Event object. Kernel objects are a limited and costly resource. In this PR, I replace the use of kernel events with user-space synchronization.
>> 
>> The new implementation uses WaitOnAddress and WakeByAddressSingle methods to implement synchronization. The methods are available since Windows 8. We only support Windows 10 and newer, so OS support should not be a problem.
>> 
>> WaitOnAddress was observed to return spuriously, so I added the necessary code to recalculate the timeout and continue waiting.
>> 
>> Tier1-5 tests passed. Performance tests were... inconclusive. For example, `ThreadOnSpinWaitProducerConsumer` reported 30% better results, while `LockUnlock.testContendedLock` results were 50% worse. 
>> 
>> Thoughts?
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comment

I read that as meaning it is more efficient than a polling loop using Sleep because WFA nominally only parks and unparks once.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19778#issuecomment-2264680706

From vklang at openjdk.org  Fri Aug  2 09:13:37 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 2 Aug 2024 09:13:37 GMT
Subject: RFR: 8331553: Windows JVM leaks Event and Thread handles when
 multiple threads are used [v2]
In-Reply-To: <Hbc7JRnzz8H9weKQFgEQRWdKOatU81o4MoqpYIaENLI=.68ce4388-6eea-4b13-a334-f36f4ed8cc01@github.com>
References: <TEAz_15hgz1K7MwO8O85d8gVGxuGYLZTuIFzUfeScOc=.d1eaaadc-0649-4b23-a732-b82758d8b5e9@github.com>
 <CfFNcsacEMcHEiTd5kQ4hSTYbbb5LPBAfkI7s8QHZe8=.7b7b9c7e-046d-4614-8b90-4116f1e763e5@github.com>
 <Hbc7JRnzz8H9weKQFgEQRWdKOatU81o4MoqpYIaENLI=.68ce4388-6eea-4b13-a334-f36f4ed8cc01@github.com>
Message-ID: <oC5yVziXllJteluzMzOwz2Kj50SED_76_pVTW94bvKw=.4a891443-f2ac-412d-a941-aa15bdab70c4@github.com>

On Fri, 2 Aug 2024 06:46:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update comment
>
> I read that as meaning it is more efficient than a polling loop using Sleep because WFA nominally only parks and unparks once.

@dholmes-ora I guess it depends on one's definition of interference. :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19778#issuecomment-2264928814

From Brian.Stafford at microsoft.com  Thu Aug  1 23:54:41 2024
From: Brian.Stafford at microsoft.com (Brian Stafford)
Date: Thu, 1 Aug 2024 23:54:41 +0000
Subject: Add "Windows aarch64" to Supported Build Platforms
Message-ID: <DS7PR21MB3407A10274F0DD81C1C08F6186B22@DS7PR21MB3407.namprd21.prod.outlook.com>

Hello,

We would like to add Microsoft as the maintainer of Windows aarch64 to the Supported Build Platforms[1] page (JDK versions 11/17/21).

Who can help us out with that?

Thanks!
Brian Stafford
Microsoft

[1] https://wiki.openjdk.org/display/Build/Supported+Build+Platforms

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240801/cc009b33/attachment.htm>

From ihse at openjdk.org  Mon Aug  5 12:06:31 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Aug 2024 12:06:31 GMT
Subject: RFR: 8337283: configure.log is truncated when build dir is on
 different filesystem
In-Reply-To: <mYhHd1tr6cUfvEI2_6jviNhB98tyu505gjo83LKLYAI=.56d98b0d-74ff-4749-8065-eacdc07783c2@github.com>
References: <mYhHd1tr6cUfvEI2_6jviNhB98tyu505gjo83LKLYAI=.56d98b0d-74ff-4749-8065-eacdc07783c2@github.com>
Message-ID: <rTi19fsuCsTsr8UnED0STXz1Y260AkmfYlWeac3isFI=.02e47a22-03df-40e4-9419-2bccfffa0346@github.com>

On Fri, 26 Jul 2024 16:21:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I noticed that `build/$confname/configure.log` was truncated on some of my build nodes. Turns out, we are moving configure.log from tree root to that place a bit prematurely.
> 
> We move `configure.log` here:
> https://github.com/openjdk/jdk/blob/4f194f10a1481cdc9df4e6338f6cabd07a34c84c/make/autoconf/basic.m4#L594-L618
> 
> ...and that is called here:
> https://github.com/openjdk/jdk/blob/4bcb8f04ed3623da7c84dda28017f473cbc97e53/make/autoconf/configure.ac#L314-L321
> 
> Or, before we print configuration summary.
> 
> Now, this works most of the time by accident: when root dir and build dir are on the same filesystem, the file move does not interfere with inodes/FDs, and we are still able to write to the same file _after_ we moved. But if build dir is on _another_ filesystem, then we miss writing the configuration summary when file moves away.
> 
> Apparently, my systems fall into that trap, since build dir is on RAM disk.

Thanks for fixing. The autoconf workarounds are really quirky, and have evolved slowly over time. I'm not even sure if the move was originally inserted too early, or the additional output has been added afterwards.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20356#pullrequestreview-2218816234

From ihse at openjdk.org  Mon Aug  5 12:11:33 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Aug 2024 12:11:33 GMT
Subject: RFR: 8336928: GHA: Bundle artifacts removal broken [v2]
In-Reply-To: <qCKDzi7NgUqaMHxU6MUE-qJ2NkZq7P1ennHEM1_0hQk=.05cdaacd-1184-48e5-89f8-19f79459c8d4@github.com>
References: <BQPGc2oNd-e9WPIfRr3sMwyI6bW6wjdIiB742EtcVog=.8479476c-2449-40f1-a5d5-96e2c9692b85@github.com>
 <qCKDzi7NgUqaMHxU6MUE-qJ2NkZq7P1ennHEM1_0hQk=.05cdaacd-1184-48e5-89f8-19f79459c8d4@github.com>
Message-ID: <ENhg4tX8TuJmcERXWDh5hGhFflstd1RzX4hAsEpuS6Q=.a93f4091-04d3-464e-a730-c41426a9245d@github.com>

On Mon, 22 Jul 2024 20:41:52 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

>> GHA code, which tries to remove bundle artifacts no longer works. It probably broke after [JDK-8324723](https://bugs.openjdk.org/browse/JDK-8324723) (GHA: Upgrade some actions to avoid deprecated Node 16).
>> 
>> **Details:**
>> Seems like there were some backend architecture changes in [artifact actions in v4](https://github.com/actions/upload-artifact?tab=readme-ov-file#v4---whats-new). As result old code to remove artifacts no longer works. However there is [REST API](https://docs.github.com/en/rest/actions/artifacts?apiVersion=2022-11-28) available, which works.
>
> Zdenek Zambersky has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reintroduce -s flag

The code looks sane. Have you been able to test this? (Trying out GHA changes is sometimes a bit tricky)

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20281#pullrequestreview-2218825646

From ihse at openjdk.org  Mon Aug  5 12:29:32 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Aug 2024 12:29:32 GMT
Subject: RFR: 8336849: Remove .llvm_addrsig section from JDK/VM static
 libraries (.a files)
In-Reply-To: <ydhogvsR2STcb7WGAQCjAua5l25gEd16Kjh_A0meInA=.92082d43-9187-47e4-b741-2fe059afb1bc@github.com>
References: <ydhogvsR2STcb7WGAQCjAua5l25gEd16Kjh_A0meInA=.92082d43-9187-47e4-b741-2fe059afb1bc@github.com>
Message-ID: <HIxGm5Z49_yc-BtDOuplRbk3WxTVc70xYDu51zAAJts=.00f0a582-8e27-45dc-8a51-17ce821b53f0@github.com>

On Sat, 20 Jul 2024 00:20:19 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that strips the `.llvm_addrsig` section from JDK and hotspot `.a` static libraries when building with clang. Please see https://bugs.openjdk.org/browse/JDK-8336849 description for details.

I'm back from vacation now. 

This all seems very odd to me. Where do we set `--icf=safe` to the linker, and why? Why has this not shown up earlier?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20265#issuecomment-2268953883

From clanger at openjdk.org  Mon Aug  5 12:35:58 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 5 Aug 2024 12:35:58 GMT
Subject: RFR: 8337819: Update GHA JDKs to 22.0.2
Message-ID: <QMsxJZXuAwkWVh0ItD6BKrbkHn0lXm6kWKuCzDgWraI=.16776427-de45-4eed-9fab-6a9fe94c3640@github.com>

Currently, we use JDK 22 GA binaries in Github Actions. Since JDK 22.0.2 is available in the meanwhile, we can use it. I also correct the alphabetical ordering of the macOS platforms.

-------------

Commit messages:
 - JDK-8337819

Changes: https://git.openjdk.org/jdk/pull/20467/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20467&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337819
  Stats: 14 lines in 1 file changed: 4 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20467.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20467/head:pull/20467

PR: https://git.openjdk.org/jdk/pull/20467

From ihse at openjdk.org  Mon Aug  5 12:46:33 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Aug 2024 12:46:33 GMT
Subject: RFR: 8335880: More troubleshooting tips around windows space in
 path [v3]
In-Reply-To: <ZixjNaACu8HNkDtzRx9jb4hMvi1VQn7jg3ZT0tbPhuI=.2fe62c2c-9bd0-4dc7-b569-b6496d91b329@github.com>
References: <w5TjafnC5QZ8V5Atd3eBEh86c1mdmhXH0D9f25bY7Xs=.528de2c6-0f89-4c58-9c98-16c5fb19e790@github.com>
 <ZixjNaACu8HNkDtzRx9jb4hMvi1VQn7jg3ZT0tbPhuI=.2fe62c2c-9bd0-4dc7-b569-b6496d91b329@github.com>
Message-ID: <HUl9uAjJCpOwPRsftpYbdZZtsYunLSzYM6nxKlSpu4I=.6e41cf3a-0328-4309-bf57-9813e7936962@github.com>

On Tue, 16 Jul 2024 23:20:03 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Context: https://mail.openjdk.org/pipermail/build-dev/2024-July/045586.html
>> 
>> People were confused on a few details around fixing windows space names, including:
>> 1. setshortname can report confusing error message when the directory is in use
>> 2. Many directories can have names set but only Microsoft Visual Studio and Windows Kits need them
>> 
>> Also adds some notes about `jdk` being the exploded image while `images/jdk` is the actual image.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update html

doc/building.md line 28:

> 26:  4. Verify your newly built JDK: \
> 27:     `./build/*/images/jdk/bin/java -version` \
> 28:     Note the built JDK is at `/images/jdk` instead of `/jdk`.

I'm not sure this is really helpful, or at least not in this place and form. Can we move the changes related to how to distinguish a full JDK image from a "partial JDK"/"exploded image" to a separate issue?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20197#discussion_r1704057102

From matthias.baesken at sap.com  Mon Aug  5 12:46:32 2024
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 5 Aug 2024 12:46:32 +0000
Subject: Add "Windows aarch64" to Supported Build Platforms
In-Reply-To: <mailman.20703.1722859899.324.build-dev@openjdk.org>
References: <mailman.20703.1722859899.324.build-dev@openjdk.org>
Message-ID: <AM9PR02MB677042A3BA6517EDC3041DA093BE2@AM9PR02MB6770.eurprd02.prod.outlook.com>

Hi Brian , if you give me the detailled info I can add  it  .

Best regards, Matthias


----------------------------------------------------------------------
Hello,

We would like to add Microsoft as the maintainer of Windows aarch64 to the Supported Build Platforms[1] page (JDK versions 11/17/21).

Who can help us out with that?

Thanks!
Brian Stafford
Microsoft

[1] https://wiki.openjdk.org/display/Build/Supported+Build+Platforms




From ihse at openjdk.org  Mon Aug  5 12:50:33 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Aug 2024 12:50:33 GMT
Subject: RFR: 8335880: More troubleshooting tips around windows space in
 path [v3]
In-Reply-To: <ZixjNaACu8HNkDtzRx9jb4hMvi1VQn7jg3ZT0tbPhuI=.2fe62c2c-9bd0-4dc7-b569-b6496d91b329@github.com>
References: <w5TjafnC5QZ8V5Atd3eBEh86c1mdmhXH0D9f25bY7Xs=.528de2c6-0f89-4c58-9c98-16c5fb19e790@github.com>
 <ZixjNaACu8HNkDtzRx9jb4hMvi1VQn7jg3ZT0tbPhuI=.2fe62c2c-9bd0-4dc7-b569-b6496d91b329@github.com>
Message-ID: <aQ50p44tUN9XA6Ps2tYetlgzulQcETDp0-WXQbPnnuQ=.6f64a2e8-537d-4aca-8bed-c82b93a4ada5@github.com>

On Tue, 16 Jul 2024 23:20:03 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Context: https://mail.openjdk.org/pipermail/build-dev/2024-July/045586.html
>> 
>> People were confused on a few details around fixing windows space names, including:
>> 1. setshortname can report confusing error message when the directory is in use
>> 2. Many directories can have names set but only Microsoft Visual Studio and Windows Kits need them
>> 
>> Also adds some notes about `jdk` being the exploded image while `images/jdk` is the actual image.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update html

doc/building.md line 1816:

> 1814: The only directories required to have short paths are `Microsoft Visual Studio`
> 1815: and `Windows Kits`; the rest of the "contains space" warnings from `configure`
> 1816: can be ignored. You can choose any short name; once it is set, `configure`'s

What other directories are reported from configure? 

It does not seem correct to me to say that they can just be ignored -- either the directory is relevant for compilation, and then we need to have it without spaces, or it is not really used and then it should be removed, or made optional.

If  `Microsoft Visual Studio` and  `Windows Kits` are typical path-with-spaces that users can run into, we should perhaps add an additional check to configure for these. In fact, I think what we *should* do is to have configure print this help about `fsutil file setshortname` if it encounters a path with spaces that it cannot turn into a short name. That way, a complete copy/pastable command line can be generated for the user to run.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20197#discussion_r1704063427

From mbaesken at openjdk.org  Mon Aug  5 12:52:31 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 5 Aug 2024 12:52:31 GMT
Subject: RFR: 8337819: Update GHA JDKs to 22.0.2
In-Reply-To: <QMsxJZXuAwkWVh0ItD6BKrbkHn0lXm6kWKuCzDgWraI=.16776427-de45-4eed-9fab-6a9fe94c3640@github.com>
References: <QMsxJZXuAwkWVh0ItD6BKrbkHn0lXm6kWKuCzDgWraI=.16776427-de45-4eed-9fab-6a9fe94c3640@github.com>
Message-ID: <_RAIeGivKkheOsrhVkDiMunRt3Z9Wl972Wfh4XDOGOc=.8def27f4-adaf-4140-a575-93644cf80986@github.com>

On Mon, 5 Aug 2024 12:30:25 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Currently, we use JDK 22 GA binaries in Github Actions. Since JDK 22.0.2 is available in the meanwhile, we can use it. I also correct the alphabetical ordering of the macOS platforms.

Marked as reviewed by mbaesken (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20467#pullrequestreview-2218911928

From zzambers at openjdk.org  Mon Aug  5 13:01:31 2024
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Mon, 5 Aug 2024 13:01:31 GMT
Subject: RFR: 8336928: GHA: Bundle artifacts removal broken [v2]
In-Reply-To: <ENhg4tX8TuJmcERXWDh5hGhFflstd1RzX4hAsEpuS6Q=.a93f4091-04d3-464e-a730-c41426a9245d@github.com>
References: <BQPGc2oNd-e9WPIfRr3sMwyI6bW6wjdIiB742EtcVog=.8479476c-2449-40f1-a5d5-96e2c9692b85@github.com>
 <qCKDzi7NgUqaMHxU6MUE-qJ2NkZq7P1ennHEM1_0hQk=.05cdaacd-1184-48e5-89f8-19f79459c8d4@github.com>
 <ENhg4tX8TuJmcERXWDh5hGhFflstd1RzX4hAsEpuS6Q=.a93f4091-04d3-464e-a730-c41426a9245d@github.com>
Message-ID: <-VlJaykNvQoJWidBV3oZd2XZ96M7U2PQe5TDL8xjgAk=.e1a8d221-7e85-4000-8f69-7abaae731cc2@github.com>

On Mon, 5 Aug 2024 12:08:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Zdenek Zambersky has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reintroduce -s flag
>
> The code looks sane. Have you been able to test this? (Trying out GHA changes is sometimes a bit tricky)

@magicus I have tested it by having GHA enabled on my fork/branch, as usual. I can see that right number of artifacts has been removed in ["Remove bundle artifacts"](https://github.com/zzambers/jdk/actions/runs/10048035882/job/27776568302) step. And there are no "bundles-*" artifacts in [Summary](https://github.com/zzambers/jdk/actions/runs/10048035882). (Unlike in other test runs, without this change, e.g. [here](https://github.com/egahlin/jdk/actions/runs/10246511374).)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20281#issuecomment-2269018010

From ihse at openjdk.org  Mon Aug  5 13:32:33 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Aug 2024 13:32:33 GMT
Subject: RFR: 8337819: Update GHA JDKs to 22.0.2
In-Reply-To: <QMsxJZXuAwkWVh0ItD6BKrbkHn0lXm6kWKuCzDgWraI=.16776427-de45-4eed-9fab-6a9fe94c3640@github.com>
References: <QMsxJZXuAwkWVh0ItD6BKrbkHn0lXm6kWKuCzDgWraI=.16776427-de45-4eed-9fab-6a9fe94c3640@github.com>
Message-ID: <QFOub80VrhOHfe-ut-CCt3-JvZU1MvxysZuNM0E123I=.3f267b39-ba81-4ae9-a02b-093b0a76c790@github.com>

On Mon, 5 Aug 2024 12:30:25 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Currently, we use JDK 22 GA binaries in Github Actions. Since JDK 22.0.2 is available in the meanwhile, we can use it. I also correct the alphabetical ordering of the macOS platforms.

Marked as reviewed by ihse (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20467#pullrequestreview-2219013381

From ihse at openjdk.org  Mon Aug  5 13:49:33 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Aug 2024 13:49:33 GMT
Subject: RFR: 8336928: GHA: Bundle artifacts removal broken [v2]
In-Reply-To: <qCKDzi7NgUqaMHxU6MUE-qJ2NkZq7P1ennHEM1_0hQk=.05cdaacd-1184-48e5-89f8-19f79459c8d4@github.com>
References: <BQPGc2oNd-e9WPIfRr3sMwyI6bW6wjdIiB742EtcVog=.8479476c-2449-40f1-a5d5-96e2c9692b85@github.com>
 <qCKDzi7NgUqaMHxU6MUE-qJ2NkZq7P1ennHEM1_0hQk=.05cdaacd-1184-48e5-89f8-19f79459c8d4@github.com>
Message-ID: <FykpPH15Mwhjm_98l4hfoIFsLCThRWGmPmVRvd6HcX8=.10e0a8ac-f462-4b13-bbfb-9708a39c7614@github.com>

On Mon, 22 Jul 2024 20:41:52 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

>> GHA code, which tries to remove bundle artifacts no longer works. It probably broke after [JDK-8324723](https://bugs.openjdk.org/browse/JDK-8324723) (GHA: Upgrade some actions to avoid deprecated Node 16).
>> 
>> **Details:**
>> Seems like there were some backend architecture changes in [artifact actions in v4](https://github.com/actions/upload-artifact?tab=readme-ov-file#v4---whats-new). As result old code to remove artifacts no longer works. However there is [REST API](https://docs.github.com/en/rest/actions/artifacts?apiVersion=2022-11-28) available, which works.
>
> Zdenek Zambersky has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reintroduce -s flag

Great, thanks! The build system does not need a secondary review so you are free to integrate.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20281#issuecomment-2269117388

From zzambers at openjdk.org  Mon Aug  5 13:49:34 2024
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Mon, 5 Aug 2024 13:49:34 GMT
Subject: RFR: 8336928: GHA: Bundle artifacts removal broken [v2]
In-Reply-To: <FykpPH15Mwhjm_98l4hfoIFsLCThRWGmPmVRvd6HcX8=.10e0a8ac-f462-4b13-bbfb-9708a39c7614@github.com>
References: <BQPGc2oNd-e9WPIfRr3sMwyI6bW6wjdIiB742EtcVog=.8479476c-2449-40f1-a5d5-96e2c9692b85@github.com>
 <qCKDzi7NgUqaMHxU6MUE-qJ2NkZq7P1ennHEM1_0hQk=.05cdaacd-1184-48e5-89f8-19f79459c8d4@github.com>
 <FykpPH15Mwhjm_98l4hfoIFsLCThRWGmPmVRvd6HcX8=.10e0a8ac-f462-4b13-bbfb-9708a39c7614@github.com>
Message-ID: <fN1YVF3qPOXoOB8DkBPxpqOb3EIYQQoZpx81gDcF4D4=.6ba1f59f-f96f-46e2-b7b0-2363cf4fb1c8@github.com>

On Mon, 5 Aug 2024 13:44:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Zdenek Zambersky has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reintroduce -s flag
>
> Great, thanks! The build system does not need a secondary review so you are free to integrate.

@magicus thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20281#issuecomment-2269120646

From duke at openjdk.org  Mon Aug  5 13:49:35 2024
From: duke at openjdk.org (duke)
Date: Mon, 5 Aug 2024 13:49:35 GMT
Subject: RFR: 8336928: GHA: Bundle artifacts removal broken [v2]
In-Reply-To: <qCKDzi7NgUqaMHxU6MUE-qJ2NkZq7P1ennHEM1_0hQk=.05cdaacd-1184-48e5-89f8-19f79459c8d4@github.com>
References: <BQPGc2oNd-e9WPIfRr3sMwyI6bW6wjdIiB742EtcVog=.8479476c-2449-40f1-a5d5-96e2c9692b85@github.com>
 <qCKDzi7NgUqaMHxU6MUE-qJ2NkZq7P1ennHEM1_0hQk=.05cdaacd-1184-48e5-89f8-19f79459c8d4@github.com>
Message-ID: <jZs2C4VnZy4g-hw8Mq4uecOJ-jxmyVcSbDkBrBSU4Qg=.4d3f1524-8920-4258-93ea-0860163e9b5a@github.com>

On Mon, 22 Jul 2024 20:41:52 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

>> GHA code, which tries to remove bundle artifacts no longer works. It probably broke after [JDK-8324723](https://bugs.openjdk.org/browse/JDK-8324723) (GHA: Upgrade some actions to avoid deprecated Node 16).
>> 
>> **Details:**
>> Seems like there were some backend architecture changes in [artifact actions in v4](https://github.com/actions/upload-artifact?tab=readme-ov-file#v4---whats-new). As result old code to remove artifacts no longer works. However there is [REST API](https://docs.github.com/en/rest/actions/artifacts?apiVersion=2022-11-28) available, which works.
>
> Zdenek Zambersky has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reintroduce -s flag

@zzambers 
Your change (at version 81c5e3144725daf926401352716e04270b8b5b68) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20281#issuecomment-2269123713

From shade at openjdk.org  Mon Aug  5 14:07:35 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 5 Aug 2024 14:07:35 GMT
Subject: RFR: 8337283: configure.log is truncated when build dir is on
 different filesystem
In-Reply-To: <mYhHd1tr6cUfvEI2_6jviNhB98tyu505gjo83LKLYAI=.56d98b0d-74ff-4749-8065-eacdc07783c2@github.com>
References: <mYhHd1tr6cUfvEI2_6jviNhB98tyu505gjo83LKLYAI=.56d98b0d-74ff-4749-8065-eacdc07783c2@github.com>
Message-ID: <MaTQiiCH8pLBuMAQDPdWh4P-WOUJ-6c3Muix09l0J3s=.e670ff0c-1d56-43cb-8de0-070d3aca2821@github.com>

On Fri, 26 Jul 2024 16:21:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I noticed that `build/$confname/configure.log` was truncated on some of my build nodes. Turns out, we are moving configure.log from tree root to that place a bit prematurely.
> 
> We move `configure.log` here:
> https://github.com/openjdk/jdk/blob/4f194f10a1481cdc9df4e6338f6cabd07a34c84c/make/autoconf/basic.m4#L594-L618
> 
> ...and that is called here:
> https://github.com/openjdk/jdk/blob/4bcb8f04ed3623da7c84dda28017f473cbc97e53/make/autoconf/configure.ac#L314-L321
> 
> Or, before we print configuration summary.
> 
> Now, this works most of the time by accident: when root dir and build dir are on the same filesystem, the file move does not interfere with inodes/FDs, and we are still able to write to the same file _after_ we moved. But if build dir is on _another_ filesystem, then we miss writing the configuration summary when file moves away.
> 
> Apparently, my systems fall into that trap, since build dir is on RAM disk.

Thanks for reviews! I have been building all (except JDK 8) builds.shipilev.net binaries with this patch for a week, and there was no trouble. I'll backport this soon.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20356#issuecomment-2269159637

From shade at openjdk.org  Mon Aug  5 14:07:36 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 5 Aug 2024 14:07:36 GMT
Subject: Integrated: 8337283: configure.log is truncated when build dir is on
 different filesystem
In-Reply-To: <mYhHd1tr6cUfvEI2_6jviNhB98tyu505gjo83LKLYAI=.56d98b0d-74ff-4749-8065-eacdc07783c2@github.com>
References: <mYhHd1tr6cUfvEI2_6jviNhB98tyu505gjo83LKLYAI=.56d98b0d-74ff-4749-8065-eacdc07783c2@github.com>
Message-ID: <zU_rtx6a8I-cWN6aLyVKIIXDfbGOpGGLsoJ0LCcZOCY=.90b2830c-9f6a-4d7f-bcd1-bf4873c9dfc6@github.com>

On Fri, 26 Jul 2024 16:21:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I noticed that `build/$confname/configure.log` was truncated on some of my build nodes. Turns out, we are moving configure.log from tree root to that place a bit prematurely.
> 
> We move `configure.log` here:
> https://github.com/openjdk/jdk/blob/4f194f10a1481cdc9df4e6338f6cabd07a34c84c/make/autoconf/basic.m4#L594-L618
> 
> ...and that is called here:
> https://github.com/openjdk/jdk/blob/4bcb8f04ed3623da7c84dda28017f473cbc97e53/make/autoconf/configure.ac#L314-L321
> 
> Or, before we print configuration summary.
> 
> Now, this works most of the time by accident: when root dir and build dir are on the same filesystem, the file move does not interfere with inodes/FDs, and we are still able to write to the same file _after_ we moved. But if build dir is on _another_ filesystem, then we miss writing the configuration summary when file moves away.
> 
> Apparently, my systems fall into that trap, since build dir is on RAM disk.

This pull request has now been integrated.

Changeset: 7e925d72
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7e925d727f716e5c366b0d85b9c0de24efe43103
Stats:     4 lines in 1 file changed: 3 ins; 1 del; 0 mod

8337283: configure.log is truncated when build dir is on different filesystem

Reviewed-by: phh, stuefe, clanger, ihse

-------------

PR: https://git.openjdk.org/jdk/pull/20356

From shade at openjdk.org  Mon Aug  5 14:43:32 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 5 Aug 2024 14:43:32 GMT
Subject: RFR: 8337819: Update GHA JDKs to 22.0.2
In-Reply-To: <QMsxJZXuAwkWVh0ItD6BKrbkHn0lXm6kWKuCzDgWraI=.16776427-de45-4eed-9fab-6a9fe94c3640@github.com>
References: <QMsxJZXuAwkWVh0ItD6BKrbkHn0lXm6kWKuCzDgWraI=.16776427-de45-4eed-9fab-6a9fe94c3640@github.com>
Message-ID: <tGeEher1zy2W1-RJKnV_oNryswdsaqiBj3WTlhq7GHY=.33ccf11c-cfe5-42f2-9cd6-aed159c6a304@github.com>

On Mon, 5 Aug 2024 12:30:25 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Currently, we use JDK 22 GA binaries in Github Actions. Since JDK 22.0.2 is available in the meanwhile, we can use it. I also correct the alphabetical ordering of the macOS platforms.

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20467#pullrequestreview-2219189626

From zzambers at openjdk.org  Mon Aug  5 15:12:36 2024
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Mon, 5 Aug 2024 15:12:36 GMT
Subject: Integrated: 8336928: GHA: Bundle artifacts removal broken
In-Reply-To: <BQPGc2oNd-e9WPIfRr3sMwyI6bW6wjdIiB742EtcVog=.8479476c-2449-40f1-a5d5-96e2c9692b85@github.com>
References: <BQPGc2oNd-e9WPIfRr3sMwyI6bW6wjdIiB742EtcVog=.8479476c-2449-40f1-a5d5-96e2c9692b85@github.com>
Message-ID: <894mHwCy5daW6jl61nN5-sL6QZc5OwqlArcq2eFT0_g=.5bef97a3-897a-48f9-a02f-bc0b90ef2bea@github.com>

On Mon, 22 Jul 2024 20:26:50 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

> GHA code, which tries to remove bundle artifacts no longer works. It probably broke after [JDK-8324723](https://bugs.openjdk.org/browse/JDK-8324723) (GHA: Upgrade some actions to avoid deprecated Node 16).
> 
> **Details:**
> Seems like there were some backend architecture changes in [artifact actions in v4](https://github.com/actions/upload-artifact?tab=readme-ov-file#v4---whats-new). As result old code to remove artifacts no longer works. However there is [REST API](https://docs.github.com/en/rest/actions/artifacts?apiVersion=2022-11-28) available, which works.

This pull request has now been integrated.

Changeset: 98562166
Author:    Zdenek Zambersky <zzambers at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/98562166e4a4c8921709014423c6cbc993aa0d97
Stats:     22 lines in 1 file changed: 4 ins; 7 del; 11 mod

8336928: GHA: Bundle artifacts removal broken

Reviewed-by: ihse

-------------

PR: https://git.openjdk.org/jdk/pull/20281

From ihse at openjdk.org  Mon Aug  5 15:22:33 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Aug 2024 15:22:33 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v2]
In-Reply-To: <o8AMwn0LgrRO6D1WfU89F7xPTwt08LdsZKzsEijFfyg=.4fa9126b-98de-4878-b601-d02b03050e2b@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <o8AMwn0LgrRO6D1WfU89F7xPTwt08LdsZKzsEijFfyg=.4fa9126b-98de-4878-b601-d02b03050e2b@github.com>
Message-ID: <SwXug6F4BisDdJjJs1Wel3evwd0AbnYyWS-1sL_sjvs=.3a66f702-9a2f-4ab1-8932-59208c3871c0@github.com>

On Fri, 26 Jul 2024 19:40:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio

make/modules/java.base/lib/CoreLibraries.gmk line 57:

> 55:     OPTIMIZATION := HIGH, \
> 56:     EXTRA_HEADER_DIRS := \
> 57:         libnio/ch, \

This will introduce a source code dependency from libjava to libnio. It might be the correct thing to do, but I just want to highlight this. 

Maybe the libnio/ch code also should move to libjava? Or, perhaps at least the header files. Conceptually, I'd feel better about having a dependency on libnio as a "downstream" library on libjava source code, than the other way around.

make/modules/java.base/lib/CoreLibraries.gmk line 71:

> 69:         -framework Foundation \
> 70:         -framework SystemConfiguration, \
> 71:     LIBS_windows := advapi32.lib ole32.lib shell32.lib version.lib mswsock.lib ws2_32.lib, \

Please keep libraries alphabetically sorted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1704283438
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1704283936

From ihse at openjdk.org  Mon Aug  5 15:28:31 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Aug 2024 15:28:31 GMT
Subject: RFR: 8336498: [macos] [build]: install-file macro may run into
 permission denied error
In-Reply-To: <dMqnljHWGtietpR7M7V0gcVxSb4gidHXTE2qJ0xVe5Y=.576e9b23-0345-425c-a106-d4ed938d5015@github.com>
References: <dMqnljHWGtietpR7M7V0gcVxSb4gidHXTE2qJ0xVe5Y=.576e9b23-0345-425c-a106-d4ed938d5015@github.com>
Message-ID: <7Ys4xNKOA1GMnrogmfUX2-pa2igFoA4kOTEQN6xFi0I=.40e466cd-bd79-4d31-8348-4547a2b9ac3a@github.com>

On Tue, 16 Jul 2024 20:50:32 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> On MacOS, files may have extended attributes attached. These attributes are copied together with the files. To prevent issues during further processing, the extended attributes of the copies must be removed. This action was implemented as solution of an older bug.
> 
> The solution is incomplete because it does not handle files with read-only permissions correctly. Without write permission, matter cannot remove the extended attributes. The action is rejected with a "permission denied" error.
> 
> The issue is present in all releases. I reproduced it in 11, 17, ... 23, head
> 
> The solution is to "chmod u+w" only those files which need to have their extended attributes removed.
> 
> Backport note: in releases prior to jdk23, the change needs to go into file MakeBase.gmk.
> 
> Testing @SAP completed without any related issues.

Hi, I'm back from vacation now. 

I feel a bit okay-ish about this fix. To be honest, we have not really been good at ensuring proper file permissions at all times, but instead resorted to this kind of adhoc-fixes whenever problems arise. So in that spirit, I guess this is as good as any of the previous such fixes.

But on the other hand, I don't like that state of affairs. I'm even more vexed by the fact that you state that the extended attributes and/or the write protection come and go erratically. I think it might be wise to spend a bit more effort trying to figure out why this happens.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20203#issuecomment-2269340953

From bpb at openjdk.org  Mon Aug  5 15:40:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 5 Aug 2024 15:40:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v2]
In-Reply-To: <SwXug6F4BisDdJjJs1Wel3evwd0AbnYyWS-1sL_sjvs=.3a66f702-9a2f-4ab1-8932-59208c3871c0@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <o8AMwn0LgrRO6D1WfU89F7xPTwt08LdsZKzsEijFfyg=.4fa9126b-98de-4878-b601-d02b03050e2b@github.com>
 <SwXug6F4BisDdJjJs1Wel3evwd0AbnYyWS-1sL_sjvs=.3a66f702-9a2f-4ab1-8932-59208c3871c0@github.com>
Message-ID: <BiQ_TBNl7VkHlTgdLT6pjZCoVEkpjwgynx-ZT0b51Aw=.3a6df22f-a074-40a6-8291-c2f4452980a0@github.com>

On Mon, 5 Aug 2024 15:19:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This will introduce a source code dependency from libjava to libnio. It might be the correct thing to do, but I just want to highlight this.

I'll look into improving it.

> make/modules/java.base/lib/CoreLibraries.gmk line 71:
> 
>> 69:         -framework Foundation \
>> 70:         -framework SystemConfiguration, \
>> 71:     LIBS_windows := advapi32.lib ole32.lib shell32.lib version.lib mswsock.lib ws2_32.lib, \
> 
> Please keep libraries alphabetically sorted.

Thanks for pointing this out; I will fix it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1704310018
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1704310460

From ihse at openjdk.org  Mon Aug  5 15:41:35 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Aug 2024 15:41:35 GMT
Subject: RFR: 8329471: Remove GTK2 [v5]
In-Reply-To: <EUtvj17LIouoxAgU-mx7MGfotJwsjJouWFk1jJzY6FI=.aaeb2d6f-a9a7-48a7-9ba2-4e87e4d167de@github.com>
References: <JABMEI4R7RPqCP6MjBvzP-0c3Mb-siUcFJQEQ1aFUJo=.96b6712e-10b3-490b-a57f-c57a130710c8@github.com>
 <EUtvj17LIouoxAgU-mx7MGfotJwsjJouWFk1jJzY6FI=.aaeb2d6f-a9a7-48a7-9ba2-4e87e4d167de@github.com>
Message-ID: <PWD3lseXfRGkn23-XiTZ2dpCFSJEp3iJJwKm3z-4kxw=.570465c7-e9c0-4241-be54-05243cba1315@github.com>

On Wed, 31 Jul 2024 19:17:05 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> GTK2 support for Swing/AWT was deprecated for removal in JDK 21. 
>> 
>> It's being removed because no platform that supports the JDK needs it.
>> 
>> Manual and automated testing is green.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more removal of is3()

Build changes are trivially fine.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20378#pullrequestreview-2219324329

From ihse at openjdk.org  Mon Aug  5 15:53:32 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Aug 2024 15:53:32 GMT
Subject: RFR: 8337410: The makefiles should set problemlist and adjust
 timeout basing on the given VM flags
In-Reply-To: <HSbKJYVYgMPgkPuXFwzDECWYOcfk5d86zp1gNmS5eJM=.38b1c9c5-558c-4584-a3e3-ac23640f7c5c@github.com>
References: <HSbKJYVYgMPgkPuXFwzDECWYOcfk5d86zp1gNmS5eJM=.38b1c9c5-558c-4584-a3e3-ac23640f7c5c@github.com>
Message-ID: <BQRW7Bj4yI83B3b5uFn21qoGpU2_lrtO9DuDgHgoFKQ=.675377d3-8713-412d-a2c7-cdcbcd38764b@github.com>

On Thu, 1 Aug 2024 18:26:55 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> There jtreg tests have several additional problemlists 
> ProblemList-Xcomp.txt
> ProblemList-generational-zgc.txt
> ProblemList-zgc.txt
> Each of them is bound to corresponding execution mode (Xcomp/ZGC) and it makes sense to treat them like standard problemlist when tests are executed with -Xcomp or ZGC enabled.
> Currently, it is needed to set them manually and it is often forgotten. So engineers waste time analyzing known failures.
> 
> Additionally, the **default** timeoutFactor is increased when Xcomp is enabled because of slowness of this mode. 
> 
> The jtreg allows to add the same problemlist twice so it is not needed to update any execution system that set problemlists.
> 
> Later it might makes sens to set 'JTREG_ALL_OPTIONS' by asking java about actually set mode. So it is possible to adjust  options for fastdebug/slowdebug/product modes and/or different options that are set during compilation (saying different default GC).

make/RunTests.gmk line 844:

> 842: 
> 843:   ifneq ($$(findstring -Xcomp, $$(JTREG_ALL_OPTIONS)), )
> 844:     JTREG_AUTO_PROBLEM_LISTS := $$(JTREG_AUTO_PROBLEM_LISTS) ProblemList-Xcomp.txt

Please use `+=` instead.

make/RunTests.gmk line 845:

> 843:   ifneq ($$(findstring -Xcomp, $$(JTREG_ALL_OPTIONS)), )
> 844:     JTREG_AUTO_PROBLEM_LISTS := $$(JTREG_AUTO_PROBLEM_LISTS) ProblemList-Xcomp.txt
> 845:     JTREG_AUTO_TIMEOUT_FACTOR ?= 10

Since you assign this to be 4 a couple of lines up, this code will never do anything.

make/RunTests.gmk line 849:

> 847: 
> 848:   ifneq ($$(findstring -XX:+UseZGC, $$(JTREG_ALL_OPTIONS)), )
> 849:     ifneq ($$(findstring -XX:-ZGenerational, $$(JTREG_ALL_OPTIONS)), )

Is this the only way that zgc can be run in a non-generational mode? I understand the idea to automatically pick the right set of problem list files, I just want to make sure it is robust.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20430#discussion_r1704323910
PR Review Comment: https://git.openjdk.org/jdk/pull/20430#discussion_r1704324902
PR Review Comment: https://git.openjdk.org/jdk/pull/20430#discussion_r1704328291

From ihse at openjdk.org  Mon Aug  5 15:53:33 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Aug 2024 15:53:33 GMT
Subject: RFR: 8337410: The makefiles should set problemlist and adjust
 timeout basing on the given VM flags
In-Reply-To: <BQRW7Bj4yI83B3b5uFn21qoGpU2_lrtO9DuDgHgoFKQ=.675377d3-8713-412d-a2c7-cdcbcd38764b@github.com>
References: <HSbKJYVYgMPgkPuXFwzDECWYOcfk5d86zp1gNmS5eJM=.38b1c9c5-558c-4584-a3e3-ac23640f7c5c@github.com>
 <BQRW7Bj4yI83B3b5uFn21qoGpU2_lrtO9DuDgHgoFKQ=.675377d3-8713-412d-a2c7-cdcbcd38764b@github.com>
Message-ID: <UOtShMmbN0JiqogWzwXhCLcGg39O5tHBSX2yHCPMA8c=.d67b18c2-f8bc-4c52-be44-0c219b999afe@github.com>

On Mon, 5 Aug 2024 15:48:44 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> There jtreg tests have several additional problemlists 
>> ProblemList-Xcomp.txt
>> ProblemList-generational-zgc.txt
>> ProblemList-zgc.txt
>> Each of them is bound to corresponding execution mode (Xcomp/ZGC) and it makes sense to treat them like standard problemlist when tests are executed with -Xcomp or ZGC enabled.
>> Currently, it is needed to set them manually and it is often forgotten. So engineers waste time analyzing known failures.
>> 
>> Additionally, the **default** timeoutFactor is increased when Xcomp is enabled because of slowness of this mode. 
>> 
>> The jtreg allows to add the same problemlist twice so it is not needed to update any execution system that set problemlists.
>> 
>> Later it might makes sens to set 'JTREG_ALL_OPTIONS' by asking java about actually set mode. So it is possible to adjust  options for fastdebug/slowdebug/product modes and/or different options that are set during compilation (saying different default GC).
>
> make/RunTests.gmk line 845:
> 
>> 843:   ifneq ($$(findstring -Xcomp, $$(JTREG_ALL_OPTIONS)), )
>> 844:     JTREG_AUTO_PROBLEM_LISTS := $$(JTREG_AUTO_PROBLEM_LISTS) ProblemList-Xcomp.txt
>> 845:     JTREG_AUTO_TIMEOUT_FACTOR ?= 10
> 
> Since you assign this to be 4 a couple of lines up, this code will never do anything.

Did you test that this patch works as intended?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20430#discussion_r1704325504

From liach at openjdk.org  Mon Aug  5 15:57:32 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 5 Aug 2024 15:57:32 GMT
Subject: RFR: 8335880: More troubleshooting tips around windows space in
 path [v3]
In-Reply-To: <aQ50p44tUN9XA6Ps2tYetlgzulQcETDp0-WXQbPnnuQ=.6f64a2e8-537d-4aca-8bed-c82b93a4ada5@github.com>
References: <w5TjafnC5QZ8V5Atd3eBEh86c1mdmhXH0D9f25bY7Xs=.528de2c6-0f89-4c58-9c98-16c5fb19e790@github.com>
 <ZixjNaACu8HNkDtzRx9jb4hMvi1VQn7jg3ZT0tbPhuI=.2fe62c2c-9bd0-4dc7-b569-b6496d91b329@github.com>
 <aQ50p44tUN9XA6Ps2tYetlgzulQcETDp0-WXQbPnnuQ=.6f64a2e8-537d-4aca-8bed-c82b93a4ada5@github.com>
Message-ID: <s0G3j--MZD878ZdqW_eB8SgjIGk-qomBW-MTLPQscNA=.ea971d73-84d7-428d-9a8f-4fb43a173814@github.com>

On Mon, 5 Aug 2024 12:47:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update html
>
> doc/building.md line 1816:
> 
>> 1814: The only directories required to have short paths are `Microsoft Visual Studio`
>> 1815: and `Windows Kits`; the rest of the "contains space" warnings from `configure`
>> 1816: can be ignored. You can choose any short name; once it is set, `configure`'s
> 
> What other directories are reported from configure? 
> 
> It does not seem correct to me to say that they can just be ignored -- either the directory is relevant for compilation, and then we need to have it without spaces, or it is not really used and then it should be removed, or made optional.
> 
> If  `Microsoft Visual Studio` and  `Windows Kits` are typical path-with-spaces that users can run into, we should perhaps add an additional check to configure for these. In fact, I think what we *should* do is to have configure print this help about `fsutil file setshortname` if it encounters a path with spaces that it cannot turn into a short name. That way, a complete copy/pastable command line can be generated for the user to run.

configure scans `PATH` which may include other spaced directories, such as "Intellij Idea." On a user device, this list can quickly become huge and it would be unrealistic for users to generate short paths for every single one of those directories.

In fact, the only 2 directories that need short path configuration for configure to work correctly are Microsoft Visual Studio and Windows Kits.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20197#discussion_r1704333632

From ihse at openjdk.org  Mon Aug  5 16:01:31 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Aug 2024 16:01:31 GMT
Subject: RFR: 8335880: More troubleshooting tips around windows space in
 path [v3]
In-Reply-To: <s0G3j--MZD878ZdqW_eB8SgjIGk-qomBW-MTLPQscNA=.ea971d73-84d7-428d-9a8f-4fb43a173814@github.com>
References: <w5TjafnC5QZ8V5Atd3eBEh86c1mdmhXH0D9f25bY7Xs=.528de2c6-0f89-4c58-9c98-16c5fb19e790@github.com>
 <ZixjNaACu8HNkDtzRx9jb4hMvi1VQn7jg3ZT0tbPhuI=.2fe62c2c-9bd0-4dc7-b569-b6496d91b329@github.com>
 <aQ50p44tUN9XA6Ps2tYetlgzulQcETDp0-WXQbPnnuQ=.6f64a2e8-537d-4aca-8bed-c82b93a4ada5@github.com>
 <s0G3j--MZD878ZdqW_eB8SgjIGk-qomBW-MTLPQscNA=.ea971d73-84d7-428d-9a8f-4fb43a173814@github.com>
Message-ID: <ptF1eU0FrKynl0-RNxK_nTma7VvFGWAcCWPhX_hrPw0=.0a4fac67-9c69-4c46-8800-cb7ff9ef1fce@github.com>

On Mon, 5 Aug 2024 15:55:12 GMT, Chen Liang <liach at openjdk.org> wrote:

>> doc/building.md line 1816:
>> 
>>> 1814: The only directories required to have short paths are `Microsoft Visual Studio`
>>> 1815: and `Windows Kits`; the rest of the "contains space" warnings from `configure`
>>> 1816: can be ignored. You can choose any short name; once it is set, `configure`'s
>> 
>> What other directories are reported from configure? 
>> 
>> It does not seem correct to me to say that they can just be ignored -- either the directory is relevant for compilation, and then we need to have it without spaces, or it is not really used and then it should be removed, or made optional.
>> 
>> If  `Microsoft Visual Studio` and  `Windows Kits` are typical path-with-spaces that users can run into, we should perhaps add an additional check to configure for these. In fact, I think what we *should* do is to have configure print this help about `fsutil file setshortname` if it encounters a path with spaces that it cannot turn into a short name. That way, a complete copy/pastable command line can be generated for the user to run.
>
> configure scans `PATH` which may include other spaced directories, such as "Intellij Idea." On a user device, this list can quickly become huge and it would be unrealistic for users to generate short paths for every single one of those directories.
> 
> In fact, the only 2 directories that need short path configuration for configure to work correctly are Microsoft Visual Studio and Windows Kits.

Hm, it feels buggy that it should complain about random entries in the PATH; it should only be an issue if we try to FIXUP a path. I need to look into that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20197#discussion_r1704339319

From jiangli at openjdk.org  Mon Aug  5 17:05:30 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 5 Aug 2024 17:05:30 GMT
Subject: RFR: 8336849: Remove .llvm_addrsig section from JDK/VM static
 libraries (.a files)
In-Reply-To: <ydhogvsR2STcb7WGAQCjAua5l25gEd16Kjh_A0meInA=.92082d43-9187-47e4-b741-2fe059afb1bc@github.com>
References: <ydhogvsR2STcb7WGAQCjAua5l25gEd16Kjh_A0meInA=.92082d43-9187-47e4-b741-2fe059afb1bc@github.com>
Message-ID: <WeNG-IoKttN2gYHv7i3RvCgiCmWh_pDd1FDjZtMy-Y8=.7e4cfb08-e5fa-4a3b-86d4-97bb7e72ba19@github.com>

On Sat, 20 Jul 2024 00:20:19 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that strips the `.llvm_addrsig` section from JDK and hotspot `.a` static libraries when building with clang. Please see https://bugs.openjdk.org/browse/JDK-8336849 description for details.

Thanks for looking into this

> This all seems very odd to me. Where do we set `--icf=safe` to the linker, and why? Why has this not shown up earlier?

As described in earlier comment, `-Wl,--icf=safe` could be specified when linking the launcher executable using `libjvm.a` and etc. That's the #2 step described in the comment. I found following links with some detaills on `--icf=safe`:

- https://nxmnpg.lemoda.net/1/ld.lld (search for `icf`)
- https://github.com/rui314/mold/issues/484 (some useful info, not for lld)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20265#issuecomment-2269520892

From Brian.Stafford at microsoft.com  Mon Aug  5 17:21:19 2024
From: Brian.Stafford at microsoft.com (Brian Stafford)
Date: Mon, 5 Aug 2024 17:21:19 +0000
Subject: Add "Windows aarch64" to Supported Build Platforms
In-Reply-To: <AM9PR02MB677042A3BA6517EDC3041DA093BE2@AM9PR02MB6770.eurprd02.prod.outlook.com>
References: <mailman.20703.1722859899.324.build-dev@openjdk.org>
 <AM9PR02MB677042A3BA6517EDC3041DA093BE2@AM9PR02MB6770.eurprd02.prod.outlook.com>
Message-ID: <DS7PR21MB3407651D065F80B2CBE3C30D86BE2@DS7PR21MB3407.namprd21.prod.outlook.com>

Hi Matthias,

Thank you for your assistance. Here are the details:

Platform: Windows aarch64 
Status: Works correctly (Green star)
OS Type/Vendor: Microsoft Windows Server Datacenter Azure Edition 
OS Version: 2025 
Compiler/Toolchain Type/Vendor: Microsoft Visual Studio
Compiler/Toolchain Version: 2022 (devkit)
Notes / Workarounds: Maintained by Microsoft

Please update the JDK 11, JDK 17, and JDK 21 tables.

Thanks again!

Brian Stafford 
Microsoft




From clanger at openjdk.org  Mon Aug  5 18:00:38 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 5 Aug 2024 18:00:38 GMT
Subject: RFR: 8337819: Update GHA JDKs to 22.0.2
In-Reply-To: <QMsxJZXuAwkWVh0ItD6BKrbkHn0lXm6kWKuCzDgWraI=.16776427-de45-4eed-9fab-6a9fe94c3640@github.com>
References: <QMsxJZXuAwkWVh0ItD6BKrbkHn0lXm6kWKuCzDgWraI=.16776427-de45-4eed-9fab-6a9fe94c3640@github.com>
Message-ID: <pbpCcwBqXVr5NRSMtmfviw8AmcW7w0VhcrRz5RhIVdQ=.ffeac0b1-4b33-40cf-a45c-df3eecb08d5e@github.com>

On Mon, 5 Aug 2024 12:30:25 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Currently, we use JDK 22 GA binaries in Github Actions. Since JDK 22.0.2 is available in the meanwhile, we can use it. I also correct the alphabetical ordering of the macOS platforms.

Thanks for the reviews. All GHA tests went green, so

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20467#issuecomment-2269605240

From clanger at openjdk.org  Mon Aug  5 18:00:39 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 5 Aug 2024 18:00:39 GMT
Subject: Integrated: 8337819: Update GHA JDKs to 22.0.2
In-Reply-To: <QMsxJZXuAwkWVh0ItD6BKrbkHn0lXm6kWKuCzDgWraI=.16776427-de45-4eed-9fab-6a9fe94c3640@github.com>
References: <QMsxJZXuAwkWVh0ItD6BKrbkHn0lXm6kWKuCzDgWraI=.16776427-de45-4eed-9fab-6a9fe94c3640@github.com>
Message-ID: <KmZqpT53F8BO3nBTFzaK4YmTFH_G6nd0A-exIu-YeCg=.cf74ba69-3c77-42d1-8de2-dd457ad1d1dc@github.com>

On Mon, 5 Aug 2024 12:30:25 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Currently, we use JDK 22 GA binaries in Github Actions. Since JDK 22.0.2 is available in the meanwhile, we can use it. I also correct the alphabetical ordering of the macOS platforms.

This pull request has now been integrated.

Changeset: 08f697f4
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/08f697f4fcbcdd912c3aa5f331fbf8212906465f
Stats:     14 lines in 1 file changed: 4 ins; 4 del; 6 mod

8337819: Update GHA JDKs to 22.0.2

Reviewed-by: mbaesken, ihse, shade

-------------

PR: https://git.openjdk.org/jdk/pull/20467

From lmesnik at openjdk.org  Mon Aug  5 18:34:01 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 5 Aug 2024 18:34:01 GMT
Subject: RFR: 8337410: The makefiles should set problemlist and adjust
 timeout basing on the given VM flags [v2]
In-Reply-To: <HSbKJYVYgMPgkPuXFwzDECWYOcfk5d86zp1gNmS5eJM=.38b1c9c5-558c-4584-a3e3-ac23640f7c5c@github.com>
References: <HSbKJYVYgMPgkPuXFwzDECWYOcfk5d86zp1gNmS5eJM=.38b1c9c5-558c-4584-a3e3-ac23640f7c5c@github.com>
Message-ID: <mMI8sps-o9W0wnY2NR9C7srUUcwp9gTKE3m_J9YIV7o=.35b2527f-b080-40fe-89eb-27e75572c689@github.com>

> There jtreg tests have several additional problemlists 
> ProblemList-Xcomp.txt
> ProblemList-generational-zgc.txt
> ProblemList-zgc.txt
> Each of them is bound to corresponding execution mode (Xcomp/ZGC) and it makes sense to treat them like standard problemlist when tests are executed with -Xcomp or ZGC enabled.
> Currently, it is needed to set them manually and it is often forgotten. So engineers waste time analyzing known failures.
> 
> Additionally, the **default** timeoutFactor is increased when Xcomp is enabled because of slowness of this mode. 
> 
> The jtreg allows to add the same problemlist twice so it is not needed to update any execution system that set problemlists.
> 
> Later it might makes sens to set 'JTREG_ALL_OPTIONS' by asking java about actually set mode. So it is possible to adjust  options for fastdebug/slowdebug/product modes and/or different options that are set during compilation (saying different default GC).

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  makefile updated.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20430/files
  - new: https://git.openjdk.org/jdk/pull/20430/files/abb61081..447dff3b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20430&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20430&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20430/head:pull/20430

PR: https://git.openjdk.org/jdk/pull/20430

From lmesnik at openjdk.org  Mon Aug  5 18:34:01 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 5 Aug 2024 18:34:01 GMT
Subject: RFR: 8337410: The makefiles should set problemlist and adjust
 timeout basing on the given VM flags [v2]
In-Reply-To: <UOtShMmbN0JiqogWzwXhCLcGg39O5tHBSX2yHCPMA8c=.d67b18c2-f8bc-4c52-be44-0c219b999afe@github.com>
References: <HSbKJYVYgMPgkPuXFwzDECWYOcfk5d86zp1gNmS5eJM=.38b1c9c5-558c-4584-a3e3-ac23640f7c5c@github.com>
 <BQRW7Bj4yI83B3b5uFn21qoGpU2_lrtO9DuDgHgoFKQ=.675377d3-8713-412d-a2c7-cdcbcd38764b@github.com>
 <UOtShMmbN0JiqogWzwXhCLcGg39O5tHBSX2yHCPMA8c=.d67b18c2-f8bc-4c52-be44-0c219b999afe@github.com>
Message-ID: <1nHPex8xhWKzslVA-V13rBJq3ybyIN9cYachacb13Kw=.3d56d01f-5f92-4dc0-8d8d-53f963589081@github.com>

On Mon, 5 Aug 2024 15:49:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/RunTests.gmk line 845:
>> 
>>> 843:   ifneq ($$(findstring -Xcomp, $$(JTREG_ALL_OPTIONS)), )
>>> 844:     JTREG_AUTO_PROBLEM_LISTS := $$(JTREG_AUTO_PROBLEM_LISTS) ProblemList-Xcomp.txt
>>> 845:     JTREG_AUTO_TIMEOUT_FACTOR ?= 10
>> 
>> Since you assign this to be 4 a couple of lines up, this code will never do anything.
>
> Did you test that this patch works as intended?

Thanks for catching.
Yes, the problem is that our system always set timeout factor. So now I also run manual testing using make to verify that correct factor is used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20430#discussion_r1704491943

From lmesnik at openjdk.org  Mon Aug  5 18:39:38 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 5 Aug 2024 18:39:38 GMT
Subject: RFR: 8337410: The makefiles should set problemlist and adjust
 timeout basing on the given VM flags [v2]
In-Reply-To: <BQRW7Bj4yI83B3b5uFn21qoGpU2_lrtO9DuDgHgoFKQ=.675377d3-8713-412d-a2c7-cdcbcd38764b@github.com>
References: <HSbKJYVYgMPgkPuXFwzDECWYOcfk5d86zp1gNmS5eJM=.38b1c9c5-558c-4584-a3e3-ac23640f7c5c@github.com>
 <BQRW7Bj4yI83B3b5uFn21qoGpU2_lrtO9DuDgHgoFKQ=.675377d3-8713-412d-a2c7-cdcbcd38764b@github.com>
Message-ID: <2jUfjL9aHodk1v9hBVJUxPTpzPbwHfJNPa73YiMeFWY=.cfa0b527-e9a2-454a-b70f-61d7e4fa2894@github.com>

On Mon, 5 Aug 2024 15:51:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   makefile updated.
>
> make/RunTests.gmk line 849:
> 
>> 847: 
>> 848:   ifneq ($$(findstring -XX:+UseZGC, $$(JTREG_ALL_OPTIONS)), )
>> 849:     ifneq ($$(findstring -XX:-ZGenerational, $$(JTREG_ALL_OPTIONS)), )
> 
> Is this the only way that zgc can be run in a non-generational mode? I understand the idea to automatically pick the right set of problem list files, I just want to make sure it is robust.

Yes, I checked that  -XX:+UseZGC -XX:-ZGenerational and didn't find any other way to enable this mode.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20430#discussion_r1704497638

From lucy at openjdk.org  Mon Aug  5 21:57:30 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Mon, 5 Aug 2024 21:57:30 GMT
Subject: RFR: 8336498: [macos] [build]: install-file macro may run into
 permission denied error
In-Reply-To: <7Ys4xNKOA1GMnrogmfUX2-pa2igFoA4kOTEQN6xFi0I=.40e466cd-bd79-4d31-8348-4547a2b9ac3a@github.com>
References: <dMqnljHWGtietpR7M7V0gcVxSb4gidHXTE2qJ0xVe5Y=.576e9b23-0345-425c-a106-d4ed938d5015@github.com>
 <7Ys4xNKOA1GMnrogmfUX2-pa2igFoA4kOTEQN6xFi0I=.40e466cd-bd79-4d31-8348-4547a2b9ac3a@github.com>
Message-ID: <BsNKybqm3wejZ3y8Av5oiGHgkPI3tC7miZTbOXyCq3k=.251c5ba8-9eba-4472-8988-30abaa1fce18@github.com>

On Mon, 5 Aug 2024 15:25:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Hi, I'm back from vacation now.

Looks like we are taking turns. Now I'm on vacation. Thorough analysis of why the issue pops up occasionally will have to wait until I'm back (Aug 19th). I have no specific idea in which direction I should start my search, though. It might be an influence from the environment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20203#issuecomment-2269987015

From mli at openjdk.org  Tue Aug  6 06:54:39 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 6 Aug 2024 06:54:39 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1
In-Reply-To: <kkbgtk_UoigBgKFpQE13XMfXZF3jTSt88I-hyuT8G24=.6016aa8a-7776-4ec7-8705-6ba70e270960@github.com>
References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com>
 <UV5_X8MTcsU2dYG5j18RuPD9sWHNECZ2EB3VKvAq9K0=.f63059a0-a06f-4598-85b9-7fc204fff9e7@github.com>
 <kkbgtk_UoigBgKFpQE13XMfXZF3jTSt88I-hyuT8G24=.6016aa8a-7776-4ec7-8705-6ba70e270960@github.com>
Message-ID: <Afk_YgUw-NoQ-7vJgpQq6IwlWqLyGu95ruIaeyWsEQc=.12495cb5-504f-48b1-9796-25d91a388896@github.com>

On Thu, 27 Jun 2024 21:59:30 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> In case you need it and avoid to generate yourself, I've generated sleef inline header of 3.6.1 for riscv, it's at https://github.com/openjdk/jdk/pull/18605/commits/c279a3c290554892939267d9ebe88198988d31a4
>
> @Hamlin-Li I have generated the header files (two aarch64 and the new one for riscv64) using SLEEF 3.6.1. Please make sure they match your expectations!

Hi @vidmik @theRealAph ,
Just a kindly reminder, could you please bring up the topic (about integrating 3rd party source into jdk, mentioned in [1](https://github.com/openjdk/jdk/pull/18605#issuecomment-2214663777), [2](https://github.com/openjdk/jdk/pull/18605#issuecomment-2230581736)) on workshop or summit? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2270516320

From ihse at openjdk.org  Tue Aug  6 13:15:32 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Aug 2024 13:15:32 GMT
Subject: RFR: 8336498: [macos] [build]: install-file macro may run into
 permission denied error
In-Reply-To: <dMqnljHWGtietpR7M7V0gcVxSb4gidHXTE2qJ0xVe5Y=.576e9b23-0345-425c-a106-d4ed938d5015@github.com>
References: <dMqnljHWGtietpR7M7V0gcVxSb4gidHXTE2qJ0xVe5Y=.576e9b23-0345-425c-a106-d4ed938d5015@github.com>
Message-ID: <iltxmzvr6KNYnhLw-idPzR61QiglK-aqniedRHD6Fk4=.ce9f5b58-0710-4934-a2ea-b0172f77f084@github.com>

On Tue, 16 Jul 2024 20:50:32 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> On MacOS, files may have extended attributes attached. These attributes are copied together with the files. To prevent issues during further processing, the extended attributes of the copies must be removed. This action was implemented as solution of an older bug.
> 
> The solution is incomplete because it does not handle files with read-only permissions correctly. Without write permission, matter cannot remove the extended attributes. The action is rejected with a "permission denied" error.
> 
> The issue is present in all releases. I reproduced it in 11, 17, ... 23, head
> 
> The solution is to "chmod u+w" only those files which need to have their extended attributes removed.
> 
> Backport note: in releases prior to jdk23, the change needs to go into file MakeBase.gmk.
> 
> Testing @SAP completed without any related issues.

Enjoy your vacation! ? 

I'd suggest starting by checking all files for extended attributes and their permissions (like `ls -lr > perms.txt` on the build directory, save this file and compare it from run to run).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20203#issuecomment-2271263324

From ihse at openjdk.org  Tue Aug  6 13:16:33 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Aug 2024 13:16:33 GMT
Subject: RFR: 8337410: The makefiles should set problemlist and adjust
 timeout basing on the given VM flags [v2]
In-Reply-To: <2jUfjL9aHodk1v9hBVJUxPTpzPbwHfJNPa73YiMeFWY=.cfa0b527-e9a2-454a-b70f-61d7e4fa2894@github.com>
References: <HSbKJYVYgMPgkPuXFwzDECWYOcfk5d86zp1gNmS5eJM=.38b1c9c5-558c-4584-a3e3-ac23640f7c5c@github.com>
 <BQRW7Bj4yI83B3b5uFn21qoGpU2_lrtO9DuDgHgoFKQ=.675377d3-8713-412d-a2c7-cdcbcd38764b@github.com>
 <2jUfjL9aHodk1v9hBVJUxPTpzPbwHfJNPa73YiMeFWY=.cfa0b527-e9a2-454a-b70f-61d7e4fa2894@github.com>
Message-ID: <GumWhpdJtcDTtPHMaEZHvOuhYe0fSguph_sSsCHvZIw=.42372629-b996-4f0f-b30d-a737592b5d2e@github.com>

On Mon, 5 Aug 2024 18:37:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> make/RunTests.gmk line 849:
>> 
>>> 847: 
>>> 848:   ifneq ($$(findstring -XX:+UseZGC, $$(JTREG_ALL_OPTIONS)), )
>>> 849:     ifneq ($$(findstring -XX:-ZGenerational, $$(JTREG_ALL_OPTIONS)), )
>> 
>> Is this the only way that zgc can be run in a non-generational mode? I understand the idea to automatically pick the right set of problem list files, I just want to make sure it is robust.
>
> Yes, I checked that  -XX:+UseZGC -XX:-ZGenerational and didn't find any other way to enable this mode.

Great, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20430#discussion_r1705517624

From ihse at openjdk.org  Tue Aug  6 13:28:32 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Aug 2024 13:28:32 GMT
Subject: RFR: 8336849: Remove .llvm_addrsig section from JDK/VM static
 libraries (.a files)
In-Reply-To: <ydhogvsR2STcb7WGAQCjAua5l25gEd16Kjh_A0meInA=.92082d43-9187-47e4-b741-2fe059afb1bc@github.com>
References: <ydhogvsR2STcb7WGAQCjAua5l25gEd16Kjh_A0meInA=.92082d43-9187-47e4-b741-2fe059afb1bc@github.com>
Message-ID: <tD-tZex3MnyT2a5DoE8FZMihDIvXBIpNyq8k7G4x7J0=.39acad8f-4993-4948-871a-73a9c97e6413@github.com>

On Sat, 20 Jul 2024 00:20:19 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that strips the `.llvm_addrsig` section from JDK and hotspot `.a` static libraries when building with clang. Please see https://bugs.openjdk.org/browse/JDK-8336849 description for details.

But why and how do you specify `-Wl,--icf=safe` when building libjvm.a? That is not part of the linker flags in the JDK build mainline. I have not encountered these problems when trying to link with lld. 

Is it something you turn on explicitly in a separate branch? Or is it turned on by default by your lld version?

In any case, the links you provided explains why this approach is catastrophically wrong: 

> Other linkers, notably LLVM lld, supports --icf=safe. It uses .llvm_addrsig sections to identify functions that are safe to merge. Functions that are not mentioned in the section are not address-taken (no one takes its pointer), so they are safe to merge.

If you were to remove these sections, then the linker will believe that all functions are safe to merge. 

Yes, you will "solve" the problem with the error message, but the price you pay is that you get a binary that violates the C++ specification. 

If you really want that, then you should pass `--icf=all` to the linker, and then it will stop caring about  the `.llvm_addrsig` sections.

But from reading the links you sent, the safe and sound approach seems to be to send `--icf=none` to lld when it should operate on a partially linked (ld -r) .o file.

In any case, heavyhandedly cutting out sections like this seem utterly wrong.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20265#issuecomment-2271291483

From ihse at openjdk.org  Tue Aug  6 15:36:32 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Aug 2024 15:36:32 GMT
Subject: RFR: 8337410: The makefiles should set problemlist and adjust
 timeout basing on the given VM flags [v2]
In-Reply-To: <mMI8sps-o9W0wnY2NR9C7srUUcwp9gTKE3m_J9YIV7o=.35b2527f-b080-40fe-89eb-27e75572c689@github.com>
References: <HSbKJYVYgMPgkPuXFwzDECWYOcfk5d86zp1gNmS5eJM=.38b1c9c5-558c-4584-a3e3-ac23640f7c5c@github.com>
 <mMI8sps-o9W0wnY2NR9C7srUUcwp9gTKE3m_J9YIV7o=.35b2527f-b080-40fe-89eb-27e75572c689@github.com>
Message-ID: <ht0-6qXk6-nEc-BMMO-1EU8RUpOdbOUgUpHvgckgw4g=.7e59157e-3e7e-45dc-91c3-f4364187309f@github.com>

On Mon, 5 Aug 2024 18:34:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> There jtreg tests have several additional problemlists 
>> ProblemList-Xcomp.txt
>> ProblemList-generational-zgc.txt
>> ProblemList-zgc.txt
>> Each of them is bound to corresponding execution mode (Xcomp/ZGC) and it makes sense to treat them like standard problemlist when tests are executed with -Xcomp or ZGC enabled.
>> Currently, it is needed to set them manually and it is often forgotten. So engineers waste time analyzing known failures.
>> 
>> Additionally, the **default** timeoutFactor is increased when Xcomp is enabled because of slowness of this mode. 
>> 
>> The jtreg allows to add the same problemlist twice so it is not needed to update any execution system that set problemlists.
>> 
>> Later it might makes sens to set 'JTREG_ALL_OPTIONS' by asking java about actually set mode. So it is possible to adjust  options for fastdebug/slowdebug/product modes and/or different options that are set during compilation (saying different default GC).
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   makefile updated.

This looks good now. Thanks!

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20430#pullrequestreview-2221652406

From magnus.ihse.bursie at oracle.com  Tue Aug  6 16:37:05 2024
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 6 Aug 2024 18:37:05 +0200
Subject: jdk8u: -Wno-regsiter to support newer compilers
In-Reply-To: <CAHNTFmK9nUQ1YqYgD6sRwiAhBru0yCEXO6aSa-XM5ds2BHrOOA@mail.gmail.com>
References: <CAHNTFmK9nUQ1YqYgD6sRwiAhBru0yCEXO6aSa-XM5ds2BHrOOA@mail.gmail.com>
Message-ID: <8e27b2e0-0e1b-4a2e-909b-5db0c0fac582@oracle.com>

Hi Elazar,

I see that you never got any replies here. I suggest that you re-ask 
your question on the jdk8u mailing list instead (cc'd).

/Magnus

On 2024-07-19 16:20, Elazar Leibovich wrote:
> When trying to compile the latest jdk8u on linux I get failures over 
> warnings with the register keywords.
>
> I'm using https://github.com/openjdk/jdk8u-dev.git which seems to be 
> pretty up to date (I'm using master), and last commit is less than two 
> days ago.
>
> This is a workaround I had to use:
> diff --git a/hotspot/make/linux/makefiles/gcc.make 
> b/hotspot/make/linux/makefiles/gcc.make
> index 7dde7f0963..81f156574a 100644
> --- a/hotspot/make/linux/makefiles/gcc.make
> +++ b/hotspot/make/linux/makefiles/gcc.make
> @@ -202,7 +202,7 @@ else
> ?endif
>
> ?# Compiler warnings are treated as errors
> -WARNINGS_ARE_ERRORS = -Werror
> +WARNINGS_ARE_ERRORS = -Werror -Wno-register
>
> But I guess the best solution is to remove the register keywords from 
> the codebase.
>
> How is adoptium?building it? Does it use specific compiler? Is the 
> supported compiler documented anywhere?
>
> FTR using temurin-build repository and scripts, fails for other 
> reasons, and fails even with -D/--podman docker containers.
>
> This patch builds it with centos stream 9 on amd64.
>
> Am I doing something wrong? What's the recommended way of building jdk8?
>
> Thanks,
> Elazar Leibovich

From magnus.ihse.bursie at oracle.com  Tue Aug  6 16:41:01 2024
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 6 Aug 2024 18:41:01 +0200
Subject: Issue cross-compiling idk 8 for powerpc
In-Reply-To: <8EEB3022-4DEC-47F1-8202-40C62A01BB4D@stanford.edu>
References: <8EEB3022-4DEC-47F1-8202-40C62A01BB4D@stanford.edu>
Message-ID: <fc075bd6-7dd9-4043-a032-0a23591bc0b2@oracle.com>

Hi Kurt,

Did you manage to resolve this issue?

/Magnus

On 2024-07-10 23:52, Kurt Stine wrote:
>
> Hi Everyone,
>
> I?m running into an issue when trying to cross-compile the latest 
> jdk8u for powerpc (32 bit).
>
> I am cross-compiling from x86_64 with Azul Zulu JDK 7 as my boot JDK.
>
> Whenever I try and run "bash configure --openjdk-target=powerpc-linux 
> --with-jvm-variants=zero", configure results in the following error:
>
> checking size of int *... 8
>
> configure: The tested number of bits in the target (64) differs from 
> the number of bits expected to be found in the target (32).
>
> configure: I'll retry after setting the platforms compiler target bits 
> flag to -m32
>
> checking size of int *... 0
>
> configure: error: The tested number of bits in the target (0) differs 
> from the number of bits expected to be found in the target (32)
>
> I am using the brotlin glibc 13.2.0 toolchain 
> specifically:https://toolchains.bootlin.com/releases_powerpc-440fp.htmlbut 
> I've confirmed that the error also occurs with standard GCC as well as 
> when using a ppc sysroot.
>
> My full configure.log is here:https://paste.debian.net/1322788/
>
> Any help with this is appreciated.
>
> Thanks,
>
> Kurt Stine
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240806/f93fd3fe/attachment-0001.htm>

From jiangli at openjdk.org  Tue Aug  6 17:10:31 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 6 Aug 2024 17:10:31 GMT
Subject: RFR: 8336849: Remove .llvm_addrsig section from JDK/VM static
 libraries (.a files)
In-Reply-To: <tD-tZex3MnyT2a5DoE8FZMihDIvXBIpNyq8k7G4x7J0=.39acad8f-4993-4948-871a-73a9c97e6413@github.com>
References: <ydhogvsR2STcb7WGAQCjAua5l25gEd16Kjh_A0meInA=.92082d43-9187-47e4-b741-2fe059afb1bc@github.com>
 <tD-tZex3MnyT2a5DoE8FZMihDIvXBIpNyq8k7G4x7J0=.39acad8f-4993-4948-871a-73a9c97e6413@github.com>
Message-ID: <7F8J_fnB5gHmcAHiEkP3SLdG_SqAtHaWXe3BPYPq5Qw=.385c2c86-b824-4fce-a8fd-8dfb03071049@github.com>

On Tue, 6 Aug 2024 13:26:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> But why and how do you specify `-Wl,--icf=safe` when building libjvm.a? That is not part of the linker flags in the JDK build mainline. I have not encountered these problems when trying to link with lld.

No, it's not when **building** `libjvm.a`. It's when linking the final elf executable **using** `libjvm.a` (or `libnet.a`, etc) that's created with `ld -r` or `objcopy`. During the final elf executable linking time, user could include additional desired linker flags, such as  `-Wl,--icf=safe`. That's the case where things can run into trouble.

We don't have control of the linker flags that users might want to use.

> 
> In any case, the links you provided explains why this approach is catastrophically wrong:
> 
> > Other linkers, notably LLVM lld, supports --icf=safe. It uses .llvm_addrsig sections to identify functions that are safe to merge. Functions that are not mentioned in the section are not address-taken (no one takes its pointer), so they are safe to merge.
> 
> If you were to remove these sections, then the linker will believe that all functions are safe to merge.

How did you arrive the conclusion?

According to https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#icfall-and---icfsafe (already linked from the bug description),

"ld.lld --icf=safe uses a special section `.llvm_addrsig` (LLVM address significance table, type SHT_LLVM_ADDRSIG) produced by Clang -faddrsig....If the section is absent, ld.lld is conservative and assumes every section defining a symbol in the table is address significant."

When `.llvm_addrsig` section is removed (not present), my understanding is that the linker would only do conservative identical code folding safely.

See more in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625. 

> 
> If you really want that, then you should pass `--icf=all` to the linker, and then it will stop caring about the `.llvm_addrsig` sections.
> 
> But from reading the links you sent, the safe and sound approach seems to be to send `--icf=none` to lld when it should operate on a partially linked (ld -r) .o file.

`--icf=all` is more aggressive optimization and might not be safe? Also, we don't control how developers would be building the final elf image.

Removing `.llvm_addrsig` is safe. It has the benefit of not restricting specific final linking flags.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20265#issuecomment-2271754139

From elazarl at gmail.com  Tue Aug  6 18:33:02 2024
From: elazarl at gmail.com (Elazar Leibovich)
Date: Tue, 6 Aug 2024 21:33:02 +0300
Subject: jdk8u: -Wno-regsiter to support newer compilers
In-Reply-To: <ec4d8d3c-440f-4dc8-ba5e-e89900603a88@redhat.com>
References: <CAHNTFmK9nUQ1YqYgD6sRwiAhBru0yCEXO6aSa-XM5ds2BHrOOA@mail.gmail.com>
 <8e27b2e0-0e1b-4a2e-909b-5db0c0fac582@oracle.com>
 <ec4d8d3c-440f-4dc8-ba5e-e89900603a88@redhat.com>
Message-ID: <CAHNTFmKDVEwfkELFJViWrG0CyA2Up4Na7ZV26siBKkVAenEazA@mail.gmail.com>

Thanks,
I still fail to understand how JDK8u developers are building the project.
Is there a docker file specifying the build environment? What's the
recommended way of doing that?
Removing the register keyword, plus disabling an overflow warning in a
specific test with pragma did the trick for me, but:
1. I could not get it built in Mac OS X
2. I felt as if I'm paving my own path building it, instead of following
the Yellow Brick Road, which I'm trying to locate.

Thanks again,

On Tue, 6 Aug 2024 at 21:10, Zden?k ?ambersk? <zzambers at redhat.com> wrote:

> Hello,
>
> this is known issue, which should get fixed by JDK-8281096:
> https://github.com/openjdk/jdk8u-dev/pull/357
>
> (see also: https://github.com/openjdk/jdk8u-dev/pull/508)
>
> TLDR:
> Jdk 8 explicitly specifies older c++ version (gnu++98, which not yet
> deprecated
> 'register' keyword), but flags are not propagated to ADLC build due to bug.
> (correct me, if I am wrong)
>
>
> When it comes to Adoptium, I don't know exactly, but I think they are using
> older compiler, which uses older c++ standard by default.
>
> On 06. 08. 24 18:37, Magnus Ihse Bursie wrote:
> > Hi Elazar,
> >
> > I see that you never got any replies here. I suggest that you re-ask
> > your question on the jdk8u mailing list instead (cc'd).
> >
> > /Magnus
> >
> > On 2024-07-19 16:20, Elazar Leibovich wrote:
> >> When trying to compile the latest jdk8u on linux I get failures over
> >> warnings with the register keywords.
> >>
> >> I'm using https://github.com/openjdk/jdk8u-dev.git which seems to be
> >> pretty up to date (I'm using master), and last commit is less than
> >> two days ago.
> >>
> >> This is a workaround I had to use:
> >> diff --git a/hotspot/make/linux/makefiles/gcc.make
> >> b/hotspot/make/linux/makefiles/gcc.make
> >> index 7dde7f0963..81f156574a 100644
> >> --- a/hotspot/make/linux/makefiles/gcc.make
> >> +++ b/hotspot/make/linux/makefiles/gcc.make
> >> @@ -202,7 +202,7 @@ else
> >>  endif
> >>
> >>  # Compiler warnings are treated as errors
> >> -WARNINGS_ARE_ERRORS = -Werror
> >> +WARNINGS_ARE_ERRORS = -Werror -Wno-register
> >>
> >> But I guess the best solution is to remove the register keywords from
> >> the codebase.
> >>
> >> How is adoptium building it? Does it use specific compiler? Is the
> >> supported compiler documented anywhere?
> >>
> >> FTR using temurin-build repository and scripts, fails for other
> >> reasons, and fails even with -D/--podman docker containers.
> >>
> >> This patch builds it with centos stream 9 on amd64.
> >>
> >> Am I doing something wrong? What's the recommended way of building jdk8?
> >>
> >> Thanks,
> >> Elazar Leibovich
> >
>
> --
> Zden?k ?ambersk?
> OpenJDK QE
> Red Hat
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240806/d212bc41/attachment.htm>

From magnus.ihse.bursie at oracle.com  Tue Aug  6 18:37:20 2024
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 6 Aug 2024 20:37:20 +0200
Subject: jdk8u: -Wno-regsiter to support newer compilers
In-Reply-To: <CAHNTFmKDVEwfkELFJViWrG0CyA2Up4Na7ZV26siBKkVAenEazA@mail.gmail.com>
References: <CAHNTFmK9nUQ1YqYgD6sRwiAhBru0yCEXO6aSa-XM5ds2BHrOOA@mail.gmail.com>
 <8e27b2e0-0e1b-4a2e-909b-5db0c0fac582@oracle.com>
 <ec4d8d3c-440f-4dc8-ba5e-e89900603a88@redhat.com>
 <CAHNTFmKDVEwfkELFJViWrG0CyA2Up4Na7ZV26siBKkVAenEazA@mail.gmail.com>
Message-ID: <c00f4bd4-a59d-4970-8089-455fbe1700ca@oracle.com>

On 2024-08-06 20:33, Elazar Leibovich wrote:

> Thanks,
> I still fail to understand how JDK8u developers are building the project.

Setting up a build environment for jdk8 is unfortunately not a trivial 
task. The build readme can be of some use: 
https://github.com/openjdk/jdk8u-dev/blob/master/doc/building.md. The 
build system has gone through a complete overhaul in later versions, so 
if you were to build the mainline JDK it would be a much smoother 
experience. After all, JDK 8 was released 10 years ago, and much has 
happened since then.

/Magnus



> Is there a docker file specifying the build environment? What's the 
> recommended way of doing that?
> Removing the register keyword, plus disabling an overflow warning in a 
> specific test with pragma did the?trick for me, but:
> 1. I could not get it built in Mac OS X
> 2. I felt as if I'm paving my own path building it, instead of 
> following the Yellow Brick Road, which I'm trying to locate.
>
> Thanks again,
>
> On Tue, 6 Aug 2024 at 21:10, Zden?k ?ambersk? <zzambers at redhat.com> wrote:
>
>     Hello,
>
>     this is known issue, which should get fixed by JDK-8281096:
>     https://github.com/openjdk/jdk8u-dev/pull/357
>
>     (see also: https://github.com/openjdk/jdk8u-dev/pull/508)
>
>     TLDR:
>     Jdk 8 explicitly specifies older c++ version (gnu++98, which not yet
>     deprecated
>     'register' keyword), but flags are not propagated to ADLC build
>     due to bug.
>     (correct me, if I am wrong)
>
>
>     When it comes to Adoptium, I don't know exactly, but I think they
>     are using
>     older compiler, which uses older c++ standard by default.
>
>     On 06. 08. 24 18:37, Magnus Ihse Bursie wrote:
>     > Hi Elazar,
>     >
>     > I see that you never got any replies here. I suggest that you
>     re-ask
>     > your question on the jdk8u mailing list instead (cc'd).
>     >
>     > /Magnus
>     >
>     > On 2024-07-19 16:20, Elazar Leibovich wrote:
>     >> When trying to compile the latest jdk8u on linux I get failures
>     over
>     >> warnings with the register keywords.
>     >>
>     >> I'm using https://github.com/openjdk/jdk8u-dev.git which seems
>     to be
>     >> pretty up to date (I'm using master), and last commit is less than
>     >> two days ago.
>     >>
>     >> This is a workaround I had to use:
>     >> diff --git a/hotspot/make/linux/makefiles/gcc.make
>     >> b/hotspot/make/linux/makefiles/gcc.make
>     >> index 7dde7f0963..81f156574a 100644
>     >> --- a/hotspot/make/linux/makefiles/gcc.make
>     >> +++ b/hotspot/make/linux/makefiles/gcc.make
>     >> @@ -202,7 +202,7 @@ else
>     >> ?endif
>     >>
>     >> ?# Compiler warnings are treated as errors
>     >> -WARNINGS_ARE_ERRORS = -Werror
>     >> +WARNINGS_ARE_ERRORS = -Werror -Wno-register
>     >>
>     >> But I guess the best solution is to remove the register
>     keywords from
>     >> the codebase.
>     >>
>     >> How is adoptium?building it? Does it use specific compiler? Is the
>     >> supported compiler documented anywhere?
>     >>
>     >> FTR using temurin-build repository and scripts, fails for other
>     >> reasons, and fails even with -D/--podman docker containers.
>     >>
>     >> This patch builds it with centos stream 9 on amd64.
>     >>
>     >> Am I doing something wrong? What's the recommended way of
>     building jdk8?
>     >>
>     >> Thanks,
>     >> Elazar Leibovich
>     >
>
>     -- 
>     Zden?k ?ambersk?
>     OpenJDK QE
>     Red Hat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240806/bb8abdd4/attachment-0001.htm>

From elazarl at gmail.com  Tue Aug  6 18:42:52 2024
From: elazarl at gmail.com (Elazar Leibovich)
Date: Tue, 6 Aug 2024 21:42:52 +0300
Subject: jdk8u: -Wno-regsiter to support newer compilers
In-Reply-To: <c00f4bd4-a59d-4970-8089-455fbe1700ca@oracle.com>
References: <CAHNTFmK9nUQ1YqYgD6sRwiAhBru0yCEXO6aSa-XM5ds2BHrOOA@mail.gmail.com>
 <8e27b2e0-0e1b-4a2e-909b-5db0c0fac582@oracle.com>
 <ec4d8d3c-440f-4dc8-ba5e-e89900603a88@redhat.com>
 <CAHNTFmKDVEwfkELFJViWrG0CyA2Up4Na7ZV26siBKkVAenEazA@mail.gmail.com>
 <c00f4bd4-a59d-4970-8089-455fbe1700ca@oracle.com>
Message-ID: <CAHNTFmJsc+KyeDsMPrNa43fw2oe6AQd3yDPNmdk-a5Jkt01ciw@mail.gmail.com>

Thanks,
I did follow the readme, but could not find any commentary about the build
environment or the required compilers.
Even less information was on Mac OS X, where the autoconf files seems not
to be updated, and as a result arm was chosen instead of aarch64.

If you can point me to a specific section in the documentation specifying,
say, a list of known good compilers, I'll be grateful.

On Tue, 6 Aug 2024 at 21:37, Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> On 2024-08-06 20:33, Elazar Leibovich wrote:
>
> Thanks,
> I still fail to understand how JDK8u developers are building the project.
>
> Setting up a build environment for jdk8 is unfortunately not a trivial
> task. The build readme can be of some use:
> https://github.com/openjdk/jdk8u-dev/blob/master/doc/building.md. The
> build system has gone through a complete overhaul in later versions, so if
> you were to build the mainline JDK it would be a much smoother experience.
> After all, JDK 8 was released 10 years ago, and much has happened since
> then.
>
> /Magnus
>
>
>
> Is there a docker file specifying the build environment? What's the
> recommended way of doing that?
> Removing the register keyword, plus disabling an overflow warning in a
> specific test with pragma did the trick for me, but:
> 1. I could not get it built in Mac OS X
> 2. I felt as if I'm paving my own path building it, instead of following
> the Yellow Brick Road, which I'm trying to locate.
>
> Thanks again,
>
> On Tue, 6 Aug 2024 at 21:10, Zden?k ?ambersk? <zzambers at redhat.com> wrote:
>
>> Hello,
>>
>> this is known issue, which should get fixed by JDK-8281096:
>> https://github.com/openjdk/jdk8u-dev/pull/357
>>
>> (see also: https://github.com/openjdk/jdk8u-dev/pull/508)
>>
>> TLDR:
>> Jdk 8 explicitly specifies older c++ version (gnu++98, which not yet
>> deprecated
>> 'register' keyword), but flags are not propagated to ADLC build due to
>> bug.
>> (correct me, if I am wrong)
>>
>>
>> When it comes to Adoptium, I don't know exactly, but I think they are
>> using
>> older compiler, which uses older c++ standard by default.
>>
>> On 06. 08. 24 18:37, Magnus Ihse Bursie wrote:
>> > Hi Elazar,
>> >
>> > I see that you never got any replies here. I suggest that you re-ask
>> > your question on the jdk8u mailing list instead (cc'd).
>> >
>> > /Magnus
>> >
>> > On 2024-07-19 16:20, Elazar Leibovich wrote:
>> >> When trying to compile the latest jdk8u on linux I get failures over
>> >> warnings with the register keywords.
>> >>
>> >> I'm using https://github.com/openjdk/jdk8u-dev.git which seems to be
>> >> pretty up to date (I'm using master), and last commit is less than
>> >> two days ago.
>> >>
>> >> This is a workaround I had to use:
>> >> diff --git a/hotspot/make/linux/makefiles/gcc.make
>> >> b/hotspot/make/linux/makefiles/gcc.make
>> >> index 7dde7f0963..81f156574a 100644
>> >> --- a/hotspot/make/linux/makefiles/gcc.make
>> >> +++ b/hotspot/make/linux/makefiles/gcc.make
>> >> @@ -202,7 +202,7 @@ else
>> >>  endif
>> >>
>> >>  # Compiler warnings are treated as errors
>> >> -WARNINGS_ARE_ERRORS = -Werror
>> >> +WARNINGS_ARE_ERRORS = -Werror -Wno-register
>> >>
>> >> But I guess the best solution is to remove the register keywords from
>> >> the codebase.
>> >>
>> >> How is adoptium building it? Does it use specific compiler? Is the
>> >> supported compiler documented anywhere?
>> >>
>> >> FTR using temurin-build repository and scripts, fails for other
>> >> reasons, and fails even with -D/--podman docker containers.
>> >>
>> >> This patch builds it with centos stream 9 on amd64.
>> >>
>> >> Am I doing something wrong? What's the recommended way of building
>> jdk8?
>> >>
>> >> Thanks,
>> >> Elazar Leibovich
>> >
>>
>> --
>> Zden?k ?ambersk?
>> OpenJDK QE
>> Red Hat
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240806/777a1f01/attachment.htm>

From ihse at openjdk.org  Tue Aug  6 19:01:34 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Aug 2024 19:01:34 GMT
Subject: RFR: 8336849: Remove .llvm_addrsig section from JDK/VM static
 libraries (.a files)
In-Reply-To: <7F8J_fnB5gHmcAHiEkP3SLdG_SqAtHaWXe3BPYPq5Qw=.385c2c86-b824-4fce-a8fd-8dfb03071049@github.com>
References: <ydhogvsR2STcb7WGAQCjAua5l25gEd16Kjh_A0meInA=.92082d43-9187-47e4-b741-2fe059afb1bc@github.com>
 <tD-tZex3MnyT2a5DoE8FZMihDIvXBIpNyq8k7G4x7J0=.39acad8f-4993-4948-871a-73a9c97e6413@github.com>
 <7F8J_fnB5gHmcAHiEkP3SLdG_SqAtHaWXe3BPYPq5Qw=.385c2c86-b824-4fce-a8fd-8dfb03071049@github.com>
Message-ID: <-p4HwMMOjXyfDt0ZONQQCIZkIENX1-dOxD4V9tCWqu8=.7e0fad31-77c4-4e78-b343-85027c37ca21@github.com>

On Tue, 6 Aug 2024 17:07:55 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> No, it's not when building libjvm.a. It's when linking the final elf executable using libjvm.a (or libnet.a, etc) that's created with ld -r or objcopy. During the final elf executable linking time, user could include additional desired linker flags, such as -Wl,--icf=safe. That's the case where things can run into trouble.

Ok, I see. The static library that we generate is not usable by a later invocation of lld.

Just out of curiousity, is running objcopy required to reproduce this problem, or is it enough to run lld first with -r and then for linking the static library into an executable? If it is the latter, I think it is a really sorry implementation in lld, if they can't even use their own output. (If objcopy messes up the file, then it's a different story -- I can't really blame them if that would happen).

> We don't have control of the linker flags that users might want to use.

Well, that is indeed correct, but we can tell them that there is a know problem with lld that it cannot link these binaries with --icf=safe. (At this point I am primarily treating this as an lld bug/limitation.)

>>    If you were to remove these sections, then the linker will believe that all functions are safe to merge.

> How did you arrive the conclusion?

I quoted the part from one of the links you sent:  "Functions that are not mentioned in the section are not address-taken (no one takes its pointer), so they are safe to merge."

Prior to reading this PR, I did not know about icf, so I have no other knowledge about how it works. I interpreted the paragraph above as it would be risky to remove this section (given that it might have contained relevant content before it was mangled by ld -r/objcopy), since it would apply that there were no functions that needed preserving.

> When .llvm_addrsig section is removed (not present), my understanding is that the linker would only do conservative identical code folding safely.

Well, my contrary question is then: How did you arrive at this conclusion? I'd like to get some definite, authoritative documentation on how icf works in the presence of a mangled .llvm_addrsig section vs an intentionally removed .llvm_addrsig section.

As I see it, unless there is documentation stating that removing the .llvm_addrsig section is safe to combine with --icf=safe, then the only reliable option is to not use icf at all. Reasonably, lld should fall back to that behavior if it is missing  .llvm_addrsig sections, but apparently it chooses to fail instead. 

I'm not sure what this "conservative" icf you talk about means. My understanding, after trying to read the docs now, is that there is only three modes that ICF works in: safe, all or none. If this understanding is correct, then you only have two options if lld can't do safe icf: namely all or none. And all seems to be a dangerous choice, since it can lead to UB. 

> Removing .llvm_addrsig is safe. 

You keep saying this. Please show me some documentation that supports this claim.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20265#issuecomment-2271945258

From dcubed at openjdk.org  Tue Aug  6 22:11:49 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 6 Aug 2024 22:11:49 GMT
Subject: [jdk23] Integrated: 8337831: Remove EA from the JDK 23 version string
 with first RC promotion
Message-ID: <yZ4Nm0slUrKmX5NK2auyv2cANaCAo_oRDZN46HI1w3E=.68d690ba-b30a-4ff9-993c-e86f7497d935@github.com>

A trivial fix to remove EA from the JDK 23 version string with first RC promotion.

-------------

Commit messages:
 - 8337831: Remove EA from the JDK 23 version string with first RC promotion

Changes: https://git.openjdk.org/jdk/pull/20481/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20481&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337831
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20481.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20481/head:pull/20481

PR: https://git.openjdk.org/jdk/pull/20481

From dholmes at openjdk.org  Tue Aug  6 22:11:49 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Aug 2024 22:11:49 GMT
Subject: [jdk23] Integrated: 8337831: Remove EA from the JDK 23 version
 string with first RC promotion
In-Reply-To: <yZ4Nm0slUrKmX5NK2auyv2cANaCAo_oRDZN46HI1w3E=.68d690ba-b30a-4ff9-993c-e86f7497d935@github.com>
References: <yZ4Nm0slUrKmX5NK2auyv2cANaCAo_oRDZN46HI1w3E=.68d690ba-b30a-4ff9-993c-e86f7497d935@github.com>
Message-ID: <Z6Y5bHUsCCnroDm-7DCBXbafRYScl9xciQYByamgYg0=.aad2ab59-484c-47ee-b3af-167f2aabb8af@github.com>

On Tue, 6 Aug 2024 22:02:33 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to remove EA from the JDK 23 version string with first RC promotion.

Good

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20481#pullrequestreview-2222314019

From dcubed at openjdk.org  Tue Aug  6 22:11:49 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 6 Aug 2024 22:11:49 GMT
Subject: [jdk23] Integrated: 8337831: Remove EA from the JDK 23 version
 string with first RC promotion
In-Reply-To: <Z6Y5bHUsCCnroDm-7DCBXbafRYScl9xciQYByamgYg0=.aad2ab59-484c-47ee-b3af-167f2aabb8af@github.com>
References: <yZ4Nm0slUrKmX5NK2auyv2cANaCAo_oRDZN46HI1w3E=.68d690ba-b30a-4ff9-993c-e86f7497d935@github.com>
 <Z6Y5bHUsCCnroDm-7DCBXbafRYScl9xciQYByamgYg0=.aad2ab59-484c-47ee-b3af-167f2aabb8af@github.com>
Message-ID: <eiOsIKmIKP2m8m8aTk17L_srU1O2md4wI90l61STkzw=.f98e5bd1-2d11-438f-a294-8af5861f904c@github.com>

On Tue, 6 Aug 2024 22:04:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> A trivial fix to remove EA from the JDK 23 version string with first RC promotion.
>
> Good

@dholmes-ora - Thanks for the lightning fast review! I just changed the bug from
confidential so we'll see when the bot wakes up...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20481#issuecomment-2272231452

From dcubed at openjdk.org  Tue Aug  6 22:11:49 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 6 Aug 2024 22:11:49 GMT
Subject: [jdk23] Integrated: 8337831: Remove EA from the JDK 23 version string
 with first RC promotion
In-Reply-To: <yZ4Nm0slUrKmX5NK2auyv2cANaCAo_oRDZN46HI1w3E=.68d690ba-b30a-4ff9-993c-e86f7497d935@github.com>
References: <yZ4Nm0slUrKmX5NK2auyv2cANaCAo_oRDZN46HI1w3E=.68d690ba-b30a-4ff9-993c-e86f7497d935@github.com>
Message-ID: <xQdD7NhHc3SmviIyje4hxv14cAK3EeNa42mVUDtimVM=.65036584-4e0a-4522-bb07-71190a6fe14b@github.com>

On Tue, 6 Aug 2024 22:02:33 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to remove EA from the JDK 23 version string with first RC promotion.

This pull request has now been integrated.

Changeset: 6f582f4e
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6f582f4ee3b79f331edc847706f9503a45c81461
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8337831: Remove EA from the JDK 23 version string with first RC promotion

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/20481

From jiangli at openjdk.org  Tue Aug  6 23:44:31 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 6 Aug 2024 23:44:31 GMT
Subject: RFR: 8336849: Remove .llvm_addrsig section from JDK/VM static
 libraries (.a files)
In-Reply-To: <-p4HwMMOjXyfDt0ZONQQCIZkIENX1-dOxD4V9tCWqu8=.7e0fad31-77c4-4e78-b343-85027c37ca21@github.com>
References: <ydhogvsR2STcb7WGAQCjAua5l25gEd16Kjh_A0meInA=.92082d43-9187-47e4-b741-2fe059afb1bc@github.com>
 <tD-tZex3MnyT2a5DoE8FZMihDIvXBIpNyq8k7G4x7J0=.39acad8f-4993-4948-871a-73a9c97e6413@github.com>
 <7F8J_fnB5gHmcAHiEkP3SLdG_SqAtHaWXe3BPYPq5Qw=.385c2c86-b824-4fce-a8fd-8dfb03071049@github.com>
 <-p4HwMMOjXyfDt0ZONQQCIZkIENX1-dOxD4V9tCWqu8=.7e0fad31-77c4-4e78-b343-85027c37ca21@github.com>
Message-ID: <AFJCdmB6Zc-6Y-s-6A_ocqoFB9JPLgLHzJhtxlC37lI=.42a4d878-f4db-4a29-87a2-b942bf4a1669@github.com>

On Tue, 6 Aug 2024 18:58:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > No, it's not when building libjvm.a. It's when linking the final elf executable using libjvm.a (or libnet.a, etc) that's created with ld -r or objcopy. During the final elf executable linking time, user could include additional desired linker flags, such as -Wl,--icf=safe. That's the case where things can run into trouble.
> 
> Ok, I see. The static library that we generate is not usable by a later invocation of lld.

Yes, that's the problem.

> 
> Just out of curiousity, is running objcopy required to reproduce this problem, or is it enough to run lld first with -r and then for linking the static library into an executable? If it is the latter, I think it is a really sorry implementation in lld, if they can't even use their own output. (If objcopy messes up the file, then it's a different story -- I can't really blame them if that would happen).

Either `objcopy` **or** `ld -r` could invalidate the `.llvm_addrsig` according to the linked blog (which has the nice description of the related details).

While searching for additional information today to help make things more clear for our discussion in this thread, I just found `strip` could also invalidate the section. https://sourceware.org/bugzilla/show_bug.cgi?id=23817 mentions about the issue with `strip`. Also, according to the comments in https://sourceware.org/bugzilla/show_bug.cgi?id=23817, it seems tools might not be updated to address the corrupted `.llvm_addrsig` section.

> 
> > We don't have control of the linker flags that users might want to use.
> 
> Well, that is indeed correct, but we can tell them that there is a know problem with lld that it cannot link these binaries with --icf=safe. (At this point I am primarily treating this as an lld bug/limitation.)
> 
> > > If you were to remove these sections, then the linker will believe that all functions are safe to merge.
> 
> > How did you arrive the conclusion?
> 
> I quoted the part from one of the links you sent: "Functions that are not mentioned in the section are not address-taken (no one takes its pointer), so they are safe to merge."

https://llvm.org/docs/Extensions.html#sht-llvm-addrsig-section-address-significance-table probably (found today) is more clear:

"Any sections referred to by symbols that are not marked as address-significant in any object file may be safely merged ..."

So if symbols are treated as "address-significant", then referring object file may not be safely merged. See more related comments below.

> 
> Prior to reading this PR, I did not know about icf, so I have no other knowledge about how it works. I interpreted the paragraph above as it would be risky to remove this section (given that it might have contained relevant content before it was mangled by ld -r/objcopy), since it would apply that there were no functions that needed preserving.
> 
> > When .llvm_addrsig section is removed (not present), my understanding is that the linker would only do conservative identical code folding safely.
> 
> Well, my contrary question is then: How did you arrive at this conclusion? I'd like to get some definite, authoritative documentation on how icf works in the presence of a mangled .llvm_addrsig section vs an intentionally removed .llvm_addrsig section.

My understanding is based on the descriptions in the linked blog, specifically the part quoted from the blog in my pervious comment (quoted below again to be more clear):

"ld.lld --icf=safe uses a special section .llvm_addrsig (LLVM address significance table, type SHT_LLVM_ADDRSIG) produced by Clang -faddrsig....If the section is absent, ld.lld is conservative and assumes every section defining a symbol in the table is address significant."

> 
> As I see it, unless there is documentation stating that removing the .llvm_addrsig section is safe to combine with --icf=safe, then the only reliable option is to not use icf at all. Reasonably, lld should fall back to that behavior if it is missing .llvm_addrsig sections, but apparently it chooses to fail instead.
> 
> I'm not sure what this "conservative" icf you talk about means. My understanding, after trying to read the docs now, is that there is only three modes that ICF works in: safe, all or none. If this understanding is correct, then you only have two options if lld can't do safe icf: namely all or none. And all seems to be a dangerous choice, since it can lead to UB.
> 
> > Removing .llvm_addrsig is safe.
> 
> You keep saying this. Please show me some documentation that supports this claim.

Unfortunately, the blog article was the most comprehensive summary about the issue with the corrupted  .llvm_addrsig that I was able to find. I could not find any official documentation about removing the `.llvm_addrsig` section. In this case, I trust the expert. Additionally,  the comment in https://lists.llvm.org/pipermail/llvm-dev/2018-May/123528.html (I found today) matches with the blog info, specifically:

"but now I see you assume all symbols are address-significant if there's no address-significance table in the file"

Anyway, we can't **safely** keep the corrupted `.llvm_addrsig` section in `libjvm.a` and etc.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20265#issuecomment-2272346203

From david.holmes at oracle.com  Wed Aug  7 01:10:09 2024
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 7 Aug 2024 11:10:09 +1000
Subject: jdk8u: -Wno-regsiter to support newer compilers
In-Reply-To: <CAHNTFmJsc+KyeDsMPrNa43fw2oe6AQd3yDPNmdk-a5Jkt01ciw@mail.gmail.com>
References: <CAHNTFmK9nUQ1YqYgD6sRwiAhBru0yCEXO6aSa-XM5ds2BHrOOA@mail.gmail.com>
 <8e27b2e0-0e1b-4a2e-909b-5db0c0fac582@oracle.com>
 <ec4d8d3c-440f-4dc8-ba5e-e89900603a88@redhat.com>
 <CAHNTFmKDVEwfkELFJViWrG0CyA2Up4Na7ZV26siBKkVAenEazA@mail.gmail.com>
 <c00f4bd4-a59d-4970-8089-455fbe1700ca@oracle.com>
 <CAHNTFmJsc+KyeDsMPrNa43fw2oe6AQd3yDPNmdk-a5Jkt01ciw@mail.gmail.com>
Message-ID: <3e10bd91-0e6d-4a9e-a99b-e3632812e444@oracle.com>

On 7/08/2024 4:42 am, Elazar Leibovich wrote:
> Thanks,
> I did follow the readme, but could not find any commentary about the 
> build environment or the required compilers.

There is a tiny bit of info there but I think it is out-of-date:

Linux X86 (32-bit) and X64 (64-bit) Fedora 9 gcc 4.3
Mac OS X X64 (64-bit) Mac OS X 10.7 "Lion" XCode 4.5.2 or newer

There is also info here, but again likely out-of-date:

https://wiki.openjdk.org/display/Build/Supported+Build+Platforms

The folks on jdk8u-dev are the best source of current info.

David
-----


> Even less information was on Mac OS X, where the autoconf files seems 
> not to be updated, and as a result arm was chosen instead of aarch64.
> 
> If you can point me to a specific section in the documentation 
> specifying, say, a list of known good compilers, I'll be grateful.
> 
> On Tue, 6 Aug 2024 at 21:37, Magnus Ihse Bursie 
> <magnus.ihse.bursie at oracle.com <mailto:magnus.ihse.bursie at oracle.com>> 
> wrote:
> 
>     __
> 
>     On 2024-08-06 20:33, Elazar Leibovich wrote:
> 
>>     Thanks,
>>     I still fail to understand how JDK8u developers are building the
>>     project.
> 
>     Setting up a build environment for jdk8 is unfortunately not a
>     trivial task. The build readme can be of some use:
>     https://github.com/openjdk/jdk8u-dev/blob/master/doc/building.md
>     <https://github.com/openjdk/jdk8u-dev/blob/master/doc/building.md>.
>     The build system has gone through a complete overhaul in later
>     versions, so if you were to build the mainline JDK it would be a
>     much smoother experience. After all, JDK 8 was released 10 years
>     ago, and much has happened since then.
> 
>     /Magnus
> 
> 
> 
>>     Is there a docker file specifying the build environment? What's
>>     the recommended way of doing that?
>>     Removing the register keyword, plus disabling an overflow warning
>>     in a specific test with pragma did the?trick for me, but:
>>     1. I could not get it built in Mac OS X
>>     2. I felt as if I'm paving my own path building it, instead of
>>     following the Yellow Brick Road, which I'm trying to locate.
>>
>>     Thanks again,
>>
>>     On Tue, 6 Aug 2024 at 21:10, Zden?k ?ambersk? <zzambers at redhat.com
>>     <mailto:zzambers at redhat.com>> wrote:
>>
>>         Hello,
>>
>>         this is known issue, which should get fixed by JDK-8281096:
>>         https://github.com/openjdk/jdk8u-dev/pull/357
>>         <https://github.com/openjdk/jdk8u-dev/pull/357>
>>
>>         (see also: https://github.com/openjdk/jdk8u-dev/pull/508
>>         <https://github.com/openjdk/jdk8u-dev/pull/508>)
>>
>>         TLDR:
>>         Jdk 8 explicitly specifies older c++ version (gnu++98, which
>>         not yet
>>         deprecated
>>         'register' keyword), but flags are not propagated to ADLC
>>         build due to bug.
>>         (correct me, if I am wrong)
>>
>>
>>         When it comes to Adoptium, I don't know exactly, but I think
>>         they are using
>>         older compiler, which uses older c++ standard by default.
>>
>>         On 06. 08. 24 18:37, Magnus Ihse Bursie wrote:
>>         > Hi Elazar,
>>         >
>>         > I see that you never got any replies here. I suggest that
>>         you re-ask
>>         > your question on the jdk8u mailing list instead (cc'd).
>>         >
>>         > /Magnus
>>         >
>>         > On 2024-07-19 16:20, Elazar Leibovich wrote:
>>         >> When trying to compile the latest jdk8u on linux I get
>>         failures over
>>         >> warnings with the register keywords.
>>         >>
>>         >> I'm using https://github.com/openjdk/jdk8u-dev.git
>>         <https://github.com/openjdk/jdk8u-dev.git> which seems to be
>>         >> pretty up to date (I'm using master), and last commit is
>>         less than
>>         >> two days ago.
>>         >>
>>         >> This is a workaround I had to use:
>>         >> diff --git a/hotspot/make/linux/makefiles/gcc.make
>>         >> b/hotspot/make/linux/makefiles/gcc.make
>>         >> index 7dde7f0963..81f156574a 100644
>>         >> --- a/hotspot/make/linux/makefiles/gcc.make
>>         >> +++ b/hotspot/make/linux/makefiles/gcc.make
>>         >> @@ -202,7 +202,7 @@ else
>>         >> ?endif
>>         >>
>>         >> ?# Compiler warnings are treated as errors
>>         >> -WARNINGS_ARE_ERRORS = -Werror
>>         >> +WARNINGS_ARE_ERRORS = -Werror -Wno-register
>>         >>
>>         >> But I guess the best solution is to remove the register
>>         keywords from
>>         >> the codebase.
>>         >>
>>         >> How is adoptium?building it? Does it use specific compiler?
>>         Is the
>>         >> supported compiler documented anywhere?
>>         >>
>>         >> FTR using temurin-build repository and scripts, fails for
>>         other
>>         >> reasons, and fails even with -D/--podman docker containers.
>>         >>
>>         >> This patch builds it with centos stream 9 on amd64.
>>         >>
>>         >> Am I doing something wrong? What's the recommended way of
>>         building jdk8?
>>         >>
>>         >> Thanks,
>>         >> Elazar Leibovich
>>         >
>>
>>         -- 
>>         Zden?k ?ambersk?
>>         OpenJDK QE
>>         Red Hat
>>

From zenghuichen1997 at gmail.com  Wed Aug  7 05:56:51 2024
From: zenghuichen1997 at gmail.com (qia nxiao)
Date: Wed, 7 Aug 2024 13:56:51 +0800
Subject: Request for assistance in analyzing JDK crash without logs
Message-ID: <CAPGG-75jVo91rLMu+LS245Hc-A8dGHSDddjHY6VT4em5_O+f7A@mail.gmail.com>

Hello

After compiling and packaging in the local environment, I encountered a
crash when using the packaged JDK, and there are no relevant logs. Is there
any good method to analyze the cause of the crash?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240807/6b5a8a09/attachment.htm>

From fgao at openjdk.org  Wed Aug  7 10:46:11 2024
From: fgao at openjdk.org (Fei Gao)
Date: Wed, 7 Aug 2024 10:46:11 GMT
Subject: RFR: 8337536: AArch64: Enable BTI branch protection for runtime part
Message-ID: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>

This patch enables BTI branch protection for runtime part on Linux/aarch64 platform.

Motivation

1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. User-level packages can gain additional hardening by compiling with the GCC/Clang flag `-mbranch-protection=flag`. See [1].

2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as one VM configure flag, which would pass `-mbranch-protection=standard` compilation flags to all c/c++ files. Note that `standard` turns on both `pac-ret` and `bti` branch protections. For more details about code reuse attacks and hardware-assisted branch protections on AArch64, see [3].

However, we checked the `.note.gnu.property` section of all the shared libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so didn't set these two target feature bits:


  GNU_PROPERTY_AARCH64_FEATURE_1_BTI
  GNU_PROPERTY_AARCH64_FEATURE_1_PAC


Note-1: BTI is an all or nothing property for a link unit [4]. That is, libjvm.so is not BTI-enabled.

Note-2: PAC bit in `.note.gnu.property` section is used to protect `.got.plt` table. It's independent of whether the relocatable objects use PAC or not.

Goal

Hence, this patch aims to set PAC/BTI feature bits of the `.note.gnu.property` section for libjvm.so.

Implementation

Task-1: find out the problematic input objects

>From [5], "Static linkers processing ELF relocatable objects must set the feature bit in the output object or image only if all the input objects have the corresponding feature bit set." Hence we suspect that the root cause is probably that the PAC/BTI feature bits are not set only for some input objects of libjvm.so.

In order to find out these inputs, we passed `--force-bti` linker flag [4] in my local test. This linker flag would warn if any input object does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following list:


  src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
  src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S
  src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S
  src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S


Task-2: add `.note.gnu.property` section for these assembly files

As mentioned in Motivation-2 part, `-mbranch-protection=standard` is passed to compile c/c++ files but these assembly files are missed.

In this patch, we also pass `-mbranch-protection=standard` flag to assembler (See the update in flags-cflags.m4 and flags-other.m4), and add `.note.gnu.property` section at the end of these assembler files.

With this change, we can see PAC/BTI feature bits in the final libjvm.so.

Task-3: add BTI landing pads for hand written assembly

In the local test on Fedora 40 with PAC/BTI-capable hardware, we got `SIGILL` error, which is one typical BTI error (branch target exception). The root cause is that we should add the missing BTI landing pads for hand written assembly in hotspot.

File-1 copy_aarch64.hpp: It's a switch-case statement and we add `bti j` for these indirect jumps.

File-2 atomic_linux_aarch64.S: We add landings pads `bti c` at the function entries.

File-3 copy_linux_aarch64.S: There is no need to add `bti c` at the function entries since they are called via `bl`. And we should handle the indirect jumps.

File-4 safefetch_linux_aarch64.S: Similar to file-3, there is no need to handle these function entries.

File-5 threadLS_linux_aarch64.S: No need to handle the function entry because `paciasp` can act as the landing pad.

Evaluation

1. jtreg test

We ran tier 1-3 jtreg tests on Fedora 40 + GCC 14 + the following AArch64 hardware and all tests passed.


  1. w/o PAC and w/o BTI
  2. w/ PAC and w/o BTI
  3. w/ PAC and w/ BTI


We also ran the jtreg tests on Fedora 40 + Clang 18 + hardware w/ PAC and w/ BTI. The test passed too.

2. code size

We got about 2% code size increase before and after `--enbale-branch-protection` is used. This code size change looks reasonable. See the evaluation on glibc [6].

[1] https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication
[2] https://bugs.openjdk.org/browse/JDK-8277204
[3] https://community.arm.com/arm-community-blogs/b/tools-software-ides-blog/posts/code-reuse-attacks-the-compiler-story
[4] https://reviews.llvm.org/D62609
[5] https://github.com/ARM-software/abi-aa/blob/2a70c42d62e9c3eb5887fa50b71257f20daca6f9/aaelf64/aaelf64.rst#program-property
[6] https://developer.arm.com/documentation/102433/0100/Applying-these-techniques-to-real-code

-------------

Commit messages:
 - 8337536: AArch64: Enable BTI branch protection for runtime part

Changes: https://git.openjdk.org/jdk/pull/20491/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20491&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337536
  Stats: 223 lines in 7 files changed: 199 ins; 2 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/20491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20491/head:pull/20491

PR: https://git.openjdk.org/jdk/pull/20491

From sxa at redhat.com  Wed Aug  7 11:48:37 2024
From: sxa at redhat.com (Stewart X Addison)
Date: Wed, 7 Aug 2024 12:48:37 +0100
Subject: jdk8u: -Wno-regsiter to support newer compilers
In-Reply-To: <8e27b2e0-0e1b-4a2e-909b-5db0c0fac582@oracle.com>
References: <CAHNTFmK9nUQ1YqYgD6sRwiAhBru0yCEXO6aSa-XM5ds2BHrOOA@mail.gmail.com>
 <8e27b2e0-0e1b-4a2e-909b-5db0c0fac582@oracle.com>
Message-ID: <CAL5aOfqqBYxJJ49n_51BZ6vw+rdh4MGD=cRZ0LnCEiA4sPNNaQ@mail.gmail.com>

Hi Elazar,

> How is adoptium building it? Does it use specific compiler?

Yes - Adoptium uses our own build of gcc 7.5.0 to build Temurin's jdk8u on
Linux. If you wish to use the same environment as us, the simplest way is
to pull the `adoptopenjdk/centos7_build_image` and use that which will be a
preconfigured environment (replace centos7 with centos6 if on x64 for
exactly the one we use, but 7 will likely work too) and you should be able
to use the temurin-build scripts in that container. The 7.5.0 compiler is
under `/usr/local/gcc` in that image. Other GCC versions are installed
under /usr/local that we use for different versions of the JDK. If you
specifically want to go down the route of creating those containers
yourself from scratch, they are set up using ansible in the dockerfiles
from https://github.com/adoptium/infrastructure/tree/master/ansible/docker.

> FTR using temurin-build repository and scripts, fails for other reasons,
and fails even with -D/--podman docker containers.

Thanks for the info. If you could raise an issue with the details of that
over at https://github.com/adoptium/temurin-build that would be
appreciated. While we don't use those options in the main temurin build
processes they are useful for other users of our scripts and someone has
been updating and testing those options recently (after a bit of
stagnation) to add the support for podman so I believe they should be in a
reasonable state at the moment. Hopefully we can get that fixed if they are
currently misbehaving in some environments.

Hope that helps.

Regards,

Stewart...
--
Working for Red Hat <https://www.redhat.com> on Adoptium Temurin
<https://adoptium.net> and Node.js
<http://nodejs.org>
https://fosstodon.org/@sxa
https://github.com/sxa
<http://nodejs.org>



On Tue, 6 Aug 2024 at 17:37, Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> Hi Elazar,
>
> I see that you never got any replies here. I suggest that you re-ask
> your question on the jdk8u mailing list instead (cc'd).
>
> /Magnus
>
> On 2024-07-19 16:20, Elazar Leibovich wrote:
> > When trying to compile the latest jdk8u on linux I get failures over
> > warnings with the register keywords.
> >
> > I'm using https://github.com/openjdk/jdk8u-dev.git which seems to be
> > pretty up to date (I'm using master), and last commit is less than two
> > days ago.
> >
> > This is a workaround I had to use:
> > diff --git a/hotspot/make/linux/makefiles/gcc.make
> > b/hotspot/make/linux/makefiles/gcc.make
> > index 7dde7f0963..81f156574a 100644
> > --- a/hotspot/make/linux/makefiles/gcc.make
> > +++ b/hotspot/make/linux/makefiles/gcc.make
> > @@ -202,7 +202,7 @@ else
> >  endif
> >
> >  # Compiler warnings are treated as errors
> > -WARNINGS_ARE_ERRORS = -Werror
> > +WARNINGS_ARE_ERRORS = -Werror -Wno-register
> >
> > But I guess the best solution is to remove the register keywords from
> > the codebase.
> >
> > How is adoptium building it? Does it use specific compiler? Is the
> > supported compiler documented anywhere?
> >
> > FTR using temurin-build repository and scripts, fails for other
> > reasons, and fails even with -D/--podman docker containers.
> >
> > This patch builds it with centos stream 9 on amd64.
> >
> > Am I doing something wrong? What's the recommended way of building jdk8?
> >
> > Thanks,
> > Elazar Leibovich
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240807/54e5bfa7/attachment.htm>

From matthias.baesken at sap.com  Wed Aug  7 13:13:13 2024
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 7 Aug 2024 13:13:13 +0000
Subject: jdk21u-dev build issue : 8326332: Unclosed inline tags cause
 misalignment in summary tables
In-Reply-To: <474546f8-173b-4d8d-9ba1-6113a67892b2@oracle.com>
References: <AM9PR02MB6770EB7789144D05CCF7F79D93AA2@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <474546f8-173b-4d8d-9ba1-6113a67892b2@oracle.com>
Message-ID: <AM9PR02MB677047A49073BE20F20A37BC93B82@AM9PR02MB6770.eurprd02.prod.outlook.com>

Hi Erik,  thanks for the clarification.
Unfortunately we do not see  this in GHA ,  so backports look  nice and ?green? there .

And some people with strict version requirements in the company most likely have a problem with an old / unpatched JDK20  .


Best regards, Matthias


From: Erik Joelsson <erik.joelsson at oracle.com>
Sent: Wednesday, 7 August 2024 13:58
To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
Subject: Re: jdk21u-dev build issue : 8326332: Unclosed inline tags cause misalignment in summary tables


Hello Matthias,

If you had sent this to build-dev, you would have received an answer much quicker as both Magnus and I were on vacation.

No, you can't use JDK N features in the langtools modules because because those need to be compatible with the official bootjdk which is version JDK N-1. This has been the case since long before I started working on the JDK.

/Erik
On 7/24/24 12:52 AM, Baesken, Matthias wrote:
Hi,  when building   the backport to 21u-dev
8326332: Unclosed inline tags cause misalignment in summary tables
https://github.com/openjdk/jdk21u-dev/pull/866

with a BOOT JDK 20, I run into these build errors :
(the build works fine when a JDK21 is used as BOOT JDK  ;  in  GHA it is also fine because seems we use JDK21 boot JDK there )


/open_jdk/jdk21u_dev_2/jdk21u-dev/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java:1156: error: cannot find symbol
                        && openTags.getLast().equals(name)) {
                                   ^
  symbol:   method getLast()
  location: variable openTags of type List<Name>
/open_jdk/jdk21u_dev_2/jdk21u-dev/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java:1157: error: cannot find symbol
                    openTags.removeLast();
                            ^
  symbol:   method removeLast()
  location: variable openTags of type List<Name>
/open_jdk/jdk21u_dev_2/jdk21u-dev/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java:1501: error: cannot find symbol
            result.add(RawHtml.endElement(openTags.removeLast()));
                                                  ^
  symbol:   method removeLast()
  location: variable openTags of type List<Name>
3 errors
gmake[3]: *** [CompileInterimLangtools.gmk:127: /open_jdk/jdk21u_dev_2/buildfolder/buildtools/interim_langtools_modules/jdk.javadoc.interim/_the.BUILD_jdk.javadoc.interim_batch] Error 1
gmake[2]: *** [make/Main.gmk:78: interim-langtools] Error 2


We use here functionality of class List  ( getLast() / removeLast() )  that was added in jdk21.
Shouldn't we be able to use this functionality ?
For backports it would be much easier/ cleaner to have the ability of  clean backports without the need to  remove jdk21 functionality .
Also some people might not even notice those issues , because  they cannot use  old/unpatched/un-secure JDK20  .

It looks like there might be an issue in the build process so that we reference  java.base  from boot jdk20  , or is it done on purpose that for CompileInterimLangtools / jdk.javadoc this cannot be used) ?


Best regards, Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240807/fd5be1ed/attachment-0001.htm>

From ihse at openjdk.org  Wed Aug  7 15:10:32 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 7 Aug 2024 15:10:32 GMT
Subject: RFR: 8336849: Remove .llvm_addrsig section from JDK/VM static
 libraries (.a files)
In-Reply-To: <ydhogvsR2STcb7WGAQCjAua5l25gEd16Kjh_A0meInA=.92082d43-9187-47e4-b741-2fe059afb1bc@github.com>
References: <ydhogvsR2STcb7WGAQCjAua5l25gEd16Kjh_A0meInA=.92082d43-9187-47e4-b741-2fe059afb1bc@github.com>
Message-ID: <iHuqyYH8SEl2Qy0qVs_NMiMN8yqk4Lk7yeaDSa71O-M=.31636fd9-321c-45d1-8fca-afeaedcdd7ff@github.com>

On Sat, 20 Jul 2024 00:20:19 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that strips the `.llvm_addrsig` section from JDK and hotspot `.a` static libraries when building with clang. Please see https://bugs.openjdk.org/browse/JDK-8336849 description for details.

Thank you Jiangli for the additional links. While the lack of formal documentation is somewhat dissatisfying, I agree that the code analysis from the mailing list is good enough indication that a lack of  `.llvm_addrsig` means all addresses are considered significant.

Also, this whole situation seem like a clusterf**k of bad tooling and tooling cooperation. :-( Are you saying that even using strip can cause lld malfunction? Is there any chance we risk running into problems that way?

The opinions on the bug report you posted indicate that people are not happy with this design:

> "In my opinion, .llvm_addrsig is a poor design.  Peter Collingbourne received multiple objections to the idea when it was proposed on the generic ABI list, but he went ahead anyway. (Well, maybe the code was accepted into llvm during the discussion.)  He was even told how to implement the functionality correctly, by a toolchain expert. [...] So I'd say there is zero chance of SHT_LLVM_ADDRSIG being blessed by the generic ABI group, and also little chance that any of the binutils maintainers will treat this as a bug that needs fixing.  

I agree with this assessment. Adding a new section that causes failure if it is not kept updated by other tools (and possibly even their own `ld -r`!) is just bad behavior on their part. Nevertheless, we have had to deal with broken tools before, so if  we can force it to behave more properly by removing the `.llvm_addrsig` section, then I guess that this is the workaround we need to use anyway.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20265#issuecomment-2273700966

From ihse at openjdk.org  Wed Aug  7 15:15:32 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 7 Aug 2024 15:15:32 GMT
Subject: RFR: 8336849: Remove .llvm_addrsig section from JDK/VM static
 libraries (.a files)
In-Reply-To: <ydhogvsR2STcb7WGAQCjAua5l25gEd16Kjh_A0meInA=.92082d43-9187-47e4-b741-2fe059afb1bc@github.com>
References: <ydhogvsR2STcb7WGAQCjAua5l25gEd16Kjh_A0meInA=.92082d43-9187-47e4-b741-2fe059afb1bc@github.com>
Message-ID: <X6sCtbR-GcuJe95mp-kJmQ_dkNS5eogiP5ov6zSwB30=.da52c8b6-e3ce-485a-9bfd-fbe6b4cd77f5@github.com>

On Sat, 20 Jul 2024 00:20:19 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that strips the `.llvm_addrsig` section from JDK and hotspot `.a` static libraries when building with clang. Please see https://bugs.openjdk.org/browse/JDK-8336849 description for details.

make/common/native/Link.gmk line 114:

> 112:           # Linking with '-Wl,--icf=safe' using objects created by 'ld -r' may not work
> 113:           # and could cause errors like the following:
> 114:           #   ld: --icf=safe conservatively ignores SHT_LLVM_ADDRSIG [...] with sh_link=0 (likely created using objcopy or ld -r)

I'd recommend rephrasing the comment somewhat, like

Suggestion:

          # 'ld -r' might fail to update the .llvm_addrsig section, and this will cause subsequent
          # calls to lld to fail when linking with this library, so remove that section.


(adjust line lengths if > 80)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20265#discussion_r1707228847

From ihse at openjdk.org  Wed Aug  7 15:30:31 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 7 Aug 2024 15:30:31 GMT
Subject: RFR: 8337536: AArch64: Enable BTI branch protection for runtime
 part
In-Reply-To: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
References: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
Message-ID: <ovyOKYldRuYx5VC4XnhpuHF3_yjRYMuq1DiIVumlBr4=.2d5e7461-1f42-4d09-a067-934eb2b31445@github.com>

On Wed, 7 Aug 2024 10:40:09 GMT, Fei Gao <fgao at openjdk.org> wrote:

> This patch enables BTI branch protection for runtime part on Linux/aarch64 platform.
> 
> Motivation
> 
> 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. User-level packages can gain additional hardening by compiling with the GCC/Clang flag `-mbranch-protection=flag`. See [1].
> 
> 2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as one VM configure flag, which would pass `-mbranch-protection=standard` compilation flags to all c/c++ files. Note that `standard` turns on both `pac-ret` and `bti` branch protections. For more details about code reuse attacks and hardware-assisted branch protections on AArch64, see [3].
> 
> However, we checked the `.note.gnu.property` section of all the shared libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so didn't set these two target feature bits:
> 
> 
>   GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>   GNU_PROPERTY_AARCH64_FEATURE_1_PAC
> 
> 
> Note-1: BTI is an all or nothing property for a link unit [4]. That is, libjvm.so is not BTI-enabled.
> 
> Note-2: PAC bit in `.note.gnu.property` section is used to protect `.got.plt` table. It's independent of whether the relocatable objects use PAC or not.
> 
> Goal
> 
> Hence, this patch aims to set PAC/BTI feature bits of the `.note.gnu.property` section for libjvm.so.
> 
> Implementation
> 
> Task-1: find out the problematic input objects
> 
> From [5], "Static linkers processing ELF relocatable objects must set the feature bit in the output object or image only if all the input objects have the corresponding feature bit set." Hence we suspect that the root cause is probably that the PAC/BTI feature bits are not set only for some input objects of libjvm.so.
> 
> In order to find out these inputs, we passed `--force-bti` linker flag [4] in my local test. This linker flag would warn if any input object does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following list:
> 
> 
>   src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
>   src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S
>   src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S
>   src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S
> 
> 
> Task-2: add `.note.gnu.property` section for these assembly files
> 
> As mentioned in Motivation-2 part, `-mbranch-protection=standard` is passed to compile c/c++ files but these assembly files are missed.
> 
> In this patch, we also pass `-mbranch-protection=standard` flag to assembler (See the update in flags-cflags.m4 and flags-other.m4), and add `.note.gnu.property` section at the end...

Thank you for the detailed description!

Adding this flag to ASFLAGS as well seems reasonable, but I think the logic in the configure files can be straightened out a bit. I'll look around at the files and get back to you with a more concrete recommendation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20491#issuecomment-2273743971

From bpb at openjdk.org  Wed Aug  7 15:34:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 15:34:37 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v3]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <vfXDNsXH6ayjYSajCqItlH5E0k9DXhNrcRHhQboKF4Y=.03249396-b128-46e2-bf01-3373de8c3f78@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8337143: Removed dependency of libjava on headers in libnio/ch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20317/files
  - new: https://git.openjdk.org/jdk/pull/20317/files/48519737..7e8a02e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=01-02

  Stats: 305 lines in 17 files changed: 141 ins; 151 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

PR: https://git.openjdk.org/jdk/pull/20317

From bpb at openjdk.org  Wed Aug  7 15:34:38 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 15:34:38 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v2]
In-Reply-To: <o8AMwn0LgrRO6D1WfU89F7xPTwt08LdsZKzsEijFfyg=.4fa9126b-98de-4878-b601-d02b03050e2b@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <o8AMwn0LgrRO6D1WfU89F7xPTwt08LdsZKzsEijFfyg=.4fa9126b-98de-4878-b601-d02b03050e2b@github.com>
Message-ID: <7wiOsnhOQIZL7-64yFcJYwWS95gOM7NeaU3IcOZUCUo=.b65933fd-ce5c-4c81-8f39-395f4b4ee33b@github.com>

On Fri, 26 Jul 2024 19:40:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio

As part of 7e8a02e, the `nio_util.h` header files were modified. One unused symbolic constant was removed. Symbolic constants used in only one file were moved to that file. Function declarations that were only used where the function is defined were removed. Function declarations used in only one file other than the one where the function is defined were moved to an `extern` in that file. On Unix, one function declaration used in three files was moved to a new header file `Net.h`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2273748931

From ihse at openjdk.org  Wed Aug  7 15:51:30 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 7 Aug 2024 15:51:30 GMT
Subject: RFR: 8337536: AArch64: Enable BTI branch protection for runtime
 part
In-Reply-To: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
References: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
Message-ID: <MFEBea6TK2Nkhh8RsCqUtMwaDAYy_NrrNZRg0TrYlFY=.1c9e7501-09fc-48f0-98ac-a657a7b3c1a9@github.com>

On Wed, 7 Aug 2024 10:40:09 GMT, Fei Gao <fgao at openjdk.org> wrote:

> This patch enables BTI branch protection for runtime part on Linux/aarch64 platform.
> 
> Motivation
> 
> 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. User-level packages can gain additional hardening by compiling with the GCC/Clang flag `-mbranch-protection=flag`. See [1].
> 
> 2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as one VM configure flag, which would pass `-mbranch-protection=standard` compilation flags to all c/c++ files. Note that `standard` turns on both `pac-ret` and `bti` branch protections. For more details about code reuse attacks and hardware-assisted branch protections on AArch64, see [3].
> 
> However, we checked the `.note.gnu.property` section of all the shared libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so didn't set these two target feature bits:
> 
> 
>   GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>   GNU_PROPERTY_AARCH64_FEATURE_1_PAC
> 
> 
> Note-1: BTI is an all or nothing property for a link unit [4]. That is, libjvm.so is not BTI-enabled.
> 
> Note-2: PAC bit in `.note.gnu.property` section is used to protect `.got.plt` table. It's independent of whether the relocatable objects use PAC or not.
> 
> Goal
> 
> Hence, this patch aims to set PAC/BTI feature bits of the `.note.gnu.property` section for libjvm.so.
> 
> Implementation
> 
> Task-1: find out the problematic input objects
> 
> From [5], "Static linkers processing ELF relocatable objects must set the feature bit in the output object or image only if all the input objects have the corresponding feature bit set." Hence we suspect that the root cause is probably that the PAC/BTI feature bits are not set only for some input objects of libjvm.so.
> 
> In order to find out these inputs, we passed `--force-bti` linker flag [4] in my local test. This linker flag would warn if any input object does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following list:
> 
> 
>   src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
>   src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S
>   src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S
>   src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S
> 
> 
> Task-2: add `.note.gnu.property` section for these assembly files
> 
> As mentioned in Motivation-2 part, `-mbranch-protection=standard` is passed to compile c/c++ files but these assembly files are missed.
> 
> In this patch, we also pass `-mbranch-protection=standard` flag to assembler (See the update in flags-cflags.m4 and flags-other.m4), and add `.note.gnu.property` section at the end...

It turned out to be easier to write it myself than trying to explain it. Please have a look here:
https://github.com/openjdk/jdk/commit/0fe840dec597bb4a819eb2025a6d56cd82f237b5

(This also contains some additional cleanup in the branch protection configure code.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20491#issuecomment-2273789758

From bpb at openjdk.org  Wed Aug  7 15:59:14 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 15:59:14 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge
 - 8337143: Removed dependency of libjava on headers in libnio/ch
 - 8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio
 - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20317/files
  - new: https://git.openjdk.org/jdk/pull/20317/files/7e8a02e3..e28a4f57

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=02-03

  Stats: 23454 lines in 774 files changed: 12481 ins; 7665 del; 3308 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

PR: https://git.openjdk.org/jdk/pull/20317

From bpb at openjdk.org  Wed Aug  7 15:59:15 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 15:59:15 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v2]
In-Reply-To: <BiQ_TBNl7VkHlTgdLT6pjZCoVEkpjwgynx-ZT0b51Aw=.3a6df22f-a074-40a6-8291-c2f4452980a0@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <o8AMwn0LgrRO6D1WfU89F7xPTwt08LdsZKzsEijFfyg=.4fa9126b-98de-4878-b601-d02b03050e2b@github.com>
 <SwXug6F4BisDdJjJs1Wel3evwd0AbnYyWS-1sL_sjvs=.3a66f702-9a2f-4ab1-8932-59208c3871c0@github.com>
 <BiQ_TBNl7VkHlTgdLT6pjZCoVEkpjwgynx-ZT0b51Aw=.3a6df22f-a074-40a6-8291-c2f4452980a0@github.com>
Message-ID: <pDyI_GgnI1YL8jKxJm8g8ffaF7vWPMXjRgG_TElQhfI=.d93950b5-c588-49d3-82ea-901cf6d158aa@github.com>

On Mon, 5 Aug 2024 15:37:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> make/modules/java.base/lib/CoreLibraries.gmk line 57:
>> 
>>> 55:     OPTIMIZATION := HIGH, \
>>> 56:     EXTRA_HEADER_DIRS := \
>>> 57:         libnio/ch, \
>> 
>> This will introduce a source code dependency from libjava to libnio. It might be the correct thing to do, but I just want to highlight this. 
>> 
>> Maybe the libnio/ch code also should move to libjava? Or, perhaps at least the header files. Conceptually, I'd feel better about having a dependency on libnio as a "downstream" library on libjava source code, than the other way around.
>
>> This will introduce a source code dependency from libjava to libnio. It might be the correct thing to do, but I just want to highlight this.
> 
> I'll look into improving it.

Fixed in 7e8a02e

>> make/modules/java.base/lib/CoreLibraries.gmk line 71:
>> 
>>> 69:         -framework Foundation \
>>> 70:         -framework SystemConfiguration, \
>>> 71:     LIBS_windows := advapi32.lib ole32.lib shell32.lib version.lib mswsock.lib ws2_32.lib, \
>> 
>> Please keep libraries alphabetically sorted.
>
> Thanks for pointing this out; I will fix it.

Fixed in 7e8a02e.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1707325897
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1707326484

From ihse at openjdk.org  Wed Aug  7 15:59:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 7 Aug 2024 15:59:15 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
Message-ID: <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>

On Wed, 7 Aug 2024 15:56:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge
>  - 8337143: Removed dependency of libjava on headers in libnio/ch
>  - 8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio
>  - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava

make/modules/java.base/lib/CoreLibraries.gmk line 71:

> 69:         -framework Foundation \
> 70:         -framework SystemConfiguration, \
> 71:     LIBS_windows := advapi32.lib mswsock.lib ole32.lib shell32.lib version.lib ws2_32.lib, \

Are these libraries still required to build libnio, or can they be removed from that library now?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1707327953

From bpb at openjdk.org  Wed Aug  7 16:03:33 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 16:03:33 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
Message-ID: <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>

On Wed, 7 Aug 2024 15:56:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge
>>  - 8337143: Removed dependency of libjava on headers in libnio/ch
>>  - 8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio
>>  - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava
>
> make/modules/java.base/lib/CoreLibraries.gmk line 71:
> 
>> 69:         -framework Foundation \
>> 70:         -framework SystemConfiguration, \
>> 71:     LIBS_windows := advapi32.lib mswsock.lib ole32.lib shell32.lib version.lib ws2_32.lib, \
> 
> Are these libraries still required to build libnio, or can they be removed from that library now?

I will check. Thanks for noticing it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1707337157

From bpb at openjdk.org  Wed Aug  7 16:06:35 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 16:06:35 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
 <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
Message-ID: <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>

On Wed, 7 Aug 2024 16:00:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> make/modules/java.base/lib/CoreLibraries.gmk line 71:
>> 
>>> 69:         -framework Foundation \
>>> 70:         -framework SystemConfiguration, \
>>> 71:     LIBS_windows := advapi32.lib mswsock.lib ole32.lib shell32.lib version.lib ws2_32.lib, \
>> 
>> Are these libraries still required to build libnio, or can they be removed from that library now?
>
> I will check. Thanks for noticing it.

`CoreServices` is still necessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1707344003

From aph at openjdk.org  Wed Aug  7 17:29:30 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 7 Aug 2024 17:29:30 GMT
Subject: RFR: 8337536: AArch64: Enable BTI branch protection for runtime
 part
In-Reply-To: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
References: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
Message-ID: <446-JAhZlwZT7eNafXxR90EqiIUuV5Xd9bMfqXTOVA4=.45e46493-f09e-4ef4-9d13-6657b7938433@github.com>

On Wed, 7 Aug 2024 10:40:09 GMT, Fei Gao <fgao at openjdk.org> wrote:

> This patch enables BTI branch protection for runtime part on Linux/aarch64 platform.
> 
> Motivation
> 
> 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. User-level packages can gain additional hardening by compiling with the GCC/Clang flag `-mbranch-protection=flag`. See [1].
> 
> 2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as one VM configure flag, which would pass `-mbranch-protection=standard` compilation flags to all c/c++ files. Note that `standard` turns on both `pac-ret` and `bti` branch protections. For more details about code reuse attacks and hardware-assisted branch protections on AArch64, see [3].
> 
> However, we checked the `.note.gnu.property` section of all the shared libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so didn't set these two target feature bits:
> 
> 
>   GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>   GNU_PROPERTY_AARCH64_FEATURE_1_PAC
> 
> 
> Note-1: BTI is an all or nothing property for a link unit [4]. That is, libjvm.so is not BTI-enabled.
> 
> Note-2: PAC bit in `.note.gnu.property` section is used to protect `.got.plt` table. It's independent of whether the relocatable objects use PAC or not.
> 
> Goal
> 
> Hence, this patch aims to set PAC/BTI feature bits of the `.note.gnu.property` section for libjvm.so.
> 
> Implementation
> 
> Task-1: find out the problematic input objects
> 
> From [5], "Static linkers processing ELF relocatable objects must set the feature bit in the output object or image only if all the input objects have the corresponding feature bit set." Hence we suspect that the root cause is probably that the PAC/BTI feature bits are not set only for some input objects of libjvm.so.
> 
> In order to find out these inputs, we passed `--force-bti` linker flag [4] in my local test. This linker flag would warn if any input object does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following list:
> 
> 
>   src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
>   src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S
>   src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S
>   src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S
> 
> 
> Task-2: add `.note.gnu.property` section for these assembly files
> 
> As mentioned in Motivation-2 part, `-mbranch-protection=standard` is passed to compile c/c++ files but these assembly files are missed.
> 
> In this patch, we also pass `-mbranch-protection=standard` flag to assembler (See the update in flags-cflags.m4 and flags-other.m4), and add `.note.gnu.property` section at the end...

Can you explain why we want to support PAC without BTI? Would anyone use such a config?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20491#issuecomment-2273969126

From kstine at stanford.edu  Wed Aug  7 17:30:14 2024
From: kstine at stanford.edu (Kurt Stine)
Date: Wed, 7 Aug 2024 17:30:14 +0000
Subject: Issue cross-compiling idk 8 for powerpc
In-Reply-To: <fc075bd6-7dd9-4043-a032-0a23591bc0b2@oracle.com>
References: <8EEB3022-4DEC-47F1-8202-40C62A01BB4D@stanford.edu>
 <fc075bd6-7dd9-4043-a032-0a23591bc0b2@oracle.com>
Message-ID: <8C5F8B70-DE89-40DC-97FD-E12C39C739AB@stanford.edu>

Hi Magnus,

No, I am still unable to cross-compile jdk8u for ppc32. I was able to get the latest community ppc32 build from Azul, but it isn?t the latest/most up-to-date version.

Regards,
Kurt

From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
Date: Tuesday, August 6, 2024 at 9:41?AM
To: Kurt Stine <kstine at stanford.edu>, "build-dev at openjdk.org" <build-dev at openjdk.org>
Subject: Re: Issue cross-compiling idk 8 for powerpc


Hi Kurt,

Did you manage to resolve this issue?

/Magnus
On 2024-07-10 23:52, Kurt Stine wrote:
Hi Everyone,

I?m running into an issue when trying to cross-compile the latest jdk8u for powerpc (32 bit).

I am cross-compiling from x86_64 with Azul Zulu JDK 7 as my boot JDK.

Whenever I try and run "bash configure --openjdk-target=powerpc-linux --with-jvm-variants=zero", configure results in the following error:

checking size of int *... 8
configure: The tested number of bits in the target (64) differs from the number of bits expected to be found in the target (32).
configure: I'll retry after setting the platforms compiler target bits flag to -m32
checking size of int *... 0
configure: error: The tested number of bits in the target (0) differs from the number of bits expected to be found in the target (32)

I am using the brotlin glibc 13.2.0 toolchain specifically: https://toolchains.bootlin.com/releases_powerpc-440fp.html but I've confirmed that the error also occurs with standard GCC as well as when using a ppc sysroot.

My full configure.log is here: https://paste.debian.net/1322788/

Any help with this is appreciated.

Thanks,
Kurt Stine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240807/c4eb63c5/attachment.htm>

From shipilev at amazon.de  Wed Aug  7 17:39:04 2024
From: shipilev at amazon.de (Aleksey Shipilev)
Date: Wed, 7 Aug 2024 19:39:04 +0200
Subject: Issue cross-compiling idk 8 for powerpc
In-Reply-To: <8C5F8B70-DE89-40DC-97FD-E12C39C739AB@stanford.edu>
References: <8EEB3022-4DEC-47F1-8202-40C62A01BB4D@stanford.edu>
 <fc075bd6-7dd9-4043-a032-0a23591bc0b2@oracle.com>
 <8C5F8B70-DE89-40DC-97FD-E12C39C739AB@stanford.edu>
Message-ID: <19764da7-3784-4a86-94bd-f1dec34ef3fc@amazon.de>

Hi,

On 07.08.24 19:30, Kurt Stine wrote:
> No, I am still unable to cross-compile jdk8u for ppc32. I was able to get the latest community ppc32 
> build from Azul, but it isn?t the latest/most up-to-date version.

I used to build PPC32 binaries for JDK 8u with debootstrapped sysroots and native cross-compiler:
  https://github.com/openjdk/jdk/blob/master/doc/building.md#using-debian-debootstrap

>     Whenever I try and run "bash configure --openjdk-target=powerpc-linux --with-jvm-variants=zero",
>     configure results in the following error:

I suspect openjdk-target should be "powerpc-linux-gnu"?

JDK 8 build system is often confused about compilers as well. I recommend configuring with 
explicitly set CC and CXX, i.e.:

  $ CC=... CXX... bash ./configure ...

-Aleksey



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

From shipilev at amazon.de  Wed Aug  7 18:10:37 2024
From: shipilev at amazon.de (Aleksey Shipilev)
Date: Wed, 7 Aug 2024 20:10:37 +0200
Subject: Issue cross-compiling idk 8 for powerpc
In-Reply-To: <19764da7-3784-4a86-94bd-f1dec34ef3fc@amazon.de>
References: <8EEB3022-4DEC-47F1-8202-40C62A01BB4D@stanford.edu>
 <fc075bd6-7dd9-4043-a032-0a23591bc0b2@oracle.com>
 <8C5F8B70-DE89-40DC-97FD-E12C39C739AB@stanford.edu>
 <19764da7-3784-4a86-94bd-f1dec34ef3fc@amazon.de>
Message-ID: <8938e632-2d42-4c15-bff4-ce58e35e3052@amazon.de>

On 07.08.24 19:39, Aleksey Shipilev wrote:
> On 07.08.24 19:30, Kurt Stine wrote:
>> No, I am still unable to cross-compile jdk8u for ppc32. I was able to get the latest community 
>> ppc32 build from Azul, but it isn?t the latest/most up-to-date version.
> 
> I used to build PPC32 binaries for JDK 8u with debootstrapped sysroots and native cross-compiler:
>  ?https://github.com/openjdk/jdk/blob/master/doc/building.md#using-debian-debootstrap

Found my old build scripts. Just did the following on https://github.com/openjdk/jdk8u-dev/, and it 
worked.

=== 1. Apply this patch:

diff --git a/common/autoconf/generated-configure.sh b/common/autoconf/generated-configure.sh
index 71fabf4dbb..cc27b99c0e 100644
--- a/common/autoconf/generated-configure.sh
+++ b/common/autoconf/generated-configure.sh
@@ -48239,6 +48239,10 @@ $as_echo "$as_me: The path of FREETYPE_INCLUDE_PATH, which resolves as 
\"$path\"
        fi
      fi

+    if test "x$SYSROOT" != x; then
+      FREETYPE_CFLAGS="$FREETYPE_CFLAGS --sysroot $SYSROOT"
+    fi
+
      if test "x$FREETYPE_LIBS" = x; then

    if test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.cygwin"; then
diff --git a/common/autoconf/libraries.m4 b/common/autoconf/libraries.m4
index 6efae578ea..c39cb08dac 100644
--- a/common/autoconf/libraries.m4
+++ b/common/autoconf/libraries.m4
@@ -578,6 +578,10 @@ AC_DEFUN_ONCE([LIB_SETUP_FREETYPE],
        fi
      fi

+    if test "x$SYSROOT" != x; then
+      FREETYPE_CFLAGS="$FREETYPE_CFLAGS --sysroot $SYSROOT"
+    fi
+
      if test "x$FREETYPE_LIBS" = x; then
        BASIC_FIXUP_PATH(FREETYPE_LIB_PATH)
        if test "x$OPENJDK_TARGET_OS" = xwindows; then


=== 2. Debootstrap the sysroot: (you might be lucky with the sysroot you already have)
  https://github.com/openjdk/jdk/blob/master/doc/building.md#using-debian-debootstrap

=== 3. Configure with:

Assumes sysroot is at /chroots/powerpc/

$ CC=powerpc-linux-gnu-gcc CXX=powerpc-linux-gnu-g++ sh ./configure \
   --openjdk-target=powerpc-linux-gnu \
   --with-sysroot=/chroots/powerpc/ \
   --x-libraries=/chroots/powerpc/usr/lib/powerpc-linux-gnu/ \
   --with-freetype-lib=/chroots/powerpc/usr/lib/powerpc-linux-gnu/ \
   --with-freetype-include=/chroots/powerpc/usr/include/freetype2 \
   --with-boot-jdk=/home/shade/jdks/8u/ \
   --with-jvm-variants=zero \
   --with-extra-cflags=-Wno-error

=== 4. Build with:

$ make images

===  5. Enjoy:

$ ls build/linux-ppc-normal-zero-release/images/j2sdk-image/



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

From bpb at openjdk.org  Wed Aug  7 18:16:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 18:16:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
 <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
 <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>
Message-ID: <3svWg4OOtXThIl3WVV4kwOafudlnHmlREaqFSAfR9mI=.a9ce7e75-3275-4ab1-bbf7-f75f91788a6d@github.com>

On Wed, 7 Aug 2024 16:03:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I will check. Thanks for noticing it.
>
> `CoreServices` is still necessary ([Uniform Type Identifier](https://developer.apple.com/documentation/uniformtypeidentifiers)s).

The Windows libs are also still required for `TransmitFile` and `WSAGetLastError`:

- ```mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile```
- ```ws2_32.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol __imp_WSAGetLastError```

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1707599113

From lmesnik at openjdk.org  Wed Aug  7 20:28:35 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 7 Aug 2024 20:28:35 GMT
Subject: Integrated: 8337410: The makefiles should set problemlist and adjust
 timeout basing on the given VM flags
In-Reply-To: <HSbKJYVYgMPgkPuXFwzDECWYOcfk5d86zp1gNmS5eJM=.38b1c9c5-558c-4584-a3e3-ac23640f7c5c@github.com>
References: <HSbKJYVYgMPgkPuXFwzDECWYOcfk5d86zp1gNmS5eJM=.38b1c9c5-558c-4584-a3e3-ac23640f7c5c@github.com>
Message-ID: <yLqylQqlqtqubK1t49QC1giyv6I-YmcFUz8vSxu37kw=.bac4adeb-3240-44e8-b318-cb89e7e228a7@github.com>

On Thu, 1 Aug 2024 18:26:55 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> There jtreg tests have several additional problemlists 
> ProblemList-Xcomp.txt
> ProblemList-generational-zgc.txt
> ProblemList-zgc.txt
> Each of them is bound to corresponding execution mode (Xcomp/ZGC) and it makes sense to treat them like standard problemlist when tests are executed with -Xcomp or ZGC enabled.
> Currently, it is needed to set them manually and it is often forgotten. So engineers waste time analyzing known failures.
> 
> Additionally, the **default** timeoutFactor is increased when Xcomp is enabled because of slowness of this mode. 
> 
> The jtreg allows to add the same problemlist twice so it is not needed to update any execution system that set problemlists.
> 
> Later it might makes sens to set 'JTREG_ALL_OPTIONS' by asking java about actually set mode. So it is possible to adjust  options for fastdebug/slowdebug/product modes and/or different options that are set during compilation (saying different default GC).

This pull request has now been integrated.

Changeset: 5e021cbc
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5e021cbcc7a6cb30a27380950e115ff12846239c
Stats:     33 lines in 1 file changed: 30 ins; 2 del; 1 mod

8337410: The makefiles should set problemlist and adjust timeout basing on the given VM flags

Reviewed-by: ihse

-------------

PR: https://git.openjdk.org/jdk/pull/20430

From jiangli at openjdk.org  Wed Aug  7 20:35:05 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 7 Aug 2024 20:35:05 GMT
Subject: RFR: 8336849: Remove .llvm_addrsig section from JDK/VM static
 libraries (.a files) [v2]
In-Reply-To: <ydhogvsR2STcb7WGAQCjAua5l25gEd16Kjh_A0meInA=.92082d43-9187-47e4-b741-2fe059afb1bc@github.com>
References: <ydhogvsR2STcb7WGAQCjAua5l25gEd16Kjh_A0meInA=.92082d43-9187-47e4-b741-2fe059afb1bc@github.com>
Message-ID: <JTBNmPHO6cWtVgdAm9Z9lji-Rdb9Yop3iHRfZiFX-UE=.eaa9b5f2-d6a7-446e-8842-6bc20268170f@github.com>

> Please review this PR that strips the `.llvm_addrsig` section from JDK and hotspot `.a` static libraries when building with clang. Please see https://bugs.openjdk.org/browse/JDK-8336849 description for details.

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  - Incorporate comment suggestion from @magicus. Also applied some additional minor adjustments on top of the suggestion.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20265/files
  - new: https://git.openjdk.org/jdk/pull/20265/files/bc427baa..f2cc2b54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20265&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20265&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20265.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20265/head:pull/20265

PR: https://git.openjdk.org/jdk/pull/20265

From jiangli at openjdk.org  Wed Aug  7 20:35:05 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 7 Aug 2024 20:35:05 GMT
Subject: RFR: 8336849: Remove .llvm_addrsig section from JDK/VM static
 libraries (.a files) [v2]
In-Reply-To: <X6sCtbR-GcuJe95mp-kJmQ_dkNS5eogiP5ov6zSwB30=.da52c8b6-e3ce-485a-9bfd-fbe6b4cd77f5@github.com>
References: <ydhogvsR2STcb7WGAQCjAua5l25gEd16Kjh_A0meInA=.92082d43-9187-47e4-b741-2fe059afb1bc@github.com>
 <X6sCtbR-GcuJe95mp-kJmQ_dkNS5eogiP5ov6zSwB30=.da52c8b6-e3ce-485a-9bfd-fbe6b4cd77f5@github.com>
Message-ID: <lLkZpkzOv-1zBOGIhJecyM6MfjIe1tCpZXDhnix5SG0=.dc434407-35da-425b-b090-96e846e3aa17@github.com>

On Wed, 7 Aug 2024 15:12:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   - Incorporate comment suggestion from @magicus. Also applied some additional minor adjustments on top of the suggestion.
>
> make/common/native/Link.gmk line 114:
> 
>> 112:           # Linking with '-Wl,--icf=safe' using objects created by 'ld -r' may not work
>> 113:           # and could cause errors like the following:
>> 114:           #   ld: --icf=safe conservatively ignores SHT_LLVM_ADDRSIG [...] with sh_link=0 (likely created using objcopy or ld -r)
> 
> I'd recommend rephrasing the comment somewhat, like
> 
> Suggestion:
> 
>           # 'ld -r' might fail to update the .llvm_addrsig section, and this will cause subsequent
>           # calls to lld to fail when linking with this library, so remove that section.
> 
> 
> (adjust line lengths if > 80)

Suggestion applied, with some minor additional adjustments. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20265#discussion_r1707851591

From jiangli at openjdk.org  Wed Aug  7 20:59:32 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 7 Aug 2024 20:59:32 GMT
Subject: RFR: 8336849: Remove .llvm_addrsig section from JDK/VM static
 libraries (.a files)
In-Reply-To: <iHuqyYH8SEl2Qy0qVs_NMiMN8yqk4Lk7yeaDSa71O-M=.31636fd9-321c-45d1-8fca-afeaedcdd7ff@github.com>
References: <ydhogvsR2STcb7WGAQCjAua5l25gEd16Kjh_A0meInA=.92082d43-9187-47e4-b741-2fe059afb1bc@github.com>
 <iHuqyYH8SEl2Qy0qVs_NMiMN8yqk4Lk7yeaDSa71O-M=.31636fd9-321c-45d1-8fca-afeaedcdd7ff@github.com>
Message-ID: <xSl4_GQ7a0O14be5zvNDUDFoU17NyV4LEUOU6_9vNd0=.f3fb9af6-3524-4d66-ad2e-baa0d250137f@github.com>

On Wed, 7 Aug 2024 15:07:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Are you saying that even using strip can cause lld malfunction? 

Based on the referenced discussion thread, that seems to be the case. I haven't tested with strip for this issue.

> Is there any chance we risk running into problems that way?

I'm not too concerned with this case for `strip` regarding the static libraries in JDK/VM. We had some internal discussions with tools (e.g. profiler) experts about debugging info with `libjvm.a` in the past. I think we would want to keep the debugging info in `libjvm.a` and strip the final elf binary only to suitably support tools' requirements (it's worth also discussing more details on the debugging info in JDK static libraries in our mailing list here at some point).  In that sense, `strip` probably is not a concern for `libjvm.a`, `libjava`, and etc. 

@magicus, thanks for the thoroughness in the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20265#issuecomment-2274333311

From liach at openjdk.org  Wed Aug  7 21:49:31 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 Aug 2024 21:49:31 GMT
Subject: RFR: 8335880: More troubleshooting tips around windows space in
 path [v3]
In-Reply-To: <ptF1eU0FrKynl0-RNxK_nTma7VvFGWAcCWPhX_hrPw0=.0a4fac67-9c69-4c46-8800-cb7ff9ef1fce@github.com>
References: <w5TjafnC5QZ8V5Atd3eBEh86c1mdmhXH0D9f25bY7Xs=.528de2c6-0f89-4c58-9c98-16c5fb19e790@github.com>
 <ZixjNaACu8HNkDtzRx9jb4hMvi1VQn7jg3ZT0tbPhuI=.2fe62c2c-9bd0-4dc7-b569-b6496d91b329@github.com>
 <aQ50p44tUN9XA6Ps2tYetlgzulQcETDp0-WXQbPnnuQ=.6f64a2e8-537d-4aca-8bed-c82b93a4ada5@github.com>
 <s0G3j--MZD878ZdqW_eB8SgjIGk-qomBW-MTLPQscNA=.ea971d73-84d7-428d-9a8f-4fb43a173814@github.com>
 <ptF1eU0FrKynl0-RNxK_nTma7VvFGWAcCWPhX_hrPw0=.0a4fac67-9c69-4c46-8800-cb7ff9ef1fce@github.com>
Message-ID: <gET6TTczSkmDm_GU3eP1oXPYBiSANwxJeiPdqUnYHqw=.b32954f1-16ab-450e-adf9-98eb2d009f2b@github.com>

On Mon, 5 Aug 2024 15:58:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> configure scans `PATH` which may include other spaced directories, such as "Intellij Idea." On a user device, this list can quickly become huge and it would be unrealistic for users to generate short paths for every single one of those directories.
>> 
>> In fact, the only 2 directories that need short path configuration for configure to work correctly are Microsoft Visual Studio and Windows Kits.
>
> Hm, it feels buggy that it should complain about random entries in the PATH; it should only be an issue if we try to FIXUP a path. I need to look into that.

Can I leave this part as-is?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20197#discussion_r1707970060

From zzambers at redhat.com  Tue Aug  6 18:10:21 2024
From: zzambers at redhat.com (=?UTF-8?B?WmRlbsSbayDFvWFtYmVyc2vDvQ==?=)
Date: Tue, 6 Aug 2024 20:10:21 +0200
Subject: jdk8u: -Wno-regsiter to support newer compilers
In-Reply-To: <8e27b2e0-0e1b-4a2e-909b-5db0c0fac582@oracle.com>
References: <CAHNTFmK9nUQ1YqYgD6sRwiAhBru0yCEXO6aSa-XM5ds2BHrOOA@mail.gmail.com>
 <8e27b2e0-0e1b-4a2e-909b-5db0c0fac582@oracle.com>
Message-ID: <ec4d8d3c-440f-4dc8-ba5e-e89900603a88@redhat.com>

Hello,

this is known issue, which should get fixed by JDK-8281096:
https://github.com/openjdk/jdk8u-dev/pull/357

(see also: https://github.com/openjdk/jdk8u-dev/pull/508)

TLDR:
Jdk 8 explicitly specifies older c++ version (gnu++98, which not yet 
deprecated
'register' keyword), but flags are not propagated to ADLC build due to bug.
(correct me, if I am wrong)


When it comes to Adoptium, I don't know exactly, but I think they are using
older compiler, which uses older c++ standard by default.

On 06. 08. 24 18:37, Magnus Ihse Bursie wrote:
> Hi Elazar,
>
> I see that you never got any replies here. I suggest that you re-ask 
> your question on the jdk8u mailing list instead (cc'd).
>
> /Magnus
>
> On 2024-07-19 16:20, Elazar Leibovich wrote:
>> When trying to compile the latest jdk8u on linux I get failures over 
>> warnings with the register keywords.
>>
>> I'm using https://github.com/openjdk/jdk8u-dev.git which seems to be 
>> pretty up to date (I'm using master), and last commit is less than 
>> two days ago.
>>
>> This is a workaround I had to use:
>> diff --git a/hotspot/make/linux/makefiles/gcc.make 
>> b/hotspot/make/linux/makefiles/gcc.make
>> index 7dde7f0963..81f156574a 100644
>> --- a/hotspot/make/linux/makefiles/gcc.make
>> +++ b/hotspot/make/linux/makefiles/gcc.make
>> @@ -202,7 +202,7 @@ else
>> ?endif
>>
>> ?# Compiler warnings are treated as errors
>> -WARNINGS_ARE_ERRORS = -Werror
>> +WARNINGS_ARE_ERRORS = -Werror -Wno-register
>>
>> But I guess the best solution is to remove the register keywords from 
>> the codebase.
>>
>> How is adoptium?building it? Does it use specific compiler? Is the 
>> supported compiler documented anywhere?
>>
>> FTR using temurin-build repository and scripts, fails for other 
>> reasons, and fails even with -D/--podman docker containers.
>>
>> This patch builds it with centos stream 9 on amd64.
>>
>> Am I doing something wrong? What's the recommended way of building jdk8?
>>
>> Thanks,
>> Elazar Leibovich
>

-- 
Zden?k ?ambersk?
OpenJDK QE
Red Hat


From zzambers at redhat.com  Wed Aug  7 12:02:13 2024
From: zzambers at redhat.com (=?UTF-8?B?WmRlbsSbayDFvWFtYmVyc2vDvQ==?=)
Date: Wed, 7 Aug 2024 14:02:13 +0200
Subject: jdk8u: -Wno-regsiter to support newer compilers
In-Reply-To: <CAHNTFmJsc+KyeDsMPrNa43fw2oe6AQd3yDPNmdk-a5Jkt01ciw@mail.gmail.com>
References: <CAHNTFmK9nUQ1YqYgD6sRwiAhBru0yCEXO6aSa-XM5ds2BHrOOA@mail.gmail.com>
 <8e27b2e0-0e1b-4a2e-909b-5db0c0fac582@oracle.com>
 <ec4d8d3c-440f-4dc8-ba5e-e89900603a88@redhat.com>
 <CAHNTFmKDVEwfkELFJViWrG0CyA2Up4Na7ZV26siBKkVAenEazA@mail.gmail.com>
 <c00f4bd4-a59d-4970-8089-455fbe1700ca@oracle.com>
 <CAHNTFmJsc+KyeDsMPrNa43fw2oe6AQd3yDPNmdk-a5Jkt01ciw@mail.gmail.com>
Message-ID: <0a027333-1971-491a-8789-a7d0849a37b5@redhat.com>

I think to have jdk8 build work out of box, it is better to use older OSes.
Like rhel/centos <= 8. You can use VM or container.
I personally usually use rhel-8 VM, if I want to build jdk8 locally.

Others distros, which should work:
Ubuntu <= 20.04
debian <= bullseye (I think)

When it comes to vendors providing JDK 8 builds, I think they generally use
older linux distros (like rhel-6/7 or equivalent) to maximize portability.

I cannot really comment much on Mac OS X. I have never owned mac.
GHA was just recently updated macos-13. (there are still some issues to 
solve there)
https://github.com/openjdk/jdk8u-dev/pull/544

I don't think MacOS/aarch64 is even supported currently, at least I am 
not aware of any work in that regard.
May need some additional patching. (Adoptium does not offer MacOS/aarch64.)


However if you just want to test some changes, you can just use GHA. You 
can do test branch,
with modified GHA workflow to run test groups, you are interested in, on 
top of your changes.


On 06. 08. 24 20:42, Elazar Leibovich wrote:
> Thanks,
> I did follow the readme, but could not find any commentary about the 
> build environment or the required compilers.
> Even less information was on Mac OS X, where the autoconf files seems 
> not to be updated, and as a result arm was chosen instead of aarch64.
>
> If you can point me to a specific section in the documentation 
> specifying, say, a list of known good compilers, I'll be grateful.
>
> On Tue, 6 Aug 2024 at 21:37, Magnus Ihse Bursie 
> <magnus.ihse.bursie at oracle.com> wrote:
>
>     On 2024-08-06 20:33, Elazar Leibovich wrote:
>
>>     Thanks,
>>     I still fail to understand how JDK8u developers are building the
>>     project.
>
>     Setting up a build environment for jdk8 is unfortunately not a
>     trivial task. The build readme can be of some use:
>     https://github.com/openjdk/jdk8u-dev/blob/master/doc/building.md.
>     The build system has gone through a complete overhaul in later
>     versions, so if you were to build the mainline JDK it would be a
>     much smoother experience. After all, JDK 8 was released 10 years
>     ago, and much has happened since then.
>
>     /Magnus
>
>
>
>>     Is there a docker file specifying the build environment? What's
>>     the recommended way of doing that?
>>     Removing the register keyword, plus disabling an overflow warning
>>     in a specific test with pragma did the?trick for me, but:
>>     1. I could not get it built in Mac OS X
>>     2. I felt as if I'm paving my own path building it, instead of
>>     following the Yellow Brick Road, which I'm trying to locate.
>>
>>     Thanks again,
>>
>>     On Tue, 6 Aug 2024 at 21:10, Zden?k ?ambersk?
>>     <zzambers at redhat.com> wrote:
>>
>>         Hello,
>>
>>         this is known issue, which should get fixed by JDK-8281096:
>>         https://github.com/openjdk/jdk8u-dev/pull/357
>>
>>         (see also: https://github.com/openjdk/jdk8u-dev/pull/508)
>>
>>         TLDR:
>>         Jdk 8 explicitly specifies older c++ version (gnu++98, which
>>         not yet
>>         deprecated
>>         'register' keyword), but flags are not propagated to ADLC
>>         build due to bug.
>>         (correct me, if I am wrong)
>>
>>
>>         When it comes to Adoptium, I don't know exactly, but I think
>>         they are using
>>         older compiler, which uses older c++ standard by default.
>>
>>         On 06. 08. 24 18:37, Magnus Ihse Bursie wrote:
>>         > Hi Elazar,
>>         >
>>         > I see that you never got any replies here. I suggest that
>>         you re-ask
>>         > your question on the jdk8u mailing list instead (cc'd).
>>         >
>>         > /Magnus
>>         >
>>         > On 2024-07-19 16:20, Elazar Leibovich wrote:
>>         >> When trying to compile the latest jdk8u on linux I get
>>         failures over
>>         >> warnings with the register keywords.
>>         >>
>>         >> I'm using https://github.com/openjdk/jdk8u-dev.git which
>>         seems to be
>>         >> pretty up to date (I'm using master), and last commit is
>>         less than
>>         >> two days ago.
>>         >>
>>         >> This is a workaround I had to use:
>>         >> diff --git a/hotspot/make/linux/makefiles/gcc.make
>>         >> b/hotspot/make/linux/makefiles/gcc.make
>>         >> index 7dde7f0963..81f156574a 100644
>>         >> --- a/hotspot/make/linux/makefiles/gcc.make
>>         >> +++ b/hotspot/make/linux/makefiles/gcc.make
>>         >> @@ -202,7 +202,7 @@ else
>>         >> ?endif
>>         >>
>>         >> ?# Compiler warnings are treated as errors
>>         >> -WARNINGS_ARE_ERRORS = -Werror
>>         >> +WARNINGS_ARE_ERRORS = -Werror -Wno-register
>>         >>
>>         >> But I guess the best solution is to remove the register
>>         keywords from
>>         >> the codebase.
>>         >>
>>         >> How is adoptium?building it? Does it use specific
>>         compiler? Is the
>>         >> supported compiler documented anywhere?
>>         >>
>>         >> FTR using temurin-build repository and scripts, fails for
>>         other
>>         >> reasons, and fails even with -D/--podman docker containers.
>>         >>
>>         >> This patch builds it with centos stream 9 on amd64.
>>         >>
>>         >> Am I doing something wrong? What's the recommended way of
>>         building jdk8?
>>         >>
>>         >> Thanks,
>>         >> Elazar Leibovich
>>         >
>>
>>         -- 
>>         Zden?k ?ambersk?
>>         OpenJDK QE
>>         Red Hat
>>

-- 
Zden?k ?ambersk?
OpenJDK QE
Red Hat


From t.glaser at qvest-digital.com  Wed Aug  7 12:12:09 2024
From: t.glaser at qvest-digital.com (Thorsten Glaser)
Date: Wed, 7 Aug 2024 14:12:09 +0200 (CEST)
Subject: jdk8u: -Wno-regsiter to support newer compilers
In-Reply-To: <0a027333-1971-491a-8789-a7d0849a37b5@redhat.com>
References: <CAHNTFmK9nUQ1YqYgD6sRwiAhBru0yCEXO6aSa-XM5ds2BHrOOA@mail.gmail.com>
 <8e27b2e0-0e1b-4a2e-909b-5db0c0fac582@oracle.com>
 <ec4d8d3c-440f-4dc8-ba5e-e89900603a88@redhat.com>
 <CAHNTFmKDVEwfkELFJViWrG0CyA2Up4Na7ZV26siBKkVAenEazA@mail.gmail.com>
 <c00f4bd4-a59d-4970-8089-455fbe1700ca@oracle.com>
 <CAHNTFmJsc+KyeDsMPrNa43fw2oe6AQd3yDPNmdk-a5Jkt01ciw@mail.gmail.com>
 <0a027333-1971-491a-8789-a7d0849a37b5@redhat.com>
Message-ID: <b004c86f-754b-53ad-3544-668ffe6b3f13@qvest-digital.com>

On Wed, 7 Aug 2024, Zden?k ?ambersk? wrote:

> Others distros, which should work:
> Ubuntu <= 20.04
> debian <= bullseye (I think)

I maintain OpenJDK 8 for Debian, and my own (local repo and PPA),
Debian?s and Ubuntu?s own builds cover Debian wheezy (7) up to
unstable and all Ubuntu LTS versions from 14.04 on and the few
recent n?n-LTS releases, although they use the GCC version that
is appropriate for each.

https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/openjdk-8.git;a=blob;f=debian/rules;h=b1854f48be30d0d1cef2f026dd2019ae85965a73;hb=HEAD#l259

I?ve not yet gone to 14, the distros switched to it only very
recently (maybe two weeks or so ago).

bye,
//mirabilos
-- 
Infrastrukturexperte ? Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn ? https://www.qvest-digital.com/
Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
HRB AG Bonn 18196 ? USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter N?then

From zzambers at redhat.com  Wed Aug  7 17:49:23 2024
From: zzambers at redhat.com (=?UTF-8?B?WmRlbsSbayDFvWFtYmVyc2vDvQ==?=)
Date: Wed, 7 Aug 2024 19:49:23 +0200
Subject: jdk8u: -Wno-regsiter to support newer compilers
In-Reply-To: <b004c86f-754b-53ad-3544-668ffe6b3f13@qvest-digital.com>
References: <CAHNTFmK9nUQ1YqYgD6sRwiAhBru0yCEXO6aSa-XM5ds2BHrOOA@mail.gmail.com>
 <8e27b2e0-0e1b-4a2e-909b-5db0c0fac582@oracle.com>
 <ec4d8d3c-440f-4dc8-ba5e-e89900603a88@redhat.com>
 <CAHNTFmKDVEwfkELFJViWrG0CyA2Up4Na7ZV26siBKkVAenEazA@mail.gmail.com>
 <c00f4bd4-a59d-4970-8089-455fbe1700ca@oracle.com>
 <CAHNTFmJsc+KyeDsMPrNa43fw2oe6AQd3yDPNmdk-a5Jkt01ciw@mail.gmail.com>
 <0a027333-1971-491a-8789-a7d0849a37b5@redhat.com>
 <b004c86f-754b-53ad-3544-668ffe6b3f13@qvest-digital.com>
Message-ID: <dc7b6b5f-8fd0-49c9-a36e-f931b936a3ca@redhat.com>

Just to clarify, I meant distros, which should just work out of box 
(currently).
That is: installation of dependencies -> configure -> make.

According to documentation, without patching, explicit/custom toolchain 
configuration, etc..
(newer distros often need some additional effort due to newer toolchain)


On 07. 08. 24 14:12, Thorsten Glaser wrote:
> On Wed, 7 Aug 2024, Zden?k ?ambersk? wrote:
>
>> Others distros, which should work:
>> Ubuntu <= 20.04
>> debian <= bullseye (I think)
> I maintain OpenJDK 8 for Debian, and my own (local repo and PPA),
> Debian?s and Ubuntu?s own builds cover Debian wheezy (7) up to
> unstable and all Ubuntu LTS versions from 14.04 on and the few
> recent n?n-LTS releases, although they use the GCC version that
> is appropriate for each.
>
> https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/openjdk-8.git;a=blob;f=debian/rules;h=b1854f48be30d0d1cef2f026dd2019ae85965a73;hb=HEAD#l259
>
> I?ve not yet gone to 14, the distros switched to it only very
> recently (maybe two weeks or so ago).
>
> bye,
> //mirabilos

-- 
Zden?k ?ambersk?
OpenJDK QE
Red Hat


From david.holmes at oracle.com  Thu Aug  8 04:26:14 2024
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 8 Aug 2024 14:26:14 +1000
Subject: Request for assistance in analyzing JDK crash without logs
In-Reply-To: <CAPGG-75jVo91rLMu+LS245Hc-A8dGHSDddjHY6VT4em5_O+f7A@mail.gmail.com>
References: <CAPGG-75jVo91rLMu+LS245Hc-A8dGHSDddjHY6VT4em5_O+f7A@mail.gmail.com>
Message-ID: <0d84fee9-c3da-4268-aeea-63188824cd19@oracle.com>

On 7/08/2024 3:56 pm, qia nxiao wrote:
> Hello
> 
> After compiling and packaging in the local environment, I encountered a 
> crash when using the packaged JDK, and there are no relevant logs. Is 
> there any good method to analyze the cause of the crash?

Is there a core dump?

Does this happen immediately on startup? Otherwise there should be a 
hs_err<pid>.log file created.

David
-----

> Thanks

From zenghuichen1997 at gmail.com  Thu Aug  8 06:02:02 2024
From: zenghuichen1997 at gmail.com (qia nxiao)
Date: Thu, 8 Aug 2024 14:02:02 +0800
Subject: Error encountered while packaging version 21.0.3-9 in Windows
 environment
Message-ID: <CAPGG-76o2h7wyutT5L0eWFj57kYVZ8jSL84n+AKGZ4D=Cgy61Q@mail.gmail.com>

Hello

When I try to package version 21.0.3-9 in a Windows environment, I
encounter the following error message. Can you help me figure out what
might be causing it?

d:\code\java\jdk21u-jdk-21.0.3-9\src\hotspot\share\runtime/atomic.hpp(1000):
> error C2027: use of undefined type 'Atomic::CmpxchgImpl<D,U,T,void>'
>
>         with
>
>         [
>
>             D=jint,
>
>             U=int,
>
>             T=int
>
>         ]
>
> d:\code\java\jdk21u-jdk-21.0.3-9\src\hotspot\share\runtime/atomic.hpp(1000):
> note: see declaration of 'Atomic::CmpxchgImpl<D,U,T,void>'
>
>         with
>
>         [
>
>             D=jint,
>
>             U=int,
>
>             T=int
>
>         ]
>

 Here is the compilation command I executed.

> bash configure --with-boot-jdk='d:/Program Files/graalvm/jdk-21.0.3+9'
> --with-toolchain-version=2019 --enable-debug
> --with-tools-dir='d:/tool/vs2019/ide/VC/Auxiliary/Build'
>
make images


Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240808/5679d368/attachment.htm>

From dfuchs at openjdk.org  Thu Aug  8 09:19:41 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 Aug 2024 09:19:41 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
Message-ID: <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>

On Wed, 7 Aug 2024 15:59:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge
>  - 8337143: Removed dependency of libjava on headers in libnio/ch
>  - 8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio
>  - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava

Disclaimer: I have not tried to understand the proposed change in details. However I have spotted a small oddity.

src/java.base/share/classes/java/net/Inet6AddressImpl.java line 154:

> 152:     static {
> 153:         jdk.internal.loader.BootLoader.loadLibrary("net");
> 154:     }

I am curious about this change - wouldn't it be needed in Inet4AddressImpl as well?

src/java.base/windows/native/libjava/IOUtil.c line 37:

> 35: #include "nio.h"
> 36: #include "nio_util.h"
> 37: /* #include "net_util.h" */

Is this change intended or is this a left over from some experimentation?

-------------

PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2227299000
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709024031
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709029492

From zzambers at redhat.com  Thu Aug  8 10:41:18 2024
From: zzambers at redhat.com (=?UTF-8?B?WmRlbsSbayDFvWFtYmVyc2vDvQ==?=)
Date: Thu, 8 Aug 2024 12:41:18 +0200
Subject: jdk8u: -Wno-regsiter to support newer compilers
In-Reply-To: <0a027333-1971-491a-8789-a7d0849a37b5@redhat.com>
References: <CAHNTFmK9nUQ1YqYgD6sRwiAhBru0yCEXO6aSa-XM5ds2BHrOOA@mail.gmail.com>
 <8e27b2e0-0e1b-4a2e-909b-5db0c0fac582@oracle.com>
 <ec4d8d3c-440f-4dc8-ba5e-e89900603a88@redhat.com>
 <CAHNTFmKDVEwfkELFJViWrG0CyA2Up4Na7ZV26siBKkVAenEazA@mail.gmail.com>
 <c00f4bd4-a59d-4970-8089-455fbe1700ca@oracle.com>
 <CAHNTFmJsc+KyeDsMPrNa43fw2oe6AQd3yDPNmdk-a5Jkt01ciw@mail.gmail.com>
 <0a027333-1971-491a-8789-a7d0849a37b5@redhat.com>
Message-ID: <c5447343-a122-4d22-ba23-8086176e2431@redhat.com>

On 07. 08. 24 14:02, Zden?k ?ambersk? wrote:
> I think to have jdk8 build work out of box, it is better to use older 
> OSes.
> Like rhel/centos <= 8. You can use VM or container.
> I personally usually use rhel-8 VM, if I want to build jdk8 locally.
>
> Others distros, which should work:
> Ubuntu <= 20.04
> debian <= bullseye (I think)
>
> When it comes to vendors providing JDK 8 builds, I think they 
> generally use
> older linux distros (like rhel-6/7 or equivalent) to maximize 
> portability.
>
> I cannot really comment much on Mac OS X. I have never owned mac.
> GHA was just recently updated macos-13. (there are still some issues 
> to solve there)
> https://github.com/openjdk/jdk8u-dev/pull/544
>
> I don't think MacOS/aarch64 is even supported currently, at least I am 
> not aware of any work in that regard.
> May need some additional patching. (Adoptium does not offer 
> MacOS/aarch64.)
>

Here is the bug for MacOS/aarch64port:
https://bugs.openjdk.org/browse/JDK-8253795

It has not been backported to openjdk8. You may be able to build zero 
port on MacOS/aarc64,
but it will be much slower compared to "full" ports.

>
> However if you just want to test some changes, you can just use GHA. 
> You can do test branch,
> with modified GHA workflow to run test groups, you are interested in, 
> on top of your changes.
>
>
> On 06. 08. 24 20:42, Elazar Leibovich wrote:
>> Thanks,
>> I did follow the readme, but could not find any commentary about the 
>> build environment or the required compilers.
>> Even less information was on Mac OS X, where the autoconf files seems 
>> not to be updated, and as a result arm was chosen instead of aarch64.
>>
>> If you can point me to a specific section in the documentation 
>> specifying, say, a list of known good compilers, I'll be grateful.
>>
>> On Tue, 6 Aug 2024 at 21:37, Magnus Ihse Bursie 
>> <magnus.ihse.bursie at oracle.com> wrote:
>>
>> ??? On 2024-08-06 20:33, Elazar Leibovich wrote:
>>
>>> ??? Thanks,
>>> ??? I still fail to understand how JDK8u developers are building the
>>> ??? project.
>>
>> ??? Setting up a build environment for jdk8 is unfortunately not a
>> ??? trivial task. The build readme can be of some use:
>> https://github.com/openjdk/jdk8u-dev/blob/master/doc/building.md.
>> ??? The build system has gone through a complete overhaul in later
>> ??? versions, so if you were to build the mainline JDK it would be a
>> ??? much smoother experience. After all, JDK 8 was released 10 years
>> ??? ago, and much has happened since then.
>>
>> ??? /Magnus
>>
>>
>>
>>> ??? Is there a docker file specifying the build environment? What's
>>> ??? the recommended way of doing that?
>>> ??? Removing the register keyword, plus disabling an overflow warning
>>> ??? in a specific test with pragma did the?trick for me, but:
>>> ??? 1. I could not get it built in Mac OS X
>>> ??? 2. I felt as if I'm paving my own path building it, instead of
>>> ??? following the Yellow Brick Road, which I'm trying to locate.
>>>
>>> ??? Thanks again,
>>>
>>> ??? On Tue, 6 Aug 2024 at 21:10, Zden?k ?ambersk?
>>> ??? <zzambers at redhat.com> wrote:
>>>
>>> ??????? Hello,
>>>
>>> ??????? this is known issue, which should get fixed by JDK-8281096:
>>> ??????? https://github.com/openjdk/jdk8u-dev/pull/357
>>>
>>> ??????? (see also: https://github.com/openjdk/jdk8u-dev/pull/508)
>>>
>>> ??????? TLDR:
>>> ??????? Jdk 8 explicitly specifies older c++ version (gnu++98, which
>>> ??????? not yet
>>> ??????? deprecated
>>> ??????? 'register' keyword), but flags are not propagated to ADLC
>>> ??????? build due to bug.
>>> ??????? (correct me, if I am wrong)
>>>
>>>
>>> ??????? When it comes to Adoptium, I don't know exactly, but I think
>>> ??????? they are using
>>> ??????? older compiler, which uses older c++ standard by default.
>>>
>>> ??????? On 06. 08. 24 18:37, Magnus Ihse Bursie wrote:
>>> ??????? > Hi Elazar,
>>> ??????? >
>>> ??????? > I see that you never got any replies here. I suggest that
>>> ??????? you re-ask
>>> ??????? > your question on the jdk8u mailing list instead (cc'd).
>>> ??????? >
>>> ??????? > /Magnus
>>> ??????? >
>>> ??????? > On 2024-07-19 16:20, Elazar Leibovich wrote:
>>> ??????? >> When trying to compile the latest jdk8u on linux I get
>>> ??????? failures over
>>> ??????? >> warnings with the register keywords.
>>> ??????? >>
>>> ??????? >> I'm using https://github.com/openjdk/jdk8u-dev.git which
>>> ??????? seems to be
>>> ??????? >> pretty up to date (I'm using master), and last commit is
>>> ??????? less than
>>> ??????? >> two days ago.
>>> ??????? >>
>>> ??????? >> This is a workaround I had to use:
>>> ??????? >> diff --git a/hotspot/make/linux/makefiles/gcc.make
>>> ??????? >> b/hotspot/make/linux/makefiles/gcc.make
>>> ??????? >> index 7dde7f0963..81f156574a 100644
>>> ??????? >> --- a/hotspot/make/linux/makefiles/gcc.make
>>> ??????? >> +++ b/hotspot/make/linux/makefiles/gcc.make
>>> ??????? >> @@ -202,7 +202,7 @@ else
>>> ??????? >> ?endif
>>> ??????? >>
>>> ??????? >> ?# Compiler warnings are treated as errors
>>> ??????? >> -WARNINGS_ARE_ERRORS = -Werror
>>> ??????? >> +WARNINGS_ARE_ERRORS = -Werror -Wno-register
>>> ??????? >>
>>> ??????? >> But I guess the best solution is to remove the register
>>> ??????? keywords from
>>> ??????? >> the codebase.
>>> ??????? >>
>>> ??????? >> How is adoptium?building it? Does it use specific
>>> ??????? compiler? Is the
>>> ??????? >> supported compiler documented anywhere?
>>> ??????? >>
>>> ??????? >> FTR using temurin-build repository and scripts, fails for
>>> ??????? other
>>> ??????? >> reasons, and fails even with -D/--podman docker containers.
>>> ??????? >>
>>> ??????? >> This patch builds it with centos stream 9 on amd64.
>>> ??????? >>
>>> ??????? >> Am I doing something wrong? What's the recommended way of
>>> ??????? building jdk8?
>>> ??????? >>
>>> ??????? >> Thanks,
>>> ??????? >> Elazar Leibovich
>>> ??????? >
>>>
>>> ??????? -- ??????? Zden?k ?ambersk?
>>> ??????? OpenJDK QE
>>> ??????? Red Hat
>>>
>

-- 
Zden?k ?ambersk?
OpenJDK QE
Red Hat


From azvegint at openjdk.org  Thu Aug  8 10:54:40 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 8 Aug 2024 10:54:40 GMT
Subject: Integrated: 8329471: Remove GTK2
In-Reply-To: <JABMEI4R7RPqCP6MjBvzP-0c3Mb-siUcFJQEQ1aFUJo=.96b6712e-10b3-490b-a57f-c57a130710c8@github.com>
References: <JABMEI4R7RPqCP6MjBvzP-0c3Mb-siUcFJQEQ1aFUJo=.96b6712e-10b3-490b-a57f-c57a130710c8@github.com>
Message-ID: <CkxyMzhwbWOS7YCteWvUxJiFcM43cEW2Sk6zs5V9RB4=.27913e42-34e7-40a5-a9d1-43d10d06bee8@github.com>

On Mon, 29 Jul 2024 14:55:07 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> GTK2 support for Swing/AWT was deprecated for removal in JDK 21. 
> 
> It's being removed because no platform that supports the JDK needs it.
> 
> Manual and automated testing is green.

This pull request has now been integrated.

Changeset: 12c553f1
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/12c553f12876b4095685676f800119c0e275bf44
Stats:     3352 lines in 17 files changed: 4 ins; 3298 del; 50 mod

8329471: Remove GTK2

Reviewed-by: abhiscxk, prr, ihse

-------------

PR: https://git.openjdk.org/jdk/pull/20378

From ihse at openjdk.org  Thu Aug  8 12:20:36 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 8 Aug 2024 12:20:36 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <3svWg4OOtXThIl3WVV4kwOafudlnHmlREaqFSAfR9mI=.a9ce7e75-3275-4ab1-bbf7-f75f91788a6d@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
 <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
 <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>
 <3svWg4OOtXThIl3WVV4kwOafudlnHmlREaqFSAfR9mI=.a9ce7e75-3275-4ab1-bbf7-f75f91788a6d@github.com>
Message-ID: <v9EWejZCkBwRGhgfKKdOetI97OVPY0iJTNRwU7hVduc=.b01458ec-7d81-4106-b1cc-6afd2386e4c3@github.com>

On Wed, 7 Aug 2024 18:13:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> `CoreServices` is still necessary ([Uniform Type Identifier](https://developer.apple.com/documentation/uniformtypeidentifiers)s).
>
> The Windows libs are also still required for `TransmitFile` and `WSAGetLastError`:
> 
> - ```mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile```
> - ```ws2_32.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol __imp_WSAGetLastError```

And pthread?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709362110

From ihse at openjdk.org  Thu Aug  8 12:22:32 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 8 Aug 2024 12:22:32 GMT
Subject: RFR: 8336849: Remove .llvm_addrsig section from JDK/VM static
 libraries (.a files) [v2]
In-Reply-To: <JTBNmPHO6cWtVgdAm9Z9lji-Rdb9Yop3iHRfZiFX-UE=.eaa9b5f2-d6a7-446e-8842-6bc20268170f@github.com>
References: <ydhogvsR2STcb7WGAQCjAua5l25gEd16Kjh_A0meInA=.92082d43-9187-47e4-b741-2fe059afb1bc@github.com>
 <JTBNmPHO6cWtVgdAm9Z9lji-Rdb9Yop3iHRfZiFX-UE=.eaa9b5f2-d6a7-446e-8842-6bc20268170f@github.com>
Message-ID: <YJliTYczRuc5idvKbMBj7vxXVAFmbB4_PoDwCQJjN4E=.163a89fe-6298-4ff1-b2f6-f477a2e27434@github.com>

On Wed, 7 Aug 2024 20:35:05 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this PR that strips the `.llvm_addrsig` section from JDK and hotspot `.a` static libraries when building with clang. Please see https://bugs.openjdk.org/browse/JDK-8336849 description for details.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Incorporate comment suggestion from @magicus. Also applied some additional minor adjustments on top of the suggestion.

Marked as reviewed by ihse (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20265#pullrequestreview-2227701225

From ihse at openjdk.org  Thu Aug  8 12:29:32 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 8 Aug 2024 12:29:32 GMT
Subject: RFR: 8335880: More troubleshooting tips around windows space in
 path [v3]
In-Reply-To: <gET6TTczSkmDm_GU3eP1oXPYBiSANwxJeiPdqUnYHqw=.b32954f1-16ab-450e-adf9-98eb2d009f2b@github.com>
References: <w5TjafnC5QZ8V5Atd3eBEh86c1mdmhXH0D9f25bY7Xs=.528de2c6-0f89-4c58-9c98-16c5fb19e790@github.com>
 <ZixjNaACu8HNkDtzRx9jb4hMvi1VQn7jg3ZT0tbPhuI=.2fe62c2c-9bd0-4dc7-b569-b6496d91b329@github.com>
 <aQ50p44tUN9XA6Ps2tYetlgzulQcETDp0-WXQbPnnuQ=.6f64a2e8-537d-4aca-8bed-c82b93a4ada5@github.com>
 <s0G3j--MZD878ZdqW_eB8SgjIGk-qomBW-MTLPQscNA=.ea971d73-84d7-428d-9a8f-4fb43a173814@github.com>
 <ptF1eU0FrKynl0-RNxK_nTma7VvFGWAcCWPhX_hrPw0=.0a4fac67-9c69-4c46-8800-cb7ff9ef1fce@github.com>
 <gET6TTczSkmDm_GU3eP1oXPYBiSANwxJeiPdqUnYHqw=.b32954f1-16ab-450e-adf9-98eb2d009f2b@github.com>
Message-ID: <1Nm2kZMiJcaWUsS6BLm6Ybg2aJyDSw5gZ8rvKXUq1Mo=.557fa18b-127e-4d05-9903-d1cc8b1f1a69@github.com>

On Wed, 7 Aug 2024 21:47:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hm, it feels buggy that it should complain about random entries in the PATH; it should only be an issue if we try to FIXUP a path. I need to look into that.
>
> Can I leave this part as-is?

Yes, leave it in this patch to the documentation. If I address the core issue in configure, I'll update the docs as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20197#discussion_r1709379028

From ihse at openjdk.org  Thu Aug  8 12:32:32 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 8 Aug 2024 12:32:32 GMT
Subject: RFR: 8335880: More troubleshooting tips around windows space in
 path [v3]
In-Reply-To: <1Nm2kZMiJcaWUsS6BLm6Ybg2aJyDSw5gZ8rvKXUq1Mo=.557fa18b-127e-4d05-9903-d1cc8b1f1a69@github.com>
References: <w5TjafnC5QZ8V5Atd3eBEh86c1mdmhXH0D9f25bY7Xs=.528de2c6-0f89-4c58-9c98-16c5fb19e790@github.com>
 <ZixjNaACu8HNkDtzRx9jb4hMvi1VQn7jg3ZT0tbPhuI=.2fe62c2c-9bd0-4dc7-b569-b6496d91b329@github.com>
 <aQ50p44tUN9XA6Ps2tYetlgzulQcETDp0-WXQbPnnuQ=.6f64a2e8-537d-4aca-8bed-c82b93a4ada5@github.com>
 <s0G3j--MZD878ZdqW_eB8SgjIGk-qomBW-MTLPQscNA=.ea971d73-84d7-428d-9a8f-4fb43a173814@github.com>
 <ptF1eU0FrKynl0-RNxK_nTma7VvFGWAcCWPhX_hrPw0=.0a4fac67-9c69-4c46-8800-cb7ff9ef1fce@github.com>
 <gET6TTczSkmDm_GU3eP1oXPYBiSANwxJeiPdqUnYHqw=.b32954f1-16ab-450e-adf9-98eb2d009f2b@github.com>
 <1Nm2kZMiJcaWUsS6BLm6Ybg2aJyDSw5gZ8rvKXUq1Mo=.557fa18b-127e-4d05-9903-d1cc8b1f1a69@github.com>
Message-ID: <venzcLgnObNSCllWMxKornwPctUPrHvgZfjwf0Ih8Eo=.de9bc54e-6584-4e0d-971d-fae5f0ede804@github.com>

On Thu, 8 Aug 2024 12:26:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Can I leave this part as-is?
>
> Yes, leave it in this patch to the documentation. If I address the core issue in configure, I'll update the docs as well.

For reference, I filed this: https://bugs.openjdk.org/browse/JDK-8338059

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20197#discussion_r1709385270

From bpb at openjdk.org  Thu Aug  8 14:35:33 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Aug 2024 14:35:33 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <v9EWejZCkBwRGhgfKKdOetI97OVPY0iJTNRwU7hVduc=.b01458ec-7d81-4106-b1cc-6afd2386e4c3@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
 <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
 <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>
 <3svWg4OOtXThIl3WVV4kwOafudlnHmlREaqFSAfR9mI=.a9ce7e75-3275-4ab1-bbf7-f75f91788a6d@github.com>
 <v9EWejZCkBwRGhgfKKdOetI97OVPY0iJTNRwU7hVduc=.b01458ec-7d81-4106-b1cc-6afd2386e4c3@github.com>
Message-ID: <HyrQmrzQq9myZPqB-8lL4YOrACVeYok4uigsEZVnRTs=.21a95877-9510-4d2e-8bcb-776208a2f8f1@github.com>

On Thu, 8 Aug 2024 12:18:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The Windows libs are also still required for `TransmitFile` and `WSAGetLastError`:
>> 
>> - ```mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile```
>> - ```ws2_32.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol __imp_WSAGetLastError```
>
> And pthread?

I will check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709642993

From bpb at openjdk.org  Thu Aug  8 14:35:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Aug 2024 14:35:37 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
Message-ID: <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>

On Thu, 8 Aug 2024 09:11:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge
>>  - 8337143: Removed dependency of libjava on headers in libnio/ch
>>  - 8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio
>>  - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava
>
> src/java.base/share/classes/java/net/Inet6AddressImpl.java line 154:
> 
>> 152:     static {
>> 153:         jdk.internal.loader.BootLoader.loadLibrary("net");
>> 154:     }
> 
> I am curious about this change - wouldn't it be needed in Inet4AddressImpl as well?

I have not seen any failures in CI testing. Is there a specific test that would reveal whether this is a problem?

> src/java.base/windows/native/libjava/IOUtil.c line 37:
> 
>> 35: #include "nio.h"
>> 36: #include "nio_util.h"
>> 37: /* #include "net_util.h" */
> 
> Is this change intended or is this a left over from some experimentation?

It could be leftover. There was a lot of wrangling in this. Probably line 37 could just be deleted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709645656
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709647530

From dfuchs at openjdk.org  Thu Aug  8 15:19:32 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 Aug 2024 15:19:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
Message-ID: <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>

On Thu, 8 Aug 2024 14:32:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/Inet6AddressImpl.java line 154:
>> 
>>> 152:     static {
>>> 153:         jdk.internal.loader.BootLoader.loadLibrary("net");
>>> 154:     }
>> 
>> I am curious about this change - wouldn't it be needed in Inet4AddressImpl as well?
>
> I have not seen any failures in CI testing. Is there a specific test that would reveal whether this is a problem?

It may be because we have no IPv4 only machine in the CI? It seems strange that IPv6 is treated differently than IPv4 in that respect.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709742606

From bpb at openjdk.org  Thu Aug  8 16:12:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Aug 2024 16:12:34 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
Message-ID: <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>

On Thu, 8 Aug 2024 15:16:14 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I have not seen any failures in CI testing. Is there a specific test that would reveal whether this is a problem?
>
> It may be because we have no IPv4 only machine in the CI? It seems strange that IPv6 is treated differently than IPv4 in that respect.

How would you suggest testing this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709847199

From dfuchs at openjdk.org  Thu Aug  8 16:24:33 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 Aug 2024 16:24:33 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
Message-ID: <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>

On Thu, 8 Aug 2024 16:09:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> It may be because we have no IPv4 only machine in the CI? It seems strange that IPv6 is treated differently than IPv4 in that respect.
>
> How would you suggest testing this?

I don't know - you added that code to Inet6AddressImpl - so presumably a test was failing without that code?
Which test was that? It wasn't obvious to me that adding code to load the "net" library would be required here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709861717

From bpb at openjdk.org  Thu Aug  8 16:24:33 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Aug 2024 16:24:33 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
Message-ID: <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>

On Thu, 8 Aug 2024 16:18:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> How would you suggest testing this?
>
> I don't know - you added that code to Inet6AddressImpl - so presumably a test was failing without that code?
> Which test was that? It wasn't obvious to me that adding code to load the "net" library would be required here.

I'll have to investigate.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709866669

From bpb at openjdk.org  Thu Aug  8 16:31:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Aug 2024 16:31:37 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <HyrQmrzQq9myZPqB-8lL4YOrACVeYok4uigsEZVnRTs=.21a95877-9510-4d2e-8bcb-776208a2f8f1@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
 <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
 <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>
 <3svWg4OOtXThIl3WVV4kwOafudlnHmlREaqFSAfR9mI=.a9ce7e75-3275-4ab1-bbf7-f75f91788a6d@github.com>
 <v9EWejZCkBwRGhgfKKdOetI97OVPY0iJTNRwU7hVduc=.b01458ec-7d81-4106-b1cc-6afd2386e4c3@github.com>
 <HyrQmrzQq9myZPqB-8lL4YOrACVeYok4uigsEZVnRTs=.21a95877-9510-4d2e-8bcb-776208a2f8f1@github.com>
Message-ID: <VnTkRAzUaGsFv3VihUxdyyE7r7lo4RGBE6DDSqKWhgQ=.c9a7f7ed-7116-448d-aaee-4c8c8a4f7447@github.com>

On Thu, 8 Aug 2024 14:31:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> And pthread?
>
> I will check.

`pthread` is still needed:

open/src/java.base/unix/native/libjava/nio/ch/NativeThread.c:83: error: undefined reference to 'pthread_kill'

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709879806

From jiangli at openjdk.org  Thu Aug  8 16:33:39 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 8 Aug 2024 16:33:39 GMT
Subject: Integrated: 8336849: Remove .llvm_addrsig section from JDK/VM static
 libraries (.a files)
In-Reply-To: <ydhogvsR2STcb7WGAQCjAua5l25gEd16Kjh_A0meInA=.92082d43-9187-47e4-b741-2fe059afb1bc@github.com>
References: <ydhogvsR2STcb7WGAQCjAua5l25gEd16Kjh_A0meInA=.92082d43-9187-47e4-b741-2fe059afb1bc@github.com>
Message-ID: <N0DkctCfq5APlSdFgcJ6zbnU7GVfj7TMbDNquKvugjk=.de73921d-41e1-4c70-a488-aeb8b252896a@github.com>

On Sat, 20 Jul 2024 00:20:19 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that strips the `.llvm_addrsig` section from JDK and hotspot `.a` static libraries when building with clang. Please see https://bugs.openjdk.org/browse/JDK-8336849 description for details.

This pull request has now been integrated.

Changeset: 53c9f037
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/53c9f037fb2805aab5ab9729166ce7d5bc7a77f9
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8336849: Remove .llvm_addrsig section from JDK/VM static libraries (.a files)

Reviewed-by: ihse

-------------

PR: https://git.openjdk.org/jdk/pull/20265

From dfuchs at openjdk.org  Thu Aug  8 16:42:38 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 Aug 2024 16:42:38 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
Message-ID: <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>

On Thu, 8 Aug 2024 16:21:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I don't know - you added that code to Inet6AddressImpl - so presumably a test was failing without that code?
>> Which test was that? It wasn't obvious to me that adding code to load the "net" library would be required here.
>
> I'll have to investigate.

Possibly - if you made isIPv6Supported() in InetAddress.c return false, you might be able to see the issue in the same test that you observed failing without your change. 

InetAddress has a static block that will load the "net" library, and an other static block that will create the InetAddressImpl. It's a bit curious because I would expect the block that loads the "net" library to be executed before.

And the only place where I see Inet6AddressImpl being used is in that second static block in InetAddress.

I am not an expert on library loading though :-(

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709897049

From bpb at openjdk.org  Thu Aug  8 16:51:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Aug 2024 16:51:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
 <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
Message-ID: <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>

On Thu, 8 Aug 2024 16:39:33 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I'll have to investigate.
>
> Possibly - if you made isIPv6Supported() in InetAddress.c return false, you might be able to see the issue in the same test that you observed failing without your change. 
> 
> InetAddress has a static block that will load the "net" library, and an other static block that will create the InetAddressImpl. It's a bit curious because I would expect the block that loads the "net" library to be executed before.
> 
> And the only place where I see Inet6AddressImpl being used is in that second static block in InetAddress.
> 
> I am not an expert on library loading though :-(

Thanks for the suggestions. I will look into it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709910288

From bpb at openjdk.org  Thu Aug  8 21:28:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Aug 2024 21:28:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
 <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
 <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>
Message-ID: <tcqxKkyaWyoahFSab9fo-pEmijLf-e30cF0UGBdwP4A=.63a4cc04-e92d-419b-9f10-7b4918fc223f@github.com>

On Thu, 8 Aug 2024 16:48:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Possibly - if you made isIPv6Supported() in InetAddress.c return false, you might be able to see the issue in the same test that you observed failing without your change. 
>> 
>> InetAddress has a static block that will load the "net" library, and an other static block that will create the InetAddressImpl. It's a bit curious because I would expect the block that loads the "net" library to be executed before.
>> 
>> And the only place where I see Inet6AddressImpl being used is in that second static block in InetAddress.
>> 
>> I am not an expert on library loading though :-(
>
> Thanks for the suggestions. I will look into it.

Without loading libnet in Inet6AddressImpl, the test java/net/InetAddress/NullCharInHostnameDriver.java fails with UnsatisfiedLinkError:

java.lang.UnsatisfiedLinkError: 'java.net.InetAddress[] java.net.Inet6AddressImpl.lookupAllHostAddr(java.lang.String, int)'
	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Inet6AddressImpl.java:52)
	at java.base/java.net.NullCharInHostname.main(NullCharInHostname.java:37)

This is on Unix (Linux, macOS) only, not on Windows.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1710316659

From dfuchs at openjdk.org  Fri Aug  9 09:08:32 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 Aug 2024 09:08:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <tcqxKkyaWyoahFSab9fo-pEmijLf-e30cF0UGBdwP4A=.63a4cc04-e92d-419b-9f10-7b4918fc223f@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
 <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
 <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>
 <tcqxKkyaWyoahFSab9fo-pEmijLf-e30cF0
 UGBdwP4A=.63a4cc04-e92d-419b-9f10-7b4918fc223f@github.com>
Message-ID: <ewBEFtyyzXm9KDbu9xzEAwo1xuPNhL9PJDTuLwLJP8Y=.9e5c8ef3-f51b-484e-989d-b8507a7fdf90@github.com>

On Thu, 8 Aug 2024 21:23:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Thanks for the suggestions. I will look into it.
>
> Without loading libnet in Inet6AddressImpl, the test java/net/InetAddress/NullCharInHostnameDriver.java fails with UnsatisfiedLinkError:
> 
> java.lang.UnsatisfiedLinkError: 'java.net.InetAddress[] java.net.Inet6AddressImpl.lookupAllHostAddr(java.lang.String, int)'
> 	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> 	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Inet6AddressImpl.java:52)
> 	at java.base/java.net.NullCharInHostname.main(NullCharInHostname.java:37)
> 
> This is on Unix (Linux, macOS) only, not on Windows.

OK, this test uses a private API to create an instance of Inet6AddressImpl; This explain why in this test Inet6AddressImpl gets loaded before InetAddress.

            var impl = new Inet6AddressImpl();

It should never happen outside of this test. Now the tricky question: what in your proposed changes caused "net" not to be loaded before the test created new Inet6AddressImpl(); ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1711100272

From ihse at openjdk.org  Fri Aug  9 09:43:32 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 Aug 2024 09:43:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <VnTkRAzUaGsFv3VihUxdyyE7r7lo4RGBE6DDSqKWhgQ=.c9a7f7ed-7116-448d-aaee-4c8c8a4f7447@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
 <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
 <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>
 <3svWg4OOtXThIl3WVV4kwOafudlnHmlREaqFSAfR9mI=.a9ce7e75-3275-4ab1-bbf7-f75f91788a6d@github.com>
 <v9EWejZCkBwRGhgfKKdOetI97OVPY0iJTNRwU7hVduc=.b01458ec-7d81-4106-b1cc-6afd2386e4c3@github.com>
 <HyrQmrzQq9myZPqB-8lL4YOrACVeYok4uigsEZVnRTs=.21a95877-9510-4d2e-8bcb-776208a2f8f1@github.com>
 <VnTkRAzUaGsFv3VihUxdyyE7r7lo4RGBE6DDSqKWhgQ=.c9a7f7ed-7116-448d-aaee-4c8c8a4f7447@github.com>
Message-ID: <ym1ehC2spLARIgv3ALJkdINukIEgJ4rTjt9EvXnvj5A=.6169748e-ce16-4b5c-a865-6d64f62940f4@github.com>

On Thu, 8 Aug 2024 16:29:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I will check.
>
> `pthread` is still needed:
> 
> open/src/java.base/unix/native/libjava/nio/ch/NativeThread.c:83: error: undefined reference to 'pthread_kill'

Ok then. Thank you for your thorough checking!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1711154512

From ihse at openjdk.org  Fri Aug  9 10:31:40 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 Aug 2024 10:31:40 GMT
Subject: RFR: 8338108: Give better error message in configure if a full XCode
 is missing
Message-ID: <PnyhYRGeCu1z770ImpIbH1Pd59PR7mKKjSwFbdPx-ko=.e56b2901-ada1-403c-be9f-c646e4e0e01b@github.com>

The XCode command lines tools is almost, but not quite, enough to build the JDK. We still need the metal and metallib tools. The error message given by configure should be improved to indicate if this is the problem with the user's environment.

-------------

Commit messages:
 - 8338108: Give better error message in configure if a full XCode is missing

Changes: https://git.openjdk.org/jdk/pull/20520/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20520&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338108
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20520.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20520/head:pull/20520

PR: https://git.openjdk.org/jdk/pull/20520

From fgao at openjdk.org  Fri Aug  9 13:37:54 2024
From: fgao at openjdk.org (Fei Gao)
Date: Fri, 9 Aug 2024 13:37:54 GMT
Subject: RFR: 8337536: AArch64: Enable BTI branch protection for runtime
 part [v2]
In-Reply-To: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
References: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
Message-ID: <M50QnYb5zJhnQL3ytXnW7Rg7AhQu1aXqDWY250gcNSo=.2397b42c-f1f1-4b2d-a94f-b39c7277b651@github.com>

> This patch enables BTI branch protection for runtime part on Linux/aarch64 platform.
> 
> Motivation
> 
> 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. User-level packages can gain additional hardening by compiling with the GCC/Clang flag `-mbranch-protection=flag`. See [1].
> 
> 2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as one VM configure flag, which would pass `-mbranch-protection=standard` compilation flags to all c/c++ files. Note that `standard` turns on both `pac-ret` and `bti` branch protections. For more details about code reuse attacks and hardware-assisted branch protections on AArch64, see [3].
> 
> However, we checked the `.note.gnu.property` section of all the shared libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so didn't set these two target feature bits:
> 
> 
>   GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>   GNU_PROPERTY_AARCH64_FEATURE_1_PAC
> 
> 
> Note-1: BTI is an all or nothing property for a link unit [4]. That is, libjvm.so is not BTI-enabled.
> 
> Note-2: PAC bit in `.note.gnu.property` section is used to protect `.got.plt` table. It's independent of whether the relocatable objects use PAC or not.
> 
> Goal
> 
> Hence, this patch aims to set PAC/BTI feature bits of the `.note.gnu.property` section for libjvm.so.
> 
> Implementation
> 
> Task-1: find out the problematic input objects
> 
> From [5], "Static linkers processing ELF relocatable objects must set the feature bit in the output object or image only if all the input objects have the corresponding feature bit set." Hence we suspect that the root cause is probably that the PAC/BTI feature bits are not set only for some input objects of libjvm.so.
> 
> In order to find out these inputs, we passed `--force-bti` linker flag [4] in my local test. This linker flag would warn if any input object does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following list:
> 
> 
>   src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
>   src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S
>   src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S
>   src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S
> 
> 
> Task-2: add `.note.gnu.property` section for these assembly files
> 
> As mentioned in Motivation-2 part, `-mbranch-protection=standard` is passed to compile c/c++ files but these assembly files are missed.
> 
> In this patch, we also pass `-mbranch-protection=standard` flag to assembler (See the update in flags-cflags.m4 and flags-other.m4), and add `.note.gnu.property` section at the end...

Fei Gao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Clean up makefile
 - Merge branch 'master' into enable-bti-runtime
 - 8337536: AArch64: Enable BTI branch protection for runtime part
   
   This patch enables BTI branch protection for runtime part on
   Linux/aarch64 platform.
   
   Motivation
   
   1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default.
   User-level packages can gain additional hardening by compiling with the
   GCC/Clang flag `-mbranch-protection=flag`. See [1].
   
   2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as
   one VM configure flag, which would pass `-mbranch-protection=standard`
   compilation flags to all c/c++ files. Note that `standard` turns on both
   `pac-ret` and `bti` branch protections. For more details about code
   reuse attacks and hardware-assisted branch protections on AArch64, see
   [3].
   
   However, we checked the `.note.gnu.property` section of all the shared
   libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so
   didn't set these two target feature bits:
   
   ```
     GNU_PROPERTY_AARCH64_FEATURE_1_BTI
     GNU_PROPERTY_AARCH64_FEATURE_1_PAC
   ```
   
   Note-1: BTI is an all or nothing property for a link unit [4]. That is,
   libjvm.so is not BTI-enabled.
   
   Note-2: PAC bit in `.note.gnu.property` section is used to protect
   `.got.plt` table. It's independent of whether the relocatable objects
   use PAC or not.
   
   Goal
   
   Hence, this patch aims to set PAC/BTI feature bits of the
   `.note.gnu.property` section for libjvm.so.
   
   Implementation
   
   Task-1: find out the problematic input objects
   
   From [5], "Static linkers processing ELF relocatable objects must set
   the feature bit in the output object or image only if all the input
   objects have the corresponding feature bit set." Hence we suspect that
   the root cause is probably that the PAC/BTI feature bits are not set
   only for some input objects of libjvm.so.
   
   In order to find out these inputs, we passed `--force-bti` linker flag
   [4] in my local test. This linker flag would warn if any input object
   does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following
   list:
   
   ```
     src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
     src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S
     src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S
     src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S
   ```
   
   Task-2: add `.note.gnu.property` section for these assembly files
   
   As mentioned in Motivation-2 part, `-mbranch-protection=standard` is
   passed to compile c/c++ files but these assembly files are missed.
   
   In this patch, we also pass `-mbranch-protection=standard` flag to
   assembler (See the update in flags-cflags.m4 and flags-other.m4), and
   add `.note.gnu.property` section at the end of these assembler files.
   
   With this change, we can see PAC/BTI feature bits in the final
   libjvm.so.
   
   Task-3: add BTI landing pads for hand written assembly
   
   In the local test on Fedora 40 with PAC/BTI-capable hardware, we got
   `SIGILL` error, which is one typical BTI error (branch target exception).
   The root cause is that we should add the missing BTI landing pads for
   hand written assembly in hotspot.
   
   File-1 copy_aarch64.hpp: It's a switch-case statement and we add `bti j`
   for these indirect jumps.
   
   File-2 atomic_linux_aarch64.S: We add landings pads `bti c` at the
   function entries.
   
   File-3 copy_linux_aarch64.S: There is no need to add `bti c` at the
   function entries since they are called via `bl`. And we should handle
   the indirect jumps.
   
   File-4 safefetch_linux_aarch64.S: Similar to file-3, there is no need to
   handle these function entries.
   
   File-5 threadLS_linux_aarch64.S: No need to handle the function entry
   because `paciasp` can act as the landing pad.
   
   Evaluation
   
   1. jtreg test
   
   We ran tier 1-3 jtreg tests on Fedora 40 + GCC 14 + the following AArch64
   hardware and all tests passed.
   
   ```
     1. w/o PAC and w/o BTI
     2. w/ PAC and w/o BTI
     3. w/ PAC and w/ BTI
   ```
   
   We also ran the jtreg tests on Fedora 40 + Clang 18 + hardware w/ PAC
   and w/ BTI. The test passed too.
   
   2. code size
   
   We got about 2% code size increase before and after
   `--enbale-branch-protection` is used. This code size change looks
   reasonable. See the evaluation on glibc [6].
   
   [1] https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication
   [2] https://bugs.openjdk.org/browse/JDK-8277204
   [3] https://community.arm.com/arm-community-blogs/b/tools-software-ides-blog/posts/code-reuse-attacks-the-compiler-story
   [4] https://reviews.llvm.org/D62609
   [5] https://github.com/ARM-software/abi-aa/blob/2a70c42d62e9c3eb5887fa50b71257f20daca6f9/aaelf64/aaelf64.rst#program-property
   [6] https://developer.arm.com/documentation/102433/0100/Applying-these-techniques-to-real-code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20491/files
  - new: https://git.openjdk.org/jdk/pull/20491/files/d1506d7d..114953da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20491&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20491&range=00-01

  Stats: 7788 lines in 182 files changed: 2326 ins; 4845 del; 617 mod
  Patch: https://git.openjdk.org/jdk/pull/20491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20491/head:pull/20491

PR: https://git.openjdk.org/jdk/pull/20491

From fgao at openjdk.org  Fri Aug  9 13:37:54 2024
From: fgao at openjdk.org (Fei Gao)
Date: Fri, 9 Aug 2024 13:37:54 GMT
Subject: RFR: 8337536: AArch64: Enable BTI branch protection for runtime
 part
In-Reply-To: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
References: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
Message-ID: <5_sk0lKoqEJXEC15_5m3NTft9fQ1nOJFeTdEWLGHAVw=.ed44303e-af6e-4d85-a0e7-e0be1ce8136c@github.com>

On Wed, 7 Aug 2024 10:40:09 GMT, Fei Gao <fgao at openjdk.org> wrote:

> This patch enables BTI branch protection for runtime part on Linux/aarch64 platform.
> 
> Motivation
> 
> 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. User-level packages can gain additional hardening by compiling with the GCC/Clang flag `-mbranch-protection=flag`. See [1].
> 
> 2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as one VM configure flag, which would pass `-mbranch-protection=standard` compilation flags to all c/c++ files. Note that `standard` turns on both `pac-ret` and `bti` branch protections. For more details about code reuse attacks and hardware-assisted branch protections on AArch64, see [3].
> 
> However, we checked the `.note.gnu.property` section of all the shared libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so didn't set these two target feature bits:
> 
> 
>   GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>   GNU_PROPERTY_AARCH64_FEATURE_1_PAC
> 
> 
> Note-1: BTI is an all or nothing property for a link unit [4]. That is, libjvm.so is not BTI-enabled.
> 
> Note-2: PAC bit in `.note.gnu.property` section is used to protect `.got.plt` table. It's independent of whether the relocatable objects use PAC or not.
> 
> Goal
> 
> Hence, this patch aims to set PAC/BTI feature bits of the `.note.gnu.property` section for libjvm.so.
> 
> Implementation
> 
> Task-1: find out the problematic input objects
> 
> From [5], "Static linkers processing ELF relocatable objects must set the feature bit in the output object or image only if all the input objects have the corresponding feature bit set." Hence we suspect that the root cause is probably that the PAC/BTI feature bits are not set only for some input objects of libjvm.so.
> 
> In order to find out these inputs, we passed `--force-bti` linker flag [4] in my local test. This linker flag would warn if any input object does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following list:
> 
> 
>   src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
>   src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S
>   src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S
>   src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S
> 
> 
> Task-2: add `.note.gnu.property` section for these assembly files
> 
> As mentioned in Motivation-2 part, `-mbranch-protection=standard` is passed to compile c/c++ files but these assembly files are missed.
> 
> In this patch, we also pass `-mbranch-protection=standard` flag to assembler (See the update in flags-cflags.m4 and flags-other.m4), and add `.note.gnu.property` section at the end...

> It turned out to be easier to write it myself than trying to explain it. Please have a look here: [0fe840d](https://github.com/openjdk/jdk/commit/0fe840dec597bb4a819eb2025a6d56cd82f237b5)
> 
> (This also contains some additional cleanup in the branch protection configure code.)

Thanks for your review and suggestions @magicus . Updated in the new commit :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20491#issuecomment-2277959315

From jwaters at openjdk.org  Fri Aug  9 13:49:31 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 9 Aug 2024 13:49:31 GMT
Subject: RFR: 8338108: Give better error message in configure if a full
 XCode is missing
In-Reply-To: <PnyhYRGeCu1z770ImpIbH1Pd59PR7mKKjSwFbdPx-ko=.e56b2901-ada1-403c-be9f-c646e4e0e01b@github.com>
References: <PnyhYRGeCu1z770ImpIbH1Pd59PR7mKKjSwFbdPx-ko=.e56b2901-ada1-403c-be9f-c646e4e0e01b@github.com>
Message-ID: <GY3J6YWvbv4TNTpHp6E3jniMWm3odeCOh9ckKWkNlBw=.aed8c02b-52c5-4e2f-8a74-202abd5c03c9@github.com>

On Fri, 9 Aug 2024 10:27:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The XCode command lines tools is almost, but not quite, enough to build the JDK. We still need the metal and metallib tools. The error message given by configure should be improved to indicate if this is the problem with the user's environment.

Looks good! And great to have you back from vacation too :)

-------------

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20520#pullrequestreview-2230250307

From fgao at openjdk.org  Fri Aug  9 14:14:31 2024
From: fgao at openjdk.org (Fei Gao)
Date: Fri, 9 Aug 2024 14:14:31 GMT
Subject: RFR: 8337536: AArch64: Enable BTI branch protection for runtime
 part
In-Reply-To: <446-JAhZlwZT7eNafXxR90EqiIUuV5Xd9bMfqXTOVA4=.45e46493-f09e-4ef4-9d13-6657b7938433@github.com>
References: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
 <446-JAhZlwZT7eNafXxR90EqiIUuV5Xd9bMfqXTOVA4=.45e46493-f09e-4ef4-9d13-6657b7938433@github.com>
Message-ID: <21FL0PReEC5ZBPAFIGUhEmsnso1lLdf8W86qIjxHSPs=.1fe33a30-5d14-43f3-ab18-cbd4eb668ca6@github.com>

On Wed, 7 Aug 2024 17:27:00 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Can you explain why we want to support PAC without BTI? Would anyone use such a config?

Thanks for reviewing @theRealAph . 

Sorry, I don't quite understand your question. Do you mean why we currently only support PAC? PAC is mandatory from Armv8.3 for ROP attacks, while BTI is mandatory from Armv8.5 for JOP attacks. JDK currently has PAC enabled, but not BTI.

Or do you mean if we need the option to just support one of them? Now we enable BTI and PAC at the same time by configuring `--enable-branch-protection` and disable them without the flag, i.e. both or nothing. GCC supports all options to give maximum flexibility, just in case anyone wants it. What do you think? Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20491#issuecomment-2278041901

From ihse at openjdk.org  Fri Aug  9 14:23:33 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 Aug 2024 14:23:33 GMT
Subject: RFR: 8337536: AArch64: Enable BTI branch protection for runtime
 part [v2]
In-Reply-To: <M50QnYb5zJhnQL3ytXnW7Rg7AhQu1aXqDWY250gcNSo=.2397b42c-f1f1-4b2d-a94f-b39c7277b651@github.com>
References: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
 <M50QnYb5zJhnQL3ytXnW7Rg7AhQu1aXqDWY250gcNSo=.2397b42c-f1f1-4b2d-a94f-b39c7277b651@github.com>
Message-ID: <CTfETdH35-p_Ypj6TRi0zpnKefyUtd8eXYwbem2hB0s=.9143dabf-b797-4374-b886-6151a0217481@github.com>

On Fri, 9 Aug 2024 13:37:54 GMT, Fei Gao <fgao at openjdk.org> wrote:

>> This patch enables BTI branch protection for runtime part on Linux/aarch64 platform.
>> 
>> Motivation
>> 
>> 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. User-level packages can gain additional hardening by compiling with the GCC/Clang flag `-mbranch-protection=flag`. See [1].
>> 
>> 2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as one VM configure flag, which would pass `-mbranch-protection=standard` compilation flags to all c/c++ files. Note that `standard` turns on both `pac-ret` and `bti` branch protections. For more details about code reuse attacks and hardware-assisted branch protections on AArch64, see [3].
>> 
>> However, we checked the `.note.gnu.property` section of all the shared libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so didn't set these two target feature bits:
>> 
>> 
>>   GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>>   GNU_PROPERTY_AARCH64_FEATURE_1_PAC
>> 
>> 
>> Note-1: BTI is an all or nothing property for a link unit [4]. That is, libjvm.so is not BTI-enabled.
>> 
>> Note-2: PAC bit in `.note.gnu.property` section is used to protect `.got.plt` table. It's independent of whether the relocatable objects use PAC or not.
>> 
>> Goal
>> 
>> Hence, this patch aims to set PAC/BTI feature bits of the `.note.gnu.property` section for libjvm.so.
>> 
>> Implementation
>> 
>> Task-1: find out the problematic input objects
>> 
>> From [5], "Static linkers processing ELF relocatable objects must set the feature bit in the output object or image only if all the input objects have the corresponding feature bit set." Hence we suspect that the root cause is probably that the PAC/BTI feature bits are not set only for some input objects of libjvm.so.
>> 
>> In order to find out these inputs, we passed `--force-bti` linker flag [4] in my local test. This linker flag would warn if any input object does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following list:
>> 
>> 
>>   src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
>>   src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S
>>   src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S
>>   src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S
>> 
>> 
>> Task-2: add `.note.gnu.property` section for these assembly files
>> 
>> As mentioned in Motivation-2 part, `-mbranch-protection=standard` is passed to compile c/c++ files but these assembly files are missed.
>> 
>> In this patch, we also pass `-mbranch-protection=standard` flag to assembler (See the update i...
>
> Fei Gao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Clean up makefile
>  - Merge branch 'master' into enable-bti-runtime
>  - 8337536: AArch64: Enable BTI branch protection for runtime part
>    
>    This patch enables BTI branch protection for runtime part on
>    Linux/aarch64 platform.
>    
>    Motivation
>    
>    1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default.
>    User-level packages can gain additional hardening by compiling with the
>    GCC/Clang flag `-mbranch-protection=flag`. See [1].
>    
>    2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as
>    one VM configure flag, which would pass `-mbranch-protection=standard`
>    compilation flags to all c/c++ files. Note that `standard` turns on both
>    `pac-ret` and `bti` branch protections. For more details about code
>    reuse attacks and hardware-assisted branch protections on AArch64, see
>    [3].
>    
>    However, we checked the `.note.gnu.property` section of all the shared
>    libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so
>    didn't set these two target feature bits:
>    
>    ```
>      GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>      GNU_PROPERTY_AARCH64_FEATURE_1_PAC
>    ```
>    
>    Note-1: BTI is an all or nothing property for a link unit [4]. That is,
>    libjvm.so is not BTI-enabled.
>    
>    Note-2: PAC bit in `.note.gnu.property` section is used to protect
>    `.got.plt` table. It's independent of whether the relocatable objects
>    use PAC or not.
>    
>    Goal
>    
>    Hence, this patch aims to set PAC/BTI feature bits of the
>    `.note.gnu.property` section for libjvm.so.
>    
>    Implementation
>    
>    Task-1: find out the problematic input objects
>    
>    From [5], "Static linkers processing ELF relocatable objects must set
>    the feature bit in the output object or image only if all the input
>    objects have the corresponding feature bit set." Hence we suspect that
>    the root cause is probably that the PAC/BTI feature bits are not set
>    only for some input objects of libjvm.so.
>    
>    In order to find out these inputs, we passed `--force-bti` linker flag
>    [4] in my local test. This linker flag would warn if any input object
>    does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following
>    list:
>    
>    ```
>      src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
> ...

Thanks. I'll leave it for someone else to review the build changes, as they are effectively written by me now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20491#issuecomment-2278061225

From bpb at openjdk.org  Fri Aug  9 15:08:42 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Aug 2024 15:08:42 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <ym1ehC2spLARIgv3ALJkdINukIEgJ4rTjt9EvXnvj5A=.6169748e-ce16-4b5c-a865-6d64f62940f4@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
 <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
 <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>
 <3svWg4OOtXThIl3WVV4kwOafudlnHmlREaqFSAfR9mI=.a9ce7e75-3275-4ab1-bbf7-f75f91788a6d@github.com>
 <v9EWejZCkBwRGhgfKKdOetI97OVPY0iJTNRwU7hVduc=.b01458ec-7d81-4106-b1cc-6afd2386e4c3@github.com>
 <HyrQmrzQq9myZPqB-8lL4YOrACVeYok4uigsEZVnRTs=.21a95877-9510-4d2e-8bcb-776208a2f8f1@github.com>
 <VnTkRAzUaGsFv3VihUxdyyE7r7lo4RGBE6DDSqKWhgQ=.c9a7f7ed-7116-448d-aaee-4c8c8a4f7447@github.com>
 <ym1ehC2spLARIgv3ALJkdINukIEgJ4rTjt9EvXnvj5A=.6169748e-ce16-4b5c-a865-6d64f62940f4@github.com>
Message-ID: <mrZPe0z2rhoHe3rKhS5bqy6-2wZCFJrUDDQ_ktdUnu4=.7e35f805-21e1-48ca-b819-3fd9bc542485@github.com>

On Fri, 9 Aug 2024 09:40:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> `pthread` is still needed:
>> 
>> open/src/java.base/unix/native/libjava/nio/ch/NativeThread.c:83: error: undefined reference to 'pthread_kill'
>
> Ok then. Thank you for your thorough checking!

Thank you for suggesting it!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1711643521

From bpb at openjdk.org  Fri Aug  9 15:11:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Aug 2024 15:11:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <ewBEFtyyzXm9KDbu9xzEAwo1xuPNhL9PJDTuLwLJP8Y=.9e5c8ef3-f51b-484e-989d-b8507a7fdf90@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
 <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
 <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>
 <tcqxKkyaWyoahFSab9fo-pEmijLf-e30cF0
 UGBdwP4A=.63a4cc04-e92d-419b-9f10-7b4918fc223f@github.com>
 <ewBEFtyyzXm9KDbu9xzEAwo1xuPNhL9PJDTuLwLJP8Y=.9e5c8ef3-f51b-484e-989d-b8507a7fdf90@github.com>
Message-ID: <aq18fO2SC1t_PMgNF8zX1gxjPZvLZljsLe1SCVNhzSE=.aa134c08-3740-4b08-afc2-244d6d2db182@github.com>

On Fri, 9 Aug 2024 09:05:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Without loading libnet in Inet6AddressImpl, the test java/net/InetAddress/NullCharInHostnameDriver.java fails with UnsatisfiedLinkError:
>> 
>> java.lang.UnsatisfiedLinkError: 'java.net.InetAddress[] java.net.Inet6AddressImpl.lookupAllHostAddr(java.lang.String, int)'
>> 	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
>> 	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Inet6AddressImpl.java:52)
>> 	at java.base/java.net.NullCharInHostname.main(NullCharInHostname.java:37)
>> 
>> This is on Unix (Linux, macOS) only, not on Windows.
>
> OK, this test uses a private API to create an instance of Inet6AddressImpl; This explain why in this test Inet6AddressImpl gets loaded before InetAddress.
> 
>             var impl = new Inet6AddressImpl();
> 
> It should never happen outside of this test. Now the tricky question: what in your proposed changes caused "net" not to be loaded before the test created new Inet6AddressImpl(); ?

Loading "net" was removed from IOUtil so I am thinking that IOUtil must have been initialized somewhere before constructing Inet6AddressImpl, but I've not identified where just yet.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1711648714

From dfuchs at openjdk.org  Fri Aug  9 15:51:36 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 Aug 2024 15:51:36 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <aq18fO2SC1t_PMgNF8zX1gxjPZvLZljsLe1SCVNhzSE=.aa134c08-3740-4b08-afc2-244d6d2db182@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
 <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
 <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>
 <tcqxKkyaWyoahFSab9fo-pEmijLf-e30cF0
 UGBdwP4A=.63a4cc04-e92d-419b-9f10-7b4918fc223f@github.com>
 <ewBEFtyyzXm9KDbu9xzEAwo1xuPNhL9PJDTuLwLJP8Y=.9e5c8ef3-f51b-484e-989d-b8507a7fdf90@github.com>
 <aq18fO2SC1t_PMgNF8zX1gxjPZvLZljsLe1SCVNhzSE=.aa134c08-3740-4b08-afc2-244d6d2db182@github.com>
Message-ID: <kWuaxuPTlbHyj1xGdl4j6kvnvxpQUeUdQjsfM-Dx8fA=.cb09c1bb-63ca-41d8-a753-ece8601eb5f8@github.com>

On Fri, 9 Aug 2024 15:09:08 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> OK, this test uses a private API to create an instance of Inet6AddressImpl; This explain why in this test Inet6AddressImpl gets loaded before InetAddress.
>> 
>>             var impl = new Inet6AddressImpl();
>> 
>> It should never happen outside of this test. Now the tricky question: what in your proposed changes caused "net" not to be loaded before the test created new Inet6AddressImpl(); ?
>
> Loading "net" was removed from IOUtil so I am thinking that IOUtil must have been initialized somewhere before constructing Inet6AddressImpl, but I've not identified where just yet.

I see. Inet6AddressImpl and Inet4AddressImpl are symetric classes implementing InetAddressImpl. Both will make native calls to the "net" library - so both require the library to be loaded.

In the JDK, these two classes are only loaded by InetAddress, after the "net" library has been loaded.

The test test java/net/InetAddress/NullCharInHostnameDriver.java seems to be an outlier (@AlekseiEfimov ?) which for some reason uses a private API (the test is injected in java.base) and create a new instance of Inet6AddressImpl before InetAddress is loaded. This is why without this change to Inet6AddressImpl we get the UnsatisfiedLinkError. We would have gotten the same from Inet4AddressImpl if the test had first required access to Inet4AddressImpl instead.

So it seems that we should either add the call to load the "net" library to both Inet6AddressImpl and Inet4AddressImpl for symetry (there doesn't seem to be any reason why Inet6AddressImpl would be preferred in this respect),  or remove this call from Inet6AddressImpl and add it to the test instead. Adding the call to jdk.internal.loader.BootLoader.loadLibrary("net"); in the test should work since the actual test class (NullCharInHostname.java) is injected in java.base.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1711706176

From bpb at openjdk.org  Fri Aug  9 16:01:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Aug 2024 16:01:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <kWuaxuPTlbHyj1xGdl4j6kvnvxpQUeUdQjsfM-Dx8fA=.cb09c1bb-63ca-41d8-a753-ece8601eb5f8@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
 <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
 <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>
 <tcqxKkyaWyoahFSab9fo-pEmijLf-e30cF0
 UGBdwP4A=.63a4cc04-e92d-419b-9f10-7b4918fc223f@github.com>
 <ewBEFtyyzXm9KDbu9xzEAwo1xuPNhL9PJDTuLwLJP8Y=.9e5c8ef3-f51b-484e-989d-b8507a7fdf90@github.com>
 <aq18fO2SC1t_PMgNF8zX1gxjPZvLZljsLe1SCVNhzSE=.aa134c08-3740-4b08-afc2-244d6d2db182@github.com>
 <kWuaxuPTlbHyj1xGdl4j6kvnvxpQUeUdQjsfM-Dx8fA=.cb09c1bb-63ca-41d8-a753-ece8601eb5f8@github.com>
Message-ID: <eSowRvzxxpfIxVy3MmfC9pxFlrY73wBgPLrbWbw7E5o=.0e9d3a5f-c16e-4f12-bdf5-94a58ba2f84c@github.com>

On Fri, 9 Aug 2024 15:47:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Loading "net" was removed from IOUtil so I am thinking that IOUtil must have been initialized somewhere before constructing Inet6AddressImpl, but I've not identified where just yet.
>
> I see. Inet6AddressImpl and Inet4AddressImpl are symetric classes implementing InetAddressImpl. Both will make native calls to the "net" library - so both require the library to be loaded.
> 
> In the JDK, these two classes are only loaded by InetAddress, after the "net" library has been loaded.
> 
> The test test java/net/InetAddress/NullCharInHostnameDriver.java seems to be an outlier (@AlekseiEfimov ?) which for some reason uses a private API (the test is injected in java.base) and create a new instance of Inet6AddressImpl before InetAddress is loaded. This is why without this change to Inet6AddressImpl we get the UnsatisfiedLinkError. We would have gotten the same from Inet4AddressImpl if the test had first required access to Inet4AddressImpl instead.
> 
> So it seems that we should either add the call to load the "net" library to both Inet6AddressImpl and Inet4AddressImpl for symetry (there doesn't seem to be any reason why Inet6AddressImpl would be preferred in this respect),  or remove this call from Inet6AddressImpl and add it to the test instead. Adding the call to jdk.internal.loader.BootLoader.loadLibrary("net"); in the test should work since the actual test class (NullCharInHostname.java) is injected in java.base.

Thanks. I'll try adding it to the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1711723045

From erikj at openjdk.org  Fri Aug  9 17:52:33 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 9 Aug 2024 17:52:33 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v3]
In-Reply-To: <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com>
 <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
Message-ID: <XPDUQ_gB_V5d_47vLkUw62PxecokAsXuM3yaYdjDMa0=.8224a773-959f-4334-97e2-517fcb4fc954@github.com>

On Thu, 27 Jun 2024 22:03:37 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately. This enhancement adds the relevant files, enabling the rest of [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward.
>
> Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update README to include RISC-V

Responding to the discussion in https://github.com/openjdk/jdk/pull/18605 here as this is the PR actually adding SLEEF to the JDK source.

I was initially of the opinion that the solution already provided here was enough. We could potentially have added a Git hash in addition to the version/tag to more precisely and permanently identify the exact Sleef source we are depending on. At least a Git hash wouldn't change externally.

However, Andrew's arguments have swayed me. I now think we should add a more or less complete dump of the Sleef source into the JDK repository. I'm still open to trimming it down somewhat as long as the build steps we need to run to generate the headers we need, using the Sleef build system, are still functional. I'm basically agreeing with his suggestion but will spell it out in detail here for completeness in this PR.

We should then add a script that automatically performs the necessary build steps, using the Sleef official build system, to generate the headers we need, and outputs them into the JDK source tree, in the location where we will also commit those headers. This script should document what dependencies and configuration is necessary to run it, which will include cmake and possibly other things. Performing this step doesn't need to be completely streamlined, just reasonably possible to run. It's meant to be an import/verification step. With this solution I would recommend putting the script next to the Sleef source tree instead of in make/devkit/.

The normal JDK build will just use the committed pre-generated headers.

I looked briefly at the heroic build work provided by @fitzsim and while I admire the effort, I don't think this is the right way and we already dismissed this approach earlier. Not because I didn't think it was feasible to implement, but because of the future maintenance burden. The Sleef build is non trivial so we shouldn't try to replicate it in our build. The risk of our implementation diverging in the future is too great.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2278444569

From erik.joelsson at oracle.com  Fri Aug  9 17:55:07 2024
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 9 Aug 2024 10:55:07 -0700
Subject: Add "Windows aarch64" to Supported Build Platforms
In-Reply-To: <DS7PR21MB3407A10274F0DD81C1C08F6186B22@DS7PR21MB3407.namprd21.prod.outlook.com>
References: <DS7PR21MB3407A10274F0DD81C1C08F6186B22@DS7PR21MB3407.namprd21.prod.outlook.com>
Message-ID: <c0c46bf6-a21d-4ebf-b831-8b14f3195733@oracle.com>

Hello Brian,

(Unfortunately) only members of the respective groups are able to edit 
group specific wiki pages, so in this case you need someone in the build 
group to handle it for you. Perhaps if you are taking ownership of a 
port, you would want to volunteer someone to join the build group and 
help shoulder a bit of the general burden of build issues? If not you 
can reply here with the details of what you would like to add to which 
tables and one of us can update the page.

/Erik

On 8/1/24 4:54 PM, Brian Stafford wrote:
>
> Hello,
>
> We would like to add Microsoft as the maintainer of Windows aarch64 to 
> the Supported Build Platforms[1] page (JDK versions 11/17/21).
>
> Who can help us out with that?
>
> Thanks!
>
> Brian Stafford
>
> Microsoft
>
> [1] https://wiki.openjdk.org/display/Build/Supported+Build+Platforms
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240809/54884d17/attachment.htm>

From bpb at openjdk.org  Fri Aug  9 17:59:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Aug 2024 17:59:12 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20317/files
  - new: https://git.openjdk.org/jdk/pull/20317/files/e28a4f57..f57b6f13

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=03-04

  Stats: 11 lines in 3 files changed: 4 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

PR: https://git.openjdk.org/jdk/pull/20317

From bpb at openjdk.org  Fri Aug  9 17:59:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Aug 2024 17:59:12 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <eSowRvzxxpfIxVy3MmfC9pxFlrY73wBgPLrbWbw7E5o=.0e9d3a5f-c16e-4f12-bdf5-94a58ba2f84c@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
 <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
 <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>
 <tcqxKkyaWyoahFSab9fo-pEmijLf-e30cF0
 UGBdwP4A=.63a4cc04-e92d-419b-9f10-7b4918fc223f@github.com>
 <ewBEFtyyzXm9KDbu9xzEAwo1xuPNhL9PJDTuLwLJP8Y=.9e5c8ef3-f51b-484e-989d-b8507a7fdf90@github.com>
 <aq18fO2SC1t_PMgNF8zX1gxjPZvLZljsLe1SCVNhzSE=.aa134c08-3740-4b08-afc2-244d6d2db182@github.com>
 <kWuaxuPTlbHyj1xGdl4j6kvnvxpQUeUdQjsfM-Dx8fA=.cb09c1bb-63ca-41d8-a753-ece8601eb5f8@github.com>
 <eSowRvzxxpfIxVy3MmfC9pxFlrY73wBgPLrbWbw7E5o=.0e9d3a5f-c16e-4f12-bdf5-94a58ba2f84c@github.com>
Message-ID: <3uXhrkj0U16cG1Lf-JGCkagHJD0MLFcbcEI6ZsBxBiw=.774775bc-3ddf-4882-872a-29292daea008@github.com>

On Fri, 9 Aug 2024 15:58:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I see. Inet6AddressImpl and Inet4AddressImpl are symetric classes implementing InetAddressImpl. Both will make native calls to the "net" library - so both require the library to be loaded.
>> 
>> In the JDK, these two classes are only loaded by InetAddress, after the "net" library has been loaded.
>> 
>> The test test java/net/InetAddress/NullCharInHostnameDriver.java seems to be an outlier (@AlekseiEfimov ?) which for some reason uses a private API (the test is injected in java.base) and create a new instance of Inet6AddressImpl before InetAddress is loaded. This is why without this change to Inet6AddressImpl we get the UnsatisfiedLinkError. We would have gotten the same from Inet4AddressImpl if the test had first required access to Inet4AddressImpl instead.
>> 
>> So it seems that we should either add the call to load the "net" library to both Inet6AddressImpl and Inet4AddressImpl for symetry (there doesn't seem to be any reason why Inet6AddressImpl would be preferred in this respect),  or remove this call from Inet6AddressImpl and add it to the test instead. Adding the call to jdk.internal.loader.BootLoader.loadLibrary("net"); in the test should work since the actual test class (NullCharInHostname.java) is injected in java.base.
>
> Thanks. I'll try adding it to the test.

In f57b6f1 I reverted the Inet6AddressImpl change and added the "net" library load to NullCharInHostname.java. With this change the test passed on Unix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1711895017

From bpb at openjdk.org  Fri Aug  9 17:59:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Aug 2024 17:59:12 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
Message-ID: <a7W6SwWulATRx-mtErRTwW-ZznoeuYwXKDIwzUBoVys=.afa3463d-053c-4340-adb0-17139ff35391@github.com>

On Thu, 8 Aug 2024 14:33:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/windows/native/libjava/IOUtil.c line 37:
>> 
>>> 35: #include "nio.h"
>>> 36: #include "nio_util.h"
>>> 37: /* #include "net_util.h" */
>> 
>> Is this change intended or is this a left over from some experimentation?
>
> It could be leftover. There was a lot of wrangling in this. Probably line 37 could just be deleted.

Line 37 deleted in f57b6f1.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1711892358

From erikj at openjdk.org  Fri Aug  9 18:08:34 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 9 Aug 2024 18:08:34 GMT
Subject: RFR: 8336498: [macos] [build]: install-file macro may run into
 permission denied error
In-Reply-To: <dMqnljHWGtietpR7M7V0gcVxSb4gidHXTE2qJ0xVe5Y=.576e9b23-0345-425c-a106-d4ed938d5015@github.com>
References: <dMqnljHWGtietpR7M7V0gcVxSb4gidHXTE2qJ0xVe5Y=.576e9b23-0345-425c-a106-d4ed938d5015@github.com>
Message-ID: <YW1zd9o-Jx5yGb3IoE4Z1pk7ESS0ixT4rSDh6wsTjWY=.77fbf462-a7dd-4f63-967f-c09ee9a32f58@github.com>

On Tue, 16 Jul 2024 20:50:32 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> On MacOS, files may have extended attributes attached. These attributes are copied together with the files. To prevent issues during further processing, the extended attributes of the copies must be removed. This action was implemented as solution of an older bug.
> 
> The solution is incomplete because it does not handle files with read-only permissions correctly. Without write permission, matter cannot remove the extended attributes. The action is rejected with a "permission denied" error.
> 
> The issue is present in all releases. I reproduced it in 11, 17, ... 23, head
> 
> The solution is to "chmod u+w" only those files which need to have their extended attributes removed.
> 
> Backport note: in releases prior to jdk23, the change needs to go into file MakeBase.gmk.
> 
> Testing @SAP completed without any related issues.

If we want to make a file read-only in the build output, it needs to happen explicitly after any copy operation. I think it's fine to leave write permission for the user in this case.

The only reason I could imagine this happening is if the source tree (or subsets thereof) has somehow ended up read-only. That seems like a user environment problem, but we shouldn't fail like this because of it.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20203#pullrequestreview-2230789150

From erik.joelsson at oracle.com  Fri Aug  9 18:15:33 2024
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 9 Aug 2024 11:15:33 -0700
Subject: [External] : RE: jdk21u-dev build issue : 8326332: Unclosed
 inline tags cause misalignment in summary tables
In-Reply-To: <AM9PR02MB677047A49073BE20F20A37BC93B82@AM9PR02MB6770.eurprd02.prod.outlook.com>
References: <AM9PR02MB6770EB7789144D05CCF7F79D93AA2@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <474546f8-173b-4d8d-9ba1-6113a67892b2@oracle.com>
 <AM9PR02MB677047A49073BE20F20A37BC93B82@AM9PR02MB6770.eurprd02.prod.outlook.com>
Message-ID: <70cf9779-cd3a-400d-a88a-924454570d23@oracle.com>

To me that sounds like GHA are miss-configured for the update releases. 
To work around this, perhaps we should set an explicit '--release N-1' 
argument when building source intended to run on the bootjdk. It looks 
like we currently set '-source N-1 -target N-1' but that isn't enough as 
it won't change the available JDK APIs to link to.

/Erik

On 8/7/24 6:13 AM, Baesken, Matthias wrote:
>
> Hi Erik,? thanks for the clarification.
>
> Unfortunately we do not see? this in GHA ,? so backports look? nice 
> and ?green? there .
>
> And some people with strict version requirements in the company most 
> likely have a problem with an old / unpatched JDK20 ?.
>
> Best regards, Matthias
>
> *From:*Erik Joelsson <erik.joelsson at oracle.com>
> *Sent:* Wednesday, 7 August 2024 13:58
> *To:* Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie 
> <magnus.ihse.bursie at oracle.com>
> *Subject:* Re: jdk21u-dev build issue : 8326332: Unclosed inline tags 
> cause misalignment in summary tables
>
> Hello Matthias,
>
> If you had sent this to build-dev, you would have received an answer 
> much quicker as both Magnus and I were on vacation.
>
> No, you can't use JDK N features in the langtools modules because 
> because those need to be compatible with the official bootjdk which is 
> version JDK N-1. This has been the case since long before I started 
> working on the JDK.
>
> /Erik
>
> On 7/24/24 12:52 AM, Baesken, Matthias wrote:
>
>     Hi, ?when building ??the backport to 21u-dev
>
>     8326332: Unclosed inline tags cause misalignment in summary tables
>
>     https://github.com/openjdk/jdk21u-dev/pull/866
>     <https://urldefense.com/v3/__https://github.com/openjdk/jdk21u-dev/pull/866__;!!ACWV5N9M2RV99hQ!N6ImKRDmCqe8NMhVHZajZONX-DYbCsHBaMWvQG9P8jGjhveNzlH1ZX1ZtjzkFWHUSB35IB8wb_fY4jsQe_rh1zGFPvw$>
>
>     with a BOOT JDK 20, I run into these build errors :
>
>     (the build works fine when a JDK21 is used as BOOT JDK? ;? in? GHA
>     it is also fine because seems we use JDK21 boot JDK there )
>
>     /open_jdk/jdk21u_dev_2/jdk21u-dev/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java:1156:
>     error: cannot find symbol
>
>     ??????????????????????? && openTags.getLast().equals(name)) {
>
>     ?????????????????????????????????? ^
>
>     ? symbol:?? method getLast()
>
>     ? location: variable openTags of type List<Name>
>
>     /open_jdk/jdk21u_dev_2/jdk21u-dev/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java:1157:
>     error: cannot find symbol
>
>     ??????????????????? openTags.removeLast();
>
>     ??????? ????????????????????^
>
>     ? symbol:?? method removeLast()
>
>     ? location: variable openTags of type List<Name>
>
>     /open_jdk/jdk21u_dev_2/jdk21u-dev/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java:1501:
>     error: cannot find symbol
>
>     result.add(RawHtml.endElement(openTags.removeLast()));
>
>     ?????????????????????^
>
>     ? symbol:?? method removeLast()
>
>     ? location: variable openTags of type List<Name>
>
>     3 errors
>
>     gmake[3]: *** [CompileInterimLangtools.gmk:127:
>     /open_jdk/jdk21u_dev_2/buildfolder/buildtools/interim_langtools_modules/jdk.javadoc.interim/_the.BUILD_jdk.javadoc.interim_batch]
>     Error 1
>
>     gmake[2]: *** [make/Main.gmk:78: interim-langtools] Error 2
>
>     We use here functionality of class List? ( getLast() /
>     removeLast() ) that was added in jdk21.
>
>     Shouldn't we be able to use this functionality ?
>
>     For backports it would be much easier/ cleaner to have the ability
>     of? clean backports without the need to? remove jdk21 functionality .
>
>     Also some people might not even notice those issues , because
>     ?they cannot use old/unpatched/un-secure JDK20? .
>
>     It looks like there might be an issue in the build processso that
>     we reference? java.base? from boot jdk20 , or is it done on
>     purpose that for CompileInterimLangtools / jdk.javadoc this cannot
>     be used) ?
>
>     Best regards, Matthias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240809/d18d2386/attachment-0001.htm>

From Brian.Stafford at microsoft.com  Fri Aug  9 18:18:52 2024
From: Brian.Stafford at microsoft.com (Brian Stafford)
Date: Fri, 9 Aug 2024 18:18:52 +0000
Subject: Add "Windows aarch64" to Supported Build Platforms
In-Reply-To: <c0c46bf6-a21d-4ebf-b831-8b14f3195733@oracle.com>
References: <DS7PR21MB3407A10274F0DD81C1C08F6186B22@DS7PR21MB3407.namprd21.prod.outlook.com>
 <c0c46bf6-a21d-4ebf-b831-8b14f3195733@oracle.com>
Message-ID: <DS7PR21MB34073DF67EC77F25B3F0C7DC86BA2@DS7PR21MB3407.namprd21.prod.outlook.com>

Hi Erik,

Thanks for reaching out. Matthias Baesken helped us make the changes earlier this week.

Brian Stafford
Microsoft


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240809/ba131a5a/attachment.htm>

From erikj at openjdk.org  Fri Aug  9 18:35:30 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 9 Aug 2024 18:35:30 GMT
Subject: RFR: 8338108: Give better error message in configure if a full
 XCode is missing
In-Reply-To: <PnyhYRGeCu1z770ImpIbH1Pd59PR7mKKjSwFbdPx-ko=.e56b2901-ada1-403c-be9f-c646e4e0e01b@github.com>
References: <PnyhYRGeCu1z770ImpIbH1Pd59PR7mKKjSwFbdPx-ko=.e56b2901-ada1-403c-be9f-c646e4e0e01b@github.com>
Message-ID: <p-tbuPCcqOwo3KEparrePcWsKjNen-47m26uxnKxukI=.156c71d5-2702-484e-a470-47a6f706569f@github.com>

On Fri, 9 Aug 2024 10:27:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The XCode command lines tools is almost, but not quite, enough to build the JDK. We still need the metal and metallib tools. The error message given by configure should be improved to indicate if this is the problem with the user's environment.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20520#pullrequestreview-2230830988

From erikj at openjdk.org  Fri Aug  9 18:38:32 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 9 Aug 2024 18:38:32 GMT
Subject: RFR: 8337536: AArch64: Enable BTI branch protection for runtime
 part [v2]
In-Reply-To: <M50QnYb5zJhnQL3ytXnW7Rg7AhQu1aXqDWY250gcNSo=.2397b42c-f1f1-4b2d-a94f-b39c7277b651@github.com>
References: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
 <M50QnYb5zJhnQL3ytXnW7Rg7AhQu1aXqDWY250gcNSo=.2397b42c-f1f1-4b2d-a94f-b39c7277b651@github.com>
Message-ID: <3fLHxTC8pKjO7NWHedvizKrEJZG6CSpJlOFgf27m2hw=.301e8f28-030c-4109-96dc-f4efc2fa918c@github.com>

On Fri, 9 Aug 2024 13:37:54 GMT, Fei Gao <fgao at openjdk.org> wrote:

>> This patch enables BTI branch protection for runtime part on Linux/aarch64 platform.
>> 
>> Motivation
>> 
>> 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. User-level packages can gain additional hardening by compiling with the GCC/Clang flag `-mbranch-protection=flag`. See [1].
>> 
>> 2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as one VM configure flag, which would pass `-mbranch-protection=standard` compilation flags to all c/c++ files. Note that `standard` turns on both `pac-ret` and `bti` branch protections. For more details about code reuse attacks and hardware-assisted branch protections on AArch64, see [3].
>> 
>> However, we checked the `.note.gnu.property` section of all the shared libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so didn't set these two target feature bits:
>> 
>> 
>>   GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>>   GNU_PROPERTY_AARCH64_FEATURE_1_PAC
>> 
>> 
>> Note-1: BTI is an all or nothing property for a link unit [4]. That is, libjvm.so is not BTI-enabled.
>> 
>> Note-2: PAC bit in `.note.gnu.property` section is used to protect `.got.plt` table. It's independent of whether the relocatable objects use PAC or not.
>> 
>> Goal
>> 
>> Hence, this patch aims to set PAC/BTI feature bits of the `.note.gnu.property` section for libjvm.so.
>> 
>> Implementation
>> 
>> Task-1: find out the problematic input objects
>> 
>> From [5], "Static linkers processing ELF relocatable objects must set the feature bit in the output object or image only if all the input objects have the corresponding feature bit set." Hence we suspect that the root cause is probably that the PAC/BTI feature bits are not set only for some input objects of libjvm.so.
>> 
>> In order to find out these inputs, we passed `--force-bti` linker flag [4] in my local test. This linker flag would warn if any input object does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following list:
>> 
>> 
>>   src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
>>   src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S
>>   src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S
>>   src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S
>> 
>> 
>> Task-2: add `.note.gnu.property` section for these assembly files
>> 
>> As mentioned in Motivation-2 part, `-mbranch-protection=standard` is passed to compile c/c++ files but these assembly files are missed.
>> 
>> In this patch, we also pass `-mbranch-protection=standard` flag to assembler (See the update i...
>
> Fei Gao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Clean up makefile
>  - Merge branch 'master' into enable-bti-runtime
>  - 8337536: AArch64: Enable BTI branch protection for runtime part
>    
>    This patch enables BTI branch protection for runtime part on
>    Linux/aarch64 platform.
>    
>    Motivation
>    
>    1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default.
>    User-level packages can gain additional hardening by compiling with the
>    GCC/Clang flag `-mbranch-protection=flag`. See [1].
>    
>    2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as
>    one VM configure flag, which would pass `-mbranch-protection=standard`
>    compilation flags to all c/c++ files. Note that `standard` turns on both
>    `pac-ret` and `bti` branch protections. For more details about code
>    reuse attacks and hardware-assisted branch protections on AArch64, see
>    [3].
>    
>    However, we checked the `.note.gnu.property` section of all the shared
>    libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so
>    didn't set these two target feature bits:
>    
>    ```
>      GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>      GNU_PROPERTY_AARCH64_FEATURE_1_PAC
>    ```
>    
>    Note-1: BTI is an all or nothing property for a link unit [4]. That is,
>    libjvm.so is not BTI-enabled.
>    
>    Note-2: PAC bit in `.note.gnu.property` section is used to protect
>    `.got.plt` table. It's independent of whether the relocatable objects
>    use PAC or not.
>    
>    Goal
>    
>    Hence, this patch aims to set PAC/BTI feature bits of the
>    `.note.gnu.property` section for libjvm.so.
>    
>    Implementation
>    
>    Task-1: find out the problematic input objects
>    
>    From [5], "Static linkers processing ELF relocatable objects must set
>    the feature bit in the output object or image only if all the input
>    objects have the corresponding feature bit set." Hence we suspect that
>    the root cause is probably that the PAC/BTI feature bits are not set
>    only for some input objects of libjvm.so.
>    
>    In order to find out these inputs, we passed `--force-bti` linker flag
>    [4] in my local test. This linker flag would warn if any input object
>    does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following
>    list:
>    
>    ```
>      src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
> ...

Build changes look good.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20491#pullrequestreview-2230834719

From bpb at openjdk.org  Fri Aug  9 21:25:43 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Aug 2024 21:25:43 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava
In-Reply-To: <yq20lmGByFHXOtnDypoqB9IBiKA4MtpWciynkRd8rQs=.14028583-b497-4102-a3aa-597dd4820122@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <9Hav9cYqe9BCvB8L4WOxBvTHydeiHrqKfmZhl_5nTSo=.1e4b8663-475c-489e-a757-88d248ce0fae@github.com>
 <yq20lmGByFHXOtnDypoqB9IBiKA4MtpWciynkRd8rQs=.14028583-b497-4102-a3aa-597dd4820122@github.com>
Message-ID: <CMEneLagY0Ru5EeggWc3pS5swtt6RUP5573Wx_hsGvI=.56996229-57ca-4c1f-ade6-502f99ab2e3f@github.com>

On Fri, 26 Jul 2024 21:34:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > Also think to work through some naming on IOUtil vs. NIOUtil as it won't be obvious to maintainers which class to use.
> 
> Maybe `NIOUtil` should be `NetUtil` as its methods appear to be invoked only by classes involved in networking?

Another option is `NIONetUtil` but the `NIO` prefix is redundant with the package name.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2278773773

From dholmes at openjdk.org  Sun Aug 11 21:59:42 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 11 Aug 2024 21:59:42 GMT
Subject: RFR: 8337410: The makefiles should set problemlist and adjust
 timeout basing on the given VM flags [v2]
In-Reply-To: <mMI8sps-o9W0wnY2NR9C7srUUcwp9gTKE3m_J9YIV7o=.35b2527f-b080-40fe-89eb-27e75572c689@github.com>
References: <HSbKJYVYgMPgkPuXFwzDECWYOcfk5d86zp1gNmS5eJM=.38b1c9c5-558c-4584-a3e3-ac23640f7c5c@github.com>
 <mMI8sps-o9W0wnY2NR9C7srUUcwp9gTKE3m_J9YIV7o=.35b2527f-b080-40fe-89eb-27e75572c689@github.com>
Message-ID: <Qe0h7hVT84sEdSOxS5pvipsm-z3RWKdYIcJ8R9tl5x4=.2693eead-25e6-48ce-b073-0680acad25f4@github.com>

On Mon, 5 Aug 2024 18:34:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> There jtreg tests have several additional problemlists 
>> ProblemList-Xcomp.txt
>> ProblemList-generational-zgc.txt
>> ProblemList-zgc.txt
>> Each of them is bound to corresponding execution mode (Xcomp/ZGC) and it makes sense to treat them like standard problemlist when tests are executed with -Xcomp or ZGC enabled.
>> Currently, it is needed to set them manually and it is often forgotten. So engineers waste time analyzing known failures.
>> 
>> Additionally, the **default** timeoutFactor is increased when Xcomp is enabled because of slowness of this mode. 
>> 
>> The jtreg allows to add the same problemlist twice so it is not needed to update any execution system that set problemlists.
>> 
>> Later it might makes sens to set 'JTREG_ALL_OPTIONS' by asking java about actually set mode. So it is possible to adjust  options for fastdebug/slowdebug/product modes and/or different options that are set during compilation (saying different default GC).
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   makefile updated.

Doesn't the use of multiple problem-list files like this greatly increase the risk of running into duplicate PL entries which are not handled correctly by jtreg?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20430#issuecomment-2282901814

From dholmes at openjdk.org  Mon Aug 12 04:33:33 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 12 Aug 2024 04:33:33 GMT
Subject: RFR: 8337410: The makefiles should set problemlist and adjust
 timeout basing on the given VM flags [v2]
In-Reply-To: <mMI8sps-o9W0wnY2NR9C7srUUcwp9gTKE3m_J9YIV7o=.35b2527f-b080-40fe-89eb-27e75572c689@github.com>
References: <HSbKJYVYgMPgkPuXFwzDECWYOcfk5d86zp1gNmS5eJM=.38b1c9c5-558c-4584-a3e3-ac23640f7c5c@github.com>
 <mMI8sps-o9W0wnY2NR9C7srUUcwp9gTKE3m_J9YIV7o=.35b2527f-b080-40fe-89eb-27e75572c689@github.com>
Message-ID: <ofNZRToT-cleQfbuior3kC8OZ1n7mKfoFIJFJhxLE40=.3a3a8d71-3ad7-4ffb-aa5f-430622012114@github.com>

On Mon, 5 Aug 2024 18:34:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> There jtreg tests have several additional problemlists 
>> ProblemList-Xcomp.txt
>> ProblemList-generational-zgc.txt
>> ProblemList-zgc.txt
>> Each of them is bound to corresponding execution mode (Xcomp/ZGC) and it makes sense to treat them like standard problemlist when tests are executed with -Xcomp or ZGC enabled.
>> Currently, it is needed to set them manually and it is often forgotten. So engineers waste time analyzing known failures.
>> 
>> Additionally, the **default** timeoutFactor is increased when Xcomp is enabled because of slowness of this mode. 
>> 
>> The jtreg allows to add the same problemlist twice so it is not needed to update any execution system that set problemlists.
>> 
>> Later it might makes sens to set 'JTREG_ALL_OPTIONS' by asking java about actually set mode. So it is possible to adjust  options for fastdebug/slowdebug/product modes and/or different options that are set during compilation (saying different default GC).
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   makefile updated.

Never mind. The problem is only with multiple entries in the same file apparently: [CODETOOLS-7903657](https://bugs.openjdk.org/browse/CODETOOLS-7903657)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20430#issuecomment-2283094653

From kbarrett at openjdk.org  Mon Aug 12 05:31:04 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 12 Aug 2024 05:31:04 GMT
Subject: RFR: 8338154: Fix -Wzero-as-null-pointer-constant warnings in gtest
 framework
Message-ID: <PPrZeaX5gCyWQ7SPwTeUzqlNLfJwphAUcNhPuXUVOdk=.e67fb09b-051b-47d7-9c10-1a48711a05c2@github.com>

Please review this change to remove -Wzero-as-null-pointer-constant warnings
produced by the gtest framework when such warnings are enabled.

Warnings from the 3rd party GoogleTest are suppressed by disabling that
warning when compiling those files.

Testing: mach5 tier1

-------------

Commit messages:
 - gtest warnings

Changes: https://git.openjdk.org/jdk/pull/20536/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20536&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338154
  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20536.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20536/head:pull/20536

PR: https://git.openjdk.org/jdk/pull/20536

From matthias.baesken at sap.com  Mon Aug 12 07:08:49 2024
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 12 Aug 2024 07:08:49 +0000
Subject: [External] : RE: jdk21u-dev build issue : 8326332: Unclosed
 inline tags cause misalignment in summary tables
In-Reply-To: <70cf9779-cd3a-400d-a88a-924454570d23@oracle.com>
References: <AM9PR02MB6770EB7789144D05CCF7F79D93AA2@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <474546f8-173b-4d8d-9ba1-6113a67892b2@oracle.com>
 <AM9PR02MB677047A49073BE20F20A37BC93B82@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <70cf9779-cd3a-400d-a88a-924454570d23@oracle.com>
Message-ID: <AM9PR02MB67709F348A2C0B02C5D5975893852@AM9PR02MB6770.eurprd02.prod.outlook.com>

Hi Erik, the  '--release N-1'   sounds like a good idea ; where do we have to set it ?

Best regards, Matthias


>To me that sounds like GHA are miss-configured for the update releases. To work around this, perhaps we should set an explicit '--release N-1' argument when building source intended to run on the bootjdk. It looks like we currently set '-source N-1 -target N-1' but that isn't enough as it won't change the available JDK APIs to link to.

>/Erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240812/4269daba/attachment.htm>

From shade at openjdk.org  Mon Aug 12 10:54:37 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 12 Aug 2024 10:54:37 GMT
Subject: RFR: 8338108: Give better error message in configure if a full
 XCode is missing
In-Reply-To: <PnyhYRGeCu1z770ImpIbH1Pd59PR7mKKjSwFbdPx-ko=.e56b2901-ada1-403c-be9f-c646e4e0e01b@github.com>
References: <PnyhYRGeCu1z770ImpIbH1Pd59PR7mKKjSwFbdPx-ko=.e56b2901-ada1-403c-be9f-c646e4e0e01b@github.com>
Message-ID: <pVQvsAV1uTCUDfnDMBnSv6TNQE8wvPFN1YjlcQTAdE8=.9fb720b6-4e68-4e85-abc7-491cef623c70@github.com>

On Fri, 9 Aug 2024 10:27:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The XCode command lines tools is almost, but not quite, enough to build the JDK. We still need the metal and metallib tools. The error message given by configure should be improved to indicate if this is the problem with the user's environment.

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20520#pullrequestreview-2232646099

From erik.joelsson at oracle.com  Mon Aug 12 12:30:21 2024
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 12 Aug 2024 05:30:21 -0700
Subject: [External] : RE: jdk21u-dev build issue : 8326332: Unclosed
 inline tags cause misalignment in summary tables
In-Reply-To: <AM9PR02MB67709F348A2C0B02C5D5975893852@AM9PR02MB6770.eurprd02.prod.outlook.com>
References: <AM9PR02MB6770EB7789144D05CCF7F79D93AA2@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <474546f8-173b-4d8d-9ba1-6113a67892b2@oracle.com>
 <AM9PR02MB677047A49073BE20F20A37BC93B82@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <70cf9779-cd3a-400d-a88a-924454570d23@oracle.com>
 <AM9PR02MB67709F348A2C0B02C5D5975893852@AM9PR02MB6770.eurprd02.prod.outlook.com>
Message-ID: <a3fe434b-1fd8-45c9-9670-d33a3d99f94a@oracle.com>

There is a variable BOOT_JDK_SOURCETARGET exported from configure and 
picked up in JavaCompilation.gmk. We should probably change the name of 
the variable as well to avoid confusion.

/Erik

On 8/12/24 12:08 AM, Baesken, Matthias wrote:
>
> Hi Erik, the '--release N-1'?? sounds like a good idea ; where do we 
> have to set it ?
>
> Best regards, Matthias
>
> >To me that sounds like GHA are miss-configured for the update 
> releases. To work around this, perhaps we should set an explicit 
> '--release N-1' argument when building source intended to run on the 
> bootjdk. It looks like we currently set '-source N-1 -target N-1' but 
> that isn't enough as it won't change the available JDK APIs to link to.
>
> >/Erik
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240812/b1ed1ae3/attachment-0001.htm>

From matthias.baesken at sap.com  Mon Aug 12 12:56:21 2024
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 12 Aug 2024 12:56:21 +0000
Subject: [External] : RE: jdk21u-dev build issue : 8326332: Unclosed
 inline tags cause misalignment in summary tables
In-Reply-To: <a3fe434b-1fd8-45c9-9670-d33a3d99f94a@oracle.com>
References: <AM9PR02MB6770EB7789144D05CCF7F79D93AA2@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <474546f8-173b-4d8d-9ba1-6113a67892b2@oracle.com>
 <AM9PR02MB677047A49073BE20F20A37BC93B82@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <70cf9779-cd3a-400d-a88a-924454570d23@oracle.com>
 <AM9PR02MB67709F348A2C0B02C5D5975893852@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <a3fe434b-1fd8-45c9-9670-d33a3d99f94a@oracle.com>
Message-ID: <AM9PR02MB677061F9A51688118C8235F393852@AM9PR02MB6770.eurprd02.prod.outlook.com>

You mean instead of   BOOT_JDK_SOURCETARGET   use  BOOT_JDK_RELEASETARGET   (and set '--release N-1'  there)  ?

Best regards, Matthias



From: Erik Joelsson <erik.joelsson at oracle.com>
Sent: Monday, 12 August 2024 14:30
To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; build-dev at openjdk.org
Subject: Re: [External] : RE: jdk21u-dev build issue : 8326332: Unclosed inline tags cause misalignment in summary tables


There is a variable BOOT_JDK_SOURCETARGET exported from configure and picked up in JavaCompilation.gmk. We should probably change the name of the variable as well to avoid confusion.

/Erik
On 8/12/24 12:08 AM, Baesken, Matthias wrote:
Hi Erik, the  '--release N-1'   sounds like a good idea ; where do we have to set it ?

Best regards, Matthias


>To me that sounds like GHA are miss-configured for the update releases. To work around this, perhaps we should set an explicit '--release N-1' argument when building source intended to run on the bootjdk. It looks like we currently set '-source N-1 -target N-1' but that isn't enough as it won't change the available JDK APIs to link to.

>/Erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240812/7d77d7dd/attachment.htm>

From erik.joelsson at oracle.com  Mon Aug 12 13:27:22 2024
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 12 Aug 2024 06:27:22 -0700
Subject: [External] : RE: jdk21u-dev build issue : 8326332: Unclosed
 inline tags cause misalignment in summary tables
In-Reply-To: <AM9PR02MB677061F9A51688118C8235F393852@AM9PR02MB6770.eurprd02.prod.outlook.com>
References: <AM9PR02MB6770EB7789144D05CCF7F79D93AA2@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <474546f8-173b-4d8d-9ba1-6113a67892b2@oracle.com>
 <AM9PR02MB677047A49073BE20F20A37BC93B82@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <70cf9779-cd3a-400d-a88a-924454570d23@oracle.com>
 <AM9PR02MB67709F348A2C0B02C5D5975893852@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <a3fe434b-1fd8-45c9-9670-d33a3d99f94a@oracle.com>
 <AM9PR02MB677061F9A51688118C8235F393852@AM9PR02MB6770.eurprd02.prod.outlook.com>
Message-ID: <3ae2b089-437e-423f-95ab-4e47defa436c@oracle.com>

Something like that yes. Maybe just BOOT_JDK_RELEASE, or possibly 
BOOT_JDK_RELEASE_FLAG?

/Erik

On 8/12/24 5:56 AM, Baesken, Matthias wrote:
>
> You mean instead of BOOT_JDK_SOURCETARGET?? use 
> BOOT_JDK_RELEASETARGET?? (and set '--release N-1'??there)? ?
>
> Best regards, Matthias
>
> *From:*Erik Joelsson <erik.joelsson at oracle.com>
> *Sent:* Monday, 12 August 2024 14:30
> *To:* Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie 
> <magnus.ihse.bursie at oracle.com>; build-dev at openjdk.org
> *Subject:* Re: [External] : RE: jdk21u-dev build issue : 8326332: 
> Unclosed inline tags cause misalignment in summary tables
>
> There is a variable BOOT_JDK_SOURCETARGET exported from configure and 
> picked up in JavaCompilation.gmk. We should probably change the name 
> of the variable as well to avoid confusion.
>
> /Erik
>
> On 8/12/24 12:08 AM, Baesken, Matthias wrote:
>
>     Hi Erik, the '--release N-1'?? sounds like a good idea ; where do
>     we have to set it ?
>
>     Best regards, Matthias
>
>     >To me that sounds like GHA are miss-configured for the update
>     releases. To work around this, perhaps we should set an explicit
>     '--release N-1' argument when building source intended to run on
>     the bootjdk. It looks like we currently set '-source N-1 -target
>     N-1' but that isn't enough as it won't change the available JDK
>     APIs to link to.
>
>     >/Erik
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240812/bb60eed1/attachment-0001.htm>

From matthias.baesken at sap.com  Mon Aug 12 14:15:27 2024
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 12 Aug 2024 14:15:27 +0000
Subject: [External] : RE: jdk21u-dev build issue : 8326332: Unclosed
 inline tags cause misalignment in summary tables
In-Reply-To: <3ae2b089-437e-423f-95ab-4e47defa436c@oracle.com>
References: <AM9PR02MB6770EB7789144D05CCF7F79D93AA2@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <474546f8-173b-4d8d-9ba1-6113a67892b2@oracle.com>
 <AM9PR02MB677047A49073BE20F20A37BC93B82@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <70cf9779-cd3a-400d-a88a-924454570d23@oracle.com>
 <AM9PR02MB67709F348A2C0B02C5D5975893852@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <a3fe434b-1fd8-45c9-9670-d33a3d99f94a@oracle.com>
 <AM9PR02MB677061F9A51688118C8235F393852@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <3ae2b089-437e-423f-95ab-4e47defa436c@oracle.com>
Message-ID: <AM9PR02MB67704DE5466BCCE41C7A2D2F93852@AM9PR02MB6770.eurprd02.prod.outlook.com>

I created

https://bugs.openjdk.org/browse/JDK-8338205
8338205: replace BOOT_JDK_SOURCETARGET

Best regards, Matthias


>Something like that yes. Maybe just BOOT_JDK_RELEASE, or possibly BOOT_JDK_RELEASE_FLAG?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240812/1942a87c/attachment.htm>

From sgehwolf at openjdk.org  Mon Aug 12 14:21:58 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 12 Aug 2024 14:21:58 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v33]
In-Reply-To: <7MIX-3emJ0epp2GHVCT3ulfXMB0yFMxSQ-u2-KFLN6Y=.f84b6d3e-2485-43e0-8de0-5b292242b5d7@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <7MIX-3emJ0epp2GHVCT3ulfXMB0yFMxSQ-u2-KFLN6Y=.f84b6d3e-2485-43e0-8de0-5b292242b5d7@github.com>
Message-ID: <TXlNz6vzjx1NgAPCzlTqR1MYihOI2iUnrigwX3DJhFI=.c769621e-e5c1-425f-b0ea-2020828c29b1@github.com>

On Mon, 24 Jun 2024 14:33:51 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 137 commits:
> 
>  - JLinkDedupTestBatchSizeOne.java test fix
>    
>    Run only the packaged modules version if we have a linkable JDK runtime
>    with packaged modules available as well in the JDK install.
>  - Enable IncludeLocalesPluginTest
>  - Enable GenerateJLIClassesPluginTest.java test
>  - Enable JLinkReproducibleTest.java for linkable JDK images
>  - Remove restriction on directory based modules
>    
>    Enable the following tests:
>    - JLink100Modules.java
>    - JLinkDedupTestBatchSizeOne.java
>  - Comment fix in JRTArchive. Long line in JlinkTask
>  - Comment fixes in ImageFileCreator
>  - Comments and clean-up in JlinkTask
>  - Helper support for linkable JDK runtimes
>  - Test clean-up. class-file API module.
>  - ... and 127 more: https://git.openjdk.org/jdk/compare/5cad0b4d...04cd98f8

Please keep it open bot.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2284102882

From matthias.baesken at sap.com  Mon Aug 12 14:44:57 2024
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 12 Aug 2024 14:44:57 +0000
Subject: [External] : RE: jdk21u-dev build issue : 8326332: Unclosed
 inline tags cause misalignment in summary tables
References: <AM9PR02MB6770EB7789144D05CCF7F79D93AA2@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <474546f8-173b-4d8d-9ba1-6113a67892b2@oracle.com>
 <AM9PR02MB677047A49073BE20F20A37BC93B82@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <70cf9779-cd3a-400d-a88a-924454570d23@oracle.com>
 <AM9PR02MB67709F348A2C0B02C5D5975893852@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <a3fe434b-1fd8-45c9-9670-d33a3d99f94a@oracle.com>
 <AM9PR02MB677061F9A51688118C8235F393852@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <3ae2b089-437e-423f-95ab-4e47defa436c@oracle.com> 
Message-ID: <AM9PR02MB677057198575494FB36AEBF193852@AM9PR02MB6770.eurprd02.prod.outlook.com>

Unfortunately  using  --release is not working in our build.
We run  very soon into this error :

error: exporting a package from system module java.base is not allowed with --release

Best regards, Matthias


>I created
>
>https://bugs.openjdk.org/browse/JDK-8338205
>8338205: replace BOOT_JDK_SOURCETARGET
>
>Best regards, Matthias
>
>>Something like that yes. Maybe just BOOT_JDK_RELEASE, or possibly BOOT_JDK_RELEASE_FLAG?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240812/12e5174d/attachment-0001.htm>

From tim.bell at oracle.com  Mon Aug 12 15:04:20 2024
From: tim.bell at oracle.com (tim.bell at oracle.com)
Date: Mon, 12 Aug 2024 15:04:20 +0000
Subject: Need CCATS for OpenJDK 8 (ECCN 5D992.c)
In-Reply-To: <AM7PR04MB71926729E2DF1F317886F896CA852@AM7PR04MB7192.eurprd04.prod.outlook.com>
References: <AM7PR04MB7192EE0AE2F41A1B9BCE9C4FCAB92@AM7PR04MB7192.eurprd04.prod.outlook.com>
 <AM7PR04MB7192FA5FED147F12F89A3FCFCAB92@AM7PR04MB7192.eurprd04.prod.outlook.com>
 <AM7PR04MB71920D2B6F4FA93F6C734EA0CA852@AM7PR04MB7192.eurprd04.prod.outlook.com>
 <AM7PR04MB71926729E2DF1F317886F896CA852@AM7PR04MB7192.eurprd04.prod.outlook.com>
Message-ID: <1f18679e-9e7e-4024-818a-4e90b61c43f7@oracle.com>

Hello

OpenJDK can't provide export control certification information for third 
parties.

Contact the vendor providing your JDK 8 runtime for this information.

Best regards-

Tim Bell
OpenJDK.org infrastructure team

On 8/12/24 13:34, Hemantkumar Prakashbhai Makhijani wrote:
> Hello
> Jdk8u, build-dev , jdk-updates-dev
>
> Can you guys help us here please ?
>
>
>
>
>
> Regards
> Hemantkumar Makhijani
>
>
>
> ------------------------------------------------------------------------
> *From:* Hemantkumar Prakashbhai Makhijani
> *Sent:* Monday, August 12, 2024 3:45 PM
> *To:* mailman-owner at openjdk.org <mailman-owner at openjdk.org>
> *Cc:* Shankar Shailesh <SShailesh at slb.com>; Rim Bains <bains1 at slb.com>
> *Subject:* RE: Need CCATS for OpenJDK 8 (ECCN 5D992.c)
>
> Gentle reminder ?
>
> Since *OpenJDK 8*is managed by you,
>
> Please provide Commodity Classification Automated Tracking System 
> (CCATS 
> <https://urldefense.com/v3/__https:/en.wikipedia.org/wiki/Commodity_Classification_Automated_Tracking_System__;!!Kjv0uj3L4nM6H-I!kKdj5-2J8PMr6snsnaIEK7ihVZrfuBUHEvHSrIz071YEiEqKQVtly-jLmqnJkanl1GW9IAXygO34$>) 
> .
>
> This is because, we got to know that, for ENC product, it is mandatory 
> to get CCATS certificate from U.S. to meet export control guidelines.
>
> Regards
>
> *Hemant Makhijani*
>
> *From:*Hemantkumar Prakashbhai Makhijani
> *Sent:* Thursday, August 8, 2024 7:21 PM
> *To:* mailman-owner at openjdk.org
> *Cc:* Shankar Shailesh <SShailesh at slb.com>; Rim Bains <bains1 at slb.com>
> *Subject:* Need CCATS for OpenJDK 8 (ECCN 5D992.c)
>
> Hello
>
> We are interested to obtain a copy of the Commodity Classification 
> Automated Tracking System (CCATS 
> <https://urldefense.com/v3/__https:/en.wikipedia.org/wiki/Commodity_Classification_Automated_Tracking_System__;!!Kjv0uj3L4nM6H-I!kKdj5-2J8PMr6snsnaIEK7ihVZrfuBUHEvHSrIz071YEiEqKQVtly-jLmqnJkanl1GW9IAXygO34$>)certificate 
> so that we can understand how *ENC note reporting* should be handled 
> for your *below* product :
>
> OpenJDK 8 
> <https://urldefense.com/v3/__https:/openjdk.org/projects/jdk8/__;!!Kjv0uj3L4nM6H-I!gBn5YiaC0D2z5emONQmzd9BweE6qhAlD02ME0qIc6nghKCpywUKOOco6dSlXNWEcCoTl7d7a9d8pCXPpIrPe5u9S$>.
>
> Note :-
>
> Referring this, we could understand that OpenJDK has ECCN as 5D992.c 
> and CCATS number as *G167674. *However, we don?t see actual CCATS 
> certificate anywhere.
>
> Regards
>
> *Hemantkumar Makhijani | SLB*
>
> SLB-Public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240812/87e35e2c/attachment.htm>

From dfuchs at openjdk.org  Mon Aug 12 15:14:34 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Aug 2024 15:14:34 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
Message-ID: <jeA6snOedvNP-wP-5Aw4RWMKAqJZ_SGFOZYTHCrDoNE=.27f8f41e-0637-446c-b2e7-7b0b98fa73a0@github.com>

On Fri, 9 Aug 2024 17:59:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c

The changes to the java/net code look OK to me now. Thanks Brian. I am approving these changes - but please also get a Reviewer for the NIO and build side of these.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2233341338

From ihse at openjdk.org  Mon Aug 12 15:35:35 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Aug 2024 15:35:35 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
Message-ID: <be3LT-XgLWSRAmNaJgWOEwhpTXZsHDYvrO1T8tg4tsw=.1f73b219-19d7-4222-8163-1e71d1de574f@github.com>

On Fri, 9 Aug 2024 17:59:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c

Build changes look good.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2233398100

From ihse at openjdk.org  Mon Aug 12 15:36:37 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Aug 2024 15:36:37 GMT
Subject: Integrated: 8338108: Give better error message in configure if a full
 XCode is missing
In-Reply-To: <PnyhYRGeCu1z770ImpIbH1Pd59PR7mKKjSwFbdPx-ko=.e56b2901-ada1-403c-be9f-c646e4e0e01b@github.com>
References: <PnyhYRGeCu1z770ImpIbH1Pd59PR7mKKjSwFbdPx-ko=.e56b2901-ada1-403c-be9f-c646e4e0e01b@github.com>
Message-ID: <1rn7UnV9-vYMFRIR_b_aUR8iphiURxYvcQtacBp_KOA=.5983fa4a-8685-497c-8503-8149ce16e6bd@github.com>

On Fri, 9 Aug 2024 10:27:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The XCode command lines tools is almost, but not quite, enough to build the JDK. We still need the metal and metallib tools. The error message given by configure should be improved to indicate if this is the problem with the user's environment.

This pull request has now been integrated.

Changeset: a36fb368
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a36fb368e1a3630d32908884f4abdc3382eb9aaa
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8338108: Give better error message in configure if a full XCode is missing

Reviewed-by: jwaters, erikj, shade

-------------

PR: https://git.openjdk.org/jdk/pull/20520

From alanb at openjdk.org  Mon Aug 12 15:48:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 Aug 2024 15:48:33 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
Message-ID: <SpMnbnugG9ZKlNltWcPJ9_fBoUbYST6O70QgpNqNKsE=.702b4843-4d2a-4216-a659-b88085af6b39@github.com>

On Fri, 9 Aug 2024 17:59:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c

I plan to review this, please do not integrate this change until I get time to make sure that the placement and naming is workable in these areas.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2284326641

From bpb at openjdk.org  Mon Aug 12 17:14:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 12 Aug 2024 17:14:34 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <SpMnbnugG9ZKlNltWcPJ9_fBoUbYST6O70QgpNqNKsE=.702b4843-4d2a-4216-a659-b88085af6b39@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <SpMnbnugG9ZKlNltWcPJ9_fBoUbYST6O70QgpNqNKsE=.702b4843-4d2a-4216-a659-b88085af6b39@github.com>
Message-ID: <oaXC9bmYWzhk0cmHn2O7K8SySeDsjNCsK-3h790GtTs=.20455ccb-59a5-4264-9818-072ae6d42fc4@github.com>

On Mon, 12 Aug 2024 15:46:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> please do not integrate this change until I get time

Sure, of course I will not.

Thanks to @magicus and @dfuch for helping to make it better.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2284529067

From ihse at openjdk.org  Mon Aug 12 20:41:31 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Aug 2024 20:41:31 GMT
Subject: RFR: 8338154: Fix -Wzero-as-null-pointer-constant warnings in
 gtest framework
In-Reply-To: <PPrZeaX5gCyWQ7SPwTeUzqlNLfJwphAUcNhPuXUVOdk=.e67fb09b-051b-47d7-9c10-1a48711a05c2@github.com>
References: <PPrZeaX5gCyWQ7SPwTeUzqlNLfJwphAUcNhPuXUVOdk=.e67fb09b-051b-47d7-9c10-1a48711a05c2@github.com>
Message-ID: <xh-2oJ13smKGcbjA46BXigO4i80Ruz5-dARcHEN8p_s=.8ffcdd0d-b2db-4e36-843b-66a39f0e5a8f@github.com>

On Mon, 12 Aug 2024 05:25:49 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to remove -Wzero-as-null-pointer-constant warnings
> produced by the gtest framework when such warnings are enabled.
> 
> Warnings from the 3rd party GoogleTest are suppressed by disabling that
> warning when compiling those files.
> 
> Testing: mach5 tier1

Build change is trivially fine.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20536#pullrequestreview-2233974704

From dholmes at openjdk.org  Tue Aug 13 01:27:47 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 13 Aug 2024 01:27:47 GMT
Subject: RFR: 8338154: Fix -Wzero-as-null-pointer-constant warnings in
 gtest framework
In-Reply-To: <PPrZeaX5gCyWQ7SPwTeUzqlNLfJwphAUcNhPuXUVOdk=.e67fb09b-051b-47d7-9c10-1a48711a05c2@github.com>
References: <PPrZeaX5gCyWQ7SPwTeUzqlNLfJwphAUcNhPuXUVOdk=.e67fb09b-051b-47d7-9c10-1a48711a05c2@github.com>
Message-ID: <nvvINgtXkmmzvpeK5x593c4jHDk4D1vFIcpQZrUoSfI=.aa90f665-c029-4089-887d-6b7c14c0d659@github.com>

On Mon, 12 Aug 2024 05:25:49 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to remove -Wzero-as-null-pointer-constant warnings
> produced by the gtest framework when such warnings are enabled.
> 
> Warnings from the 3rd party GoogleTest are suppressed by disabling that
> warning when compiling those files.
> 
> Testing: mach5 tier1

Looks good. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20536#pullrequestreview-2234287336

From jwaters at openjdk.org  Tue Aug 13 02:01:47 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 13 Aug 2024 02:01:47 GMT
Subject: RFR: 8338154: Fix -Wzero-as-null-pointer-constant warnings in
 gtest framework
In-Reply-To: <PPrZeaX5gCyWQ7SPwTeUzqlNLfJwphAUcNhPuXUVOdk=.e67fb09b-051b-47d7-9c10-1a48711a05c2@github.com>
References: <PPrZeaX5gCyWQ7SPwTeUzqlNLfJwphAUcNhPuXUVOdk=.e67fb09b-051b-47d7-9c10-1a48711a05c2@github.com>
Message-ID: <CLaJphNJ4dRu60IDgHS8dKfgpTSE7zOfalUIabl6rPA=.f9cc0383-09b0-41e5-974c-83289952e0fc@github.com>

On Mon, 12 Aug 2024 05:25:49 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to remove -Wzero-as-null-pointer-constant warnings
> produced by the gtest framework when such warnings are enabled.
> 
> Warnings from the 3rd party GoogleTest are suppressed by disabling that
> warning when compiling those files.
> 
> Testing: mach5 tier1

Marked as reviewed by jwaters (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20536#pullrequestreview-2234320445

From kbarrett at openjdk.org  Tue Aug 13 05:49:52 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 13 Aug 2024 05:49:52 GMT
Subject: RFR: 8338154: Fix -Wzero-as-null-pointer-constant warnings in
 gtest framework
In-Reply-To: <xh-2oJ13smKGcbjA46BXigO4i80Ruz5-dARcHEN8p_s=.8ffcdd0d-b2db-4e36-843b-66a39f0e5a8f@github.com>
References: <PPrZeaX5gCyWQ7SPwTeUzqlNLfJwphAUcNhPuXUVOdk=.e67fb09b-051b-47d7-9c10-1a48711a05c2@github.com>
 <xh-2oJ13smKGcbjA46BXigO4i80Ruz5-dARcHEN8p_s=.8ffcdd0d-b2db-4e36-843b-66a39f0e5a8f@github.com>
Message-ID: <59GtKeYKdA05bOBCJYkXlQ_wYW_9FhSdDW0ZeDLWrbg=.e448cf9a-1564-4aef-bff7-9bc9bb06cbf9@github.com>

On Mon, 12 Aug 2024 20:38:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Please review this change to remove -Wzero-as-null-pointer-constant warnings
>> produced by the gtest framework when such warnings are enabled.
>> 
>> Warnings from the 3rd party GoogleTest are suppressed by disabling that
>> warning when compiling those files.
>> 
>> Testing: mach5 tier1
>
> Build change is trivially fine.

Thanks for reviews @magicus , @TheShermanTanker , and @dholmes-ora

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20536#issuecomment-2285382903

From kbarrett at openjdk.org  Tue Aug 13 05:49:53 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 13 Aug 2024 05:49:53 GMT
Subject: Integrated: 8338154: Fix -Wzero-as-null-pointer-constant warnings in
 gtest framework
In-Reply-To: <PPrZeaX5gCyWQ7SPwTeUzqlNLfJwphAUcNhPuXUVOdk=.e67fb09b-051b-47d7-9c10-1a48711a05c2@github.com>
References: <PPrZeaX5gCyWQ7SPwTeUzqlNLfJwphAUcNhPuXUVOdk=.e67fb09b-051b-47d7-9c10-1a48711a05c2@github.com>
Message-ID: <1LwXdAvPvm1ksXvMqkk4_xmZCDe-Omkv5dOl2XOQmM8=.a1630592-b156-4fd5-a22f-dff499ae5f38@github.com>

On Mon, 12 Aug 2024 05:25:49 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to remove -Wzero-as-null-pointer-constant warnings
> produced by the gtest framework when such warnings are enabled.
> 
> Warnings from the 3rd party GoogleTest are suppressed by disabling that
> warning when compiling those files.
> 
> Testing: mach5 tier1

This pull request has now been integrated.

Changeset: d77e6fe4
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d77e6fe45c7b834db457a772ce0bea514d2e44f3
Stats:     3 lines in 2 files changed: 1 ins; 0 del; 2 mod

8338154: Fix -Wzero-as-null-pointer-constant warnings in gtest framework

Reviewed-by: ihse, dholmes, jwaters

-------------

PR: https://git.openjdk.org/jdk/pull/20536

From fgao at openjdk.org  Tue Aug 13 08:37:58 2024
From: fgao at openjdk.org (Fei Gao)
Date: Tue, 13 Aug 2024 08:37:58 GMT
Subject: RFR: 8337536: AArch64: Enable BTI branch protection for runtime
 part [v2]
In-Reply-To: <3fLHxTC8pKjO7NWHedvizKrEJZG6CSpJlOFgf27m2hw=.301e8f28-030c-4109-96dc-f4efc2fa918c@github.com>
References: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
 <M50QnYb5zJhnQL3ytXnW7Rg7AhQu1aXqDWY250gcNSo=.2397b42c-f1f1-4b2d-a94f-b39c7277b651@github.com>
 <3fLHxTC8pKjO7NWHedvizKrEJZG6CSpJlOFgf27m2hw=.301e8f28-030c-4109-96dc-f4efc2fa918c@github.com>
Message-ID: <oVlACfcYd9PKlDxvo0KsoZQxwsw7S0fS59LvisEML7Y=.f28e2a58-787b-4d18-b262-4c3d1f161ea4@github.com>

On Fri, 9 Aug 2024 18:35:55 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Fei Gao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Clean up makefile
>>  - Merge branch 'master' into enable-bti-runtime
>>  - 8337536: AArch64: Enable BTI branch protection for runtime part
>>    
>>    This patch enables BTI branch protection for runtime part on
>>    Linux/aarch64 platform.
>>    
>>    Motivation
>>    
>>    1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default.
>>    User-level packages can gain additional hardening by compiling with the
>>    GCC/Clang flag `-mbranch-protection=flag`. See [1].
>>    
>>    2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as
>>    one VM configure flag, which would pass `-mbranch-protection=standard`
>>    compilation flags to all c/c++ files. Note that `standard` turns on both
>>    `pac-ret` and `bti` branch protections. For more details about code
>>    reuse attacks and hardware-assisted branch protections on AArch64, see
>>    [3].
>>    
>>    However, we checked the `.note.gnu.property` section of all the shared
>>    libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so
>>    didn't set these two target feature bits:
>>    
>>    ```
>>      GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>>      GNU_PROPERTY_AARCH64_FEATURE_1_PAC
>>    ```
>>    
>>    Note-1: BTI is an all or nothing property for a link unit [4]. That is,
>>    libjvm.so is not BTI-enabled.
>>    
>>    Note-2: PAC bit in `.note.gnu.property` section is used to protect
>>    `.got.plt` table. It's independent of whether the relocatable objects
>>    use PAC or not.
>>    
>>    Goal
>>    
>>    Hence, this patch aims to set PAC/BTI feature bits of the
>>    `.note.gnu.property` section for libjvm.so.
>>    
>>    Implementation
>>    
>>    Task-1: find out the problematic input objects
>>    
>>    From [5], "Static linkers processing ELF relocatable objects must set
>>    the feature bit in the output object or image only if all the input
>>    objects have the corresponding feature bit set." Hence we suspect that
>>    the root cause is probably that the PAC/BTI feature bits are not set
>>    only for some input objects of libjvm.so.
>>    
>>    In order to find out these inputs, we passed `--force-bti` linker flag
>>    [4] in my local test. This linker flag would warn if any input object
>>    does not have GNU_PROPERTY_AARCH64_FEATU...
>
> Build changes look good.

Thanks for your review @erikj79

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20491#issuecomment-2285678720

From shade at openjdk.org  Tue Aug 13 09:40:00 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 Aug 2024 09:40:00 GMT
Subject: RFR: 8338286: GHA: Demote x86_32 to hotspot build only
Message-ID: <wSc5DO7WQR7a-on8Kmr8nkAnyc3Ej_EUOSwQlwjPAYA=.5c1f7e04-6f39-4356-b80e-2d4253a77893@github.com>

As planned in [JDK-8338285](https://bugs.openjdk.org/browse/JDK-8338285), we are about to deprecate the port for removal. It makes little sense to continue testing the port, and thus block development and integration of new features.

Ahead of that JEP, we can separately decide to disable the x86-32 test jobs in GHA. This effectively demotes x86-32 to any other port that only builds Hotspot and relies on port maintainers to provide the runtime testing. This is deliberately separate change, so that Update Releases could decide to disable their x86-32 jobs as well.

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/20563/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20563&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338286
  Stats: 19 lines in 1 file changed: 1 ins; 11 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/20563.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20563/head:pull/20563

PR: https://git.openjdk.org/jdk/pull/20563

From ihse at openjdk.org  Tue Aug 13 10:34:48 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 13 Aug 2024 10:34:48 GMT
Subject: RFR: 8338286: GHA: Demote x86_32 to hotspot build only
In-Reply-To: <wSc5DO7WQR7a-on8Kmr8nkAnyc3Ej_EUOSwQlwjPAYA=.5c1f7e04-6f39-4356-b80e-2d4253a77893@github.com>
References: <wSc5DO7WQR7a-on8Kmr8nkAnyc3Ej_EUOSwQlwjPAYA=.5c1f7e04-6f39-4356-b80e-2d4253a77893@github.com>
Message-ID: <p_Hs_sjS_W5OfBCXJWuAe2IxPLZzUB5c6WhWxng_Uk8=.7edc44fc-35bc-444c-ba3f-cd25ba997d43@github.com>

On Tue, 13 Aug 2024 09:35:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> As planned in [JDK-8338285](https://bugs.openjdk.org/browse/JDK-8338285), we are about to deprecate the port for removal. It makes little sense to continue testing the port, and thus block development and integration of new features.
> 
> Ahead of that JEP, we can separately decide to disable the x86_32 test jobs in GHA. This effectively demotes x86_32 to any other port that only builds Hotspot and relies on port maintainers to provide the runtime testing. Building hotspot in both release and debug modes still gives us some level of 32-bit cleanliness checks.
> 
> This is deliberately separate change, so that Update Releases could decide to demote their x86_32 jobs as well.

This sounds reasonable. The implementation seems correct.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20563#pullrequestreview-2235177739

From gdams at openjdk.org  Wed Aug 14 08:38:57 2024
From: gdams at openjdk.org (George Adams)
Date: Wed, 14 Aug 2024 08:38:57 GMT
Subject: RFR: 8338286: GHA: Demote x86_32 to hotspot build only
In-Reply-To: <wSc5DO7WQR7a-on8Kmr8nkAnyc3Ej_EUOSwQlwjPAYA=.5c1f7e04-6f39-4356-b80e-2d4253a77893@github.com>
References: <wSc5DO7WQR7a-on8Kmr8nkAnyc3Ej_EUOSwQlwjPAYA=.5c1f7e04-6f39-4356-b80e-2d4253a77893@github.com>
Message-ID: <GjYUlO6QmhY_MmApEb8--s-_7x52YgMTFU7G3PL8eE0=.a27290db-3d25-4f86-8f1f-db27e472a056@github.com>

On Tue, 13 Aug 2024 09:35:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> As planned in [JDK-8338285](https://bugs.openjdk.org/browse/JDK-8338285), we are about to deprecate the port for removal. It makes little sense to continue testing the port, and thus block development and integration of new features.
> 
> Ahead of that JEP, we can separately decide to disable the x86_32 test jobs in GHA. This effectively demotes x86_32 to any other port that only builds Hotspot and relies on port maintainers to provide the runtime testing. Building hotspot in both release and debug modes still gives us some level of 32-bit cleanliness checks.
> 
> This is deliberately separate change, so that Update Releases could decide to demote their x86_32 jobs as well.

This is great to see! thanks for pushing it through @shipilev. I wonder if it's time for me to reboot my PR about testing Alpine Linux if we're dropping back on the actions usage here: https://github.com/openjdk/jdk/pull/7771

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20563#issuecomment-2288173261

From gdams at openjdk.org  Wed Aug 14 08:58:21 2024
From: gdams at openjdk.org (George Adams)
Date: Wed, 14 Aug 2024 08:58:21 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
Message-ID: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>

Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.

-------------

Commit messages:
 - fix test bundle
 - add make-target: 'hotspot'
 - 8282944: GHA: Add Alpine Linux x86_64 pre-integration check

Changes: https://git.openjdk.org/jdk/pull/20577/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8282944
  Stats: 140 lines in 3 files changed: 139 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20577.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20577/head:pull/20577

PR: https://git.openjdk.org/jdk/pull/20577

From gdams at openjdk.org  Wed Aug 14 09:08:12 2024
From: gdams at openjdk.org (George Adams)
Date: Wed, 14 Aug 2024 09:08:12 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v2]
In-Reply-To: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
Message-ID: <94xehYcmPsA6kepiiJ-BbYc2Ye4Oz25i09OBvUjaxPw=.1fa28e46-b97a-4822-abb5-e9a1929ab84b@github.com>

> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.

George Adams has updated the pull request incrementally with one additional commit since the last revision:

  force grep newline

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20577/files
  - new: https://git.openjdk.org/jdk/pull/20577/files/960a847e..db1ebae5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20577.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20577/head:pull/20577

PR: https://git.openjdk.org/jdk/pull/20577

From gdams at openjdk.org  Wed Aug 14 09:11:18 2024
From: gdams at openjdk.org (George Adams)
Date: Wed, 14 Aug 2024 09:11:18 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v3]
In-Reply-To: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
Message-ID: <dmdvtqAkgqgESXZPZ7DPmVZfV6Y323gjALlULTvHo-8=.0edf9b03-cc9b-45a3-9cf8-c886ef93a61d@github.com>

> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.

George Adams has updated the pull request incrementally with one additional commit since the last revision:

  fix alpine skip

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20577/files
  - new: https://git.openjdk.org/jdk/pull/20577/files/db1ebae5..cb8fd628

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20577.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20577/head:pull/20577

PR: https://git.openjdk.org/jdk/pull/20577

From gdams at openjdk.org  Wed Aug 14 09:16:30 2024
From: gdams at openjdk.org (George Adams)
Date: Wed, 14 Aug 2024 09:16:30 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v4]
In-Reply-To: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
Message-ID: <aZqOqje_7HdzW-RWK33TukrW9jpOZt3iLqAO2EbQ_3U=.d44cfac2-be21-44ae-b841-cbefc44b2ce4@github.com>

> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.

George Adams has updated the pull request incrementally with one additional commit since the last revision:

  fix order of tasks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20577/files
  - new: https://git.openjdk.org/jdk/pull/20577/files/cb8fd628..21855fae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=02-03

  Stats: 10 lines in 1 file changed: 5 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20577.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20577/head:pull/20577

PR: https://git.openjdk.org/jdk/pull/20577

From gdams at openjdk.org  Wed Aug 14 09:47:07 2024
From: gdams at openjdk.org (George Adams)
Date: Wed, 14 Aug 2024 09:47:07 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v5]
In-Reply-To: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
Message-ID: <Gm-4OcYV6iXawdkRpASQIjEJYf9XgEhMnQdDDE-NZSA=.0f2db00c-bc7a-4d42-8efd-7b424db95bc2@github.com>

> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.

George Adams has updated the pull request incrementally with one additional commit since the last revision:

  add wget

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20577/files
  - new: https://git.openjdk.org/jdk/pull/20577/files/21855fae..a146c907

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20577.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20577/head:pull/20577

PR: https://git.openjdk.org/jdk/pull/20577

From gdams at openjdk.org  Wed Aug 14 09:51:06 2024
From: gdams at openjdk.org (George Adams)
Date: Wed, 14 Aug 2024 09:51:06 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v6]
In-Reply-To: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
Message-ID: <WKaxKqyXv41kmkA6_zJvTLdRwjYO192n81jVVXK4NZ4=.43bae1f7-b3d4-4d07-8f7a-16c4c630ef07@github.com>

> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.

George Adams has updated the pull request incrementally with one additional commit since the last revision:

  add Java 17 for jtreg

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20577/files
  - new: https://git.openjdk.org/jdk/pull/20577/files/a146c907..04c655f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=04-05

  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20577.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20577/head:pull/20577

PR: https://git.openjdk.org/jdk/pull/20577

From gdams at openjdk.org  Wed Aug 14 09:59:07 2024
From: gdams at openjdk.org (George Adams)
Date: Wed, 14 Aug 2024 09:59:07 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v7]
In-Reply-To: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
Message-ID: <nk8vyKiYZucALRwFHCnyaMSsyXbM7krQRKlaPmNbI1Y=.8e59b806-61f2-4319-ab44-c923ac64c8de@github.com>

> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.

George Adams has updated the pull request incrementally with one additional commit since the last revision:

  skip gtest and jtreg

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20577/files
  - new: https://git.openjdk.org/jdk/pull/20577/files/04c655f2..180e1618

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=05-06

  Stats: 16 lines in 1 file changed: 0 ins; 16 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20577.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20577/head:pull/20577

PR: https://git.openjdk.org/jdk/pull/20577

From gdams at openjdk.org  Wed Aug 14 10:24:04 2024
From: gdams at openjdk.org (George Adams)
Date: Wed, 14 Aug 2024 10:24:04 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v3]
In-Reply-To: <5ZtvQGgDVuLQSReITu27yhuseUdBgGoJ3KIpKM2ngKY=.7b78497e-bf63-45a0-b148-238f5ea4a46f@github.com>
References: <FHqoKNfebvAySW7HnGS-ZcE_NkVzGQKiOnfrFzMYRzY=.cee77c2d-3b4d-42e6-9732-9b180df7c88e@github.com>
 <h_zU3LP9vQn9tzuZjZqm-OmyDCOOPiTKiNo8f3SeDuo=.42aafe95-8b72-4d06-845a-01e71dd3a09b@github.com>
 <5ZtvQGgDVuLQSReITu27yhuseUdBgGoJ3KIpKM2ngKY=.7b78497e-bf63-45a0-b148-238f5ea4a46f@github.com>
Message-ID: <mQFOVAdAoiONtt-1WDuFxswZ30sTtNBXeoCLfJD5CjQ=.287486d4-cb46-4ea3-a0da-448adf3fe2c8@github.com>

On Thu, 10 Mar 2022 22:51:44 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I was not very fond of adding x86 testing to GHA either. :-) I will not enter the fight if that should be removed. (But my personal opinion is that it makes a whole lot more sense to test on a 32-bit architecture than just a different libc.)
> 
> If you can change this to just test hotspot, it'd definitely be an improvement. Building hotspot requires just a fraction of the resources needed to build the entire JDK.

@magicus I've refactored this PR and switched it to testing hotspot only: https://github.com/openjdk/jdk/pull/20577

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7771#issuecomment-2288382745

From mbaesken at openjdk.org  Wed Aug 14 10:54:58 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 14 Aug 2024 10:54:58 GMT
Subject: RFR: 8338304: clang on Linux - check for lld presence after
 JDK-8333189
Message-ID: <sb6zFD-Qq_mAJhr1uFyedzkB8ln8FbBrPHEoHfrcT20=.806971e3-5ed0-49da-aac0-a42a545714d1@github.com>

After [JDK-8333189](https://bugs.openjdk.org/browse/JDK-8333189) I get now this build error (when using clang on Linux) :
`clang: error: invalid linker name in argument '-fuse-ld=lld'`
We  should better check for lld in the configure process if it is required with clang .

-------------

Commit messages:
 - JDK-8338304

Changes: https://git.openjdk.org/jdk/pull/20579/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20579&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338304
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20579.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20579/head:pull/20579

PR: https://git.openjdk.org/jdk/pull/20579

From erikj at openjdk.org  Wed Aug 14 12:44:48 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 14 Aug 2024 12:44:48 GMT
Subject: RFR: 8338304: clang on Linux - check for lld presence after
 JDK-8333189
In-Reply-To: <sb6zFD-Qq_mAJhr1uFyedzkB8ln8FbBrPHEoHfrcT20=.806971e3-5ed0-49da-aac0-a42a545714d1@github.com>
References: <sb6zFD-Qq_mAJhr1uFyedzkB8ln8FbBrPHEoHfrcT20=.806971e3-5ed0-49da-aac0-a42a545714d1@github.com>
Message-ID: <uWDKAFTQVGPZQLN4toK0cKb00wsDSB642O5XgXrhnnI=.0a9bf2b0-d58d-477d-8e33-1fbe31396736@github.com>

On Wed, 14 Aug 2024 10:49:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After [JDK-8333189](https://bugs.openjdk.org/browse/JDK-8333189) I get now this build error (when using clang on Linux) :
> `clang: error: invalid linker name in argument '-fuse-ld=lld'`
> We  should better check for lld in the configure process if it is required with clang .

make/autoconf/flags-ldflags.m4 line 76:

> 74:       BASIC_LDFLAGS="-fuse-ld=lld -Wl,--exclude-libs,ALL"
> 75:       # Linux/clang toolchain needs now lld on the system to work
> 76:       UTIL_REQUIRE_PROGS(LLD, lld)

I would suggest a more concise comment and moving it up a line as the parameter forcing the use of lld is right there.

Suggestion:

      # Clang needs the lld linker to work correctly
      BASIC_LDFLAGS="-fuse-ld=lld -Wl,--exclude-libs,ALL"
      UTIL_REQUIRE_PROGS(LLD, lld)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20579#discussion_r1716854701

From shade at openjdk.org  Wed Aug 14 12:59:52 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Aug 2024 12:59:52 GMT
Subject: RFR: 8338286: GHA: Demote x86_32 to hotspot build only
In-Reply-To: <wSc5DO7WQR7a-on8Kmr8nkAnyc3Ej_EUOSwQlwjPAYA=.5c1f7e04-6f39-4356-b80e-2d4253a77893@github.com>
References: <wSc5DO7WQR7a-on8Kmr8nkAnyc3Ej_EUOSwQlwjPAYA=.5c1f7e04-6f39-4356-b80e-2d4253a77893@github.com>
Message-ID: <AGjjx053QrroKlKNqyBezP55IYyKKuI7tCTf06bpLW4=.e4930632-bdad-4a2e-8e04-ba346668dfb1@github.com>

On Tue, 13 Aug 2024 09:35:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> As planned in [JDK-8338285](https://bugs.openjdk.org/browse/JDK-8338285), we are about to deprecate the port for removal. It makes little sense to continue testing the port, and thus block development and integration of new features.
> 
> Ahead of that JEP, we can separately decide to disable the x86_32 test jobs in GHA. This effectively demotes x86_32 to any other port that only builds Hotspot and relies on port maintainers to provide the runtime testing. Building hotspot in both release and debug modes still gives us some level of 32-bit cleanliness checks.
> 
> This is deliberately separate change, so that Update Releases could decide to demote their x86_32 jobs as well.

Thanks! Any other opinions on this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20563#issuecomment-2288670477

From mbaesken at openjdk.org  Wed Aug 14 13:01:09 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 14 Aug 2024 13:01:09 GMT
Subject: RFR: 8338304: clang on Linux - check for lld presence after
 JDK-8333189 [v2]
In-Reply-To: <sb6zFD-Qq_mAJhr1uFyedzkB8ln8FbBrPHEoHfrcT20=.806971e3-5ed0-49da-aac0-a42a545714d1@github.com>
References: <sb6zFD-Qq_mAJhr1uFyedzkB8ln8FbBrPHEoHfrcT20=.806971e3-5ed0-49da-aac0-a42a545714d1@github.com>
Message-ID: <QHRmZ_RVn9U1Ho-2MQyXPxZMQq5_KnlOlEV_eosvolE=.b7660909-a723-4243-8622-d91c4242a4f8@github.com>

> After [JDK-8333189](https://bugs.openjdk.org/browse/JDK-8333189) I get now this build error (when using clang on Linux) :
> `clang: error: invalid linker name in argument '-fuse-ld=lld'`
> We  should better check for lld in the configure process if it is required with clang .

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  adjust and move comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20579/files
  - new: https://git.openjdk.org/jdk/pull/20579/files/a653c5ea..5bdc49a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20579&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20579&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20579.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20579/head:pull/20579

PR: https://git.openjdk.org/jdk/pull/20579

From mbaesken at openjdk.org  Wed Aug 14 13:01:10 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 14 Aug 2024 13:01:10 GMT
Subject: RFR: 8338304: clang on Linux - check for lld presence after
 JDK-8333189
In-Reply-To: <sb6zFD-Qq_mAJhr1uFyedzkB8ln8FbBrPHEoHfrcT20=.806971e3-5ed0-49da-aac0-a42a545714d1@github.com>
References: <sb6zFD-Qq_mAJhr1uFyedzkB8ln8FbBrPHEoHfrcT20=.806971e3-5ed0-49da-aac0-a42a545714d1@github.com>
Message-ID: <5vrpw8wTRscn0F6Wbsg_-rugKLgKm-0Oh5GrFqbrlEo=.92a5d439-698b-4baa-90a5-f5903e53bdea@github.com>

On Wed, 14 Aug 2024 10:49:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After [JDK-8333189](https://bugs.openjdk.org/browse/JDK-8333189) I get now this build error (when using clang on Linux) :
> `clang: error: invalid linker name in argument '-fuse-ld=lld'`
> We  should better check for lld in the configure process if it is required with clang .

Thanks, I adjusted and moved the comment .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20579#issuecomment-2288673853

From erikj at openjdk.org  Wed Aug 14 13:07:48 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 14 Aug 2024 13:07:48 GMT
Subject: RFR: 8338304: clang on Linux - check for lld presence after
 JDK-8333189 [v2]
In-Reply-To: <QHRmZ_RVn9U1Ho-2MQyXPxZMQq5_KnlOlEV_eosvolE=.b7660909-a723-4243-8622-d91c4242a4f8@github.com>
References: <sb6zFD-Qq_mAJhr1uFyedzkB8ln8FbBrPHEoHfrcT20=.806971e3-5ed0-49da-aac0-a42a545714d1@github.com>
 <QHRmZ_RVn9U1Ho-2MQyXPxZMQq5_KnlOlEV_eosvolE=.b7660909-a723-4243-8622-d91c4242a4f8@github.com>
Message-ID: <u_WGdsMrT-4BB2vXkpJWzDkgGm4OZ1KbEoBkmEsl_oI=.341318c1-879d-4971-8543-c6f0cecd8a3d@github.com>

On Wed, 14 Aug 2024 13:01:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> After [JDK-8333189](https://bugs.openjdk.org/browse/JDK-8333189) I get now this build error (when using clang on Linux) :
>> `clang: error: invalid linker name in argument '-fuse-ld=lld'`
>> We  should better check for lld in the configure process if it is required with clang .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust and move comment

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20579#pullrequestreview-2238105863

From ihse at openjdk.org  Wed Aug 14 13:25:51 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 Aug 2024 13:25:51 GMT
Subject: RFR: 8338304: clang on Linux - check for lld presence after
 JDK-8333189 [v2]
In-Reply-To: <QHRmZ_RVn9U1Ho-2MQyXPxZMQq5_KnlOlEV_eosvolE=.b7660909-a723-4243-8622-d91c4242a4f8@github.com>
References: <sb6zFD-Qq_mAJhr1uFyedzkB8ln8FbBrPHEoHfrcT20=.806971e3-5ed0-49da-aac0-a42a545714d1@github.com>
 <QHRmZ_RVn9U1Ho-2MQyXPxZMQq5_KnlOlEV_eosvolE=.b7660909-a723-4243-8622-d91c4242a4f8@github.com>
Message-ID: <4K6hkwVG4rVf43XM3GDxtPOKEiTi5xE1ocf1wGvHr6Q=.55286315-ea95-4ff8-a636-62c2907daa54@github.com>

On Wed, 14 Aug 2024 13:01:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> After [JDK-8333189](https://bugs.openjdk.org/browse/JDK-8333189) I get now this build error (when using clang on Linux) :
>> `clang: error: invalid linker name in argument '-fuse-ld=lld'`
>> We  should better check for lld in the configure process if it is required with clang .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust and move comment

Looks good.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20579#pullrequestreview-2238157592

From zzambers at openjdk.org  Wed Aug 14 14:39:12 2024
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Wed, 14 Aug 2024 14:39:12 GMT
Subject: RFR: 8338402: GHA: some of bundles may not get removed
Message-ID: <pgI9A_Vy_NP1nRSlKpDvE4F1KT3AnZ2NJDgRXVq4JHA=.4851cbac-285a-4abb-ac4a-d4f49566660f@github.com>

Some of bundles may not get removed. This is follows [JDK-8336928](https://bugs.openjdk.org/browse/JDK-8336928). Problem does not always show up, so I have not seen it in my test runs, but since then I have seen some GHA runs affected by this.

**Details:**
Turns out, that call to list artifacts is by default limited to first 30 artifacts. GHA of openjdk currently produces 75 artifacts of which 10 are bundles (built jdk). Problem happens if build on some platform takes too long and enough test results (other platforms) got uploaded in meantime. Bundle can then be shifted down in list and not fall into list of first 30 artifacts. Problem can be fixed by increasing per_page limit ([API allows up to 100](https://docs.github.com/en/rest/actions/artifacts?apiVersion=2022-11-28#list-workflow-run-artifacts)).

**Testing:**
GHA: OK (see [artifacts in summary tab](https://github.com/zzambers/jdk/actions/runs/10373518734#artifacts))

-------------

Commit messages:
 - GHA: list artifacts with higher limit

Changes: https://git.openjdk.org/jdk/pull/20585/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20585&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338402
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20585.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20585/head:pull/20585

PR: https://git.openjdk.org/jdk/pull/20585

From ihse at openjdk.org  Wed Aug 14 14:48:47 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 Aug 2024 14:48:47 GMT
Subject: RFR: 8338402: GHA: some of bundles may not get removed
In-Reply-To: <pgI9A_Vy_NP1nRSlKpDvE4F1KT3AnZ2NJDgRXVq4JHA=.4851cbac-285a-4abb-ac4a-d4f49566660f@github.com>
References: <pgI9A_Vy_NP1nRSlKpDvE4F1KT3AnZ2NJDgRXVq4JHA=.4851cbac-285a-4abb-ac4a-d4f49566660f@github.com>
Message-ID: <_8uNffNKG8UxABO6OElVv3hyv8eDJ7suJVPqnt6KAYk=.3e8f485f-957c-42ee-b38a-2645c77d3562@github.com>

On Wed, 14 Aug 2024 14:30:28 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

> Some of bundles may not get removed. This is follows [JDK-8336928](https://bugs.openjdk.org/browse/JDK-8336928). Problem does not always show up, so I have not seen it in my test runs, but since then I have seen some GHA runs affected by this.
> 
> **Details:**
> Turns out, that call to list artifacts is by default limited to first 30 artifacts. GHA of openjdk currently produces 75 artifacts of which 10 are bundles (built jdk). Problem happens if build on some platform takes too long and enough test results (other platforms) got uploaded in meantime. Bundle can then be shifted down in list and not fall into list of first 30 artifacts. Problem can be fixed by increasing per_page limit ([API allows up to 100](https://docs.github.com/en/rest/actions/artifacts?apiVersion=2022-11-28#list-workflow-run-artifacts)).
> 
> **Testing:**
> GHA: OK (see [artifacts in summary tab](https://github.com/zzambers/jdk/actions/runs/10373518734#artifacts))

Looks good, but the 75 current artifacts looks dangerously close to the 100 limit. We'll have to try to keep in mind that if we continue increase the number of artifacts, we might have to replace this with a series of repeated calls.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20585#pullrequestreview-2238417823

From ihse at openjdk.org  Wed Aug 14 14:55:50 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 Aug 2024 14:55:50 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v7]
In-Reply-To: <nk8vyKiYZucALRwFHCnyaMSsyXbM7krQRKlaPmNbI1Y=.8e59b806-61f2-4319-ab44-c923ac64c8de@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
 <nk8vyKiYZucALRwFHCnyaMSsyXbM7krQRKlaPmNbI1Y=.8e59b806-61f2-4319-ab44-c923ac64c8de@github.com>
Message-ID: <3PfqIzosvCJN8YjhaA2Ziq8IynWurN3roYa2y4OM8i8=.a3521d70-cf2e-4fce-a2c9-8cf69bdb085e@github.com>

On Wed, 14 Aug 2024 09:59:07 GMT, George Adams <gdams at openjdk.org> wrote:

>> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.
>
> George Adams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   skip gtest and jtreg

The GHA code itself looks basically good. I was thinking a bit about the name, I wonder if "linux-alpine-x64" would not be better, to keep the os name in front (after all, Alpine is just a flavor of Linux, not a completely new OS). But maybe that's just me..?

The big question, as always with GHA, is if there is enough interest from the community to warrant adding this configuration to GHA. GHA testing is done on the developer's individual account's quota. It takes time and resources, and since we've introduced it we've basically only added platforms, never removing them.

Can you elaborate a bit what problems you expect to find with this addition, that is not currently detected by GHA, and why this is important enough to always run this in GHA? Basically, convince me that it is worth all the computing power and everyone's time to add this (what to me looks like a) special case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20577#issuecomment-2289037113

From zzambers at openjdk.org  Wed Aug 14 15:03:48 2024
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Wed, 14 Aug 2024 15:03:48 GMT
Subject: RFR: 8338402: GHA: some of bundles may not get removed
In-Reply-To: <_8uNffNKG8UxABO6OElVv3hyv8eDJ7suJVPqnt6KAYk=.3e8f485f-957c-42ee-b38a-2645c77d3562@github.com>
References: <pgI9A_Vy_NP1nRSlKpDvE4F1KT3AnZ2NJDgRXVq4JHA=.4851cbac-285a-4abb-ac4a-d4f49566660f@github.com>
 <_8uNffNKG8UxABO6OElVv3hyv8eDJ7suJVPqnt6KAYk=.3e8f485f-957c-42ee-b38a-2645c77d3562@github.com>
Message-ID: <6oNFK_HUGHtufiXZy0Es02BR5tAFC3h3JeKzJz0lQK0=.525d8da2-7beb-47f8-8da5-a2a3ccca68ad@github.com>

On Wed, 14 Aug 2024 14:46:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some of bundles may not get removed. This is follows [JDK-8336928](https://bugs.openjdk.org/browse/JDK-8336928). Problem does not always show up, so I have not seen it in my test runs, but since then I have seen some GHA runs affected by this.
>> 
>> **Details:**
>> Turns out, that call to list artifacts is by default limited to first 30 artifacts. GHA of openjdk currently produces 75 artifacts of which 10 are bundles (built jdk). Problem happens if build on some platform takes too long and enough test results (other platforms) got uploaded in meantime. Bundle can then be shifted down in list and not fall into list of first 30 artifacts. Problem can be fixed by increasing per_page limit ([API allows up to 100](https://docs.github.com/en/rest/actions/artifacts?apiVersion=2022-11-28#list-workflow-run-artifacts)).
>> 
>> **Testing:**
>> GHA: OK (see [artifacts in summary tab](https://github.com/zzambers/jdk/actions/runs/10373518734#artifacts))
>
> Looks good, but the 75 current artifacts looks dangerously close to the 100 limit. We'll have to try to keep in mind that if we continue increase the number of artifacts, we might have to replace this with a series of repeated calls.

@magicus thanks

Fortunately bundles usually tend to be at beginning of the list (it was usually just one long running build causing problems). So if number of artifacts would be slightly over the limit, it should be unlikely to cause problems, though possible.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20585#issuecomment-2289054822

From duke at openjdk.org  Wed Aug 14 15:03:49 2024
From: duke at openjdk.org (duke)
Date: Wed, 14 Aug 2024 15:03:49 GMT
Subject: RFR: 8338402: GHA: some of bundles may not get removed
In-Reply-To: <pgI9A_Vy_NP1nRSlKpDvE4F1KT3AnZ2NJDgRXVq4JHA=.4851cbac-285a-4abb-ac4a-d4f49566660f@github.com>
References: <pgI9A_Vy_NP1nRSlKpDvE4F1KT3AnZ2NJDgRXVq4JHA=.4851cbac-285a-4abb-ac4a-d4f49566660f@github.com>
Message-ID: <qt040BLCnM3hKA27KybMbbJHaEif1AWUft7ZGRTYIQE=.4be3e5ac-3467-4cc6-8222-98b931e5f7a7@github.com>

On Wed, 14 Aug 2024 14:30:28 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

> Some of bundles may not get removed. This is follows [JDK-8336928](https://bugs.openjdk.org/browse/JDK-8336928). Problem does not always show up, so I have not seen it in my test runs, but since then I have seen some GHA runs affected by this.
> 
> **Details:**
> Turns out, that call to list artifacts is by default limited to first 30 artifacts. GHA of openjdk currently produces 75 artifacts of which 10 are bundles (built jdk). Problem happens if build on some platform takes too long and enough test results (other platforms) got uploaded in meantime. Bundle can then be shifted down in list and not fall into list of first 30 artifacts. Problem can be fixed by increasing per_page limit ([API allows up to 100](https://docs.github.com/en/rest/actions/artifacts?apiVersion=2022-11-28#list-workflow-run-artifacts)).
> 
> **Testing:**
> GHA: OK (see [artifacts in summary tab](https://github.com/zzambers/jdk/actions/runs/10373518734#artifacts))

@zzambers 
Your change (at version 75f54ead41842b3f88c4df4505609952791e618d) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20585#issuecomment-2289056456

From shade at openjdk.org  Wed Aug 14 15:22:53 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Aug 2024 15:22:53 GMT
Subject: RFR: 8338402: GHA: some of bundles may not get removed
In-Reply-To: <pgI9A_Vy_NP1nRSlKpDvE4F1KT3AnZ2NJDgRXVq4JHA=.4851cbac-285a-4abb-ac4a-d4f49566660f@github.com>
References: <pgI9A_Vy_NP1nRSlKpDvE4F1KT3AnZ2NJDgRXVq4JHA=.4851cbac-285a-4abb-ac4a-d4f49566660f@github.com>
Message-ID: <dK8St6taMczcdPypiUJxJgi6gBDoq1S2XnCLjLohSdY=.23fdcbf4-39f2-465e-83e8-fe58848f96c8@github.com>

On Wed, 14 Aug 2024 14:30:28 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

> Some of bundles may not get removed. This is follows [JDK-8336928](https://bugs.openjdk.org/browse/JDK-8336928). Problem does not always show up, so I have not seen it in my test runs, but since then I have seen some GHA runs affected by this.
> 
> **Details:**
> Turns out, that call to list artifacts is by default limited to first 30 artifacts. GHA of openjdk currently produces 75 artifacts of which 10 are bundles (built jdk). Problem happens if build on some platform takes too long and enough test results (other platforms) got uploaded in meantime. Bundle can then be shifted down in list and not fall into list of first 30 artifacts. Problem can be fixed by increasing per_page limit ([API allows up to 100](https://docs.github.com/en/rest/actions/artifacts?apiVersion=2022-11-28#list-workflow-run-artifacts)).
> 
> **Testing:**
> GHA: OK (see [artifacts in summary tab](https://github.com/zzambers/jdk/actions/runs/10373518734#artifacts))

Marked as reviewed by shade (Reviewer).

All right, let's do this :)

-------------

PR Review: https://git.openjdk.org/jdk/pull/20585#pullrequestreview-2238505759
PR Comment: https://git.openjdk.org/jdk/pull/20585#issuecomment-2289097677

From zzambers at openjdk.org  Wed Aug 14 15:22:53 2024
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Wed, 14 Aug 2024 15:22:53 GMT
Subject: Integrated: 8338402: GHA: some of bundles may not get removed
In-Reply-To: <pgI9A_Vy_NP1nRSlKpDvE4F1KT3AnZ2NJDgRXVq4JHA=.4851cbac-285a-4abb-ac4a-d4f49566660f@github.com>
References: <pgI9A_Vy_NP1nRSlKpDvE4F1KT3AnZ2NJDgRXVq4JHA=.4851cbac-285a-4abb-ac4a-d4f49566660f@github.com>
Message-ID: <nfMFSnKDWlnu9_jSMAu0w3u7AviJ7NfhZtK4Udu1VMg=.ccec983c-f8ca-43c8-a940-ea0c85f0b774@github.com>

On Wed, 14 Aug 2024 14:30:28 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

> Some of bundles may not get removed. This is follows [JDK-8336928](https://bugs.openjdk.org/browse/JDK-8336928). Problem does not always show up, so I have not seen it in my test runs, but since then I have seen some GHA runs affected by this.
> 
> **Details:**
> Turns out, that call to list artifacts is by default limited to first 30 artifacts. GHA of openjdk currently produces 75 artifacts of which 10 are bundles (built jdk). Problem happens if build on some platform takes too long and enough test results (other platforms) got uploaded in meantime. Bundle can then be shifted down in list and not fall into list of first 30 artifacts. Problem can be fixed by increasing per_page limit ([API allows up to 100](https://docs.github.com/en/rest/actions/artifacts?apiVersion=2022-11-28#list-workflow-run-artifacts)).
> 
> **Testing:**
> GHA: OK (see [artifacts in summary tab](https://github.com/zzambers/jdk/actions/runs/10373518734#artifacts))

This pull request has now been integrated.

Changeset: d8e4d3f2
Author:    Zdenek Zambersky <zzambers at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d8e4d3f2d6c187f2487acd390a4e5fa2a99010ea
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8338402: GHA: some of bundles may not get removed

Reviewed-by: ihse, shade

-------------

PR: https://git.openjdk.org/jdk/pull/20585

From duke at openjdk.org  Wed Aug 14 18:00:06 2024
From: duke at openjdk.org (duke)
Date: Wed, 14 Aug 2024 18:00:06 GMT
Subject: Withdrawn: 8314488: Compile the JDK as C++17
In-Reply-To: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
Message-ID: <S3xFC1DtGWldM7g-RHHY8i1irbLyJWTbIHqLbd2IixI=.c150635e-87fa-433b-a572-4d1a07151f5a@github.com>

On Mon, 24 Jul 2023 01:41:16 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Compile the JDK as C++17, enabling the use of all C++17 language features

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14988

From eliu at openjdk.org  Thu Aug 15 02:28:49 2024
From: eliu at openjdk.org (Eric Liu)
Date: Thu, 15 Aug 2024 02:28:49 GMT
Subject: RFR: 8337536: AArch64: Enable BTI branch protection for runtime
 part [v2]
In-Reply-To: <M50QnYb5zJhnQL3ytXnW7Rg7AhQu1aXqDWY250gcNSo=.2397b42c-f1f1-4b2d-a94f-b39c7277b651@github.com>
References: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
 <M50QnYb5zJhnQL3ytXnW7Rg7AhQu1aXqDWY250gcNSo=.2397b42c-f1f1-4b2d-a94f-b39c7277b651@github.com>
Message-ID: <vUplKbuUzSIIRLMkMt3bN3TbTwGUJhbNd6X9VSkrYoA=.e745b7de-1a2a-47ef-a7b3-784433e1fc63@github.com>

On Fri, 9 Aug 2024 13:37:54 GMT, Fei Gao <fgao at openjdk.org> wrote:

>> This patch enables BTI branch protection for runtime part on Linux/aarch64 platform.
>> 
>> Motivation
>> 
>> 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. User-level packages can gain additional hardening by compiling with the GCC/Clang flag `-mbranch-protection=flag`. See [1].
>> 
>> 2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as one VM configure flag, which would pass `-mbranch-protection=standard` compilation flags to all c/c++ files. Note that `standard` turns on both `pac-ret` and `bti` branch protections. For more details about code reuse attacks and hardware-assisted branch protections on AArch64, see [3].
>> 
>> However, we checked the `.note.gnu.property` section of all the shared libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so didn't set these two target feature bits:
>> 
>> 
>>   GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>>   GNU_PROPERTY_AARCH64_FEATURE_1_PAC
>> 
>> 
>> Note-1: BTI is an all or nothing property for a link unit [4]. That is, libjvm.so is not BTI-enabled.
>> 
>> Note-2: PAC bit in `.note.gnu.property` section is used to protect `.got.plt` table. It's independent of whether the relocatable objects use PAC or not.
>> 
>> Goal
>> 
>> Hence, this patch aims to set PAC/BTI feature bits of the `.note.gnu.property` section for libjvm.so.
>> 
>> Implementation
>> 
>> Task-1: find out the problematic input objects
>> 
>> From [5], "Static linkers processing ELF relocatable objects must set the feature bit in the output object or image only if all the input objects have the corresponding feature bit set." Hence we suspect that the root cause is probably that the PAC/BTI feature bits are not set only for some input objects of libjvm.so.
>> 
>> In order to find out these inputs, we passed `--force-bti` linker flag [4] in my local test. This linker flag would warn if any input object does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following list:
>> 
>> 
>>   src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
>>   src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S
>>   src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S
>>   src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S
>> 
>> 
>> Task-2: add `.note.gnu.property` section for these assembly files
>> 
>> As mentioned in Motivation-2 part, `-mbranch-protection=standard` is passed to compile c/c++ files but these assembly files are missed.
>> 
>> In this patch, we also pass `-mbranch-protection=standard` flag to assembler (See the update i...
>
> Fei Gao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Clean up makefile
>  - Merge branch 'master' into enable-bti-runtime
>  - 8337536: AArch64: Enable BTI branch protection for runtime part
>    
>    This patch enables BTI branch protection for runtime part on
>    Linux/aarch64 platform.
>    
>    Motivation
>    
>    1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default.
>    User-level packages can gain additional hardening by compiling with the
>    GCC/Clang flag `-mbranch-protection=flag`. See [1].
>    
>    2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as
>    one VM configure flag, which would pass `-mbranch-protection=standard`
>    compilation flags to all c/c++ files. Note that `standard` turns on both
>    `pac-ret` and `bti` branch protections. For more details about code
>    reuse attacks and hardware-assisted branch protections on AArch64, see
>    [3].
>    
>    However, we checked the `.note.gnu.property` section of all the shared
>    libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so
>    didn't set these two target feature bits:
>    
>    ```
>      GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>      GNU_PROPERTY_AARCH64_FEATURE_1_PAC
>    ```
>    
>    Note-1: BTI is an all or nothing property for a link unit [4]. That is,
>    libjvm.so is not BTI-enabled.
>    
>    Note-2: PAC bit in `.note.gnu.property` section is used to protect
>    `.got.plt` table. It's independent of whether the relocatable objects
>    use PAC or not.
>    
>    Goal
>    
>    Hence, this patch aims to set PAC/BTI feature bits of the
>    `.note.gnu.property` section for libjvm.so.
>    
>    Implementation
>    
>    Task-1: find out the problematic input objects
>    
>    From [5], "Static linkers processing ELF relocatable objects must set
>    the feature bit in the output object or image only if all the input
>    objects have the corresponding feature bit set." Hence we suspect that
>    the root cause is probably that the PAC/BTI feature bits are not set
>    only for some input objects of libjvm.so.
>    
>    In order to find out these inputs, we passed `--force-bti` linker flag
>    [4] in my local test. This linker flag would warn if any input object
>    does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following
>    list:
>    
>    ```
>      src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
> ...

Marked as reviewed by eliu (Committer).

src/hotspot/cpu/aarch64/copy_aarch64.hpp line 67:

> 65: "       .align  5;\n"                                                   \
> 66: "0:"                                                                    \
> 67: "       hint    #0x24; // bti j\n"                                               \

LGTM. Only a few indent issues.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20491#pullrequestreview-2239522676
PR Review Comment: https://git.openjdk.org/jdk/pull/20491#discussion_r1717797701

From mbaesken at openjdk.org  Thu Aug 15 07:41:52 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 15 Aug 2024 07:41:52 GMT
Subject: RFR: 8338304: clang on Linux - check for lld presence after
 JDK-8333189 [v2]
In-Reply-To: <QHRmZ_RVn9U1Ho-2MQyXPxZMQq5_KnlOlEV_eosvolE=.b7660909-a723-4243-8622-d91c4242a4f8@github.com>
References: <sb6zFD-Qq_mAJhr1uFyedzkB8ln8FbBrPHEoHfrcT20=.806971e3-5ed0-49da-aac0-a42a545714d1@github.com>
 <QHRmZ_RVn9U1Ho-2MQyXPxZMQq5_KnlOlEV_eosvolE=.b7660909-a723-4243-8622-d91c4242a4f8@github.com>
Message-ID: <IZcNWUqniw3BvqQOztf7TB_2eXmhx5Wbdk1D6PxlAlg=.4a5929b4-7ffc-43dc-be49-00dc9a428f84@github.com>

On Wed, 14 Aug 2024 13:01:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> After [JDK-8333189](https://bugs.openjdk.org/browse/JDK-8333189) I get now this build error (when using clang on Linux) :
>> `clang: error: invalid linker name in argument '-fuse-ld=lld'`
>> We  should better check for lld in the configure process if it is required with clang .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust and move comment

Hi Erik and Magnus, thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20579#issuecomment-2290823698

From mbaesken at openjdk.org  Thu Aug 15 07:41:52 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 15 Aug 2024 07:41:52 GMT
Subject: Integrated: 8338304: clang on Linux - check for lld presence after
 JDK-8333189
In-Reply-To: <sb6zFD-Qq_mAJhr1uFyedzkB8ln8FbBrPHEoHfrcT20=.806971e3-5ed0-49da-aac0-a42a545714d1@github.com>
References: <sb6zFD-Qq_mAJhr1uFyedzkB8ln8FbBrPHEoHfrcT20=.806971e3-5ed0-49da-aac0-a42a545714d1@github.com>
Message-ID: <DRG1rhWrVJCI22BnEdxcbaBUI_DzFIPjdjTRJ-zZtlE=.9771433e-c94b-4c83-8418-3c907d711640@github.com>

On Wed, 14 Aug 2024 10:49:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After [JDK-8333189](https://bugs.openjdk.org/browse/JDK-8333189) I get now this build error (when using clang on Linux) :
> `clang: error: invalid linker name in argument '-fuse-ld=lld'`
> We  should better check for lld in the configure process if it is required with clang .

This pull request has now been integrated.

Changeset: 4c344335
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4c344335fe0abc04308f4bfc62c6b3afc110240c
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8338304: clang on Linux - check for lld presence after JDK-8333189

Reviewed-by: erikj, ihse

-------------

PR: https://git.openjdk.org/jdk/pull/20579

From shade at openjdk.org  Thu Aug 15 08:52:58 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Aug 2024 08:52:58 GMT
Subject: Integrated: 8338286: GHA: Demote x86_32 to hotspot build only
In-Reply-To: <wSc5DO7WQR7a-on8Kmr8nkAnyc3Ej_EUOSwQlwjPAYA=.5c1f7e04-6f39-4356-b80e-2d4253a77893@github.com>
References: <wSc5DO7WQR7a-on8Kmr8nkAnyc3Ej_EUOSwQlwjPAYA=.5c1f7e04-6f39-4356-b80e-2d4253a77893@github.com>
Message-ID: <lmrNBjMLeCxxJV25z-7NUdhTzA5NviuGVzRIIMRB9T0=.8801ae53-4c63-4968-9c92-39f80fb3a889@github.com>

On Tue, 13 Aug 2024 09:35:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> As planned in [JDK-8338285](https://bugs.openjdk.org/browse/JDK-8338285), we are about to deprecate the port for removal. It makes little sense to continue testing the port, and thus block development and integration of new features.
> 
> Ahead of that JEP, we can separately decide to disable the x86_32 test jobs in GHA. This effectively demotes x86_32 to any other port that only builds Hotspot and relies on port maintainers to provide the runtime testing. Building hotspot in both release and debug modes still gives us some level of 32-bit cleanliness checks.
> 
> This is deliberately separate change, so that Update Releases could decide to demote their x86_32 jobs as well.

This pull request has now been integrated.

Changeset: da7311bb
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da7311bbe37c2b9632b117d52a77c659047820b7
Stats:     19 lines in 1 file changed: 1 ins; 11 del; 7 mod

8338286: GHA: Demote x86_32 to hotspot build only

Reviewed-by: ihse

-------------

PR: https://git.openjdk.org/jdk/pull/20563

From shade at openjdk.org  Thu Aug 15 08:52:57 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Aug 2024 08:52:57 GMT
Subject: RFR: 8338286: GHA: Demote x86_32 to hotspot build only
In-Reply-To: <wSc5DO7WQR7a-on8Kmr8nkAnyc3Ej_EUOSwQlwjPAYA=.5c1f7e04-6f39-4356-b80e-2d4253a77893@github.com>
References: <wSc5DO7WQR7a-on8Kmr8nkAnyc3Ej_EUOSwQlwjPAYA=.5c1f7e04-6f39-4356-b80e-2d4253a77893@github.com>
Message-ID: <27mLYAFjwwdl6vA0rb3M8pSnd6CCD_vSyi1pnQIFpg8=.779ddea8-1877-4532-9992-5edb50a62392@github.com>

On Tue, 13 Aug 2024 09:35:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> As planned in [JDK-8338285](https://bugs.openjdk.org/browse/JDK-8338285), we are about to deprecate the port for removal. It makes little sense to continue testing the port, and thus block development and integration of new features.
> 
> Ahead of that JEP, we can separately decide to disable the x86_32 test jobs in GHA. This effectively demotes x86_32 to any other port that only builds Hotspot and relies on port maintainers to provide the runtime testing. Building hotspot in both release and debug modes still gives us some level of 32-bit cleanliness checks.
> 
> This is deliberately separate change, so that Update Releases could decide to demote their x86_32 jobs as well.

By the powers vested in me as x86_32 maintainer I declare this PR integrateable. :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20563#issuecomment-2290911019

From jwaters at openjdk.org  Thu Aug 15 09:02:56 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 15 Aug 2024 09:02:56 GMT
Subject: RFR: 8338286: GHA: Demote x86_32 to hotspot build only
In-Reply-To: <wSc5DO7WQR7a-on8Kmr8nkAnyc3Ej_EUOSwQlwjPAYA=.5c1f7e04-6f39-4356-b80e-2d4253a77893@github.com>
References: <wSc5DO7WQR7a-on8Kmr8nkAnyc3Ej_EUOSwQlwjPAYA=.5c1f7e04-6f39-4356-b80e-2d4253a77893@github.com>
Message-ID: <M617qnSd0AOVvVRsDOQClmWvSMFl2yZSRXDImbDXWgg=.59d6de0f-5532-4a3e-a37f-4a3e666358e8@github.com>

On Tue, 13 Aug 2024 09:35:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> As planned in [JDK-8338285](https://bugs.openjdk.org/browse/JDK-8338285), we are about to deprecate the port for removal. It makes little sense to continue testing the port, and thus block development and integration of new features.
> 
> Ahead of that JEP, we can separately decide to disable the x86_32 test jobs in GHA. This effectively demotes x86_32 to any other port that only builds Hotspot and relies on port maintainers to provide the runtime testing. Building hotspot in both release and debug modes still gives us some level of 32-bit cleanliness checks.
> 
> This is deliberately separate change, so that Update Releases could decide to demote their x86_32 jobs as well.

Sad to see a port start to go, but it had to be done, You were good, x86_32 port :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20563#issuecomment-2290927410

From gdams at openjdk.org  Thu Aug 15 10:26:17 2024
From: gdams at openjdk.org (George Adams)
Date: Thu, 15 Aug 2024 10:26:17 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v8]
In-Reply-To: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
Message-ID: <OcEfGY_eIL84XBI90JgGr6ujZOZAhTSPnWMBYsl6yLI=.f713a987-a182-4071-9969-a2a4a5cc2355@github.com>

> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.

George Adams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into alpine
 - skip gtest and jtreg
 - add Java 17 for jtreg
 - add wget
 - fix order of tasks
 - fix alpine skip
 - force grep newline
 - fix test bundle
 - add make-target: 'hotspot'
 - 8282944: GHA: Add Alpine Linux x86_64 pre-integration check

-------------

Changes: https://git.openjdk.org/jdk/pull/20577/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=07
  Stats: 132 lines in 4 files changed: 130 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20577.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20577/head:pull/20577

PR: https://git.openjdk.org/jdk/pull/20577

From gdams at openjdk.org  Thu Aug 15 10:29:47 2024
From: gdams at openjdk.org (George Adams)
Date: Thu, 15 Aug 2024 10:29:47 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v7]
In-Reply-To: <3PfqIzosvCJN8YjhaA2Ziq8IynWurN3roYa2y4OM8i8=.a3521d70-cf2e-4fce-a2c9-8cf69bdb085e@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
 <nk8vyKiYZucALRwFHCnyaMSsyXbM7krQRKlaPmNbI1Y=.8e59b806-61f2-4319-ab44-c923ac64c8de@github.com>
 <3PfqIzosvCJN8YjhaA2Ziq8IynWurN3roYa2y4OM8i8=.a3521d70-cf2e-4fce-a2c9-8cf69bdb085e@github.com>
Message-ID: <UH9PnDbjQVvimhNC-eN9gKyH224QnkUtRfW6hAkLayE=.43583503-30dd-49cc-b1c5-ef75096764a5@github.com>

On Wed, 14 Aug 2024 14:53:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The big question, as always with GHA, is if there is enough interest from the community to warrant adding this configuration to GHA. GHA testing is done on the developer's individual account's quota. It takes time and resources, and since we've introduced it we've basically only added platforms, never removing them.
> 
> Can you elaborate a bit what problems you expect to find with this addition, that is not currently detected by GHA, and why this is important enough to always run this in GHA? Basically, convince me that it is worth all the computing power and everyone's time to add this (what to me looks like a) special case.

Including Alpine Linux in the GHA pipeline is valuable because it uses the musl C library, which is different from the glibc found in most other Linux distributions. This difference can expose compatibility issues that might not be caught elsewhere. Given Alpine's popularity in containerised environments due to its small footprint and security features, ensuring that OpenJDK works well on Alpine helps meet the needs of developers who rely on these setups. By testing on Alpine, we can catch potential issues early and make OpenJDK more reliable in a variety of environments, especially in cloud-native applications where Alpine is often used.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20577#issuecomment-2291035727

From ihse at openjdk.org  Thu Aug 15 14:55:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Aug 2024 14:55:52 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v8]
In-Reply-To: <OcEfGY_eIL84XBI90JgGr6ujZOZAhTSPnWMBYsl6yLI=.f713a987-a182-4071-9969-a2a4a5cc2355@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
 <OcEfGY_eIL84XBI90JgGr6ujZOZAhTSPnWMBYsl6yLI=.f713a987-a182-4071-9969-a2a4a5cc2355@github.com>
Message-ID: <eWjjNq7si6a9QqmqePm69xCj9vig-CPhQUUJq3WXSJ0=.05fe0962-11a8-49a6-b4b3-ffcf6c2897d9@github.com>

On Thu, 15 Aug 2024 10:26:17 GMT, George Adams <gdams at openjdk.org> wrote:

>> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.
>
> George Adams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into alpine
>  - skip gtest and jtreg
>  - add Java 17 for jtreg
>  - add wget
>  - fix order of tasks
>  - fix alpine skip
>  - force grep newline
>  - fix test bundle
>  - add make-target: 'hotspot'
>  - 8282944: GHA: Add Alpine Linux x86_64 pre-integration check

Thanks. From my point of view, the code looks okay. However, I'd like to hear someone else weigh in on the question if this should be enabled or not.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20577#issuecomment-2291447099

From fgao at openjdk.org  Thu Aug 15 15:32:28 2024
From: fgao at openjdk.org (Fei Gao)
Date: Thu, 15 Aug 2024 15:32:28 GMT
Subject: RFR: 8337536: AArch64: Enable BTI branch protection for runtime
 part [v3]
In-Reply-To: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
References: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
Message-ID: <7JRzzIvH26CZPYCX76eWBbQSYUhMDnOqRufDtWaIXq8=.d3270022-4933-4fa7-828a-f57dbc5b8a46@github.com>

> This patch enables BTI branch protection for runtime part on Linux/aarch64 platform.
> 
> Motivation
> 
> 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. User-level packages can gain additional hardening by compiling with the GCC/Clang flag `-mbranch-protection=flag`. See [1].
> 
> 2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as one VM configure flag, which would pass `-mbranch-protection=standard` compilation flags to all c/c++ files. Note that `standard` turns on both `pac-ret` and `bti` branch protections. For more details about code reuse attacks and hardware-assisted branch protections on AArch64, see [3].
> 
> However, we checked the `.note.gnu.property` section of all the shared libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so didn't set these two target feature bits:
> 
> 
>   GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>   GNU_PROPERTY_AARCH64_FEATURE_1_PAC
> 
> 
> Note-1: BTI is an all or nothing property for a link unit [4]. That is, libjvm.so is not BTI-enabled.
> 
> Note-2: PAC bit in `.note.gnu.property` section is used to protect `.got.plt` table. It's independent of whether the relocatable objects use PAC or not.
> 
> Goal
> 
> Hence, this patch aims to set PAC/BTI feature bits of the `.note.gnu.property` section for libjvm.so.
> 
> Implementation
> 
> Task-1: find out the problematic input objects
> 
> From [5], "Static linkers processing ELF relocatable objects must set the feature bit in the output object or image only if all the input objects have the corresponding feature bit set." Hence we suspect that the root cause is probably that the PAC/BTI feature bits are not set only for some input objects of libjvm.so.
> 
> In order to find out these inputs, we passed `--force-bti` linker flag [4] in my local test. This linker flag would warn if any input object does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following list:
> 
> 
>   src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
>   src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S
>   src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S
>   src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S
> 
> 
> Task-2: add `.note.gnu.property` section for these assembly files
> 
> As mentioned in Motivation-2 part, `-mbranch-protection=standard` is passed to compile c/c++ files but these assembly files are missed.
> 
> In this patch, we also pass `-mbranch-protection=standard` flag to assembler (See the update in flags-cflags.m4 and flags-other.m4), and add `.note.gnu.property` section at the end...

Fei Gao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Fix indentation
 - Merge branch 'master' into enable-bti-runtime
 - Clean up makefile
 - Merge branch 'master' into enable-bti-runtime
 - 8337536: AArch64: Enable BTI branch protection for runtime part
   
   This patch enables BTI branch protection for runtime part on
   Linux/aarch64 platform.
   
   Motivation
   
   1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default.
   User-level packages can gain additional hardening by compiling with the
   GCC/Clang flag `-mbranch-protection=flag`. See [1].
   
   2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as
   one VM configure flag, which would pass `-mbranch-protection=standard`
   compilation flags to all c/c++ files. Note that `standard` turns on both
   `pac-ret` and `bti` branch protections. For more details about code
   reuse attacks and hardware-assisted branch protections on AArch64, see
   [3].
   
   However, we checked the `.note.gnu.property` section of all the shared
   libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so
   didn't set these two target feature bits:
   
   ```
     GNU_PROPERTY_AARCH64_FEATURE_1_BTI
     GNU_PROPERTY_AARCH64_FEATURE_1_PAC
   ```
   
   Note-1: BTI is an all or nothing property for a link unit [4]. That is,
   libjvm.so is not BTI-enabled.
   
   Note-2: PAC bit in `.note.gnu.property` section is used to protect
   `.got.plt` table. It's independent of whether the relocatable objects
   use PAC or not.
   
   Goal
   
   Hence, this patch aims to set PAC/BTI feature bits of the
   `.note.gnu.property` section for libjvm.so.
   
   Implementation
   
   Task-1: find out the problematic input objects
   
   From [5], "Static linkers processing ELF relocatable objects must set
   the feature bit in the output object or image only if all the input
   objects have the corresponding feature bit set." Hence we suspect that
   the root cause is probably that the PAC/BTI feature bits are not set
   only for some input objects of libjvm.so.
   
   In order to find out these inputs, we passed `--force-bti` linker flag
   [4] in my local test. This linker flag would warn if any input object
   does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following
   list:
   
   ```
     src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
     src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S
     src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S
     src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S
   ```
   
   Task-2: add `.note.gnu.property` section for these assembly files
   
   As mentioned in Motivation-2 part, `-mbranch-protection=standard` is
   passed to compile c/c++ files but these assembly files are missed.
   
   In this patch, we also pass `-mbranch-protection=standard` flag to
   assembler (See the update in flags-cflags.m4 and flags-other.m4), and
   add `.note.gnu.property` section at the end of these assembler files.
   
   With this change, we can see PAC/BTI feature bits in the final
   libjvm.so.
   
   Task-3: add BTI landing pads for hand written assembly
   
   In the local test on Fedora 40 with PAC/BTI-capable hardware, we got
   `SIGILL` error, which is one typical BTI error (branch target exception).
   The root cause is that we should add the missing BTI landing pads for
   hand written assembly in hotspot.
   
   File-1 copy_aarch64.hpp: It's a switch-case statement and we add `bti j`
   for these indirect jumps.
   
   File-2 atomic_linux_aarch64.S: We add landings pads `bti c` at the
   function entries.
   
   File-3 copy_linux_aarch64.S: There is no need to add `bti c` at the
   function entries since they are called via `bl`. And we should handle
   the indirect jumps.
   
   File-4 safefetch_linux_aarch64.S: Similar to file-3, there is no need to
   handle these function entries.
   
   File-5 threadLS_linux_aarch64.S: No need to handle the function entry
   because `paciasp` can act as the landing pad.
   
   Evaluation
   
   1. jtreg test
   
   We ran tier 1-3 jtreg tests on Fedora 40 + GCC 14 + the following AArch64
   hardware and all tests passed.
   
   ```
     1. w/o PAC and w/o BTI
     2. w/ PAC and w/o BTI
     3. w/ PAC and w/ BTI
   ```
   
   We also ran the jtreg tests on Fedora 40 + Clang 18 + hardware w/ PAC
   and w/ BTI. The test passed too.
   
   2. code size
   
   We got about 2% code size increase before and after
   `--enbale-branch-protection` is used. This code size change looks
   reasonable. See the evaluation on glibc [6].
   
   [1] https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication
   [2] https://bugs.openjdk.org/browse/JDK-8277204
   [3] https://community.arm.com/arm-community-blogs/b/tools-software-ides-blog/posts/code-reuse-attacks-the-compiler-story
   [4] https://reviews.llvm.org/D62609
   [5] https://github.com/ARM-software/abi-aa/blob/2a70c42d62e9c3eb5887fa50b71257f20daca6f9/aaelf64/aaelf64.rst#program-property
   [6] https://developer.arm.com/documentation/102433/0100/Applying-these-techniques-to-real-code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20491/files
  - new: https://git.openjdk.org/jdk/pull/20491/files/114953da..06c6e234

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20491&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20491&range=01-02

  Stats: 5391 lines in 320 files changed: 3562 ins; 739 del; 1090 mod
  Patch: https://git.openjdk.org/jdk/pull/20491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20491/head:pull/20491

PR: https://git.openjdk.org/jdk/pull/20491

From fgao at openjdk.org  Thu Aug 15 15:32:29 2024
From: fgao at openjdk.org (Fei Gao)
Date: Thu, 15 Aug 2024 15:32:29 GMT
Subject: RFR: 8337536: AArch64: Enable BTI branch protection for runtime
 part [v2]
In-Reply-To: <vUplKbuUzSIIRLMkMt3bN3TbTwGUJhbNd6X9VSkrYoA=.e745b7de-1a2a-47ef-a7b3-784433e1fc63@github.com>
References: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
 <M50QnYb5zJhnQL3ytXnW7Rg7AhQu1aXqDWY250gcNSo=.2397b42c-f1f1-4b2d-a94f-b39c7277b651@github.com>
 <vUplKbuUzSIIRLMkMt3bN3TbTwGUJhbNd6X9VSkrYoA=.e745b7de-1a2a-47ef-a7b3-784433e1fc63@github.com>
Message-ID: <VSP-AIRwreFZPz71ZjbwKaheT0Z19zdG28-llRfSxJE=.8fbcaac2-9667-40c7-973c-236e817af2f6@github.com>

On Thu, 15 Aug 2024 02:26:10 GMT, Eric Liu <eliu at openjdk.org> wrote:

>> Fei Gao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Clean up makefile
>>  - Merge branch 'master' into enable-bti-runtime
>>  - 8337536: AArch64: Enable BTI branch protection for runtime part
>>    
>>    This patch enables BTI branch protection for runtime part on
>>    Linux/aarch64 platform.
>>    
>>    Motivation
>>    
>>    1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default.
>>    User-level packages can gain additional hardening by compiling with the
>>    GCC/Clang flag `-mbranch-protection=flag`. See [1].
>>    
>>    2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as
>>    one VM configure flag, which would pass `-mbranch-protection=standard`
>>    compilation flags to all c/c++ files. Note that `standard` turns on both
>>    `pac-ret` and `bti` branch protections. For more details about code
>>    reuse attacks and hardware-assisted branch protections on AArch64, see
>>    [3].
>>    
>>    However, we checked the `.note.gnu.property` section of all the shared
>>    libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so
>>    didn't set these two target feature bits:
>>    
>>    ```
>>      GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>>      GNU_PROPERTY_AARCH64_FEATURE_1_PAC
>>    ```
>>    
>>    Note-1: BTI is an all or nothing property for a link unit [4]. That is,
>>    libjvm.so is not BTI-enabled.
>>    
>>    Note-2: PAC bit in `.note.gnu.property` section is used to protect
>>    `.got.plt` table. It's independent of whether the relocatable objects
>>    use PAC or not.
>>    
>>    Goal
>>    
>>    Hence, this patch aims to set PAC/BTI feature bits of the
>>    `.note.gnu.property` section for libjvm.so.
>>    
>>    Implementation
>>    
>>    Task-1: find out the problematic input objects
>>    
>>    From [5], "Static linkers processing ELF relocatable objects must set
>>    the feature bit in the output object or image only if all the input
>>    objects have the corresponding feature bit set." Hence we suspect that
>>    the root cause is probably that the PAC/BTI feature bits are not set
>>    only for some input objects of libjvm.so.
>>    
>>    In order to find out these inputs, we passed `--force-bti` linker flag
>>    [4] in my local test. This linker flag would warn if any input object
>>    does not have GNU_PROPERTY_AARCH64_FEATU...
>
> src/hotspot/cpu/aarch64/copy_aarch64.hpp line 67:
> 
>> 65: "       .align  5;\n"                                                   \
>> 66: "0:"                                                                    \
>> 67: "       hint    #0x24; // bti j\n"                                               \
> 
> LGTM. Only a few indent issues.

@e1iu thanks for review! Updated it in the new commit :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20491#discussion_r1718569298

From shade at openjdk.org  Thu Aug 15 15:46:49 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Aug 2024 15:46:49 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v8]
In-Reply-To: <OcEfGY_eIL84XBI90JgGr6ujZOZAhTSPnWMBYsl6yLI=.f713a987-a182-4071-9969-a2a4a5cc2355@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
 <OcEfGY_eIL84XBI90JgGr6ujZOZAhTSPnWMBYsl6yLI=.f713a987-a182-4071-9969-a2a4a5cc2355@github.com>
Message-ID: <9ZBiVdLMWPNgbSptb-8qJh6GIWP4XU5Kb3nec5snlqo=.5ca850a8-99a9-4d78-ac8a-38a8772c5be3@github.com>

On Thu, 15 Aug 2024 10:26:17 GMT, George Adams <gdams at openjdk.org> wrote:

>> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.
>
> George Adams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into alpine
>  - skip gtest and jtreg
>  - add Java 17 for jtreg
>  - add wget
>  - fix order of tasks
>  - fix alpine skip
>  - force grep newline
>  - fix test bundle
>  - add make-target: 'hotspot'
>  - 8282944: GHA: Add Alpine Linux x86_64 pre-integration check

Honestly, I am ambivalent about this. This only captures the Hotspot build errors, which I think are rare for Alpine, judging by looking around the JBS. And it makes sense: the build failures looks basically around compiling against weird libc APIs that might not be supported by musl. I think most of the issues with Alpine are runtime problems in tests?

So it looks that building only Hotspot is in weird spot: we spend time without getting much of the testing off it. How bad would it be to run testing with Alpine? That would probably not be very well received, though, if no one could debug Alpine test failures...

Tangentially, I think we should start thinking about extended workflows that are _not_ run by default PR-triggers, so you could potentially run them if you wanted for Alpine-specific fixes. This would making the decisions like this rather easy.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20577#issuecomment-2291572564

From gdams at openjdk.org  Thu Aug 15 15:52:49 2024
From: gdams at openjdk.org (George Adams)
Date: Thu, 15 Aug 2024 15:52:49 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v8]
In-Reply-To: <9ZBiVdLMWPNgbSptb-8qJh6GIWP4XU5Kb3nec5snlqo=.5ca850a8-99a9-4d78-ac8a-38a8772c5be3@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
 <OcEfGY_eIL84XBI90JgGr6ujZOZAhTSPnWMBYsl6yLI=.f713a987-a182-4071-9969-a2a4a5cc2355@github.com>
 <9ZBiVdLMWPNgbSptb-8qJh6GIWP4XU5Kb3nec5snlqo=.5ca850a8-99a9-4d78-ac8a-38a8772c5be3@github.com>
Message-ID: <AuuTuxYiFZkXC7YCAbJnga_kmotqbWp4PCM9oWXRe0w=.49481943-dee7-46a7-9e25-9ed60f2bc23f@github.com>

On Thu, 15 Aug 2024 15:44:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Honestly, I am ambivalent about this. This only captures the Hotspot build errors, which I think are rare for Alpine, judging by looking around the JBS. And it makes sense: the build failures looks basically around compiling against weird libc APIs that might not be supported by musl. I think most of the issues with Alpine are runtime problems in tests?
> 
> So it looks that building only Hotspot is in weird spot: we spend time without getting much of the testing off it. How bad would it be to run testing with Alpine? That would probably not be very well received, though, if no one could debug Alpine test failures...
> 
> Tangentially, I think we should start thinking about extended workflows that are _not_ run by default PR-triggers, so you could potentially run them if you wanted for Alpine-specific fixes. This would making the decisions like this rather easy.

I was actually going to try building the whole JDK and see what the difference in build time was. If it's not significant then it might be a good first step to just add full build testing. We could always follow up with test running at a later stage if people feel it would be important?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20577#issuecomment-2291582943

From gdams at openjdk.org  Thu Aug 15 15:58:19 2024
From: gdams at openjdk.org (George Adams)
Date: Thu, 15 Aug 2024 15:58:19 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v9]
In-Reply-To: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
Message-ID: <u3-TJI9_kNF-M5wF0URFfHrzMh3wGxU2E8NA578vW2I=.4b30a79b-232a-4df5-acb4-3b705066c864@github.com>

> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.

George Adams has updated the pull request incrementally with one additional commit since the last revision:

  build entire JDK rather than hotspot

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20577/files
  - new: https://git.openjdk.org/jdk/pull/20577/files/678df7fc..c6906eff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=07-08

  Stats: 8 lines in 1 file changed: 0 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/20577.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20577/head:pull/20577

PR: https://git.openjdk.org/jdk/pull/20577

From gdams at openjdk.org  Thu Aug 15 15:58:20 2024
From: gdams at openjdk.org (George Adams)
Date: Thu, 15 Aug 2024 15:58:20 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v8]
In-Reply-To: <OcEfGY_eIL84XBI90JgGr6ujZOZAhTSPnWMBYsl6yLI=.f713a987-a182-4071-9969-a2a4a5cc2355@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
 <OcEfGY_eIL84XBI90JgGr6ujZOZAhTSPnWMBYsl6yLI=.f713a987-a182-4071-9969-a2a4a5cc2355@github.com>
Message-ID: <QEihq_rUkN9xqlAMUDgm2GXBadgaVauVpE1lmaRpBfk=.ace7157e-cfbf-4638-90c5-f5094dc393c5@github.com>

On Thu, 15 Aug 2024 10:26:17 GMT, George Adams <gdams at openjdk.org> wrote:

>> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.
>
> George Adams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into alpine
>  - skip gtest and jtreg
>  - add Java 17 for jtreg
>  - add wget
>  - fix order of tasks
>  - fix alpine skip
>  - force grep newline
>  - fix test bundle
>  - add make-target: 'hotspot'
>  - 8282944: GHA: Add Alpine Linux x86_64 pre-integration check

For reference:

| Build Type | Duration |
| ----------  | -------- |
| hotspot (debug) | 21m |
| hotspot (release) | 15m |
| full (debug) | TBD |
| full (release) | TBD |

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20577#issuecomment-2291588558

From dalibor.topic at oracle.com  Thu Aug 15 20:53:00 2024
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Thu, 15 Aug 2024 22:53:00 +0200
Subject: OpenJDK configuration with emscripten problem
In-Reply-To: <CAAPjUpQsDLj09NbuD+_yhPFpDKR94XioKt15pZ0Xqx5UfbAwCg@mail.gmail.com>
References: <CAAPjUpQsDLj09NbuD+_yhPFpDKR94XioKt15pZ0Xqx5UfbAwCg@mail.gmail.com>
Message-ID: <de769e73-3c31-4526-bb3f-9ad31cbb59ff@oracle.com>

Hi ?a?la,

you want the build-dev mailing list for that kind of questions. 
Forwarded there. You can subscribe via 
https://mail.openjdk.org/mailman/listinfo/build-dev

Short answer is that there is no support for emscripten yet. If that's 
something you'd like to add, then build-dev is the right place to 
discuss it.

Fwiw, if you look through emscripten issues, someone else has already 
been on a similar journey recently. [0]

cheers,
dalibor topic

[0] https://github.com/emscripten-core/emscripten/issues/21961

On 15.08.2024 21:08, ?a?la Nur Yuva wrote:
> I don't know if it is a correct mail address to get support for openJDK 
> project, if it is not, you can ignore the message below.
> 
> I am trying to configure openjdk (https://github.com/openjdk/jdk 
> <https://github.com/openjdk/jdk>) with emscripten toolchain. However, 
> whether I use emconfigure or not, I can't manage to configure openjdk 
> with emscripten toolchain whatever values I gave for host, target or 
> openjdk-target etc.
> 
> Does OpenJDK configure file has support for emscripten toolchain? If it 
> is not, how can I add this support to openJDK? I would like to hear your 
> suggestions. Could you please clearly provide as much detail as possible?
> 
> Thank you.

-- 
<http://www.oracle.com> Dalibor Topic
Consulting Product Manager
Phone: +494089091214 <tel:+494089091214>, Mobile: +491737185961
<tel:+491737185961>

Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRB 246209
Gesch?ftsf?hrer: Ralf Herrmann


From mli at openjdk.org  Fri Aug 16 09:48:50 2024
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 16 Aug 2024 09:48:50 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v3]
In-Reply-To: <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com>
 <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
Message-ID: <geN8VMoF-kDepFi3AYS7wzBk7SxI-nZiD5-Vtx6cnVw=.023d7d59-27e6-4370-bd0b-787a3f143095@github.com>

On Thu, 27 Jun 2024 22:03:37 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately. This enhancement adds the relevant files, enabling the rest of [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward.
>
> Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update README to include RISC-V

> With this solution I would recommend putting the script next to the Sleef source tree instead of in make/devkit/.

> The normal JDK build will just use the committed pre-generated headers.

> Not because I didn't think it was feasible to implement, but because of the future maintenance burden.

I agree with @erikj79, in particular the above 3 points.

Shall we be ready to move forward? Or we're still blocked by some other issues, such as legal process?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2293190145

From ihse at openjdk.org  Fri Aug 16 11:54:49 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 16 Aug 2024 11:54:49 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v9]
In-Reply-To: <u3-TJI9_kNF-M5wF0URFfHrzMh3wGxU2E8NA578vW2I=.4b30a79b-232a-4df5-acb4-3b705066c864@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
 <u3-TJI9_kNF-M5wF0URFfHrzMh3wGxU2E8NA578vW2I=.4b30a79b-232a-4df5-acb4-3b705066c864@github.com>
Message-ID: <KNu5-Psu2mCkSvWfgvhzI3Q2JiNC1qk68lG553tv1yI=.3ef64746-625c-4163-8fb7-16bd04425a61@github.com>

On Thu, 15 Aug 2024 15:58:19 GMT, George Adams <gdams at openjdk.org> wrote:

>> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.
>
> George Adams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   build entire JDK rather than hotspot

> Tangentially, I think we should start thinking about extended workflows that are not run by default PR-triggers, so you could potentially run them if you wanted for Alpine-specific fixes. This would making the decisions like this rather easy.

I agree, we should really add that functionality. Then, as you say, it would be a no-brainer to add Alpine as an opt-in build and/or build+test.

If you are hesitant as well about adding this, maybe this is something we should prioritize before accepting this. (And then only accepting this as a non-default option.)

It might be so simple as to not list it in the `default` field of the platform selection part. 

@gdams Maybe you can test that? Revert line 39 in main.yml, and start the test manually and specify alpine as a target.

If that works fine, we can add some way for users to set their own defaults by setting a GHA environment/repository variable. (Either an "JDK_EXTRA_TARGETS" to just appent more to the default, or a "JDK_TARGETS" to completely override, or both.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20577#issuecomment-2293367690

From jlahoda at openjdk.org  Fri Aug 16 12:28:15 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 16 Aug 2024 12:28:15 GMT
Subject: RFR: 8298920: Improve microbenchmark build times
Message-ID: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>

Currently incremental builds for the microbenchmarks may take notable amount of time, like:

$ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
Building target 'test' in configuration 'linux-x86_64-server-release'
Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
Running Indify on microbenchmark classes
[snip]
==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
   jtreg:test/jaxp:tier1                                 0     0     0     0
==============================
TEST SUCCESS

Finished building target 'test' in configuration 'linux-x86_64-server-release'

real    0m37,581s
user    2m4,747s
sys     0m7,223s


The microbenchmark compilation is not using the `Depend` plugin that avoids recompilation of other files if the change files only contain minor changes (i.e. non-API changes). The patch here proposes to enhance the build to use the `Depend` plugin. The change that enables that is `CREATE_API_DIGEST := true,`, but since both the `Depend` plugin and JMH framework needs to be added to the classpath the patch re-organizes the code a little to properly augment the classpath.

With this patch, a build similar to the above might be:

$ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
Building target 'test' in configuration 'linux-x86_64-server-release'
Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
Running Indify on microbenchmark classes
[snip]
==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
   jtreg:test/jaxp:tier1                                 0     0     0     0
==============================
TEST SUCCESS

Finished building target 'test' in configuration 'linux-x86_64-server-release'

real    0m7,505s
user    0m14,128s
sys     0m3,158s

-------------

Commit messages:
 - 8298920: Improve microbenchmark build times

Changes: https://git.openjdk.org/jdk/pull/20616/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20616&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298920
  Stats: 32 lines in 2 files changed: 16 ins; 14 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20616.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20616/head:pull/20616

PR: https://git.openjdk.org/jdk/pull/20616

From erikj at openjdk.org  Fri Aug 16 13:18:49 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 16 Aug 2024 13:18:49 GMT
Subject: RFR: 8298920: Improve microbenchmark build times
In-Reply-To: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
References: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
Message-ID: <1S73jpdQcdnJ77y1cgu42I6xujASLv5nZR8LYEylV4M=.bb86217c-7613-4bc7-be74-fff37dee11e8@github.com>

On Fri, 16 Aug 2024 12:24:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently incremental builds for the microbenchmarks may take notable amount of time, like:
> 
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
> Building target 'test' in configuration 'linux-x86_64-server-release'
> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
> Running Indify on microbenchmark classes
> [snip]
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp:tier1                                 0     0     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'linux-x86_64-server-release'
> 
> real    0m37,581s
> user    2m4,747s
> sys     0m7,223s
> 
> 
> The microbenchmark compilation is not using the `Depend` plugin that avoids recompilation of other files if the change files only contain minor changes (i.e. non-API changes). The patch here proposes to enhance the build to use the `Depend` plugin. The change that enables that is `CREATE_API_DIGEST := true,`, but since both the `Depend` plugin and JMH framework needs to be added to the classpath the patch re-organizes the code a little to properly augment the classpath.
> 
> With this patch, a build similar to the above might be:
> 
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
> Building target 'test' in configuration 'linux-x86_64-server-release'
> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
> Running Indify on microbenchmark classes
> [snip]
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp:tier1                                 0     0     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'linux-x86_64-server-release'
> 
> real    0m7,505s
> user    0m14,128s
> sys     0m3,158s

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20616#pullrequestreview-2242686219

From liach at openjdk.org  Fri Aug 16 13:18:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 16 Aug 2024 13:18:49 GMT
Subject: RFR: 8298920: Improve microbenchmark build times
In-Reply-To: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
References: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
Message-ID: <g2ZCNsmK0q7YVdXiyloe3yfiK-rA5fJfSgF5bgeabZM=.534183d4-9308-4667-a759-e3aa164df949@github.com>

On Fri, 16 Aug 2024 12:24:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently incremental builds for the microbenchmarks may take notable amount of time, like:
> 
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
> Building target 'test' in configuration 'linux-x86_64-server-release'
> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
> Running Indify on microbenchmark classes
> [snip]
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp:tier1                                 0     0     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'linux-x86_64-server-release'
> 
> real    0m37,581s
> user    2m4,747s
> sys     0m7,223s
> 
> 
> The microbenchmark compilation is not using the `Depend` plugin that avoids recompilation of other files if the change files only contain minor changes (i.e. non-API changes). The patch here proposes to enhance the build to use the `Depend` plugin. The change that enables that is `CREATE_API_DIGEST := true,`, but since both the `Depend` plugin and JMH framework needs to be added to the classpath the patch re-organizes the code a little to properly augment the classpath.
> 
> With this patch, a build similar to the above might be:
> 
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
> Building target 'test' in configuration 'linux-x86_64-server-release'
> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
> Running Indify on microbenchmark classes
> [snip]
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp:tier1                                 0     0     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'linux-x86_64-server-release'
> 
> real    0m7,505s
> user    0m14,128s
> sys     0m3,158s

Note that this is affecting regular jtreg tests too. So great fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20616#issuecomment-2293492318

From gdams at openjdk.org  Fri Aug 16 15:35:49 2024
From: gdams at openjdk.org (George Adams)
Date: Fri, 16 Aug 2024 15:35:49 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v9]
In-Reply-To: <KNu5-Psu2mCkSvWfgvhzI3Q2JiNC1qk68lG553tv1yI=.3ef64746-625c-4163-8fb7-16bd04425a61@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
 <u3-TJI9_kNF-M5wF0URFfHrzMh3wGxU2E8NA578vW2I=.4b30a79b-232a-4df5-acb4-3b705066c864@github.com>
 <KNu5-Psu2mCkSvWfgvhzI3Q2JiNC1qk68lG553tv1yI=.3ef64746-625c-4163-8fb7-16bd04425a61@github.com>
Message-ID: <u_rhjnRpWP5O4Q5uhnVcWgj-wdSQCK3ZpUp-EJyQ_3c=.ddba15ba-c63d-4862-8f56-cecf96cd2cd7@github.com>

On Fri, 16 Aug 2024 11:52:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > Tangentially, I think we should start thinking about extended workflows that are not run by default PR-triggers, so you could potentially run them if you wanted for Alpine-specific fixes. This would making the decisions like this rather easy.
> 
> I agree, we should really add that functionality. Then, as you say, it would be a no-brainer to add Alpine as an opt-in build and/or build+test.
> 
> If you are hesitant as well about adding this, maybe this is something we should prioritize before accepting this. (And then only accepting this as a non-default option.)
> 
> It might be so simple as to not list it in the `default` field of the platform selection part.
> 
> @gdams Maybe you can test that? Revert line 39 in main.yml, and start the test manually and specify alpine as a target.
> 
> If that works fine, we can add some way for users to set their own defaults by setting a GHA environment/repository variable. (Either an "JDK_EXTRA_TARGETS" to just appent more to the default, or a "JDK_TARGETS" to completely override, or both.)

I'm not actually sure if line 39 is where we want to make the changes. I think we need to add some logic to this function to skip certain platforms by default when a push event is triggered:

https://github.com/openjdk/jdk/blob/c6906eff9db8f7e7737c42af49ae4f2f6ad7b095/.github/workflows/main.yml#L77-L112

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20577#issuecomment-2293726115

From gdams at openjdk.org  Fri Aug 16 15:59:02 2024
From: gdams at openjdk.org (George Adams)
Date: Fri, 16 Aug 2024 15:59:02 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v10]
In-Reply-To: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
Message-ID: <gVt8hFOdYcYlBehIzcWYvYz9RUZCbMM8pBc768zV4j0=.46c835fa-ca3c-4be3-bdd0-60922d36185d@github.com>

> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.

George Adams has updated the pull request incrementally with one additional commit since the last revision:

  skip alpine linux build by default

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20577/files
  - new: https://git.openjdk.org/jdk/pull/20577/files/c6906eff..4a6cbe47

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=08-09

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20577.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20577/head:pull/20577

PR: https://git.openjdk.org/jdk/pull/20577

From gdams at openjdk.org  Fri Aug 16 15:59:03 2024
From: gdams at openjdk.org (George Adams)
Date: Fri, 16 Aug 2024 15:59:03 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v9]
In-Reply-To: <KNu5-Psu2mCkSvWfgvhzI3Q2JiNC1qk68lG553tv1yI=.3ef64746-625c-4163-8fb7-16bd04425a61@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
 <u3-TJI9_kNF-M5wF0URFfHrzMh3wGxU2E8NA578vW2I=.4b30a79b-232a-4df5-acb4-3b705066c864@github.com>
 <KNu5-Psu2mCkSvWfgvhzI3Q2JiNC1qk68lG553tv1yI=.3ef64746-625c-4163-8fb7-16bd04425a61@github.com>
Message-ID: <aKuQNBy80NiZBFW406OPK8LOJdZI8CbDTjrWiOjAd54=.e5be3a41-1731-4607-a885-e83bd346399e@github.com>

On Fri, 16 Aug 2024 11:52:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> George Adams has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   build entire JDK rather than hotspot
>
>> Tangentially, I think we should start thinking about extended workflows that are not run by default PR-triggers, so you could potentially run them if you wanted for Alpine-specific fixes. This would making the decisions like this rather easy.
> 
> I agree, we should really add that functionality. Then, as you say, it would be a no-brainer to add Alpine as an opt-in build and/or build+test.
> 
> If you are hesitant as well about adding this, maybe this is something we should prioritize before accepting this. (And then only accepting this as a non-default option.)
> 
> It might be so simple as to not list it in the `default` field of the platform selection part. 
> 
> @gdams Maybe you can test that? Revert line 39 in main.yml, and start the test manually and specify alpine as a target.
> 
> If that works fine, we can add some way for users to set their own defaults by setting a GHA environment/repository variable. (Either an "JDK_EXTRA_TARGETS" to just appent more to the default, or a "JDK_TARGETS" to completely override, or both.)

@magicus I've pushed a single line change to the `if:` logic for the Alpine Linux job which means it will only run on workflow dispatch runs (e.g manually)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20577#issuecomment-2293755189

From ihse at openjdk.org  Mon Aug 19 07:22:50 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 19 Aug 2024 07:22:50 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v10]
In-Reply-To: <gVt8hFOdYcYlBehIzcWYvYz9RUZCbMM8pBc768zV4j0=.46c835fa-ca3c-4be3-bdd0-60922d36185d@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
 <gVt8hFOdYcYlBehIzcWYvYz9RUZCbMM8pBc768zV4j0=.46c835fa-ca3c-4be3-bdd0-60922d36185d@github.com>
Message-ID: <4utmgkpAm-qFIGQyawBLZ8fvDgON-VhiNFZEq2AytWo=.6c0a8de8-5e60-42f6-889a-fcb060f68293@github.com>

On Fri, 16 Aug 2024 15:59:02 GMT, George Adams <gdams at openjdk.org> wrote:

>> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.
>
> George Adams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   skip alpine linux build by default

For the future, I think we should try to figure out a way to allow users to define their own set of included checks persistently, but for now this is good. Since it will not run by default, I have no objections.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20577#pullrequestreview-2244784570

From gdams at openjdk.org  Mon Aug 19 08:49:49 2024
From: gdams at openjdk.org (George Adams)
Date: Mon, 19 Aug 2024 08:49:49 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v10]
In-Reply-To: <4utmgkpAm-qFIGQyawBLZ8fvDgON-VhiNFZEq2AytWo=.6c0a8de8-5e60-42f6-889a-fcb060f68293@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
 <gVt8hFOdYcYlBehIzcWYvYz9RUZCbMM8pBc768zV4j0=.46c835fa-ca3c-4be3-bdd0-60922d36185d@github.com>
 <4utmgkpAm-qFIGQyawBLZ8fvDgON-VhiNFZEq2AytWo=.6c0a8de8-5e60-42f6-889a-fcb060f68293@github.com>
Message-ID: <sLRygLZPw6xq104QZLduTxV9DTLXfFNjCM8YKlLo5AM=.8d771185-26f9-45c3-8ea7-5facb83ae983@github.com>

On Mon, 19 Aug 2024 07:20:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> For the future, I think we should try to figure out a way to allow users to define their own set of included checks persistently, but for now this is good. Since it will not run by default, I have no objections.

I think this is the idea of these `JDK_SUBMIT_FILTER` and `JDK_SUBMIT_PLATFORMS`:

https://github.com/openjdk/jdk/blob/4a6cbe47daae82970c36c8cd86655581b2c59f59/.github/workflows/main.yml#L86-L92

Admittedly with my current setup this wouldn't work for Alpine. The only other option I could think of is maintaining a list of "skip unless explicitly defined" platforms in the `check_platform()` function. I'd be happy to put a prototype together if you'd prefer this solution

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20577#issuecomment-2296016836

From gdams at openjdk.org  Mon Aug 19 09:23:50 2024
From: gdams at openjdk.org (George Adams)
Date: Mon, 19 Aug 2024 09:23:50 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v10]
In-Reply-To: <sLRygLZPw6xq104QZLduTxV9DTLXfFNjCM8YKlLo5AM=.8d771185-26f9-45c3-8ea7-5facb83ae983@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
 <gVt8hFOdYcYlBehIzcWYvYz9RUZCbMM8pBc768zV4j0=.46c835fa-ca3c-4be3-bdd0-60922d36185d@github.com>
 <4utmgkpAm-qFIGQyawBLZ8fvDgON-VhiNFZEq2AytWo=.6c0a8de8-5e60-42f6-889a-fcb060f68293@github.com>
 <sLRygLZPw6xq104QZLduTxV9DTLXfFNjCM8YKlLo5AM=.8d771185-26f9-45c3-8ea7-5facb83ae983@github.com>
Message-ID: <Gg5AfbLm8wJUrEUEBWg9a5NTg24hmVHsNwxVQZwPpZA=.d74d161e-d76a-466b-a498-6e6c89ef72f7@github.com>

On Mon, 19 Aug 2024 08:47:13 GMT, George Adams <gdams at openjdk.org> wrote:

> > For the future, I think we should try to figure out a way to allow users to define their own set of included checks persistently, but for now this is good. Since it will not run by default, I have no objections.
> 
> I think this is the idea of these `JDK_SUBMIT_FILTER` and `JDK_SUBMIT_PLATFORMS`:
> 
> https://github.com/openjdk/jdk/blob/4a6cbe47daae82970c36c8cd86655581b2c59f59/.github/workflows/main.yml#L86-L92
> 
> Admittedly with my current setup this wouldn't work for Alpine. The only other option I could think of is maintaining a list of "skip unless explicitly defined" platforms in the `check_platform()` function. I'd be happy to put a prototype together if you'd prefer this solution

I found https://wiki.openjdk.org/display/skara/testing#Testing-Conditionallyenable/disablebuildsandtests which defines this process but unfortunately this has been broken for some time in GitHub actions as it treats the platform as a secret and redacts it's contents:

<img width="604" alt="Screenshot 2024-08-19 at 10 21 21" src="https://github.com/user-attachments/assets/1f29aa51-caf9-4e31-a70e-8042175ca6bb">

I'll see if I can find a workaround that fixes this

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20577#issuecomment-2296086833

From gdams at openjdk.org  Mon Aug 19 09:44:04 2024
From: gdams at openjdk.org (George Adams)
Date: Mon, 19 Aug 2024 09:44:04 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v11]
In-Reply-To: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
Message-ID: <Kyy0KaV6gq3Y9P7PPKEDwvhsfwcNidctgGN0X2jtW2k=.b0a7841c-5fc4-47c4-a972-0dd29b181c9e@github.com>

> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.

George Adams has updated the pull request incrementally with two additional commits since the last revision:

 - improve conditional logic
 - try this

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20577/files
  - new: https://git.openjdk.org/jdk/pull/20577/files/4a6cbe47..ab51ba67

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=09-10

  Stats: 21 lines in 1 file changed: 18 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20577.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20577/head:pull/20577

PR: https://git.openjdk.org/jdk/pull/20577

From gdams at openjdk.org  Mon Aug 19 09:44:04 2024
From: gdams at openjdk.org (George Adams)
Date: Mon, 19 Aug 2024 09:44:04 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v9]
In-Reply-To: <KNu5-Psu2mCkSvWfgvhzI3Q2JiNC1qk68lG553tv1yI=.3ef64746-625c-4163-8fb7-16bd04425a61@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
 <u3-TJI9_kNF-M5wF0URFfHrzMh3wGxU2E8NA578vW2I=.4b30a79b-232a-4df5-acb4-3b705066c864@github.com>
 <KNu5-Psu2mCkSvWfgvhzI3Q2JiNC1qk68lG553tv1yI=.3ef64746-625c-4163-8fb7-16bd04425a61@github.com>
Message-ID: <fh4QHlaPIuwgIWR_hFZcl2E6tBZPUBsu1MCm1kuQU3s=.bdd32749-5e11-4021-9e5c-46215b5bfe30@github.com>

On Fri, 16 Aug 2024 11:52:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> George Adams has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   build entire JDK rather than hotspot
>
>> Tangentially, I think we should start thinking about extended workflows that are not run by default PR-triggers, so you could potentially run them if you wanted for Alpine-specific fixes. This would making the decisions like this rather easy.
> 
> I agree, we should really add that functionality. Then, as you say, it would be a no-brainer to add Alpine as an opt-in build and/or build+test.
> 
> If you are hesitant as well about adding this, maybe this is something we should prioritize before accepting this. (And then only accepting this as a non-default option.)
> 
> It might be so simple as to not list it in the `default` field of the platform selection part. 
> 
> @gdams Maybe you can test that? Revert line 39 in main.yml, and start the test manually and specify alpine as a target.
> 
> If that works fine, we can add some way for users to set their own defaults by setting a GHA environment/repository variable. (Either an "JDK_EXTRA_TARGETS" to just appent more to the default, or a "JDK_TARGETS" to completely override, or both.)

@magicus I think I've got this working correctly now. If users choose to they can run alpine testing by default by following https://wiki.openjdk.org/display/skara/testing#Testing-Conditionallyenable/disablebuildsandtests or run it manually by triggering the `workflow_dispatch` but by default Alpine will not run

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20577#issuecomment-2296127572

From ihse at openjdk.org  Mon Aug 19 13:23:50 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 19 Aug 2024 13:23:50 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v11]
In-Reply-To: <Kyy0KaV6gq3Y9P7PPKEDwvhsfwcNidctgGN0X2jtW2k=.b0a7841c-5fc4-47c4-a972-0dd29b181c9e@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
 <Kyy0KaV6gq3Y9P7PPKEDwvhsfwcNidctgGN0X2jtW2k=.b0a7841c-5fc4-47c4-a972-0dd29b181c9e@github.com>
Message-ID: <o1ChjR1bf9Vz0HnE4SNJT5m2OEUaz5zBxg4gA3hO_Uw=.d79b9cd5-8519-494b-9351-dfa60ef8cdfe@github.com>

On Mon, 19 Aug 2024 09:44:04 GMT, George Adams <gdams at openjdk.org> wrote:

>> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.
>
> George Adams has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - improve conditional logic
>  - try this

.github/workflows/main.yml line 84:

> 82: 
> 83:           # List of platforms to exclude by default
> 84:           EXCLUDED_PLATFORMS=("alpine-linux-x64")

I'm not to fond of declaring a list like this in the middle of a code body. Perhaps you can set it up as a non-required workflow input with alpine as the default value, declared next to the default list of platforms?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20577#discussion_r1721781401

From ihse at openjdk.org  Mon Aug 19 13:28:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 19 Aug 2024 13:28:52 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v11]
In-Reply-To: <Kyy0KaV6gq3Y9P7PPKEDwvhsfwcNidctgGN0X2jtW2k=.b0a7841c-5fc4-47c4-a972-0dd29b181c9e@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
 <Kyy0KaV6gq3Y9P7PPKEDwvhsfwcNidctgGN0X2jtW2k=.b0a7841c-5fc4-47c4-a972-0dd29b181c9e@github.com>
Message-ID: <Og0AHzStB0tBa7fhWptcowwoXSn0GHJm961y-fLr6to=.59080e4e-e919-4c55-af60-4502847c1d61@github.com>

On Mon, 19 Aug 2024 09:44:04 GMT, George Adams <gdams at openjdk.org> wrote:

>> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.
>
> George Adams has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - improve conditional logic
>  - try this

Yes, this is somewhat more akin to what I was thinking. But I was actually thinking about a more encompassing rewrite of that method.

First of all, GHA variables did not exist when that code were written, so they had to be secrets, even though it does not make sense in this context. These control variables should be changed from secrets to variables, or the code rewritten so it can support both.

Secondly, I think there is a use-case for having both a variable which just appends to the default set of platforms/tests, and one that replaces the default value.

Third, there has been requests to change what tests are run  (e.g. tier-2) as well as which platforms are tested. I think it would be good to let such functionality tie in with any other changes in this area.

But, just to be clear, I don't think it is necessary, nor even appropriate, for you to address any of these changes in this PR. In fact, I would have been happy with the previous iteration as well. But this version is okay as well, if you can move the exclude list to a more suited location.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20577#issuecomment-2296576086

From duke at openjdk.org  Mon Aug 19 13:30:57 2024
From: duke at openjdk.org (duke)
Date: Mon, 19 Aug 2024 13:30:57 GMT
Subject: Withdrawn: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis
In-Reply-To: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
Message-ID: <Jr7cUWDjepxdj9H7rWSBEzzzkDeqBFyuIWEXtutjlVY=.91688338-dec9-454f-b541-5883aae27af6@github.com>

On Tue, 23 Apr 2024 13:56:32 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> WIP
> 
> This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/18915

From gdams at openjdk.org  Mon Aug 19 13:37:49 2024
From: gdams at openjdk.org (George Adams)
Date: Mon, 19 Aug 2024 13:37:49 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v11]
In-Reply-To: <Og0AHzStB0tBa7fhWptcowwoXSn0GHJm961y-fLr6to=.59080e4e-e919-4c55-af60-4502847c1d61@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
 <Kyy0KaV6gq3Y9P7PPKEDwvhsfwcNidctgGN0X2jtW2k=.b0a7841c-5fc4-47c4-a972-0dd29b181c9e@github.com>
 <Og0AHzStB0tBa7fhWptcowwoXSn0GHJm961y-fLr6to=.59080e4e-e919-4c55-af60-4502847c1d61@github.com>
Message-ID: <RXArkjcIB2_K0benSuZbEX-6ukYb9u_DgYqmwFoKE7o=.494a3152-cae3-45fa-9c72-210a3f1d4e5f@github.com>

On Mon, 19 Aug 2024 13:26:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Yes, this is somewhat more akin to what I was thinking. But I was actually thinking about a more encompassing rewrite of that method.
> 
> First of all, GHA variables did not exist when that code were written, so they had to be secrets, even though it does not make sense in this context. These control variables should be changed from secrets to variables, or the code rewritten so it can support both.
> 
> Secondly, I think there is a use-case for having both a variable which just appends to the default set of platforms/tests, and one that replaces the default value.
> 
> Third, there has been requests to change what tests are run (e.g. tier-2) as well as which platforms are tested. I think it would be good to let such functionality tie in with any other changes in this area.
> 
> But, just to be clear, I don't think it is necessary, nor even appropriate, for you to address any of these changes in this PR. In fact, I would have been happy with the previous iteration as well. But this version is okay as well, if you can move the exclude list to a more suited location.

yeah I totally agree with this idea, I'm happy to make these changes but that's outside of the scope of this PR, I'll test some changes in my local environment.

> .github/workflows/main.yml line 84:
> 
>> 82: 
>> 83:           # List of platforms to exclude by default
>> 84:           EXCLUDED_PLATFORMS=("alpine-linux-x64")
> 
> I'm not to fond of declaring a list like this in the middle of a code body. Perhaps you can set it up as a non-required workflow input with alpine as the default value, declared next to the default list of platforms?

yeah this makes sense, I'll make that change now

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20577#issuecomment-2296595922
PR Review Comment: https://git.openjdk.org/jdk/pull/20577#discussion_r1721799725

From ihse at openjdk.org  Mon Aug 19 14:19:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 19 Aug 2024 14:19:52 GMT
Subject: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX
 [v7]
In-Reply-To: <Im5Io8I0KFrq0VMnTh04FN1lF_lJ894Ol6UHbzoLALA=.b9fa2522-eb47-4b62-9ad4-45c10319cf5a@github.com>
References: <ICO286ZvQYqYXv9c73UlduKVcNF19k9Eln1po4znpxc=.2fbc366d-3095-47ca-a49d-ec35509f30ba@github.com>
 <Im5Io8I0KFrq0VMnTh04FN1lF_lJ894Ol6UHbzoLALA=.b9fa2522-eb47-4b62-9ad4-45c10319cf5a@github.com>
Message-ID: <tYLRJq2cvSKrblf0lEQz1_FslyxKa2h9AItoKmEr0iI=.1ea54296-2fd6-40e0-85be-137db01ae459@github.com>

On Thu, 18 Jan 2024 16:21:46 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted autoconf flags being added to the command line, and solves the issue by filtering out the added flags by force. This is not optimal however, as doing so leaves the autoconf message that the flags were added still displaying during the configure process, which is confusing. Instead, setting a couple of fields to disable the autoconf internals responsible for the unwanted flag is a cleaner solution
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement custom AC_PROG_CC and AC_PROG_CXX in util.m4

Keep it for a while more, bot. I'll try to some testing of this on 2.69 and 2.70 if Julian is unable to.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-2296693414

From matthias.baesken at sap.com  Mon Aug 19 14:41:47 2024
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 19 Aug 2024 14:41:47 +0000
Subject: MSAN memory sanitizer and OpenJDK 
Message-ID: <AM9PR02MB6770D886D486B74C631E1D82938C2@AM9PR02MB6770.eurprd02.prod.outlook.com>

Hello , I thought about  MSAN memory sanitizer  and OpenJDK. See

https://clang.llvm.org/docs/MemorySanitizer.html
https://github.com/google/sanitizers/wiki/MemorySanitizer

We have already some sanitizer support in OpenJDK  e.g. for ASAN  (address) and UBSAN  (undefined behavior).
Would MSAN be still useful , or is everything already  covered by other tools?
Was there already some attempt to try out/support MSAN with OpenJDK ?

While looking into it,  it seems that so far MSAN only works with clang   (while e.g. UBSAN works with clang and gcc),  is that correct ?

Btw.  while giving it a try  to compile OpenJDK with MSAN support  (Linux/clang ; added  build flags  -fsanitize=memory -fno-omit-frame-pointer )  I was running into this

?/jdk/bin/javac: symbol lookup error: ?/jdk/bin/../lib/libjli.so: undefined symbol: __msan_param_tls

(maybe someone has seen a similar error ?)


Best regards, Matthias






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240819/d54ba243/attachment-0001.htm>

From gdams at openjdk.org  Mon Aug 19 15:27:51 2024
From: gdams at openjdk.org (George Adams)
Date: Mon, 19 Aug 2024 15:27:51 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v11]
In-Reply-To: <o1ChjR1bf9Vz0HnE4SNJT5m2OEUaz5zBxg4gA3hO_Uw=.d79b9cd5-8519-494b-9351-dfa60ef8cdfe@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
 <Kyy0KaV6gq3Y9P7PPKEDwvhsfwcNidctgGN0X2jtW2k=.b0a7841c-5fc4-47c4-a972-0dd29b181c9e@github.com>
 <o1ChjR1bf9Vz0HnE4SNJT5m2OEUaz5zBxg4gA3hO_Uw=.d79b9cd5-8519-494b-9351-dfa60ef8cdfe@github.com>
Message-ID: <M9bnSiAj91quEFLCLQLa0EV7_Wbyzh7bJ6_fnY5rC_k=.69510389-f622-4ab7-a73d-ab0c28dada4d@github.com>

On Mon, 19 Aug 2024 13:21:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> George Adams has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - improve conditional logic
>>  - try this
>
> .github/workflows/main.yml line 84:
> 
>> 82: 
>> 83:           # List of platforms to exclude by default
>> 84:           EXCLUDED_PLATFORMS=("alpine-linux-x64")
> 
> I'm not to fond of declaring a list like this in the middle of a code body. Perhaps you can set it up as a non-required workflow input with alpine as the default value, declared next to the default list of platforms?

@magicus do you want me to push this change?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20577#discussion_r1721971949

From gdams at openjdk.org  Mon Aug 19 15:33:07 2024
From: gdams at openjdk.org (George Adams)
Date: Mon, 19 Aug 2024 15:33:07 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v12]
In-Reply-To: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
Message-ID: <cnkyJoEgKge8mJZ-VSzH5XXxoHh7WJLiBE2isMREd80=.fe84db13-5f3c-4bfb-abe6-0487ab9ae08b@github.com>

> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.

George Adams has updated the pull request incrementally with one additional commit since the last revision:

  move EXCLUDED_PLATFORMS definition to the top of the job

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20577/files
  - new: https://git.openjdk.org/jdk/pull/20577/files/ab51ba67..a223d3c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20577&range=10-11

  Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20577.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20577/head:pull/20577

PR: https://git.openjdk.org/jdk/pull/20577

From djelinski at openjdk.org  Mon Aug 19 19:51:48 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 19 Aug 2024 19:51:48 GMT
Subject: RFR: 8298920: Improve microbenchmark build times
In-Reply-To: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
References: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
Message-ID: <SstjE0P3uwic8DqQoXN9VgeCB8Stq793FlKMsi5emrc=.dca719e6-a0e7-4a01-a06a-532f694d8d9a@github.com>

On Fri, 16 Aug 2024 12:24:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently incremental builds for the microbenchmarks may take notable amount of time, like:
> 
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
> Building target 'test' in configuration 'linux-x86_64-server-release'
> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
> Running Indify on microbenchmark classes
> [snip]
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp:tier1                                 0     0     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'linux-x86_64-server-release'
> 
> real    0m37,581s
> user    2m4,747s
> sys     0m7,223s
> 
> 
> The microbenchmark compilation is not using the `Depend` plugin that avoids recompilation of other files if the change files only contain minor changes (i.e. non-API changes). The patch here proposes to enhance the build to use the `Depend` plugin. The change that enables that is `CREATE_API_DIGEST := true,`, but since both the `Depend` plugin and JMH framework needs to be added to the classpath the patch re-organizes the code a little to properly augment the classpath.
> 
> With this patch, a build similar to the above might be:
> 
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
> Building target 'test' in configuration 'linux-x86_64-server-release'
> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
> Running Indify on microbenchmark classes
> [snip]
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp:tier1                                 0     0     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'linux-x86_64-server-release'
> 
> real    0m7,505s
> user    0m14,128s
> sys     0m3,158s

That's a great improvement. Thanks!

I noticed that with these changes, the api files (_the.BUILD_JDK_MICROBENCHMARK_*api) are included in the resulting jar file (images/test/micro/benchmarks.jar). Probably not a big deal.

> Note that this is affecting regular jtreg tests too. So great fix.

Yeah! Though I tend to keep a worktree configured without --with-jmh for even greater speedup.

-------------

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20616#pullrequestreview-2246339529

From serb at openjdk.org  Mon Aug 19 19:59:00 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 19 Aug 2024 19:59:00 GMT
Subject: RFR: 8297088: Update LCMS to 2.14
In-Reply-To: <ipiXX_herQFr9T35SL10vIC3cIbIp_w1E-Xy_8mb_oU=.5b9f5d94-7ac8-4ab1-ae36-63d3b735de56@github.com>
References: <dNSastNjApaqQREyv3DDYY-uEfyXn9Mfjp_4hXgcpOk=.24e9897d-a556-4b34-b315-b1be2ba46735@github.com>
 <ipiXX_herQFr9T35SL10vIC3cIbIp_w1E-Xy_8mb_oU=.5b9f5d94-7ac8-4ab1-ae36-63d3b735de56@github.com>
Message-ID: <UN-duBvD485woi3mSA4aLAHkyeOi_UUY3iEw1ea_g6Y=.80241231-0775-432b-abab-f1c1d3858e32@github.com>

On Fri, 18 Nov 2022 08:42:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Redo of 8295369: Update LCMS to 2.14
>> Update LCMS to newest release.
>> Updated DISABLED_WARNINGS_gcc for LCMS to include type limits to prevent a build error in linux.
>> Automatic tests and J2D demo tests were run.
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 308:
> 
>> 306:         libawt/java2d, \
>> 307:     HEADERS_FROM_SRC := $(LIBLCMS_HEADERS_FROM_SRC), \
>> 308:     DISABLED_WARNINGS_gcc := format-nonliteral type-limits stringop-truncation, \
> 
> it would be good to report this upstream.

https://github.com/mm2/Little-CMS/issues/458

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11217#discussion_r1722281884

From djelinski at openjdk.org  Mon Aug 19 20:05:48 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 19 Aug 2024 20:05:48 GMT
Subject: RFR: 8298920: Improve microbenchmark build times
In-Reply-To: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
References: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
Message-ID: <BZBcTGdUThiVjz79hikstbRF9DsVrMg5-e58s6GO7f4=.6e5c06ea-69a5-48d6-a792-f6e8177dd8a1@github.com>

On Fri, 16 Aug 2024 12:24:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently incremental builds for the microbenchmarks may take notable amount of time, like:
> 
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
> Building target 'test' in configuration 'linux-x86_64-server-release'
> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
> Running Indify on microbenchmark classes
> [snip]
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp:tier1                                 0     0     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'linux-x86_64-server-release'
> 
> real    0m37,581s
> user    2m4,747s
> sys     0m7,223s
> 
> 
> The microbenchmark compilation is not using the `Depend` plugin that avoids recompilation of other files if the change files only contain minor changes (i.e. non-API changes). The patch here proposes to enhance the build to use the `Depend` plugin. The change that enables that is `CREATE_API_DIGEST := true,`, but since both the `Depend` plugin and JMH framework needs to be added to the classpath the patch re-organizes the code a little to properly augment the classpath.
> 
> With this patch, a build similar to the above might be:
> 
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
> Building target 'test' in configuration 'linux-x86_64-server-release'
> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
> Running Indify on microbenchmark classes
> [snip]
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp:tier1                                 0     0     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'linux-x86_64-server-release'
> 
> real    0m7,505s
> user    0m14,128s
> sys     0m3,158s

Wait, something is off here:

$ touch test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench.java;time make test TEST=jaxp:tier1
Building target 'test' in configuration 'windows-x86_64-server-release'
Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
C:...\test\micro\org\openjdk\bench\javax\crypto\full\AESGCMBench.java:36: error: cannot find symbol
public class AESGCMBench extends BenchBase {
                                 ^
  symbol: class BenchBase
1 error

-------------

Changes requested by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20616#pullrequestreview-2246361916

From djelinski at openjdk.org  Tue Aug 20 09:04:49 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 20 Aug 2024 09:04:49 GMT
Subject: RFR: 8298920: Improve microbenchmark build times
In-Reply-To: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
References: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
Message-ID: <71i_4CpJyt-cQlR6_vZRoZghvS8diEvZWp8U0j-l8D8=.054273d3-79d8-43d6-85f3-97246db8e120@github.com>

On Fri, 16 Aug 2024 12:24:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently incremental builds for the microbenchmarks may take notable amount of time, like:
> 
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
> Building target 'test' in configuration 'linux-x86_64-server-release'
> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
> Running Indify on microbenchmark classes
> [snip]
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp:tier1                                 0     0     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'linux-x86_64-server-release'
> 
> real    0m37,581s
> user    2m4,747s
> sys     0m7,223s
> 
> 
> The microbenchmark compilation is not using the `Depend` plugin that avoids recompilation of other files if the change files only contain minor changes (i.e. non-API changes). The patch here proposes to enhance the build to use the `Depend` plugin. The change that enables that is `CREATE_API_DIGEST := true,`, but since both the `Depend` plugin and JMH framework needs to be added to the classpath the patch re-organizes the code a little to properly augment the classpath.
> 
> With this patch, a build similar to the above might be:
> 
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
> Building target 'test' in configuration 'linux-x86_64-server-release'
> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
> Running Indify on microbenchmark classes
> [snip]
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp:tier1                                 0     0     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'linux-x86_64-server-release'
> 
> real    0m7,505s
> user    0m14,128s
> sys     0m3,158s

also interesting, but probably preexisting, and might be platform-specific (tested on Cygwin):
- compile benchmarks with `make test TEST=jaxp:tier1`
- edit `test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench.java`
- touch `test/micro/org/openjdk/bench/javax/crypto/full/BenchBase.java`
- compile again with `make test TEST=jaxp:tier1` - fails - cannot find CryptoBase
- touch `test/micro/org/openjdk/bench/javax/crypto/full/CryptoBase.java`
- run the modified benchmark with `make test TEST=micro:small.AESGCMBench` - succeeds, but uses the old AESGCMBench.class file

if you touch all 3 files at once (AESGCMBench, BenchBase, CryptoBase) and then make, the correct (new) file is used.

(I changed 128 to 129 in [this line](https://github.com/openjdk/jdk/blob/b9d49dcef22ab81a087d890bbac0329a5244a2ef/test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench.java#L45). With that change the benchmark throws an exception, so it's easy to check if the file was recompiled or not)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20616#issuecomment-2298348154

From prappo at openjdk.org  Tue Aug 20 09:10:56 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 20 Aug 2024 09:10:56 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
Message-ID: <MXhh7BptkSt56mS9c00G6g5ZxmSuhoMR0Lc9TVuQGp0=.34251420-7215-4987-917b-39151f50fad1@github.com>

On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>> 
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>> 
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>> 
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>> 
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace InputStreamReader with BufferedReader

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_pt_BR.properties line 95:

> 93: 
> 94: main.usage.summary=Uso: jar [OPTION...] [ [--release VERSION] [-C dir] files] ...
> 95: main.usage.summary.try=Tente `jar --ajuda' para obter mais informa??es.

I was looking for something unrelated in properties files, and found this. It is surprising to see an option name being localised; it must be a bug.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15694#discussion_r1722966688

From ihse at openjdk.org  Tue Aug 20 14:32:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 20 Aug 2024 14:32:53 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v12]
In-Reply-To: <cnkyJoEgKge8mJZ-VSzH5XXxoHh7WJLiBE2isMREd80=.fe84db13-5f3c-4bfb-abe6-0487ab9ae08b@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
 <cnkyJoEgKge8mJZ-VSzH5XXxoHh7WJLiBE2isMREd80=.fe84db13-5f3c-4bfb-abe6-0487ab9ae08b@github.com>
Message-ID: <C6IHtI8q9V141C59SjSIgoolfoA8uCEvEg4QBNPM3c4=.1a1e1fed-2e44-4d2a-b01a-aa74fac10caf@github.com>

On Mon, 19 Aug 2024 15:33:07 GMT, George Adams <gdams at openjdk.org> wrote:

>> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.
>
> George Adams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move EXCLUDED_PLATFORMS definition to the top of the job

Marked as reviewed by ihse (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20577#pullrequestreview-2248188407

From duke at openjdk.org  Tue Aug 20 14:36:50 2024
From: duke at openjdk.org (duke)
Date: Tue, 20 Aug 2024 14:36:50 GMT
Subject: RFR: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check
 [v12]
In-Reply-To: <cnkyJoEgKge8mJZ-VSzH5XXxoHh7WJLiBE2isMREd80=.fe84db13-5f3c-4bfb-abe6-0487ab9ae08b@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
 <cnkyJoEgKge8mJZ-VSzH5XXxoHh7WJLiBE2isMREd80=.fe84db13-5f3c-4bfb-abe6-0487ab9ae08b@github.com>
Message-ID: <c1KG9plMWXoXjaq-q_V2VoZ1OBOncycfROQKhD7Bu8w=.5758019d-8782-4315-aa50-834b8140616e@github.com>

On Mon, 19 Aug 2024 15:33:07 GMT, George Adams <gdams at openjdk.org> wrote:

>> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.
>
> George Adams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move EXCLUDED_PLATFORMS definition to the top of the job

@gdams 
Your change (at version a223d3c37c43fe46a71e6fe4ba52da321b631734) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20577#issuecomment-2299016979

From ihse at openjdk.org  Tue Aug 20 14:39:48 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 20 Aug 2024 14:39:48 GMT
Subject: RFR: 8298920: Improve microbenchmark build times
In-Reply-To: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
References: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
Message-ID: <yK1gWpwYwCwFtXhrfz2ZFaJvvcyowvEaCNZQL4mLMIs=.df3b78b4-d976-4606-9ed4-f37664ff6277@github.com>

On Fri, 16 Aug 2024 12:24:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently incremental builds for the microbenchmarks may take notable amount of time, like:
> 
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
> Building target 'test' in configuration 'linux-x86_64-server-release'
> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
> Running Indify on microbenchmark classes
> [snip]
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp:tier1                                 0     0     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'linux-x86_64-server-release'
> 
> real    0m37,581s
> user    2m4,747s
> sys     0m7,223s
> 
> 
> The microbenchmark compilation is not using the `Depend` plugin that avoids recompilation of other files if the change files only contain minor changes (i.e. non-API changes). The patch here proposes to enhance the build to use the `Depend` plugin. The change that enables that is `CREATE_API_DIGEST := true,`, but since both the `Depend` plugin and JMH framework needs to be added to the classpath the patch re-organizes the code a little to properly augment the classpath.
> 
> With this patch, a build similar to the above might be:
> 
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
> Building target 'test' in configuration 'linux-x86_64-server-release'
> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
> Running Indify on microbenchmark classes
> [snip]
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp:tier1                                 0     0     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'linux-x86_64-server-release'
> 
> real    0m7,505s
> user    0m14,128s
> sys     0m3,158s

The code build system changes look correct. However, it is worrying that @djelinski manages to find issues. I wonder if it is related to this change, or if it is some kind of edge case for the depend plugin that is not working correctly?

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20616#pullrequestreview-2248207077

From gdams at openjdk.org  Tue Aug 20 14:40:57 2024
From: gdams at openjdk.org (George Adams)
Date: Tue, 20 Aug 2024 14:40:57 GMT
Subject: Integrated: 8282944: GHA: Add Alpine Linux x86_64 pre-integration
 check
In-Reply-To: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
References: <JMxtnojacRUqyZsaC64j0Do5xGTqvJIAqwVYGRHs1-k=.ef993e46-f649-4764-ba3d-b3804310d92f@github.com>
Message-ID: <tz_TwKQhcG4vmgEwd9qjx3ilQYu_gQYfUqqO_zlPyj8=.29d17e35-871d-4650-8491-611b5bd677c2@github.com>

On Wed, 14 Aug 2024 08:52:44 GMT, George Adams <gdams at openjdk.org> wrote:

> Adds Alpine build CI job to the GitHub actions matrix. Currently this only builds hotspot. I can add tests too if people think that would be useful but for now I've left it as just build.

This pull request has now been integrated.

Changeset: bc2700b7
Author:    George Adams <gdams at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bc2700b7dc6039e2a17124a0ca32780383c4a43f
Stats:     153 lines in 4 files changed: 150 ins; 0 del; 3 mod

8282944: GHA: Add Alpine Linux x86_64 pre-integration check

Reviewed-by: ihse

-------------

PR: https://git.openjdk.org/jdk/pull/20577

From jlahoda at openjdk.org  Tue Aug 20 14:53:52 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 20 Aug 2024 14:53:52 GMT
Subject: RFR: 8298920: Improve microbenchmark build times
In-Reply-To: <71i_4CpJyt-cQlR6_vZRoZghvS8diEvZWp8U0j-l8D8=.054273d3-79d8-43d6-85f3-97246db8e120@github.com>
References: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
 <71i_4CpJyt-cQlR6_vZRoZghvS8diEvZWp8U0j-l8D8=.054273d3-79d8-43d6-85f3-97246db8e120@github.com>
Message-ID: <MOSuqy3k_rngbA9WGLPEP2OocsUr8mZ3xEaYfKI3S-c=.5e233bee-925b-4cf2-ad28-9329c77b1e5c@github.com>

On Tue, 20 Aug 2024 09:02:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Currently incremental builds for the microbenchmarks may take notable amount of time, like:
>> 
>> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
>> Building target 'test' in configuration 'linux-x86_64-server-release'
>> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
>> Running Indify on microbenchmark classes
>> [snip]
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jaxp:tier1                                 0     0     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> Finished building target 'test' in configuration 'linux-x86_64-server-release'
>> 
>> real    0m37,581s
>> user    2m4,747s
>> sys     0m7,223s
>> 
>> 
>> The microbenchmark compilation is not using the `Depend` plugin that avoids recompilation of other files if the change files only contain minor changes (i.e. non-API changes). The patch here proposes to enhance the build to use the `Depend` plugin. The change that enables that is `CREATE_API_DIGEST := true,`, but since both the `Depend` plugin and JMH framework needs to be added to the classpath the patch re-organizes the code a little to properly augment the classpath.
>> 
>> With this patch, a build similar to the above might be:
>> 
>> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
>> Building target 'test' in configuration 'linux-x86_64-server-release'
>> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
>> Running Indify on microbenchmark classes
>> [snip]
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jaxp:tier1                                 0     0     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> Finished building target 'test' in configuration 'linux-x86_64-server-release'
>> 
>> real    0m7,505s
>> user    0m14,128s
>> sys     0m3,158s
>
> also interesting, but probably preexisting, and might be platform-specific (tested on Cygwin):
> - compile benchmarks with `make test TEST=jaxp:tier1`
> - edit `test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench.java`
> - touch `test/micro/org/openjdk/bench/javax/crypto/full/BenchBase.java`
> - compile again with `make test TEST=jaxp:tier1` - fails - cannot find CryptoBase
> - touch `test/micro/org/openjdk/bench/javax/crypto/full/CryptoBase.java`
> - run the modified benchmark with `make test TEST=micro:small.AESGCMBench` - succeeds, but uses the old AESGCMBench.class file
> 
> if you touch all 3 files at once (AESGCMBench, BenchBase, CryptoBase) and then make, the correct (new) file is used.
> 
> (I changed 128 to 129 in [this line](https://github.com/openjdk/jdk/blob/b9d49dcef22ab81a087d890bbac0329a5244a2ef/test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench.java#L45). With that change the benchmark throws an exception, so it's easy to check if the file was recompiled or not)

@djelinski (and others), thanks for finding the problem, and I apologize for nor figuring this out myself. The problem is that when compiling (Java) named modules, if javac needs to read something from a classfile, it will (also) look into the output directory (besides system classes, etc.) So, the incremental build works, because any class that is necessary, but its compilation has been skipped, is load from output directory.

That is not the case when compiling code inside the unnamed module - javac will not, by itself, look into the output directory for classfiles. And the microbenchmarks are in the unnnamed module. So, when we skip compilation of e.g. `BenchBase`, there's no place where javac could read it from. The traditional way to solve this issue was to put the output directory to the classpath. I have an update for this patch that adds the output directory to the classpath, running tests on it now.

Sorry for not realizing/finding this myself.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20616#issuecomment-2299054321

From djelinski at openjdk.org  Tue Aug 20 15:09:49 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 20 Aug 2024 15:09:49 GMT
Subject: RFR: 8298920: Improve microbenchmark build times
In-Reply-To: <MOSuqy3k_rngbA9WGLPEP2OocsUr8mZ3xEaYfKI3S-c=.5e233bee-925b-4cf2-ad28-9329c77b1e5c@github.com>
References: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
 <71i_4CpJyt-cQlR6_vZRoZghvS8diEvZWp8U0j-l8D8=.054273d3-79d8-43d6-85f3-97246db8e120@github.com>
 <MOSuqy3k_rngbA9WGLPEP2OocsUr8mZ3xEaYfKI3S-c=.5e233bee-925b-4cf2-ad28-9329c77b1e5c@github.com>
Message-ID: <ifO2FCaykJqL-zYLIye0CbB5d9LAZwWOvvy6uJ03dsA=.db6f93bb-e038-4ccb-ba9a-09e7e4c1ec76@github.com>

On Tue, 20 Aug 2024 14:51:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> also interesting, but probably preexisting, and might be platform-specific (tested on Cygwin):
>> - compile benchmarks with `make test TEST=jaxp:tier1`
>> - edit `test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench.java`
>> - touch `test/micro/org/openjdk/bench/javax/crypto/full/BenchBase.java`
>> - compile again with `make test TEST=jaxp:tier1` - fails - cannot find CryptoBase
>> - touch `test/micro/org/openjdk/bench/javax/crypto/full/CryptoBase.java`
>> - run the modified benchmark with `make test TEST=micro:small.AESGCMBench` - succeeds, but uses the old AESGCMBench.class file
>> 
>> if you touch all 3 files at once (AESGCMBench, BenchBase, CryptoBase) and then make, the correct (new) file is used.
>> 
>> (I changed 128 to 129 in [this line](https://github.com/openjdk/jdk/blob/b9d49dcef22ab81a087d890bbac0329a5244a2ef/test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench.java#L45). With that change the benchmark throws an exception, so it's easy to check if the file was recompiled or not)
>
> @djelinski (and others), thanks for finding the problem, and I apologize for nor figuring this out myself. The problem is that when compiling (Java) named modules, if javac needs to read something from a classfile, it will (also) look into the output directory (besides system classes, etc.) So, the incremental build works, because any class that is necessary, but its compilation has been skipped, is load from output directory.
> 
> That is not the case when compiling code inside the unnamed module - javac will not, by itself, look into the output directory for classfiles. And the microbenchmarks are in the unnnamed module. So, when we skip compilation of e.g. `BenchBase`, there's no place where javac could read it from. The traditional way to solve this issue was to put the output directory to the classpath. I have an update for this patch that adds the output directory to the classpath, running tests on it now.
> 
> Sorry for not realizing/finding this myself.

@lahodaj no apologies necessary! I very much appreciate the effort you put into improving the build system. Thanks for making it better!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20616#issuecomment-2299092652

From naoto at openjdk.org  Tue Aug 20 15:30:58 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 Aug 2024 15:30:58 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <MXhh7BptkSt56mS9c00G6g5ZxmSuhoMR0Lc9TVuQGp0=.34251420-7215-4987-917b-39151f50fad1@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
 <MXhh7BptkSt56mS9c00G6g5ZxmSuhoMR0Lc9TVuQGp0=.34251420-7215-4987-917b-39151f50fad1@github.com>
Message-ID: <9wZvcGjRkpfRm02paHISi86ynU0aYrW9WoinmyIb-RM=.9795a780-b857-4de3-bca6-075305fbd9f7@github.com>

On Tue, 20 Aug 2024 09:07:54 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace InputStreamReader with BufferedReader
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_pt_BR.properties line 95:
> 
>> 93: 
>> 94: main.usage.summary=Uso: jar [OPTION...] [ [--release VERSION] [-C dir] files] ...
>> 95: main.usage.summary.try=Tente `jar --ajuda' para obter mais informa??es.
> 
> I was looking for something unrelated in properties files, and found this. It is surprising to see an option name being localised; it must be a bug.

Good catch, Pavel. It is indeed a bug. This type of overtranslation l10n bug happens all the time, and hard to catch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15694#discussion_r1723520963

From aph at openjdk.org  Tue Aug 20 16:30:50 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 20 Aug 2024 16:30:50 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v3]
In-Reply-To: <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com>
 <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
Message-ID: <Uw6F37UvlscZuuQOPHagKacPtc5uwTGs5JzXPzIXXBI=.71524f34-84b2-42e8-aff6-c471d20bf70e@github.com>

On Thu, 27 Jun 2024 22:03:37 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately. This enhancement adds the relevant files, enabling the rest of [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward.
>
> Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update README to include RISC-V

> Responding to the discussion in #18605 here as this is the PR actually adding SLEEF to the JDK source.
> 
> I was initially of the opinion that the solution already provided here was enough. We could potentially have added a Git hash in addition to the version/tag to more precisely and permanently identify the exact Sleef source we are depending on. At least a Git hash wouldn't change externally.
> 
> However, Andrew's arguments have swayed me. I now think we should add a more or less complete dump of the Sleef source into the JDK repository. I'm still open to trimming it down somewhat as long as the build steps we need to run to generate the headers we need, using the Sleef build system, are still functional. I'm basically agreeing with his suggestion but will spell it out in detail here for completeness in this PR.

Sounds good, thanks.

> We should then add a script that automatically performs the necessary build steps, using the Sleef official build system, to generate the headers we need, and outputs them into the JDK source tree, in the location where we will also commit those headers. This script should document what dependencies and configuration is necessary to run it, which will include cmake and possibly other things. Performing this step doesn't need to be completely streamlined, just reasonably possible to run. It's meant to be an import/verification step. With this solution I would recommend putting the script next to the Sleef source tree instead of in make/devkit/.
> 
> The normal JDK build will just use the committed pre-generated headers.
> 
> I looked briefly at the heroic build work provided by @fitzsim and while I admire the effort, I don't think this is the right way and we already dismissed this approach earlier. Not because I didn't think it was feasible to implement, but because of the future maintenance burden. The Sleef build is non trivial so we shouldn't try to replicate it in our build. The risk of our implementation diverging in the future is too great.

OK.

I had a brief meeting with Mark Reinhold to discuss this issue. I asked him if it would ever be acceptable to check in preprocessed code without the corresponding preferred from, and the immediate answer was an emphatic "no". So that's that.

I'm neutral on just how much of SLEEF should be checked into our source tree. As long as we include the full source for whatever subset of SLEEF we use, and it is the real source in its preferred form, I'm happy.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2299263306

From lucy at openjdk.org  Tue Aug 20 16:45:06 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Tue, 20 Aug 2024 16:45:06 GMT
Subject: RFR: 8336498: [macos] [build]: install-file macro may run into
 permission denied error
In-Reply-To: <dMqnljHWGtietpR7M7V0gcVxSb4gidHXTE2qJ0xVe5Y=.576e9b23-0345-425c-a106-d4ed938d5015@github.com>
References: <dMqnljHWGtietpR7M7V0gcVxSb4gidHXTE2qJ0xVe5Y=.576e9b23-0345-425c-a106-d4ed938d5015@github.com>
Message-ID: <4iLdwXiytWSKtl6hy_QFogx8eGnnkWZ8_p_40KdkhUk=.2e12d1cd-efc9-4a0c-9978-db983d0ce3e1@github.com>

On Tue, 16 Jul 2024 20:50:32 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> On MacOS, files may have extended attributes attached. These attributes are copied together with the files. To prevent issues during further processing, the extended attributes of the copies must be removed. This action was implemented as solution of an older bug.
> 
> The solution is incomplete because it does not handle files with read-only permissions correctly. Without write permission, matter cannot remove the extended attributes. The action is rejected with a "permission denied" error.
> 
> The issue is present in all releases. I reproduced it in 11, 17, ... 23, head
> 
> The solution is to "chmod u+w" only those files which need to have their extended attributes removed.
> 
> Backport note: in releases prior to jdk23, the change needs to go into file MakeBase.gmk.
> 
> Testing @SAP completed without any related issues.

Back from vacation, working through the pile of tasks...

@erikj79 An influence of the user environment, that is my suspicion as well (see above). 

I would go ahead an integrate tomorrow (Wednesday), if there is no veto.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20203#issuecomment-2299298418

From erikj at openjdk.org  Tue Aug 20 16:56:07 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 20 Aug 2024 16:56:07 GMT
Subject: RFR: 8336498: [macos] [build]: install-file macro may run into
 permission denied error
In-Reply-To: <dMqnljHWGtietpR7M7V0gcVxSb4gidHXTE2qJ0xVe5Y=.576e9b23-0345-425c-a106-d4ed938d5015@github.com>
References: <dMqnljHWGtietpR7M7V0gcVxSb4gidHXTE2qJ0xVe5Y=.576e9b23-0345-425c-a106-d4ed938d5015@github.com>
Message-ID: <LT2ToVokY4oeUEEBrMXsvYj9nP79VgSy8dzrraaaLmw=.236e974e-30b9-4af0-9847-27da272ae13a@github.com>

On Tue, 16 Jul 2024 20:50:32 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> On MacOS, files may have extended attributes attached. These attributes are copied together with the files. To prevent issues during further processing, the extended attributes of the copies must be removed. This action was implemented as solution of an older bug.
> 
> The solution is incomplete because it does not handle files with read-only permissions correctly. Without write permission, matter cannot remove the extended attributes. The action is rejected with a "permission denied" error.
> 
> The issue is present in all releases. I reproduced it in 11, 17, ... 23, head
> 
> The solution is to "chmod u+w" only those files which need to have their extended attributes removed.
> 
> Backport note: in releases prior to jdk23, the change needs to go into file MakeBase.gmk.
> 
> Testing @SAP completed without any related issues.

I'm still ok with this patch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20203#issuecomment-2299318585

From sgehwolf at openjdk.org  Tue Aug 20 19:04:47 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 20 Aug 2024 19:04:47 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v34]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <talFCAYOb2_aiCjAKkxq4i74T421fF6Wp08wA3zN5S0=.945756ad-5255-4f31-b30f-080c4dd9a772@github.com>

> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b
 eing modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.manage...

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 139 commits:

 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - JLinkDedupTestBatchSizeOne.java test fix
   
   Run only the packaged modules version if we have a linkable JDK runtime
   with packaged modules available as well in the JDK install.
 - Enable IncludeLocalesPluginTest
 - Enable GenerateJLIClassesPluginTest.java test
 - Enable JLinkReproducibleTest.java for linkable JDK images
 - Remove restriction on directory based modules
   
   Enable the following tests:
   - JLink100Modules.java
   - JLinkDedupTestBatchSizeOne.java
 - Comment fix in JRTArchive. Long line in JlinkTask
 - Comment fixes in ImageFileCreator
 - Comments and clean-up in JlinkTask
 - ... and 129 more: https://git.openjdk.org/jdk/compare/686eb233...7e2bc4e1

-------------

Changes: https://git.openjdk.org/jdk/pull/14787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=33
  Stats: 3959 lines in 42 files changed: 3762 ins; 117 del; 80 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

PR: https://git.openjdk.org/jdk/pull/14787

From jlahoda at openjdk.org  Wed Aug 21 06:15:43 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 21 Aug 2024 06:15:43 GMT
Subject: RFR: 8298920: Improve microbenchmark build times [v2]
In-Reply-To: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
References: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
Message-ID: <TSbYAJytqcykyy6wAwwTNstdiOGPOtcXk2wpp8L4ss0=.6d4d50e4-8d55-4342-a14e-b95a7a52ce62@github.com>

> Currently incremental builds for the microbenchmarks may take notable amount of time, like:
> 
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
> Building target 'test' in configuration 'linux-x86_64-server-release'
> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
> Running Indify on microbenchmark classes
> [snip]
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp:tier1                                 0     0     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'linux-x86_64-server-release'
> 
> real    0m37,581s
> user    2m4,747s
> sys     0m7,223s
> 
> 
> The microbenchmark compilation is not using the `Depend` plugin that avoids recompilation of other files if the change files only contain minor changes (i.e. non-API changes). The patch here proposes to enhance the build to use the `Depend` plugin. The change that enables that is `CREATE_API_DIGEST := true,`, but since both the `Depend` plugin and JMH framework needs to be added to the classpath the patch re-organizes the code a little to properly augment the classpath.
> 
> With this patch, a build similar to the above might be:
> 
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
> Building target 'test' in configuration 'linux-x86_64-server-release'
> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
> Running Indify on microbenchmark classes
> [snip]
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp:tier1                                 0     0     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'linux-x86_64-server-release'
> 
> real    0m7,505s
> user    0m14,128s
> sys     0m3,158s

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Fixing classpath for incremental microbenchmark build.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20616/files
  - new: https://git.openjdk.org/jdk/pull/20616/files/3f6875cb..f21c2b76

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20616&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20616&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20616.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20616/head:pull/20616

PR: https://git.openjdk.org/jdk/pull/20616

From lucy at openjdk.org  Wed Aug 21 08:26:11 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 21 Aug 2024 08:26:11 GMT
Subject: Integrated: 8336498: [macos] [build]: install-file macro may run into
 permission denied error
In-Reply-To: <dMqnljHWGtietpR7M7V0gcVxSb4gidHXTE2qJ0xVe5Y=.576e9b23-0345-425c-a106-d4ed938d5015@github.com>
References: <dMqnljHWGtietpR7M7V0gcVxSb4gidHXTE2qJ0xVe5Y=.576e9b23-0345-425c-a106-d4ed938d5015@github.com>
Message-ID: <RVdSNDFccDqDuTkk_LDQRloag2bB0SV8_R70wXntJsg=.7482bb19-c09e-453c-93b3-eb156c51fab1@github.com>

On Tue, 16 Jul 2024 20:50:32 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> On MacOS, files may have extended attributes attached. These attributes are copied together with the files. To prevent issues during further processing, the extended attributes of the copies must be removed. This action was implemented as solution of an older bug.
> 
> The solution is incomplete because it does not handle files with read-only permissions correctly. Without write permission, matter cannot remove the extended attributes. The action is rejected with a "permission denied" error.
> 
> The issue is present in all releases. I reproduced it in 11, 17, ... 23, head
> 
> The solution is to "chmod u+w" only those files which need to have their extended attributes removed.
> 
> Backport note: in releases prior to jdk23, the change needs to go into file MakeBase.gmk.
> 
> Testing @SAP completed without any related issues.

This pull request has now been integrated.

Changeset: 715fa8f9
Author:    Lutz Schmidt <lucy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/715fa8f9fe7242e86b985aece3d078b226f53fb9
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8336498: [macos] [build]: install-file macro may run into permission denied error

Reviewed-by: clanger, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/20203

From djelinski at openjdk.org  Wed Aug 21 08:28:05 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 21 Aug 2024 08:28:05 GMT
Subject: RFR: 8298920: Improve microbenchmark build times [v2]
In-Reply-To: <TSbYAJytqcykyy6wAwwTNstdiOGPOtcXk2wpp8L4ss0=.6d4d50e4-8d55-4342-a14e-b95a7a52ce62@github.com>
References: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
 <TSbYAJytqcykyy6wAwwTNstdiOGPOtcXk2wpp8L4ss0=.6d4d50e4-8d55-4342-a14e-b95a7a52ce62@github.com>
Message-ID: <4RpGC4LVYszA1hDbt2wIym9yrS6o4hKOmjMwIHipPe4=.7f9d496d-6c56-4f28-b3e9-b4c8dfa8d84c@github.com>

On Wed, 21 Aug 2024 06:15:43 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently incremental builds for the microbenchmarks may take notable amount of time, like:
>> 
>> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
>> Building target 'test' in configuration 'linux-x86_64-server-release'
>> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
>> Running Indify on microbenchmark classes
>> [snip]
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jaxp:tier1                                 0     0     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> Finished building target 'test' in configuration 'linux-x86_64-server-release'
>> 
>> real    0m37,581s
>> user    2m4,747s
>> sys     0m7,223s
>> 
>> 
>> The microbenchmark compilation is not using the `Depend` plugin that avoids recompilation of other files if the change files only contain minor changes (i.e. non-API changes). The patch here proposes to enhance the build to use the `Depend` plugin. The change that enables that is `CREATE_API_DIGEST := true,`, but since both the `Depend` plugin and JMH framework needs to be added to the classpath the patch re-organizes the code a little to properly augment the classpath.
>> 
>> With this patch, a build similar to the above might be:
>> 
>> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
>> Building target 'test' in configuration 'linux-x86_64-server-release'
>> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
>> Running Indify on microbenchmark classes
>> [snip]
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jaxp:tier1                                 0     0     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> Finished building target 'test' in configuration 'linux-x86_64-server-release'
>> 
>> real    0m7,505s
>> user    0m14,128s
>> sys     0m3,158s
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing classpath for incremental microbenchmark build.

Works fine now. Thanks again!

-------------

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20616#pullrequestreview-2250135772

From ihse at openjdk.org  Wed Aug 21 09:16:11 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Aug 2024 09:16:11 GMT
Subject: RFR: 8298920: Improve microbenchmark build times [v2]
In-Reply-To: <TSbYAJytqcykyy6wAwwTNstdiOGPOtcXk2wpp8L4ss0=.6d4d50e4-8d55-4342-a14e-b95a7a52ce62@github.com>
References: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
 <TSbYAJytqcykyy6wAwwTNstdiOGPOtcXk2wpp8L4ss0=.6d4d50e4-8d55-4342-a14e-b95a7a52ce62@github.com>
Message-ID: <X023c2euINe2m2hRo-w7syW3Hf7ku6wlFL7_1oRvRjI=.8bf85b38-959f-404d-a4f2-7a6b612d41cd@github.com>

On Wed, 21 Aug 2024 06:15:43 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently incremental builds for the microbenchmarks may take notable amount of time, like:
>> 
>> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
>> Building target 'test' in configuration 'linux-x86_64-server-release'
>> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
>> Running Indify on microbenchmark classes
>> [snip]
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jaxp:tier1                                 0     0     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> Finished building target 'test' in configuration 'linux-x86_64-server-release'
>> 
>> real    0m37,581s
>> user    2m4,747s
>> sys     0m7,223s
>> 
>> 
>> The microbenchmark compilation is not using the `Depend` plugin that avoids recompilation of other files if the change files only contain minor changes (i.e. non-API changes). The patch here proposes to enhance the build to use the `Depend` plugin. The change that enables that is `CREATE_API_DIGEST := true,`, but since both the `Depend` plugin and JMH framework needs to be added to the classpath the patch re-organizes the code a little to properly augment the classpath.
>> 
>> With this patch, a build similar to the above might be:
>> 
>> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
>> Building target 'test' in configuration 'linux-x86_64-server-release'
>> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
>> Running Indify on microbenchmark classes
>> [snip]
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jaxp:tier1                                 0     0     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> Finished building target 'test' in configuration 'linux-x86_64-server-release'
>> 
>> real    0m7,505s
>> user    0m14,128s
>> sys     0m3,158s
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing classpath for incremental microbenchmark build.

make/common/JavaCompilation.gmk line 297:

> 295: 
> 296:     $1_EXTRA_DEPS := $$(BUILDTOOLS_OUTPUTDIR)/depend/_the.COMPILE_DEPEND_batch
> 297:     $1_AUGMENTED_CLASSPATH += $$(BUILDTOOLS_OUTPUTDIR)/depend

I think it would be better if you added `$$($1_BIN)` to the classpath whenever CREATE_API_DIGEST is true, rather than hard-coding it in the case of the microbenchmarks. 

Maybe you can also add a couple of lines of comments explaining the rationale, if you can make it succinct enough.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20616#discussion_r1724720149

From jlahoda at openjdk.org  Wed Aug 21 11:21:34 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 21 Aug 2024 11:21:34 GMT
Subject: RFR: 8298920: Improve microbenchmark build times [v3]
In-Reply-To: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
References: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
Message-ID: <3NfZ6PvTmQmZwfPgNIyUWoaA-xyFo0pMnwx9W8xAQ7I=.3f886aa4-9584-4fc5-9921-e205f1daf4f0@github.com>

> Currently incremental builds for the microbenchmarks may take notable amount of time, like:
> 
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
> Building target 'test' in configuration 'linux-x86_64-server-release'
> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
> Running Indify on microbenchmark classes
> [snip]
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp:tier1                                 0     0     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'linux-x86_64-server-release'
> 
> real    0m37,581s
> user    2m4,747s
> sys     0m7,223s
> 
> 
> The microbenchmark compilation is not using the `Depend` plugin that avoids recompilation of other files if the change files only contain minor changes (i.e. non-API changes). The patch here proposes to enhance the build to use the `Depend` plugin. The change that enables that is `CREATE_API_DIGEST := true,`, but since both the `Depend` plugin and JMH framework needs to be added to the classpath the patch re-organizes the code a little to properly augment the classpath.
> 
> With this patch, a build similar to the above might be:
> 
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
> Building target 'test' in configuration 'linux-x86_64-server-release'
> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
> Running Indify on microbenchmark classes
> [snip]
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp:tier1                                 0     0     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'linux-x86_64-server-release'
> 
> real    0m7,505s
> user    0m14,128s
> sys     0m3,158s

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20616/files
  - new: https://git.openjdk.org/jdk/pull/20616/files/f21c2b76..7eefc210

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20616&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20616&range=01-02

  Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20616.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20616/head:pull/20616

PR: https://git.openjdk.org/jdk/pull/20616

From rkennke at openjdk.org  Wed Aug 21 11:48:26 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 21 Aug 2024 11:48:26 GMT
Subject: RFR: 8305895: Implementation: JEP 450: Compact Object Headers
 (Experimental)
Message-ID: <GADoH3CbLaJymFNWVrLgOAi7CCXB7qRiQQvhbGMnqvA=.519ae324-cf9f-4d87-9bba-b2b1eb6f2526@github.com>

This is the main body of the JEP 450: Compact Object Headers (Experimental).

Main changes:
 - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
 - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are building on #20603 and #20605 to protect the relevant (upper 32) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
 - The identity hash-code is temporarily narrowed to 25 bits. As soon as we get Tiny Class-Pointers (planned before the JEP can be integrated, and to be opened for review soon), we will widen the hash-bits back to 31 bits.
 - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
 - Arrays will can now store their length at offset 8.
 - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archives are generated, next to the _nocoops variant.
 - Note that oopDesc::klass_offset_in_bytes() is not used by +UCOH paths anymore. The only exception is C2, which uses it as a placeholder/identifier of the special memory slice that only LoadNKlass uses. The backend then extracts the original oop and loads its mark-word and extracts the narrow-Klass* from that. I played with other approaches to implement LoadNKlass. Expanding it as a macro did not easily work, because C2 is missing a way to cast a word-sized integral to a narrow-Klass* (or at least I could not find it), and also I fear that doing so could mess with optimizations. This may be useful to revisit. OTOH, the approach that I have taken works and is similar to DecodeNKlass and similar instructions.

Testing:
 (+UseCompactObjectHeaders tests are run with the flag hard-patched into the build, to also catch @flagless tests.)
The below testing has been run many times, but not with this exact base version of the JDK. I want to hold off the full testing until we also have the Tiny Class-Pointers PR lined-up, and test with that.

 - [x] tier1 (x86_64)
 - [ ] tier2 (x86_64)
 - [ ] tier3 (x86_64)
 - [ ] tier4 (x86_64)
 - [x] tier1 (aarch64)
 - [ ] tier2 (aarch64)
 - [ ] tier3 (aarch64)
 - [ ] tier4 (aarch64)
 - [x] tier1 (x86_64) +UseCompactObjectHeaders
 - [ ] tier2 (x86_64) +UseCompactObjectHeaders
 - [ ] tier3 (x86_64) +UseCompactObjectHeaders
 - [ ] tier4 (x86_64) +UseCompactObjectHeaders
 - [x] tier1 (aarch64) +UseCompactObjectHeaders
 - [ ] tier2 (aarch64) +UseCompactObjectHeaders
 - [ ] tier3 (aarch64) +UseCompactObjectHeaders
 - [ ] tier4 (aarch64) +UseCompactObjectHeaders
 - [x] Running as a backport in production since >1 year.

-------------

Depends on: https://git.openjdk.org/jdk/pull/20605

Commit messages:
 - 8305894: Implementation: JEP 450: Compact Object Headers (Experimental)

Changes: https://git.openjdk.org/jdk/pull/20640/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20640&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305895
  Stats: 1668 lines in 104 files changed: 1232 ins; 206 del; 230 mod
  Patch: https://git.openjdk.org/jdk/pull/20640.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20640/head:pull/20640

PR: https://git.openjdk.org/jdk/pull/20640

From aph at openjdk.org  Wed Aug 21 12:27:05 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 21 Aug 2024 12:27:05 GMT
Subject: RFR: 8305895: Implementation: JEP 450: Compact Object Headers
 (Experimental)
In-Reply-To: <GADoH3CbLaJymFNWVrLgOAi7CCXB7qRiQQvhbGMnqvA=.519ae324-cf9f-4d87-9bba-b2b1eb6f2526@github.com>
References: <GADoH3CbLaJymFNWVrLgOAi7CCXB7qRiQQvhbGMnqvA=.519ae324-cf9f-4d87-9bba-b2b1eb6f2526@github.com>
Message-ID: <h07bQf788sDf4Cz_-ZWKDu7YmyGBoOClveek11i5-5I=.40fbb021-60bf-4e9f-b24a-377a6a65eb33@github.com>

On Tue, 20 Aug 2024 10:07:26 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are building on #20603 and #20605 to protect the relevant (upper 32) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - The identity hash-code is temporarily narrowed to 25 bits. As soon as we get Tiny Class-Pointers (planned before the JEP can be integrated, and to be opened for review soon), we will widen the hash-bits back to 31 bits.
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will can now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archives are generated, next to the _nocoops variant.
>  - Note that oopDesc::klass_offset_in_bytes() is not used by +UCOH paths anymore. The only exception is C2, which uses it as a placeholder/identifier of the special memory slice that only LoadNKlass uses. The backend then extracts the original oop and loads its mark-word and extracts the narrow-Klass* from that. I played with other approaches to implement LoadNKlass. Expanding it as a macro did not easily work, because C2 is missing a way to cast a word-sized integral to a narrow-Klass* (o...

src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp line 184:

> 182:   } else {
> 183:     // This assumes that all prototype bits fit in an int32_t
> 184:     mov(t1, (int32_t)(intptr_t)markWord::prototype().value());

Suggestion:

    mov(t1, checked_cast<int32_t>((intptr_t)markWord::prototype().value()));

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20640#discussion_r1724960170

From ihse at openjdk.org  Wed Aug 21 12:34:37 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Aug 2024 12:34:37 GMT
Subject: RFR: 8338290: Xcode project generator for hotspot
Message-ID: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>

Add a make target to generate an Xcode project file for Hotspot. 

This PR is the result of a cooperation between me and @gerard-ziemski. Gerard developed the original Xcode generator (as a stand-alone project in https://github.com/gerard-ziemski/xcode), and I have written the build system "glue" to integrate it, and refactored the code to modern JDK standards.

Usage: Run `make hotspot-xcode-project`, and an Xcode project file will be generated in `build/$BUILD/xcode`. You can also have this automatically opened in Xcode by `make open-hotspot-xcode-project` (but note that for repeated runs of this, `make open-hotspot-xcode-project-only` is greatly preferred).

-------------

Commit messages:
 - Remove inadvertent tab (fixes jcheck complaint)
 - Move copying of helper scripts to makefile, and chmod them +x
 - 8007737: Xcode generator project for hotspot

Changes: https://git.openjdk.org/jdk/pull/20564/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20564&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338290
  Stats: 1776 lines in 14 files changed: 1762 ins; 5 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/20564.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20564/head:pull/20564

PR: https://git.openjdk.org/jdk/pull/20564

From azafari at openjdk.org  Wed Aug 21 12:34:37 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 21 Aug 2024 12:34:37 GMT
Subject: RFR: 8338290: Xcode project generator for hotspot
In-Reply-To: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>
References: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>
Message-ID: <Hzby-P_zb1JmqV9qmefz2prJXcVYewWhoCV2rnJBuIg=.bb0b3a76-e508-4b51-a998-53e2d78e0b9e@github.com>

On Tue, 13 Aug 2024 09:57:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Add a make target to generate an Xcode project file for Hotspot. 
> 
> This PR is the result of a cooperation between me and @gerard-ziemski. Gerard developed the original Xcode generator (as a stand-alone project in https://github.com/gerard-ziemski/xcode), and I have written the build system "glue" to integrate it, and refactored the code to modern JDK standards.
> 
> Usage: Run `make hotspot-xcode-project`, and an Xcode project file will be generated in `build/$BUILD/xcode`. You can also have this automatically opened in Xcode by `make open-hotspot-xcode-project` (but note that for repeated runs of this, `make open-hotspot-xcode-project-only` is greatly preferred).

Thanks for this great work.
IIRC, the copyright year for new files should show only the current year (2024) and does not include any earlier years. Correct?
The new files in this PR all have pair of years for new files. I think this is not the correct style.

Thank you for this useful feature. Creating the Xcode project and opening it work well.
Is there any help/doc for building JVM with XCode? I got this after opening the project in XCode and the first build try:
`Command PhaseScriptExecution failed with a nonzero exit code`

-------------

PR Review: https://git.openjdk.org/jdk/pull/20564#pullrequestreview-2250430729
PR Comment: https://git.openjdk.org/jdk/pull/20564#issuecomment-2288765201

From ihse at openjdk.org  Wed Aug 21 12:34:37 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Aug 2024 12:34:37 GMT
Subject: RFR: 8338290: Xcode project generator for hotspot
In-Reply-To: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>
References: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>
Message-ID: <43tgMF2DPAE3xwLU4PLMe7sSuRNqyT1plSODWqEOavY=.2084a5cb-cda8-4f06-8407-2c2ad947f96c@github.com>

On Tue, 13 Aug 2024 09:57:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Add a make target to generate an Xcode project file for Hotspot. 
> 
> This PR is the result of a cooperation between me and @gerard-ziemski. Gerard developed the original Xcode generator (as a stand-alone project in https://github.com/gerard-ziemski/xcode), and I have written the build system "glue" to integrate it, and refactored the code to modern JDK standards.
> 
> Usage: Run `make hotspot-xcode-project`, and an Xcode project file will be generated in `build/$BUILD/xcode`. You can also have this automatically opened in Xcode by `make open-hotspot-xcode-project` (but note that for repeated runs of this, `make open-hotspot-xcode-project-only` is greatly preferred).

A note for reviewers: The original stand-alone project maker had to reconstruct a lot of data internally, that can now be made more easily available due to the integration in the build system. We have converted the most essential parts to use data from the build system, but more improvements can be made. View this as the first step, not the last, for this project generator.

The problem Afshin encountered have been identified and fixed, and he has verified the fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20564#issuecomment-2285863712
PR Comment: https://git.openjdk.org/jdk/pull/20564#issuecomment-2301700113

From gziemski at openjdk.org  Wed Aug 21 12:34:37 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 21 Aug 2024 12:34:37 GMT
Subject: RFR: 8338290: Xcode project generator for hotspot
In-Reply-To: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>
References: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>
Message-ID: <Q5UlKG2sBAKlEBQmb2flwQKQMo7qgBlaGSse2AtxcYQ=.f63aee3d-9925-4636-87ff-c34335d5854a@github.com>

On Tue, 13 Aug 2024 09:57:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Add a make target to generate an Xcode project file for Hotspot. 
> 
> This PR is the result of a cooperation between me and @gerard-ziemski. Gerard developed the original Xcode generator (as a stand-alone project in https://github.com/gerard-ziemski/xcode), and I have written the build system "glue" to integrate it, and refactored the code to modern JDK standards.
> 
> Usage: Run `make hotspot-xcode-project`, and an Xcode project file will be generated in `build/$BUILD/xcode`. You can also have this automatically opened in Xcode by `make open-hotspot-xcode-project` (but note that for repeated runs of this, `make open-hotspot-xcode-project-only` is greatly preferred).

A note for reviewers: I have been personally using this for 7 years with minimum fixes or any upgrades required. The generator code creates Xcode project, which I reverse engineered. At the time that I was developing it, there were not any great options for automatic generation of Xcode projects, so I wrote my own, hoping that the internal details of the Xcode project will not change. This has proven to be the case so far.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20564#issuecomment-2286520226

From gziemski at openjdk.org  Wed Aug 21 12:34:37 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 21 Aug 2024 12:34:37 GMT
Subject: RFR: 8338290: Xcode project generator for hotspot
In-Reply-To: <Hzby-P_zb1JmqV9qmefz2prJXcVYewWhoCV2rnJBuIg=.bb0b3a76-e508-4b51-a998-53e2d78e0b9e@github.com>
References: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>
 <Hzby-P_zb1JmqV9qmefz2prJXcVYewWhoCV2rnJBuIg=.bb0b3a76-e508-4b51-a998-53e2d78e0b9e@github.com>
Message-ID: <3AduotT28xnVYcEryQeMceVj-xPd_D6niqKWiHY7-tg=.eef9ff3d-169b-45f2-8022-2dcdacaa970c@github.com>

On Wed, 14 Aug 2024 13:33:39 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> Thank you for this useful feature. Creating the Xcode project and opening it work well. Is there any help/doc for building JVM with XCode? I got this after opening the project in XCode and the first build try: `Command PhaseScriptExecution failed with a nonzero exit code`

Thank you for trying it. I will DM you on this to see if we can figure it out.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20564#issuecomment-2289692769

From ihse at openjdk.org  Wed Aug 21 12:34:37 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Aug 2024 12:34:37 GMT
Subject: RFR: 8338290: Xcode project generator for hotspot
In-Reply-To: <Hzby-P_zb1JmqV9qmefz2prJXcVYewWhoCV2rnJBuIg=.bb0b3a76-e508-4b51-a998-53e2d78e0b9e@github.com>
References: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>
 <Hzby-P_zb1JmqV9qmefz2prJXcVYewWhoCV2rnJBuIg=.bb0b3a76-e508-4b51-a998-53e2d78e0b9e@github.com>
Message-ID: <Kq9Qz8FByd5i6zLjygHl_Rzdopwz6cw4aMLcjEDF8vQ=.ad58f93e-8209-4a7e-84c4-4930080a1957@github.com>

On Wed, 21 Aug 2024 10:34:18 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> IIRC, the copyright year for new files should show only the current year (2024) and does not include any earlier years. 

The patch has been in development for several year. I thought all years should be included in such a case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20564#issuecomment-2301927533

From erikj at openjdk.org  Wed Aug 21 12:51:03 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 21 Aug 2024 12:51:03 GMT
Subject: RFR: 8298920: Improve microbenchmark build times [v3]
In-Reply-To: <3NfZ6PvTmQmZwfPgNIyUWoaA-xyFo0pMnwx9W8xAQ7I=.3f886aa4-9584-4fc5-9921-e205f1daf4f0@github.com>
References: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
 <3NfZ6PvTmQmZwfPgNIyUWoaA-xyFo0pMnwx9W8xAQ7I=.3f886aa4-9584-4fc5-9921-e205f1daf4f0@github.com>
Message-ID: <VCmdtu6OKnzVfCPZKGDYUFaUJhtEZIz88mI8L6YPazo=.240c5ff5-9917-4059-af42-de6f1b8cb42a@github.com>

On Wed, 21 Aug 2024 11:21:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently incremental builds for the microbenchmarks may take notable amount of time, like:
>> 
>> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
>> Building target 'test' in configuration 'linux-x86_64-server-release'
>> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
>> Running Indify on microbenchmark classes
>> [snip]
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jaxp:tier1                                 0     0     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> Finished building target 'test' in configuration 'linux-x86_64-server-release'
>> 
>> real    0m37,581s
>> user    2m4,747s
>> sys     0m7,223s
>> 
>> 
>> The microbenchmark compilation is not using the `Depend` plugin that avoids recompilation of other files if the change files only contain minor changes (i.e. non-API changes). The patch here proposes to enhance the build to use the `Depend` plugin. The change that enables that is `CREATE_API_DIGEST := true,`, but since both the `Depend` plugin and JMH framework needs to be added to the classpath the patch re-organizes the code a little to properly augment the classpath.
>> 
>> With this patch, a build similar to the above might be:
>> 
>> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
>> Building target 'test' in configuration 'linux-x86_64-server-release'
>> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
>> Running Indify on microbenchmark classes
>> [snip]
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jaxp:tier1                                 0     0     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> Finished building target 'test' in configuration 'linux-x86_64-server-release'
>> 
>> real    0m7,505s
>> user    0m14,128s
>> sys     0m3,158s
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20616#pullrequestreview-2250709849

From aph at openjdk.org  Wed Aug 21 13:11:05 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 21 Aug 2024 13:11:05 GMT
Subject: RFR: 8305895: Implementation: JEP 450: Compact Object Headers
 (Experimental)
In-Reply-To: <GADoH3CbLaJymFNWVrLgOAi7CCXB7qRiQQvhbGMnqvA=.519ae324-cf9f-4d87-9bba-b2b1eb6f2526@github.com>
References: <GADoH3CbLaJymFNWVrLgOAi7CCXB7qRiQQvhbGMnqvA=.519ae324-cf9f-4d87-9bba-b2b1eb6f2526@github.com>
Message-ID: <1JS96-UJBR95NbAe79ETt1c7aJ3vH9-cijwG24ufs0E=.537b0a80-aedd-4b25-9605-264a2f7f60fb@github.com>

On Tue, 20 Aug 2024 10:07:26 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are building on #20603 and #20605 to protect the relevant (upper 32) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - The identity hash-code is temporarily narrowed to 25 bits. As soon as we get Tiny Class-Pointers (planned before the JEP can be integrated, and to be opened for review soon), we will widen the hash-bits back to 31 bits.
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will can now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archives are generated, next to the _nocoops variant.
>  - Note that oopDesc::klass_offset_in_bytes() is not used by +UCOH paths anymore. The only exception is C2, which uses it as a placeholder/identifier of the special memory slice that only LoadNKlass uses. The backend then extracts the original oop and loads its mark-word and extracts the narrow-Klass* from that. I played with other approaches to implement LoadNKlass. Expanding it as a macro did not easily work, because C2 is missing a way to cast a word-sized integral to a narrow-Klass* (o...

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 2575:

> 2573:   } else {
> 2574:     lea(dst, Address(obj, index, Address::lsl(scale)));
> 2575:     ldr(dst, Address(dst, offset));

Suggestion:

    ldr(dst, Address(dst, index, Address::lsl(scale)));

Will this work? Or is dst unaligned?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20640#discussion_r1725025276

From erikj at openjdk.org  Wed Aug 21 13:16:04 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 21 Aug 2024 13:16:04 GMT
Subject: RFR: 8338290: Xcode project generator for hotspot
In-Reply-To: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>
References: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>
Message-ID: <oY2d5pMtTBnKQeGO8ODfb2cufpiXVo2vrylj1xdtlLM=.9bb615a7-91ae-4448-ae9d-79d4db5b9ed1@github.com>

On Tue, 13 Aug 2024 09:57:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Add a make target to generate an Xcode project file for Hotspot. 
> 
> This PR is the result of a cooperation between me and @gerard-ziemski. Gerard developed the original Xcode generator (as a stand-alone project in https://github.com/gerard-ziemski/xcode), and I have written the build system "glue" to integrate it, and refactored the code to modern JDK standards.
> 
> Usage: Run `make hotspot-xcode-project`, and an Xcode project file will be generated in `build/$BUILD/xcode`. You can also have this automatically opened in Xcode by `make open-hotspot-xcode-project` (but note that for repeated runs of this, `make open-hotspot-xcode-project-only` is greatly preferred).

Build system changes look fine overall. Left a couple of nit questions.

make/common/native/Link.gmk line 203:

> 201: 
> 202:   # This is for IDE integration purposes only, and is not normally generated
> 203:   $1_LD_JSON := $$(MAKESUPPORT_OUTPUTDIR)/compile-commands/$$($1_NAME)-ldflags.txt

Should this be called `JSON` if it's not actually a json file? In the other file it's referenced as a LINKER_FLAGS_FILE.

make/ide/xcode/hotspot/CreateXcodeProject.gmk line 40:

> 38: 
> 39:   PROJECT_MAKER_DIR := $(TOPDIR)/make/ide/xcode/hotspot
> 40:   TOOLS_OUTPUTDIR := $(MAKESUPPORT_OUTPUTDIR)/ide/xcode

I would have expected this to go in `$(BUILDTOOLS_OUTPUTDIR)`. Not that it matters that much. It only really affects which clean target removes what.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20564#pullrequestreview-2250744799
PR Review Comment: https://git.openjdk.org/jdk/pull/20564#discussion_r1725016281
PR Review Comment: https://git.openjdk.org/jdk/pull/20564#discussion_r1725021741

From ihse at openjdk.org  Wed Aug 21 13:20:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Aug 2024 13:20:03 GMT
Subject: RFR: 8338290: Xcode project generator for hotspot
In-Reply-To: <oY2d5pMtTBnKQeGO8ODfb2cufpiXVo2vrylj1xdtlLM=.9bb615a7-91ae-4448-ae9d-79d4db5b9ed1@github.com>
References: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>
 <oY2d5pMtTBnKQeGO8ODfb2cufpiXVo2vrylj1xdtlLM=.9bb615a7-91ae-4448-ae9d-79d4db5b9ed1@github.com>
Message-ID: <rJrL7DKjyF1KG3XxrMas76-WhgETPhS29DY5KEWEJC0=.9b64198a-ffb0-4726-b6ea-456f1d0937b0@github.com>

On Wed, 21 Aug 2024 13:02:23 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Add a make target to generate an Xcode project file for Hotspot. 
>> 
>> This PR is the result of a cooperation between me and @gerard-ziemski. Gerard developed the original Xcode generator (as a stand-alone project in https://github.com/gerard-ziemski/xcode), and I have written the build system "glue" to integrate it, and refactored the code to modern JDK standards.
>> 
>> Usage: Run `make hotspot-xcode-project`, and an Xcode project file will be generated in `build/$BUILD/xcode`. You can also have this automatically opened in Xcode by `make open-hotspot-xcode-project` (but note that for repeated runs of this, `make open-hotspot-xcode-project-only` is greatly preferred).
>
> make/common/native/Link.gmk line 203:
> 
>> 201: 
>> 202:   # This is for IDE integration purposes only, and is not normally generated
>> 203:   $1_LD_JSON := $$(MAKESUPPORT_OUTPUTDIR)/compile-commands/$$($1_NAME)-ldflags.txt
> 
> Should this be called `JSON` if it's not actually a json file? In the other file it's referenced as a LINKER_FLAGS_FILE.

Good catch, thanks. Too much copy/paste.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20564#discussion_r1725039988

From rkennke at openjdk.org  Wed Aug 21 13:21:04 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 21 Aug 2024 13:21:04 GMT
Subject: RFR: 8305895: Implementation: JEP 450: Compact Object Headers
 (Experimental)
In-Reply-To: <1JS96-UJBR95NbAe79ETt1c7aJ3vH9-cijwG24ufs0E=.537b0a80-aedd-4b25-9605-264a2f7f60fb@github.com>
References: <GADoH3CbLaJymFNWVrLgOAi7CCXB7qRiQQvhbGMnqvA=.519ae324-cf9f-4d87-9bba-b2b1eb6f2526@github.com>
 <1JS96-UJBR95NbAe79ETt1c7aJ3vH9-cijwG24ufs0E=.537b0a80-aedd-4b25-9605-264a2f7f60fb@github.com>
Message-ID: <YpCBkv4hvZzmvq4x9FFI6b-Qw_4FT8nEnVylCHREuPw=.34d957a9-c581-4211-8cbe-5213f88d9e18@github.com>

On Wed, 21 Aug 2024 13:08:23 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are building on #20603 and #20605 to protect the relevant (upper 32) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - The identity hash-code is temporarily narrowed to 25 bits. As soon as we get Tiny Class-Pointers (planned before the JEP can be integrated, and to be opened for review soon), we will widen the hash-bits back to 31 bits.
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will can now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archives are generated, next to the _nocoops variant.
>>  - Note that oopDesc::klass_offset_in_bytes() is not used by +UCOH paths anymore. The only exception is C2, which uses it as a placeholder/identifier of the special memory slice that only LoadNKlass uses. The backend then extracts the original oop and loads its mark-word and extracts the narrow-Klass* from that. I played with other approaches to implement LoadNKlass. Expanding it as a macro did not easily work, because C2 is missing a way to cast a word-sized integral t...
>
> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 2575:
> 
>> 2573:   } else {
>> 2574:     lea(dst, Address(obj, index, Address::lsl(scale)));
>> 2575:     ldr(dst, Address(dst, offset));
> 
> Suggestion:
> 
>     ldr(dst, Address(dst, index, Address::lsl(scale)));
> 
> Will this work? Or is dst unaligned?

It ignores the offset, right? Or are you saying that offset must be 0 on that path?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20640#discussion_r1725040269

From ihse at openjdk.org  Wed Aug 21 13:25:06 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Aug 2024 13:25:06 GMT
Subject: RFR: 8338290: Xcode project generator for hotspot
In-Reply-To: <oY2d5pMtTBnKQeGO8ODfb2cufpiXVo2vrylj1xdtlLM=.9bb615a7-91ae-4448-ae9d-79d4db5b9ed1@github.com>
References: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>
 <oY2d5pMtTBnKQeGO8ODfb2cufpiXVo2vrylj1xdtlLM=.9bb615a7-91ae-4448-ae9d-79d4db5b9ed1@github.com>
Message-ID: <BAytfWziq4I-L1ufZMv1W8HREHoCyuUuvdwpoxtVkec=.4e4f22ac-c5ef-4da4-9f8e-013c74409c29@github.com>

On Wed, 21 Aug 2024 13:06:00 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Add a make target to generate an Xcode project file for Hotspot. 
>> 
>> This PR is the result of a cooperation between me and @gerard-ziemski. Gerard developed the original Xcode generator (as a stand-alone project in https://github.com/gerard-ziemski/xcode), and I have written the build system "glue" to integrate it, and refactored the code to modern JDK standards.
>> 
>> Usage: Run `make hotspot-xcode-project`, and an Xcode project file will be generated in `build/$BUILD/xcode`. You can also have this automatically opened in Xcode by `make open-hotspot-xcode-project` (but note that for repeated runs of this, `make open-hotspot-xcode-project-only` is greatly preferred).
>
> make/ide/xcode/hotspot/CreateXcodeProject.gmk line 40:
> 
>> 38: 
>> 39:   PROJECT_MAKER_DIR := $(TOPDIR)/make/ide/xcode/hotspot
>> 40:   TOOLS_OUTPUTDIR := $(MAKESUPPORT_OUTPUTDIR)/ide/xcode
> 
> I would have expected this to go in `$(BUILDTOOLS_OUTPUTDIR)`. Not that it matters that much. It only really affects which clean target removes what.

For me, buildtools means "binaries we create to help with the build of the product" (basically specialized compilers).

Generating an IDE project is a different kind of story. Given your question, I checked what the Visual Studio java tool did. It created it's output in `$(HOTSPOT_OUTPUTDIR)/support/ide_classes`. That's not really better. (I think it should go to `$(MAKESUPPORT_OUTPUTDIR)/ide/visualstudio`.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20564#discussion_r1725046796

From ihse at openjdk.org  Wed Aug 21 13:33:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Aug 2024 13:33:56 GMT
Subject: RFR: 8338290: Xcode project generator for hotspot [v2]
In-Reply-To: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>
References: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>
Message-ID: <_yTSfzWJTNCdC3_uiyihET_e_0Arw9_dNv0VErZ7cms=.8b3ca9ac-b03f-4778-9b45-550042765019@github.com>

> Add a make target to generate an Xcode project file for Hotspot. 
> 
> This PR is the result of a cooperation between me and @gerard-ziemski. Gerard developed the original Xcode generator (as a stand-alone project in https://github.com/gerard-ziemski/xcode), and I have written the build system "glue" to integrate it, and refactored the code to modern JDK standards.
> 
> Usage: Run `make hotspot-xcode-project`, and an Xcode project file will be generated in `build/$BUILD/xcode`. You can also have this automatically opened in Xcode by `make open-hotspot-xcode-project` (but note that for repeated runs of this, `make open-hotspot-xcode-project-only` is greatly preferred).

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Update vs project generator for consistency

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20564/files
  - new: https://git.openjdk.org/jdk/pull/20564/files/d0514e5a..64b3ae19

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20564&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20564&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20564.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20564/head:pull/20564

PR: https://git.openjdk.org/jdk/pull/20564

From ihse at openjdk.org  Wed Aug 21 14:07:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Aug 2024 14:07:00 GMT
Subject: RFR: 8338290: Xcode project generator for hotspot [v3]
In-Reply-To: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>
References: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>
Message-ID: <ranHVBrPv9n3oUN2r8ZnHO44_eRa4AvkUD60Y989F3k=.191d4ffc-90f6-498a-b66b-432d4719842d@github.com>

> Add a make target to generate an Xcode project file for Hotspot. 
> 
> This PR is the result of a cooperation between me and @gerard-ziemski. Gerard developed the original Xcode generator (as a stand-alone project in https://github.com/gerard-ziemski/xcode), and I have written the build system "glue" to integrate it, and refactored the code to modern JDK standards.
> 
> Usage: Run `make hotspot-xcode-project`, and an Xcode project file will be generated in `build/$BUILD/xcode`. You can also have this automatically opened in Xcode by `make open-hotspot-xcode-project` (but note that for repeated runs of this, `make open-hotspot-xcode-project-only` is greatly preferred).

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Rename $1_LD_JSON to $1_LDFLAGS_FILE

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20564/files
  - new: https://git.openjdk.org/jdk/pull/20564/files/64b3ae19..ffff6a16

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20564&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20564&range=01-02

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20564.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20564/head:pull/20564

PR: https://git.openjdk.org/jdk/pull/20564

From erikj at openjdk.org  Wed Aug 21 14:12:04 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 21 Aug 2024 14:12:04 GMT
Subject: RFR: 8338290: Xcode project generator for hotspot [v3]
In-Reply-To: <ranHVBrPv9n3oUN2r8ZnHO44_eRa4AvkUD60Y989F3k=.191d4ffc-90f6-498a-b66b-432d4719842d@github.com>
References: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>
 <ranHVBrPv9n3oUN2r8ZnHO44_eRa4AvkUD60Y989F3k=.191d4ffc-90f6-498a-b66b-432d4719842d@github.com>
Message-ID: <bOI_8FEYnVx2JG3FfXEyr0HnSg_hJTl7ctEPn3agykI=.e5f97db8-211e-4b03-9a1f-8d8c9c963896@github.com>

On Wed, 21 Aug 2024 14:07:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Add a make target to generate an Xcode project file for Hotspot. 
>> 
>> This PR is the result of a cooperation between me and @gerard-ziemski. Gerard developed the original Xcode generator (as a stand-alone project in https://github.com/gerard-ziemski/xcode), and I have written the build system "glue" to integrate it, and refactored the code to modern JDK standards.
>> 
>> Usage: Run `make hotspot-xcode-project`, and an Xcode project file will be generated in `build/$BUILD/xcode`. You can also have this automatically opened in Xcode by `make open-hotspot-xcode-project` (but note that for repeated runs of this, `make open-hotspot-xcode-project-only` is greatly preferred).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename $1_LD_JSON to $1_LDFLAGS_FILE

Marked as reviewed by erikj (Reviewer).

To be clear, I've reviewed the build system changes, not the generator itself.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20564#pullrequestreview-2250922231
PR Comment: https://git.openjdk.org/jdk/pull/20564#issuecomment-2302150466

From ihse at openjdk.org  Wed Aug 21 14:16:06 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Aug 2024 14:16:06 GMT
Subject: RFR: 8298920: Improve microbenchmark build times [v3]
In-Reply-To: <3NfZ6PvTmQmZwfPgNIyUWoaA-xyFo0pMnwx9W8xAQ7I=.3f886aa4-9584-4fc5-9921-e205f1daf4f0@github.com>
References: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
 <3NfZ6PvTmQmZwfPgNIyUWoaA-xyFo0pMnwx9W8xAQ7I=.3f886aa4-9584-4fc5-9921-e205f1daf4f0@github.com>
Message-ID: <YMh1ayTEP23vB6EkBcsc36R0xIcEOg0mgPqRyrb7esk=.d505c60a-380e-4c6e-88a0-092c05ce42b7@github.com>

On Wed, 21 Aug 2024 11:21:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently incremental builds for the microbenchmarks may take notable amount of time, like:
>> 
>> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
>> Building target 'test' in configuration 'linux-x86_64-server-release'
>> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
>> Running Indify on microbenchmark classes
>> [snip]
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jaxp:tier1                                 0     0     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> Finished building target 'test' in configuration 'linux-x86_64-server-release'
>> 
>> real    0m37,581s
>> user    2m4,747s
>> sys     0m7,223s
>> 
>> 
>> The microbenchmark compilation is not using the `Depend` plugin that avoids recompilation of other files if the change files only contain minor changes (i.e. non-API changes). The patch here proposes to enhance the build to use the `Depend` plugin. The change that enables that is `CREATE_API_DIGEST := true,`, but since both the `Depend` plugin and JMH framework needs to be added to the classpath the patch re-organizes the code a little to properly augment the classpath.
>> 
>> With this patch, a build similar to the above might be:
>> 
>> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
>> Building target 'test' in configuration 'linux-x86_64-server-release'
>> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
>> Running Indify on microbenchmark classes
>> [snip]
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jaxp:tier1                                 0     0     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> Finished building target 'test' in configuration 'linux-x86_64-server-release'
>> 
>> real    0m7,505s
>> user    0m14,128s
>> sys     0m3,158s
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

Thanks! This looks good to be pushed now.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20616#pullrequestreview-2250934681

From yzheng at openjdk.org  Wed Aug 21 14:34:04 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 21 Aug 2024 14:34:04 GMT
Subject: RFR: 8305895: Implementation: JEP 450: Compact Object Headers
 (Experimental)
In-Reply-To: <GADoH3CbLaJymFNWVrLgOAi7CCXB7qRiQQvhbGMnqvA=.519ae324-cf9f-4d87-9bba-b2b1eb6f2526@github.com>
References: <GADoH3CbLaJymFNWVrLgOAi7CCXB7qRiQQvhbGMnqvA=.519ae324-cf9f-4d87-9bba-b2b1eb6f2526@github.com>
Message-ID: <bCheJmScZHopid-GeTesEAXnkIjkrwZcXR9jBBWPI0A=.b552dbab-6feb-4df5-8cec-ba05b22ccfed@github.com>

On Tue, 20 Aug 2024 10:07:26 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are building on #20603 and #20605 to protect the relevant (upper 32) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - The identity hash-code is temporarily narrowed to 25 bits. As soon as we get Tiny Class-Pointers (planned before the JEP can be integrated, and to be opened for review soon), we will widen the hash-bits back to 31 bits.
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will can now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archives are generated, next to the _nocoops variant.
>  - Note that oopDesc::klass_offset_in_bytes() is not used by +UCOH paths anymore. The only exception is C2, which uses it as a placeholder/identifier of the special memory slice that only LoadNKlass uses. The backend then extracts the original oop and loads its mark-word and extracts the narrow-Klass* from that. I played with other approaches to implement LoadNKlass. Expanding it as a macro did not easily work, because C2 is missing a way to cast a word-sized integral to a narrow-Klass* (o...

src/hotspot/share/opto/library_call.cpp line 4631:

> 4629:   // vm: see markWord.hpp.
> 4630:   Node *hash_mask      = _gvn.intcon(UseCompactObjectHeaders ? markWord::hash_mask_compact  : markWord::hash_mask);
> 4631:   Node *hash_shift     = _gvn.intcon(UseCompactObjectHeaders ? markWord::hash_shift_compact : markWord::hash_shift);

Could you please export these two symbols to JVMCI? Thanks!

diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
index 688691fb976..d97fdcb3f44 100644
--- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
+++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
@@ -792,11 +792,13 @@
   declare_constant(InvocationCounter::count_shift)                        \
                                                                           \
   declare_constant(markWord::hash_shift)                                  \
+  declare_constant(markWord::hash_shift_compact)                          \
   declare_constant(markWord::monitor_value)                               \
                                                                           \
   declare_constant(markWord::lock_mask_in_place)                          \
   declare_constant(markWord::age_mask_in_place)                           \
   declare_constant(markWord::hash_mask)                                   \
+  declare_constant(markWord::hash_mask_compact)                           \
   declare_constant(markWord::hash_mask_in_place)                          \
                                                                           \
   declare_constant(markWord::unlocked_value)                              \

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20640#discussion_r1725162361

From aph at openjdk.org  Wed Aug 21 14:43:06 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 21 Aug 2024 14:43:06 GMT
Subject: RFR: 8305895: Implementation: JEP 450: Compact Object Headers
 (Experimental)
In-Reply-To: <YpCBkv4hvZzmvq4x9FFI6b-Qw_4FT8nEnVylCHREuPw=.34d957a9-c581-4211-8cbe-5213f88d9e18@github.com>
References: <GADoH3CbLaJymFNWVrLgOAi7CCXB7qRiQQvhbGMnqvA=.519ae324-cf9f-4d87-9bba-b2b1eb6f2526@github.com>
 <1JS96-UJBR95NbAe79ETt1c7aJ3vH9-cijwG24ufs0E=.537b0a80-aedd-4b25-9605-264a2f7f60fb@github.com>
 <YpCBkv4hvZzmvq4x9FFI6b-Qw_4FT8nEnVylCHREuPw=.34d957a9-c581-4211-8cbe-5213f88d9e18@github.com>
Message-ID: <KjxQzxDWjAdCbhw_p5fZ5YOq83POeK9KA7UshAVHKaI=.811586e2-801f-40d9-84a9-ed7ccbad074f@github.com>

On Wed, 21 Aug 2024 13:18:03 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are building on #20603 and #20605 to protect the relevant (upper 32) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - The identity hash-code is temporarily narrowed to 25 bits. As soon as we get Tiny Class-Pointers (planned before the JEP can be integrated, and to be opened for review soon), we will widen the hash-bits back to 31 bits.
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will can now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archives are generated, next to the _nocoops variant.
>>  - Note that oopDesc::klass_offset_in_bytes() is not used by +UCOH paths anymore. The only exception is C2, which uses it as a placeholder/identifier of the special memory slice that only LoadNKlass uses. The backend then extracts the original oop and loads its mark-word and extracts the narrow-Klass* from that. I played with other approaches to implement LoadNKlass. Expanding it as a macro did not easily work, because C2 is missing a way to cast a word-sized integral t...
>
> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 2575:
> 
>> 2573:   } else {
>> 2574:     lea(dst, Address(obj, index, Address::lsl(scale)));
>> 2575:     ldr(dst, Address(dst, offset));
> 
> It ignores the offset, right? Or are you saying that offset must be 0 on that path?

Sorry, brain fart.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20640#discussion_r1725176978

From ihse at openjdk.org  Wed Aug 21 14:50:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Aug 2024 14:50:07 GMT
Subject: RFR: 8305895: Implementation: JEP 450: Compact Object Headers
 (Experimental)
In-Reply-To: <GADoH3CbLaJymFNWVrLgOAi7CCXB7qRiQQvhbGMnqvA=.519ae324-cf9f-4d87-9bba-b2b1eb6f2526@github.com>
References: <GADoH3CbLaJymFNWVrLgOAi7CCXB7qRiQQvhbGMnqvA=.519ae324-cf9f-4d87-9bba-b2b1eb6f2526@github.com>
Message-ID: <l5_KW-Z8PcQ0JbBYANqf2TmWHM0gGct9Au3fRoMGpGI=.b06a25ce-da74-4bb9-be29-d6451da83731@github.com>

On Tue, 20 Aug 2024 10:07:26 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are building on #20603 and #20605 to protect the relevant (upper 32) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - The identity hash-code is temporarily narrowed to 25 bits. As soon as we get Tiny Class-Pointers (planned before the JEP can be integrated, and to be opened for review soon), we will widen the hash-bits back to 31 bits.
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will can now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archives are generated, next to the _nocoops variant.
>  - Note that oopDesc::klass_offset_in_bytes() is not used by +UCOH paths anymore. The only exception is C2, which uses it as a placeholder/identifier of the special memory slice that only LoadNKlass uses. The backend then extracts the original oop and loads its mark-word and extracts the narrow-Klass* from that. I played with other approaches to implement LoadNKlass. Expanding it as a macro did not easily work, because C2 is missing a way to cast a word-sized integral to a narrow-Klass* (o...

make/autoconf/jdk-options.m4 line 696:

> 694:           AVAILABLE=false
> 695:         else
> 696:           AC_MSG_RESULT([yes])

You should set `AVAILABLE=true` in this case. Apparently it works anyway, but it will increase clarity of the code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20640#discussion_r1725190726

From mikael at openjdk.org  Wed Aug 21 16:38:07 2024
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 21 Aug 2024 16:38:07 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v3]
In-Reply-To: <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com>
 <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
Message-ID: <KId7bq0zTcuetwbln6G0T0yUk3WTQKhznlhVoSHq6iI=.244d9174-72c4-487a-a83b-1a5e08b5c309@github.com>

On Thu, 27 Jun 2024 22:03:37 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately. This enhancement adds the relevant files, enabling the rest of [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward.
>
> Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update README to include RISC-V

I'm following up on the necessary logistics given the new plan.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2302515601

From azafari at openjdk.org  Thu Aug 22 07:22:03 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 22 Aug 2024 07:22:03 GMT
Subject: RFR: 8338290: Xcode project generator for hotspot [v3]
In-Reply-To: <ranHVBrPv9n3oUN2r8ZnHO44_eRa4AvkUD60Y989F3k=.191d4ffc-90f6-498a-b66b-432d4719842d@github.com>
References: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>
 <ranHVBrPv9n3oUN2r8ZnHO44_eRa4AvkUD60Y989F3k=.191d4ffc-90f6-498a-b66b-432d4719842d@github.com>
Message-ID: <0dl8DpdsJ5be0MnWQq3Oz3_O8hPZ8CAjx55ew7dhgl8=.4aec5dee-8181-4e57-b74f-b097673798c6@github.com>

On Wed, 21 Aug 2024 14:07:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Add a make target to generate an Xcode project file for Hotspot. 
>> 
>> This PR is the result of a cooperation between me and @gerard-ziemski. Gerard developed the original Xcode generator (as a stand-alone project in https://github.com/gerard-ziemski/xcode), and I have written the build system "glue" to integrate it, and refactored the code to modern JDK standards.
>> 
>> Usage: Run `make hotspot-xcode-project`, and an Xcode project file will be generated in `build/$BUILD/xcode`. You can also have this automatically opened in Xcode by `make open-hotspot-xcode-project` (but note that for repeated runs of this, `make open-hotspot-xcode-project-only` is greatly preferred).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename $1_LD_JSON to $1_LDFLAGS_FILE

Thanks for the work done. LGTM.

-------------

Marked as reviewed by azafari (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20564#pullrequestreview-2253690909

From rkennke at openjdk.org  Thu Aug 22 08:00:54 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Aug 2024 08:00:54 GMT
Subject: RFR: 8305895: Implementation: JEP 450: Compact Object Headers
 (Experimental) [v2]
In-Reply-To: <GADoH3CbLaJymFNWVrLgOAi7CCXB7qRiQQvhbGMnqvA=.519ae324-cf9f-4d87-9bba-b2b1eb6f2526@github.com>
References: <GADoH3CbLaJymFNWVrLgOAi7CCXB7qRiQQvhbGMnqvA=.519ae324-cf9f-4d87-9bba-b2b1eb6f2526@github.com>
Message-ID: <lXVF-gH3CUZW11l0gF4Ut0EjzoOJtNw2aeqLamQJ2X8=.ddfa17ad-d916-4dd3-a190-25e44d446738@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are building on #20603 and #20605 to protect the relevant (upper 32) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - The identity hash-code is temporarily narrowed to 25 bits. As soon as we get Tiny Class-Pointers (planned before the JEP can be integrated, and to be opened for review soon), we will widen the hash-bits back to 31 bits.
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will can now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archives are generated, next to the _nocoops variant.
>  - Note that oopDesc::klass_offset_in_bytes() is not used by +UCOH paths anymore. The only exception is C2, which uses it as a placeholder/identifier of the special memory slice that only LoadNKlass uses. The backend then extracts the original oop and loads its mark-word and extracts the narrow-Klass* from that. I played with other approaches to implement LoadNKlass. Expanding it as a macro did not easily work, because C2 is missing a way to cast a word-sized integral to a narrow-Klass* (o...

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'JDK-8305896-v2' into JDK-8305895-v3
 - Merge branch 'JDK-8305896-v2' into JDK-8305895-v3
 - Explicitely make AVAILABLE=true
 - Export new hash constants to JVMCI
 - Improve asserts
 - 8305894: Implementation: JEP 450: Compact Object Headers (Experimental)

-------------

Changes: https://git.openjdk.org/jdk/pull/20640/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20640&range=01
  Stats: 1670 lines in 105 files changed: 1234 ins; 208 del; 228 mod
  Patch: https://git.openjdk.org/jdk/pull/20640.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20640/head:pull/20640

PR: https://git.openjdk.org/jdk/pull/20640

From ihse at openjdk.org  Thu Aug 22 10:33:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Aug 2024 10:33:05 GMT
Subject: RFR: Implement JEP 450: Compact Object Headers (Experimental) [v2]
In-Reply-To: <lXVF-gH3CUZW11l0gF4Ut0EjzoOJtNw2aeqLamQJ2X8=.ddfa17ad-d916-4dd3-a190-25e44d446738@github.com>
References: <GADoH3CbLaJymFNWVrLgOAi7CCXB7qRiQQvhbGMnqvA=.519ae324-cf9f-4d87-9bba-b2b1eb6f2526@github.com>
 <lXVF-gH3CUZW11l0gF4Ut0EjzoOJtNw2aeqLamQJ2X8=.ddfa17ad-d916-4dd3-a190-25e44d446738@github.com>
Message-ID: <QIuTCrnGqACIqr4SHi387mA_zXH82_4kbP0E923rwis=.802f7a7f-c94f-4ca3-80b0-88311a834048@github.com>

On Thu, 22 Aug 2024 08:00:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are building on #20603 and #20605 to protect the relevant (upper 32) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - The identity hash-code is temporarily narrowed to 25 bits. As soon as we get Tiny Class-Pointers (planned before the JEP can be integrated, and to be opened for review soon), we will widen the hash-bits back to 31 bits.
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will can now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archives are generated, next to the _nocoops variant.
>>  - Note that oopDesc::klass_offset_in_bytes() is not used by +UCOH paths anymore. The only exception is C2, which uses it as a placeholder/identifier of the special memory slice that only LoadNKlass uses. The backend then extracts the original oop and loads its mark-word and extracts the narrow-Klass* from that. I played with other approaches to implement LoadNKlass. Expanding it as a macro did not easily work, because C2 is missing a way to cast a word-sized integral t...
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'JDK-8305896-v2' into JDK-8305895-v3
>  - Merge branch 'JDK-8305896-v2' into JDK-8305895-v3
>  - Explicitely make AVAILABLE=true
>  - Export new hash constants to JVMCI
>  - Improve asserts
>  - 8305894: Implementation: JEP 450: Compact Object Headers (Experimental)

Build changes look good. I have not looked at any other changes.

@rkennke Note that the Skara bot removed the RFR label when you changed the title to no longer match a JBS issue. This means that no emails will be sent to the corresponding lists. I am not sure if this was intentional on your part.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20640#pullrequestreview-2254136529
PR Comment: https://git.openjdk.org/jdk/pull/20640#issuecomment-2304321468

From ihse at openjdk.org  Thu Aug 22 10:34:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Aug 2024 10:34:15 GMT
Subject: RFR: 8338290: Xcode project generator for hotspot [v3]
In-Reply-To: <ranHVBrPv9n3oUN2r8ZnHO44_eRa4AvkUD60Y989F3k=.191d4ffc-90f6-498a-b66b-432d4719842d@github.com>
References: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>
 <ranHVBrPv9n3oUN2r8ZnHO44_eRa4AvkUD60Y989F3k=.191d4ffc-90f6-498a-b66b-432d4719842d@github.com>
Message-ID: <qU0sBw1odvkMTvsmi_bsCu0jgrKaH0rdWArO8nBipB8=.21595cf7-bc37-4acc-9fcb-37a40086162a@github.com>

On Wed, 21 Aug 2024 14:07:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Add a make target to generate an Xcode project file for Hotspot. 
>> 
>> This PR is the result of a cooperation between me and @gerard-ziemski. Gerard developed the original Xcode generator (as a stand-alone project in https://github.com/gerard-ziemski/xcode), and I have written the build system "glue" to integrate it, and refactored the code to modern JDK standards.
>> 
>> Usage: Run `make hotspot-xcode-project`, and an Xcode project file will be generated in `build/$BUILD/xcode`. You can also have this automatically opened in Xcode by `make open-hotspot-xcode-project` (but note that for repeated runs of this, `make open-hotspot-xcode-project-only` is greatly preferred).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename $1_LD_JSON to $1_LDFLAGS_FILE

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20564#issuecomment-2304322536

From ihse at openjdk.org  Thu Aug 22 10:34:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Aug 2024 10:34:18 GMT
Subject: Integrated: 8338290: Xcode project generator for hotspot
In-Reply-To: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>
References: <JzSbEJrTsylS__33n6suhNts85pcI1D-lq5G3UejD9Y=.6da221b5-1f51-4665-8c98-1ccff5fb8bfb@github.com>
Message-ID: <_ha72K2qIyeu6yu1gFTkOvxZkzpvpU9zDK8V0oaKCtI=.a63686d8-aff6-483d-8101-f5fa8e616ab9@github.com>

On Tue, 13 Aug 2024 09:57:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Add a make target to generate an Xcode project file for Hotspot. 
> 
> This PR is the result of a cooperation between me and @gerard-ziemski. Gerard developed the original Xcode generator (as a stand-alone project in https://github.com/gerard-ziemski/xcode), and I have written the build system "glue" to integrate it, and refactored the code to modern JDK standards.
> 
> Usage: Run `make hotspot-xcode-project`, and an Xcode project file will be generated in `build/$BUILD/xcode`. You can also have this automatically opened in Xcode by `make open-hotspot-xcode-project` (but note that for repeated runs of this, `make open-hotspot-xcode-project-only` is greatly preferred).

This pull request has now been integrated.

Changeset: 129f527f
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/129f527f4f6de04897440a11f0be024f1a378433
Stats:     1778 lines in 15 files changed: 1762 ins; 5 del; 11 mod

8338290: Xcode project generator for hotspot

Co-authored-by: Gerard Ziemski <gziemski at openjdk.org>
Co-authored-by: Magnus Ihse Bursie <ihse at openjdk.org>
Reviewed-by: azafari, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/20564

From rkennke at openjdk.org  Thu Aug 22 11:05:18 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Aug 2024 11:05:18 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v3]
In-Reply-To: <GADoH3CbLaJymFNWVrLgOAi7CCXB7qRiQQvhbGMnqvA=.519ae324-cf9f-4d87-9bba-b2b1eb6f2526@github.com>
References: <GADoH3CbLaJymFNWVrLgOAi7CCXB7qRiQQvhbGMnqvA=.519ae324-cf9f-4d87-9bba-b2b1eb6f2526@github.com>
Message-ID: <plexEOT7MTJkynkwwuZjZpmiw2isRIqFaaDqa2OBy80=.f99c04bb-13a2-4679-9bf6-b8b7d5871424@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are building on #20603 and #20605 to protect the relevant (upper 32) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - The identity hash-code is temporarily narrowed to 25 bits. As soon as we get Tiny Class-Pointers (planned before the JEP can be integrated, and to be opened for review soon), we will widen the hash-bits back to 31 bits.
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will can now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archives are generated, next to the _nocoops variant.
>  - Note that oopDesc::klass_offset_in_bytes() is not used by +UCOH paths anymore. The only exception is C2, which uses it as a placeholder/identifier of the special memory slice that only LoadNKlass uses. The backend then extracts the original oop and loads its mark-word and extracts the narrow-Klass* from that. I played with other approaches to implement LoadNKlass. Expanding it as a macro did not easily work, because C2 is missing a way to cast a word-sized integral to a narrow-Klass* (o...

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'JDK-8305896-v2' into JDK-8305895-v3
 - Merge branch 'JDK-8305896-v2' into JDK-8305895-v3
 - Merge branch 'JDK-8305896-v2' into JDK-8305895-v3
 - Explicitely make AVAILABLE=true
 - Export new hash constants to JVMCI
 - Improve asserts
 - 8305894: Implementation: JEP 450: Compact Object Headers (Experimental)

-------------

Changes: https://git.openjdk.org/jdk/pull/20640/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20640&range=02
  Stats: 1670 lines in 105 files changed: 1234 ins; 208 del; 228 mod
  Patch: https://git.openjdk.org/jdk/pull/20640.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20640/head:pull/20640

PR: https://git.openjdk.org/jdk/pull/20640

From rkennke at openjdk.org  Thu Aug 22 11:05:18 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Aug 2024 11:05:18 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v2]
In-Reply-To: <QIuTCrnGqACIqr4SHi387mA_zXH82_4kbP0E923rwis=.802f7a7f-c94f-4ca3-80b0-88311a834048@github.com>
References: <GADoH3CbLaJymFNWVrLgOAi7CCXB7qRiQQvhbGMnqvA=.519ae324-cf9f-4d87-9bba-b2b1eb6f2526@github.com>
 <lXVF-gH3CUZW11l0gF4Ut0EjzoOJtNw2aeqLamQJ2X8=.ddfa17ad-d916-4dd3-a190-25e44d446738@github.com>
 <QIuTCrnGqACIqr4SHi387mA_zXH82_4kbP0E923rwis=.802f7a7f-c94f-4ca3-80b0-88311a834048@github.com>
Message-ID: <qzF0BH158HO411NifWandYCVeXQEbmVsYotmeiIbF0Y=.2004b51f-574a-4300-88dd-5b2a409eda74@github.com>

On Thu, 22 Aug 2024 10:30:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> @rkennke Note that the Skara bot removed the RFR label when you changed the title to no longer match a JBS issue. This means that no emails will be sent to the corresponding lists. I am not sure if this was intentional on your part.

Thanks for pointing that out! No it was not intentional. Mark changed the title in the JBS issue, and I copied that over, but forgot the actual issue number. Should be fixed now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20640#issuecomment-2304384577

From rkennke at openjdk.org  Thu Aug 22 14:51:15 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Aug 2024 14:51:15 GMT
Subject: Withdrawn: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental)
In-Reply-To: <GADoH3CbLaJymFNWVrLgOAi7CCXB7qRiQQvhbGMnqvA=.519ae324-cf9f-4d87-9bba-b2b1eb6f2526@github.com>
References: <GADoH3CbLaJymFNWVrLgOAi7CCXB7qRiQQvhbGMnqvA=.519ae324-cf9f-4d87-9bba-b2b1eb6f2526@github.com>
Message-ID: <Ad1r6BgWF9RXpSpgKyCPhlwejZH_3BBilEaLAUS8s-w=.3eeb8cb1-362e-4135-83b4-86dedcc37324@github.com>

On Tue, 20 Aug 2024 10:07:26 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are building on #20603 and #20605 to protect the relevant (upper 32) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - The identity hash-code is temporarily narrowed to 25 bits. As soon as we get Tiny Class-Pointers (planned before the JEP can be integrated, and to be opened for review soon), we will widen the hash-bits back to 31 bits.
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will can now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archives are generated, next to the _nocoops variant.
>  - Note that oopDesc::klass_offset_in_bytes() is not used by +UCOH paths anymore. The only exception is C2, which uses it as a placeholder/identifier of the special memory slice that only LoadNKlass uses. The backend then extracts the original oop and loads its mark-word and extracts the narrow-Klass* from that. I played with other approaches to implement LoadNKlass. Expanding it as a macro did not easily work, because C2 is missing a way to cast a word-sized integral to a narrow-Klass* (o...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20640

From rkennke at openjdk.org  Thu Aug 22 14:53:47 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Aug 2024 14:53:47 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental)
Message-ID: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>

This is the main body of the JEP 450: Compact Object Headers (Experimental).

It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.

Main changes:
 - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
 - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
 - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
 - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
 - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
 - Arrays will now store their length at offset 8.
 - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archives are generated, next to the _nocoops variant.
 - Note that oopDesc::klass_offset_in_bytes() is not used by +UCOH paths anymore. The only exception is C2, which uses it as a placeholder/identifier of the special memory slice that only LoadNKlass uses. The backend then extracts the original oop and loads its mark-word and extracts the narrow-Klass* from that. I played with other approaches to implement LoadNKlass. Expanding it as a macro did not easily work, because C2 is missing a way to cast a word-sized integral to a narrow-Klass* (or at least I could not find it), and also I fear that doing so could mess with optimizations. This may be useful to revisit. OTOH, the approach that I have taken works and is similar to DecodeNKlass and similar instructions.

Testing:
 (+UseCompactObjectHeaders tests are run with the flag hard-patched into the build, to also catch @flagless tests.)
The below testing has been run many times, but not with this exact base version of the JDK. I want to hold off the full testing until we also have the Tiny Class-Pointers PR lined-up, and test with that.

 - [x] tier1 (x86_64)
 - [ ] tier2 (x86_64)
 - [ ] tier3 (x86_64)
 - [ ] tier4 (x86_64)
 - [x] tier1 (aarch64)
 - [ ] tier2 (aarch64)
 - [ ] tier3 (aarch64)
 - [ ] tier4 (aarch64)
 - [x] tier1 (x86_64) +UseCompactObjectHeaders
 - [ ] tier2 (x86_64) +UseCompactObjectHeaders
 - [ ] tier3 (x86_64) +UseCompactObjectHeaders
 - [ ] tier4 (x86_64) +UseCompactObjectHeaders
 - [x] tier1 (aarch64) +UseCompactObjectHeaders
 - [ ] tier2 (aarch64) +UseCompactObjectHeaders
 - [ ] tier3 (aarch64) +UseCompactObjectHeaders
 - [ ] tier4 (aarch64) +UseCompactObjectHeaders
 - [x] Running as a backport in production since >1 year.

-------------

Commit messages:
 - 8305895: Implement JEP 450: Compact Object Headers (Experimental)

Changes: https://git.openjdk.org/jdk/pull/20677/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305895
  Stats: 4526 lines in 187 files changed: 3238 ins; 671 del; 617 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

PR: https://git.openjdk.org/jdk/pull/20677

From rkennke at openjdk.org  Thu Aug 22 14:51:15 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Aug 2024 14:51:15 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v3]
In-Reply-To: <plexEOT7MTJkynkwwuZjZpmiw2isRIqFaaDqa2OBy80=.f99c04bb-13a2-4679-9bf6-b8b7d5871424@github.com>
References: <GADoH3CbLaJymFNWVrLgOAi7CCXB7qRiQQvhbGMnqvA=.519ae324-cf9f-4d87-9bba-b2b1eb6f2526@github.com>
 <plexEOT7MTJkynkwwuZjZpmiw2isRIqFaaDqa2OBy80=.f99c04bb-13a2-4679-9bf6-b8b7d5871424@github.com>
Message-ID: <_dUMNfQKbcgEP_r6avLEDuPprVLFitHPaIWTxJ7_ZcU=.c711b62a-6bc1-4e69-85f2-52e38ccfeb87@github.com>

On Thu, 22 Aug 2024 11:05:18 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are building on #20603 and #20605 to protect the relevant (upper 32) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - The identity hash-code is temporarily narrowed to 25 bits. As soon as we get Tiny Class-Pointers (planned before the JEP can be integrated, and to be opened for review soon), we will widen the hash-bits back to 31 bits.
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will can now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archives are generated, next to the _nocoops variant.
>>  - Note that oopDesc::klass_offset_in_bytes() is not used by +UCOH paths anymore. The only exception is C2, which uses it as a placeholder/identifier of the special memory slice that only LoadNKlass uses. The backend then extracts the original oop and loads its mark-word and extracts the narrow-Klass* from that. I played with other approaches to implement LoadNKlass. Expanding it as a macro did not easily work, because C2 is missing a way to cast a word-sized integral t...
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'JDK-8305896-v2' into JDK-8305895-v3
>  - Merge branch 'JDK-8305896-v2' into JDK-8305895-v3
>  - Merge branch 'JDK-8305896-v2' into JDK-8305895-v3
>  - Explicitely make AVAILABLE=true
>  - Export new hash constants to JVMCI
>  - Improve asserts
>  - 8305894: Implementation: JEP 450: Compact Object Headers (Experimental)

Superseding by #20677

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20640#issuecomment-2304864714

From rkennke at openjdk.org  Thu Aug 22 15:00:09 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Aug 2024 15:00:09 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v2]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <dfwWs-WA77sOPzUwJw_9Zaa40qpzGO5BI70_YmyqD2g=.d3346941-4f23-47ee-b599-b0c90703ca2f@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Add missing newline

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/ed032173..18e08c1e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

PR: https://git.openjdk.org/jdk/pull/20677

From rkennke at openjdk.org  Thu Aug 22 16:23:48 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Aug 2024 16:23:48 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v3]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <bKtmNAMLqRlWTG9MBcosxeh2rYNK_yx_gkh_qbNKt6s=.e23c8a75-0072-4c9f-8d8e-7db14826fded@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Remove hashcode leftovers from SA

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/18e08c1e..1578ffae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

PR: https://git.openjdk.org/jdk/pull/20677

From rkennke at openjdk.org  Thu Aug 22 17:59:10 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Aug 2024 17:59:10 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v4]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <jzdcu_4W9ntyW1POE6uoXyLHD4Z1EcQtwIKiiuT98aM=.1ccc2769-fed3-4570-80a0-49d7b8d8ee2b@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Fix hash_mask_in_place in ClhsdbLongConstant test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/1578ffae..7009e147

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

PR: https://git.openjdk.org/jdk/pull/20677

From rkennke at openjdk.org  Thu Aug 22 18:18:01 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Aug 2024 18:18:01 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v5]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <TzmQRM_6QAc9tdMzNYnzSPR_nENrokTzNx2q-TPuWpw=.cfcbe6f4-4397-4c31-be73-d5a456618090@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Fix hash shift for 32 bit builds

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/7009e147..5ffc582f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

PR: https://git.openjdk.org/jdk/pull/20677

From ihse at openjdk.org  Thu Aug 22 19:29:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Aug 2024 19:29:03 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v5]
In-Reply-To: <TzmQRM_6QAc9tdMzNYnzSPR_nENrokTzNx2q-TPuWpw=.cfcbe6f4-4397-4c31-be73-d5a456618090@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TzmQRM_6QAc9tdMzNYnzSPR_nENrokTzNx2q-TPuWpw=.cfcbe6f4-4397-4c31-be73-d5a456618090@github.com>
Message-ID: <XLy_mB3TjLyOUGwNwrUGiyUtCHtOuVmCtZcFjuWvu8k=.ac3b111a-e665-49c5-994a-c52d8b06fddd@github.com>

On Thu, 22 Aug 2024 18:18:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix hash shift for 32 bit builds

Build changes look good. I have not looked at any other code.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2255474321

From rkennke at openjdk.org  Thu Aug 22 20:08:43 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Aug 2024 20:08:43 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Fix bit counts in GCForwarding

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/5ffc582f..eaec1117

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

PR: https://git.openjdk.org/jdk/pull/20677

From ayang at openjdk.org  Thu Aug 22 20:16:07 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 22 Aug 2024 20:16:07 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v5]
In-Reply-To: <TzmQRM_6QAc9tdMzNYnzSPR_nENrokTzNx2q-TPuWpw=.cfcbe6f4-4397-4c31-be73-d5a456618090@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TzmQRM_6QAc9tdMzNYnzSPR_nENrokTzNx2q-TPuWpw=.cfcbe6f4-4397-4c31-be73-d5a456618090@github.com>
Message-ID: <-G_gdaZBT2xhZFsdyEwIqiOHpbLpiL79N6NDsW8X2BY=.bc52bd8a-21c5-40e7-a921-a5f68675200f@github.com>

On Thu, 22 Aug 2024 18:18:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix hash shift for 32 bit builds

src/hotspot/share/gc/shared/gcForwarding.cpp line 37:

> 35:   size_t max_narrow_heap_size = right_n_bits(NumLowBitsNarrow - Shift);
> 36:   if (UseCompactObjectHeaders && max_heap_size > max_narrow_heap_size * HeapWordSize) {
> 37:     FLAG_SET_DEFAULT(UseCompactObjectHeaders, false);

Maybe a log-info/warning would be nice.

src/hotspot/share/gc/shared/gcForwarding.hpp line 36:

> 34:  * Implements forwarding for the full-GCs of Serial, Parallel, G1 and Shenandoah in
> 35:  * a way that preserves upper N bits of object mark-words, which contain crucial
> 36:  * Klass* information when running with compact headers. The encoding is similar to

This doc suggests this forwarding is only for compact-header so I wonder if we can check `UseCompactObjectHeaders` directly instead of heap-size in `GCForwarding::initialize`.

src/hotspot/share/gc/shared/gcForwarding.hpp line 40:

> 38:  * heap-base, shifts that difference into the right place, and sets the lowest two
> 39:  * bits (to indicate 'forwarded' state as usual).
> 40:  */

> "can use 40 bits for forwardee encoding. That's enough for 8TB of heap."

I feel this 8T-constraint is significant and should be in the doc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1727708193
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1727727638
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1727732496

From ayang at openjdk.org  Thu Aug 22 20:16:05 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 22 Aug 2024 20:16:05 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v3]
In-Reply-To: <bKtmNAMLqRlWTG9MBcosxeh2rYNK_yx_gkh_qbNKt6s=.e23c8a75-0072-4c9f-8d8e-7db14826fded@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <bKtmNAMLqRlWTG9MBcosxeh2rYNK_yx_gkh_qbNKt6s=.e23c8a75-0072-4c9f-8d8e-7db14826fded@github.com>
Message-ID: <ySywujYrcJzmYZtj5oflhcQZbzxPv78dm29gJ5B1fqE=.31b98908-bc0f-48af-b67a-75e7351d1b74@github.com>

On Thu, 22 Aug 2024 16:23:48 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove hashcode leftovers from SA

src/hotspot/share/gc/parallel/mutableSpace.cpp line 232:

> 230:         p += obj->forwardee()->size();
> 231:       } else {
> 232:         p += obj->size();

I feel it's more correct to go through the forwardee for forwarded objs even for the non-COMPACT_HEADERS case. (This method is meant to cover all objs, so should not be perf-critical.) IOW, the `false` case should just be dropped.

src/hotspot/share/gc/serial/defNewGeneration.cpp line 707:

> 705:       } else if (obj->is_forwarded()) {
> 706:         // To restore the klass-bits in the header.
> 707:         obj->forward_safe_init_mark();

I wonder if not modifying successful-forwarded objs is cleaner. Sth like:


reset_self_forwarded_in_space(space) {
  cur = space->bottom();
  top = space->top();

  while (cur < top) {
    obj = cast_to_oop(cur);

    if (obj->is_self_forwarded()) {
      obj->unset_self_forwarded();
      obj_size = obj->size();
    } else {
      assert(obj->is_forwarded(), "inv");
      obj_size = obj->forwardee()->size();
    }

    cur += obj_size;
  }
}

reset_self_forwarded_in_space(eden());
reset_self_forwarded_in_space(from());

src/hotspot/share/gc/serial/serialArguments.cpp line 33:

> 31: void SerialArguments::initialize_heap_flags_and_sizes() {
> 32:   GenArguments::initialize_heap_flags_and_sizes();
> 33:   GCForwarding::initialize_flags(MaxNewSize + MaxOldSize);

Can one use `MaxHeapSize` here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1727547638
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1727524479
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1727548413

From mcimadamore at openjdk.org  Fri Aug 23 09:03:32 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 23 Aug 2024 09:03:32 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v10]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <HA3_7MIOfWFK3QKeLQUsXDMtbDGiEBaTnijTfbQxbj8=.17f3d5b1-ad76-431f-91a5-b2f95816db7a@github.com>

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Merge branch 'master' into restricted_jni
 - Merge branch 'master' into restricted_jni
 - Address review comments
 - Add note on --illegal-native-access default value in the launcher help
 - Address review comment
 - Refine warning text for JNI method binding
 - Address review comments
   Improve warning for JNI methods, similar to what's described in JEP 472
   Beef up tests
 - Address review comments
 - Fix another typo
 - Fix typo
 - ... and 3 more: https://git.openjdk.org/jdk/compare/f7ea738c...04622748

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/ff51ac6a..04622748

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=08-09

  Stats: 51278 lines in 1477 files changed: 28775 ins; 15348 del; 7155 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

PR: https://git.openjdk.org/jdk/pull/19213

From duke at openjdk.org  Fri Aug 23 10:43:30 2024
From: duke at openjdk.org (Pratiksha.Sawant)
Date: Fri, 23 Aug 2024 10:43:30 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
Message-ID: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>

Mapping ISO-8859-8-I charset to ISO-8859-8.
Below mentioned 2 aliases are added as part of this:-
**ISO-8859-8-I**
**ISO8859-8-I**

The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686

-------------

Commit messages:
 - Mapping ISO-8859-8-I charset to ISO-8859-8.

Changes: https://git.openjdk.org/jdk/pull/20690/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20690&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8195686
  Stats: 7 lines in 2 files changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20690/head:pull/20690

PR: https://git.openjdk.org/jdk/pull/20690

From stefank at openjdk.org  Fri Aug 23 10:56:05 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 23 Aug 2024 10:56:05 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
Message-ID: <MZnkyvL6XoHEuPO0DtoekBz4QH_I5uisKXGwCOFGcA4=.53525e3d-54aa-4298-be5d-9b70cb483f8b@github.com>

On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bit counts in GCForwarding

I've looked through the changes to the gc/ directory and have a couple of proposal changes. Please have a look:
https://github.com/openjdk/jdk/compare/pr/20677...stefank:jdk:lilliput_review_gc_1

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2306834883

From duke at openjdk.org  Fri Aug 23 11:10:03 2024
From: duke at openjdk.org (Pratiksha.Sawant)
Date: Fri, 23 Aug 2024 11:10:03 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
Message-ID: <cFfYFo52RgmzeWDMUV6Nm2I6-zURQCzJId23YdrHH3M=.1e844acb-3337-4407-86da-6e15b606885a@github.com>

On Fri, 23 Aug 2024 10:38:38 GMT, Pratiksha.Sawant <duke at openjdk.org> wrote:

> Mapping ISO-8859-8-I charset to ISO-8859-8.
> Below mentioned 2 aliases are added as part of this:-
> **ISO-8859-8-I**
> **ISO8859-8-I**
> 
> The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686

I have attached a test case for the charset issue.

Without the charset fix, below issue is seen:

ISO-8859-8I charset testing
ISO-8859-8 bytes: 1C 1E DF FE 3F FD 
Exception in thread "main" java.io.UnsupportedEncodingException: ISO-8859-8-I
	at java.base/java.lang.String.lookupCharset(String.java:861)
	at java.base/java.lang.String.getBytes(String.java:1795)
	at iso88598.main(iso88598.java:8)


After applying the fix, able to decode characters using **ISO-8859-8-I** charset.

ISO-8859-8I charset testing
ISO-8859-8 bytes: 1C 1E DF FE 3F FD 
ISO-8859-8-I bytes: 1C 1E DF FE 3F FD 
ISO8859-8-I bytes: 1C 1E DF FE 3F FD

[iso88598.txt](https://github.com/user-attachments/files/16727747/iso88598.txt)

@jaikiran, could you please review my PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2306856630
PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2306859247

From jpai at openjdk.org  Fri Aug 23 11:19:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 23 Aug 2024 11:19:05 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
Message-ID: <Bqww1CSew8sO9kERs-FX6DB7lk4fB9Lzt2cOqZtgrdA=.c81dad01-f849-4e7e-8a25-b50d13029d65@github.com>

On Fri, 23 Aug 2024 10:38:38 GMT, Pratiksha.Sawant <duke at openjdk.org> wrote:

> Mapping ISO-8859-8-I charset to ISO-8859-8.
> Below mentioned 2 aliases are added as part of this:-
> **ISO-8859-8-I**
> **ISO8859-8-I**
> 
> The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686

Hello Pratiksha, this is not an area that I have knowledge in. Naoto and Justin review changes in this area and I believe they will take a look at this when they are around.

Having said that, I notice that in your comment you mention that you ran a test with this change that fixes the issue. It looks like that was tested as a standalone application? Could you add that as a jtreg test to reproduce the issue and verify the fix?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2306873563

From lmesnik at openjdk.org  Fri Aug 23 16:37:05 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 23 Aug 2024 16:37:05 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
Message-ID: <JEzJGLkDHhgNGFns5-xLFV1TGH2-EkzWd568IcAO1Rg=.b48dc38e-57a9-4e4f-b512-fc86efdb77c4@github.com>

On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bit counts in GCForwarding

Changes requested by lmesnik (Reviewer).

make/Images.gmk line 135:

> 133: #
> 134: # Param1 - VM variant (e.g., server, client, zero, ...)
> 135: # Param2 - _nocoops, _coh, _nocoops_coh, or empty

The -XX:+UseCompactObjectHeaders ssems to incompatible withe zero vm. The zero vm build start failing while generating shared archive with +UseCompactObjectHeaders. Generation should be disabled by default for zero to don't break the build.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2257621775
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1729222671

From naoto at openjdk.org  Fri Aug 23 16:46:08 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 23 Aug 2024 16:46:08 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
Message-ID: <I0cEy87rro0hjAa2VpDP-S2RChLoruawBg4oh4qg8tw=.3a50d346-4f6b-4fc0-b275-943f356bb96f@github.com>

On Fri, 23 Aug 2024 10:38:38 GMT, Pratiksha.Sawant <duke at openjdk.org> wrote:

> Mapping ISO-8859-8-I charset to ISO-8859-8.
> Below mentioned 2 aliases are added as part of this:-
> **ISO-8859-8-I**
> **ISO8859-8-I**
> 
> The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686

Hi,
Could you please elaborate the rationale to implement this encoding? As ISO-8859 encodings are pretty much obsolete, not sure it is worth adding this encoding now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2307443250

From mli at openjdk.org  Fri Aug 23 18:49:05 2024
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 23 Aug 2024 18:49:05 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
Message-ID: <utcfd2HiwL8a7ut2UJ7tHb1P_oz5TKXA9bwGQ5G_FnE=.63fa2666-dc3f-406d-b8d2-4f960f05f05d@github.com>

On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bit counts in GCForwarding

src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.cpp line 170:

> 168:   mv(tmp1, (int32_t)(intptr_t)markWord::prototype().value());
> 169:   sd(tmp1, Address(obj, oopDesc::mark_offset_in_bytes()));
> 170: // Todo UseCompactObjectHeaders

Can I ask, will this pr fullly support riscv?

src/hotspot/share/oops/oop.inline.hpp line 94:

> 92: 
> 93: void oopDesc::init_mark() {
> 94:   if (UseCompactObjectHeaders) {

Seems only `set_mark(prototype_mark());` is fine for both cases?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1729383247
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1728833750

From lmesnik at openjdk.org  Fri Aug 23 19:06:04 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 23 Aug 2024 19:06:04 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
Message-ID: <roqs5Spc1UGAUaoLhyc7-hVGR0pNLPcofkdaT_6R7Pg=.fda59880-aac8-4ec3-bc26-286639a519bd@github.com>

On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bit counts in GCForwarding

test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java line 59:

> 57:     public static void main(String... args) throws Exception {
> 58:          String zGenerational = args[0];
> 59:          String compactHeaders = "-XX:" + (zGenerational.equals("-XX:+ZGenerational") ? "+" : "-") + "UseCompactObjectHeaders";

The test failing with
 stdout: [[0.176s][info][cds] trying to map /opt/mach5/mesos/work_dir/slaves/a20696e7-ae7d-4d37-8e9c-83f99ef002cb-S2261/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/f0801999-993f-4e08-b017-08b33a8ec44f/runs/34cc555e-ae8f-4a48-8175-e998194f204b/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_cds_relocation/scratch/5/appcds-18h50m16s773.jsa
[0.176s][info][cds] Opened archive /opt/mach5/mesos/work_dir/slaves/a20696e7-ae7d-4d37-8e9c-83f99ef002cb-S2261/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/f0801999-993f-4e08-b017-08b33a8ec44f/runs/34cc555e-ae8f-4a48-8175-e998194f204b/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_cds_relocation/scratch/5/appcds-18h50m16s773.jsa.
[0.176s][info][cds] Archive was created with UseCompressedOops = 0, UseCompressedClassPointers = 1
[0.176s][info][cds] The shared archive file's UseCompactObjectHeaders setting (enabled) does not equal the current UseCompactObjectHeaders setting (disabled).
[0.176s][info][cds] Initialize static archive failed.
[0.176s][info][cds] Unable to map shared spaces
[0.176s][error][cds] An error has occurred while processing the shared archive file.
[0.176s][error][cds] Unable to map shared spaces
Error occurred during initialization of VM
Unable to use shared archive.
];
 stderr: []
 exitValue = 1

java.lang.RuntimeException: 'Hello World' missing from stdout/stderr
	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:252)
	at TestZGCWithCDS.main(TestZGCWithCDS.java:123)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1575)

JavaTest Message: Test threw exception: java.lang.RuntimeException
JavaTest Message: shutting down test

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1729404477

From duke at openjdk.org  Sat Aug 24 02:02:15 2024
From: duke at openjdk.org (Jason Mehrens)
Date: Sat, 24 Aug 2024 02:02:15 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <I0cEy87rro0hjAa2VpDP-S2RChLoruawBg4oh4qg8tw=.3a50d346-4f6b-4fc0-b275-943f356bb96f@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
 <I0cEy87rro0hjAa2VpDP-S2RChLoruawBg4oh4qg8tw=.3a50d346-4f6b-4fc0-b275-943f356bb96f@github.com>
Message-ID: <fytEl6_pY7w-gIehGFn6yUhNopa7aMDt5swff9PYmh0=.8b1c7c10-d3a7-46d7-9b27-e39c60c299a0@github.com>

On Fri, 23 Aug 2024 16:43:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Mapping ISO-8859-8-I charset to ISO-8859-8.
>> Below mentioned 2 aliases are added as part of this:-
>> **ISO-8859-8-I**
>> **ISO8859-8-I**
>> 
>> The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686
>
> Hi,
> Could you please elaborate the rationale to implement this encoding? As ISO-8859 encodings are pretty much obsolete, not sure it is worth adding this encoding now.

@naotoj The origin comes from an old JavaMail ticket that Bill Shannon was working on.  The link is here: https://github.com/jakartaee/mail-api/issues/302

I'm picking up where Bill left off and @psawant19 is just addressing the matching jdk bug.  I can add the mappings to JakaraMail but Bill wanted the evaluation of root issue in the JDK before doing that. The history is in the linked ticket.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2307990303

From alanb at openjdk.org  Sun Aug 25 07:24:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 25 Aug 2024 07:24:05 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
Message-ID: <Na8UyyWw50w06OmA82DKBlPb8DafD4XTLbtI5bO4PTM=.2bd106b9-66de-44ac-be69-9c4a34425e8a@github.com>

On Fri, 23 Aug 2024 10:38:38 GMT, Pratiksha.Sawant <duke at openjdk.org> wrote:

> Mapping ISO-8859-8-I charset to ISO-8859-8.
> Below mentioned 2 aliases are added as part of this:-
> **ISO-8859-8-I**
> **ISO8859-8-I**
> 
> The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686

I've added the "csr" label as this is adding support for "ISO8859-8-I".

Naoto asked me about it but I'm not 100% sure if it's an alias or a different charset. I think this topic may require input from those more familiar with charsets in environment that require bidi processing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2308711172

From stuefe at openjdk.org  Mon Aug 26 08:06:09 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 26 Aug 2024 08:06:09 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <roqs5Spc1UGAUaoLhyc7-hVGR0pNLPcofkdaT_6R7Pg=.fda59880-aac8-4ec3-bc26-286639a519bd@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <roqs5Spc1UGAUaoLhyc7-hVGR0pNLPcofkdaT_6R7Pg=.fda59880-aac8-4ec3-bc26-286639a519bd@github.com>
Message-ID: <GLFs2h_prTbuRe_A3rKZRt3Yfb4AErMRaxyjH2fcdBE=.f3ab0807-3dec-4ae1-b042-7181bba0a7f1@github.com>

On Fri, 23 Aug 2024 19:03:19 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bit counts in GCForwarding
>
> test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java line 59:
> 
>> 57:     public static void main(String... args) throws Exception {
>> 58:          String zGenerational = args[0];
>> 59:          String compactHeaders = "-XX:" + (zGenerational.equals("-XX:+ZGenerational") ? "+" : "-") + "UseCompactObjectHeaders";
> 
> The test failing with
>  stdout: [[0.176s][info][cds] trying to map /opt/mach5/mesos/work_dir/slaves/a20696e7-ae7d-4d37-8e9c-83f99ef002cb-S2261/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/f0801999-993f-4e08-b017-08b33a8ec44f/runs/34cc555e-ae8f-4a48-8175-e998194f204b/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_cds_relocation/scratch/5/appcds-18h50m16s773.jsa
> [0.176s][info][cds] Opened archive /opt/mach5/mesos/work_dir/slaves/a20696e7-ae7d-4d37-8e9c-83f99ef002cb-S2261/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/f0801999-993f-4e08-b017-08b33a8ec44f/runs/34cc555e-ae8f-4a48-8175-e998194f204b/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_cds_relocation/scratch/5/appcds-18h50m16s773.jsa.
> [0.176s][info][cds] Archive was created with UseCompressedOops = 0, UseCompressedClassPointers = 1
> [0.176s][info][cds] The shared archive file's UseCompactObjectHeaders setting (enabled) does not equal the current UseCompactObjectHeaders setting (disabled).
> [0.176s][info][cds] Initialize static archive failed.
> [0.176s][info][cds] Unable to map shared spaces
> [0.176s][error][cds] An error has occurred while processing the shared archive file.
> [0.176s][error][cds] Unable to map shared spaces
> Error occurred during initialization of VM
> Unable to use shared archive.
> ];
>  stderr: []
>  exitValue = 1
> 
> java.lang.RuntimeException: 'Hello World' missing from stdout/stderr
> 	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:252)
> 	at TestZGCWithCDS.main(TestZGCWithCDS.java:123)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
> 	at java.base/java.lang.Thread.run(Thread.java:1575)
> 
> JavaTest Message: Test threw exception: java.lang.RuntimeException
> JavaTest Message: shutting down test

Roman has two weeks of vacation; I am taking a look at this one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1730855152

From mcimadamore at openjdk.org  Mon Aug 26 09:20:18 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Aug 2024 09:20:18 GMT
Subject: Integrated: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <3nep7-Z8_feW39di9cTU1O07lgFQD4WmSHQia-UUS7c=.18fb2776-9f8a-47c8-be58-8cd1dd30d45f@github.com>

On Mon, 13 May 2024 10:42:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

This pull request has now been integrated.

Changeset: 20d8f58c
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/20d8f58c92009a46dfb91b951e7d87b4cb8e8b41
Stats:     532 lines in 107 files changed: 341 ins; 52 del; 139 mod

8331671: Implement JEP 472: Prepare to Restrict the Use of JNI

Reviewed-by: jpai, prr, ihse, kcr, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/19213

From duke at openjdk.org  Mon Aug 26 13:06:03 2024
From: duke at openjdk.org (Pratiksha.Sawant)
Date: Mon, 26 Aug 2024 13:06:03 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
Message-ID: <pouzOQuLYjKVFeJs9bra1176CdhEAFB-N9bYBP0Jx4A=.3b7fd602-2471-4fba-b7ca-b84f5a1a8665@github.com>

On Fri, 23 Aug 2024 10:38:38 GMT, Pratiksha.Sawant <duke at openjdk.org> wrote:

> Mapping ISO-8859-8-I charset to ISO-8859-8.
> Below mentioned 2 aliases are added as part of this:-
> **ISO-8859-8-I**
> **ISO8859-8-I**
> 
> The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686

"ISO-8859-8-I" is a charset name for character encoding "ISO-8859-8".(https://en.wikipedia.org/wiki/ISO-8859-8-I).

We had found 2 files where the aliases for charsets are added in jdk code base.

?src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/EncodingMap.java?
?/make/data/charsetmapping/charsets?


?ISO-8859-8-I? charset is referenced in the headers as the charset of the email contents in few clients when the email is generated from Middle East and China. As it is supposed to be a duplicate of ISO-8859-8, and we are supporting this ISO-8859-8-I in EncodingMap.java, supporting this encoding in charsets file also makes the behaviour consistent through the JDK.

There is a ticket raised in angus-mail for similar issue :- https://github.com/eclipse-ee4j/angus-mail/issues/147

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2310164523

From cjplummer at openjdk.org  Mon Aug 26 21:56:04 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 26 Aug 2024 21:56:04 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
Message-ID: <Og4I5G3w51d7zF27JawLM9pm_XpHwijYt3lJZ4hpeWQ=.fd974e82-2ce0-4ebd-b49e-108ab87690a9@github.com>

On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bit counts in GCForwarding

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Oop.java line 85:

> 83: 
> 84:   private static Klass getKlass(Mark mark) {
> 85:     assert(VM.getVM().isCompactObjectHeadersEnabled());

`mark.getKlass()` already does this assert. I don't see any value in this `getKlass()` method. The caller should just call `getMark().getKlass()` rather than `getKlass(getMark())`.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Oop.java line 169:

> 167:         } else {
> 168:           visitor.doMetadata(klass, true);
> 169:         }

Why is there no `visitor.doMetadata()` call for the compressed object header case?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1731849434
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1731866842

From fyang at openjdk.org  Tue Aug 27 05:42:05 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 27 Aug 2024 05:42:05 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <utcfd2HiwL8a7ut2UJ7tHb1P_oz5TKXA9bwGQ5G_FnE=.63fa2666-dc3f-406d-b8d2-4f960f05f05d@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <utcfd2HiwL8a7ut2UJ7tHb1P_oz5TKXA9bwGQ5G_FnE=.63fa2666-dc3f-406d-b8d2-4f960f05f05d@github.com>
Message-ID: <n33g0VZINE0Qly_UoJV2zOCDkapbuqFgRyzTYor6TrE=.7acb0ac5-5bbe-4747-bf3c-20110201616c@github.com>

On Fri, 23 Aug 2024 18:42:28 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bit counts in GCForwarding
>
> src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.cpp line 170:
> 
>> 168:   mv(tmp1, (int32_t)(intptr_t)markWord::prototype().value());
>> 169:   sd(tmp1, Address(obj, oopDesc::mark_offset_in_bytes()));
>> 170: // Todo UseCompactObjectHeaders
> 
> Can I ask, will this pr fullly support riscv?

@Hamlin-Li : AFAIK, porting to linux-riscv platform has NOT been started yet. To avoid duplicate work, please let me know if anyone is interested or has been working on it :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1732153574

From jlahoda at openjdk.org  Tue Aug 27 07:26:08 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 27 Aug 2024 07:26:08 GMT
Subject: Integrated: 8298920: Improve microbenchmark build times
In-Reply-To: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
References: <G7scc5IzHp0KQgeQI80W62nWOntbs1w1vk8pGQnlpc4=.9c6caaa9-37c2-4009-a9fa-b342b011d3a8@github.com>
Message-ID: <s-hgTc4Stygil2OtyMe4ep6QLy4nd-174jpIxN377lI=.49426cb4-7003-4ebd-9bac-e7f8ab9936ce@github.com>

On Fri, 16 Aug 2024 12:24:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently incremental builds for the microbenchmarks may take notable amount of time, like:
> 
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
> Building target 'test' in configuration 'linux-x86_64-server-release'
> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
> Running Indify on microbenchmark classes
> [snip]
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp:tier1                                 0     0     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'linux-x86_64-server-release'
> 
> real    0m37,581s
> user    2m4,747s
> sys     0m7,223s
> 
> 
> The microbenchmark compilation is not using the `Depend` plugin that avoids recompilation of other files if the change files only contain minor changes (i.e. non-API changes). The patch here proposes to enhance the build to use the `Depend` plugin. The change that enables that is `CREATE_API_DIGEST := true,`, but since both the `Depend` plugin and JMH framework needs to be added to the classpath the patch re-organizes the code a little to properly augment the classpath.
> 
> With this patch, a build similar to the above might be:
> 
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java; time make test TEST=jaxp:tier1
> Building target 'test' in configuration 'linux-x86_64-server-release'
> Compiling up to 656 files for BUILD_JDK_MICROBENCHMARK
> Running Indify on microbenchmark classes
> [snip]
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp:tier1                                 0     0     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'linux-x86_64-server-release'
> 
> real    0m7,505s
> user    0m14,128s
> sys     0m3,158s

This pull request has now been integrated.

Changeset: b704bfa2
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b704bfa205bbd8c56f128ce5d727d40c8a3ec613
Stats:     35 lines in 2 files changed: 19 ins; 14 del; 2 mod

8298920: Improve microbenchmark build times

Reviewed-by: erikj, ihse, djelinski

-------------

PR: https://git.openjdk.org/jdk/pull/20616

From mli at openjdk.org  Tue Aug 27 07:46:10 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 27 Aug 2024 07:46:10 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <n33g0VZINE0Qly_UoJV2zOCDkapbuqFgRyzTYor6TrE=.7acb0ac5-5bbe-4747-bf3c-20110201616c@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <utcfd2HiwL8a7ut2UJ7tHb1P_oz5TKXA9bwGQ5G_FnE=.63fa2666-dc3f-406d-b8d2-4f960f05f05d@github.com>
 <n33g0VZINE0Qly_UoJV2zOCDkapbuqFgRyzTYor6TrE=.7acb0ac5-5bbe-4747-bf3c-20110201616c@github.com>
Message-ID: <wVUrQQtzaYdZNPBPyiuln0Zd8C67zG2y0yX2Iik6l_I=.0be5dcf7-c48d-4bb9-9966-23530f0b8d2e@github.com>

On Tue, 27 Aug 2024 05:37:30 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.cpp line 170:
>> 
>>> 168:   mv(tmp1, (int32_t)(intptr_t)markWord::prototype().value());
>>> 169:   sd(tmp1, Address(obj, oopDesc::mark_offset_in_bytes()));
>>> 170: // Todo UseCompactObjectHeaders
>> 
>> Can I ask, will this pr fullly support riscv?
>
> @Hamlin-Li : AFAIK, porting to linux-riscv platform has NOT been started yet. To avoid duplicate work, please let me know if anyone is interested or has been working on it :-)

Yes, I'm interested in it. Thanks for raising the discussion. :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1732312058

From sgehwolf at openjdk.org  Tue Aug 27 09:48:50 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 27 Aug 2024 09:48:50 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v35]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <FFSS1M7GS20RauKkiCEdkpNH5rS2F4HSSMpJRYOxobs=.70675ea3-3c6f-44e5-9aef-984a361dd3a0@github.com>

> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b
 eing modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.manage...

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 140 commits:

 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - JLinkDedupTestBatchSizeOne.java test fix
   
   Run only the packaged modules version if we have a linkable JDK runtime
   with packaged modules available as well in the JDK install.
 - Enable IncludeLocalesPluginTest
 - Enable GenerateJLIClassesPluginTest.java test
 - Enable JLinkReproducibleTest.java for linkable JDK images
 - Remove restriction on directory based modules
   
   Enable the following tests:
   - JLink100Modules.java
   - JLinkDedupTestBatchSizeOne.java
 - Comment fix in JRTArchive. Long line in JlinkTask
 - Comment fixes in ImageFileCreator
 - ... and 130 more: https://git.openjdk.org/jdk/compare/aefdbdc7...59997873

-------------

Changes: https://git.openjdk.org/jdk/pull/14787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=34
  Stats: 3959 lines in 42 files changed: 3762 ins; 117 del; 80 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

PR: https://git.openjdk.org/jdk/pull/14787

From mikael at openjdk.org  Tue Aug 27 22:02:29 2024
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 27 Aug 2024 22:02:29 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v3]
In-Reply-To: <geN8VMoF-kDepFi3AYS7wzBk7SxI-nZiD5-Vtx6cnVw=.023d7d59-27e6-4370-bd0b-787a3f143095@github.com>
References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com>
 <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
 <geN8VMoF-kDepFi3AYS7wzBk7SxI-nZiD5-Vtx6cnVw=.023d7d59-27e6-4370-bd0b-787a3f143095@github.com>
Message-ID: <7bKMs0Na_OgNIOnzHF9baDK8E_EXPbtd6ZFVUWHVH9o=.ace95434-f086-46f5-9368-07573941cbe1@github.com>

On Fri, 16 Aug 2024 09:45:59 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update README to include RISC-V
>
>> With this solution I would recommend putting the script next to the Sleef source tree instead of in make/devkit/.
> 
>> The normal JDK build will just use the committed pre-generated headers.
> 
>> Not because I didn't think it was feasible to implement, but because of the future maintenance burden.
> 
> I agree with @erikj79, in particular the above 3 points.
> 
> Shall we be ready to move forward? Or we're still blocked by some other issues, such as legal process?

@Hamlin-Li We now have the necessary approvals in place for the new plan to include all of SLEEF (and the pre-generated header files) in the JDK. I (or somebody else from Oracle) will need to be the one committing/contributing the actual SLEEF code itself in the end. Can you take on the work of implementing the actual plan/logic and make sure it's all effectively ready for integration?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2313650531

From liach at openjdk.org  Tue Aug 27 22:24:02 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Aug 2024 22:24:02 GMT
Subject: RFR: 8339115: Rename TypeKind enum constants to follow code style
Message-ID: <PE4gAxKmGTt47D19xxdW0d4wyT3p4sD7JmKGviY7gBg=.979b0984-046f-4bd6-87fe-f7d12e2bfc66@github.com>

`TypeKind` enum constants are named in wrong code style; correct them before finalization.

Also improved `TypeKind` specification to talk about not mentioned `returnType`, `void`, and subword types being erased to int (and how). See the associated CSR too.

-------------

Commit messages:
 - 8339115: Rename TypeKind enum constants to follow code style

Changes: https://git.openjdk.org/jdk/pull/20737/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20737&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339115
  Stats: 664 lines in 31 files changed: 70 ins; 14 del; 580 mod
  Patch: https://git.openjdk.org/jdk/pull/20737.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20737/head:pull/20737

PR: https://git.openjdk.org/jdk/pull/20737

From mli at openjdk.org  Tue Aug 27 22:28:22 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 27 Aug 2024 22:28:22 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v3]
In-Reply-To: <7bKMs0Na_OgNIOnzHF9baDK8E_EXPbtd6ZFVUWHVH9o=.ace95434-f086-46f5-9368-07573941cbe1@github.com>
References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com>
 <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
 <geN8VMoF-kDepFi3AYS7wzBk7SxI-nZiD5-Vtx6cnVw=.023d7d59-27e6-4370-bd0b-787a3f143095@github.com>
 <7bKMs0Na_OgNIOnzHF9baDK8E_EXPbtd6ZFVUWHVH9o=.ace95434-f086-46f5-9368-07573941cbe1@github.com>
Message-ID: <KNs7ooCESzInOClcv_W92KJRqFeEUFhX2d9vbdgqbB4=.1b9ef0e9-aeb5-4bcb-9bb2-c4b59e988bd7@github.com>

On Tue, 27 Aug 2024 21:59:28 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>>> With this solution I would recommend putting the script next to the Sleef source tree instead of in make/devkit/.
>> 
>>> The normal JDK build will just use the committed pre-generated headers.
>> 
>>> Not because I didn't think it was feasible to implement, but because of the future maintenance burden.
>> 
>> I agree with @erikj79, in particular the above 3 points.
>> 
>> Shall we be ready to move forward? Or we're still blocked by some other issues, such as legal process?
>
> @Hamlin-Li We now have the necessary approvals in place for the new plan to include all of SLEEF (and the pre-generated header files) in the JDK. I (or somebody else from Oracle) will need to be the one committing/contributing the actual SLEEF code itself in the end. Can you take on the work of implementing the actual plan/logic and make sure it's all effectively ready for integration?

@vidmik Thanks for pushing forward this work.
Sure, I can take the work.

Just several questions, Sorry, as this is the first time I do this kind of work in jdk.
In this pr, we already have the pre-generated sleef files and the scripts to generate it, what we are missing is the sleef original file (in my understanding, we also need to checkin them), besides of sleef original files, do we need any other files or document? In particular, do you mind to clarify further about `plan/logic` mentioned above?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2313681144

From ihse at openjdk.org  Tue Aug 27 22:31:16 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Aug 2024 22:31:16 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings
In-Reply-To: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
Message-ID: <Bf2Hw0qejuqqPoPfXd_kq8xTGvpL9LVrWfXNTUcjJno=.705d1175-43bd-4844-bbf3-740c4caceb8b@github.com>

On Tue, 27 Aug 2024 20:04:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

If at some point the diff seems larger than needed, it could be that I have reordered things where the alphabetic order had capsized.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20733#issuecomment-2313681273

From ihse at openjdk.org  Tue Aug 27 22:31:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Aug 2024 22:31:15 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings
Message-ID: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>

Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.

We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

-------------

Commit messages:
 - Fix debug builds
 - Try fixing static builds on zero
 - Fix zero
 - Fix libfallbackLinker
 - Also update native tests
 - 8339120: Use more fine-granular gcc unused warnings

Changes: https://git.openjdk.org/jdk/pull/20733/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339120
  Stats: 50 lines in 17 files changed: 28 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/20733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20733/head:pull/20733

PR: https://git.openjdk.org/jdk/pull/20733

From mikael at openjdk.org  Tue Aug 27 22:39:21 2024
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 27 Aug 2024 22:39:21 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v3]
In-Reply-To: <KNs7ooCESzInOClcv_W92KJRqFeEUFhX2d9vbdgqbB4=.1b9ef0e9-aeb5-4bcb-9bb2-c4b59e988bd7@github.com>
References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com>
 <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
 <geN8VMoF-kDepFi3AYS7wzBk7SxI-nZiD5-Vtx6cnVw=.023d7d59-27e6-4370-bd0b-787a3f143095@github.com>
 <7bKMs0Na_OgNIOnzHF9baDK8E_EXPbtd6ZFVUWHVH9o=.ace95434-f086-46f5-9368-07573941cbe1@github.com>
 <KNs7ooCESzInOClcv_W92KJRqFeEUFhX2d9vbdgqbB4=.1b9ef0e9-aeb5-4bcb-9bb2-c4b59e988bd7@github.com>
Message-ID: <8cIGwT38AWUYMa_wtSSBmE16BCJbipyG_tFBeW3tzL8=.5ad181bd-ab04-4a5c-a9a2-b16e4bdcd554@github.com>

On Tue, 27 Aug 2024 22:26:02 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> @Hamlin-Li We now have the necessary approvals in place for the new plan to include all of SLEEF (and the pre-generated header files) in the JDK. I (or somebody else from Oracle) will need to be the one committing/contributing the actual SLEEF code itself in the end. Can you take on the work of implementing the actual plan/logic and make sure it's all effectively ready for integration?
>
> @vidmik Thanks for pushing forward this work.
> Sure, I can take the work.
> 
> Just several questions, Sorry, as this is the first time I do this kind of work in jdk.
> In this pr, we already have the pre-generated sleef files and the scripts to generate it, what we are missing is the sleef original file (in my understanding, we also need to checkin them), besides of sleef original files, do we need any other files or document? In particular, do you mind to clarify further about `plan/logic` mentioned above?

@Hamlin-Li Thank you for taking it on!

Part of the work is figuring out exactly what exactly we want - see the comments from @erikj79 and @theRealAph in this PR for inspiration. In particular, we'll want to include all or part of the SLEEF sources in the JDK, but we'll likely also want some additional build scripts and documentation to make it easy for developers to reproduce and update going forward. This could probably be based on the README and createSleef script.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2313693092

From jjg at openjdk.org  Tue Aug 27 22:41:18 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 27 Aug 2024 22:41:18 GMT
Subject: RFR: 8339115: Rename TypeKind enum constants to follow code style
In-Reply-To: <PE4gAxKmGTt47D19xxdW0d4wyT3p4sD7JmKGviY7gBg=.979b0984-046f-4bd6-87fe-f7d12e2bfc66@github.com>
References: <PE4gAxKmGTt47D19xxdW0d4wyT3p4sD7JmKGviY7gBg=.979b0984-046f-4bd6-87fe-f7d12e2bfc66@github.com>
Message-ID: <7_wHsVuwcRF8Q9t7p3ZKCW0aegJceddguT4ud21ScO0=.5cbe52f1-4cb7-45e1-afba-50004c49aee3@github.com>

On Tue, 27 Aug 2024 22:15:17 GMT, Chen Liang <liach at openjdk.org> wrote:

> `TypeKind` enum constants are named in wrong code style; correct them before finalization.
> 
> Also improved `TypeKind` specification to talk about not mentioned `returnType`, `void`, and subword types being erased to int (and how). See the associated CSR too.
> 
> See the HTML output for the changed `JSpec` taglet's `6.5.newarray` rendering: https://cr.openjdk.org/~liach/8339115-typekind/java.base/java/lang/classfile/TypeKind.html
> 
> Note: when reviewing, please use https://cr.openjdk.org/~iris/se/23/spec/draft/java-se-23-draft-spec-37/ instead of JVMS 22 for reference; JVMS 23 has fixed a few ambiguities about subword types being absent from JVM's stack and locals.

Changes to JSpec.java look OK.

No comment on other changes.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20737#pullrequestreview-2264584894

From jwaters at openjdk.org  Wed Aug 28 03:49:25 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 28 Aug 2024 03:49:25 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings
In-Reply-To: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
Message-ID: <hIiv7dM_QvSeLf3DIiTUlWwtruXr6K8BERQkewTd4sc=.b65677db-ecfa-40d7-ab81-4070f7ae948d@github.com>

On Tue, 27 Aug 2024 20:04:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

That's a lot of new warnings, but I like the idea of being more fine grained in what is disabled and enabled

-------------

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20733#pullrequestreview-2265064013

From kbarrett at openjdk.org  Wed Aug 28 06:41:19 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 28 Aug 2024 06:41:19 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings
In-Reply-To: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
Message-ID: <T4rqV_-AyEo5Xvecfu1ffRwYjFdyAFpP7vu9xsBofFk=.c55de0dc-2c01-40e6-a73c-7120c74589c2@github.com>

On Tue, 27 Aug 2024 20:04:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

We should make a similar set of changes for clang, though doing that in a separate
proposal is good.  Is there a JBS issue for that yet?

make/autoconf/flags-cflags.m4 line 239:

> 237:       # Additional warnings that are not activated by -Wall and -Wextra
> 238:       WARNINGS_ENABLE_ADDITIONAL="-Wpointer-arith -Wreturn-type -Wsign-compare \
> 239:           -Wtrampolines -Wundef -Wunused-const-variable -Wunused-function \

I think we don't want `-Wunused-const-variable=2` (eqv. `-Wunused-const-variable`) for C++
code. Recall that C++ const variables default to internal linkage (e.g. implicitly static). It's normal
to have a non-local constant in a header file that isn't used by every translation unit.  For C++ use
`-Wunused-const-variable=1`.  I think doing this might eliminate the need for disabling this warning
in a bunch of other places in this PR.

-------------

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20733#pullrequestreview-2265277235
PR Review Comment: https://git.openjdk.org/jdk/pull/20733#discussion_r1734067573

From mli at openjdk.org  Wed Aug 28 08:00:21 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 28 Aug 2024 08:00:21 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v3]
In-Reply-To: <8cIGwT38AWUYMa_wtSSBmE16BCJbipyG_tFBeW3tzL8=.5ad181bd-ab04-4a5c-a9a2-b16e4bdcd554@github.com>
References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com>
 <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
 <geN8VMoF-kDepFi3AYS7wzBk7SxI-nZiD5-Vtx6cnVw=.023d7d59-27e6-4370-bd0b-787a3f143095@github.com>
 <7bKMs0Na_OgNIOnzHF9baDK8E_EXPbtd6ZFVUWHVH9o=.ace95434-f086-46f5-9368-07573941cbe1@github.com>
 <KNs7ooCESzInOClcv_W92KJRqFeEUFhX2d9vbdgqbB4=.1b9ef0e9-aeb5-4bcb-9bb2-c4b59e988bd7@github.com>
 <8cIGwT38AWUYMa_wtSSBmE16BCJbipyG_tFBeW3tzL8=.5ad181bd-ab04-4a5c-a9a2-b16e4bdcd554@github.com>
Message-ID: <8hrzVXrMU2kZjsz8SD8HJXX9Vc5tuGvu03eC6TjRS5Q=.d62e2134-fd59-4152-8b2b-18585e1c71fd@github.com>

On Tue, 27 Aug 2024 22:37:01 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> @vidmik Thanks for pushing forward this work.
>> Sure, I can take the work.
>> 
>> Just several questions, Sorry, as this is the first time I do this kind of work in jdk.
>> In this pr, we already have the pre-generated sleef files and the scripts to generate it, what we are missing is the sleef original file (in my understanding, we also need to checkin them), besides of sleef original files, do we need any other files or document? In particular, do you mind to clarify further about `plan/logic` mentioned above?
>
> @Hamlin-Li Thank you for taking it on!
> 
> Part of the work is figuring out exactly what exactly we want - see the comments from @erikj79 and @theRealAph in this PR for inspiration. In particular, we'll want to include all or part of the SLEEF sources in the JDK, but we'll likely also want some additional build scripts and documentation to make it easy for developers to reproduce and update going forward. This could probably be based on the README and createSleef script.

@vidmik Thanks for clarifying, I'll figure it out.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2314597648

From ihse at openjdk.org  Wed Aug 28 11:28:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Aug 2024 11:28:19 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings
In-Reply-To: <T4rqV_-AyEo5Xvecfu1ffRwYjFdyAFpP7vu9xsBofFk=.c55de0dc-2c01-40e6-a73c-7120c74589c2@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
 <T4rqV_-AyEo5Xvecfu1ffRwYjFdyAFpP7vu9xsBofFk=.c55de0dc-2c01-40e6-a73c-7120c74589c2@github.com>
Message-ID: <Wh_ehv03iycRbr8kc8OJpaa8NnL3IUeNxUNLcqe7aRE=.8d2dd737-0832-4aab-a3de-554094fe9b4f@github.com>

On Wed, 28 Aug 2024 06:38:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> We should make a similar set of changes for clang, though doing that in a separate
proposal is good. Is there a JBS issue for that yet?

Yes, we should. I am 80% done with that patch, but I have not yet opened a JBS ticket. Will do that now.

> make/autoconf/flags-cflags.m4 line 239:
> 
>> 237:       # Additional warnings that are not activated by -Wall and -Wextra
>> 238:       WARNINGS_ENABLE_ADDITIONAL="-Wpointer-arith -Wreturn-type -Wsign-compare \
>> 239:           -Wtrampolines -Wundef -Wunused-const-variable -Wunused-function \
> 
> I think we don't want `-Wunused-const-variable=2` (eqv. `-Wunused-const-variable`) for C++
> code. Recall that C++ const variables default to internal linkage (e.g. implicitly static). It's normal
> to have a non-local constant in a header file that isn't used by every translation unit.  For C++ use
> `-Wunused-const-variable=1`.  I think doing this might eliminate the need for disabling this warning
> in a bunch of other places in this PR.

Good point, I'll try that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20733#issuecomment-2315053230
PR Review Comment: https://git.openjdk.org/jdk/pull/20733#discussion_r1734501680

From ihse at openjdk.org  Wed Aug 28 12:15:21 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Aug 2024 12:15:21 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v3]
In-Reply-To: <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com>
 <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
Message-ID: <1h6dur7t9dol43m5WDZFIdx2f9b0SAFdeCTnK2bT2fg=.2a7c42f2-c8bb-494a-9867-aef0ee562dda@github.com>

On Thu, 27 Jun 2024 22:03:37 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately. This enhancement adds the relevant files, enabling the rest of [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward.
>
> Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update README to include RISC-V

I think this will need some discussion to get it right, both from a
a) source layout/organization, and
b) build system perspective.

We're doing something that is quite new to the JDK source code base and build system, after all.

Some questions that needs to be answered:

* Do we store the full source code "off tree", e.g. like in `src/utils/spleef`, just for reference? And then store the generated files that are actually compiled in the "proper" place, like `src/java.base/native/libspleef`. Doing it this way will simplify the build. It will possibly also simplify for developers, since they can look at the actual code that is compiled and used.

* Or do we store the complete code base at e.g.  `src/java.base/native/libspleef`, but filter out that from the build, and instead have the generated files in something like  `src/java.base/native/libspleef/preprocessed-src`? I think that sounds like a bad idea, in general. It would be confusing, harder to implement in the build, and overall not generally helpful for the understanding of the code base.

* Or do we only store the complete code base at e.g.  `src/java.base/native/libspleef`, and generate the preprocessed files at build time, every time we build? That would in effect mean we incorporate the libsleef build in our system, including all their dependencies. The advantage is that it would make the source code placement logical, but it would be a hard hit on how we build the product. 

* If we chose to check in pre-processed sources, where should the logic for doing the pre-processing reside? As part of configure, make, or a separate script? My spontaneous reaction is to have it as part of the build system, like  `make update-spleef-source`, but there might be more to it. For checking requirements, configure is the general go-to place.
I am not a fan of the idea of having a specially hacked shell script dropped down in the middle of the spleef sources. :-(

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2315158159

From ihse at openjdk.org  Wed Aug 28 12:34:28 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Aug 2024 12:34:28 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v2]
In-Reply-To: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
Message-ID: <EU5oA6dm39X6mxMx-Pt5cQMUlaiW6kgoHIfoTWcZlM4=.4532a170-dc0c-4f55-b035-602a512acbaa@github.com>

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Use -Wunused-const-variable=1 instead

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20733/files
  - new: https://git.openjdk.org/jdk/pull/20733/files/7d4f1380..27cd3b06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=00-01

  Stats: 48 lines in 5 files changed: 8 ins; 1 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/20733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20733/head:pull/20733

PR: https://git.openjdk.org/jdk/pull/20733

From ihse at openjdk.org  Wed Aug 28 12:34:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Aug 2024 12:34:29 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v2]
In-Reply-To: <Wh_ehv03iycRbr8kc8OJpaa8NnL3IUeNxUNLcqe7aRE=.8d2dd737-0832-4aab-a3de-554094fe9b4f@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
 <T4rqV_-AyEo5Xvecfu1ffRwYjFdyAFpP7vu9xsBofFk=.c55de0dc-2c01-40e6-a73c-7120c74589c2@github.com>
 <Wh_ehv03iycRbr8kc8OJpaa8NnL3IUeNxUNLcqe7aRE=.8d2dd737-0832-4aab-a3de-554094fe9b4f@github.com>
Message-ID: <kj31yN6Llw0LfS6uJQTJ2mmIDBz5IvFHVNQVjWAwMjY=.6f0b5244-a1b8-480e-bfb1-5189444bb34e@github.com>

On Wed, 28 Aug 2024 11:26:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/autoconf/flags-cflags.m4 line 239:
>> 
>>> 237:       # Additional warnings that are not activated by -Wall and -Wextra
>>> 238:       WARNINGS_ENABLE_ADDITIONAL="-Wpointer-arith -Wreturn-type -Wsign-compare \
>>> 239:           -Wtrampolines -Wundef -Wunused-const-variable -Wunused-function \
>> 
>> I think we don't want `-Wunused-const-variable=2` (eqv. `-Wunused-const-variable`) for C++
>> code. Recall that C++ const variables default to internal linkage (e.g. implicitly static). It's normal
>> to have a non-local constant in a header file that isn't used by every translation unit.  For C++ use
>> `-Wunused-const-variable=1`.  I think doing this might eliminate the need for disabling this warning
>> in a bunch of other places in this PR.
>
> Good point, I'll try that.

It turned out to be sort-of okay-ish. I explicitly listed like 6 or so per-file exclusions in Hotspot (even though my normal cutoff for just setting a component-wide exclude is 3-4) since it seems that you will want to look at and fix those.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20733#discussion_r1734588979

From ihse at openjdk.org  Wed Aug 28 13:02:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Aug 2024 13:02:55 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v3]
In-Reply-To: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
Message-ID: <8Z0-2COIwtT2yDoSU8DkeNh2NbBOg7LZhFCEqtJzLOI=.83df3ab0-da2f-4b81-ab72-6091924ffdc1@github.com>

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix aarch54

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20733/files
  - new: https://git.openjdk.org/jdk/pull/20733/files/27cd3b06..7d3bf0d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20733/head:pull/20733

PR: https://git.openjdk.org/jdk/pull/20733

From kbarrett at openjdk.org  Wed Aug 28 13:38:20 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 28 Aug 2024 13:38:20 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v3]
In-Reply-To: <8Z0-2COIwtT2yDoSU8DkeNh2NbBOg7LZhFCEqtJzLOI=.83df3ab0-da2f-4b81-ab72-6091924ffdc1@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
 <8Z0-2COIwtT2yDoSU8DkeNh2NbBOg7LZhFCEqtJzLOI=.83df3ab0-da2f-4b81-ab72-6091924ffdc1@github.com>
Message-ID: <CYdPaXV4225As6MAyJ7HXXm3km8SwG6Jqbc_8Qhb2gw=.bf7b3427-0ae8-4705-8bf1-26310ad929ea@github.com>

On Wed, 28 Aug 2024 13:02:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
>> 
>> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix aarch54

Changes requested by kbarrett (Reviewer).

make/modules/java.desktop/lib/ClientLibraries.gmk line 284:

> 282: 
> 283: ifeq ($(USE_EXTERNAL_HARFBUZZ), true)
> 284:   LIBFONTMANAGER_EXTRA_SRC =

I think this 3space -> 2space indentation change shouldn't be part of this PR, esp. since 3space is
used in other parts of this file.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20733#pullrequestreview-2266289452
PR Review Comment: https://git.openjdk.org/jdk/pull/20733#discussion_r1734691445

From erikj at openjdk.org  Wed Aug 28 13:41:21 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 28 Aug 2024 13:41:21 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <WjbVrrjlwa6wJw57f2FNXrGvqUUaRdwylCjEI0g1URI=.afc15190-599c-4c3f-9e0f-8990ed87823f@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <WjbVrrjlwa6wJw57f2FNXrGvqUUaRdwylCjEI0g1URI=.afc15190-599c-4c3f-9e0f-8990ed87823f@github.com>
Message-ID: <9YbB0gtUIqE5SAmbAMmVC_S8wNDa9kKPVop6uvKUxCY=.e000ded5-fcb8-42f9-bde7-97cd1f52ecf9@github.com>

On Mon, 26 Aug 2024 02:07:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I understand the cost overhead experienced by any individual Java run may be lost in the noise, but it still impacts every single Java run just to save some time/resources for the handful of builders of statically linked VMs. I am not a fan.

I understand your stance and it's a fair principle. My opinion is that we need to weigh the pros and cons with more nuance. We are often in situations where have to weigh runtime performance against things like (openjdk) developer convenience, maintainability and build performance. As we are building the Java platform, we often give up a lot to eek out the last drops of runtime performance, but we sure aren't always making that tradeoff in favor of performance. As a very clear example, we could enable LTO (Link Time Optimization), which would likely give a measurable (though likely small) performance improvement at runtime, at the cost of a big increase in build time, but we haven't, because we don't think the tradeoff is worth it. My take on the current issue is that the potential savings in build time is easily comparable to using LTO or not, while the difference in runtime performance is likely different by orders of magnitudes. My point is that we make these kinds of calls quite 
 often.

So in this case, my take is that even if the size difference in the number of people impacted is big, I think the size difference in the actual impact more than makes up for it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2315348318

From ihse at openjdk.org  Wed Aug 28 15:01:33 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Aug 2024 15:01:33 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v4]
In-Reply-To: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
Message-ID: <KgBC60i5kAAsmyHiUnWuP1Plcv3nh2nOIW8g9LNKhrM=.5c75079b-84c8-44f9-b9f3-4e307d21bd1f@github.com>

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix ppc64

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20733/files
  - new: https://git.openjdk.org/jdk/pull/20733/files/7d3bf0d7..69a6b308

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=02-03

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20733/head:pull/20733

PR: https://git.openjdk.org/jdk/pull/20733

From ihse at openjdk.org  Wed Aug 28 15:12:34 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Aug 2024 15:12:34 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v5]
In-Reply-To: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
Message-ID: <eJTrcLr8Y5nK_QXxwjrC_AXgKauaiauboNjmO9_QeHE=.0d553f03-7ebb-4ff7-a2c6-5093e78c507e@github.com>

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix s390x build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20733/files
  - new: https://git.openjdk.org/jdk/pull/20733/files/69a6b308..f4bdce72

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=03-04

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20733/head:pull/20733

PR: https://git.openjdk.org/jdk/pull/20733

From ihse at openjdk.org  Wed Aug 28 15:12:34 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Aug 2024 15:12:34 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v5]
In-Reply-To: <kj31yN6Llw0LfS6uJQTJ2mmIDBz5IvFHVNQVjWAwMjY=.6f0b5244-a1b8-480e-bfb1-5189444bb34e@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
 <T4rqV_-AyEo5Xvecfu1ffRwYjFdyAFpP7vu9xsBofFk=.c55de0dc-2c01-40e6-a73c-7120c74589c2@github.com>
 <Wh_ehv03iycRbr8kc8OJpaa8NnL3IUeNxUNLcqe7aRE=.8d2dd737-0832-4aab-a3de-554094fe9b4f@github.com>
 <kj31yN6Llw0LfS6uJQTJ2mmIDBz5IvFHVNQVjWAwMjY=.6f0b5244-a1b8-480e-bfb1-5189444bb34e@github.com>
Message-ID: <CHHurrG_t_PlepqZYEZDoxJUvFEb9gyRpv2j4GWmX78=.3e38360e-8a82-44e7-8ba0-466530396d33@github.com>

On Wed, 28 Aug 2024 12:29:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Good point, I'll try that.
>
> It turned out to be sort-of okay-ish. I explicitly listed like 6 or so per-file exclusions in Hotspot (even though my normal cutoff for just setting a component-wide exclude is 3-4) since it seems that you will want to look at and fix those.

Actually, it was probably a bad idea. I've been chasing platform-specific build failures for the last hour or so. :( But now at least it is done. I hope you guys can use this to actually fix the problems so it was worth it. ;-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20733#discussion_r1734869178

From ihse at openjdk.org  Wed Aug 28 15:12:34 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Aug 2024 15:12:34 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v3]
In-Reply-To: <CYdPaXV4225As6MAyJ7HXXm3km8SwG6Jqbc_8Qhb2gw=.bf7b3427-0ae8-4705-8bf1-26310ad929ea@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
 <8Z0-2COIwtT2yDoSU8DkeNh2NbBOg7LZhFCEqtJzLOI=.83df3ab0-da2f-4b81-ab72-6091924ffdc1@github.com>
 <CYdPaXV4225As6MAyJ7HXXm3km8SwG6Jqbc_8Qhb2gw=.bf7b3427-0ae8-4705-8bf1-26310ad929ea@github.com>
Message-ID: <GCeXNsH3kFHr6aWWGr4EFYCKj-1D-pat3f6DpKjgkQM=.5d34adec-5180-48f2-a73c-2c6a7f5eca3e@github.com>

On Wed, 28 Aug 2024 13:35:19 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix aarch54
>
> make/modules/java.desktop/lib/ClientLibraries.gmk line 284:
> 
>> 282: 
>> 283: ifeq ($(USE_EXTERNAL_HARFBUZZ), true)
>> 284:   LIBFONTMANAGER_EXTRA_SRC =
> 
> I think this 3space -> 2space indentation change shouldn't be part of this PR, esp. since 3space is
> used in other parts of this file.

Really? That is sooo broken. :( But fair enough, I'll do a separate PR on the broken indentation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20733#discussion_r1734867997

From kbarrett at openjdk.org  Wed Aug 28 15:17:52 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 28 Aug 2024 15:17:52 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v6]
In-Reply-To: <O-r-qYjq4hOO6wR08EZgDB_wNd2XDP-kFfkWToEv5Ig=.cae8eedd-9dba-433e-8e56-198e56bf73af@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
 <O-r-qYjq4hOO6wR08EZgDB_wNd2XDP-kFfkWToEv5Ig=.cae8eedd-9dba-433e-8e56-198e56bf73af@github.com>
Message-ID: <AGU85m2KKLxP9maWuwpt7XYjylhqg7ha5W-skjWyHvc=.fa1483d5-8898-402a-9719-42c056dd771c@github.com>

On Wed, 28 Aug 2024 15:15:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
>> 
>> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Roll back indentation fix

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20733#pullrequestreview-2266590446

From ihse at openjdk.org  Wed Aug 28 15:17:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Aug 2024 15:17:52 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v6]
In-Reply-To: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
Message-ID: <O-r-qYjq4hOO6wR08EZgDB_wNd2XDP-kFfkWToEv5Ig=.cae8eedd-9dba-433e-8e56-198e56bf73af@github.com>

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Roll back indentation fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20733/files
  - new: https://git.openjdk.org/jdk/pull/20733/files/f4bdce72..88654b97

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=04-05

  Stats: 35 lines in 1 file changed: 0 ins; 0 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/20733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20733/head:pull/20733

PR: https://git.openjdk.org/jdk/pull/20733

From jwaters at openjdk.org  Wed Aug 28 15:34:20 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 28 Aug 2024 15:34:20 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v6]
In-Reply-To: <O-r-qYjq4hOO6wR08EZgDB_wNd2XDP-kFfkWToEv5Ig=.cae8eedd-9dba-433e-8e56-198e56bf73af@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
 <O-r-qYjq4hOO6wR08EZgDB_wNd2XDP-kFfkWToEv5Ig=.cae8eedd-9dba-433e-8e56-198e56bf73af@github.com>
Message-ID: <y2q_LRB8SAoGsnPo-t3nLaUnqfdAR-DeBYz0a85s4cY=.73b4f9cb-589a-4e10-b288-29cf1f01aedf@github.com>

On Wed, 28 Aug 2024 15:17:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
>> 
>> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Roll back indentation fix

Marked as reviewed by jwaters (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20733#pullrequestreview-2266632564

From mli at openjdk.org  Wed Aug 28 15:39:22 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 28 Aug 2024 15:39:22 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v3]
In-Reply-To: <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com>
 <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
Message-ID: <t1Vf2gbhpH56zaw95nD2_Z6U1YvvMexTEqQdaCbZaMs=.8f252e78-39a2-4936-b6ee-0dbcac97f09c@github.com>

On Thu, 27 Jun 2024 22:03:37 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately. This enhancement adds the relevant files, enabling the rest of [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward.
>
> Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update README to include RISC-V

By understanding the previous discussion, there should be 2 parts of source code related to sleef integrated into jdk: 
1]. original sleef source
2]. pre-processed sleef header files

Besides of above sources, there should be another part connecting above 2 parts, i.e. 
3]. scripts to transfering from 1] to 2], and necessary documents, e.g. record which tag of sleef to use, .


So, for the source layout/organization, the previous conclusion is to have both 1] and 2], and 1] is just for verification and reproducing, general build of jdk only needs 2].

As to where to put various new files, I think current location for 2] in this pr is good, 1] could be put somewhere with minimum impact on current build system, `src/utils/sleef` suggested by @magicus is a good candidate, 3] should be put together with 1].
In summary, one solution could be as below:

${JDK_ROOT}/src
  |-- utils/
      |-- sleef-src/   # i.e. part 1]
           |-- ... # original sleef source, we could trim or not trim the src tree. 
      |-- sleef-misc/
          |-- createSleef.sh    # accept a sleef source root(i.e. part 1], or an external sleef repo location) as input, and generate sleef header files(i.e. part 2] )
          |-- sleef.md
          |-- ..  # other misc files, e.g. 
  |-- jdk.incubator.vector/linux/native/libvectormath      # i.e. part 2]
      |-- README  # also including a reference pointing to src/utils/sleef*
      |-- misc.h
      |-- sleefinline_advsimd.h
      |-- sleefinline_rvvm1.h
      |-- sleefinline_sve.h


As for which part of original sleef source to integreate into jdk, we could trim the original source in some way, but I think it's more simple and maintainable to just put all sleef source into jdk without any trim.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2315693943

From jiangli at openjdk.org  Wed Aug 28 17:19:23 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 28 Aug 2024 17:19:23 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <W4_qu1WmI5dVU7jOS1ppECKBnPdT_OjW0Qo5ZLDJyQo=.9ca295d5-ce8e-44f1-af69-027d3df54ffc@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <BeiZn9bGbf4QnQp1NK-ICE4UMOWfQ69W9OFDi3wYrfo=.dbea5276-6770-4b67-8f4b-a1bd8ebd355b@github.com>
 <W4_qu1WmI5dVU7jOS1ppECKBnPdT_OjW0Qo5ZLDJyQo=.9ca295d5-ce8e-44f1-af69-027d3df54ffc@github.com>
Message-ID: <bhEaZtx3yqF8AHILP18elpVqLQKcnyrlrc9LKoMaMu0=.8562a11a-5bf7-4e9c-9168-d0697278b977@github.com>

On Tue, 27 Aug 2024 23:15:03 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> And the discussion whether the checks are made "dynamically" or "statically" is too simplified to be really helpful.
>> 
>> Currently, we compile two sets of all object files, with slightly different compiler arguments, one for dynamic libraries and one for static libraries. Files that are doing things differently for these two modes have an #ifdef, so the alternative way of doing things are not included in the object file. 
>> 
>> In your branch, you still have a separate compilation of all files for static builds, but you also try to figure out through various means (which involves jumping through some hoops to get the bootstrapping right) if this is a static build or a dynamic build. In a way, one could argue that this is just worse than the current solution, since you are still recompiling all files separately for static libraries so you could "know" at build time if you are static or not.
>> 
>> What I am trying to do is to get to a point where we can compile almost all files just once, and then have two trivially small files that are compiled twice, with just a different value of a define that makes the difference. To propagate this information to all other object files, they need to call the function provided in this object file. So, is it then a "build time" lookup or a "runtime lookup", or a "static lookup" vs "dynamic lookup"? The semantics does not really matter. The whole point is that the difference in build is reduced to an absolute minimum. Sure, this single "lookup" function could be created more like the way you are doing in your branch to try to figure this out without the help of the build system, but there is really no point in that. This is a simple and elegant solution.
>
> @magicus please also specify contributor properly to so it's clear part of the change is based on/extracted from https://github.com/openjdk/leyden/tree/hermetic-java-runtime.

> @jianglizhou Are there any other authors on the `hermetic-java-runtime` branch that should be credited?

For any commits in https://github.com/openjdk/leyden/compare/master...hermetic-java-runtime contributed by other contributor(s) or additional contributor(s), I documented that the commit message (e.g. https://github.com/openjdk/leyden/commit/4faa3a964ec550e410c741048c7e0ed99ac64b52). The current PR is related to the following. Please refer to those commit messages.

- https://github.com/openjdk/leyden/commit/7d75a7f4d6aa020b7580fbbf660b2b3e3a41b274
- https://github.com/openjdk/leyden/commit/22d8c439157b61acdfe99090d39f91c09388b1b1

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2315882065

From erikj at openjdk.org  Wed Aug 28 19:36:19 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 28 Aug 2024 19:36:19 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v6]
In-Reply-To: <O-r-qYjq4hOO6wR08EZgDB_wNd2XDP-kFfkWToEv5Ig=.cae8eedd-9dba-433e-8e56-198e56bf73af@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
 <O-r-qYjq4hOO6wR08EZgDB_wNd2XDP-kFfkWToEv5Ig=.cae8eedd-9dba-433e-8e56-198e56bf73af@github.com>
Message-ID: <QbwTh_Qzgj4o-CKhBYF33ichnJLXVX5RvY_Z2a0OhY4=.f6964407-a5c3-4307-b083-140cefa7d23c@github.com>

On Wed, 28 Aug 2024 15:17:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
>> 
>> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Roll back indentation fix

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20733#pullrequestreview-2267102496

From erikj at openjdk.org  Wed Aug 28 19:39:21 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 28 Aug 2024 19:39:21 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v3]
In-Reply-To: <t1Vf2gbhpH56zaw95nD2_Z6U1YvvMexTEqQdaCbZaMs=.8f252e78-39a2-4936-b6ee-0dbcac97f09c@github.com>
References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com>
 <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
 <t1Vf2gbhpH56zaw95nD2_Z6U1YvvMexTEqQdaCbZaMs=.8f252e78-39a2-4936-b6ee-0dbcac97f09c@github.com>
Message-ID: <YI9HxSNrgweWDUz24c_DuaTu7p_9--m0gRyO9h3zoFM=.f8271873-ae92-4b18-9ef0-20681757a879@github.com>

On Wed, 28 Aug 2024 15:36:41 GMT, Hamlin Li <mli at openjdk.org> wrote:

> 3]. scripts to transfering from 1] to 2], and necessary documents, e.g. record which tag of sleef to use, .

In addition to the tag, we should include the full git hash as well. A tag can be moved, but it's very hard to fake a new git hash for a commit if any changes are made.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2316110825

From mli at openjdk.org  Wed Aug 28 20:21:21 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 28 Aug 2024 20:21:21 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v3]
In-Reply-To: <YI9HxSNrgweWDUz24c_DuaTu7p_9--m0gRyO9h3zoFM=.f8271873-ae92-4b18-9ef0-20681757a879@github.com>
References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com>
 <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
 <t1Vf2gbhpH56zaw95nD2_Z6U1YvvMexTEqQdaCbZaMs=.8f252e78-39a2-4936-b6ee-0dbcac97f09c@github.com>
 <YI9HxSNrgweWDUz24c_DuaTu7p_9--m0gRyO9h3zoFM=.f8271873-ae92-4b18-9ef0-20681757a879@github.com>
Message-ID: <9b-SpqS-THo5Abs9r8jXg8tUmJJYNGGse7UqB0T92NE=.18123b4f-4e3a-4585-a802-9146ba0c2966@github.com>

On Wed, 28 Aug 2024 19:36:28 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > 3]. scripts to transfering from 1] to 2], and necessary documents, e.g. record which tag of sleef to use, .
> 
> In addition to the tag, we should include the full git hash as well. A tag can be moved, but it's very hard to fake a new git hash for a commit if any changes are made.

I agree, thanks for reminding! I also updated my comment above.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2316178220

From ihse at openjdk.org  Thu Aug 29 07:32:21 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 29 Aug 2024 07:32:21 GMT
Subject: Integrated: 8339120: Use more fine-granular gcc unused warnings
In-Reply-To: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
Message-ID: <Qm02HXx8S59SmKB7eiZfw3CPSU-emBr3GMjaXS3DSfI=.c704e468-dc4d-4d65-ab56-74cd42b9b57c@github.com>

On Tue, 27 Aug 2024 20:04:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

This pull request has now been integrated.

Changeset: 362f9ce0
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/362f9ce077baa900ed81a0473ec0187efde132ef
Stats:     61 lines in 17 files changed: 39 ins; 0 del; 22 mod

8339120: Use more fine-granular gcc unused warnings

Reviewed-by: jwaters, kbarrett, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/20733

From ihse at openjdk.org  Thu Aug 29 08:29:20 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 29 Aug 2024 08:29:20 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
Message-ID: <rTdJslX26f6JU-5aDKAg7RE2eASsK8rZ5lFQnRnHfSM=.6a7ff6b7-eb57-4593-a710-16517805b34b@github.com>

On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not.
>> 
>> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. 
>> 
>> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update build to link properly

Okay. Unless I misunderstand something, there were no additional authors to be credited for these two commits.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2317008624

From ihse at openjdk.org  Thu Aug 29 09:07:45 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 29 Aug 2024 09:07:45 GMT
Subject: RFR: 8339235: Fix indentation in build system
Message-ID: <rtNtR-GuYui8rn6mSsY4us4qAFrBb9rAEdRHtm3rHjA=.17e803f6-38e9-415b-b775-a683d849a150@github.com>

The indentation in the build system should be two spaces for logical indents, and four spaces for broken lines, period.

I searched for files starting with an odd number of spaces, and fixed those.

-------------

Commit messages:
 - Merge branch 'master' into fix-bad-indentation
 - 8339235: Fix indentation in build system

Changes: https://git.openjdk.org/jdk/pull/20763/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20763&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339235
  Stats: 122 lines in 25 files changed: 12 ins; 1 del; 109 mod
  Patch: https://git.openjdk.org/jdk/pull/20763.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20763/head:pull/20763

PR: https://git.openjdk.org/jdk/pull/20763

From stefank at openjdk.org  Thu Aug 29 09:31:21 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 29 Aug 2024 09:31:21 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
Message-ID: <BVUpj-RjVqUVV4F9IJnR-lKhg0YywsLdBDXrY65Wch8=.17bf1d03-fbdf-4cf6-8968-10b6c98b031c@github.com>

On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bit counts in GCForwarding

src/hotspot/share/cds/archiveHeapWriter.cpp line 214:

> 212:       oopDesc::set_mark(mem, markWord::prototype());
> 213:       oopDesc::release_set_klass(mem, k);
> 214:     }

The `UseCompactObjectHeaders` path calls `get_requested_narrow_klass`, while the `else` part directly uses `k`. Is one of these paths incorrect?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1735881613

From stuefe at openjdk.org  Thu Aug 29 11:40:25 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 29 Aug 2024 11:40:25 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
Message-ID: <D6FeNJzWSRs-UNHDF0ZVnjY3fcQlBINuIuAFZQs-Wzw=.7ad105c7-0da9-4a39-9bab-cffeee7ee8f4@github.com>

On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bit counts in GCForwarding

src/hotspot/share/cds/archiveHeapWriter.hpp line 261:

> 259:   //    at mapping start, these 4G are enough. Therefore, we don't need to shift at all (shift=0).
> 260:   static constexpr int precomputed_narrow_klass_shift = 0;
> 261: 

Reviewer Note: move to ArchiveBuilder

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1736042302

From ihse at openjdk.org  Thu Aug 29 12:25:21 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 29 Aug 2024 12:25:21 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v3]
In-Reply-To: <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com>
 <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
Message-ID: <UxFTU-rzRmzhJtpqUJlFZf8irZ5VE1_4jKX5Fw1LG9A=.46ccf043-3ea7-4a9e-9543-1ffa0ed54d1e@github.com>

On Thu, 27 Jun 2024 22:03:37 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately. This enhancement adds the relevant files, enabling the rest of [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward.
>
> Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update README to include RISC-V

After thinking a bit more on this, I would recommend a somewhat different layout:


${JDK_ROOT}/src
  |-- jdk.incubator.vector/linux/native/libsleef
      |-- README.md
      |-- upstream/ 
           |-- ... # original sleef source (trimmed or not)
      |-- generated/
           |-- misc.h
           |-- sleefinline_advsimd.h
           |-- sleefinline_rvvm1.h
           |-- sleefinline_sve.h
  |-- jdk.incubator.vector/linux/legal/libsleef.md


`jdk.incubator.vector/linux/legal/libsleef.md` needs to contain the libsleef
license; see other legal/*.md files for reference.

The README.md file should briefly but clearly explain how we handle libsleef
code in the JDK, explain how to update the generated files, and describe
from where the source was obtained and at what git tag+hash.

In the build system, we will then add jdk.incubator.vector/linux/native/libsleef/generated as an additional source root when building libvectormath.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2317500698
PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2317501858

From ihse at openjdk.org  Thu Aug 29 12:42:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 29 Aug 2024 12:42:23 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v3]
In-Reply-To: <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com>
 <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
Message-ID: <vMVYZ4AdTtSSvF9iiM3YjfCdDwti-ocZxSl-_MTXvBA=.677691cb-f43e-444b-bda5-73527b07b9b8@github.com>

On Thu, 27 Jun 2024 22:03:37 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately. This enhancement adds the relevant files, enabling the rest of [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward.
>
> Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update README to include RISC-V

Furthermore, despite what Erik said above, I would really, really like to not have a stand-alone shell script mixed in with the spleef sources. Instead, we should treat updating the generated spleef sources as any other build-related activities, that is, we should have a build target for that.

I imagine we would have a `make update-spleef-source` that calls into UpdateSpleefSource.gmk. This in turn will more or less call `cmake` with the proper arguments needed to build spleef, and copy the resulting files into the `generated` directory.

The prerequisites required for doing this, e.g. having cmake available (and possibly any other requirements?) should be checked by configure. 

There are two slightly different nuances on how we handle these dependencies: We could either add a `--enable-spleef-updating` argument to configure, which will fail configure if some dependencies are missing, and if will be responsible for making the `update-spleef-source` target available. (This would have a typical true/false/auto setup, so the target will be available if you happen to have all requirements present.)

The other alternative, if the one above would be too much, is to just set the dependencies in configure if they are found, and then verify in UpdateSpleefSource.gmk that they are non-empty (and fail with an error otherwise). This is contrary to the general design of the build system, but might be acceptable in a special case like this, to gain a bit of simplicity in the code.

I can help you with the build system changes, if what I wrote above made no sense to you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2317538370
PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2317539214

From erikj at openjdk.org  Thu Aug 29 12:51:21 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 29 Aug 2024 12:51:21 GMT
Subject: RFR: 8339235: Fix indentation in build system
In-Reply-To: <rtNtR-GuYui8rn6mSsY4us4qAFrBb9rAEdRHtm3rHjA=.17e803f6-38e9-415b-b775-a683d849a150@github.com>
References: <rtNtR-GuYui8rn6mSsY4us4qAFrBb9rAEdRHtm3rHjA=.17e803f6-38e9-415b-b775-a683d849a150@github.com>
Message-ID: <EASXydfIpPlv-gskyjbKmucE9HowAC2WQI0iuj46yu8=.46fda391-eec0-46c1-af47-00a0c5cea5e6@github.com>

On Thu, 29 Aug 2024 09:02:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The indentation in the build system should be two spaces for logical indents, and four spaces for broken lines, period.
> 
> I searched for files starting with an odd number of spaces, and fixed those.

Thanks for fixing this! See two nits. Also for anyone wondering, we defined these conventions for the build system a long time ago: https://openjdk.org/groups/build/doc/code-conventions.html

make/CompileJavaModules.gmk line 78:

> 76: CreateHkTargets = \
> 77:     $(call FilterExcludedTranslations, \
> 78:       $(patsubst $(TOPDIR)/src/%, $(JDK_OUTPUTDIR)/modules/%, \

Isn't this a continuation?

make/autoconf/boot-jdk.m4 line 609:

> 607:         BUILD_JDK_FOUND=maybe
> 608:         AC_MSG_NOTICE([Found potential Build JDK using configure arguments])
> 609:       fi

And here?

-------------

PR Review: https://git.openjdk.org/jdk/pull/20763#pullrequestreview-2268621402
PR Review Comment: https://git.openjdk.org/jdk/pull/20763#discussion_r1736133668
PR Review Comment: https://git.openjdk.org/jdk/pull/20763#discussion_r1736134938

From erikj at openjdk.org  Thu Aug 29 12:57:21 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 29 Aug 2024 12:57:21 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v3]
In-Reply-To: <vMVYZ4AdTtSSvF9iiM3YjfCdDwti-ocZxSl-_MTXvBA=.677691cb-f43e-444b-bda5-73527b07b9b8@github.com>
References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com>
 <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
 <vMVYZ4AdTtSSvF9iiM3YjfCdDwti-ocZxSl-_MTXvBA=.677691cb-f43e-444b-bda5-73527b07b9b8@github.com>
Message-ID: <tA54jsNJj1vHiaHPl7N4rJCkPi56QEhKGsjnieswJoc=.a739b8a4-a99e-499b-8c62-66e861a9b8b9@github.com>

On Thu, 29 Aug 2024 12:39:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Furthermore, despite what Erik said above, I would really, really like to not have a stand-alone shell script mixed in with the spleef sources. Instead, we should treat updating the generated spleef sources as any other build-related activities, that is, we should have a build target for that.

I'm ok with this as you are offering to help implement it. My suggestion for using a separate script was out of simplicity and an assumed lack of resourcing for a more involved solution. Your suggested solution would generally be a better end result.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2317580781

From ihse at openjdk.org  Thu Aug 29 13:20:21 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 29 Aug 2024 13:20:21 GMT
Subject: RFR: 8339235: Fix indentation in build system
In-Reply-To: <EASXydfIpPlv-gskyjbKmucE9HowAC2WQI0iuj46yu8=.46fda391-eec0-46c1-af47-00a0c5cea5e6@github.com>
References: <rtNtR-GuYui8rn6mSsY4us4qAFrBb9rAEdRHtm3rHjA=.17e803f6-38e9-415b-b775-a683d849a150@github.com>
 <EASXydfIpPlv-gskyjbKmucE9HowAC2WQI0iuj46yu8=.46fda391-eec0-46c1-af47-00a0c5cea5e6@github.com>
Message-ID: <yKZ9cPX_28aqnX51e64VHXVwZRi_FjqGLgAt2TCn-U8=.cfd6a645-4a87-49de-a1c9-a0296cdb5a35@github.com>

On Thu, 29 Aug 2024 12:43:45 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> The indentation in the build system should be two spaces for logical indents, and four spaces for broken lines, period.
>> 
>> I searched for files starting with an odd number of spaces, and fixed those.
>
> make/CompileJavaModules.gmk line 78:
> 
>> 76: CreateHkTargets = \
>> 77:     $(call FilterExcludedTranslations, \
>> 78:       $(patsubst $(TOPDIR)/src/%, $(JDK_OUTPUTDIR)/modules/%, \
> 
> Isn't this a continuation?

Yep. I missed that. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20763#discussion_r1736193343

From ihse at openjdk.org  Thu Aug 29 13:24:31 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 29 Aug 2024 13:24:31 GMT
Subject: RFR: 8339235: Fix indentation in build system [v2]
In-Reply-To: <rtNtR-GuYui8rn6mSsY4us4qAFrBb9rAEdRHtm3rHjA=.17e803f6-38e9-415b-b775-a683d849a150@github.com>
References: <rtNtR-GuYui8rn6mSsY4us4qAFrBb9rAEdRHtm3rHjA=.17e803f6-38e9-415b-b775-a683d849a150@github.com>
Message-ID: <Zzg07KiHfWioBaitN9IF43RCFrTwkXo0SvOdkKqL4r8=.041cceb0-4522-40e3-a7f1-b3c960e5ca1b@github.com>

> The indentation in the build system should be two spaces for logical indents, and four spaces for broken lines, period.
> 
> I searched for files starting with an odd number of spaces, and fixed those.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix incorrect indentation type

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20763/files
  - new: https://git.openjdk.org/jdk/pull/20763/files/061a80b6..7c92160e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20763&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20763&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20763.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20763/head:pull/20763

PR: https://git.openjdk.org/jdk/pull/20763

From ihse at openjdk.org  Thu Aug 29 13:24:32 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 29 Aug 2024 13:24:32 GMT
Subject: RFR: 8339235: Fix indentation in build system [v2]
In-Reply-To: <EASXydfIpPlv-gskyjbKmucE9HowAC2WQI0iuj46yu8=.46fda391-eec0-46c1-af47-00a0c5cea5e6@github.com>
References: <rtNtR-GuYui8rn6mSsY4us4qAFrBb9rAEdRHtm3rHjA=.17e803f6-38e9-415b-b775-a683d849a150@github.com>
 <EASXydfIpPlv-gskyjbKmucE9HowAC2WQI0iuj46yu8=.46fda391-eec0-46c1-af47-00a0c5cea5e6@github.com>
Message-ID: <iUq8Pn5B_HPILQAOllQr-oaU4QPEdOHVl2KMdXrzGp0=.658b9e7d-da2e-48c0-8ad0-9cee2e564815@github.com>

On Thu, 29 Aug 2024 12:44:29 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix incorrect indentation type
>
> make/autoconf/boot-jdk.m4 line 609:
> 
>> 607:         BUILD_JDK_FOUND=maybe
>> 608:         AC_MSG_NOTICE([Found potential Build JDK using configure arguments])
>> 609:       fi
> 
> And here?

Actually, I think this is correct. The block is logically indented inside the `([` and `])` start-of-block and end-of-block markers. Kind of the same reasons as all m4 macros (as created by `AC_DEFUN`) is indented two spaces, and not four.

We have precedence for this pattern elsewhere as well, e.g. at line 240 in this file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20763#discussion_r1736199904

From mli at openjdk.org  Thu Aug 29 13:55:21 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 29 Aug 2024 13:55:21 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v3]
In-Reply-To: <UxFTU-rzRmzhJtpqUJlFZf8irZ5VE1_4jKX5Fw1LG9A=.46ccf043-3ea7-4a9e-9543-1ffa0ed54d1e@github.com>
References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com>
 <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
 <UxFTU-rzRmzhJtpqUJlFZf8irZ5VE1_4jKX5Fw1LG9A=.46ccf043-3ea7-4a9e-9543-1ffa0ed54d1e@github.com>
Message-ID: <TRPvVCpp-5MghZlYapfhCpIH-kQYPUCD_x_JfmIIbw8=.1a442ffc-a567-48d5-94ae-f93bb35fed41@github.com>

On Thu, 29 Aug 2024 12:22:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> ```
> ${JDK_ROOT}/src
>   |-- jdk.incubator.vector/linux/native/libsleef
>       |-- README.md
>       |-- upstream/ 
>            |-- ... # original sleef source (trimmed or not)
>       |-- generated/
>            |-- misc.h
>            |-- sleefinline_advsimd.h
>            |-- sleefinline_rvvm1.h
>            |-- sleefinline_sve.h
>   |-- jdk.incubator.vector/linux/legal/libsleef.md
> ```

Thanks, this is much better.

> Furthermore, despite what Erik said above, I would really, really like to not have a stand-alone shell script mixed in with the spleef sources. Instead, we should treat updating the generated spleef sources as any other build-related activities, that is, we should have a build target for that.
> ...
> There are two slightly different nuances on how we handle these dependencies.

I'm ok too with either of solutions.
Only reminding is that we should treat sleef build/source-generation as a blackbox.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2317727274

From ihse at openjdk.org  Thu Aug 29 14:21:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 29 Aug 2024 14:21:54 GMT
Subject: RFR: 8339156: Use more fine-granular clang unused warnings
Message-ID: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>

Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.

We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

This is similar to what has been done for gcc in JDK-8339120.

-------------

Commit messages:
 - 8339156: Use more fine-granular clang unused warnings

Changes: https://git.openjdk.org/jdk/pull/20770/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20770&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339156
  Stats: 60 lines in 16 files changed: 42 ins; 1 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/20770.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20770/head:pull/20770

PR: https://git.openjdk.org/jdk/pull/20770

From jiangli at openjdk.org  Thu Aug 29 15:00:21 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 29 Aug 2024 15:00:21 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <rTdJslX26f6JU-5aDKAg7RE2eASsK8rZ5lFQnRnHfSM=.6a7ff6b7-eb57-4593-a710-16517805b34b@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <rTdJslX26f6JU-5aDKAg7RE2eASsK8rZ5lFQnRnHfSM=.6a7ff6b7-eb57-4593-a710-16517805b34b@github.com>
Message-ID: <WDs803DQdxoaBmK4lKspnKzkgy3YAKzHU5VnXUU0U6Y=.d345bccd-03ee-43fe-9333-1ee967fd509a@github.com>

On Thu, 29 Aug 2024 08:26:16 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Okay. Unless I misunderstand something, there were no additional authors to be credited for these two commits.

That's correct for these.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2317982354

From ihse at openjdk.org  Thu Aug 29 15:12:48 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 29 Aug 2024 15:12:48 GMT
Subject: RFR: 8338404: Cross-compilation to different endianness fails after
 JDK-8318913
Message-ID: <n85K7VLMkyr3ettQrwohTDuF85bEI9pz4LI5oIcn6Pk=.e4e4ebac-f573-469e-9d92-7f5d7529c451@github.com>

>From the bug report:

After JDK-8318913, trying to cross-compile to a different endian target than the build host is using, will cause the interim image generation to fail:


[buildjdk] Creating interim jimage
Error: specified --endian LITTLE_ENDIAN does not match endianness of target platform linux-s390
java.io.IOException: specified --endian LITTLE_ENDIAN does not match endianness of target platform linux-s390
        at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:574)
        at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:410)
        at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:285)
        at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
        at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
InterimImage.gmk:47: recipe for target '/localhome/git/jdk-BAR/build/linux-s390x/support/interim-image/bin/java' failed


This has only been spotted when cross-compiling from x64 to s390x, but it seems to be a general endianness problem.

---

In fact, it was technically a problem with how we generate all interim images, but apparently the platform mistake did not affect jlink apart from when cross-compiling and the endianness was off.

-------------

Commit messages:
 - Adjust OS name for macosx
 - 8338404: Cross-compilation to different endianness fails after JDK-8318913

Changes: https://git.openjdk.org/jdk/pull/20750/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20750&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338404
  Stats: 20 lines in 2 files changed: 15 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20750.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20750/head:pull/20750

PR: https://git.openjdk.org/jdk/pull/20750

From ihse at openjdk.org  Thu Aug 29 15:12:48 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 29 Aug 2024 15:12:48 GMT
Subject: RFR: 8338404: Cross-compilation to different endianness fails
 after JDK-8318913
In-Reply-To: <n85K7VLMkyr3ettQrwohTDuF85bEI9pz4LI5oIcn6Pk=.e4e4ebac-f573-469e-9d92-7f5d7529c451@github.com>
References: <n85K7VLMkyr3ettQrwohTDuF85bEI9pz4LI5oIcn6Pk=.e4e4ebac-f573-469e-9d92-7f5d7529c451@github.com>
Message-ID: <ZGSWNil1s7s9UxPatC0cz8Aq_BhKBN5GYCSPVIERBko=.1197b41a-57b4-4176-8e14-03c85e8bbf92@github.com>

On Wed, 28 Aug 2024 14:49:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> From the bug report:
> 
> After JDK-8318913, trying to cross-compile to a different endian target than the build host is using, will cause the interim image generation to fail:
> 
> 
> [buildjdk] Creating interim jimage
> Error: specified --endian LITTLE_ENDIAN does not match endianness of target platform linux-s390
> java.io.IOException: specified --endian LITTLE_ENDIAN does not match endianness of target platform linux-s390
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:574)
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:410)
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:285)
>         at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
>         at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
> InterimImage.gmk:47: recipe for target '/localhome/git/jdk-BAR/build/linux-s390x/support/interim-image/bin/java' failed
> 
> 
> This has only been spotted when cross-compiling from x64 to s390x, but it seems to be a general endianness problem.
> 
> ---
> 
> In fact, it was technically a problem with how we generate all interim images, but apparently the platform mistake did not affect jlink apart from when cross-compiling and the endianness was off.

This has been verified to solve the cross-compilation problem on s390x, and has passed sanity tests on all other platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20750#issuecomment-2318029068

From erikj at openjdk.org  Thu Aug 29 16:49:20 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 29 Aug 2024 16:49:20 GMT
Subject: RFR: 8339235: Fix indentation in build system [v2]
In-Reply-To: <Zzg07KiHfWioBaitN9IF43RCFrTwkXo0SvOdkKqL4r8=.041cceb0-4522-40e3-a7f1-b3c960e5ca1b@github.com>
References: <rtNtR-GuYui8rn6mSsY4us4qAFrBb9rAEdRHtm3rHjA=.17e803f6-38e9-415b-b775-a683d849a150@github.com>
 <Zzg07KiHfWioBaitN9IF43RCFrTwkXo0SvOdkKqL4r8=.041cceb0-4522-40e3-a7f1-b3c960e5ca1b@github.com>
Message-ID: <urHFopCm1-9NID1Rmb0WVZ1IkNiiKc8cU7ACCVVyfDg=.f9387c60-e631-44dd-934c-78de4973f2e0@github.com>

On Thu, 29 Aug 2024 13:24:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The indentation in the build system should be two spaces for logical indents, and four spaces for broken lines, period.
>> 
>> I searched for files starting with an odd number of spaces, and fixed those.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix incorrect indentation type

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20763#pullrequestreview-2269488694

From erikj at openjdk.org  Thu Aug 29 16:53:19 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 29 Aug 2024 16:53:19 GMT
Subject: RFR: 8339156: Use more fine-granular clang unused warnings
In-Reply-To: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
References: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
Message-ID: <jaXduuwskjnlK5V0p_Lk6xv6f9A_V9axTA9Kc4pVGNs=.873196ed-6f57-465a-9bd6-5e3f9c41294b@github.com>

On Thu, 29 Aug 2024 13:14:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
> 
> This is similar to what has been done for gcc in JDK-8339120.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20770#pullrequestreview-2269506759

From erikj at openjdk.org  Thu Aug 29 16:57:19 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 29 Aug 2024 16:57:19 GMT
Subject: RFR: 8338404: Cross-compilation to different endianness fails
 after JDK-8318913
In-Reply-To: <n85K7VLMkyr3ettQrwohTDuF85bEI9pz4LI5oIcn6Pk=.e4e4ebac-f573-469e-9d92-7f5d7529c451@github.com>
References: <n85K7VLMkyr3ettQrwohTDuF85bEI9pz4LI5oIcn6Pk=.e4e4ebac-f573-469e-9d92-7f5d7529c451@github.com>
Message-ID: <0YwWzEzXJvORkXoFhQESj6A-m0CXIDCFTusmL_Amd6k=.58d4bad6-1cf6-4c5d-9450-2785783a49a3@github.com>

On Wed, 28 Aug 2024 14:49:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> From the bug report:
> 
> After JDK-8318913, trying to cross-compile to a different endian target than the build host is using, will cause the interim image generation to fail:
> 
> 
> [buildjdk] Creating interim jimage
> Error: specified --endian LITTLE_ENDIAN does not match endianness of target platform linux-s390
> java.io.IOException: specified --endian LITTLE_ENDIAN does not match endianness of target platform linux-s390
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:574)
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:410)
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:285)
>         at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
>         at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
> InterimImage.gmk:47: recipe for target '/localhome/git/jdk-BAR/build/linux-s390x/support/interim-image/bin/java' failed
> 
> 
> This has only been spotted when cross-compiling from x64 to s390x, but it seems to be a general endianness problem.
> 
> ---
> 
> In fact, it was technically a problem with how we generate all interim images, but apparently the platform mistake did not affect jlink apart from when cross-compiling and the endianness was off.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20750#pullrequestreview-2269518877

From fbredberg at openjdk.org  Thu Aug 29 18:12:20 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 29 Aug 2024 18:12:20 GMT
Subject: RFR: 8338404: Cross-compilation to different endianness fails
 after JDK-8318913
In-Reply-To: <n85K7VLMkyr3ettQrwohTDuF85bEI9pz4LI5oIcn6Pk=.e4e4ebac-f573-469e-9d92-7f5d7529c451@github.com>
References: <n85K7VLMkyr3ettQrwohTDuF85bEI9pz4LI5oIcn6Pk=.e4e4ebac-f573-469e-9d92-7f5d7529c451@github.com>
Message-ID: <Y8W2tv2d6lAUP0oQ6w6pAZm4e2GBQ5GxC74e_dkP2p0=.a6bf3962-6f38-40b7-8faa-0b3399ca5c30@github.com>

On Wed, 28 Aug 2024 14:49:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> From the bug report:
> 
> After JDK-8318913, trying to cross-compile to a different endian target than the build host is using, will cause the interim image generation to fail:
> 
> 
> [buildjdk] Creating interim jimage
> Error: specified --endian LITTLE_ENDIAN does not match endianness of target platform linux-s390
> java.io.IOException: specified --endian LITTLE_ENDIAN does not match endianness of target platform linux-s390
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:574)
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:410)
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:285)
>         at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
>         at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
> InterimImage.gmk:47: recipe for target '/localhome/git/jdk-BAR/build/linux-s390x/support/interim-image/bin/java' failed
> 
> 
> This has only been spotted when cross-compiling from x64 to s390x, but it seems to be a general endianness problem.
> 
> ---
> 
> In fact, it was technically a problem with how we generate all interim images, but apparently the platform mistake did not affect jlink apart from when cross-compiling and the endianness was off.

Looks good to me. But most importantly, it works for me. Thanks!

-------------

Marked as reviewed by fbredberg (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20750#pullrequestreview-2269732254

From kbarrett at openjdk.org  Thu Aug 29 18:48:20 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 29 Aug 2024 18:48:20 GMT
Subject: RFR: 8339156: Use more fine-granular clang unused warnings
In-Reply-To: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
References: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
Message-ID: <GK2LiZr5-psH4LxqYJzOeT7eY3lq5T7z0K1TueGzn2Q=.144dd5fd-8192-4a3e-884f-50d118a9fc06@github.com>

On Thu, 29 Aug 2024 13:14:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
> 
> This is similar to what has been done for gcc in JDK-8339120.

Looks good.

make/autoconf/flags-cflags.m4 line 266:

> 264:       # These warnings will never be turned on, since they generate too many
> 265:       # false positives.
> 266:       DISABLED_WARNINGS="unknown-warning-option unused-parameter"

JDK-8339120 added -Wunused-const-variable=1 and -Wunused-result to gcc's
WARNINGS_ENABLE_ADDITIONAL, to "make up" for the corresponding removal of
disabling -Wunused. That isn't done here. I assume that was intentional,
probably to avoid needing more of the specific disables in this PR. That's
fine. We can do more warning option cleanups later in conjunction with
corresponding code changes.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20770#pullrequestreview-2269819308
PR Review Comment: https://git.openjdk.org/jdk/pull/20770#discussion_r1736918417

From ihse at openjdk.org  Thu Aug 29 20:43:20 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 29 Aug 2024 20:43:20 GMT
Subject: RFR: 8339156: Use more fine-granular clang unused warnings
In-Reply-To: <GK2LiZr5-psH4LxqYJzOeT7eY3lq5T7z0K1TueGzn2Q=.144dd5fd-8192-4a3e-884f-50d118a9fc06@github.com>
References: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
 <GK2LiZr5-psH4LxqYJzOeT7eY3lq5T7z0K1TueGzn2Q=.144dd5fd-8192-4a3e-884f-50d118a9fc06@github.com>
Message-ID: <jKYklFcR9lbszuS_j1drGdjjLFjay1E5-0T1IuuFC5E=.1216db2a-d72b-43ec-a980-90dd3b6eb70e@github.com>

On Thu, 29 Aug 2024 18:44:22 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
>> 
>> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
>> 
>> This is similar to what has been done for gcc in JDK-8339120.
>
> make/autoconf/flags-cflags.m4 line 266:
> 
>> 264:       # These warnings will never be turned on, since they generate too many
>> 265:       # false positives.
>> 266:       DISABLED_WARNINGS="unknown-warning-option unused-parameter"
> 
> JDK-8339120 added -Wunused-const-variable=1 and -Wunused-result to gcc's
> WARNINGS_ENABLE_ADDITIONAL, to "make up" for the corresponding removal of
> disabling -Wunused. That isn't done here. I assume that was intentional,
> probably to avoid needing more of the specific disables in this PR. That's
> fine. We can do more warning option cleanups later in conjunction with
> corresponding code changes.

No, it was just not needed by clang. `-Wunused-result` is enabled by `-Wunused-value` which is enabled by `-Wunused` which is enabled by `-Wall`. Or something like that. I think it made sense, but the documentation was bad so you had to jump around to understand how things were related.

`Wunused-const-variable=1` does not exist in clang, but whatever the closest matching thing was, was enabled as well indirectly already.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20770#discussion_r1737153568

From iklam at openjdk.org  Thu Aug 29 22:35:22 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 29 Aug 2024 22:35:22 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <BVUpj-RjVqUVV4F9IJnR-lKhg0YywsLdBDXrY65Wch8=.17bf1d03-fbdf-4cf6-8968-10b6c98b031c@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <BVUpj-RjVqUVV4F9IJnR-lKhg0YywsLdBDXrY65Wch8=.17bf1d03-fbdf-4cf6-8968-10b6c98b031c@github.com>
Message-ID: <3M4XT4BaiowyWjJhSoFBREh9e-Be2B6L4tHVAXKw5VQ=.7647e788-8d7d-4e05-91f3-509c6fbd0d3c@github.com>

On Thu, 29 Aug 2024 09:28:50 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bit counts in GCForwarding
>
> src/hotspot/share/cds/archiveHeapWriter.cpp line 214:
> 
>> 212:       oopDesc::set_mark(mem, markWord::prototype());
>> 213:       oopDesc::release_set_klass(mem, k);
>> 214:     }
> 
> The `UseCompactObjectHeaders` path calls `get_requested_narrow_klass`, while the `else` part directly uses `k`. Is one of these paths incorrect?

This seems odd. The original code sets `Universe::objectArrayKlass()` into the object header. This is the value of this class in the current JVM lifetime.

Later, `ArchiveHeapWriter::update_header_for_requested_obj()` would change the object's klass to the "requested" address. I.e., where this class will be loaded in a future JVM lifetime when the CDS archive is loaded into memory.

It seems the same logic should be used in the `UseCompactObjectHeaders==true` case.

BTW (unrelated to this PR) the comment a few lines up is outdated and wrong:


Klass* k = Universe::objectArrayKlass(); // already relocated to point to archived klass


`k` is the value of the *actual* location of this class in the current JVM lifetime. Please ignore this comment when trying to understand this function.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1737294872

From ihse at openjdk.org  Thu Aug 29 23:13:21 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 29 Aug 2024 23:13:21 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v3]
In-Reply-To: <8cIGwT38AWUYMa_wtSSBmE16BCJbipyG_tFBeW3tzL8=.5ad181bd-ab04-4a5c-a9a2-b16e4bdcd554@github.com>
References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com>
 <UbmhsQZfRkrrnO1UzH21ozr6Xaq4UP_WrgySwd1ItsI=.29372823-91e1-4992-8b5b-c914eb1fa310@github.com>
 <geN8VMoF-kDepFi3AYS7wzBk7SxI-nZiD5-Vtx6cnVw=.023d7d59-27e6-4370-bd0b-787a3f143095@github.com>
 <7bKMs0Na_OgNIOnzHF9baDK8E_EXPbtd6ZFVUWHVH9o=.ace95434-f086-46f5-9368-07573941cbe1@github.com>
 <KNs7ooCESzInOClcv_W92KJRqFeEUFhX2d9vbdgqbB4=.1b9ef0e9-aeb5-4bcb-9bb2-c4b59e988bd7@github.com>
 <8cIGwT38AWUYMa_wtSSBmE16BCJbipyG_tFBeW3tzL8=.5ad181bd-ab04-4a5c-a9a2-b16e4bdcd554@github.com>
Message-ID: <31W-PGgd2iqFejvLOapPcIdIi8AQwE0o6yA_93TznAo=.0b6df088-a531-4093-b827-14f8364bd166@github.com>

On Tue, 27 Aug 2024 22:37:01 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> @vidmik Thanks for pushing forward this work.
>> Sure, I can take the work.
>> 
>> Just several questions, Sorry, as this is the first time I do this kind of work in jdk.
>> In this pr, we already have the pre-generated sleef files and the scripts to generate it, what we are missing is the sleef original file (in my understanding, we also need to checkin them), besides of sleef original files, do we need any other files or document? In particular, do you mind to clarify further about `plan/logic` mentioned above?
>
> @Hamlin-Li Thank you for taking it on!
> 
> Part of the work is figuring out exactly what exactly we want - see the comments from @erikj79 and @theRealAph in this PR for inspiration. In particular, we'll want to include all or part of the SLEEF sources in the JDK, but we'll likely also want some additional build scripts and documentation to make it easy for developers to reproduce and update going forward. This could probably be based on the README and createSleef script.

@vidmik @Hamlin-Li I kind of hijacked this... 

I created the necessary build system changes to update the generated sleef code. At that point, also importing the actual source code was just a trivial addition.

The new PR is here: https://github.com/openjdk/jdk/pull/20781

I think it implements everything we've talked about here, in the way I understood consensus to be.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2319340361

From alanb at openjdk.org  Fri Aug 30 04:40:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 Aug 2024 04:40:20 GMT
Subject: RFR: 8339156: Use more fine-granular clang unused warnings
In-Reply-To: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
References: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
Message-ID: <1lG4XEx1lF8Hu6csMsC9jNvDImrf9Pd5_xblOGlOyh4=.26a4c1cc-cc26-4581-8236-107ec28fe840@github.com>

On Thu, 29 Aug 2024 13:14:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
> 
> This is similar to what has been done for gcc in JDK-8339120.

I wonder if there should be JBS issues for the specific source files/warnings so they can be looked at more closely (or maybe you've looked at them all already). Just wondering about the maintainability of DISABLED_WARNINGS_xxx values that list specific files as I assume they can bit rot quickly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20770#issuecomment-2320021124

From kbarrett at openjdk.org  Fri Aug 30 05:09:18 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 30 Aug 2024 05:09:18 GMT
Subject: RFR: 8339156: Use more fine-granular clang unused warnings
In-Reply-To: <1lG4XEx1lF8Hu6csMsC9jNvDImrf9Pd5_xblOGlOyh4=.26a4c1cc-cc26-4581-8236-107ec28fe840@github.com>
References: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
 <1lG4XEx1lF8Hu6csMsC9jNvDImrf9Pd5_xblOGlOyh4=.26a4c1cc-cc26-4581-8236-107ec28fe840@github.com>
Message-ID: <ncITSE1Vu3Ct9KiNcU2z19oYGsrapHuPSIfvibE1NJ8=.080efae6-8a96-4da2-a273-c41ba706f887@github.com>

On Fri, 30 Aug 2024 04:37:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I wonder if there should be JBS issues for the specific source files/warnings so they can be looked at more closely (or maybe you've looked at them all already). Just wondering about the maintainability of DISABLED_WARNINGS_xxx values that list specific files as I assume they can bit rot quickly.

The idea, from the build component POV, is that teams responsible for the various parts of the code where warnings
are being suppressed are responsible for filing issues to address them and scheduling the work to do so.  Different
teams have different approaches to backlog issues, how they prioritize them, and whether they keep them open or
close as WNF because they don't see getting to them for a long time, if ever.  I personally dislike the last approach,
but it's not under my control.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20770#issuecomment-2320065831

From stefank at openjdk.org  Fri Aug 30 07:30:22 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 30 Aug 2024 07:30:22 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v3]
In-Reply-To: <ySywujYrcJzmYZtj5oflhcQZbzxPv78dm29gJ5B1fqE=.31b98908-bc0f-48af-b67a-75e7351d1b74@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <bKtmNAMLqRlWTG9MBcosxeh2rYNK_yx_gkh_qbNKt6s=.e23c8a75-0072-4c9f-8d8e-7db14826fded@github.com>
 <ySywujYrcJzmYZtj5oflhcQZbzxPv78dm29gJ5B1fqE=.31b98908-bc0f-48af-b67a-75e7351d1b74@github.com>
Message-ID: <eFA0oBxF9AwGNg6r016aErf6_DSRH0Ca-gCKyYudO2o=.5a535692-d46e-4891-b16b-6d2c6ae3f39f@github.com>

On Thu, 22 Aug 2024 17:30:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove hashcode leftovers from SA
>
> src/hotspot/share/gc/serial/serialArguments.cpp line 33:
> 
>> 31: void SerialArguments::initialize_heap_flags_and_sizes() {
>> 32:   GenArguments::initialize_heap_flags_and_sizes();
>> 33:   GCForwarding::initialize_flags(MaxNewSize + MaxOldSize);
> 
> Can one use `MaxHeapSize` here?

Good catch. This is actually a bug that is causing the CDS tests to fail. The used variables have not yet been initialized at this point. I tried making the suggested change and that fixed at least one of the CDS failures.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1738101667

From stefank at openjdk.org  Fri Aug 30 07:30:23 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 30 Aug 2024 07:30:23 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v5]
In-Reply-To: <-G_gdaZBT2xhZFsdyEwIqiOHpbLpiL79N6NDsW8X2BY=.bc52bd8a-21c5-40e7-a921-a5f68675200f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TzmQRM_6QAc9tdMzNYnzSPR_nENrokTzNx2q-TPuWpw=.cfcbe6f4-4397-4c31-be73-d5a456618090@github.com>
 <-G_gdaZBT2xhZFsdyEwIqiOHpbLpiL79N6NDsW8X2BY=.bc52bd8a-21c5-40e7-a921-a5f68675200f@github.com>
Message-ID: <BarC_59LJpof-lBzklJ8Dm8liOxnh6jr9cbCn6-NCTI=.64c466f7-c527-44e0-9f5f-2c6928e6a436@github.com>

On Thu, 22 Aug 2024 19:36:00 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix hash shift for 32 bit builds
>
> src/hotspot/share/gc/shared/gcForwarding.cpp line 37:
> 
>> 35:   size_t max_narrow_heap_size = right_n_bits(NumLowBitsNarrow - Shift);
>> 36:   if (UseCompactObjectHeaders && max_heap_size > max_narrow_heap_size * HeapWordSize) {
>> 37:     FLAG_SET_DEFAULT(UseCompactObjectHeaders, false);
> 
> Maybe a log-info/warning would be nice.

Yes. This silent setting of UseCompactObjectHeaders ended up hiding why we got CDS failures. I would also suggest that we change this to FLAG_SET_ERGO.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1738104783

From stuefe at openjdk.org  Fri Aug 30 07:40:23 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 30 Aug 2024 07:40:23 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <JEzJGLkDHhgNGFns5-xLFV1TGH2-EkzWd568IcAO1Rg=.b48dc38e-57a9-4e4f-b512-fc86efdb77c4@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <JEzJGLkDHhgNGFns5-xLFV1TGH2-EkzWd568IcAO1Rg=.b48dc38e-57a9-4e4f-b512-fc86efdb77c4@github.com>
Message-ID: <YlpC3YUY4jE9Qb4Et5SqUc3q16AkDrY3b9-mXSMKzSg=.dd4d0fd4-ffac-42b8-83f5-639f3a930f8c@github.com>

On Fri, 23 Aug 2024 16:23:19 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bit counts in GCForwarding
>
> make/Images.gmk line 135:
> 
>> 133: #
>> 134: # Param1 - VM variant (e.g., server, client, zero, ...)
>> 135: # Param2 - _nocoops, _coh, _nocoops_coh, or empty
> 
> The -XX:+UseCompactObjectHeaders ssems to incompatible withe zero vm. The zero vm build start failing while generating shared archive with +UseCompactObjectHeaders. Generation should be disabled by default for zero to don't break the build.

No, zero works with +COH, but a small change is needed. I'll post a suggestion inline.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1738119614

From stuefe at openjdk.org  Fri Aug 30 07:45:19 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 30 Aug 2024 07:45:19 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v3]
In-Reply-To: <eFA0oBxF9AwGNg6r016aErf6_DSRH0Ca-gCKyYudO2o=.5a535692-d46e-4891-b16b-6d2c6ae3f39f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <bKtmNAMLqRlWTG9MBcosxeh2rYNK_yx_gkh_qbNKt6s=.e23c8a75-0072-4c9f-8d8e-7db14826fded@github.com>
 <ySywujYrcJzmYZtj5oflhcQZbzxPv78dm29gJ5B1fqE=.31b98908-bc0f-48af-b67a-75e7351d1b74@github.com>
 <eFA0oBxF9AwGNg6r016aErf6_DSRH0Ca-gCKyYudO2o=.5a535692-d46e-4891-b16b-6d2c6ae3f39f@github.com>
Message-ID: <Jwh871WmMQFGiJuKUYzWPWPJprr9n0CZRz-eJUnxTp8=.23bd8a24-d5b4-476b-973f-bf5196b4f7a1@github.com>

On Fri, 30 Aug 2024 07:25:54 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/gc/serial/serialArguments.cpp line 33:
>> 
>>> 31: void SerialArguments::initialize_heap_flags_and_sizes() {
>>> 32:   GenArguments::initialize_heap_flags_and_sizes();
>>> 33:   GCForwarding::initialize_flags(MaxNewSize + MaxOldSize);
>> 
>> Can one use `MaxHeapSize` here?
>
> Good catch. This is actually a bug that is causing the CDS tests to fail. The used variables have not yet been initialized at this point. I tried making the suggested change and that fixed at least one of the CDS failures.

Yes, one must, since MaxNewSize and MaxOldSize are still on their initial values, so way too large to allow the GC forwarding, and therefore CompactObjectHeaders get automatically disabled for SerialGC. That explains a bunch of the problems @lmesnik saw.

This fixes SerialGC for me:
Suggestion:

  GCForwarding::initialize_flags(MaxHeapSize);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1738123826

From stuefe at openjdk.org  Fri Aug 30 07:45:20 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 30 Aug 2024 07:45:20 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v5]
In-Reply-To: <BarC_59LJpof-lBzklJ8Dm8liOxnh6jr9cbCn6-NCTI=.64c466f7-c527-44e0-9f5f-2c6928e6a436@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TzmQRM_6QAc9tdMzNYnzSPR_nENrokTzNx2q-TPuWpw=.cfcbe6f4-4397-4c31-be73-d5a456618090@github.com>
 <-G_gdaZBT2xhZFsdyEwIqiOHpbLpiL79N6NDsW8X2BY=.bc52bd8a-21c5-40e7-a921-a5f68675200f@github.com>
 <BarC_59LJpof-lBzklJ8Dm8liOxnh6jr9cbCn6-NCTI=.64c466f7-c527-44e0-9f5f-2c6928e6a436@github.com>
Message-ID: <3QGPH52NyrDPne5EgoGx2sx9OeGRu9K72onNNwzMr2M=.8a390b3d-2e8a-470e-8bb7-1ba975070c53@github.com>

On Fri, 30 Aug 2024 07:27:45 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/gcForwarding.cpp line 37:
>> 
>>> 35:   size_t max_narrow_heap_size = right_n_bits(NumLowBitsNarrow - Shift);
>>> 36:   if (UseCompactObjectHeaders && max_heap_size > max_narrow_heap_size * HeapWordSize) {
>>> 37:     FLAG_SET_DEFAULT(UseCompactObjectHeaders, false);
>> 
>> Maybe a log-info/warning would be nice.
>
> Yes. This silent setting of UseCompactObjectHeaders ended up hiding why we got CDS failures. I would also suggest that we change this to FLAG_SET_ERGO.

Seems we run all into the same thoughts :)

I added

Suggestion:

    FLAG_SET_DEFAULT(UseCompactObjectHeaders, false);
    warning("Compact object headers require a java heap size smaller than %zu (given: %zu). "
                 "Disabling compact object headers.", max_narrow_heap_size * HeapWordSize, max_heap_size);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1738127194

From stefank at openjdk.org  Fri Aug 30 08:10:21 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 30 Aug 2024 08:10:21 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
Message-ID: <ppEMUrlGXfCRo9oZPRt0xf_FrD3-pv5SjJh8eBoe3TU=.92c19564-443c-41d0-b047-0a9a7c6dad10@github.com>

On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bit counts in GCForwarding

src/hotspot/share/cds/filemap.cpp line 2507:

> 2505:   }
> 2506: 
> 2507:   if (compact_headers() != UseCompactObjectHeaders) {

(Commenting here, but the comment applies to code a bit above) While debugging CDS, it would have been useful to print the value of UseCompactObjectHeaders.

Could we change the code to be:

  log_info(cds)("Archive was created with UseCompressedOops = %d, UseCompressedClassPointers = %d, UseCompactObjectHeaders = %d",
                          compressed_oops(), compressed_class_pointers(), compact_headers());

src/hotspot/share/cds/filemap.cpp line 2508:

> 2506: 
> 2507:   if (compact_headers() != UseCompactObjectHeaders) {
> 2508:     log_info(cds)("The shared archive file's UseCompactObjectHeaders setting (%s)"

Printing on the `info` level mimics what we do when there's a mismatch for compressed classes (and oops), but I wonder if that one is intentional or if it is accidentally printing to 'info' instead of 'warning'.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1738164792
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1738166832

From ihse at openjdk.org  Fri Aug 30 09:00:27 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Aug 2024 09:00:27 GMT
Subject: Integrated: 8338404: Cross-compilation to different endianness fails
 after JDK-8318913
In-Reply-To: <n85K7VLMkyr3ettQrwohTDuF85bEI9pz4LI5oIcn6Pk=.e4e4ebac-f573-469e-9d92-7f5d7529c451@github.com>
References: <n85K7VLMkyr3ettQrwohTDuF85bEI9pz4LI5oIcn6Pk=.e4e4ebac-f573-469e-9d92-7f5d7529c451@github.com>
Message-ID: <olULDYIi1CW-yOF3NuqnRh_JExOyQe-wjUFzcWoh0TQ=.876dae23-ad5f-4a33-bd31-f4afb98e355f@github.com>

On Wed, 28 Aug 2024 14:49:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> From the bug report:
> 
> After JDK-8318913, trying to cross-compile to a different endian target than the build host is using, will cause the interim image generation to fail:
> 
> 
> [buildjdk] Creating interim jimage
> Error: specified --endian LITTLE_ENDIAN does not match endianness of target platform linux-s390
> java.io.IOException: specified --endian LITTLE_ENDIAN does not match endianness of target platform linux-s390
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:574)
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:410)
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:285)
>         at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
>         at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
> InterimImage.gmk:47: recipe for target '/localhome/git/jdk-BAR/build/linux-s390x/support/interim-image/bin/java' failed
> 
> 
> This has only been spotted when cross-compiling from x64 to s390x, but it seems to be a general endianness problem.
> 
> ---
> 
> In fact, it was technically a problem with how we generate all interim images, but apparently the platform mistake did not affect jlink apart from when cross-compiling and the endianness was off.

This pull request has now been integrated.

Changeset: bb28b0d2
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bb28b0d2292c0f45decfaac0fb2f4c4284e9c666
Stats:     20 lines in 2 files changed: 15 ins; 0 del; 5 mod

8338404: Cross-compilation to different endianness fails after JDK-8318913

Reviewed-by: erikj, fbredberg

-------------

PR: https://git.openjdk.org/jdk/pull/20750

From ihse at openjdk.org  Fri Aug 30 09:03:31 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Aug 2024 09:03:31 GMT
Subject: Integrated: 8339235: Fix indentation in build system
In-Reply-To: <rtNtR-GuYui8rn6mSsY4us4qAFrBb9rAEdRHtm3rHjA=.17e803f6-38e9-415b-b775-a683d849a150@github.com>
References: <rtNtR-GuYui8rn6mSsY4us4qAFrBb9rAEdRHtm3rHjA=.17e803f6-38e9-415b-b775-a683d849a150@github.com>
Message-ID: <Utoc0RptIFaGaDk8CfofztIU_ZoGO_-d06GOEoGHug8=.98dd8cd5-53ed-470f-b00b-fc96f49cd9c0@github.com>

On Thu, 29 Aug 2024 09:02:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The indentation in the build system should be two spaces for logical indents, and four spaces for broken lines, period.
> 
> I searched for files starting with an odd number of spaces, and fixed those.

This pull request has now been integrated.

Changeset: 2abe2ff6
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2abe2ff69b205ccaf502bf8b6de3ce9e1260c386
Stats:     123 lines in 25 files changed: 12 ins; 1 del; 110 mod

8339235: Fix indentation in build system

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/20763

From alanb at openjdk.org  Fri Aug 30 10:07:23 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 Aug 2024 10:07:23 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
Message-ID: <sTrTkqq0pYei2TvKybXAvMcxFs49UdBgRkzAZTpWR5g=.669af597-8982-4ea6-9a91-b58144656c44@github.com>

On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not.
>> 
>> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. 
>> 
>> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update build to link properly

I think the approach is pragmatic and okay. I agree it looks a bit unusual to be testing the image type at runtime but it doesn't seem to be measurable and not a concern right now. In the future, I suspect we will have many places in the libraries that will need to test this at runtime for 30+ other reasons.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20666#pullrequestreview-2271829178

From ihse at openjdk.org  Fri Aug 30 10:54:20 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Aug 2024 10:54:20 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <WjbVrrjlwa6wJw57f2FNXrGvqUUaRdwylCjEI0g1URI=.afc15190-599c-4c3f-9e0f-8990ed87823f@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <WjbVrrjlwa6wJw57f2FNXrGvqUUaRdwylCjEI0g1URI=.afc15190-599c-4c3f-9e0f-8990ed87823f@github.com>
Message-ID: <eQv90nmAArKzh8kjaZ1oGg5jInJTI6J7jxJ8sjIxEXI=.a8ba6456-c192-44eb-8bad-f6ee245239e8@github.com>

On Mon, 26 Aug 2024 02:07:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Also update build to link properly
>
> I understand the cost overhead experienced by any individual Java run may be lost in the noise, but it still impacts every single Java run just to save some time/resources for the handful of builders of statically linked VMs. I am not a fan.

@dholmes-ora This PR now has three reviewers approving it. You say you are "not a fan". Does this mean you want to veto this change? Or can you be willing to accept it, even if you do not like it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2320832777

From stefank at openjdk.org  Fri Aug 30 11:10:23 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 30 Aug 2024 11:10:23 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v3]
In-Reply-To: <ySywujYrcJzmYZtj5oflhcQZbzxPv78dm29gJ5B1fqE=.31b98908-bc0f-48af-b67a-75e7351d1b74@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <bKtmNAMLqRlWTG9MBcosxeh2rYNK_yx_gkh_qbNKt6s=.e23c8a75-0072-4c9f-8d8e-7db14826fded@github.com>
 <ySywujYrcJzmYZtj5oflhcQZbzxPv78dm29gJ5B1fqE=.31b98908-bc0f-48af-b67a-75e7351d1b74@github.com>
Message-ID: <CjcHSbAikUEXe-wpmu-p2od4z6IN-QC54DCKL5hSaZY=.85532a31-e607-447b-8cea-80e97024f994@github.com>

On Thu, 22 Aug 2024 17:12:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove hashcode leftovers from SA
>
> src/hotspot/share/gc/serial/defNewGeneration.cpp line 707:
> 
>> 705:       } else if (obj->is_forwarded()) {
>> 706:         // To restore the klass-bits in the header.
>> 707:         obj->forward_safe_init_mark();
> 
> I wonder if not modifying successful-forwarded objs is cleaner. Sth like:
> 
> 
> reset_self_forwarded_in_space(space) {
>   cur = space->bottom();
>   top = space->top();
> 
>   while (cur < top) {
>     obj = cast_to_oop(cur);
> 
>     if (obj->is_self_forwarded()) {
>       obj->unset_self_forwarded();
>       obj_size = obj->size();
>     } else {
>       assert(obj->is_forwarded(), "inv");
>       obj_size = obj->forwardee()->size();
>     }
> 
>     cur += obj_size;
>   }
> }
> 
> reset_self_forwarded_in_space(eden());
> reset_self_forwarded_in_space(from());

I was thinking the same, but there's a problem with that. If we get a promotion failure in the young gen, we are leaving the dead objects marked as forwarded. Then when the Full GC scans these regions with dead objects it will mistakenly think that they have been marked alive because `is_forwarded() == is_gc_marked()`. The code in `phase2_calculate_new_addr` will then break when it looks for `is_gc_marked` objects.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1738433303

From stefank at openjdk.org  Fri Aug 30 11:18:20 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 30 Aug 2024 11:18:20 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v3]
In-Reply-To: <CjcHSbAikUEXe-wpmu-p2od4z6IN-QC54DCKL5hSaZY=.85532a31-e607-447b-8cea-80e97024f994@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <bKtmNAMLqRlWTG9MBcosxeh2rYNK_yx_gkh_qbNKt6s=.e23c8a75-0072-4c9f-8d8e-7db14826fded@github.com>
 <ySywujYrcJzmYZtj5oflhcQZbzxPv78dm29gJ5B1fqE=.31b98908-bc0f-48af-b67a-75e7351d1b74@github.com>
 <CjcHSbAikUEXe-wpmu-p2od4z6IN-QC54DCKL5hSaZY=.85532a31-e607-447b-8cea-80e97024f994@github.com>
Message-ID: <VGJOzveV1b0KxnQ_lSugtMP7boOK5TPmiYT7QXgcCoM=.780e110d-491c-4bbc-9ee7-a7db237ee9dc@github.com>

On Fri, 30 Aug 2024 11:07:46 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/gc/serial/defNewGeneration.cpp line 707:
>> 
>>> 705:       } else if (obj->is_forwarded()) {
>>> 706:         // To restore the klass-bits in the header.
>>> 707:         obj->forward_safe_init_mark();
>> 
>> I wonder if not modifying successful-forwarded objs is cleaner. Sth like:
>> 
>> 
>> reset_self_forwarded_in_space(space) {
>>   cur = space->bottom();
>>   top = space->top();
>> 
>>   while (cur < top) {
>>     obj = cast_to_oop(cur);
>> 
>>     if (obj->is_self_forwarded()) {
>>       obj->unset_self_forwarded();
>>       obj_size = obj->size();
>>     } else {
>>       assert(obj->is_forwarded(), "inv");
>>       obj_size = obj->forwardee()->size();
>>     }
>> 
>>     cur += obj_size;
>>   }
>> }
>> 
>> reset_self_forwarded_in_space(eden());
>> reset_self_forwarded_in_space(from());
>
> I was thinking the same, but there's a problem with that. If we get a promotion failure in the young gen, we are leaving the dead objects marked as forwarded. Then when the Full GC scans these regions with dead objects it will mistakenly think that they have been marked alive because `is_forwarded() == is_gc_marked()`. The code in `phase2_calculate_new_addr` will then break when it looks for `is_gc_marked` objects.

FWIW, the ParallelGC does something very similar to what you propose, except that it walks bitmaps instead of paring the space to find the self-forwarded objects. It then has a check inside object_iterate to make sure that it doesn't expose the dead objects (in eden and the from space) to heap dumpers and histogram printers.

Because of the the code above, the SerialGC clears away the information about what objects are dead in eden and the from space, so heap dumpers and histogram printers will include these dead objects. We might want to fix that as a future RFE.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1738444174

From ihse at openjdk.org  Fri Aug 30 11:35:51 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Aug 2024 11:35:51 GMT
Subject: RFR: 8339156: Use more fine-granular clang unused warnings [v2]
In-Reply-To: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
References: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
Message-ID: <b8OW9mnHcvmbpUGxL2Lz2OH598ndK_MUnup0LOIcDO8=.0918f694-df17-40e2-92db-c064d5329f91@github.com>

> Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
> 
> This is similar to what has been done for gcc in JDK-8339120.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into finegranular-clang-unused
 - 8339156: Use more fine-granular clang unused warnings

-------------

Changes: https://git.openjdk.org/jdk/pull/20770/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20770&range=01
  Stats: 60 lines in 16 files changed: 42 ins; 1 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/20770.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20770/head:pull/20770

PR: https://git.openjdk.org/jdk/pull/20770

From ihse at openjdk.org  Fri Aug 30 11:35:51 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Aug 2024 11:35:51 GMT
Subject: RFR: 8339156: Use more fine-granular clang unused warnings
In-Reply-To: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
References: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
Message-ID: <pMZLlp2I8S-tuWZvmM9vE-WienVIK5IJLN7-gOCm6ec=.0de975f3-bb99-444e-a0fb-2e37c82a5c7d@github.com>

On Thu, 29 Aug 2024 13:14:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
> 
> This is similar to what has been done for gcc in JDK-8339120.

As Kim says. I can pave the way for the component teams to fix the warnings as smoothly as possible, but I cannot and will not try to fix the actual issue. (When I embarked on the journey to try and improve the warning situation, I na?vely tried to fix some "simple" warnings, thinking that would be easier than to turn off the warning... Heh! Just let me say, I'm not doing that again.)

I used to file a JBS issue whenever I disabled a warning on a component, but they were mostly just ignored or closed after several years without any action, so I got tired of doing all the paperwork for nothing.

Maybe we can try to raise some general awareness that teams should check up what warnings they have disabled and see if they can fix them? I know some teams, like client-libs, have tons of warnings, are well aware of the fact, but do not have the manpower to be able to address them. Other teams might just be oblivious to the situations, however, but I have no way to tell which way it is.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20770#issuecomment-2320924437

From ihse at openjdk.org  Fri Aug 30 13:16:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Aug 2024 13:16:18 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1
Message-ID: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>

[JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately.

This is a new attempt at solving [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816); the original attempt is here: https://github.com/openjdk/jdk/pull/19185. This PR is based on the discussions on how to move forward that was held in that original PR.

-------------

Commit messages:
 - Expand tabs to 8 spaces to make jcheck happy
 -  Add generated sources for riscv64
 - Remove executable bit
 - Add generated sources for aarch64
 - Add build support for updating sleef sources
 - Add README
 - Add sleef license in legal
 - * Add source of libsleef 3.6.1

Changes: https://git.openjdk.org/jdk/pull/20781/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20781&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329816
  Stats: 120301 lines in 175 files changed: 120301 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20781.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20781/head:pull/20781

PR: https://git.openjdk.org/jdk/pull/20781

From mli at openjdk.org  Fri Aug 30 13:16:19 2024
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 30 Aug 2024 13:16:19 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1
In-Reply-To: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
References: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
Message-ID: <DQqBrwMD3majJzWahCbW8uMi-VKscc9t1RO41FQua3o=.31adcfb4-029e-4c0c-80d5-c6eb1db9ce49@github.com>

On Thu, 29 Aug 2024 23:07:16 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately.
> 
> This is a new attempt at solving [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816); the original attempt is here: https://github.com/openjdk/jdk/pull/19185. This PR is based on the discussions on how to move forward that was held in that original PR.

Thanks a lot for the quick response and effort!

I'm not qualified to review changes in make files, just have one general question below.

I also checked the git hash, and generated files, they're good.

Can I ask another general question in advance related to [subsequent pr](https://github.com/openjdk/jdk/pull/18605)? As there are several folders (`generated` and `upstream`) under src/jdk.incubator.vector/linux/native/libsleef/ now, what's the recommended way to only include `generated` and skip `upstream` when compile/build the final libsleef.so in that pr?

make/UpdateSleefSource.gmk line 105:

> 103: TARGETS := $(sleef_native_build)
> 104: 
> 105: $(eval $(call SetupExecute, sleef_cross_config, \

Not sure if it's still necessary or right to run the 2 steps build the second time, when native and cross-compilation are the same, e.g. build sve for aarch64 on an aarch64 machine.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20781#pullrequestreview-2271712946
PR Review Comment: https://git.openjdk.org/jdk/pull/20781#discussion_r1738285588

From ihse at openjdk.org  Fri Aug 30 13:16:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Aug 2024 13:16:19 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1
In-Reply-To: <DQqBrwMD3majJzWahCbW8uMi-VKscc9t1RO41FQua3o=.31adcfb4-029e-4c0c-80d5-c6eb1db9ce49@github.com>
References: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
 <DQqBrwMD3majJzWahCbW8uMi-VKscc9t1RO41FQua3o=.31adcfb4-029e-4c0c-80d5-c6eb1db9ce49@github.com>
Message-ID: <a_P0Cl7KkrtjI-oaD8n-_Z80xhHTgrZP-zKAJ6fwluc=.9557dc13-68c2-4bda-b8ee-6088d3d78ae2@github.com>

On Fri, 30 Aug 2024 09:28:59 GMT, Hamlin Li <mli at openjdk.org> wrote:

> As there are several folders (generated and upstream) under src/jdk.incubator.vector/linux/native/libsleef/ now, what's the recommended way to only include generated and skip upstream when compile/build the final libsleef.so in that pr?

Basically, under the `$(eval $(call SetupJdkLibrary, BUILD_LIBVECTORMATH` call, you add the line:

    EXTRA_SRC := libsleef/generated, \

and that should be it. However, I see that you also manipulate compiler flags for individual files. I don't know if that is still needed, or can be removed. Or, conversely, if additional files will need the special flags.

> make/UpdateSleefSource.gmk line 105:
> 
>> 103: TARGETS := $(sleef_native_build)
>> 104: 
>> 105: $(eval $(call SetupExecute, sleef_cross_config, \
> 
> Not sure if it's still necessary or right to run the 2 steps build the second time, when native and cross-compilation are the same, e.g. build sve for aarch64 on an aarch64 machine.

As the documentation says, the update make target only supports cross-compilation. I based this on the shell script created by Mikael, but I guess his reasoning for doing it that way is the same as mine: When an update is needed, you are going to have to do it for all supported platforms, and hence it is easier to cross-compile it to all targets.

Since updating is a very uncommon operation, I prefer to keep the makefile simple.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20781#issuecomment-2320849630
PR Review Comment: https://git.openjdk.org/jdk/pull/20781#discussion_r1738426993

From ihse at openjdk.org  Fri Aug 30 13:16:20 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Aug 2024 13:16:20 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1
In-Reply-To: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
References: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
Message-ID: <BLqTzemWb3NQCtX14KBasaRmPKZr1MxgDOmsI9yM4BQ=.e6889d8d-4d1f-4594-a6ec-e8074e60b778@github.com>

On Thu, 29 Aug 2024 23:07:16 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately.
> 
> This is a new attempt at solving [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816); the original attempt is here: https://github.com/openjdk/jdk/pull/19185. This PR is based on the discussions on how to move forward that was held in that original PR.

Sorry for the force push. The libsleef source code had *tons* of trailing whitespace, and it seems jcheck got stuck on that. The bot had not finished in 12 hours or so. I initially pushed an additional commit that fixed the whitespace, but jcheck goes through the commits one at a time, so that did not help.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20781#issuecomment-2320943487

From mli at openjdk.org  Fri Aug 30 13:16:19 2024
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 30 Aug 2024 13:16:19 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1
In-Reply-To: <a_P0Cl7KkrtjI-oaD8n-_Z80xhHTgrZP-zKAJ6fwluc=.9557dc13-68c2-4bda-b8ee-6088d3d78ae2@github.com>
References: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
 <DQqBrwMD3majJzWahCbW8uMi-VKscc9t1RO41FQua3o=.31adcfb4-029e-4c0c-80d5-c6eb1db9ce49@github.com>
 <a_P0Cl7KkrtjI-oaD8n-_Z80xhHTgrZP-zKAJ6fwluc=.9557dc13-68c2-4bda-b8ee-6088d3d78ae2@github.com>
Message-ID: <Qpxy-45eYk8-i68rxxYDCu1BAxgIcXEFf1Mg_ezrHxw=.dca5a8b1-2ba8-4fc9-bf46-1c513cc08585@github.com>

On Fri, 30 Aug 2024 10:59:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Basically, under the `$(eval $(call SetupJdkLibrary, BUILD_LIBVECTORMATH` call, you add the line:
> 
> ```
>     EXTRA_SRC := libsleef/generated, \
> ```
> 
> and that should be it. 

Thanks!

> However, I see that you also manipulate compiler flags for individual files. I don't know if that is still needed, or can be removed. Or, conversely, if additional files will need the special flags.

OK, let's have discussion in that pr for further details later.

>> make/UpdateSleefSource.gmk line 105:
>> 
>>> 103: TARGETS := $(sleef_native_build)
>>> 104: 
>>> 105: $(eval $(call SetupExecute, sleef_cross_config, \
>> 
>> Not sure if it's still necessary or right to run the 2 steps build the second time, when native and cross-compilation are the same, e.g. build sve for aarch64 on an aarch64 machine.
>
> As the documentation says, the update make target only supports cross-compilation. I based this on the shell script created by Mikael, but I guess his reasoning for doing it that way is the same as mine: When an update is needed, you are going to have to do it for all supported platforms, and hence it is easier to cross-compile it to all targets.
> 
> Since updating is a very uncommon operation, I prefer to keep the makefile simple.

I see, make sense to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20781#issuecomment-2320895996
PR Review Comment: https://git.openjdk.org/jdk/pull/20781#discussion_r1738445738

From erikj at openjdk.org  Fri Aug 30 14:04:22 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 30 Aug 2024 14:04:22 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1
In-Reply-To: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
References: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
Message-ID: <nDMnf9kAWgF2RIzmASz6jlyNtUd_qhdNykb7B9UlFE0=.18ceea30-b5d9-4039-9589-6c5c5480fbcb@github.com>

On Thu, 29 Aug 2024 23:07:16 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately.
> 
> This is a new attempt at solving [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816); the original attempt is here: https://github.com/openjdk/jdk/pull/19185. This PR is based on the discussions on how to move forward that was held in that original PR.

I replicated the generation using the instructions in the readme. It worked but the generated files end up with large whitespace differences, probably because you generated them before cleaning the whitespace in the original sources. If that is the case, could you update the generated files from the exact upstream sources that were committed?

make/UpdateSleefSource.gmk line 38:

> 36: ################################################################################
> 37: # This file is responsible for updating the generated sleef source code files
> 38: # that are checked in to the JDK repo, and that is actually used when building.

Suggestion:

# that are checked in to the JDK repo, and that are actually used when building.

src/jdk.incubator.vector/linux/native/libsleef/README.md line 29:

> 27: `https://github.com/shibatch/sleef.git`, and copy all files, except the `docs`
> 28: and `.github` directories, into
> 29: `src/jdk.incubator.vector/linux/native/libsleef/upstream`.

I think you need to add something about the need for whitespace cleanup here.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20781#pullrequestreview-2272399884
PR Review Comment: https://git.openjdk.org/jdk/pull/20781#discussion_r1738702398
PR Review Comment: https://git.openjdk.org/jdk/pull/20781#discussion_r1738715361

From ihse at openjdk.org  Fri Aug 30 15:51:22 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Aug 2024 15:51:22 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v2]
In-Reply-To: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
References: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
Message-ID: <MkEaTke4WVy_3V__akXtZjfs22iUn8ApHH1mBwcpyyY=.c61bb1e9-50b1-4fde-99be-c16a213285bf@github.com>

> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately.
> 
> This is a new attempt at solving [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816); the original attempt is here: https://github.com/openjdk/jdk/pull/19185. This PR is based on the discussions on how to move forward that was held in that original PR.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Update the generated sources based on the whitespace-fixed upstream source

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20781/files
  - new: https://git.openjdk.org/jdk/pull/20781/files/ccfe566e..c4c58e6c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20781&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20781&range=00-01

  Stats: 603 lines in 3 files changed: 0 ins; 0 del; 603 mod
  Patch: https://git.openjdk.org/jdk/pull/20781.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20781/head:pull/20781

PR: https://git.openjdk.org/jdk/pull/20781

From ihse at openjdk.org  Fri Aug 30 15:56:17 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Aug 2024 15:56:17 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v3]
In-Reply-To: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
References: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
Message-ID: <YjLXTUjNVvCey0jeEPo3h-BY7eMs4b_BFsFPIJ_yFjI=.991d7922-3b9d-40ca-bcb3-56c771037452@github.com>

> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately.
> 
> This is a new attempt at solving [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816); the original attempt is here: https://github.com/openjdk/jdk/pull/19185. This PR is based on the discussions on how to move forward that was held in that original PR.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo
  
  Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20781/files
  - new: https://git.openjdk.org/jdk/pull/20781/files/c4c58e6c..db12b25b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20781&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20781&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20781.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20781/head:pull/20781

PR: https://git.openjdk.org/jdk/pull/20781

From ihse at openjdk.org  Fri Aug 30 16:03:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Aug 2024 16:03:19 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v4]
In-Reply-To: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
References: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
Message-ID: <-zH_fwCKD_PmNXdigApQcfk6KON7z2iggFh9okwXrP0=.4504ce8d-81e4-4eb5-ae12-f40150192ba8@github.com>

> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately.
> 
> This is a new attempt at solving [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816); the original attempt is here: https://github.com/openjdk/jdk/pull/19185. This PR is based on the discussions on how to move forward that was held in that original PR.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  README fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20781/files
  - new: https://git.openjdk.org/jdk/pull/20781/files/db12b25b..6992d5b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20781&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20781&range=02-03

  Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20781.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20781/head:pull/20781

PR: https://git.openjdk.org/jdk/pull/20781

From ihse at openjdk.org  Fri Aug 30 16:03:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Aug 2024 16:03:19 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v4]
In-Reply-To: <nDMnf9kAWgF2RIzmASz6jlyNtUd_qhdNykb7B9UlFE0=.18ceea30-b5d9-4039-9589-6c5c5480fbcb@github.com>
References: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
 <nDMnf9kAWgF2RIzmASz6jlyNtUd_qhdNykb7B9UlFE0=.18ceea30-b5d9-4039-9589-6c5c5480fbcb@github.com>
Message-ID: <7X-_fQHq0GcqzB1m7ZieK51JPh6ZhTsWBZM700LyvQQ=.08d243b6-0240-415b-8dfa-34a147bce99b@github.com>

On Fri, 30 Aug 2024 13:50:11 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   README fixes
>
> src/jdk.incubator.vector/linux/native/libsleef/README.md line 29:
> 
>> 27: `https://github.com/shibatch/sleef.git`, and copy all files, except the `docs`
>> 28: and `.github` directories, into
>> 29: `src/jdk.incubator.vector/linux/native/libsleef/upstream`.
> 
> I think you need to add something about the need for whitespace cleanup here.

Good point. Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20781#discussion_r1739003726

From ihse at openjdk.org  Fri Aug 30 16:03:33 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Aug 2024 16:03:33 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v3]
In-Reply-To: <YjLXTUjNVvCey0jeEPo3h-BY7eMs4b_BFsFPIJ_yFjI=.991d7922-3b9d-40ca-bcb3-56c771037452@github.com>
References: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
 <YjLXTUjNVvCey0jeEPo3h-BY7eMs4b_BFsFPIJ_yFjI=.991d7922-3b9d-40ca-bcb3-56c771037452@github.com>
Message-ID: <IMH-cSyJvLFHXXfj8tnfnAFtdz1mxKxbhAhSv46WvrY=.778c7d33-15d5-42e9-9c93-a56dc9880293@github.com>

On Fri, 30 Aug 2024 15:56:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately.
>> 
>> This is a new attempt at solving [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816); the original attempt is here: https://github.com/openjdk/jdk/pull/19185. This PR is based on the discussions on how to move forward that was held in that original PR.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo
>   
>   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

I have updated the generated files. If you would like to re-try that you can replicate them exactly this time that'd be appreciated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20781#issuecomment-2321757498

From ihse at openjdk.org  Fri Aug 30 16:39:58 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Aug 2024 16:39:58 GMT
Subject: RFR: 8339336: Fix build system whitespace to adhere to coding
 conventions
Message-ID: <c4xtGeV414thJl2ggoO9ZiObIn86CUZwyipYsvp-D1w=.b530223b-f497-4712-8406-406d87cbec6d@github.com>

The build system code has unfortunately diverted in some places from the conventions as described in https://openjdk.org/groups/build/doc/code-conventions.html.

Instead of trying to fix these when touching code nearby, I'd like to make an effort to fix all issues at once and separately. Incremental fixes has their benefit, but they can also muddy the actual fix and are not always appreciated.

The updates in this patch have all been discovered using automated tools, but each and every change has been manually scrutinized. Those that the automatic tools pointed out that, but that were not obviously or clear-cut safe (e.g. adding spaces after comma, in `subst` or similar situations) were reverted before I pushed. I chose to err on the "First, do no harm" side, so there might be places that could have been corrected, but were not. 

I have made a single type of change per commit in this branch. It might be easier to review this by looking at one commit at a time.

-------------

Commit messages:
 - Multi-line lists should have \ on the last line and end with #
 - Make ### delimiters consistent length
 - Setup* calls should end with )) on a separate line
 - Trailing \ should be preceded by space
 - Comma should be followed by space, unless not possible
 - Assignments in Makefiles should be surrounded by space

Changes: https://git.openjdk.org/jdk/pull/20798/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20798&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339336
  Stats: 636 lines in 81 files changed: 27 ins; 10 del; 599 mod
  Patch: https://git.openjdk.org/jdk/pull/20798.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20798/head:pull/20798

PR: https://git.openjdk.org/jdk/pull/20798

From erikj at openjdk.org  Fri Aug 30 16:46:30 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 30 Aug 2024 16:46:30 GMT
Subject: RFR: 8339156: Use more fine-granular clang unused warnings [v2]
In-Reply-To: <b8OW9mnHcvmbpUGxL2Lz2OH598ndK_MUnup0LOIcDO8=.0918f694-df17-40e2-92db-c064d5329f91@github.com>
References: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
 <b8OW9mnHcvmbpUGxL2Lz2OH598ndK_MUnup0LOIcDO8=.0918f694-df17-40e2-92db-c064d5329f91@github.com>
Message-ID: <EWPT7AGQaUN8olIWoahROKnS7mts9XX6WAGJxjEw9bw=.c33d39e3-d1a4-41a2-b25b-b7be6ec005cf@github.com>

On Fri, 30 Aug 2024 11:35:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
>> 
>> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
>> 
>> This is similar to what has been done for gcc in JDK-8339120.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into finegranular-clang-unused
>  - 8339156: Use more fine-granular clang unused warnings

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20770#pullrequestreview-2273037764

From ihse at openjdk.org  Fri Aug 30 16:46:31 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Aug 2024 16:46:31 GMT
Subject: Integrated: 8339156: Use more fine-granular clang unused warnings
In-Reply-To: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
References: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
Message-ID: <jCx-fCeWrT743k3v48tHI3-aLnI988lRRZHFnrSANsE=.e23e66e8-d58d-4571-a431-9522b897ef32@github.com>

On Thu, 29 Aug 2024 13:14:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
> 
> This is similar to what has been done for gcc in JDK-8339120.

This pull request has now been integrated.

Changeset: a528c4b3
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a528c4b370be1e7730778268cf8c52ffcfd27048
Stats:     60 lines in 16 files changed: 42 ins; 1 del; 17 mod

8339156: Use more fine-granular clang unused warnings

Reviewed-by: erikj, kbarrett

-------------

PR: https://git.openjdk.org/jdk/pull/20770

From ihse at openjdk.org  Fri Aug 30 16:57:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Aug 2024 16:57:18 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v5]
In-Reply-To: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
References: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
Message-ID: <B1eOha2lU0yO6zRq-pOeqEKDf5VPhVO7KaTBiR4fBzw=.a1987d89-2d8e-4322-81fd-e8001e9df5d9@github.com>

> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately.
> 
> This is a new attempt at solving [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816); the original attempt is here: https://github.com/openjdk/jdk/pull/19185. This PR is based on the discussions on how to move forward that was held in that original PR.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Use "whitespace" as an uncountable noun
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - I suck at English verb forms
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20781/files
  - new: https://git.openjdk.org/jdk/pull/20781/files/6992d5b6..e5fe681e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20781&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20781&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20781.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20781/head:pull/20781

PR: https://git.openjdk.org/jdk/pull/20781

From erikj at openjdk.org  Fri Aug 30 16:57:20 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 30 Aug 2024 16:57:20 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v4]
In-Reply-To: <-zH_fwCKD_PmNXdigApQcfk6KON7z2iggFh9okwXrP0=.4504ce8d-81e4-4eb5-ae12-f40150192ba8@github.com>
References: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
 <-zH_fwCKD_PmNXdigApQcfk6KON7z2iggFh9okwXrP0=.4504ce8d-81e4-4eb5-ae12-f40150192ba8@github.com>
Message-ID: <F1Vw7D3v9NVyxQBVPlabLKzDOhQC98Z9dIT9p9RE5L8=.d8739302-71be-4141-8ee7-3c20b3ecfce8@github.com>

On Fri, 30 Aug 2024 16:03:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately.
>> 
>> This is a new attempt at solving [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816); the original attempt is here: https://github.com/openjdk/jdk/pull/19185. This PR is based on the discussions on how to move forward that was held in that original PR.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   README fixes

Can confirm that I get no diff when running the update target now.

src/jdk.incubator.vector/linux/native/libsleef/README.md line 31:

> 29: `src/jdk.incubator.vector/linux/native/libsleef/upstream`.
> 30: 
> 31: The libsleef source code do not follow the JDK whitespace rules as enforced by

Suggestion:

The libsleef source code does not follow the JDK whitespace rules as enforced by

src/jdk.incubator.vector/linux/native/libsleef/README.md line 32:

> 30: 
> 31: The libsleef source code do not follow the JDK whitespace rules as enforced by
> 32: jcheck. You will need to remove trailing whitespaces, and expand tabs to 8

Suggestion:

jcheck. You will need to remove trailing whitespace, and expand tabs to 8

-------------

PR Review: https://git.openjdk.org/jdk/pull/20781#pullrequestreview-2273050769
PR Review Comment: https://git.openjdk.org/jdk/pull/20781#discussion_r1739118570
PR Review Comment: https://git.openjdk.org/jdk/pull/20781#discussion_r1739119374

From erikj at openjdk.org  Fri Aug 30 17:04:19 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 30 Aug 2024 17:04:19 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v5]
In-Reply-To: <B1eOha2lU0yO6zRq-pOeqEKDf5VPhVO7KaTBiR4fBzw=.a1987d89-2d8e-4322-81fd-e8001e9df5d9@github.com>
References: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
 <B1eOha2lU0yO6zRq-pOeqEKDf5VPhVO7KaTBiR4fBzw=.a1987d89-2d8e-4322-81fd-e8001e9df5d9@github.com>
Message-ID: <UbLpstk6p0nmQDNrUGeWC2bPVDpNm2bI_VIraIV2UKs=.11dd0054-9ce5-415f-9864-bb0ea6323573@github.com>

On Fri, 30 Aug 2024 16:57:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately.
>> 
>> This is a new attempt at solving [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816); the original attempt is here: https://github.com/openjdk/jdk/pull/19185. This PR is based on the discussions on how to move forward that was held in that original PR.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use "whitespace" as an uncountable noun
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - I suck at English verb forms
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20781#pullrequestreview-2273084845

From ayang at openjdk.org  Fri Aug 30 18:13:23 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 30 Aug 2024 18:13:23 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v3]
In-Reply-To: <VGJOzveV1b0KxnQ_lSugtMP7boOK5TPmiYT7QXgcCoM=.780e110d-491c-4bbc-9ee7-a7db237ee9dc@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <bKtmNAMLqRlWTG9MBcosxeh2rYNK_yx_gkh_qbNKt6s=.e23c8a75-0072-4c9f-8d8e-7db14826fded@github.com>
 <ySywujYrcJzmYZtj5oflhcQZbzxPv78dm29gJ5B1fqE=.31b98908-bc0f-48af-b67a-75e7351d1b74@github.com>
 <CjcHSbAikUEXe-wpmu-p2od4z6IN-QC54DCKL5hSaZY=.85532a31-e607-447b-8cea-80e97024f994@github.com>
 <VGJOzveV1b0KxnQ_lSugtMP7boOK5TPmiYT7QXgcCoM=.780e110d-491c-4bbc-9ee7-a7db237ee9dc@github.com>
Message-ID: <LwLTyRUwTUB8Kph7ngHJExHVwAdJSvimoXRsh6A2HcM=.1c03eb16-4e7a-42ac-bbe1-425f4f7fed75@github.com>

On Fri, 30 Aug 2024 11:15:23 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I was thinking the same, but there's a problem with that. If we get a promotion failure in the young gen, we are leaving the dead objects marked as forwarded. Then when the Full GC scans these regions with dead objects it will mistakenly think that they have been marked alive because `is_forwarded() == is_gc_marked()`. The code in `phase2_calculate_new_addr` will then break when it looks for `is_gc_marked` objects.
>
> FWIW, the ParallelGC does something very similar to what you propose, except that it walks bitmaps instead of paring the space to find the self-forwarded objects. It then has a check inside object_iterate to make sure that it doesn't expose the dead objects (in eden and the from space) to heap dumpers and histogram printers.
> 
> Because of the the code above, the SerialGC clears away the information about what objects are dead in eden and the from space, so heap dumpers and histogram printers will include these dead objects. We might want to fix that as a future RFE.

> If we get a promotion failure in the young gen, we are leaving the dead objects marked as forwarded. 

True; need to do sth like `obj->init_mark();` for the non-self-forwarded case. The postcondition is that no forwarded objs in eden/from.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1739218189

From mli at openjdk.org  Fri Aug 30 19:51:19 2024
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 30 Aug 2024 19:51:19 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v5]
In-Reply-To: <B1eOha2lU0yO6zRq-pOeqEKDf5VPhVO7KaTBiR4fBzw=.a1987d89-2d8e-4322-81fd-e8001e9df5d9@github.com>
References: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
 <B1eOha2lU0yO6zRq-pOeqEKDf5VPhVO7KaTBiR4fBzw=.a1987d89-2d8e-4322-81fd-e8001e9df5d9@github.com>
Message-ID: <G9XJbL1N0j00tKfKlBLJacvSWC_jil7vv3PVC7CsnGQ=.37547b90-5070-442a-9f5e-ebf0f4e57817@github.com>

On Fri, 30 Aug 2024 16:57:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately.
>> 
>> This is a new attempt at solving [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816); the original attempt is here: https://github.com/openjdk/jdk/pull/19185. This PR is based on the discussions on how to move forward that was held in that original PR.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use "whitespace" as an uncountable noun
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - I suck at English verb forms
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

I've applied the generated sleef headers to aarch64/riscv64 patches (`Optimize vector math operations with SLEEF`), all good (the so files are built successfully, the tests jdk/incubator/vector/(Double|Float)MaxVectorTests.java run successfully, also output log is correct), although I don't run jmh tests, I think it's fine.

Thanks @magicus @erikj79 for the efficient co-work!

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20781#pullrequestreview-2273399318

From erikj at openjdk.org  Fri Aug 30 20:26:23 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 30 Aug 2024 20:26:23 GMT
Subject: RFR: 8339336: Fix build system whitespace to adhere to coding
 conventions
In-Reply-To: <c4xtGeV414thJl2ggoO9ZiObIn86CUZwyipYsvp-D1w=.b530223b-f497-4712-8406-406d87cbec6d@github.com>
References: <c4xtGeV414thJl2ggoO9ZiObIn86CUZwyipYsvp-D1w=.b530223b-f497-4712-8406-406d87cbec6d@github.com>
Message-ID: <EJBbVaupf4kfDoREPFXnCfeodKkJ2r0jju-RhEqiOBY=.e443f6d3-b99a-4bfb-ae89-d7a311c27146@github.com>

On Fri, 30 Aug 2024 16:27:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The build system code has unfortunately diverted in some places from the conventions as described in https://openjdk.org/groups/build/doc/code-conventions.html.
> 
> Instead of trying to fix these when touching code nearby, I'd like to make an effort to fix all issues at once and separately. Incremental fixes has their benefit, but they can also muddy the actual fix and are not always appreciated.
> 
> The updates in this patch have all been discovered using automated tools, but each and every change has been manually scrutinized. Those that the automatic tools pointed out that, but that were not obviously or clear-cut safe (e.g. adding spaces after comma, in `subst` or similar situations) were reverted before I pushed. I chose to err on the "First, do no harm" side, so there might be places that could have been corrected, but were not. 
> 
> I have made a single type of change per commit in this branch. It might be easier to review this by looking at one commit at a time.

I'm pretty sure most of these are safe changes, but there are some where I'm a bit hesitant. I would feel safer if you ran a full compare build on it and also manually verified a few incremental build scenarios, including running tests.

In general I very much approve of this patch, thank you for taking the time to clean house! I'm amazed at the number of 79 character wide comment line dividers.

make/MainSupport.gmk line 202:

> 200:   $(foreach i, 2 3 4 5 6 7 8, $(if $(strip $($i)),$(strip $1)_$(strip $($i)))$(NEWLINE))
> 201:   $(if $(9), $(error Internal makefile error: Too many arguments to \
> 202:       DeclareRecipesForPhase, please update MakeHelper.gmk))

I know this is a whitespace cleanup, so this should likely be addressed in a separate issue, but this error message is referencing `MakeHelper.gmk` while being in the file `MainSupport.gmk`.  Also, shouldn't this be able to use the `NamedParamsMacroTemplate` instead of using this old technique for named arguments?

make/test/BuildMicrobenchmark.gmk line 71:

> 69: # Need double \n to get new lines and no trailing spaces
> 70: MICROBENCHMARK_MANIFEST := Build: $(FULL_VERSION)\n \
> 71: \nJMH-Version: $(JMH_VERSION)\n \

Are you sure these spaces are safe? The comment mentions trailing spaces as something undesired and depending on how this is used, I suspect adding a space between the \n could interfere with that.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20798#pullrequestreview-2273355090
PR Review Comment: https://git.openjdk.org/jdk/pull/20798#discussion_r1739308489
PR Review Comment: https://git.openjdk.org/jdk/pull/20798#discussion_r1739378849

From duke at openjdk.org  Sat Aug 31 11:27:22 2024
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Sat, 31 Aug 2024 11:27:22 GMT
Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v5]
In-Reply-To: <B1eOha2lU0yO6zRq-pOeqEKDf5VPhVO7KaTBiR4fBzw=.a1987d89-2d8e-4322-81fd-e8001e9df5d9@github.com>
References: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com>
 <B1eOha2lU0yO6zRq-pOeqEKDf5VPhVO7KaTBiR4fBzw=.a1987d89-2d8e-4322-81fd-e8001e9df5d9@github.com>
Message-ID: <vNjL4613UVecyo4xNPbIQOyNxN-WXUPPwOcBv5olS5o=.d682a5bc-2c40-4573-aeda-405eebc8489e@github.com>

On Fri, 30 Aug 2024 16:57:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately.
>> 
>> This is a new attempt at solving [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816); the original attempt is here: https://github.com/openjdk/jdk/pull/19185. This PR is based on the discussions on how to move forward that was held in that original PR.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use "whitespace" as an uncountable noun
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - I suck at English verb forms
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20781#pullrequestreview-2273829185

From dholmes at openjdk.org  Sat Aug 31 11:57:19 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sat, 31 Aug 2024 11:57:19 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <eQv90nmAArKzh8kjaZ1oGg5jInJTI6J7jxJ8sjIxEXI=.a8ba6456-c192-44eb-8bad-f6ee245239e8@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <WjbVrrjlwa6wJw57f2FNXrGvqUUaRdwylCjEI0g1URI=.afc15190-599c-4c3f-9e0f-8990ed87823f@github.com>
 <eQv90nmAArKzh8kjaZ1oGg5jInJTI6J7jxJ8sjIxEXI=.a8ba6456-c192-44eb-8bad-f6ee245239e8@github.com>
Message-ID: <BN6thNr1y0adSkxfbgfj_d2M-bTC-o6t7sbTwwWgv00=.ad19dcd9-fc24-44a9-a9b1-58c479344bb1@github.com>

On Fri, 30 Aug 2024 10:51:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I understand the cost overhead experienced by any individual Java run may be lost in the noise, but it still impacts every single Java run just to save some time/resources for the handful of builders of statically linked VMs. I am not a fan.
>
> @dholmes-ora This PR now has three reviewers approving it. You say you are "not a fan". Does this mean you want to veto this change? Or can you be willing to accept it, even if you do not like it?

@magicus There is no "veto" power in OpenJDK. You have your reviewers, I have to accept it even if I don't like it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2322873797