Integrated: JDK-8274311: Make build.tools.jigsaw.GenGraphs more configurable

2021-09-27 Thread Mandy Chung
On Fri, 24 Sep 2021 23:07:33 GMT, Mandy Chung wrote: > GenGraphs tool generates the module graph. It currently supports the > configuration via javadoc-graphs.properties. However, > `make/jdk/src/classes/build/tools/jigsaw/javadoc-graphs.properties` only > documents two propertie

RFR: JDK-8274311: Make build.tools.jigsaw.GenGraphs more configurable

2021-09-24 Thread Mandy Chung
GenGraphs tool generates the module graph. It currently supports the configuration via javadoc-graphs.properties. However, `make/jdk/src/classes/build/tools/jigsaw/javadoc-graphs.properties` only documents two properties. It should be updated to cover all configurable properties. There are a

Re: RFR: 8266936: Add a finalization JFR event [v12]

2021-09-24 Thread Mandy Chung
On Fri, 24 Sep 2021 09:27:02 GMT, Markus Grönlund wrote: >> Greetings, >> >> Object.finalize() was deprecated in JDK9. There is an ongoing effort to >> replace and mitigate Object.finalize() uses in the JDK libraries; please see >> https://bugs.openjdk.java.net/browse/JDK-8253568 for more

Re: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file [v3]

2021-09-23 Thread Mandy Chung
On Thu, 23 Sep 2021 14:53:42 GMT, Christian Stein wrote: >> This commit appends the name of the JAR file to the exception message for >> when automatic module lists a non-existing provider class. > > Christian Stein has updated the pull request incrementally with one > additional commit since

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v9]

2021-09-22 Thread Mandy Chung
> > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] > https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request with a new target base due to

Re: RFR: 8274071: Clean up java.lang.ref comments and documentation

2021-09-21 Thread Mandy Chung
On Tue, 21 Sep 2021 12:05:27 GMT, Pavel Rappo wrote: > This PR fixes an inline comment typo and reduces "overlinking" in a doc > comment in `java.lang.ref.Reference`. Overlinking happens because the > `reachabilityFence` method: > * Links `package-summary.html#reachability` twice. > * Refers

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8]

2021-09-21 Thread Mandy Chung
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation >> uses `MethodHandle`. For `Field` accessor, the new implementa

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8]

2021-09-20 Thread Mandy Chung
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation >> uses `MethodHandle`. For `Field` accessor, the new implementa

Re: RFR: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms [v5]

2021-09-16 Thread Mandy Chung
On Fri, 17 Sep 2021 02:17:09 GMT, Remilia Scarlet wrote: >> The test assumes that it always runs on 64-bit platform and >> classes_nocoops.jsa is always created. >> It's a test bug. The test should only expect classes_nocoops.jsa exists if >> it's running on a supported 64-bit platform. >>

Re: RFR: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms [v4]

2021-09-16 Thread Mandy Chung
On Fri, 17 Sep 2021 01:47:05 GMT, Remilia Scarlet wrote: >> The test assumes that it always runs on 64-bit platform and >> classes_nocoops.jsa is always created. >> It's a test bug. The test should only expect classes_nocoops.jsa exists if >> it's running on a supported 64-bit platform. >>

Re: RFR: 8273401: Disable JarIndex support in URLClassPath [v3]

2021-09-16 Thread Mandy Chung
On Thu, 16 Sep 2021 13:32:08 GMT, wxiang wrote: >> There is a bug for URLClassPath.findResources with JarIndex. >> Currently, there was agreement on dropping the support from the >> URLClassLoader implementation but it was suggested that it should be >> disabled for a release or two before

Re: RFR: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms [v3]

2021-09-16 Thread Mandy Chung
On Thu, 16 Sep 2021 17:48:35 GMT, Calvin Cheung wrote: > The fix in the test case seems fine to me. This test may fail in other cases. We should prepare for those cases in this fix: if (!Platform.isDefaultCDSArchiveSupported() && !Platform.isAArch64())) throw new SkippedException("not a

Re: RFR: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms [v3]

2021-09-16 Thread Mandy Chung
On Thu, 16 Sep 2021 03:44:24 GMT, Remilia Scarlet wrote: >> The test assumes that it always runs on 64-bit platform and >> classes_nocoops.jsa is always created. >> It's a test bug. The test should only expect classes_nocoops.jsa exists if >> it's running on a supported 64-bit platform. >>

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8]

