Re: RFR: 8338700: AttributeMapper type parameter should be bounded by Attribute

2024-08-21 Thread Adam Sotona
On Wed, 21 Aug 2024 23:20:38 GMT, Chen Liang wrote: > A minor oversight in AttributeMapper type parameter bounds, that it should be > bounded by Attribute. Only real impact is in BoundAttribute.readAttributes > where a cast is now omitted, as other sites of access like > Attribute::attributeMa

Re: RFR: 8338745: Intrinsify Continuation.pin() and Continuation.unpin()

2024-08-21 Thread Tobias Hartmann
On Wed, 21 Aug 2024 20:11:05 GMT, Markus Grönlund wrote: > Greetings, > > Please help review this change set that implements C2 intrinsics for > jdk.internal.vm.Continuation.pin() and jdk.internal.vm.Continuation.unpin(). > > This work is a consequence of > [JDK-8338417](https://bugs.openjdk.

Re: RFR: 8338768: Introduce runtime lookup to check for static builds [v2]

2024-08-21 Thread Julian Waters
On Thu, 22 Aug 2024 02:46:34 GMT, David Holmes wrote: > Sorry but I don't understand the point of changing build-time constructs > using `ifdef STATIC_BUILD` into what appear to be runtime checks, but the > result of which is already determined at build time. These are not really > runtime che

Re: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)

2024-08-21 Thread Chen Liang
On Wed, 21 Aug 2024 22:27:02 GMT, Chen Liang wrote: > Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through > `ClassDesc` comparison and reusing descriptor hash to calculate internal name > hash if possible. No suitable device to run benchmarks so need to find > something to r

RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)

2024-08-21 Thread Chen Liang
Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended. -

Re: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)

2024-08-21 Thread Chen Liang
On Wed, 21 Aug 2024 22:27:02 GMT, Chen Liang wrote: > Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through > `ClassDesc` comparison and reusing descriptor hash to calculate internal name > hash if possible. No suitable device to run benchmarks so need to find > something to r

Re: RFR: 8338768: Introduce runtime lookup to check for static builds [v2]

2024-08-21 Thread David Holmes
On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie 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 o

Re: RFR: 8338023: Support two vector selectFrom API [v3]

2024-08-21 Thread Sandhya Viswanathan
On Wed, 21 Aug 2024 16:42:44 GMT, Jatin Bhateja wrote: >> Hi All, >> >> As per the discussion on panama-dev mailing list[1], patch adds the support >> for following new two vector permutation APIs. >> >> >> Declaration:- >> Vector.selectFrom(Vector v1, Vector v2) >> >> >> Semantics:- >>

Re: RFR: 8338768: Introduce runtime lookup to check for static builds [v2]

2024-08-21 Thread Jiangli Zhou
On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie 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 o

Re: RFR: 8338768: Introduce runtime lookup to check for static builds [v2]

2024-08-21 Thread Phil Race
On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie 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 o

RFR: 8338700: AttributeMapper type parameter should be bounded by Attribute

2024-08-21 Thread Chen Liang
A minor oversight in AttributeMapper type parameter bounds, that it should be bounded by Attribute. Only real impact is in BoundAttribute.readAttributes where a cast is now omitted, as other sites of access like Attribute::attributeMapper has already bounded the returned type argument.

Re: RFR: 8338768: Introduce runtime lookup to check for static builds [v2]

