On Mon, 29 Jul 2024 23:30:48 GMT, Chen Liang wrote:
>> Removes 6 `AccessFlags` factories that do not take class-file versions as
>> its arguments.
>>
>> `AccessFlags` is a wrapper around a bit mask to support modifier streaming
>> in ClassFile API. It additionally supports advanced validation
On Mon, 29 Jul 2024 19:36:31 GMT, Chen Liang wrote:
> In #20241, it's noted that `ClassFile.verify` can return a mix-and-match of
> mutable and immutable lists.
>
> Though the mutability of the list returned by `verify` has no particular
> importance, as the mutable list is constructed on
On Mon, 29 Jul 2024 12:32:10 GMT, Chen Liang wrote:
>> As discussed in offline meeting, the max stack and locals information are
>> part of the code attribute and not meaningful for buffered code elements.
>> Computation would be costly and these see no real usage during
>> transformations.
On Mon, 29 Jul 2024 02:22:11 GMT, Chen Liang wrote:
>> As discussed in offline meeting, the max stack and locals information are
>> part of the code attribute and not meaningful for buffered code elements.
>> Computation would be costly and these see no real usage during
>> transformations.
On Thu, 25 Jul 2024 23:11:15 GMT, Chen Liang wrote:
> Removes 6 `AccessFlags` factories that do not take class-file versions as its
> arguments.
>
> `AccessFlags` is a wrapper around a bit mask to support modifier streaming in
> ClassFile API. It additionally supports advanced validation
On Thu, 25 Jul 2024 22:41:08 GMT, Chen Liang wrote:
> As discussed in offline meeting, the max stack and locals information are
> part of the code attribute and not meaningful for buffered code elements.
> Computation would be costly and these see no real usage during
> transformations. Thus,
On Wed, 24 Jul 2024 13:00:47 GMT, Chen Liang wrote:
>> `TypeAnnotation` is not an annotation, as it should not be used in places
>> like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an
>> annotation at a given location instead of to be an annotation.
>>
>> Depends on #20205.
On Wed, 24 Jul 2024 07:58:31 GMT, ExE Boss wrote:
>> This transformation is called only after the `classModel` is transformed:
>> - at line 472 and 380 when the `transformToBytes()` method is called is
>> after effectively transforming the `classModel` inside the `Logic` class.
>
> There
On Tue, 23 Jul 2024 15:43:42 GMT, Chen Liang wrote:
>> Convert `AnnotationImpl` to a record so it comes with proper `equals` and
>> `hashCode` implementations. This also fixes the comparison for
>> annotation-valued annotation element values.
>
> Chen Liang has updated the pull request with a
On Tue, 23 Jul 2024 05:40:05 GMT, Chen Liang wrote:
>> `WritableElement` has always been one of the biggest peculiarities of
>> ClassFile API: it exposes element writing yet has no corresponding reading
>> ability exposed. Its existence creates a lot of API noise, increasing
>> maintenance
On Tue, 23 Jul 2024 04:44:57 GMT, Chen Liang wrote:
> Convert `AnnotationImpl` to a record so it comes with proper `equals` and
> `hashCode` implementations. This also fixes the comparison for
> annotation-valued annotation element values.
Looks good to me, thanks for the fix.
-
On Fri, 19 Jul 2024 15:32:24 GMT, Adam Sotona wrote:
> Artificially corrupted class with overflowing max - min values of
> `tableswitch` instruction cause infinite loop in
> `jdk.internal.classfile.impl.CodeImpl::inflateJumpTargets`
>
> This patch fixes the overflow and add
On Fri, 19 Jul 2024 15:41:07 GMT, Chen Liang wrote:
>> Artificially corrupted class with overflowing max - min values of
>> `tableswitch` instruction cause infinite loop in
>> `jdk.internal.classfile.impl.CodeImpl::inflateJumpTargets`
>>
>> This patch fixes the overflow and adds relevant
Artificially corrupted class with overflowing max - min values of `tableswitch`
instruction cause infinite loop in
`jdk.internal.classfile.impl.CodeImpl::inflateJumpTargets`
This patch fixes the overflow and adds relevant test.
Please review.
Thank you,
Adam
-
Commit messages:
On Fri, 19 Jul 2024 01:55:57 GMT, Chen Liang wrote:
> `TypeAnnotation` is not an annotation, as it should not be used in places
> like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an
> annotation at a given location instead of to be an annotation.
>
> Depends on #20205.
On Fri, 19 Jul 2024 01:55:57 GMT, Chen Liang wrote:
> `TypeAnnotation` is not an annotation, as it should not be used in places
> like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an
> annotation at a given location instead of to be an annotation.
>
> Depends on #20205.
On Thu, 18 Jul 2024 22:21:08 GMT, Chen Liang wrote:
> `BufferedMethodBuilder` accepts a static flag and passes it to the
> `CodeBuilder` it creates; yet it does not prevent static flag tampering like
> `DirectMethodBuilder` does. This patch makes their behaviors consistent.
>
> Note that the
On Thu, 18 Jul 2024 16:23:44 GMT, Adam Sotona wrote:
> `ClassFile.verify()` should always return list of verification errors and
> never throw an exception, even for corrupted classes.
> `BoundAttribute` initializations of `LocalVariableTable` and
> `LocalVariableTypeTable` a
On Fri, 19 Jul 2024 08:26:46 GMT, Adam Sotona wrote:
>> `ClassFile.verify()` should always return list of verification errors and
>> never throw an exception, even for corrupted classes.
>> `BoundAttribute` initializations of `LocalVariableTable` and
>> `LocalVariable
On Thu, 18 Jul 2024 22:56:10 GMT, Chen Liang wrote:
>> `WritableElement` has always been one of the biggest peculiarities of
>> ClassFile API: it exposes element writing yet has no corresponding reading
>> ability exposed. Its existence creates a lot of API noise, increasing
>> maintenance
ialization.
>
> Relevant test is added.
>
> Please review.
>
> Thanks,
> Adam
Adam Sotona has updated the pull request incrementally with one additional
commit since the last revision:
nit change
-
Changes:
- all: https://git.openjdk.org/jdk/pull/20241/fi
ialization.
>
> Relevant test is added.
>
> Please review.
>
> Thanks,
> Adam
Adam Sotona has updated the pull request incrementally with one additional
commit since the last revision:
wrapped ClassFile::verify(Method) + added test
-
Changes:
- all: h
On Thu, 18 Jul 2024 21:57:52 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java
>> line 117:
>>
>>> 115:
>>> 116: public static List verify(ClassModel classModel,
>>> ClassHierarchyResolver classHierarchyResolver, Consumer logger)
`ClassFile.verify()` should always return list of verification errors and never
throw an exception, even for corrupted classes.
`BoundAttribute` initializations of `LocalVariableTable` and
`LocalVariableTypeTable` attributes do not expect invalid possible locations
and cause
On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote:
> Hi all,
> After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the
> footprint memory usage increased significantly when run the testcase with
> -Xcomp jvm options, then cause the testcase was killed by docker by OOM.
>
On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote:
> Hi all,
> After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the
> footprint memory usage increased significantly when run the testcase with
> -Xcomp jvm options, then cause the testcase was killed by docker by OOM.
>
On Wed, 17 Jul 2024 21:31:51 GMT, Chen Liang wrote:
> There's another bug in ClassFile transform composition where the downstream
> transform receives items from upstream transform's chained builders before
> the downstream transform itself starts. This is a simple fix, and a test case
>
On Wed, 17 Jul 2024 20:51:32 GMT, Chen Liang wrote:
> Qualify the reading of entry lists with the anticipated types up-front, so we
> throw the correct `ConstantPoolException` instead of `ClassCastException`
> when we encounter malformed attribute lists. (`ClassModel.getInterfaces`
> already
> Class-File API is leaving preview.
> This is a removal of all `@PreviewFeature` annotations from Class-File API.
> It also bumps all `@since` tags and removes
> `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
>
> Please review.
>
> Thanks,
> Adam
Adam
On Tue, 16 Jul 2024 23:50:17 GMT, Chen Liang wrote:
> `WritableElement` has always been one of the biggest peculiarities of
> ClassFile API: it exposes element writing yet has no corresponding reading
> ability exposed. Its existence creates a lot of API noise, increasing
> maintenance cost
On Tue, 16 Jul 2024 23:50:17 GMT, Chen Liang wrote:
> `WritableElement` has always been one of the biggest peculiarities of
> ClassFile API: it exposes element writing yet has no corresponding reading
> ability exposed. Its existence creates a lot of API noise, increasing
> maintenance cost
On Mon, 15 Jul 2024 15:16:23 GMT, Chen Liang wrote:
>> Remove unused `Class/Field/Method/CodeBuilder.original()`, and make
>> `Field/Method/CodeModel.parent()` return present only if it's bound (i.e.
>> not buffered transformed). See the CSR for details.
>
> Chen Liang has updated the pull
On Mon, 15 Jul 2024 05:53:12 GMT, Adam Sotona wrote:
> 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due
> to IllegalArgumentException: hash must be nonzero
This pull request has now been integrated.
Changeset: 52cd9bb5
Author: Adam Sotona
URL:
On Mon, 15 Jul 2024 05:53:12 GMT, Adam Sotona wrote:
> 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due
> to IllegalArgumentException: hash must be nonzero
Thank you.
-
PR Comment: https://git.openjdk.org/jdk/pull/20180#issuecomment-2228021104
8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to
IllegalArgumentException: hash must be nonzero
-
Commit messages:
- Backport 3f2636d9b71f5270c83d17dcf5d18cf907978475
Changes: https://git.openjdk.org/jdk/pull/20180/files
Webrev:
On Sun, 14 Jul 2024 13:49:09 GMT, Chen Liang wrote:
>> Removes ClassFile API transformation implementation details accidentally
>> leaked to public API. Users don't have access to classes necessary to
>> correctly implement these transform resolutions. In addition, removed
>> improper
On Mon, 8 Jul 2024 13:09:50 GMT, Adam Sotona wrote:
> Class-File API constant pool implementation requires non-zero entry hash code.
> Unfortunately current implementation computes zero hash code for specific CP
> entries.
>
> This patch removes invalid and obsolete `AbstractPo
On Tue, 9 Jul 2024 23:29:28 GMT, Chen Liang wrote:
>> `CompoundElement` already inherits `Iterable` and its `forEach(Consumer)`,
>> thus we can remove `Iterable elements()` and `forEachElements(Consumer)`.
>
> Chen Liang has updated the pull request incrementally with one additional
> commit
On Wed, 10 Jul 2024 22:10:50 GMT, Chen Liang wrote:
> Please review this non-clean backport of the bugfix in #20100 to release 23,
> where ClassFile API chained builders does not emit certain elements through
> downstream transforms and returns wrong builder for chaining. This backport
>
On Tue, 9 Jul 2024 19:00:45 GMT, Chen Liang wrote:
>> Removes ClassFile API transformation implementation details accidentally
>> leaked to public API. Users don't have access to classes necessary to
>> correctly implement these transform resolutions. In addition, removed
>> improper
On Tue, 9 Jul 2024 17:34:14 GMT, Chen Liang wrote:
> Please review the fix for a major transformation bug within the ClassFile
> API, where certain kinds of buffered elements produced by one transform is
> not sent to the next, and the "chained" (`andThen` transformation chains)
> builders
On Mon, 8 Jul 2024 13:57:20 GMT, Chen Liang wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed BootstrapMethodEntryImpl::computeHashCode
>
> src/java.base/share/class
File API benchmarks.
>
> Please review.
>
> Thanks,
> Adam
Adam Sotona has updated the pull request incrementally with one additional
commit since the last revision:
fixed BootstrapMethodEntryImpl::computeHashCode
-
Changes:
- all: https://git.openjdk.org/jdk/pull
Class-File API constant pool implementation requires non-zero entry hash code.
Unfortunately current implementation computes zero hash code for specific CP
entries.
This patch removes invalid and obsolete `AbstractPoolEntry::phiMix` calculation
and assures all pool entries have non-zero hash. A
On Wed, 3 Jul 2024 02:38:58 GMT, Chen Liang wrote:
> Please review this clean backport of #19981 onto JDK 23, fixing
> `StackMapGenerator` generating static methods with no declared local variable
> a max local of 1.
Marked as reviewed by asotona (Reviewer).
-
PR Review:
On Thu, 4 Jul 2024 18:04:27 GMT, Nizar Benalla wrote:
> Please review this simple doc only change.
> Some methods in ClassFile API were renamed recently as part of
> [JDK-8335290](https://bugs.openjdk.org/browse/JDK-8335290) and
> [JDK-8335110](https://bugs.openjdk.org/browse/JDK-8335110) and
On Mon, 1 Jul 2024 22:54:16 GMT, Chen Liang wrote:
> Trivial fix for the bug where `StackMapGenerator` is pre-allocating the
> locals incorrectly, affecting static methods with 0 locals. `StackCounter`
> was not affected.
Looks good to me, thanks for the fix.
-
Marked as
On Wed, 26 Jun 2024 06:53:28 GMT, Adam Sotona wrote:
> Conversion of `java.lang.invoke` package to Class-File API is failing to
> execute method handles with specific type conversion requirements. Root cause
> is in the new `TypeConvertingMethodAdapter::primitiveTypeKind
On Wed, 26 Jun 2024 06:53:28 GMT, Adam Sotona wrote:
> Conversion of `java.lang.invoke` package to Class-File API is failing to
> execute method handles with specific type conversion requirements. Root cause
> is in the new `TypeConvertingMethodAdapter::primitiveTypeKind
On Wed, 26 Jun 2024 06:53:28 GMT, Adam Sotona wrote:
> Conversion of `java.lang.invoke` package to Class-File API is failing to
> execute method handles with specific type conversion requirements. Root cause
> is in the new `TypeConvertingMethodAdapter::primitiveTypeKind
On Fri, 28 Jun 2024 22:01:33 GMT, Chen Liang wrote:
> `ClassFile::transform` was initially `ClassModel::transform`, which
> transforms the receiver class model to a new class byte array. This
> functionality was in parallel with `ClassBuilder::transform`, which accepts a
> `ClassModel` and a
On Tue, 18 Jun 2024 07:41:26 GMT, Claes Redestad wrote:
> Simple refactoring to extract identical, simple lambda expressions. Improve
> code clarity and reduce classes generated.
Looks good to me.
-
Marked as reviewed by asotona (Reviewer).
PR Review:
On Tue, 25 Jun 2024 21:22:34 GMT, Chen Liang wrote:
>> This is a collection of fixes and improvements to CodeBuilder, plus 2
>> renames.
>>
>> Fixes include:
>> 1. `CodeBuilder::receiverSlot` typo
>> 2. `CodeAttribute::labelToBci` update spec
>> 3. `CodeBuilder::exceptionCatch` implementation
On Tue, 25 Jun 2024 13:47:39 GMT, Adam Sotona wrote:
>> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code
>> generation and unfortunately it causes StackOverflow on BigEndian platforms.
>>
>> This patch converts all lambdas in ClassSpeciali
On Mon, 24 Jun 2024 16:01:41 GMT, Adam Sotona wrote:
> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code
> generation and unfortunately it causes StackOverflow on BigEndian platforms.
>
> This patch converts all lambdas in ClassSpecializer into ano
Conversion of `java.lang.invoke` package to Class-File API is failing to
execute method handles with specific type conversion requirements. Root cause
is in the new `TypeConvertingMethodAdapter::primitiveTypeKindFromClass`
implementation. Original code has been matching the types by hash code
On Tue, 25 Jun 2024 13:45:17 GMT, Oussama Louati wrote:
>> test/jdk/java/lang/invoke/indify/Indify.java line 386:
>>
>>> 384:
>>> 385: byte[] transformToBytes(ClassModel classModel) {
>>> 386: return of().transform(classModel, ClassTransform.ACCEPT_ALL);
>>
>> What is the purpose
On Tue, 25 Jun 2024 09:36:37 GMT, Adam Sotona wrote:
>> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code
>> generation and unfortunately it causes StackOverflow on BigEndian platforms.
>>
>> This patch converts all lambdas in ClassSpeciali
d test on a BigEndian platform.
>
> Thanks,
> Adam
Adam Sotona has updated the pull request incrementally with one additional
commit since the last revision:
more de-lambda work on ClassSpecializer
-
Changes:
- all: https://git.openjdk.org/jdk/pull/19863/files
- new: ht
On Sat, 22 Jun 2024 15:55:28 GMT, Oussama Louati wrote:
>> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code
>> private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle,
>> MethodType, and CallSite constants.
>> ### Purpose of Indify
>>
>> -
On Sat, 22 Jun 2024 15:55:28 GMT, Oussama Louati wrote:
>> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code
>> private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle,
>> MethodType, and CallSite constants.
>> ### Purpose of Indify
>>
>> -
On Mon, 24 Jun 2024 16:01:41 GMT, Adam Sotona wrote:
> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code
> generation and unfortunately it causes StackOverflow on BigEndian platforms.
>
> This patch converts all lambdas in ClassSpecializer into ano
d test on a BigEndian platform.
>
> Thanks,
> Adam
Adam Sotona has updated the pull request incrementally with one additional
commit since the last revision:
more lambdas conversions to fix bootstrap
-
Changes:
- all: https://git.openjdk.org/jdk/pull/19863/files
- new: ht
On Mon, 24 Jun 2024 16:01:41 GMT, Adam Sotona wrote:
> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code
> generation and unfortunately it causes StackOverflow on BigEndian platforms.
>
> This patch converts all lambdas in ClassSpecializer into ano
After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code
generation and unfortunately it causes StackOverflow on BigEndian platforms.
This patch converts all lambdas in ClassSpecializer into anonymous inner
classes.
Please review and test on a BigEndian platform.
Thanks,
On Sat, 22 Jun 2024 00:26:51 GMT, Chen Liang wrote:
> Please review this clean backport of #19708, to make javap recover and
> continue after encountering undefined access flag bits set while still
> exiting with a code of error, allowing it to error against improper bits
> while still
On Fri, 21 Jun 2024 15:52:44 GMT, Chen Liang wrote:
> `ClassReader.readXxxEntry` were added before we had generic, type-aware
> `readEntry` and `readEntryOrNull` APIs (#19330). We should remove these
> specialized versions in favor of the generic version to reduce API bloating.
Looks good to
On Fri, 21 Jun 2024 14:38:44 GMT, Chen Liang wrote:
> In preparation of Class-File API exiting review, we are housekeeping our API
> surface. These 3 method removals are the most obvious and simple ones.
>
> This is separated from more throughout and (possibly controversial) changes
> for the
On Fri, 21 Jun 2024 12:31:05 GMT, Alan Bateman wrote:
> Looks like this has been accidentally created as a sub-task of the JEP issue,
> I assume you'll fix that. Will there be another issue to update the tests and
> drop `@enablePreview`?
I thought the implementation is usually created as a
On Fri, 21 Jun 2024 11:56:37 GMT, Adam Sotona wrote:
> Class-File API is leaving preview.
> This is a removal of all `@PreviewFeature` annotations from Class-File API.
> It also bumps all `@since` tags and removes
> `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
>
Class-File API is leaving preview.
This is a removal of all `@PreviewFeature` annotations from Class-File API.
It also bumps all `@since` tags and removes
`jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
Please review.
Thanks,
Adam
-
Commit messages:
- bumped @since tag
On Thu, 20 Jun 2024 20:11:06 GMT, Chen Liang wrote:
> Please review this patch, which is a backport of the fix in #19615 to JDK 23.
>
> This is not a clean patch, because the old patch was done on JDK-8333479
> (#19585) which was absent in JDK 23; however, the conflicts were small, and
> the
On Thu, 14 Dec 2023 12:39:52 GMT, Adam Sotona wrote:
> java.base java.lang.invoke package heavily uses ASM to generate lambdas and
> method handles.
>
> This patch converts ASM calls to Classfile API.
>
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
On Wed, 19 Jun 2024 09:08:35 GMT, Adam Sotona wrote:
>> java.base java.lang.invoke package heavily uses ASM to generate lambdas and
>> method handles.
>>
>> This patch converts ASM calls to Classfile API.
>>
>> This PR is continuation of https://github.c
come.
>
> Please review.
>
> Thank you,
> Adam
Adam Sotona has updated the pull request incrementally with two additional
commits since the last revision:
- removed empty line
- problem-listed runtime/ClassInitErrors/TestStackOverflowDuringInit.java
-
Changes:
- all:
come.
>
> Please review.
>
> Thank you,
> Adam
Adam Sotona has updated the pull request incrementally with one additional
commit since the last revision:
fixed sneaky completion typo
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17108/files
- new: https://git.op
come.
>
> Please review.
>
> Thank you,
> Adam
Adam Sotona has updated the pull request incrementally with one additional
commit since the last revision:
Update
src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
Co-authored-by: ExE Boss <
come.
>
> Please review.
>
> Thank you,
> Adam
Adam Sotona has updated the pull request incrementally with one additional
commit since the last revision:
Inlined condy construction directly into CP entries
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17108/files
come.
>
> Please review.
>
> Thank you,
> Adam
Adam Sotona has updated the pull request incrementally with four additional
commits since the last revision:
- Merge pull request #8 from cl4es/serialization_hostile
SerializationHostileMethod
- Reduce gratuitous code movement
- In
On Thu, 13 Jun 2024 14:11:48 GMT, Chen Liang wrote:
>> Please review this patch that fixes a critical issue that breaks some Proxy
>> usages.
>>
>> Since the problematic patch from before cannot be backed out, this patch
>> aims to emulate the old behavior before. A diff between before the
On Mon, 17 Jun 2024 17:38:56 GMT, Chen Liang wrote:
>> Currently, javap crashes for class files that have set non-zero values for
>> undefined access flag bits, as
>> `java.lang.reflect.AccessFlag.maskToAccessFlag` and
>> `java.lang.classfile.AccessFlags.flags` fail. In contrast, the JVMS,
On Mon, 17 Jun 2024 13:55:41 GMT, Chen Liang wrote:
>> Currently, javap crashes for class files that have set non-zero values for
>> undefined access flag bits, as
>> `java.lang.reflect.AccessFlag.maskToAccessFlag` and
>> `java.lang.classfile.AccessFlags.flags` fail. In contrast, the JVMS,
On Mon, 17 Jun 2024 13:55:41 GMT, Chen Liang wrote:
>> Currently, javap crashes for class files that have set non-zero values for
>> undefined access flag bits, as
>> `java.lang.reflect.AccessFlag.maskToAccessFlag` and
>> `java.lang.classfile.AccessFlags.flags` fail. In contrast, the JVMS,
come.
>
> Please review.
>
> Thank you,
> Adam
Adam Sotona has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 32 commits:
- Merge branch 'master' into JDK-8294960-invoke
# Conflicts:
#src/java.base/share/classes/ja
come.
>
> Please review.
>
> Thank you,
> Adam
Adam Sotona has updated the pull request incrementally with one additional
commit since the last revision:
Update
src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
Co-authored-by: Chen Liang
On Wed, 12 Jun 2024 20:27:05 GMT, Chen Liang wrote:
>> Adam Sotona has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - reverted static initialization of ConstantPoolBuilder and CP entries
>> - fixed naming
On Thu, 6 Jun 2024 13:17:20 GMT, Chen Liang wrote:
>> Adam Sotona has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - reverted static initialization of ConstantPoolBuilder and CP entries
>> - fixed naming
On Thu, 6 Jun 2024 12:22:41 GMT, Chen Liang wrote:
>> Adam Sotona has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - reverted static initialization of ConstantPoolBuilder and CP entries
>> - fixed naming
On Thu, 6 Jun 2024 12:17:14 GMT, Chen Liang wrote:
>> Adam Sotona has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - reverted static initialization of ConstantPoolBuilder and CP entries
>> - fixed naming
On Thu, 6 Jun 2024 12:13:44 GMT, Chen Liang wrote:
>> Adam Sotona has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - reverted static initialization of ConstantPoolBuilder and CP entries
>> - fixed naming
On Thu, 13 Jun 2024 09:27:44 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 616:
>>
>>> 614: final ClassDesc classDesc = ClassDesc.of(className0);
>>> 615: final ClassDesc superClassDesc =
>>>
On Fri, 14 Jun 2024 17:02:40 GMT, Chen Liang wrote:
>> Currently, javap crashes for class files that have set non-zero values for
>> undefined access flag bits, as
>> `java.lang.reflect.AccessFlag.maskToAccessFlag` and
>> `java.lang.classfile.AccessFlags.flags` fail. In contrast, the JVMS,
On Fri, 24 May 2024 17:12:34 GMT, Oussama Louati wrote:
>> test/jdk/java/lang/invoke/indify/Indify.java line 503:
>>
>>> 501:
>>> 502: Iterator instructionIterator
>>> =getInstructions(m).iterator();
>>> 503: final Stack shouldProceedAfterIndyAdded = new
>>>
On Tue, 28 May 2024 11:03:18 GMT, Oussama Louati wrote:
>> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code
>> private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle,
>> MethodType, and CallSite constants.
>> It currently uses ad-hoc code to
On Fri, 24 May 2024 17:12:24 GMT, Oussama Louati wrote:
>> test/jdk/java/lang/invoke/indify/Indify.java line 578:
>>
>>> 576: classTransform =
>>> ClassTransform.transformingMethodBodies(filter, codeTransform);
>>> 577: classModel = of().parse(
come.
>
> Please review.
>
> Thank you,
> Adam
Adam Sotona has updated the pull request incrementally with two additional
commits since the last revision:
- reverted static initialization of ConstantPoolBuilder and CP entries
- fixed naming conventions
-
Changes:
- all:
come.
>
> Please review.
>
> Thank you,
> Adam
Adam Sotona has updated the pull request incrementally with one additional
commit since the last revision:
use of jdk.internal.constant to improve performance
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17108/files
come.
>
> Please review.
>
> Thank you,
> Adam
Adam Sotona has updated the pull request incrementally with one additional
commit since the last revision:
fixed imports
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17108/files
- new: https://git.openjdk.org/
come.
>
> Please review.
>
> Thank you,
> Adam
Adam Sotona has updated the pull request incrementally with one additional
commit since the last revision:
Apply suggestions from code review
There are new possibilities with decoupled constants implementation, thank
you for the
come.
>
> Please review.
>
> Thank you,
> Adam
Adam Sotona has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 24 commits:
- Merge branch 'master' into JDK-8294960-invoke
# Conflicts:
#
src/j
1 - 100 of 1072 matches
Mail list logo