2021-09-15 Thread Mandy Chung
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation >> uses `MethodHandle`. For `Field` accessor, the new implementa

Re: RFR: 8273774: jdk.tools.jlink.internal.Platform::is64Bit() should not hard code for x64 and AARCH64

2021-09-15 Thread Mandy Chung
On Wed, 15 Sep 2021 06:28:25 GMT, Remilia Scarlet wrote: > Currently, the Platform.is64Bit() hard coded for judging whether the target > arch is 64-bit. > The `classes_nocoops.jsa not found` issue can be found while testing > CDSPluginTest.java on 64-bit platform, excluding x64 and AARCH64,

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8]

2021-09-14 Thread Mandy Chung
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation >> uses `MethodHandle`. For `Field` accessor, the new implementa

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8]

2021-09-14 Thread Mandy Chung
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation >> uses `MethodHandle`. For `Field` accessor, the new implementa

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8]

2021-09-14 Thread Mandy Chung
On Tue, 14 Sep 2021 19:33:38 GMT, Peter Levart wrote: > Just another question: Is migrating from Unsafe based FieldAccessor(s) to > VarHandle based an important step to final goal of Unsafe elimination because > I don't think it is a necessary step for Loom. No. We could continue to use

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8]

2021-09-14 Thread Mandy Chung
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation >> uses `MethodHandle`. For `Field` accessor, the new implementa

Re: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage

2021-09-13 Thread Mandy Chung
On Mon, 13 Sep 2021 11:06:15 GMT, Сергей Цыпанов wrote: > Currently the method is implemented like > > public List> parameterList() { > return Collections.unmodifiableList(Arrays.asList(ptypes.clone())); > } > > This seems to be excessive, as three objects are allocated here. Instead we >

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8]

2021-09-13 Thread Mandy Chung
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation >> uses `MethodHandle`. For `Field` accessor, the new implementa

Integrated: JDK-8273194: Document the two possible cases when Lookup::ensureInitialized returns

2021-09-10 Thread Mandy Chung
On Wed, 1 Sep 2021 20:56:59 GMT, Mandy Chung wrote: > Improve the specification to document the cases when > `Lookup::ensureInitialized` returns as specified JVMS 5.5 and matches the > implementation. > > Please also review CSR: https://bugs.openjdk.java.net/browse/JDK-827

Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging

2021-09-09 Thread Mandy Chung
On Fri, 3 Sep 2021 17:19:05 GMT, Phil Race wrote: > Hmm I was under the impression this was removing AppContext itself but it is > just removing the backdoor needed by logging > Perhaps this isn't the change that requires the CSR but it then leaves an > inconsistent state where desktop

Re: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v3]

2021-09-09 Thread Mandy Chung
On Fri, 3 Sep 2021 12:01:12 GMT, Vladimir Ivanov wrote: > > For the change of MethodHandle::asType to a final method, this needs a CSR. > > It is not allowed to extend/subclass `MethodHandle` outside > `java.lang.invoke` package. > So, the aforementioned change doesn't have any compatibility

Re: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v3]

2021-09-02 Thread Mandy Chung
On Thu, 2 Sep 2021 11:35:52 GMT, Vladimir Ivanov wrote: >> `MethodHandle.asTypeCache` keeps a strong reference to adapted >> `MethodHandle` and it can introduce a class loader leak through its >> `MethodType`. >> >> Proposed fix introduces a 2-level cache (1 element each) where 1st level can

Re: RFR: JDK-8273194: Document the two possible cases when Lookup::ensureInitialized returns [v2]

2021-09-02 Thread Mandy Chung
> Improve the specification to document the cases when > `Lookup::ensureInitialized` returns as specified JVMS 5.5 and matches the > implementation. > > Please also review CSR: https://bugs.openjdk.java.net/browse/JDK-8273253 Mandy Chung has updated the pull request increme

Re: RFR: JDK-8273194: Document the two possible cases when Lookup::ensureInitialized returns [v2]

