On Tue, 25 Feb 2025 09:51:08 GMT, Maurizio Cimadamore
wrote:
>> Benchmark results for the latest revision appears performance neutral.
>> bytestacks same as last revision. 11 jobs left in tier 1-3, no failure so
>> far. Also created CSR for this minor behavioral change.
>>
>> Benchmark
On Tue, 25 Feb 2025 23:11:30 GMT, Chen Liang wrote:
> Indeed, the byte access currently only supports read/write (automatically
> aligned). No CAS or bitwise for now in FFM.
Do you know why that is so?
-
PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2683738533
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 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 Tue, 25 Feb 2025 09:14:10 GMT, Matthias Baesken wrote:
> > I think you can optionally configure libjvm.so to be built for small size,
> > not performance
>
> Yes true for libjvm this is possible, it is the opt-size part of the minimal
> features set `JVM_FEATURES_minimal='compiler1 minimal
On Fri, 21 Feb 2025 14:32:24 GMT, Aleksey Shipilev wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Rename -static job to -static-libs
>
> The point about difference between `static-libs` and `static` JDK is val
> 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 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 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
> 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 added -ftrivial-auto-var-init=, which specifies how
> automatic variable
On Mon, 24 Feb 2025 11:38:40 GMT, Matthias Baesken wrote:
>>> I'll try to prioritize separating gtest and hotspot builds, and then it
>>> will be possible to fix this in a clean way.
>>
>> Okay thanks, then let's wait a bit for your change separating gtest and
>> hotspot builds, if this helps
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 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 20:17:09 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 ap
On Tue, 25 Feb 2025 13:13:13 GMT, Julian Waters wrote:
> >
> > I am not sure if it is currently a good idea to set LTO for all JDK native
> > libs; but for some it might work well and be beneficial.
>
> Maybe I can prepare a changeset for this and send the diff just to get a
> cursory review
On Tue, 25 Feb 2025 13:09:08 GMT, Matthias Baesken wrote:
> > I'm not sure what that line in Flags.gmk has to do with LTO support, since
> > it's setting the optimization levels.
>
> We could offer there another option LTO, additionally to LOW, HIGH, HIGHEST,
> SIZE etc. .
>
> > I don't think
On Tue, 25 Feb 2025 09:33:58 GMT, Julian Waters wrote:
> I'm not sure what that line in Flags.gmk has to do with LTO support, since
> it's setting the optimization levels.
We could offer there another option LTO, additionally to LOW, HIGH, HIGHEST,
SIZE etc. .
> I don't think we should do it
On Tue, 25 Feb 2025 10:02:51 GMT, Per Minborg 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/SegmentVarHandle.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
On Fri, 21 Feb 2025 14:32:24 GMT, Aleksey Shipilev wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Rename -static job to -static-libs
>
> The point about difference between `static-libs` and `static` JDK is val
On Mon, 24 Feb 2025 17:53:36 GMT, Chen Liang wrote:
>> Maybe let's leave it, at least in this round
>
> Done in latest update.
Thanks! I think it looks very good!
-
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1969396191
On Mon, 24 Feb 2025 19:11:23 GMT, Chen Liang wrote:
> I think direct var handles are quite cheap already and don't really need
> caching. What really worth caching should be the combinators and the VH
> derived from those combinators.
Right -- and one big advantage of this PR, if I'm correct,
On Fri, 21 Feb 2025 22:19:08 GMT, Chen Liang wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review remarks, dates, some more simplifications
>
> Benchmark results for the latest revision appears performance neutral.
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 Tue, 25 Feb 2025 09:12:30 GMT, Matthias Baesken wrote:
> > Absence of benchmarking and given the relatively small footprint savings, I
> > don't think we should switch to SIZE. LTO seems fine. I don't know of any
> > negative impacts with using it.
>
> @TheShermanTanker , @magicus what do
On Tue, 25 Feb 2025 02:31:29 GMT, Chris Plummer wrote:
> Absence of benchmarking and given the relatively small footprint savings, I
> don't think we should switch to SIZE. LTO seems fine. I don't know of any
> negative impacts with using it.
@TheShermanTanker , @magicus what do you think ?
27 matches
Mail list logo
