Re: Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

On 6/3/20 6:24 PM, John Rose wrote: On Jun 3, 2020, at 5:16 PM, Paul Sandoz > wrote:  if (UNSAFE.shouldBeInitialized(cls)) {  UNSAFE.ensureClassInitialized(cls);  } Although it seems redundant to perform the check, suggesting it is not needed. It’s usefu

Re: Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

On 6/3/20 5:16 PM, Paul Sandoz wrote: Hi Mandy, Did you consider an alternative name, such as: /** * Initializes {@code targetClass}, if not already initialized. * ... */ public Class initializeClass(Class targetClass) ... ? I considered this.   The targetClass may have been initializ

Re: [PATCH] 8245694 : java.util.Properties.entrySet() does not override java.lang.Object methods

Hi Jason, That's a good point! thx~ will do. Best regards, Yu On Wed, Jun 3, 2020 at 11:10 PM Jason Mehrens wrote: > Yu Li, > > You should consider changing the equals implementation to include an > identity self check. > > public boolean equals(Object o) { > return this == o || entry

Re: Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

On Jun 3, 2020, at 5:16 PM, Paul Sandoz wrote: > > if (UNSAFE.shouldBeInitialized(cls)) { > UNSAFE.ensureClassInitialized(cls); > } > > Although it seems redundant to perform the check, suggesting it is not needed. It’s useful (IIRC) in this kind of code: MethodHandle mh = … something a

Re: Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

