Integrated: 8274299: Make Method/Constructor/Field accessors @Stable

On Sat, 25 Sep 2021 10:15:11 GMT, Peter Levart wrote: > This patch improves reflective access speed as shown by the included > benchmarks: > > https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a > > ... and is also a prerequisi

Re: RFR: JDK-8274686 : java.util.UUID#hashCode() should use Long.hashCode()

On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis wrote: > This is trivial fix of > [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686) > which replaces manually-computed `int`-based `long` hash-code. > > Because `Long#hashCode(long)` uses other hashing function than

Re: RFR: JDK-8274686 : java.util.UUID#hashCode() should use Long.hashCode()

On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis wrote: > This is trivial fix of > [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686) > which replaces manually-computed `int`-based `long` hash-code. > > Because `Long#hashCode(long)` uses other hashing function than

Re: RFR: JDK-8274686 : java.util.UUID#hashCode() should use Long.hashCode()

On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis wrote: > This is trivial fix of > [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686) > which replaces manually-computed `int`-based `long` hash-code. > > Because `Long#hashCode(long)` uses other hashing function than

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

On Tue, 12 Oct 2021 17:42:01 GMT, Peter Levart wrote: >> Mandy Chung has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix left-over assignment > > src/java.base/shar

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

On Fri, 8 Oct 2021 23:31: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 implementation uses >> `VarHandle`.For the

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

On Thu, 14 Oct 2021 16:05:19 GMT, Mandy Chung wrote: >> src/java.base/share/classes/jdk/internal/reflect/DirectMethodHandleAccessor.java >> line 86: >> >>> 84: } >>> 85: >>> 86: private static final int PARAM_COUNT_MASK = 0x00FF; >> >> Is this packing logic required? I get it that it

Re: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources

Hi, On 11/10/2021 20:42, John Rose wrote: To summarize: We can (and should) try to model “close-debt” using interfaces. Doing so opens up the usual cans of worms with interoperability and exceptions, but still gives us a model we can contemplate. We can (and should) contemplate how such a mod

Re: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources

On Sun, 3 Oct 2021 11:00:25 GMT, Tagir F. Valeev wrote: > Currently, when the stream holds a resource, it's necessary to wrap it with > try-with-resources. This undermines the compact and fluent style of stream > API calls. For example, if we want to get the `List` of files inside the > direct

Re: RFR: JDK-8276422 Add command-line option to disable finalization [v2]

On Thu, 18 Nov 2021 08:39:52 GMT, Alan Bateman wrote: >> Yeah, "flag" is `Holder.ENABLED` here. I mean, are Java methods >> `registerFinalizer` and `runFinalization` called only by VM? If so, can VM >> check the whole thing on VM side, without going to Java and asking back from >> there? > > I

Re: RFR: JDK-8276422 Add command-line option to disable finalization [v2]

On Thu, 18 Nov 2021 14:53:38 GMT, Peter Levart wrote: >> I think @shipilev asks a good question. This could be done completely in the >> VM without the changes to j.l.ref.Finalizer. The CLI option is for >> experimenting, at least in the short term, and should be

Re: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive

On Mon, 15 Nov 2021 19:10:17 GMT, Roman Kennke wrote: > > If the intent of this change is to alter the lifetimes of the objects in > > question in a meaningful way, I recommend a CSR for the behavioral > > compatibility impact. > > It would be hard for application code to observe this change:

Re: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive [v2]

On Mon, 29 Nov 2021 13:47:19 GMT, Roman Kennke wrote: > I don't quite understand this: If the Class object is still reachable by the > app, 1. a weak reference would not get cleared and 2. the Class's ClassLoader would not get unloaded. ...but the ObjectStreamClass instance could still get GC-

Re: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive [v2]

On Mon, 15 Nov 2021 21:35:06 GMT, Roman Kennke wrote: >> The caches in ObjectStreamClass basically map WeakReference to >> SoftReference, where the ObjectStreamClass also >> references the same Class. That means that the cache entry, and thus the >> class and its class-loader, will not get rec

