On Tue, 25 Feb 2025 15:09:32 GMT, Magnus Ihse Bursie wrote:
> Maybe setup a wiki page with all native libraries, what current optimization
> levels they use, and what the difference in size would be for e.g. SIZE and
> HIGH instead.
Hi @magicus I can collect some info from our builds (gcc13,
Please review a simple build change to re-enable the `-serialwarn` javadoc
option for normal and reference API docs. The option was removed in
[JDK-8252717](https://bugs.openjdk.org/browse/JDK-8252717) to avoid warnings
for missing `@serial` tags which have since been added in
[JDK-8286931](htt
On Tue, 25 Feb 2025 16:59:44 GMT, Aleksey Shipilev wrote:
>> Noticed this when reviewing
>> [JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to
>> kludgy workaround the hunk introduced by `static-libs-bundles` addition
>> ([JDK-8337265](https://bugs.openjdk.org/browse/JDK-
On Wed, 26 Feb 2025 16:59:39 GMT, Jorn Vernee wrote:
>> src/java.base/share/classes/java/lang/invoke/VarForm.java line 150:
>>
>>> 148: String methodName = value.methodName();
>>> 149: MethodType type =
>>> methodType_table[value.at.ordinal()].insertParameterTypes(0,
>>> VarHan
On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang wrote:
>> Simplify the layout access var handles to be direct in some common cases.
>> Also made `VarHandle::isAccessModeSupported` report if an access mode is
>> supported for a VH.
>>
>> Reduces the instructions to execute this code in a simple ma
On Wed, 26 Feb 2025 17:22:13 GMT, Jorn Vernee wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line
On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang wrote:
>> Simplify the layout access var handles to be direct in some common cases.
>> Also made `VarHandle::isAccessModeSupported` report if an access mode is
>> supported for a VH.
>>
>> Reduces the instructions to execute this code in a simple ma
> Please review this change that adds a `linux-x86-static` job in GHA. The job
> builds the `static-jdk-image` release binary on linux-x64. Please see
> https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for
> some additional context.
>
> A `debug` build job (building `stat
On Wed, 19 Feb 2025 09:55:42 GMT, Ivan Bereziuk wrote:
>> The output for Jtreg v7.5 was
>> [enhanced](https://github.com/openjdk/jtreg/pull/217/files#diff-b6ab77bf651f1fd9a83c3ca0aab9cd24ae5c08cef41e6e257f7eaccc07c7c366R947)
>> with [information about skipped
>> tests](https://github.com/openj
On 2/26/25 10:40 AM, Frederic Thevenet wrote:
Hi Erik,
Thanks for your comments.
As a matter of fact, we at Red Hat also face similar constraints that
prevent us from being able to sign the files on the machine that build
them (and I suspect this is quite common-place).
My initial idea to a
On Wed, 26 Feb 2025 18:24:13 GMT, Jiangli Zhou wrote:
>> Please review this change that adds a `linux-x86-static` job in GHA. The job
>> builds the `static-jdk-image` release binary on linux-x64. Please see
>> https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for
>> some
On Wed, 26 Feb 2025 17:18:16 GMT, Jorn Vernee wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.j
On Wed, 26 Feb 2025 17:23:02 GMT, Jorn Vernee wrote:
>> src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 216:
>>
>>> 214: } else {
>>> 215: // simpler adaptation
>>> 216: handle = MethodHandles.insertCoordinates(handle, 2,
>>> offset);
Hello,
I think this is a reasonable idea and you are welcome to implement it.
At Oracle we have been solving this using custom extension makefiles.
That will unfortunately not change with this proposal as our signing
process does not involve direct access to the native tools of the OS.
Perhap
On Wed, 26 Feb 2025 14:06:43 GMT, Hannes Wallnöfer wrote:
> Please review a simple build change to re-enable the `-serialwarn` javadoc
> option for normal and reference API docs. The option was removed in
> [JDK-8252717](https://bugs.openjdk.org/browse/JDK-8252717) to avoid warnings
> for miss
On Wed, 26 Feb 2025 14:06:43 GMT, Hannes Wallnöfer wrote:
> Please review a simple build change to re-enable the `-serialwarn` javadoc
> option for normal and reference API docs. The option was removed in
> [JDK-8252717](https://bugs.openjdk.org/browse/JDK-8252717) to avoid warnings
> for miss
On Fri, 21 Feb 2025 21:52:56 GMT, Jiangli Zhou wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Rename -static job to -static-libs
>
> Yes, we should distinguish between `static-libs` and `static` JDK. Currently
On Thu, 20 Feb 2025 17:15:13 GMT, Aleksey Shipilev wrote:
> Noticed this when reviewing
> [JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to
> kludgy workaround the hunk introduced by `static-libs-bundles` addition
> ([JDK-8337265](https://bugs.openjdk.org/browse/JDK-8337
On Wed, 5 Feb 2025 19:41:51 GMT, Jiangli Zhou wrote:
> Please review this change that adds a `linux-x86-static` job in GHA. The job
> builds the `static-jdk-image` release binary on linux-x64. Please see
> https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for
> some addit
On Wed, 26 Feb 2025 22:26:58 GMT, Mikael Vidstedt wrote:
> Core files may from time to time end up in the source tree of the JDK, adding
> noise in git etc. Because we have valid files and directories called "core*"
> in the tree it's non-trivial to exclude any and all core files, but as a
> s
On Wed, 26 Feb 2025 20:25:41 GMT, Jiangli Zhou wrote:
>> Please review this change that adds a `linux-x86-static` job in GHA. The job
>> builds the `static-jdk-image` release binary on linux-x64. Please see
>> https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for
>> some
On Tue, 25 Feb 2025 15:36:39 GMT, Magnus Ihse Bursie wrote:
>> This is a retry to add `-ftrivial-auto-var-init=pattern` to gcc debug
>> builds. The first attempt was buggy in multiple ways and had to be backed
>> out.
>>
>> This is the description of the original bug report:
>>
>> gcc12 has a
On Wed, 26 Feb 2025 15:02:08 GMT, Aleksey Shipilev wrote:
>> Please review this change that adds a `linux-x86-static` job in GHA. The job
>> builds the `static-jdk-image` release binary on linux-x64. Please see
>> https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for
>> s
On Wed, 5 Feb 2025 19:41:51 GMT, Jiangli Zhou wrote:
> Please review this change that adds a `linux-x86-static` job in GHA. The job
> builds the `static-jdk-image` release binary on linux-x64. Please see
> https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for
> some addit
On Wed, 26 Feb 2025 22:26:58 GMT, Mikael Vidstedt wrote:
> Core files may from time to time end up in the source tree of the JDK, adding
> noise in git etc. Because we have valid files and directories called "core*"
> in the tree it's non-trivial to exclude any and all core files, but as a
> s
On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang wrote:
>> Simplify the layout access var handles to be direct in some common cases.
>> Also made `VarHandle::isAccessModeSupported` report if an access mode is
>> supported for a VH.
>>
>> Reduces the instructions to execute this code in a simple ma
On Wed, 26 Feb 2025 17:52:57 GMT, Jiangli Zhou wrote:
>> Please review this change that adds a `linux-x86-static` job in GHA. The job
>> builds the `static-jdk-image` release binary on linux-x64. Please see
>> https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for
>> some
On Wed, 26 Feb 2025 17:58:08 GMT, Aleksey Shipilev wrote:
>> Jiangli Zhou 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 nine additional
>> com
On Wed, 26 Feb 2025 17:59:46 GMT, Aleksey Shipilev wrote:
>> .github/workflows/main.yml line 171:
>>
>>> 169: if: needs.prepare.outputs.linux-x64 == 'true'
>>> 170:
>>> 171: build-linux-x64-static-jdk:
>>
>> Move this closer to `build-linux-x64-static-libs`? These are somewhat
>> relate
On Wed, 26 Feb 2025 17:59:46 GMT, Aleksey Shipilev wrote:
>> .github/workflows/main.yml line 171:
>>
>>> 169: if: needs.prepare.outputs.linux-x64 == 'true'
>>> 170:
>>> 171: build-linux-x64-static-jdk:
>>
>> Move this closer to `build-linux-x64-static-libs`? These are somewhat
>> relate
On Wed, 26 Feb 2025 14:59:11 GMT, Aleksey Shipilev wrote:
>> Yes, we should distinguish between `static-libs` and `static` JDK.
>> Currently, we refer `static` JDK as a 'fully' statically linked `java`
>> launcher, plus `lib/modules` and other JDK resource files needed for
>> runtime.
>>
>>
On Fri, 21 Feb 2025 10:05:36 GMT, Maurizio Cimadamore
wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/java/lang/invoke/VarForm.java li
On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang wrote:
>> Simplify the layout access var handles to be direct in some common cases.
>> Also made `VarHandle::isAccessModeSupported` report if an access mode is
>> supported for a VH.
>>
>> Reduces the instructions to execute this code in a simple ma
Hi Erik,
Thanks for your comments.
As a matter of fact, we at Red Hat also face similar constraints that
prevent us from being able to sign the files on the machine that build
them (and I suspect this is quite common-place).
My initial idea to accommodate that is to have the jdk build invoke
> Please review this change that adds a `linux-x86-static` job in GHA. The job
> builds the `static-jdk-image` release binary on linux-x64. Please see
> https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for
> some additional context.
>
> A `debug` build job (building `stat
On Wed, 26 Feb 2025 19:44:50 GMT, Aleksey Shipilev wrote:
> Ah, one more trouble: this job produces bundles. But that bundle name is just
> `linux-x64`, which overrides the standard bundle. See how
> `build-linux-x64-static-libs` overrides `bundle-suffix:`, do the same here.
> E.g. `bundle-suf
> Simplify the layout access var handles to be direct in some common cases.
> Also made `VarHandle::isAccessModeSupported` report if an access mode is
> supported for a VH.
>
> Reduces the instructions to execute this code in a simple main by 47%:
>
> long[] arr = new long[8];
> var ms = Memory
On Wed, 26 Feb 2025 20:13:42 GMT, Chen Liang wrote:
>> Simplify the layout access var handles to be direct in some common cases.
>> Also made `VarHandle::isAccessModeSupported` report if an access mode is
>> supported for a VH.
>>
>> Reduces the instructions to execute this code in a simple ma
On Wed, 26 Feb 2025 17:26:41 GMT, Jorn Vernee wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java
> Please review this change that adds a `linux-x86-static` job in GHA. The job
> builds the `static-jdk-image` release binary on linux-x64. Please see
> https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for
> some additional context.
>
> A `debug` build job (building `stat
On Wed, 26 Feb 2025 20:13:42 GMT, Chen Liang wrote:
>> Simplify the layout access var handles to be direct in some common cases.
>> Also made `VarHandle::isAccessModeSupported` report if an access mode is
>> supported for a VH.
>>
>> Reduces the instructions to execute this code in a simple ma
On Wed, 26 Feb 2025 20:25:41 GMT, Jiangli Zhou wrote:
>> Please review this change that adds a `linux-x86-static` job in GHA. The job
>> builds the `static-jdk-image` release binary on linux-x64. Please see
>> https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for
>> some
Core files may from time to time end up in the source tree of the JDK, adding
noise in git etc. Because we have valid files and directories called "core*" in
the tree it's non-trivial to exclude any and all core files, but as a special
case we can at least ignore `core.[0-9]*` which is the typic
Hi,
I would like to start a discussion about adding built-in support for
code signing native executable file and dynamic library on Windows
directly as part of the JDK build, in a similar fashion to what already
exists for macOS.
Most, if not all vendors already ensure that every native exec
On Wed, 19 Feb 2025 09:55:42 GMT, Ivan Bereziuk wrote:
>> The output for Jtreg v7.5 was
>> [enhanced](https://github.com/openjdk/jtreg/pull/217/files#diff-b6ab77bf651f1fd9a83c3ca0aab9cd24ae5c08cef41e6e257f7eaccc07c7c366R947)
>> with [information about skipped
>> tests](https://github.com/openj
45 matches
Mail list logo