2024-08-21 Thread Magnus Ihse Bursie
> 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. (T

Re: RFR: 8333265: De-duplicate method references in java.util.stream.FindOps [v3]

2024-08-21 Thread Chen Liang
On Tue, 18 Jun 2024 10:00:46 GMT, Claes Redestad wrote: >> Extracting duplicate method references to static field reduce proxy class >> spinning and loading. In this case 2 less classes loaded when using >> `findAny()` on each type of stream. > > Claes Redestad has updated the pull request incr

Re: RFR: 8333265: De-duplicate method references in java.util.stream.FindOps [v3]

2024-08-21 Thread Chen Liang
On Wed, 21 Aug 2024 22:04:02 GMT, Claes Redestad wrote: >> @cl4es Just wonder what your use case is for this addition. If this is >> accidentally committed, please remove it and I am glad with all other >> changes. > > Adding a `main` method in micros like these allow me to easily multi-purpose

Integrated: 8333265: De-duplicate method references in java.util.stream.FindOps

2024-08-21 Thread Claes Redestad
On Thu, 30 May 2024 12:50:36 GMT, Claes Redestad wrote: > Extracting duplicate method references to static field reduce proxy class > spinning and loading. In this case 2 less classes loaded when using > `findAny()` on each type of stream. This pull request has now been integrated. Changeset:

Re: RFR: 8333265: De-duplicate method references in java.util.stream.FindOps [v3]

2024-08-21 Thread Claes Redestad
On Wed, 21 Aug 2024 21:46:15 GMT, Chen Liang wrote: >> test/micro/org/openjdk/bench/java/util/stream/ops/ref/FindAny.java line 63: >> >>> 61: } >>> 62: >>> 63: public static void main(String... args) { >> >> Is this driver necessary? > > @cl4es Just wonder what your use case is for thi

RFR: 8338768: Introduce runtime lookup to check for static builds

2024-08-21 Thread Magnus Ihse Bursie
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 e

Re: RFR: 8333265: De-duplicate method references in java.util.stream.FindOps [v3]

2024-08-21 Thread Chen Liang
On Wed, 24 Jul 2024 14:24:40 GMT, Chen Liang wrote: >> Claes Redestad has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fixes > > test/micro/org/openjdk/bench/java/util/stream/ops/ref/FindAny.java line 63: > >> 61: } >> 62: >> 63:

Re: RFR: 8338526: Don't store abstract and interface Klasses in class metaspace

2024-08-21 Thread Chen Liang
On Wed, 21 Aug 2024 21:17:14 GMT, Coleen Phillimore wrote: >> Note that JVMS 4.1 requires `ACC_ABSTRACT` to be also set when >> `ACC_INTERFACE` is set. Also note that some classes capture class data to >> refer to hidden classes and method handles or lambda forms, so those fields' >> generatio

Re: RFR: 8338745: Intrinsify Continuation.pin() and Continuation.unpin()

2024-08-21 Thread Vladimir Kozlov
On Wed, 21 Aug 2024 20:11:05 GMT, Markus Grönlund wrote: > Greetings, > > Please help review this change set that implements C2 intrinsics for > jdk.internal.vm.Continuation.pin() and jdk.internal.vm.Continuation.unpin(). > > This work is a consequence of > [JDK-8338417](https://bugs.openjdk.

Re: RFR: 8338526: Don't store abstract and interface Klasses in class metaspace

2024-08-21 Thread Coleen Phillimore
On Wed, 21 Aug 2024 21:02:50 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >> line 279: >> >>> 277: clb.withMethod(invokerName, invokerDesc, ACC_STATIC, config); >>> 278: } >>> 279: >> >> There's probably not much value in usi

Re: RFR: 8338526: Don't store abstract and interface Klasses in class metaspace

2024-08-21 Thread Chen Liang
On Wed, 21 Aug 2024 20:31:09 GMT, Dean Long wrote: >> This change stores InstanceKlass for interface and abstract classes in the >> non-class metaspace, since class metaspace will have limits on number of >> classes that can be represented when Lilliput changes go in. Classes that >> have no

Re: RFR: 8338526: Don't store abstract and interface Klasses in class metaspace

2024-08-21 Thread Dean Long
On Thu, 9 May 2024 13:51:09 GMT, Coleen Phillimore wrote: > This change stores InstanceKlass for interface and abstract classes in the > non-class metaspace, since class metaspace will have limits on number of > classes that can be represented when Lilliput changes go in. Classes that > have

RFR: 8338745: Intrinsify Continuation.pin() and Continuation.unpin()

2024-08-21 Thread Markus Grönlund
Greetings, Please help review this change set that implements C2 intrinsics for jdk.internal.vm.Continuation.pin() and jdk.internal.vm.Continuation.unpin(). This work is a consequence of [JDK-8338417](https://bugs.openjdk.org/browse/JDK-8338417), which required us to introduce explicit pin con

Re: RFR: 8338023: Support two vector selectFrom API [v3]

2024-08-21 Thread Sandhya Viswanathan
On Wed, 21 Aug 2024 18:27:09 GMT, Paul Sandoz wrote: > Is it possible for the intrinsic to be responsible for wrapping, if needed? > If was looking at > [`vpermi2b`](https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#text=vpermi2b&ig_expand=4917,4982,5004,5010,5014&techs=A

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v8]

2024-08-21 Thread Archie Cobbs
On Wed, 31 Jul 2024 15:51:48 GMT, Lance Andersen wrote: >> Another (more conservative) possibility is to preserve both 1 ("Trailing >> garbage is ignored") and 3 ("Concatenated streams are automatically >> decoded") in the default configuration. >> >> Then basically all we would be changing is

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v8]