Re: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive [v3]

On Tue, 30 Nov 2021 11:25:48 GMT, Roman Kennke wrote: >> The caches in ObjectStreamClass basically map WeakReference to >> SoftReference, where the ObjectStreamClass also >> references the same Class. That means that the cache entry, and thus the >> class and its class-loader, will not get rec

Re: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive [v3]

On Tue, 30 Nov 2021 11:25:48 GMT, Roman Kennke wrote: >> The caches in ObjectStreamClass basically map WeakReference to >> SoftReference, where the ObjectStreamClass also >> references the same Class. That means that the cache entry, and thus the >> class and its class-loader, will not get rec

Re: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive [v4]

On Thu, 2 Dec 2021 14:24:06 GMT, Roman Kennke wrote: >> src/java.base/share/classes/java/io/ObjectStreamClass.java line 2133: >> >>> 2131: if (oldReflector != null) { >>> 2132: reflector = oldReflector; >>> 2133: } >> >> Map.computeIfAbsent(key, () -> new

Re: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive [v6]

On Thu, 2 Dec 2021 16:22:02 GMT, Roman Kennke wrote: >> The caches in ObjectStreamClass basically map WeakReference to >> SoftReference, where the ObjectStreamClass also >> references the same Class. That means that the cache entry, and thus the >> class and its class-loader, will not get recl

Re: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive [v7]

On Mon, 6 Dec 2021 12:12:44 GMT, Roman Kennke wrote: >> The caches in ObjectStreamClass basically map WeakReference to >> SoftReference, where the ObjectStreamClass also >> references the same Class. That means that the cache entry, and thus the >> class and its class-loader, will not get recl

Re: RFR: 8278065: Refactor subclassAudits to use ClassValue [v3]

On Fri, 10 Dec 2021 21:07:37 GMT, Roman Kennke wrote: >> As a follow-up to #6375, this change refactors >> java.io.ObjectInputStream.Caches#subclassAudits and >> java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead >> of SoftReference, similar to what we did in #6375 for

Re: RFR: 8280041: Retry loop issues in java.io.ClassCache [v3]

On Wed, 19 Jan 2022 08:25:55 GMT, Aleksey Shipilev wrote: >> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two >> issues with it: >> - The cache cannot disambiguate between cleared SoftReference and the >> accidental passing of `null` value; in that case, the retry

Re: RFR: 8280041: Retry loop issues in java.io.ClassCache [v3]

On Wed, 19 Jan 2022 08:25:55 GMT, Aleksey Shipilev wrote: >> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two >> issues with it: >> - The cache cannot disambiguate between cleared SoftReference and the >> accidental passing of `null` value; in that case, the retry

Re: RFR: 8280041: Retry loop issues in java.io.ClassCache [v3]

On Wed, 19 Jan 2022 10:44:57 GMT, Aleksey Shipilev wrote: > > So, this patch is fine for making ClassCache more robust as a re-usable > > component inside JDK (checking for non-null return of computeValue). The > > 2nd change, that apparently shields against unbounded accumulation of > > garba

Re: RFR: 8280041: Retry loop issues in java.io.ClassCache [v3]

On Wed, 19 Jan 2022 13:10:55 GMT, Peter Levart wrote: > Note this matches other places we do the weak-reference loops, for example in > `MethodType`: > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/MethodType.java#L1390-L1401 This one does

Re: RFR: 8280041: Retry loop issues in java.io.ClassCache [v4]

On Fri, 21 Jan 2022 11:04:22 GMT, Aleksey Shipilev wrote: >> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two >> issues with it: >> - The cache cannot disambiguate between cleared SoftReference and the >> accidental passing of `null` value; in that case, the retry

Re: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v3]

On Sat, 22 Jan 2022 00:00:18 GMT, liach wrote: >> liach has updated the pull request with a new target base due to a merge or >> a rebase. The incremental webrev excludes the unrelated changes brought in >> by the merge/rebase. The pull request contains four additional commits since >> the las

