> Please review this small documentation change to ConstantPoolBuilder to fix a
> typo and clarify the usage of the `constantValueEntry` method.
David M. Lloyd has updated the pull request incrementally with one additional
commit since the last revision:
Review fe
On Mon, 30 Sep 2024 10:03:57 GMT, Shaojin Wen wrote:
> The new API loadConstant(int) can shorten the calling path and can replace
> ldc when the parameter is of int/Integer type.
I was also curious about a few other seemingly "obvious" small optimizations,
like loading `-1L` as `iconst_m1; i2l
On Fri, 30 Aug 2024 18:12:38 GMT, David M. Lloyd wrote:
>> Please review this small documentation change to ConstantPoolBuilder to fix
>> a typo and clarify the usage of the `constantValueEntry` method.
>
> David M. Lloyd has updated the pull request incrementally with one ad
On Thu, 26 Sep 2024 13:41:31 GMT, Chen Liang wrote:
>> David M. Lloyd has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Make sure that we record every error instead of stopping at the first
>> error in a pa
ion pressure, in
> this code by simplifying it so that the `switch` is itself run directly
> within the `try`/`catch`.
David M. Lloyd has updated the pull request incrementally with one additional
commit since the last revision:
Make sure that we record every error instead of stopping
Currently, `ParserVerifier#verifyConstantPool` uses a `switch` to produce a
`Runnable`, which is consumed by a `Consumer` (instantiated within a
loop) which runs the task inside if a `try`/`catch`. We can eliminate a number
of lambdas and method references, plus some allocation pressure, in this
w for the reading of
> serialization-specific private static final fields from classes which have
> them.
>
> With the addition of these methods, serialization libraries no longer need to
> rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman
David
w for the reading of
> serialization-specific private static final fields from classes which have
> them.
>
> With the addition of these methods, serialization libraries no longer need to
> rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman
David
On Tue, 16 Jul 2024 18:17:00 GMT, Roger Riggs wrote:
>> David M. Lloyd has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address review feedback
>
> src/java.base/share/classes/jdk/internal/reflect/Refl
On Fri, 20 Sep 2024 20:27:00 GMT, Roger Riggs wrote:
>> David M. Lloyd has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address review comment
>
> src/java.base/share/classes/jdk/internal/reflect/Refl
w for the reading of
> serialization-specific private static final fields from classes which have
> them.
>
> With the addition of these methods, serialization libraries no longer need to
> rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman
David
On Tue, 17 Sep 2024 17:31:58 GMT, Alan Bateman wrote:
> Looks like test/jdk/jdk/classfile/OptionsTest.java was missed.
Ah. I did a code search in the IDE but I forgot that my import doesn't have
complete test coverage; I should have grep'd to be sure. Sorry about that.
-
PR Commen
On Mon, 16 Sep 2024 12:56:14 GMT, David M. Lloyd wrote:
> Please review this small change to fix a misspelling. The constant is not
> used directly; rather it is used by ordinal, which explains why the error was
> not found sooner.
This pull request has now been integrated.
On Tue, 17 Sep 2024 13:37:19 GMT, Chen Liang wrote:
>> Per Minborg has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Update javadoc
>> - Rename utility class
>
> I think a better approach to this problem might be converting these static
Please review this small change to fix a misspelling. The constant is not used
directly; rather it is used by ordinal, which explains why the error was not
found sooner.
-
Commit messages:
- 8340200: Misspelled constant
`AttributesProcessingOption.DROP_UNSTABLE_ATRIBUTES`
Changes
On Thu, 5 Sep 2024 17:54:46 GMT, Alan Bateman wrote:
>> This PR proposes to add a JDK-specific monitoring and management interface
>> for the virtual thread scheduler. The interface is named
>> [VirtualThreadSchedulerMXBean](https://download.java.net/java/early_access/loom/docs/api/jdk.manageme
On Tue, 3 Sep 2024 16:13:39 GMT, David M. Lloyd wrote:
> Please review this change, which reduces the number of allocations in
> `StackMapDecoder::writeFrames` by using a sorted array instead of a
> `TreeMap` to sort and uniquify entries before writing. It also
> adds a validati
On Wed, 4 Sep 2024 15:27:40 GMT, Chen Liang wrote:
> > I'll see if I can get the benchmarks in
> > `test/micro/org/openjdk/bench/jdk/classfile` working. It looks like there
> > may be one or more of them which would reach into this code.
>
> Just checked; no benchmark is currently supplying a
On Wed, 4 Sep 2024 14:18:09 GMT, Claes Redestad wrote:
> > If so, then this amounts to a fairly minimal and direct code path, thus I
> > approached this as being an "obvious" (as opposed to theoretical)
> > improvement.
>
> I agree that it looks like the typical path is trivial, but I don't ha
On Wed, 4 Sep 2024 13:08:49 GMT, Claes Redestad wrote:
> LGTM
>
> AFAICT before this we'd only call `DirectCodeBuilder::labelToBci` once per
> label, but now we'll do so roughly `2*n*log(n) + n` times. I would assume
> getting rid of the `TreeMap` and `Integer` key allocations more than makes
On Wed, 4 Sep 2024 01:06:10 GMT, Shaojin Wen wrote:
> It looks good, but can you provide the codeSize before and after the change?
> For example, add the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions
> -XX:+PrintInlining` to find `writeFrames` and see if this PR will change from
> les
> Tested using `StackMapsTest`.
David M. Lloyd has updated the pull request incrementally with one additional
commit since the last revision:
Review feedback: reject duplicate stack map entries
-
Changes:
- all: https://git.openjdk.org/jdk/pull/20841/files
- new: https://git.openjdk.
On Tue, 3 Sep 2024 16:13:39 GMT, David M. Lloyd wrote:
> Please review this change, which reduces the number of allocations in
> `StackMapDecoder::writeFrames` by using a sorted array instead of a
> `TreeMap` to sort and uniquify entries before writing.
>
> Tested using `Stack
Please review this change, which reduces the number of allocations in
`StackMapDecoder::writeFrames` by using a sorted array instead of a
`TreeMap` to sort and uniquify entries before writing.
Tested using `StackMapsTest`.
-
Commit messages:
- 8339492: StackMapDecoder::writeFrames
> Please review this small documentation change to ConstantPoolBuilder to fix a
> typo and clarify the usage of the `constantValueEntry` method.
David M. Lloyd has updated the pull request incrementally with one additional
commit since the last revision:
Review co
Please review this small documentation change to ConstantPoolBuilder to fix a
typo and clarify the usage of the `constantValueEntry` method.
-
Commit messages:
- 8339329: ConstantPoolBuilder#constantValueEntry method doc typo and
clarifications
Changes: https://git.openjdk.org/jdk
On Mon, 12 Aug 2024 18:18:04 GMT, Roger Riggs wrote:
> The tests should include serializing some sample JDK classes that include a
> hierarchy of 2-4 levels. It would help fles any interactions in the
> sequencing of calling the default serialization for each of a concrete
> class's supertypes
w for the reading of
> serialization-specific private static final fields from classes which have
> them.
>
> With the addition of these methods, serialization libraries no longer need to
> rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman
David
w for the reading of
> serialization-specific private static final fields from classes which have
> them.
>
> With the addition of these methods, serialization libraries no longer need to
> rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman
David
On Tue, 16 Jul 2024 18:34:00 GMT, Roger Riggs wrote:
> Is there a high level description of how these methods would be used?
They would be used identically to how the `readObjectForSerialization` and
`writeObjectForSerialization` methods are used. The caller would pass the
object as a pseudo-"
On Fri, 28 Jun 2024 13:09:19 GMT, David M. Lloyd wrote:
>> src/java.base/share/classes/java/lang/invoke/SerializationBytecodeGenerator.java
>> line 43:
>>
>>> 41: * The private serialization bytecode generator used by {@code
>>> sun.misc.ReflectionFacto
On Fri, 28 Jun 2024 22:03:36 GMT, ExE Boss wrote:
>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
>> support for functionality required to continue to support IIOP and custom
>> serializers in light of additional module-based restrictions on reflection.
>> It was expe
On Mon, 1 Jul 2024 12:46:18 GMT, David M. Lloyd wrote:
>> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line
>> 441:
>>
>>> 439: }
>>> 440:
>>> 441: return
>>> SerializationBytecodeGenerator.defau
On Mon, 1 Jul 2024 05:35:37 GMT, Chen Liang wrote:
>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
>> support for functionality required to continue to support IIOP and custom
>> serializers in light of additional module-based restrictions on reflection.
>> It was exp
On Fri, 28 Jun 2024 14:04:13 GMT, David M. Lloyd wrote:
>> Indeed, if you look at the previous revision, that's how I implemented it.
>> However, the generator currently needs access to `Lookup.IMPL_LOOKUP` in
>> order to generate a nestmate class and accessors for
On Thu, 27 Jun 2024 08:08:13 GMT, Alan Bateman wrote:
>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
>> support for functionality required to continue to support IIOP and custom
>> serializers in light of additional module-based restrictions on reflection.
>> It was
On Thu, 13 Jun 2024 14:31:06 GMT, David M. Lloyd wrote:
> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
> support for functionality required to continue to support IIOP and custom
> serializers in light of additional module-based restrictions on reflection.
Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support
for functionality required to continue to support IIOP and custom serializers
in light of additional module-based restrictions on reflection. It was expected
that these libraries would use `sun.misc.Unsafe` in order t
On Fri, 31 May 2024 13:04:03 GMT, David M. Lloyd wrote:
> The new method additions ClassReader.readEntryOrNull(int, Class) and
> ConstantPool.entryByIndex(int, Class) have incorrect since tags; they should
> be `@since 23`.
This pull request has now been integrated.
Changeset:
The new method additions ClassReader.readEntryOrNull(int, Class) and
ConstantPool.entryByIndex(int, Class) have incorrect since tags; they should be
`@since 23`.
-
Commit messages:
- 812: Incorrect since tags on new ClassReader and ConstantPool methods
Changes: https://git.ope
On Thu, 30 May 2024 21:47:02 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/classfile/ClassReader.java line 142:
>>
>>> 140: * @throws ConstantPoolException if the index is out of range of
>>> the
>>> 141: * constant pool size, or zero, or the entry is not of
On Wed, 29 May 2024 19:27:17 GMT, Chen Liang wrote:
>> I propose to add type-checked ConstantPool.entryByIndex and
>> ClassReader.readEntryOrNull taking an extra Class parameter, which throws
>> ConstantPoolException instead of ClassCastException on type mismatch, which
>> can happen to malfor
On Mon, 15 Jan 2024 02:30:39 GMT, ExE Boss wrote:
>> Chen Liang has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains ten commits:
>>
>> - Merge branch 'master' into fix/typearg-model
>> - redundant line
>> - Fix a test in langtools,
On Fri, 5 May 2023 16:31:18 GMT, Daniel Fuchs wrote:
> Thanks for your observations David!
>
> Use of synchronization in these handler classes has two purposes: one is
> visibility. Since Handlers are used by multiple (logging) threads, and
> potentially configured from different threads (e.g.
On Fri, 5 May 2023 13:43:43 GMT, Daniel Fuchs wrote:
> Several Handlers class use monitors to synchronize when formatting /
> publishing LogRecords.
> When logging within a VirtualThread, holding this monitor can cause the
> carrier thread to be pinned.
> Handlers could use jdk.internal.misc.In
On Thu, 6 Apr 2023 08:00:43 GMT, ExE Boss wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> src/java.base/share/classes/jdk/internal/util/Architecture.ja
On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev wrote:
> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The
> documentation for that method clearly says the precision and accuracy are
> dependent on the underlying system behavior. However, it always rounds up
> `nan
On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev wrote:
> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The
> documentation for that method clearly says the precision and accuracy are
> dependent on the underlying system behavior. However, it always rounds up
> `nan
On Fri, 24 Mar 2023 16:41:02 GMT, Michael Osipov wrote:
>> A bit of a quibble, several internet sources identify Linux as an operating
>> system (including Redhat).
>
> Well, no. It is just a kernel. Without a userland not an OS. That is why they
> call it GNU/Linux. Kernel + userland.
If you
On Mon, 21 Nov 2022 16:46:43 GMT, Strahinja Stanojevic wrote:
>> This PR introduces an option to output stable names for the lambda classes
>> in the JDK. A stable name consists of two parts: The first part is the
>> predefined value `$$Lambda$` appended to the lambda capturing class, and the
On Wed, 15 Feb 2023 17:32:38 GMT, David M. Lloyd wrote:
> The class generated for lambda proxies is now defined as a hidden class. This
> means that the counter, which was used to ensure a unique class name and
> avoid clashes, is now redundant. In addition to performing redun
On Fri, 24 Feb 2023 16:16:51 GMT, David M. Lloyd wrote:
>> The class generated for lambda proxies is now defined as a hidden class.
>> This means that the counter, which was used to ensure a unique class name
>> and avoid clashes, is now redundant. In addition to performing
s would also replace #10024.
David M. Lloyd has updated the pull request incrementally with one additional
commit since the last revision:
Remove final keyword
-
Changes:
- all: https://git.openjdk.org/jdk/pull/12579/files
- new: https://git.openjdk.org/jdk/pull/12579/files/
On Thu, 23 Feb 2023 23:50:16 GMT, Mandy Chung wrote:
>> David M. Lloyd has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Many tests have patterns for lambda class names; update them
>> - Update comme
s would also replace #10024.
David M. Lloyd has updated the pull request incrementally with one additional
commit since the last revision:
Apply formatting suggestions and update copyright notices
-
Changes:
- all: https://git.openjdk.org/jdk/pull/12579/files
- new: https://git
On Fri, 17 Feb 2023 19:37:59 GMT, David M. Lloyd wrote:
>> The class generated for lambda proxies is now defined as a hidden class.
>> This means that the counter, which was used to ensure a unique class name
>> and avoid clashes, is now redundant. In addition to performing
On Fri, 17 Feb 2023 19:37:59 GMT, David M. Lloyd wrote:
>> The class generated for lambda proxies is now defined as a hidden class.
>> This means that the counter, which was used to ensure a unique class name
>> and avoid clashes, is now redundant. In addition to performing
On Fri, 17 Feb 2023 02:11:10 GMT, Mandy Chung wrote:
>> David M. Lloyd has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use a unique index for the dumped lambda class instead of a time stamp
>
> `this_class
s would also replace #10024.
David M. Lloyd has updated the pull request incrementally with two additional
commits since the last revision:
- Many tests have patterns for lambda class names; update them
- Update comments and javadoc showin the old pattern
-
Changes:
- all: https
On Fri, 17 Feb 2023 16:55:28 GMT, Ioi Lam wrote:
> Java doesn't guarantee to use unique names even for "regular" classes. You
> can use two class loaders that load two completely different classes with the
> exact same name.
>
> How does Graal and qbicc handle this?
In qbicc, we keep separate
On Fri, 17 Feb 2023 15:18:25 GMT, Vojin Jovanovic wrote:
> We didn't use the cryptographic hash as it is not resilient to the changes
> that happen to the bytecode generators of hidden classes. If anything in the
> bytecode generation (e.g., in `InnerClassLambdaMetafactory`) changes, the
> has
s would also replace #10024.
David M. Lloyd has updated the pull request incrementally with one additional
commit since the last revision:
Updated to use hidden class suffix for dumps when possible, else use the
counter with a `failed` suffix. Also, remove the extra trailing `$` from the
lambda
On Thu, 16 Feb 2023 19:35:54 GMT, David M. Lloyd wrote:
>> The class generated for lambda proxies is now defined as a hidden class.
>> This means that the counter, which was used to ensure a unique class name
>> and avoid clashes, is now redundant. In addition to performing
On Thu, 16 Feb 2023 22:23:09 GMT, ExE Boss wrote:
>> The Lamdba class name already ends in `$` - is there a reason we'd need a
>> second one when dumping?
>
> I suggested removing it in:
> https://github.com/openjdk/jdk/pull/12579#discussion_r1108941733
Ah I missed that. Sure, I guess that's f
On Thu, 16 Feb 2023 19:37:18 GMT, ExE Boss wrote:
>> David M. Lloyd has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use a unique index for the dumped lambda class instead of a time stamp
>
> src/java.base/
s would also replace #10024.
David M. Lloyd has updated the pull request incrementally with one additional
commit since the last revision:
Use a unique index for the dumped lambda class instead of a time stamp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/12579/files
- new:
On Thu, 16 Feb 2023 14:06:54 GMT, David M. Lloyd wrote:
>> The class generated for lambda proxies is now defined as a hidden class.
>> This means that the counter, which was used to ensure a unique class name
>> and avoid clashes, is now redundant. In addition to performing
On Thu, 16 Feb 2023 14:06:54 GMT, David M. Lloyd wrote:
>> The class generated for lambda proxies is now defined as a hidden class.
>> This means that the counter, which was used to ensure a unique class name
>> and avoid clashes, is now redundant. In addition to performing
s would also replace #10024.
David M. Lloyd has updated the pull request incrementally with one additional
commit since the last revision:
Use `Instant.now()` for more precise timestamps.
Using `currentTimeMillis` is imprecise enough that tests may sporadically
fail if two lambda classes fro
On Thu, 16 Feb 2023 01:42:16 GMT, David M. Lloyd wrote:
>> The class generated for lambda proxies is now defined as a hidden class.
>> This means that the counter, which was used to ensure a unique class name
>> and avoid clashes, is now redundant. In addition to performing
s would also replace #10024.
David M. Lloyd has updated the pull request incrementally with two additional
commits since the last revision:
- Fix LambdaAsm test
- Fix stack walker test
-
Changes:
- all: https://git.openjdk.org/jdk/pull/12579/files
- new: https://git.openj
s would also replace #10024.
David M. Lloyd has updated the pull request incrementally with two additional
commits since the last revision:
- Import
- Beter timestamp placement
-
Changes:
- all: https://git.openjdk.org/jdk/pull/12579/files
- new: https://git.openjdk.org/jd
On Wed, 15 Feb 2023 22:44:21 GMT, David M. Lloyd wrote:
>> The class generated for lambda proxies is now defined as a hidden class.
>> This means that the counter, which was used to ensure a unique class name
>> and avoid clashes, is now redundant. In addition to performing
s would also replace #10024.
David M. Lloyd has refreshed the contents of this pull request, and previous
commits have been removed. The incremental views will show differences compared
to the previous content of the PR. The pull request contains one new commit
since the last revision:
829
On Wed, 15 Feb 2023 17:32:38 GMT, David M. Lloyd wrote:
> The class generated for lambda proxies is now defined as a hidden class. This
> means that the counter, which was used to ensure a unique class name and
> avoid clashes, is now redundant. In addition to performing redun
On Wed, 15 Feb 2023 17:32:38 GMT, David M. Lloyd wrote:
> The class generated for lambda proxies is now defined as a hidden class. This
> means that the counter, which was used to ensure a unique class name and
> avoid clashes, is now redundant. In addition to performing redun
On Wed, 15 Feb 2023 17:32:38 GMT, David M. Lloyd wrote:
> The class generated for lambda proxies is now defined as a hidden class. This
> means that the counter, which was used to ensure a unique class name and
> avoid clashes, is now redundant. In addition to performing redun
The class generated for lambda proxies is now defined as a hidden class. This
means that the counter, which was used to ensure a unique class name and avoid
clashes, is now redundant. In addition to performing redundant work, this also
impacts build reproducibility for native image generators wh
On Mon, 21 Nov 2022 16:46:43 GMT, Strahinja Stanojevic wrote:
>> This PR introduces an option to output stable names for the lambda classes
>> in the JDK. A stable name consists of two parts: The first part is the
>> predefined value `$$Lambda$` appended to the lambda capturing class, and the
79 matches
Mail list logo