2021-09-02 Thread Mandy Chung
On Thu, 2 Sep 2021 14:00:03 GMT, Alan Bateman wrote: >> Mandy Chung has updated the pull request incrementally with one additional >> commit since the last revision: >> >> review comment > > src/java.base/share/classes/java/lang/invoke/MethodHand

RFR: JDK-8273194: Document the two possible cases when Lookup::ensureInitialized returns

2021-09-01 Thread Mandy Chung
Improve the specification to document the cases when `Lookup::ensureInitialized` returns as specified JVMS 5.5 and matches the implementation. Please also review CSR: https://bugs.openjdk.java.net/browse/JDK-8273253 - Commit messages: - JDK-8273194: Document the two possible

Re: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v2]

2021-09-01 Thread Mandy Chung
On Wed, 1 Sep 2021 16:23:46 GMT, Vladimir Ivanov wrote: >> `MethodHandle.asTypeCache` keeps a strong reference to adapted >> `MethodHandle` and it can introduce a class loader leak through its >> `MethodType`. >> >> Proposed fix introduces a 2-level cache (1 element each) where 1st level can

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8]

2021-08-31 Thread Mandy Chung
> > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] > https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request incrementally w

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v3]

2021-08-31 Thread Mandy Chung
On Tue, 31 Aug 2021 16:01:39 GMT, Maurizio Cimadamore wrote: > Please throw a "Reflection" somewhere :-) - e.g. "ReflectionInvokerBuilder" Done. I'm fine with that. - PR: https://git.openjdk.java.net/jdk/pull/5027

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v7]

2021-08-31 Thread Mandy Chung
> > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] > https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request incrementally with one additiona

Re: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation

2021-08-31 Thread Mandy Chung
On Thu, 26 Aug 2021 15:35:44 GMT, Paul Sandoz wrote: > May i suggest that we add some JavaDoc to `ensureClassInitialized` describing > the two cases of the calling thread is the initialization thread or not. This is a good suggestion that also applies to `Lookup::ensureInitialized`. I

Re: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation

2021-08-31 Thread Mandy Chung
On Wed, 25 Aug 2021 22:05:24 GMT, Vladimir Ivanov wrote: > Get rid of WeakReference-based logic in > DirectMethodHandle::checkInitialized() and reimplement it with > `Unsafe::ensureClassInitialized()`/`shouldBeInitialized()`. > > The key observation is that `Unsafe::ensureClassInitialized()`

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v6]

2021-08-31 Thread Mandy Chung
> > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] > https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request incrementally with one addition

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v5]

2021-08-30 Thread Mandy Chung
> > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] > https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request incrementally with one additi

Re: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading

2021-08-30 Thread Mandy Chung
On Thu, 26 Aug 2021 17:57:26 GMT, Paul Sandoz wrote: >> `MethodHandle.asTypeCache` keeps a strong reference to adapted >> `MethodHandle` and it can introduce a class loader leak through its >> `MethodType`. >> >> Proposed fix introduces a 2-level cache (1 element each) where 1st level can >>

Re: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading

2021-08-30 Thread Mandy Chung
On Wed, 25 Aug 2021 09:31:51 GMT, Vladimir Ivanov wrote: > `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle` > and it can introduce a class loader leak through its `MethodType`. > > Proposed fix introduces a 2-level cache (1 element each) where 1st level can > only

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v4]

2021-08-30 Thread Mandy Chung
> > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] > https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request incrementally with fo

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v3]