Hi Mandy, Did you consider an alternative name, such as: /** * Initializes {@code targetClass}, if not already initialized. * ... */ public Class initializeClass(Class targetClass) ... ? What about the companion Unsafe.shouldBeInitialized? I have seen (and written) code like this: if (UNS

Re: ThreadGroup.enumerate/activeCount - any good reason not to deprecate?

Hi Alan, I've always thought ThreadGroups were a good idea that were never communicated very well. The notion of a ThreadGroup as a security context potentially had some value that was never truly realized. On 4/06/2020 4:40 am, Alan Bateman wrote: On 03/06/2020 18:47, Paul Sandoz wrote: It’

Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

This proposes a new `Lookup::ensureClassInitialized` API as a replacement for `sun.misc.Unsafe::ensureClassInitialized`.The Lookup object must have the access to the given class being initialized. CSR: https://bugs.openjdk.java.net/browse/JDK-8245871 webrev: http://cr.openjdk.java.net/~mchung/jd

Re: RFR(XL) 8198698: Support Lambda proxy classes in dynamic CDS archive

On 6/3/20 12:34 PM, Calvin Cheung wrote: I saw David has commented on this. So I'll leave the assert as before and I've added another assert (see line 1691): 1687   // The following ensures that the caller's nest host is the same as the lambda proxy's 1688   // nest host recorded at dump

Re: RFR(XL) 8198698: Support Lambda proxy classes in dynamic CDS archive

Hi David, On 6/2/20 10:30 PM, David Holmes wrote: 1685 InstanceKlass* n_h = caller_ik->nest_host(THREAD); 1686   assert(n_h->has_nest_member(caller_ik, THREAD) || 1687  n_h == caller_ik, "mismatched nest host"); I think you meant to check n_h->has_nest_member(loaded_lambda, THREAD). T

Re: RFR(XL) 8198698: Support Lambda proxy classes in dynamic CDS archive

Hi Mandy, Thanks for your review. On 6/2/20 11:38 AM, Mandy Chung wrote: Hi Calvin, To recap an offline discussion, I think we should use JDK bootcycle build to test this feature.  For example generating a boot JDK with archived lambda proxy classes for java.base and javac to build itself a

Re: ThreadGroup.enumerate/activeCount - any good reason not to deprecate?

On 03/06/2020 18:47, Paul Sandoz wrote: It’s tempting to go all out and investigate the deprecation of (not for removal) ThreadGroup in its entirety, and also deprecate the Thread constructors accepting ThreadGroup, related methods in SecurityManager, etc. I suspect that’s probably more work t

Re: ThreadGroup.enumerate/activeCount - any good reason not to deprecate?

It’s tempting to go all out and investigate the deprecation of (not for removal) ThreadGroup in its entirety, and also deprecate the Thread constructors accepting ThreadGroup, related methods in SecurityManager, etc. I suspect that’s probably more work than you want to take on right now, and may

Re: Sometimes constraints are questionable

On 6/3/20 6:20 AM, Jim Laskey wrote: I absolutely agree with the reasoning. ArraysSupport.newLength() is also probably easier for the compiler to optimize around (no exception.) I guess the only conflict here is to be meaningfully informative. The bug assigned to me (https://bugs.openjdk.ja

ThreadGroup.enumerate/activeCount - any good reason not to deprecate?

Does ThreadGroup have any fans out there? I'm looking to deprecate its enumerate, activeXXXCount, and list methods. Also Thread.enumerate and activeCount. I'm trying to identify if there are any important usages of these APIs that would suggest they shouldn't be deprecated. A static analysis

JDK-8229959: Current status and thoughts about JDK-8242888

Hi, half a year ago, I proposed a patch that implements JDK-8229959: Convert proxy class to use constant dynamic [2]. **Background**: java.lang.reflect.Proxy creates a class file at runtime that extends j.l.r.Proxy and implements the passed interfaces. Methods invoked on that proxy are passed

Re: Sometimes constraints are questionable

On 6/2/20 11:49 PM, David Holmes wrote: IIUC what you are saying is that MAX_ARRAY_LENGTH is treated as a soft-limit. A request for prefGrowth won't be allowed to exceed it. But if minGrowth takes the length passed it then the code tries to do the allocation that large anyway. If it succeeds we

Re: [PATCH] 8245694 : java.util.Properties.entrySet() does not override java.lang.Object methods

Yu Li, You should consider changing the equals implementation to include an identity self check. public boolean equals(Object o) { return this == o || entrySet.equals(o); } This is consistent with the collection wrapper classes in j.u.Collections. Jason ___

Re: RFR 8246095: Tweaks to memory access API

LGTM. The illustrative example in asUnsigned is nice ( I should have thought of similar, D’oh! ) -Chris. > On 3 Jun 2020, at 15:25, Maurizio Cimadamore > wrote: > > Please review this delta patch; I realized that the previously submitted > patch had few issues: > > * copyright header on Te

Re: RFR: 8246451: Reduce overhead of normalizing file paths with trailing slash

On 2020-06-03 16:24, Lance Andersen wrote: Hi Claes, This looks OK :-) Thank you, Lance! /Claes Best Lance On Jun 3, 2020, at 7:54 AM, Claes Redestad > wrote: Hi, I'd like to fix a bug in the microbenchmark I pushed for JDK-8246338 where the FileOpen.t

Re: RFR 8246095: Tweaks to memory access API

Please review this delta patch; I realized that the previously submitted patch had few issues: * copyright header on TestAdaptVarHandle benchmark was wrong * stream test for segment spliterator was not updated to include changes to copyFrom API * I've also incorporated a small javadoc tweak to

Re: RFR: JDK-8230744 Several classes throw OutOfMemoryError without message

It's not the goal or role of this bug to fix the wrongs of the past, merely add error messages to the exceptions. I raised the discussion as an issue. Clearly there is a correct path to follow. If you think more effort is required then file a bug. :-) Cheers, -- Jim > On Jun 2, 2020, at 7:

Re: RFR: 8246451: Reduce overhead of normalizing file paths with trailing slash

Hi Claes, This looks OK :-) Best Lance > On Jun 3, 2020, at 7:54 AM, Claes Redestad wrote: > > Hi, > > I'd like to fix a bug in the microbenchmark I pushed for JDK-8246338 > where the FileOpen.trailingSlash variant doesn't do what it intends to. > > There's also a profitable low-hanging opti

Re: Sometimes constraints are questionable

Stuart (and Martin), I absolutely agree with the reasoning. ArraysSupport.newLength() is also probably easier for the compiler to optimize around (no exception.) I guess the only conflict here is to be meaningfully informative. The bug assigned to me (https://bugs.openjdk.java.net/browse/JDK-82

RFR: 8246451: Reduce overhead of normalizing file paths with trailing slash

Hi, I'd like to fix a bug in the microbenchmark I pushed for JDK-8246338 where the FileOpen.trailingSlash variant doesn't do what it intends to. There's also a profitable low-hanging optimization down that path to substring rather than take the detour via StringBuilder[1] Bug:https://bugs.o