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
> Clas
On Thu, 17 Jun 2021 18:15:52 GMT, Aleksei Voitylov
wrote:
> Thanks Mandy for the thorough review, I'll definitely do that. Shall we wait
> for Alan opinion as well?
I think you can proceed posting a PR for jdk17 as the new version has addressed
Alan's concern of using ThreadLocal. Alan can r
On Wed, 16 Jun 2021 07:51:32 GMT, Aleksei Voitylov
wrote:
>> Please review this PR which fixes the deadlock in ClassLoader between the
>> two lock objects - a lock object associated with the class being loaded, and
>> the ClassLoader.loadedLibraryNames hash map, locked during the native
>> li
On Thu, 17 Jun 2021 18:12:19 GMT, Aleksei Voitylov
wrote:
>> test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java
>> line 95:
>>
>>> 93: Collections.addAll(args, "cvf", Paths.get(testClassPath,
>>> outputJar).toString());
>>> 94: for (String c : clas
On Wed, 16 Jun 2021 07:51:32 GMT, Aleksei Voitylov
wrote:
>> Please review this PR which fixes the deadlock in ClassLoader between the
>> two lock objects - a lock object associated with the class being loaded, and
>> the ClassLoader.loadedLibraryNames hash map, locked during the native
>> li
On Wed, 16 Jun 2021 07:51:32 GMT, Aleksei Voitylov
wrote:
>> Please review this PR which fixes the deadlock in ClassLoader between the
>> two lock objects - a lock object associated with the class being loaded, and
>> the ClassLoader.loadedLibraryNames hash map, locked during the native
>> li
On Fri, 11 Jun 2021 10:00:14 GMT, Aleksei Voitylov
wrote:
>> test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java
>> line 84:
>>
>>> 82:
>>> 83: private static OutputAnalyzer createJar(String outputJar, String...
>>> classes) throws Throwable {
>>> 84:
On Fri, 11 Jun 2021 10:03:44 GMT, Aleksei Voitylov
wrote:
>> Please review this PR which fixes the deadlock in ClassLoader between the
>> two lock objects - a lock object associated with the class being loaded, and
>> the ClassLoader.loadedLibraryNames hash map, locked during the native
>> li
On Thu, 10 Jun 2021 23:23:23 GMT, Vicente Romero wrote:
>> test/jdk/java/lang/constant/MethodHandleDescTest.java line 362:
>>
>>> 360: public void testKind() {
>>> 361: for (Kind k : Kind.values()) {
>>> 362: assertEquals(Kind.valueOf(k.refKind),
>>> Kind.valueOf(k.refKi
On Thu, 10 Jun 2021 23:26:21 GMT, Vicente Romero wrote:
>> Please review this PR which is just syncing the implementation of
>> DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the
>> method's spec is that if the value of the `refKind` parameter is:
>> MethodHandleInfo.REF
On Tue, 8 Jun 2021 15:30:33 GMT, Dan Smith wrote:
>> Small bug fix.
>
> Dan Smith has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Clean up validation of implKind REF_invokeSpecial
Looks good to me.
-
Marked as reviewed by mch
On Wed, 9 Jun 2021 10:25:35 GMT, Patrick Concannon
wrote:
>> Hi,
>>
>> Could someone please review my code for updating the code in the `java.lang`
>> packages to make use of the switch expressions?
>>
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementall
On Tue, 8 Jun 2021 16:46:36 GMT, Vicente Romero wrote:
> Please review this PR which is just syncing the implementation of
> DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the
> method's spec is that if the value of the `refKind` parameter is:
> MethodHandleInfo.REF_invo
On Sat, 5 Jun 2021 00:15:25 GMT, Dan Smith wrote:
>> Standardizes and better specifies the errors thrown by LambdaMetafactory,
>> including for inputs that would not be generated by javac.
>>
>> Does some renaming of core parameters/fields to better reflect their purpose.
>>
>> In the implemen
On Fri, 4 Jun 2021 23:41:06 GMT, Dan Smith wrote:
>> src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java line 312:
>>
>>> 310: * @return a CallSite whose target can be used to perform capture,
>>> generating
>>> 311: * instances of the interface named by {@code
On Fri, 4 Jun 2021 22:04:19 GMT, Dan Smith wrote:
>> Standardizes and better specifies the errors thrown by LambdaMetafactory,
>> including for inputs that would not be generated by javac.
>>
>> Does some renaming of core parameters/fields to better reflect their purpose.
>>
>> In the implemen
I'm not sure if the spec should be updated. JDK-8267222 needs the GC
team to evaluate.
I have added my comment in this JBS issue.
The SoftReference spec has the guarantee:
“All soft references to softly-reachable objects are guaranteed to
have been cleared before the virtual machine throws
On Fri, 4 Jun 2021 09:46:31 GMT, Jan Lahoda wrote:
>> This is a preview of a patch implementing JEP 406: Pattern Matching for
>> switch (Preview):
>> https://bugs.openjdk.java.net/browse/JDK-8213076
>>
>> The current draft of the specification is here:
>> http://cr.openjdk.java.net/~gbierman/je
On Thu, 3 Jun 2021 20:40:23 GMT, Dan Smith wrote:
>> Standardizes and better specifies the errors thrown by LambdaMetafactory,
>> including for inputs that would not be generated by javac.
>>
>> Does some renaming of core parameters/fields to better reflect their purpose.
>>
>> In the implemen
On Thu, 3 Jun 2021 20:40:23 GMT, Dan Smith wrote:
>> Standardizes and better specifies the errors thrown by LambdaMetafactory,
>> including for inputs that would not be generated by javac.
>>
>> Does some renaming of core parameters/fields to better reflect their purpose.
>>
>> In the implemen
On Thu, 3 Jun 2021 18:21:31 GMT, Mandy Chung wrote:
> Trivial javadoc change to add a reference to JVMS 4.1 in
> `Lookup::defineHiddenClass` such that the reference like `this_class` would
> be referred to JVMS for details.
This pull request has now been integrated.
Changeset:
Trivial javadoc change to add a reference to JVMS 4.1 in
`Lookup::defineHiddenClass` such that the reference like `this_class` would be
referred to JVMS for details.
-
Commit messages:
- 8267995: Add reference to JVMS class file format in Lookup::defineHiddenClass
Changes: https:/
On Thu, 3 Jun 2021 11:01:02 GMT, Patrick Concannon
wrote:
>> Hi,
>>
>> Could someone please review my code for updating the code in the `java.lang`
>> packages to make use of the switch expressions?
>>
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementall
On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote:
> Please review the change to update to using jtreg 6.
>
> The primary change is to the jib-profiles.js file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the `requiredVersion`
On Thu, 27 May 2021 14:31:59 GMT, Aleksei Voitylov
wrote:
>> Please review this PR which fixes the deadlock in ClassLoader between the
>> two lock objects - a lock object associated with the class being loaded, and
>> the ClassLoader.loadedLibraryNames hash map, locked during the native
>> li
On Mon, 31 May 2021 07:36:10 GMT, Сергей Цыпанов
wrote:
> This a tiny follop-up of https://github.com/openjdk/jdk/pull/3571.
>
> The loop in `sun.reflect.misc.ReflectUtil.privateCheckPackageAccess()` is
> redundant since `Class.getPackageName()` will already return the package name
> of the i
On Fri, 21 May 2021 15:49:09 GMT, Aleksei Voitylov
wrote:
>> Please review this PR which fixes the deadlock in ClassLoader between the
>> two lock objects - a lock object associated with the class being loaded, and
>> the ClassLoader.loadedLibraryNames hash map, locked during the native
>> li
On Mon, 24 May 2021 22:49:05 GMT, Claes Redestad wrote:
>> Slightly reduce VarHandle startup overhead by introducing package-private
>> COUNT constants for two enums
>
> Claes Redestad has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Mandy
On Mon, 24 May 2021 11:47:53 GMT, Claes Redestad wrote:
> Extract some common behavior checks from the generated VarHandleGuards code
> to a package-private VarHandle method. This reduces the code size (-5.2kb
> lib/modules) and slightly improves startup, while being performance neutral
> on m
On Mon, 24 May 2021 11:26:51 GMT, Claes Redestad wrote:
> Slightly reduce VarHandle startup overhead by introducing package-private
> COUNT constants for two enums
src/java.base/share/classes/java/lang/invoke/VarHandle.java line 1639:
> 1637: GET_AND_UPDATE(Object.class);
> 1638:
> 16
On Fri, 21 May 2021 08:53:51 GMT, Gavin Bierman wrote:
>> Hi all,
>>
>> Please review this patch to make the ConstantDesc hierarchy `sealed`, as was
>> promised in its Javadoc, now that sealed classes are finalising in JDK 17.
>>
>> Thanks,
>> Gavin
>
> Gavin Bierman has updated the pull requ
On Thu, 20 May 2021 22:35:38 GMT, Thiago Henrique Hüpner
wrote:
>> I should have made it clear. I was expecting `DynamicConstantDesc` should
>> be `sealed`. Do you expect non-JDK implementation class extending
>> `DynamicConstantDesc`?
>
> From the ConstantDesc Javadoc:
>
> * Non-platform
On Thu, 20 May 2021 22:17:03 GMT, Gavin Bierman wrote:
>> src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java line
>> 59:
>>
>>> 57: * @since 12
>>> 58: */
>>> 59: non-sealed public abstract class DynamicConstantDesc
>>
>> can you explain why `DynamicConstantDesc` is non-
On Thu, 20 May 2021 21:32:05 GMT, Gavin Bierman wrote:
>> Hi all,
>>
>> Please review this patch to make the ConstantDesc hierarchy `sealed`, as was
>> promised in its Javadoc, now that sealed classes are finalising in JDK 17.
>>
>> Thanks,
>> Gavin
>
> Gavin Bierman has updated the pull requ
This seems a good improvement. I created
https://bugs.openjdk.java.net/browse/JDK-8267509 for this issue.
How did you run into this illegal varargs method? Is that class file
generated at runtime?
Mandy
On 5/20/21 10:18 AM, x4e_x4e wrote:
Hello,
If a MethodHandles.Lookup is used to locat
On Wed, 19 May 2021 17:57:11 GMT, Erik Gahlin wrote:
> > I was also thinking if this event should be implemented in the VM in order
> > to avoid some performance overhead such as object allocation. Erik, what is
> > the benefit of implementing in in the VM?
>
> No startup cost, no allocation a
On Wed, 19 May 2021 09:00:27 GMT, Alan Bateman wrote:
> I wonder if there needs to be one event per finalized object?
I also concern with the performance overhead of one event per finalized object.
The primary goal of this JFR event is to help identifying the use of finalizers
in existing libr
On Tue, 18 May 2021 23:01:05 GMT, Mark Reinhold wrote:
>> Please review this implementation of JEP 403
>> (https://openjdk.java.net/jeps/403).
>> Alan Bateman is the original author of almost all of it. Passes tiers 1-3
>> on
>> {linux,macos,windows}-x64 and {linux,macos}-aarch64.
>
> Mark Re
On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote:
> Please review this implementation of [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> The code change is divided into 3 commits. Please review them one by one.
>
> 1.
> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28
On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote:
> Please review the test changes for [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> With JEP 411 and the default value of `-Djava.security.manager` becoming
> `disallow`, tests calling `System.setSecurityManager()` need
> `-Djava.secu
On Thu, 13 May 2021 23:07:07 GMT, Mark Reinhold wrote:
>> Please review this implementation of JEP 403
>> (https://openjdk.java.net/jeps/403).
>> Alan Bateman is the original author of almost all of it. Passes tiers 1-3
>> on
>> {linux,macos,windows}-x64 and {linux,macos}-aarch64.
>
> Mark Re
On 5/13/21 6:05 AM, David Holmes wrote:
Not every problem has a solution :) If JNI_OnLoad has to execute
atomically with respect to loading a library then there will always be
a deadlock potential. The only complete solution would not hold a lock
while JNI_OnLoad is executed, but that comple
On Thu, 13 May 2021 20:38:20 GMT, Lance Andersen wrote:
>> HI all,
>>
>> Please review the fix to HashesTest.java to support running on TestNG 7.4.
>>
>> The fix adds a no-arg constructor which TestNG requires.
>>
>> The change allows the test to run with the current jtreg as well as the
>>
checking. I thought I remembered something like this
somewhere, but it may be that you already fixed such tests when you
did hidden classes? In any case, seems like we're all good now.
Cheers,
-Brian
On 5/13/2021 2:50 PM, Mandy Chung wrote:
I did a search on java.base and the tests on `S
On Thu, 13 May 2021 18:37:21 GMT, Lance Andersen wrote:
>> HI all,
>>
>> Please review the fix to HashesTest.java to support running on TestNG 7.4.
>>
>> The fix adds a no-arg constructor which TestNG requires.
>>
>> The change allows the test to run with the current jtreg as well as the
>>
I did a search on java.base and the tests on `String::indexOf` and
`String::contains` of a slash and don't spot any such test. The JDK has
no use of VM anonymous class. If the test is trying to determine if
it's lambda proxy class, it should be converted to call
`Class::isHidden` but testing
On Thu, 13 May 2021 18:11:30 GMT, Mark Reinhold wrote:
>> Please review this implementation of JEP 403
>> (https://openjdk.java.net/jeps/403).
>> Alan Bateman is the original author of almost all of it. Passes tiers 1-3
>> on
>> {linux,macos,windows}-x64 and {linux,macos}-aarch64.
>
> Mark Re
On Thu, 13 May 2021 10:49:21 GMT, Lance Andersen wrote:
> HI all,
>
> Please review the fix to HashesTest.java to support running on TestNG 7.4.
>
> The fix adds a no-arg constructor which TestNG requires.
>
> The change allows the test to run with the current jtreg as well as the
> upcomin
On Wed, 12 May 2021 16:10:24 GMT, Harold Seigel wrote:
>> Please review this large change to remove Unsafe::defineAnonymousClass().
>> The change removes dAC relevant code and changes a lot of tests. Many of
>> the changed tests need renaming. I hope to do this in a follow up RFE.
>> Some
On Wed, 12 May 2021 20:59:51 GMT, Ioi Lam wrote:
>> src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java line 60:
>>
>>> 58: // Sets the ServicesCatalog for the specified loader using archived
>>> objects.
>>> 59: private static void setArchivedServicesCatalog(
>>> 60:
On Wed, 12 May 2021 15:48:16 GMT, Daniel Fuchs wrote:
> ParentLoggersTest.java has been (rarely) seen failing with "checkLoggers:
> getLoggerNames() returned unexpected loggers"
> The suspicion is that there might be some possible interaction with other
> tests running in the same VM. This test
On Wed, 12 May 2021 05:51:14 GMT, Ioi Lam wrote:
> This bug was discovered during the development of
> [JDK-6824466](https://bugs.openjdk.java.net/browse/JDK-6824466): when CDS is
> enabled, if `BootLoader::loadClassOrNull` is called before `initPhase2`, it
> would trigger the initialization o
On Tue, 11 May 2021 14:13:49 GMT, Harold Seigel wrote:
>> Please review this large change to remove Unsafe::defineAnonymousClass().
>> The change removes dAC relevant code and changes a lot of tests. Many of
>> the changed tests need renaming. I hope to do this in a follow up RFE.
>> Some
On Tue, 11 May 2021 17:38:36 GMT, Mandy Chung wrote:
> Add a test to verify that hidden class's members are not statically invocable
> based on
> test/jdk/java/lang/invoke/VMAnonymousClass.java.
This pull request has now been integrated.
Changeset: cc03734b
Author: Ma
, unit the internal
version of ASM is refreshed so the constant V17 can be used.
Agree. I will fix that.
Mandy
Rémi
- Mail original -----
De: "mandy chung"
À: "core-libs-dev" , "hotspot compiler"
Envoyé: Mardi 11 Mai 2021 22:42:01
Objet: Draft JEP: Reimp
, great point. I will add that.
Mandy
On 5/11/2021 4:42 PM, Mandy Chung wrote:
This draft JEP is a proposal to reimplement core reflection on top of
method handles:
https://bugs.openjdk.java.net/browse/JDK-8266010
Feedback is welcome. The prototype is at [1].
Mandy
[1] https://github.com
On Tue, 11 May 2021 14:13:49 GMT, Harold Seigel wrote:
>> Please review this large change to remove Unsafe::defineAnonymousClass().
>> The change removes dAC relevant code and changes a lot of tests. Many of
>> the changed tests need renaming. I hope to do this in a follow up RFE.
>> Some
This draft JEP is a proposal to reimplement core reflection on top of
method handles:
https://bugs.openjdk.java.net/browse/JDK-8266010
Feedback is welcome. The prototype is at [1].
Mandy
[1] https://github.com/mlchung/jdk/tree/reimplement-method-invoke
e/Context.java*L329__;Iw!!GqivPVa7Brio!LQB5qhHavp8DtWhCLdw4CJAYuNYZhhEGY65H9uA3sx_xqMOriXmvlH9VQibTLkCtHQ$>
[1]
https://mail.openjdk.java.net/pipermail/nashorn-dev/2020-October/007578.html
<https://mail.openjdk.java.net/pipermail/nashorn-dev/2020-October/007578.html>
On Tue, May 11, 2021 at 1:03 AM Man
On Tue, 11 May 2021 16:48:28 GMT, Mandy Chung wrote:
> Data provider with varargs does not work on TestNG 7.4.0. Fix the test to
> create an object array instead of varargs to workaround this issue.
This pull request has now been integrated.
Changeset: dfe8833f
Author: Mandy Chun
Add a test to verify that hidden class's members are not statically invocable
based on
test/jdk/java/lang/invoke/VMAnonymousClass.java.
-
Commit messages:
- 8266925: Add a test to verify that hidden class's members are not statically
invocable
Changes: https://git.openjdk.java.net
On Tue, 11 May 2021 16:48:28 GMT, Mandy Chung wrote:
> Data provider with varargs does not work on TestNG 7.4.0. Fix the test to
> create an object array instead of varargs to workaround this issue.
Yes, fixing these is indeed looking more comfortable 😄
-
PR:
Data provider with varargs does not work on TestNG 7.4.0. Fix the test to
create an object array instead of varargs to workaround this issue.
-
Commit messages:
- 8266783: java\lang\reflect\Proxy\DefaultMethods.java fails with jtreg 6
Changes: https://git.openjdk.java.net/jdk/pul
Thank you all.
Mandy
On 5/10/21 2:27 PM, Paul Sandoz wrote:
Looks good, I took the liberty of making some minor edits, mostly fixing some
typos.
Paul.
On May 10, 2021, at 12:26 PM, Mandy Chung wrote:
Hidden classes were added in Java SE 15. Class data support was added in 16
Hidden classes were added in Java SE 15. Class data support was added in
16. `sun.misc.Unsafe::defineAnonymousClass` was deprecated in JDK 15 and
deprecated for terminally removal in JDK 16.
I propose to remove `sun.misc.Unsafe::defineAnonymousClass` from JDK 17:
CSR: https://bugs.openjdk.java.
On Mon, 10 May 2021 18:15:01 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-412 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] - https://openjd
On Fri, 30 Apr 2021 22:39:46 GMT, Mandy Chung wrote:
> Replace the use of reflection with a direct method call to a
> platform-specific implementation class where `SystemMetrics::instance`
> returns `CgroupMetrics.getInstance()` on linux and returns null on other
> platforms
Replace the use of reflection with a direct method call to a platform-specific
implementation class where `SystemMetrics::instance` returns
`CgroupMetrics.getInstance()` on linux and returns null on other platforms.
-
Commit messages:
- fix whitespace
- JDK-8266391: Replace use of
On Fri, 30 Apr 2021 12:24:38 GMT, Maurizio Cimadamore
wrote:
> I've added `@CS` in the interface methods too. I've also added a stronger
> test which creates method handles in one module (which doesn't have native
> access) and then calls them from another module (which does NOT have native
>
On Thu, 29 Apr 2021 10:31:29 GMT, Maurizio Cimadamore
wrote:
> I think I expect that, with caller sensitive, it is possible from a client in
> an "enabled" module to obtain a MethodHandle, and then pass it to an
> unprivileged module, which then calls it, and works ok. This matches my
> expec
On Wed, 28 Apr 2021 21:10:33 GMT, Maurizio Cimadamore
wrote:
> I just did a test:
>
> ```
> public class TestLookup {
> public static void main(String[] args) throws Throwable {
> MethodHandle handle =
> MethodHandles.lookup().findVirtual(CLinker.class, "downcallHandle",
> MethodT
On Wed, 28 Apr 2021 20:38:47 GMT, Maurizio Cimadamore
wrote:
> To be clear - by aliasing you mean when the @CallerSensitive implementation
> is called with invokeinterface - so, e.g. doing
> `MethodHandles.lookup().findVirtual(CLinker.class, ...)` right?
Yes. The caller would be java.base i
On Wed, 28 Apr 2021 18:26:30 GMT, Maurizio Cimadamore
wrote:
> test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java
Yes that's the test. That test misses to catch your case where aliasing may be
possible.
-
PR: https://git.openjdk.java.net/jdk/pull/3699
On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-412 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] - https://openjd
On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-412 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] - https://openjd
On Wed, 28 Apr 2021 01:11:38 GMT, Mandy Chung wrote:
> jdeps should print "JDK removed internal APIs" to give an informative
> description when a JDK internal API that is being referenced has been
> removed. JDK-8213909 incorrectly changed it to print `jdk8internals`.
>
jdeps should print "JDK removed internal APIs" to give an informative
description when a JDK internal API that is being referenced has been removed.
JDK-8213909 incorrectly changed it to print `jdk8internals`.
An example output is:
classes -> jdk8internals
p.Main
On Tue, 27 Apr 2021 00:20:49 GMT, Ian Graves wrote:
> 8260560: convert jdeps and jdeprscan tools to use Stream.toList()
Marked as reviewed by mchung (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/3705
Hi Aleksei,
Looks like is a bug. "JDK removed internal API" is the intended
description as it indicates that a non-existent API is referenced.
I created https://bugs.openjdk.java.net/browse/JDK-8265773 to fix this.
thanks
Mandy
On 4/22/21 4:21 AM, Aleksei Voitylov wrote:
Hi,
JDK-8213909 [
On Wed, 14 Apr 2021 11:38:15 GMT, Jorn Vernee wrote:
>> This patch implements 2 leftover TODOs for implementing var handle invoker
>> MH caching (lambda forms for those were already shared/cached).
>>
>> This piggybacks on the existing mechanism for method handle invoker caching.
>>
>> Testing
On Wed, 14 Apr 2021 21:26:52 GMT, Claes Redestad wrote:
>> This patch reduces work done initializing VarForms - mostly observed when
>> loading each VarHandle implementation class.
>>
>> - Lazily resolve MemberNames.
>> - Streamline MethodType creation. This reduces the number of MethodTypes
>
On Wed, 14 Apr 2021 11:35:14 GMT, Claes Redestad wrote:
>> This patch reduces work done initializing VarForms - mostly observed when
>> loading each VarHandle implementation class.
>>
>> - Lazily resolve MemberNames.
>> - Streamline MethodType creation. This reduces the number of MethodTypes
>
On Tue, 13 Apr 2021 18:11:37 GMT, Claes Redestad wrote:
> This patch reduces work done initializing VarForms - mostly observed when
> loading each VarHandle implementation class.
>
> - Lazily resolve MemberNames.
> - Streamline MethodType creation. This reduces the number of MethodTypes
> crea
On Mon, 12 Apr 2021 10:45:20 GMT, Claes Redestad wrote:
> Desugaring the single-case switch in MethodHandleNatives::canBeCalledVirtual
> is a cleanup and minimal startup improvement on apps spinning up
> MethodHandles.
Marked as reviewed by mchung (Reviewer).
-
PR: https://git.op
On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote:
>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related
>> to Ahead-of-Time Compiler from JDK:
>>
>> - `jdk.aot` module — the `jaotc` tool
>> - `src/hotspot/share/aot` — loads AoT compiled code into VM for execution
On Tue, 23 Mar 2021 01:03:55 GMT, Kim Barrett wrote:
>> Please review this change to java.util.Timer, replacing the use of
>> deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
>>
>> In addition, Timer.cancel now cancels any later execution of the the no
>> longer relevan
On Mon, 22 Mar 2021 17:47:10 GMT, Patrick Concannon
wrote:
>> Hi,
>>
>> Could someone please review my code for updating the code in the `java.lang`
>> package to make use of the `instanceof` pattern variable?
>>
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request w
On Thu, 18 Mar 2021 22:56:53 GMT, Claes Redestad wrote:
>> I don't object this dead code elimination. I don't know the design/thought
>> when these unused canonicalization codes were defined.
>
> This code appear to have been initially introduced with the JDK 7
> implementation of JSR 292, whi
On Thu, 18 Mar 2021 15:42:49 GMT, Claes Redestad wrote:
> MethodTypeForm.INTS, LONGS and RAW_RETURN are effectively unused. This
> removes these canonicalization codes and cleans up related code.
I don't object this dead code elimination. I don't know the design/thought
when these unused cano
On Wed, 17 Mar 2021 18:15:37 GMT, Mandy Chung wrote:
>> Other methods that delegate to `makeImpl` aren't doing up-front validation,
>> so this change was made to get things more in line. It might be good to
>> spell out that `makeImpl` does these checks for all its ca
On Wed, 17 Mar 2021 19:12:10 GMT, Claes Redestad wrote:
>> - Remove unused code
>> - Inline and simplify the bootstrap method invocation code (remove pointless
>> reboxing checks etc)
>> - Apply pattern matching to make some code more readable
>
> Claes Redestad has updated the pull request incr
On Wed, 17 Mar 2021 17:57:08 GMT, Claes Redestad wrote:
>> - Remove unused code
>> - Inline and simplify the bootstrap method invocation code (remove pointless
>> reboxing checks etc)
>> - Apply pattern matching to make some code more readable
>
> Claes Redestad has updated the pull request incr
On Wed, 17 Mar 2021 18:02:07 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodType.java line 418:
>>
>>> 416: public MethodType changeParameterType(int num, Class nptype) {
>>> 417: if (parameterType(num) == nptype) return this;
>>> 418: check
On Tue, 16 Mar 2021 22:24:55 GMT, Joe Darcy wrote:
> java.lang.Class has a number of methods to return some kind of textual token
> associated with the class, including a type name, canonical name, simple
> name, and separately the results of toString().
>
> Bug 8254979 notes that getSimpleNam
On Tue, 16 Mar 2021 11:13:50 GMT, Daniel Fuchs wrote:
>> src/java.base/share/classes/java/lang/StackTraceElement.java line 413:
>>
>>> 411: && Objects.equals(moduleName, e.moduleName)
>>> 412: && Objects.equals(moduleVersion, e.moduleVersion)
>>> 413:
On Mon, 15 Mar 2021 09:21:22 GMT, Patrick Concannon
wrote:
>> Hi,
>>
>> Could someone please review my code for updating the code in the `java.lang`
>> package to make use of the `instanceof` pattern variable?
>>
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request i
On Wed, 10 Mar 2021 16:34:39 GMT, Claes Redestad wrote:
>> - Remove unused code
>> - Inline and simplify the bootstrap method invocation code (remove pointless
>> reboxing checks etc)
>> - Apply pattern matching to make some code more readable
>
> Claes Redestad has updated the pull request with
On Fri, 12 Mar 2021 13:27:39 GMT, Claes Redestad wrote:
> Remove unused methods.
Marked as reviewed by mchung (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/2969
hould add w.r.t. Class::arrayType?
Yes, I suggest to put it under test/jdk/java/lang/Class/arrayType.
Mandy
- Johannes
On 24-Feb-21 20:54, Mandy Chung wrote:
Hi Johannes,
Changing Class::arrayType to throw ISA makes sense to me. I think
`TypeDescriptor.ofField::arrayType` spec should al
Hi Johannes,
Changing Class::arrayType to throw ISA makes sense to me. I think
`TypeDescriptor.ofField::arrayType` spec should also be updated to throw
ISA to follow what JVM checks for array dimension because it's a static
constraint check [1] (rather than a resolution error) for `anewarray
401 - 500 of 3335 matches
Mail list logo