2021-08-30 Thread Mandy Chung
On Fri, 27 Aug 2021 13:28:08 GMT, Maurizio Cimadamore wrote: > Overall, seems like a solid piece of work. I did not review in full the > intricacies with caller sensitive (as I don't know that area too much), but > the general rewrite seems solid. Thanks for the review. > One thing I had

Re: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null [v3]

2021-08-29 Thread Mandy Chung
On Thu, 26 Aug 2021 02:36:47 GMT, Vicente Romero wrote: >> Please review this simple PR along with the associated CSR. The PR is >> basically adding a line the the specification of method >> `java.lang.runtime.ObjectMethods::bootstrap` stating under what conditions a >> NPE will be thrown. >>

Re: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null [v2]

2021-08-25 Thread Mandy Chung
On 8/25/21 12:08 PM, Vicente Romero wrote: On Wed, 25 Aug 2021 02:17:12 GMT, Mandy Chung wrote: Hi Mandy, I have changed the implementation of the method to explicitly require all arguments but lookup to be non-null as suggested by Brian. I have also covered, I think, all the missing

Re: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null [v2]

2021-08-24 Thread Mandy Chung
On Tue, 24 Aug 2021 03:03:37 GMT, Vicente Romero wrote: >> src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 327: >> >>> 325: * @throws IllegalArgumentException if the bootstrap arguments are >>> invalid >>> 326: * or inconsistent

Re: RFR: 8264322: Generate CDS archive when creating custom JDK image [v2]

2021-08-23 Thread Mandy Chung
On Fri, 20 Aug 2021 00:09:01 GMT, Calvin Cheung wrote: >> Please review this change for adding a `jlink` command line option >> `--generate-cds-archive` for generating CDS archives as a post processing >> step during the creation of a custom JDK image. >> >> Details can be found in the

Re: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null

2021-08-23 Thread Mandy Chung
On Mon, 23 Aug 2021 18:08:02 GMT, Vicente Romero wrote: > Please review this simple PR along with the associated CSR. The PR is > basically adding a line the the specification of method > `java.lang.runtime.ObjectMethods::bootstrap` stating under what conditions a > NPE will be thrown. > >

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v3]

2021-08-22 Thread Mandy Chung
On Sun, 22 Aug 2021 01:53:40 GMT, liach wrote: >> Mandy Chung has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove separate accessor for static vs instance method >> >> There is no effectiv

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v3]

2021-08-21 Thread Mandy Chung
On Sat, 21 Aug 2021 22:37:05 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation >> uses `MethodHandle`. For `Field` accessor, the new implementa

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v3]

2021-08-21 Thread Mandy Chung
On Sat, 21 Aug 2021 22:37:05 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation >> uses `MethodHandle`. For `Field` accessor, the new implementa

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v3]

2021-08-21 Thread Mandy Chung
> > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] > https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request incrementally with one additio

Re: RFR: 8264322: Generate CDS archive when creating custom JDK image [v2]

2021-08-19 Thread Mandy Chung
On Thu, 19 Aug 2021 23:59:32 GMT, Calvin Cheung wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/CDSPlugin.java >> line 121: >> >>> 119: @Override >>> 120: public ResourcePool transform(ResourcePool in, ResourcePoolBuilder >>> out) { >>> 121:

Re: RFR: 8264322: Generate CDS archive when creating custom JDK image [v2]

2021-08-19 Thread Mandy Chung
On Fri, 20 Aug 2021 00:09:01 GMT, Calvin Cheung wrote: >> Please review this change for adding a `jlink` command line option >> `--generate-cds-archive` for generating CDS archives as a post processing >> step during the creation of a custom JDK image. >> >> Details can be found in the

Re: RFR: 8264322: Generate CDS archive when creating custom JDK image [v2]

2021-08-19 Thread Mandy Chung
On Thu, 19 Aug 2021 23:56:00 GMT, Calvin Cheung wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java >> line 89: >> >>> 87: private final List args; >>> 88: private final Set modules; >>> 89: private Platform platform; >> >> Can

Re: RFR: 8264322: Generate CDS archive when creating custom JDK image

2021-08-18 Thread Mandy Chung
On Wed, 18 Aug 2021 21:21:06 GMT, Calvin Cheung wrote: > Please review this change for adding a `jlink` command line option > `--generate-cds-archive` for generating CDS archives as a post processing > step during the creation of a custom JDK image. > > Details can be found in the

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v2]

2021-08-09 Thread Mandy Chung
On Sat, 7 Aug 2021 02:07:24 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation >> uses `MethodHandle`. For `Field` accessor, the new implementa

Re: RFR: 8271862: C2 intrinsic for Reference.refersTo() is often not used

2021-08-09 Thread Mandy Chung
On Mon, 9 Aug 2021 19:58:48 GMT, Vladimir Ivanov wrote: >> While fixing JDK-8270626 it was discovered that the C2 intrinsic for >> `Reference.refersTo()` is not used as often as one would think. Instead C2 >> often prefers using the native implementation, which is much slower which >> defeats

Re: RFR: 8271862: C2 intrinsic for Reference.refersTo() is often not used