Re: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v5]

On Thu, 10 Feb 2022 13:36:11 GMT, liach wrote: >> liach has updated the pull request with a new target base due to a merge or >> a rebase. The incremental webrev excludes the unrelated changes brought in >> by the merge/rebase. The pull request contains seven additional commits >> since the la

Re: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v6]

On Thu, 10 Feb 2022 22:53:56 GMT, liach wrote: >> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), >> by design, duplicate initialization of ReflectionFactory should be safe as >> it performs side-effect-free property read actions, and the suggesting of >> making the

Re: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v6]

On Fri, 11 Feb 2022 08:05:30 GMT, Peter Levart wrote: >> liach has updated the pull request incrementally with one additional commit >> since the last revision: >> >> Make config a pojo, move loading code into config class > > src/java.base/shar

Re: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v7]

On Fri, 11 Feb 2022 13:51:38 GMT, liach wrote: >> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), >> by design, duplicate initialization of ReflectionFactory should be safe as >> it performs side-effect-free property read actions, and the suggesting of >> making the

Re: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v6]

On Fri, 11 Feb 2022 13:42:01 GMT, liach wrote: >> ...having suggested that rearrangement, perhaps the right way to do it is to >> enable some VM.isXXX queries themselves to be constant-foldable so that >> other callers too may benefit. Like this: >> https://github.com/plevart/jdk/commit/e918ccc

Re: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v7]

On Fri, 11 Feb 2022 21:44:04 GMT, Mandy Chung wrote: > Note that the object methods of this Config record are called via indy which > is > available to use after initPhase1. We can workaround that limitation by > implementing the object methods. "Note that the object methods of this Config r

Re: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v9]

On Mon, 21 Feb 2022 16:35:09 GMT, liach wrote: >> liach has updated the pull request with a new target base due to a merge or >> a rebase. The incremental webrev excludes the unrelated changes brought in >> by the merge/rebase. The pull request contains 13 additional commits since >> the last

Re: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable

On Mon, 17 Jan 2022 08:28:35 GMT, Erik Gahlin wrote: >> src/jdk.jfr/share/classes/jdk/jfr/internal/TypeLibrary.java line 405: >> >>> 403: Object res = m.invoke(a, new Object[0]); >>> 404: if (res instanceof Annotation[]) { >>> 405:

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is >> "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but >> dist

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v12]

On Mon, 28 Feb 2022 18:20:13 GMT, ExE Boss wrote: >> It does because of the AccessFlags.MODULE constant. > >> It does because of the AccessFlags.MODULE constant. > > But that’s exactly what the unqualified `MODULE` identifier refers to, and  > there’s no other bare `MODULE` identifier in scope t

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is >> "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but >> dist

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

On Tue, 8 Mar 2022 00:19:58 GMT, Joe Darcy wrote: > > The mapping from Location to AccessFlag(s) could be implemented event > > without using a Map. You just have to be careful not to use EnumSet for > > that (i.e. before AccessFlag enum constants are fully initialized) - an > > ArrayList is b

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is >> "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but >> dist

Re: RFR: JDK-8283075: Bad IllegalArgumentException message when calling ClassDesc.arrayType(int) which results in a rank > 255 [v2]

On Mon, 14 Mar 2022 21:27:29 GMT, Joe Darcy wrote: >> Improving the exception messages for out-of-supported-range array types. >> >> I'll update copyrights before pushing. > > Joe Darcy has updated the pull request incrementally with one additional > commit since the last revision: > > Respo

Re: RFR: 8286571: java source launcher from a minimal jdk image containing jdk.compiler fails with --enable-preview option [v3]

On Wed, 18 May 2022 06:30:34 GMT, Adam Sotona wrote: >> ### Problem description >> Minimal jdk image created by jlink with the only jdk.compiler module and its >> dependencies >> fails to run java source launcher correctly (for example when --source N is >> specified). >> Failing source launche

Re: RFR: 8286571: java source launcher from a minimal jdk image containing jdk.compiler fails with --enable-preview option [v3]

