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
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 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
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 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 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
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
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 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 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 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 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/
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: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
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 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
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
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 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
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
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 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:
Remove final keyword
-
Changes:
- all: https://git.openjdk.org/jdk/pull/12579/files
- new: https://git.openjdk.org/jdk/pull/12579/files/
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
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 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 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 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 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 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 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 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 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 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
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 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:
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 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.
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 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 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 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 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 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 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-"
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 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
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
> 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 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
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
> 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 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
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 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 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 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 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
64 matches
Mail list logo