2024-08-21 Thread Lance Andersen
On Wed, 31 Jul 2024 15:51:48 GMT, Lance Andersen wrote: >> Another (more conservative) possibility is to preserve both 1 ("Trailing >> garbage is ignored") and 3 ("Concatenated streams are automatically >> decoded") in the default configuration. >> >> Then basically all we would be changing is

Withdrawn: 8333265: De-duplicate method references in java.util.stream.FindOps

2024-08-21 Thread duke
On Thu, 30 May 2024 12:50:36 GMT, Claes Redestad wrote: > Extracting duplicate method references to static field reduce proxy class > spinning and loading. In this case 2 less classes loaded when using > `findAny()` on each type of stream. This pull request has been closed without being integr

Re: RFR: 8338023: Support two vector selectFrom API [v3]

2024-08-21 Thread John Rose
On 21 Aug 2024, at 11:30, Paul Sandoz wrote: > Is it possible for the intrinsic to be responsible for wrapping, if needed? > If was looking at > [`vpermi2b`](https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#text=vpermi2b&ig_expand=4917,4982,5004,5010,5014&techs=AVX_512) >

Re: RFR: 8338023: Support two vector selectFrom API [v3]

2024-08-21 Thread Paul Sandoz
On Wed, 21 Aug 2024 16:42:44 GMT, Jatin Bhateja wrote: >> Hi All, >> >> As per the discussion on panama-dev mailing list[1], patch adds the support >> for following new two vector permutation APIs. >> >> >> Declaration:- >> Vector.selectFrom(Vector v1, Vector v2) >> >> >> Semantics:- >>

Re: RFR: 8338023: Support two vector selectFrom API [v3]

2024-08-21 Thread John Rose
On 21 Aug 2024, at 10:51, Sandhya Viswanathan wrote: > @jatin-bhateja Thanks, the PR ((https://github.com/openjdk/jdk/pull/20634) is > still work in progress and can be simplified much further. The changes I am > currently working on are do wrap by default for rearrange and selectFrom as > sugg

Re: RFR: 8338417: Explicitly pin a virtual thread before acquiring the JFR string pool monitor [v5]

2024-08-21 Thread Markus Grönlund
> Greetings, > > Explicitly pin a virtual thread before acquiring the JFR string pool monitor > because migrating a carrier thread local event writer object onto another > carrier thread is impossible. > > During event commit, the thread is in a critical section because it has > loaded a carri

Integrated: 8338146: Improve Exchanger performance with VirtualThreads

2024-08-21 Thread Doug Lea
On Mon, 12 Aug 2024 17:07:42 GMT, Doug Lea wrote: > The Exchanger class uses spin-waits that are hostile to some uses of > VirtualThreads. Improving this requires a means of estimating whether there > are many VirtualThreads with few carriers, which can be supported by adding a > method in cla

Re: RFR: 8338417: Explicitly pin a virtual thread before acquiring the JFR string pool monitor [v4]

2024-08-21 Thread Markus Grönlund
> Greetings, > > Explicitly pin a virtual thread before acquiring the JFR string pool monitor > because migrating a carrier thread local event writer object onto another > carrier thread is impossible. > > During event commit, the thread is in a critical section because it has > loaded a carri

Re: RFR: 8338023: Support two vector selectFrom API [v3]

2024-08-21 Thread Sandhya Viswanathan
On Wed, 21 Aug 2024 16:49:40 GMT, Jatin Bhateja wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Pass explicit wrap argument to selectFrom API with default value set to >> true. > > Hi @rose00 , @sviswa7 , @PaulSa

Re: RFR: 8338146: Improve Exchanger performance with VirtualThreads [v2]

2024-08-21 Thread Alan Bateman
On Wed, 21 Aug 2024 14:06:39 GMT, Doug Lea wrote: >> The Exchanger class uses spin-waits that are hostile to some uses of >> VirtualThreads. Improving this requires a means of estimating whether there >> are many VirtualThreads with few carriers, which can be supported by adding >> a method in

Re: RFR: 8338526: Don't store abstract and interface Klasses in class metaspace

2024-08-21 Thread Chen Liang
On Thu, 9 May 2024 13:51:09 GMT, Coleen Phillimore wrote: > This change stores InstanceKlass for interface and abstract classes in the > non-class metaspace, since class metaspace will have limits on number of > classes that can be represented when Lilliput changes go in. Classes that > have

Re: RFR: 8336275: Move common Method and Constructor fields to Executable [v3]

2024-08-21 Thread Coleen Phillimore
On Wed, 21 Aug 2024 15:42:18 GMT, Chen Liang wrote: >> Move fields common to Method and Field to executable, which simplifies >> implementation. Removed useless transient modifiers as Method and Field were >> never serializable. >> >> Note to core-libs reviewers: Please review the associated C

Re: RFR: 8338023: Support two vector selectFrom API [v3]

2024-08-21 Thread Jatin Bhateja
On Wed, 21 Aug 2024 16:42:44 GMT, Jatin Bhateja wrote: >> Hi All, >> >> As per the discussion on panama-dev mailing list[1], patch adds the support >> for following new two vector permutation APIs. >> >> >> Declaration:- >> Vector.selectFrom(Vector v1, Vector v2) >> >> >> Semantics:- >>

Re: RFR: 8336275: Move common Method and Constructor fields to Executable [v3]

2024-08-21 Thread Coleen Phillimore
On Wed, 21 Aug 2024 15:42:18 GMT, Chen Liang wrote: >> Move fields common to Method and Field to executable, which simplifies >> implementation. Removed useless transient modifiers as Method and Field were >> never serializable. >> >> Note to core-libs reviewers: Please review the associated C

Re: RFR: 8338023: Support two vector selectFrom API [v3]

2024-08-21 Thread Jatin Bhateja
> Hi All, > > As per the discussion on panama-dev mailing list[1], patch adds the support > for following new two vector permutation APIs. > > > Declaration:- > Vector.selectFrom(Vector v1, Vector v2) > > > Semantics:- > Using index values stored in the lanes of "this" vector, assembl

Re: RFR: 8333446: Add tests for hierarchical container support [v5]

2024-08-21 Thread Severin Gehwolf
On Tue, 20 Aug 2024 17:34:46 GMT, Severin Gehwolf wrote: >> Please review this PR which adds test support for systemd slices so that >> bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be >> verified. The added test, `SystemdMemoryAwarenessTest` currently passes on >> c

RFR: 8338526: Don't store abstract and interface Klasses in class metaspace

2024-08-21 Thread Coleen Phillimore
This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in. Classes that have no instances created for them don't require compressed class pointer

Re: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics [v2]

2024-08-21 Thread Severin Gehwolf
On Mon, 29 Jul 2024 14:18:24 GMT, Severin Gehwolf wrote: >> Please review this fix for cgroups-based metrics reporting in the >> `jdk.internal.platform` package. This fix is supposed to address wrong >> reporting of certain limits if the limits aren't set at the leaf nodes. >> >> For example,

Re: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics [v3]

2024-08-21 Thread Severin Gehwolf
> Please review this fix for cgroups-based metrics reporting in the > `jdk.internal.platform` package. This fix is supposed to address wrong > reporting of certain limits if the limits aren't set at the leaf nodes. > > For example, on cg v2, the memory limit interface file is `memory.max`. > Co

Re: RFR: 8336267: Method and Constructor signature parsing can be shared on the root object [v2]

2024-08-21 Thread Chen Liang
> A straightforward optimization, to share the signature parsing of method, > constructor, and field between the root and the copied objects, like how > method handle accessors are shared. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull reques

Re: RFR: 8336275: Move common Method and Constructor fields to Executable [v3]

2024-08-21 Thread Chen Liang
> Move fields common to Method and Field to executable, which simplifies > implementation. Removed useless transient modifiers as Method and Field were > never serializable. > > Note to core-libs reviewers: Please review the associated CSR on trivial > removal of `abstract` modifier as well. C

Integrated: 8338677: Improve startup of memory access var handles by simplifying combinator chains

2024-08-21 Thread Maurizio Cimadamore
On Tue, 20 Aug 2024 15:05:24 GMT, Maurizio Cimadamore wrote: > This PR reduces the amount of lambda forms (LFs) which are created when > generating var handles for simple struct field accessors. This contributes to > the startup regression seen in > [JDK-8337505](https://bugs.openjdk.org/brow

Integrated: 8338532: Speed up the ClassFile API MethodTypeDesc#ofDescriptor

2024-08-21 Thread Shaojin Wen
On Fri, 16 Aug 2024 08:53:38 GMT, Shaojin Wen wrote: > The current implementation of ofDescriptor puts return type and parameter > types together in an ArrayList, and then splits them into return type and > array of parameter types. This ArrayList creation is unnecessary, considering > most de

Re: RFR: 8338532: Speed up the ClassFile API MethodTypeDesc#ofDescriptor [v3]

2024-08-21 Thread Chen Liang
On Tue, 20 Aug 2024 12:39:14 GMT, Shaojin Wen wrote: >> The current implementation of ofDescriptor puts return type and parameter >> types together in an ArrayList, and then splits them into return type and >> array of parameter types. This ArrayList creation is unnecessary, >> considering mos

Re: RFR: 8338532: Speed up the ClassFile API MethodTypeDesc#ofDescriptor [v3]

2024-08-21 Thread duke
On Tue, 20 Aug 2024 12:39:14 GMT, Shaojin Wen wrote: >> The current implementation of ofDescriptor puts return type and parameter >> types together in an ArrayList, and then splits them into return type and >> array of parameter types. This ArrayList creation is unnecessary, >> considering mos

Re: RFR: 8338417: Explicitly pin a virtual thread before acquiring the JFR string pool monitor [v3]

2024-08-21 Thread Markus Grönlund
On Wed, 21 Aug 2024 14:21:39 GMT, Markus Grönlund wrote: >> Thread.currentThread() has an intrinsic, and isVirtual is just a type check. >> ContinuationSupport.isSupported reads a static final so will disappear once >> compiled. The pattern we are using in other areas is for the pin to return a

Re: RFR: 8338417: Explicitly pin a virtual thread before acquiring the JFR string pool monitor [v3]

2024-08-21 Thread Markus Grönlund
On Thu, 15 Aug 2024 14:32:40 GMT, Alan Bateman wrote: >> Would it be possible to create a boolean in the EventWriter that indicates >> if it is associated with a carrier thread or a normal thread (which can >> never be virtual) and then have two methods. >> >> long l = this.carrierThread ?

concurrency-discuss mailing list

2024-08-21 Thread Alan Bateman
For many years, concurrency-interest was the mailing list to discuss j.u.concurrent and related topics. The mailing list was hosted on a server maintained by Prof. Doug Lea. Sadly, the mailing list didn't survive an OS upgrade and has been unavailable for some time. A new mailing list concu

Re: RFR: 8316662: Remove one allocation per conversion in Double.toString(double) and Float.toString(float) [v4]

2024-08-21 Thread Raffaello Giulietti
On Tue, 30 Apr 2024 08:44:32 GMT, Raffaello Giulietti wrote: >> By correctly sizing an intermediate `byte[]` and making use of the internal >> `newStringNoRepl()` method, one allocation per conversion can be avoided >> when the runtime uses compact strings. > > Raffaello Giulietti has updated

Re: RFR: 8338146: Improve Exchanger performance with VirtualThreads

2024-08-21 Thread Doug Lea
On Mon, 12 Aug 2024 17:07:42 GMT, Doug Lea wrote: > The Exchanger class uses spin-waits that are hostile to some uses of > VirtualThreads. Improving this requires a means of estimating whether there > are many VirtualThreads with few carriers, which can be supported by adding a > method in cla

Re: RFR: 8338146: Improve Exchanger performance with VirtualThreads [v2]

2024-08-21 Thread Doug Lea
> The Exchanger class uses spin-waits that are hostile to some uses of > VirtualThreads. Improving this requires a means of estimating whether there > are many VirtualThreads with few carriers, which can be supported by adding a > method in class ForkJoinWorkerThread. This enables a reworking of

RFR: 8338731: MemoryLayout::offsetHandle can return a negative offset

2024-08-21 Thread Maurizio Cimadamore
When working on startup improvements, I noticed that the method handle returned by `MemoryLayout::offsetHandle` can overflow if the client calls the handle with a base offset that is too big. In other similar situations, the layout API always fails with `ArithmeticException` (see `MemoryLayout:

Re: RFR: 8338728: Misc issues in memory layout javadoc [v2]

2024-08-21 Thread Maurizio Cimadamore
> This PR fixes two minor issues in the `MemoryLayout` javadoc: > * the section describing dereference path talks about `P` and `P'` but then > only uses `P` in the code; > * the `ceilDiv` math on the `PathElement::sequenceElement(long, long)` is > wrong, as the division returns a negative number

Integrated: 8338545: Functional interface implementations for common pre-boot ClassFile operations

2024-08-21 Thread Chen Liang
On Mon, 19 Aug 2024 15:57:34 GMT, Chen Liang wrote: > Some ad-hoc lambdas and classes for functional calls to ClassFile API in > early bootstrap can be replaced with a few fixed factories. This allows some > methods to be used at early bootstrap with less class loading costs. > > Depends on #2

Re: RFR: 8338595: Add more linesize for MIME decoder in macro bench test Base64Decode

2024-08-21 Thread Hamlin Li
On Wed, 21 Aug 2024 10:03:57 GMT, Robbin Ehn wrote: >> Hi, >> Can you help to review this simple patch? >> >> Currently, lineSize linesize for MIME case in macro bench test Base64Decode >> is only "4", but in Base64.Encoder default linesize for MIME encoder is 76. >> It's helpful to add more li

Integrated: 8338595: Add more linesize for MIME decoder in macro bench test Base64Decode

2024-08-21 Thread Hamlin Li
On Mon, 19 Aug 2024 16:43:02 GMT, Hamlin Li wrote: > Hi, > Can you help to review this simple patch? > > Currently, lineSize linesize for MIME case in macro bench test Base64Decode > is only "4", but in Base64.Encoder default linesize for MIME encoder is 76. > It's helpful to add more linesize,

Re: RFR: 8338677: Improve startup of memory access var handles by simplifying combinator chains [v2]

2024-08-21 Thread Claes Redestad
On Wed, 21 Aug 2024 09:38:42 GMT, Maurizio Cimadamore wrote: >> This PR reduces the amount of lambda forms (LFs) which are created when >> generating var handles for simple struct field accessors. This contributes >> to the startup regression seen in >> [JDK-8337505](https://bugs.openjdk.org/

Re: RFR: 8338595: Add more linesize for MIME decoder in macro bench test Base64Decode

2024-08-21 Thread Robbin Ehn
On Mon, 19 Aug 2024 16:43:02 GMT, Hamlin Li wrote: > Hi, > Can you help to review this simple patch? > > Currently, lineSize linesize for MIME case in macro bench test Base64Decode > is only "4", but in Base64.Encoder default linesize for MIME encoder is 76. > It's helpful to add more linesize,

RFR: 8338728: Misc issues in memory layout javadoc

2024-08-21 Thread Maurizio Cimadamore
This PR fixes two minor issues in the `MemoryLayout` javadoc: * the section describing dereference path talks about `P` and `P'` but then only uses `P` in the code; * the `ceilDiv` math on the `PathElement::sequenceElement(long, long)` is wrong, as the division returns a negative number for F < 0

Re: RFR: 8338677: Improve startup of memory access var handles by simplifying combinator chains [v2]

2024-08-21 Thread Maurizio Cimadamore
> This PR reduces the amount of lambda forms (LFs) which are created when > generating var handles for simple struct field accessors. This contributes to > the startup regression seen in > [JDK-8337505](https://bugs.openjdk.org/browse/JDK-8337505). > > There are essentially three sources of exc

Re: RFR: 8337408: Use GetTempPath2 API instead of GetTempPath [v2]

2024-08-21 Thread Kevin Walls
On Thu, 15 Aug 2024 20:28:28 GMT, Dhamoder Nalla wrote: >> Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code >> across the OpenJDK repository to retrieve the temporary directory path, as >> GetTempPath2 provides enhanced security. While GetTempPath may still >> function

Re: RFR: 8333446: Add tests for hierarchical container support [v5]

2024-08-21 Thread Severin Gehwolf
On Tue, 20 Aug 2024 17:34:46 GMT, Severin Gehwolf wrote: >> Please review this PR which adds test support for systemd slices so that >> bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be >> verified. The added test, `SystemdMemoryAwarenessTest` currently passes on >> c

Integrated: 8338661: StackMapTable is invalid if frames appear in dead code

2024-08-21 Thread Adam Sotona
On Tue, 20 Aug 2024 13:54:08 GMT, Adam Sotona wrote: > ClassFile API allows to build a class with dead code and provide custom > `StackMapTable` attribute with user-specified frames covering the dead code. > `StackCounter` is responsible for calculation of `maxStack` and `maxLocals` > in certai

Re: RFR: 8338545: Functional interface implementations for common pre-boot ClassFile operations [v3]

2024-08-21 Thread Adam Sotona
On Tue, 20 Aug 2024 17:10:56 GMT, Chen Liang wrote: >> Some ad-hoc lambdas and classes for functional calls to ClassFile API in >> early bootstrap can be replaced with a few fixed factories. This allows some >> methods to be used at early bootstrap with less class loading costs. >> >> Depends