On Sun, 22 May 2022 16:54:25 GMT, Peter Levart wrote: > My humble opinion: if java.compiler needs jdk.zipfs for full functionality Sorry, I wrongly assumed it was `java.compiler` (the library module), but this is about `jdk.compiler` (the tool)... Nevertheless, the same question appl

Re: Stream.fromForEach(Consumer>)

Hi, On 23/05/2022 14:53, Brian Goetz wrote: ... Are there any useful Consumer> in the wild, that are actually typed like that?  I doubt it (there are many things convertible to it, though.)  Which suggests it might be fruitful to define a FI:     interface PushSource {     void accept(

Re: RFR: 8287073: NPE from CgroupV2Subsystem.getInstance()

On Fri, 20 May 2022 08:34:58 GMT, Maxim Kartashev wrote: > Following the logic from the comment directly above the changed line, since > it doesn't matter which controller we pick, pick any available controller > instead of the one called "memory" specifically. This way we are guarded > again

Re: RFR: 8287073: NPE from CgroupV2Subsystem.getInstance()

On Wed, 25 May 2022 14:39:42 GMT, Peter Levart wrote: >> Following the logic from the comment directly above the changed line, since >> it doesn't matter which controller we pick, pick any available controller >> instead of the one called "memory" spec

Re: RFR: 8287073: NPE from CgroupV2Subsystem.getInstance()

On Wed, 25 May 2022 15:54:04 GMT, Maxim Kartashev wrote: >> `CgroupV1Subsystem.getInstance(...)` also claims that it never returns >> `null`, but has a code-path that actually returns `null` (when there is no >> active controller). Is this a possible outcome? > > @plevart Are you asking about

Re: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle [v2]

On Fri, 10 Jun 2022 11:45:28 GMT, David M. Lloyd wrote: >> Hello David, I suspect you mean `handlers.put(sig, handler)` and not >> `handlers.replace(...)`? And yes, I think what you suggest will help remove >> the synchronized block here. > > Oops, yes you are correct! Hi, I think the synchron

Re: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle [v2]

On Sat, 11 Jun 2022 07:55:52 GMT, Peter Levart wrote: >> Oops, yes you are correct! > > Hi, > I think the synchronized block was redundant already in original code. Since > the entire handle method is `static synchronized` and it is the only method > that modifies the `h

Re: hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String

On Thursday, May 31, 2012 03:22:35 AM mike.dui...@oracle.com wrote: > Changeset: 2c773daa825d > Author:mduigou > Date: 2012-05-17 10:06 -0700 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d > > 6924259: Remove offset and count fields from java.lang.String > Summary: R

Re: String.subSequence and CR#6924259: Remove offset and count fields from java.lang.String

quence currently and which will > fail when the result is not a String instance as String.equals() will > return false for all CharSequences that aren't Strings. ie. CharSequence > token = line.subSequence(line, start, end); if (keyword.equals(token)) ... > This would now fail. >

ServiceLoader.load(Class, ClassLoader) bug

Hi, The javadoc for java.util.ServiceLoader.load(Class service, ClassLoader loader) method says about it's parameters: * @param service * The interface or abstract class representing the service * * @param loader * The class loader to be used to load

Re: ServiceLoader.load(Class, ClassLoader) bug

I reported this as Bug ID: 7198496 Regards, Peter On 09/13/2012 05:13 PM, Peter Levart wrote: Hi, The javadoc for java.util.ServiceLoader.load(Class service, ClassLoader loader) method says about it's parameters: * @param service * The interface or abstract

Re: ServiceLoader.load(Class, ClassLoader) bug

is will change behaviour to no longer produce an error that would otherwise be acted on. This may be the case for libraries that use SL and the user passed a CL to the library and the library on error uses, for example. the thread context CL. Who knows, CL code can be very strange. Paul. On

Re: Reviewer and committer request for 7198496

I think that in the LazyIterator.hasNext() you still have to check for null loader: 337 if (loader == null) 338 configs = ClassLoader.getSystemResources(fullName); 339 else 340 configs = loader.getResourc

Re: Reviewer and committer request for 7198496

On 10/04/2012 03:37 PM, David Holmes wrote: On 4/10/2012 9:56 PM, Paul Sandoz wrote: On Oct 4, 2012, at 12:37 PM, David Holmes wrote: Paul, On 4/10/2012 7:53 PM, Paul Sandoz wrote: On Oct 4, 2012, at 11:34 AM, David Holmes wrote: These parts of the javadoc for get/setContextClassLoad

Re: RFR: 6206780 (str) Forwarding append methods in String{Buffer, Builder} are inconsistent

On 10/07/2012 08:42 PM, Alan Bateman wrote: On 06/10/2012 01:52, Jim Gish wrote: I've revamped the previous proposed change. Please review the update at http://cr.openjdk.java.net/~jgish/Bug6206780-sb-append-forward/ This re

Re: Review/comment needed for the new public java.util.Base64 class

One way to do it without state in encoder is 1st as suggested to have the 'endOfStream' flag and in addition when new-line breaks are requested, to only encode "full lines" at each invocation. So If one wants to use this line-breakage feature he/she must make sure that there is enough space (li

Re: Review/comment needed for the new public java.util.Base64 class

On 10/13/2012 11:21 AM, Peter Levart wrote: One way to do it without state in encoder is 1st as suggested to have the 'endOfStream' flag and in addition when new-line breaks are requested, to only encode "full lines" at each invocation. So If one wants to use this line-bre

Re: RFR 9: 8086117: java/lang/Runtime/exec/LotsOfOutput.java still fails intermittently with Process consumes memory

Hi Roger, I don't know how the tests are executed in your environment, but is it possible that, while you're running the test in a shared VM, some other concurrent activity allocates from heap and that the test fails because of that and not because of Process.exec() at all? Regards, Peter O

Re: JEP 132: More-prompt finalization

Hi Kim, On 06/09/2015 07:44 AM, Peter Levart wrote: Hi Kim, Thanks for taking a look at this code. On 06/09/2015 04:03 AM, Kim Barrett wrote: On May 31, 2015, at 3:32 PM, Peter Levart wrote: So, for the curious, here's the improved prototype: http://cr.openjdk.java.net/~plevart

Re: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

Hi Brian, On 06/24/2015 09:04 PM, Brian Burkhalter wrote: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8042377 Patch: http://cr.openjdk.java.net/~bpb/8042377/webrev.00/ The use of try-with-resources in FilteredOutputStream.close() is replaced with expli

Re: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

On 06/26/2015 09:52 AM, Alan Bateman wrote: On 25/06/2015 18:58, Brian Burkhalter wrote: Hi Peter, Thanks for the code change suggestion. I have modified the patch to use its logic and to revert to the original boolean instance variable instead of the contentious AtomicBoolean: http://cr.

Re: JEP 132: More-prompt finalization

Hi Kim, Thanks again for looking into changed code. Some comments to your comments for easier understanding of my code (when you have time)... On 06/26/2015 11:36 PM, Kim Barrett wrote: On Jun 22, 2015, at 3:33 AM, Peter Levart wrote: Hi Kim, Sorry, I just noticed you'd sent an upd

Re: RFR - 8129956: jaxp: CodeSource.getLocation() might return null

Hi Daniel, Just a question. Would diamonds on anonymous instance creation expressions work in these cases? Regards, Peter On 06/26/2015 12:45 PM, Daniel Fuchs wrote: Hi, It was brought to my attention that CodeSource.getLocation() might return null. The javadoc is not very clear on the subj

RFR: JDK-8080225: FileInputStream cleanup should be improved

Hi, As part of JEP 132 (More-prompt finalization) I wanted to find out what it would take to convert finalization-based cleanup code used in a JDK class to PhantomReference-based. In FileInputStream case, the state needed for clean-up is stored in a FileDescriptor referenced from FileInputSt

Re: RFR 9: 8078099 : (process) ProcessHandle should uniquely identify processes

Hi Roger, I looked at the code briefly and have the following comments: For ProcessHandleImpl_macosx.c, in method getProcessPids0: 224 // Get buffer size needed to read all processes 225 int mib[4] = {CTL_KERN, KERN_PROC, KERN_PROC_ALL, 0}; 226 if (sysctl(mib, 4, NULL, &bufSize,

Exception handling in Files.walk and Files.find

Hi, Recently I wanted to use Files.walk method returning a Stream to scan a directory of files. I quickly learned that it is of limited use. For example, the following code: long pngFilesCount = Files.walk(Paths.get("/usr")) .filter(path -> path.toString().endsWith(".p

Re: Exception handling in Files.walk and Files.find

, Steven Schlansker wrote: How about BiConsumer, unless the Path is easily accessible otherwise? On Jul 2, 2015, at 6:56 AM, Peter Levart wrote: Hi, Recently I wanted to use Files.walk method returning a Stream to scan a directory of files. I quickly learned that it is of limited use. For example

Re: RFR 9: 8078099 : (process) ProcessHandle should uniquely identify processes

n-exceptional in any case. I just wonder if it is OK that this "lack of full-information" is not communicated to the method caller and acted upon. Regards, Peter Thanks, Roger On 7/2/2015 3:32 AM, Peter Levart wrote: Hi Roger, I looked at the code briefly and have the follo

Re: RFR JDK-8130914: java/util/zip/TestExtraTime.java fails with "java.lang.RuntimeException: setTime should make getLastModifiedTime return the specified instant: 3078282244456 got: 3078282244455"

Hi Sherman, On 07/15/2015 09:10 PM, Xueming Shen wrote: Hi, Please help review the change for JDK-8130914. issue: https://bugs.openjdk.java.net/browse/JDK-8130914 webrev: http://cr.openjdk.java.net/~sherman/8130914/ This is a "regression" triggered by https://bugs.openjdk.java.net/browse/JDK-

Re: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with "RuntimeException: Error: poll() returned null; expected ref object"

Hi, Let me chime in and add some comments... On 07/30/2015 01:46 AM, Kim Barrett wrote: On Jul 29, 2015, at 4:32 AM, David Holmes wrote: On 29/07/2015 5:57 PM, Kim Barrett wrote: ... The race is being fixed by reordering a pair of volatile assignments. While this seems logical for the fail

Re: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with "RuntimeException: Error: poll() returned null; expected ref object"

On 07/30/2015 10:38 AM, Peter Levart wrote: [This suggests the r.queue = NULL assignment in reallyPoll() should be moved later, though I think the assignment order in reallyPoll() doesn't matter.] I think the assignment to r.queue = NULL in realyPoll() should be moved *before

Re: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with "RuntimeException: Error: poll() returned null; expected ref object"

On 07/30/2015 11:12 AM, Daniel Fuchs wrote: Hi Peter, I'm glad you're looking at this too! We can't have too many eyes :-) On 30/07/15 10:38, Peter Levart wrote: Suppose we have a Reference 'r' and it's associated ReferenceQueue 'q'. Currently it ca

Re: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with "RuntimeException: Error: poll() returned null; expected ref object"

On 07/30/2015 12:24 PM, David Holmes wrote: On 30/07/2015 8:20 PM, Peter Levart wrote: On 07/30/2015 11:12 AM, Daniel Fuchs wrote: Hi Peter, I'm glad you're looking at this too! We can't have too many eyes :-) On 30/07/15 10:38, Peter Levart wrote: Suppose we have a Re

Re: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with "RuntimeException: Error: poll() returned null; expected ref object"

On 07/30/2015 12:48 PM, Daniel Fuchs wrote: On 30/07/15 12:20, Peter Levart wrote: On 07/30/2015 11:12 AM, Daniel Fuchs wrote: Hi Peter, I'm glad you're looking at this too! We can't have too many eyes :-) On 30/07/15 10:38, Peter Levart wrote: Suppose we have a Referen

Re: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with "RuntimeException: Error: poll() returned null; expected ref object"

On 07/30/2015 01:44 PM, David Holmes wrote: r.isEnqueued() && q.poll() == null && r.isEnqueued() ==> true What is surprising in the above expression evaluating to true is the fact that 'r' appears to be enqueued before and after the q.poll() returns null. I can easily imagine code that would

Re: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with "RuntimeException: Error: poll() returned null; expected ref object"

On 07/31/2015 12:56 AM, Kim Barrett wrote: On Jul 30, 2015, at 5:33 PM, David Holmes wrote: So I think I can either: 1. Go ahead with my change + Peter's change. 2. Give this back to core-libs while I step carefully away :-) I *think* option (1) is at least an improvement. But I completel

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

On 09/08/2015 09:15 PM, Remi Forax wrote: On 09/08/2015 03:29 PM, Andrew Haley wrote: On 09/08/2015 02:05 PM, Andrew Haley wrote: I don't think you'd actually need to unmap anything until a safepoint. I don't think that the speed of unmapping is critical as long as it happens "soon". Althoug

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

Hi Uwe, As I thought, the problem for some seems to be non-prompt unmapping of mapped address space held by otherwise unreachable mapped byte buffers. The mapped address space doesn't live in the Java heap and doesn't represent a heap memory pressure, so GC doesn't kick-in automatically when

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

On 09/09/2015 04:21 PM, Peter Levart wrote: Hi Uwe, As I thought, the problem for some seems to be non-prompt unmapping of mapped address space held by otherwise unreachable mapped byte buffers. The mapped address space doesn't live in the Java heap and doesn't represent a h

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

On 09/09/2015 04:56 PM, Dawid Weiss wrote: I think it would be best to leave to the application to decide and implement the tracking and also triggering GC at times when it approaches the limit. I disagree. The GC -- when and how it is triggered -- should be transparent to the application. We

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

Hi guys, Perhaps there's no need for this protection/trap dance. If the situation is never tripped in correct programs (that unmap only after noone is using the buffers any more), then checking for address and throwing in case it is equal to some guard value is a never taken branch that is pr

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

(dulicate(), slice(), asXxxBuffer()) since they copy over the address to their instance field, so multiple instances point to the same block of memory with their own address fields... Regards, Peter sent from my phone On Sep 10, 2015 6:29 PM, "Peter Levart" <mailto:peter.l

Re: URLClassPath does unnecessary linear search through every jar and jar entry to find resource

Hi Adrian, I looked briefly at your code and claims and have some comments inline... On 09/13/2015 11:08 AM, Adrian wrote: Hi, I posted about this earlier (few weeks ago), and got some responses about concerns which I addressed in my last email, though I didn't hear back about it. My apologies

Re: RFR: 8136583: Core libraries should use blessed modifier order

Hi Martin, On 09/16/2015 02:42 AM, Martin Buchholz wrote: Hi, Chris and Paul, I'd like you to do a very boring code review. This change is entirely machine generated. (the script is more interesting) http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order/blessed-modifier-ord

Re: RFR(m) 2: 8072722: add stream support to Scanner

As an alternative to additional boolean field, you could use one bit of expectedCount/modCount int field(s): - let initial value of expectedCount be 1 (odd value) - instead of (expectedCount >= 0) ==> (expectedCount != 1) - let initial value of modCount be 0 (even value) - instead of modCount++

Re: JEP 264: Platform Logging API and Service

On 09/18/2015 06:17 PM, mark.reinh...@oracle.com wrote: New JEP Candidate: http://openjdk.java.net/jeps/264 - Mark Hi, What is the purpose of exposing a factory for loggers in the generally exported package (java.lang) and making it standard Java API as opposed to keeping it internal API

Re: RFR 8135248: Add utility methods to check indexes and ranges

Hi Paul, It seems that all that is needed for performance is to intrinsify static methods Integer.compareUnsigned(int, int) and Long.compareUnsigned(long, long). Or would that not be enough? Then perhaps explicit compare operations would suffice: public class Integer { ... public static

Re: RFR 8135248: Add utility methods to check indexes and ranges

On 09/21/2015 05:22 PM, Peter Levart wrote: Hi Paul, It seems that all that is needed for performance is to intrinsify static methods Integer.compareUnsigned(int, int) and Long.compareUnsigned(long, long). Or would that not be enough? Then perhaps explicit compare operations would suffice

Re: RFR 8135248: Add utility methods to check indexes and ranges

On 09/21/2015 05:46 PM, Paul Sandoz wrote: On 21 Sep 2015, at 16:45, Remi Forax wrote: I agree with Stephen. Calling the function interface with the name ...Exception seems very wrong to me. Agreed, need to think of a better name. One solution is to remove it all together :-) see below.

Re: Array equality, comparison and mismatch

Hi Paul, Just some thoughts about nulls... Simple compare and compareUnsigned methods (without ranges) accept null arrays. They specify that indirectly by stating that they are consistent with equals methods that do the same. The equals methods specify that two null array references are equal

RFR: JDK-8136893: Improve early java.lang.invoke infrastructure initialization

Hi, I propose a simple fix for two initialization issues described/linked in: https://bugs.openjdk.java.net/browse/JDK-8136893 The patch is here: http://cr.openjdk.java.net/~plevart/jdk9-dev/8136893_MethodType.fromDescriptor/webrev.01/ The 1st issue is the method: MetodType.fromMethodDescript

Re: RFR 8080418 Add Optional.or()

On 09/25/2015 02:30 PM, Paul Sandoz wrote: >There's also another problem. The orElseGet(null) is documented to >work to work fine for non-empty optional >(why on the Earth it was specified this way?). Arguably it was a mistake that we did not catch in the frenzy of Java 8 feature freeze. I wo

Re: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure initialization

entical - it's probably really easy to confuse the two when working at the core libs level. Unfortunately, the only proposal for a name I can make, fromDescriptorStringBootCL(), is clunky. Maybe that's acceptable for a low-level method only visible at package level. Am 25.09.2015 um 0

Re: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure initialization

null means bootstrap loader in other public APIs as well (for example: Class.forName(String name, boolean initialize, ClassLoader loader); ) although passing null from user code is rarely needed if at all. This is usually just for internal use. Regards, Peter Am 25.09.2015 um 08:46 schrieb P

Re: RFR 8135248: Add utility methods to check indexes and ranges

On 09/29/2015 06:05 PM, Paul Sandoz wrote: On 29 Sep 2015, at 12:57, Stephen Colebourne wrote: Just to note that an ideal location for this would be on a new class, one that has been discussed before, an "argument checker class". See Guava Preconditions: https://github.com/google/guava/blob/

Re: RFR 8135248: Add utility methods to check indexes and ranges

On 09/29/2015 10:01 PM, Paul Sandoz wrote: >I think it's worth introducing Preconditions class. checkNotNull overloads are equally well suited for Objects as they are for Preconditions, so it's not wrong to have them in both, while checkIndex and friends don't really suit any of the existing

Re: JEP 264: Platform Logging API and Service

niel Fuchs wrote: On 20/09/15 15:46, Peter Levart wrote: On 09/18/2015 06:17 PM, mark.reinh...@oracle.com wrote: New JEP Candidate:http://openjdk.java.net/jeps/264 - Mark Hi, What is the purpose of exposing a factory for loggers in the generally exported package (java.lang) and making it standar

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Roger, This is a nice and clean API. I like the trick with embedding a private CleanerImpl in Cleaner and registering Cleaner itself as a tracked object so that automatic thread termination can be performed in a safe manner. You say the scope of this is not to replace internal usages of su

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use > alternative to finalization (Roger Riggs)

On 10/02/2015 10:16 PM, Roger Riggs wrote: Hi Mike, Thanks for the review and comments... On 10/2/2015 3:33 PM, Mike Duigou wrote: Hi Roger; This looks like an interesting proposal and would be a good replacement for alternative solutions. I am curious why the thread is run at max priori

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