2021-08-09 Thread Mandy Chung
On Mon, 9 Aug 2021 13:13:33 GMT, Per Liden wrote: > While fixing JDK-8270626 it was discovered that the C2 intrinsic for > `Reference.refersTo()` is not used as often as one would think. Instead C2 > often prefers using the native implementation, which is much slower which > defeats the

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v2]

2021-08-07 Thread Mandy Chung
On Sat, 7 Aug 2021 02:07:24 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation >> uses `MethodHandle`. For `Field` accessor, the new implementa

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v2]

2021-08-06 Thread Mandy Chung
> > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] > https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request incrementally with one ad

RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle

2021-08-05 Thread Mandy Chung
This reimplements core reflection with method handles. For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`.For the first few invocations of one of these reflective methods on a

Re: RFR: 8271627: Use local field access in favor of Class.getClassLoader0

2021-08-02 Thread Mandy Chung
On Mon, 2 Aug 2021 18:27:00 GMT, Claes Redestad wrote: > Trivial startup hack/cleanup to use the `classLoader` field directly rather > than the `getClassLoader0` accessor. > > Before aa12c8fbf5b020d168cf29412643bf15514b0439 there was no `classLoader` > field and `getClassLoader0` was a

Re: RFR: 8270321: Startup regressions in 18-b5 caused by JDK-8266310

2021-07-26 Thread Mandy Chung
On Fri, 23 Jul 2021 18:03:31 GMT, Sergey Chernyshev wrote: > Dear colleagues, > > Please review the patch that replaces the lambdas with anonymous classes > which solves the startup time regression as shown below. > > I attached the Bytestacks flamegraphs for both original (regression) and

Re: RFR: 8270321: Startup regressions in 18-b5 caused by JDK-8266310

2021-07-26 Thread Mandy Chung
On Fri, 23 Jul 2021 18:03:31 GMT, Sergey Chernyshev wrote: > Dear colleagues, > > Please review the patch that replaces the lambdas with anonymous classes > which solves the startup time regression as shown below. > > I attached the Bytestacks flamegraphs for both original (regression) and

Re: [jdk17] RFR: 8270056: Generated lambda class can not access protected static method of target class

2021-07-13 Thread Mandy Chung
On Tue, 13 Jul 2021 03:06:12 GMT, Yi Yang wrote: > Hi all, > > this pull request contains a backport of commit 07e90524 from the openjdk/jdk > repository. > > The commit being backported was authored by Yi Yang on 13 Jul 2021 and was > reviewed by Mandy Chung.

Re: RFR: 8266936: Add a finalization JFR event

2021-07-12 Thread Mandy Chung
On Thu, 8 Jul 2021 19:47:26 GMT, Markus Grönlund wrote: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to > replace and mitigate Object.finalize() uses in the JDK libraries; please see > https://bugs.openjdk.java.net/browse/JDK-8253568 for more

Re: [jdk17] RFR: 8270025: DynamicCallSiteDesc::withArgs doesn't throw NPE [v3]

2021-07-12 Thread Mandy Chung
On Mon, 12 Jul 2021 18:02:54 GMT, Vicente Romero wrote: >> Please review this PR that is fixing a mismatch between the implementation >> for method `java.lang.constant.DynamicCallSiteDesc::withArgs` and its >> implementation. I made a mistake while working on a recent CSR >>

Re: RFR: 8270056: Generated lambda class can not access protected static method of target class [v3]

2021-07-12 Thread Mandy Chung
On Mon, 12 Jul 2021 02:57:26 GMT, Yi Yang wrote: >> Generated lambda class can not access protected static method of the target >> class. The following exception is thrown when executing the attached >> reproducible program: >> >> >> Exception in thread "main" java.lang.IllegalAccessError:

Re: [jdk17] RFR: 8270025: DynamicCallSiteDesc::withArgs doesn't throw NPE

2021-07-12 Thread Mandy Chung
On Sat, 10 Jul 2021 19:03:36 GMT, Vicente Romero wrote: > Please review this PR that is fixing a mismatch between the implementation > for method `java.lang.constant.DynamicCallSiteDesc::withArgs` and its > implementation. I made a mistake while working on a recent CSR >

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} for java.base [v11]

2021-07-12 Thread Mandy Chung
On Mon, 12 Jul 2021 05:21:34 GMT, Yi Yang wrote: > I'm not familiar with the review process of core-lib group. Is it sufficient > for merging with one approval? Should I have more reviews for this? 樂 It depends on the change. For this patch, it's good to get another reviewer to look through

Re: RFR: 8270056: Generated lambda class can not access protected static method of target class [v2]

2021-07-09 Thread Mandy Chung
On Fri, 9 Jul 2021 02:28:46 GMT, Yi Yang wrote: >> Generated lambda class can not access protected static method of the target >> class. The following exception is thrown when executing the attached >> reproducible program: >> >> >> Exception in thread "main" java.lang.IllegalAccessError:

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} for java.base [v11]

2021-07-08 Thread Mandy Chung
On Thu, 8 Jul 2021 03:12:24 GMT, Yi Yang wrote: >> After JDK-8265518(#3615), it's possible to replace all variants of >> checkIndex by >> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in >> the whole JDK codebase. > > Yi Yang has refreshed the contents of this pull

Re: RFR: 8270056: Generated lambda class can not access protected static method of target class

2021-07-08 Thread Mandy Chung
On Thu, 8 Jul 2021 02:32:45 GMT, Yi Yang wrote: > Generated lambda class can not access protected static method of the target > class. The following exception is thrown when executing the attached > reproducible program: > > > Exception in thread "main" java.lang.IllegalAccessError: class >

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible [v8]

2021-07-07 Thread Mandy Chung
On Wed, 7 Jul 2021 16:22:25 GMT, Mandy Chung wrote: >> Hi Mandy, thanks for reviewing this. >> >>> I suggest to separate the client changes (both src and test) in a separate >>> PR for the client review. >> >> Does "client changes" means

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible [v8]

2021-07-07 Thread Mandy Chung
On Wed, 7 Jul 2021 02:10:10 GMT, Yi Yang wrote: > Does "client changes" means changes involving src/java.desktop and > test/java/awt? src/java.desktop, test/java/awt, and test/javax/imageio - PR: https://git.openjdk.java.net/jdk/pull/4507

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible [v8]

2021-07-06 Thread Mandy Chung
On Wed, 23 Jun 2021 03:54:55 GMT, Yi Yang wrote: >> After JDK-8265518(#3615), it's possible to replace all variants of >> checkIndex by >> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in >> the whole JDK codebase. > > Yi Yang has updated the pull request

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible

2021-07-06 Thread Mandy Chung
On Mon, 5 Jul 2021 06:29:58 GMT, David Holmes wrote: >> @dholmes-ora @AlanBateman @PaulSandoz do you have any comments on the latest >> version? Thanks. > > @kelthuzadx I did not see any response to my query about the change in > initialization (not load) order. I also remain concerned about

[jdk17] Integrated: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing

2021-07-06 Thread Mandy Chung
On Wed, 30 Jun 2021 18:24:24 GMT, Mandy Chung wrote: > This spec clarification is a follow-up to > [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320) > w.r.t.

Re: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing [v2]

2021-07-02 Thread Mandy Chung
On Fri, 2 Jul 2021 08:58:35 GMT, Peter Levart wrote: >> Well, "determine" seems to have both meanings: >> https://www.google.com/search?q=determine >> So by the 2nd meaning, it is good. > > ... and considering the "Schrödinger's cat", even the 1st interpretation is > correct. You can't know

Re: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing [v2]

2021-06-30 Thread Mandy Chung
gs.openjdk.java.net/browse/JDK-8269690 Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Kim's suggestion on the wording - Changes: - all: https://git.openjdk.java.net/jdk17/pull/183/files - new: https://git.openjdk

Re: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing [v2]

2021-06-30 Thread Mandy Chung
On Wed, 30 Jun 2021 21:29:17 GMT, Kim Barrett wrote: >> Mandy Chung has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Kim's suggestion on the wording > > src/java.base/share/classes/java/lang/Ru

[jdk17] Integrated: JDK-8262841: Clarify the behavior of PhantomReference::refersTo

2021-06-30 Thread Mandy Chung
On Wed, 30 Jun 2021 16:49:44 GMT, Mandy Chung wrote: > `Reference::refersTo` behaves the same for soft, weak, and phantom references > whereas `PhantomReference::get` always returns `null` which is different than > soft and weak references. > > This patch clarifies th

[jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing

2021-06-30 Thread Mandy Chung
This spec clarification is a follow-up to [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320) w.r.t. reference processing. Since there is no guarantee for any memory

[jdk17] RFR: JDK-8262841: Clarify the behavior of PhantomReference::refersTo

2021-06-30 Thread Mandy Chung
`Reference::refersTo` behaves the same for soft, weak, and phantom references whereas `PhantomReference::get` always returns `null` which is different than soft and weak references. This patch clarifies the specification of `PhantomReference` to make it clear that `refersTo` can be used for

[jdk17] Integrated: JDK-8269426: Rename test/jdk/java/lang/invoke/t8150782 to accessClassAndFindClass

2021-06-28 Thread Mandy Chung
On Mon, 28 Jun 2021 16:09:36 GMT, Mandy Chung wrote: > `test/jdk/java/lang/invoke/t8150782` is the only one using that convention. > There are several tests under `` directory. As the tests under > `test/jdk/java/lang/invoke/t8150782` are mostly unit tests for > `Lookup:

Re: [jdk17] RFR: JDK-8269426: Rename test/jdk/java/lang/invoke/t8150782 to accessClassAndFindClass

2021-06-28 Thread Mandy Chung
On Mon, 28 Jun 2021 16:09:36 GMT, Mandy Chung wrote: > `test/jdk/java/lang/invoke/t8150782` is the only one using that convention. > There are several tests under `` directory. As the tests under > `test/jdk/java/lang/invoke/t8150782` are mostly unit tests for > `Lookup:

Re: [jdk17] RFR: JDK-8269426: Rename test/jdk/java/lang/invoke/t8150782 to accessClassAndFindClass [v2]

2021-06-28 Thread Mandy Chung
ply be moved to > the parent directory. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Keep the tests under a directory - Changes: - all: https://git.openjdk.java.net/jdk17/pull/162/files - new: https://git.openjdk.java.net

Re: [jdk17] RFR: JDK-8269426: Move tests from test/jdk/java/lang/invoke/t8150782 to its parent directory

2021-06-28 Thread Mandy Chung
On Mon, 28 Jun 2021 16:09:36 GMT, Mandy Chung wrote: > `test/jdk/java/lang/invoke/t8150782` is the only one using that convention. > There are several tests under `` directory. As the tests under > `test/jdk/java/lang/invoke/t8150782` are mostly unit tests for > `Lookup:

