> 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-8337265)). I am somewhat
> surprised we even have `static-libs-
On Thu, 20 Feb 2025 15:58:03 GMT, Aleksey Shipilev wrote:
>> What's the difference between `build-linux-static.yml` and
>> `build-linux.yml`? Can we just call `build-linux.yml` to do the static build?
>
>> @shipilev Can you help review/approve the change, if no other questions?
>
> Sorry for no
> 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-8337265)). I am somewhat
> surprised we even have `static-libs-
On Fri, 21 Feb 2025 08:29:28 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 Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken wrote:
> The libjdwp is currently built with LOW optimization level, it could be built
> with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag
> so no diff
On Fri, 21 Feb 2025 13:53:47 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 77:
>>
>>> 75:
>>> 76: private static MethodHandle computeFilterHandle(int index) {
>>> 77: MethodHandles.Lookup lookup = MethodHandles.lookup();
>>
>> please bre
On Fri, 21 Feb 2025 14:24:22 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 Fri, 21 Feb 2025 13:49:51 GMT, Chen Liang wrote:
> I have disabled them with #, and the status is confirmed by test for access
> modes. I kept the infra to make future reenabling easy.
Doh - I missed the `#` -- maybe add few more to make that more explicit? (I
agree with the approach)
>> s
On Fri, 21 Feb 2025 06:57:05 GMT, Alan Bateman wrote:
> > Updated to skipping
> > `java/lang/String/nativeEncoding/StringPlatformChars.java` on static JDK.
>
> Thanks. If you can bump the copyright header date then I think we are done
> with this one.
Done, thanks!
-
PR Comment:
On Fri, 21 Feb 2025 14:43:31 GMT, Maurizio Cimadamore
wrote:
>> I have disabled them with #, and the status is confirmed by test for access
>> modes. I kept the infra to make future reenabling easy.
>
>> I have disabled them with #, and the status is confirmed by test for access
>> modes. I ke
> 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 Fri, 21 Feb 2025 16:04:57 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template
>> line 77:
>>
>>> 75: }
>>> 76:
>>> 77: @ForceInline
>>
>> Question: can this and the `offset` method go in the
>> `VarHandleSegmentViewBa
On Fri, 21 Feb 2025 18:34:48 GMT, Maurizio Cimadamore
wrote:
>> We have two caches, one in `ValueLayouts` and another in `Utils`. Should we
>> remove both?
>
> I'm not convinced about the one in ValueLayouts *e.g. where this comment was
> added) -- if you agree that the other cache should alre
> Please review the fix to make
> `java/lang/String/nativeEncoding/StringPlatformChars.java` jtreg test:
>
> - Lookup `JNU_GetStringPlatformChars`, `JNU_ClassString` and
> `JNU_NewStringPlatform` dynamically
> - Remove `#include "jni_util.h"` and don't link `libstringPlatformChars.so`
> with `
On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken wrote:
> The libjdwp is currently built with LOW optimization level, it could be built
> with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag
> so no diff
On Fri, 21 Feb 2025 14:24:22 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 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 Fri, 21 Feb 2025 22:11:01 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/jdk/internal/foreign/Utils.java
On Fri, 21 Feb 2025 09:59:27 GMT, Maurizio Cimadamore
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
On Fri, 21 Feb 2025 08:35:06 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-
> 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-8337265)). I am somewhat
> surprised we even have `static-libs-
On Thu, 20 Feb 2025 22:24:01 GMT, Archie Cobbs wrote:
>> This PR is a prototype to stimulate discussion of
>> [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to
>> add more warnings when an implicit cast of a primitive value might lose
>> information. This can possibly
On Fri, 21 Feb 2025 00:01:36 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 main by
On Fri, 21 Feb 2025 10:12:45 GMT, Maurizio Cimadamore
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
On Thu, 20 Feb 2025 20:57:47 GMT, Archie Cobbs wrote:
> This PR is a prototype to stimulate discussion of
> [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to
> add more warnings when an implicit cast of a primitive value might lose
> information. This can possibly happ
> This PR is a prototype to stimulate discussion of
> [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to
> add more warnings when an implicit cast of a primitive value might lose
> information. This can possibly happen when converting an `int` to `float`, or
> when conve
On Fri, 21 Feb 2025 11:31:34 GMT, Raffaello Giulietti
wrote:
> You may want to take a look at `java.lang.runtime.ExactConversionsSupport`.
Thanks! That's exactly what I needed. Fixed in 92b479a94ff.
> There are several reasons that it would be ideal to hold this PR off, for
> now. There is an
On Fri, 21 Feb 2025 00:01:36 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 main by
On Thu, 20 Feb 2025 20:57:47 GMT, Archie Cobbs wrote:
> This PR is a prototype to stimulate discussion of
> [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to
> add more warnings when an implicit cast of a primitive value might lose
> information. This can possibly happ
On Fri, 21 Feb 2025 08:32:05 GMT, Aleksey Shipilev wrote:
> OK, this downstream use should really be documented if you want people to
> know why it should persist. New version does a comment hopefully explaining
> this. The static bundle is uploaded, but now separately, in
> `linux-x64-static`
On Fri, 21 Feb 2025 00:01:36 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 main by
On Fri, 21 Feb 2025 00:01:36 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 main by
On Fri, 21 Feb 2025 11:05:30 GMT, Maurizio Cimadamore
wrote:
> Overall, this is a great cleanup and consolidation of the memory segment VH
> code. I left various comments -- but this is already in a great shape. Thanks!
It would be useful to run some micro benchmarks before/after -- especially
On Fri, 21 Feb 2025 00:01:36 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 main by
On Fri, 21 Feb 2025 00:01:36 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 main by
On Fri, 21 Feb 2025 00:01:36 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 main by
On Fri, 21 Feb 2025 00:01:36 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 main by
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 Fri, 21 Feb 2025 19:04:31 GMT, Jiangli Zhou wrote:
>> Please review the fix to make
>> `java/lang/String/nativeEncoding/StringPlatformChars.java` jtreg test:
>>
>> - Lookup `JNU_GetStringPlatformChars`, `JNU_ClassString` and
>> `JNU_NewStringPlatform` dynamically
>> - Remove `#include "jni
39 matches
Mail list logo