Re: [jdk17] RFR: 8269486: CallerAccessTest fails for non server variant [v2]

2021-06-28 Thread Mandy Chung
On Mon, 28 Jun 2021 14:52:41 GMT, Christoph Göttschkes wrote: >> Hi, >> >> please review this small fix. The test case uses a custom launcher and >> before launching the JVM, it adds the "lib" and "lib/server" directories to >> the environment variable which controls the native library search

[jdk17] RFR: JDK-8269426: Move tests from test/jdk/java/lang/invoke/t8150782 to its parent directory

2021-06-28 Thread Mandy Chung
`test/jdk/java/lang/invoke/t8150782` is the only one using that convention. There are several tests under `` directory. As the tests under `test/jdk/java/lang/invoke/t8150782` are mostly unit tests for `Lookup::accessClass` and `Lookup::findClass`, they can simply be moved to the parent

[jdk17] Integrated: JDK-8266269: Lookup::accessClass fails with IAE when accessing an arrayClass with a protected inner class as component class

2021-06-26 Thread Mandy Chung
On Thu, 24 Jun 2021 18:42:23 GMT, Mandy Chung wrote: > `Lookup::accessClass` should determine the accessibility of the element type. > An array class is accessible if and only if its element type is accessible. > > This also fixes a spec bug to document `@throws NullPoin

Re: [jdk17] RFR: JDK-8266269: Lookup::accessClass fails with IAE when accessing an arrayClass with a protected inner class as component class [v2]

2021-06-26 Thread Mandy Chung
On Fri, 25 Jun 2021 18:46:30 GMT, Mandy Chung wrote: >> `Lookup::accessClass` should determine the accessibility of the element >> type. An array class is accessible if and only if its element type is >> accessible. >> >> This also fixes a spec bug to document

[jdk17] Integrated: JDK-8269351: Proxy::newProxyInstance and MethodHandleProxies::asInterfaceInstance should reject sealed interfaces

2021-06-26 Thread Mandy Chung
On Fri, 25 Jun 2021 17:24:58 GMT, Mandy Chung wrote: > `java.lang.reflect.Proxy::newProxyInstance` and > `java.lang.invoke.MethodHandleProxies::asInterfaceInstance` do not specify > how to deal with sealed interfaces. These APIs should reject sealed &g

Re: [jdk17] RFR: JDK-8266269: Lookup::accessClass fails with IAE when accessing an arrayClass with a protected inner class as component class [v2]

2021-06-25 Thread Mandy Chung
Please review the CSR: > https://bugs.openjdk.java.net/browse/JDK-8269312 Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: remove extra import - Changes: - all: https://git.openjdk.java.net/jdk17/pull/

[jdk17] RFR: JDK-8269351: Proxy::newProxyInstance and MethodHandleProxies::asInterfaceInstance should reject sealed interfaces

2021-06-25 Thread Mandy Chung
`java.lang.reflect.Proxy::newProxyInstance` and `java.lang.invoke.MethodHandleProxies::asInterfaceInstance` do not specify how to deal with sealed interfaces. These APIs should reject sealed interface with `IllegalArgumentException` which is thrown if the given interface is invalid. Please

Re: [jdk17] RFR: JDK-8266269: Lookup::accessClass fails with IAE when accessing an arrayClass with a protected inner class as component class

2021-06-25 Thread Mandy Chung
On Fri, 25 Jun 2021 08:44:54 GMT, Chris Hegarty wrote: >> `Lookup::accessClass` should determine the accessibility of the element >> type. An array class is accessible if and only if its element type is >> accessible. >> >> This also fixes a spec bug to document `@throws

Re: [jdk17] RFR: JDK-8266310: deadlock between System.loadLibrary and JNI FindClass loading another class

2021-06-24 Thread Mandy Chung
On Fri, 18 Jun 2021 09:50:49 GMT, Aleksei Voitylov wrote: > Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976 > against JDK17. > > This fixes the deadlock in ClassLoader between the two lock objects - a lock > object associated with the class being loaded, and the >

[jdk17] RFR: JDK-8266269: Lookup::accessClass fails with IAE when accessing an arrayClass with a protected inner class as component class

2021-06-24 Thread Mandy Chung
`Lookup::accessClass` should determine the accessibility of the element type. An array class is accessible if and only if its element type is accessible. This also fixes a spec bug to document `@throws NullPointerException` if the argument is null. Please review the CSR:

Re: [jdk17] RFR: 8269096: Add java.util.Objects.newIdentity method [v3]

2021-06-22 Thread Mandy Chung
On Tue, 22 Jun 2021 16:18:11 GMT, Roger Riggs wrote: >> Add java.util.Objects.newIdentity to supply a unique object with identity. >> This is a replacement code can be used today for the traditional new >> Object() idiom, which will be deprecated under Project Valhalla. >> Refer to [JEP 401:

Re: [jdk17] RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling [v2]

2021-06-21 Thread Mandy Chung
On Fri, 11 Jun 2021 18:17:10 GMT, Vicente Romero wrote: >> This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416) >> which was intended to openjdk/jdk. >> >> Please review this PR which is syncing the implementation of >> `DirectMethodHandleDesc.Kind.valueOf(int)` and >>

Re: [jdk17] RFR: 8269096: Add java.util.Objects.newIdentity method

2021-06-21 Thread Mandy Chung
On Mon, 21 Jun 2021 22:25:49 GMT, Roger Riggs wrote: > Add java.util.Objects.newIdentity to supply a unique object with identity. > This is a replacement code can be used today for the traditional new Object() > idiom, which will be deprecated under Project Valhalla. > Refer to [JEP 401:

Re: [jdk17] RFR: JDK-8266310: deadlock between System.loadLibrary and JNI FindClass loading another class

2021-06-21 Thread Mandy Chung
On Fri, 18 Jun 2021 09:50:49 GMT, Aleksei Voitylov wrote: > Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976 > against JDK17. > > This fixes the deadlock in ClassLoader between the two lock objects - a lock > object associated with the class being loaded, and the >

<    1   2   3   4   5   6   7   8   9   10   >