From donraab at gmail.com Sat May 1 00:07:25 2021 From: donraab at gmail.com (Donald Raab) Date: Fri, 30 Apr 2021 20:07:25 -0400 Subject: Collection::getAny discussion In-Reply-To: <534c8276-8afe-f707-160e-58c170cdc4e0@oracle.com> References: <38af-60883900-4c5-3a732100@161619996> <838b3ee1-20ac-2baa-f477-03e92f4697c3@oracle.com> <534c8276-8afe-f707-160e-58c170cdc4e0@oracle.com> Message-ID: <94D038CB-CC61-4118-9220-A2ABA7DC1125@gmail.com> To clarify, RichIterable is not a subclass of Collection. As we discovered in JDK 15, a problem exists when we add default methods to interfaces that might get ?mixed? with other interfaces that already have those methods. There are a few potential issues with adding zero argument default methods to common interfaces. The two easiest to reason about that we have experience with are: 1. Signatures don?t match (e.g. getAny() returns Optional) - very bad - lots of pain caused - forces backwards incompatible change to library APIs - this happened when default sort() was added to List and returned void 2. Signatures match, but no concrete implementations when mixing competing default implementations - work for library developers - forces clients to upgrade to new version of library to use new version of JDK (e.g. EC 10.4 upgrade to work with JDK 15 for CharSequence.isEmpty()) https://stuartmarks.wordpress.com/2020/09/22/incompatibilities-with-jdk-15-charsequence-isempty/ I think adding getAny() to Collection makes sense, that?s why we have defined the method on RichIterable. For Eclipse Collections, option #2 is the only option that works (getAny() returns E). It will cause us OSS library maintainers a bunch of work and a release upgrade. Knowing the direction and testing with early access versions (as we do) prior to our next release will help so we can start coding out any necessary concrete implementations wherever they don?t exist in the hierarchy. The default getAny() implementation on RichIterable is different than just calling iterator.next() though. The getAny() method is currently defined as calling getFirst() which will return null in the case an iterable is empty. So this creates a new kind of potential issue we haven?t experienced where we could wind up with two getAny() methods with the same signature but with different specifications and results on empty. This will be potentially confusing for Eclipse Collections users as they could get different behavior from any JDK collections for getAny(), or libraries they use could get different behavior for Eclipse Collections types that extend JDK types. Do we change the Eclipse Collections specification to match the new JDK specification? Will this break anyone that currently uses it by causing new unexpected Runtime exceptions? I honestly don?t know. For additional reference, there is also a getOnly() method on RichIterable which behaves differently than getAny(). https://www.eclipse.org/collections/javadoc/10.4.0/org/eclipse/collections/api/RichIterable.html#getOnly() There are also getFirst() and getLast() methods on RichIterable which were deprecated in 6.0 but will never be removed. They were added to OrderedIterable where they make more sense. > On Apr 30, 2021, at 4:14 PM, Brian Goetz wrote: > > While I agree that we should be careful, let's not paint ourselves into an either/or strawman. The choice is not "never add anything to Collection" vs "let's dump every silly idea that comes to anyone's mind into Collection"; it is, as always, going to involve tradeoffs between stability and evolution. > > We cannot constrain ourselves so hard that we cannot evolve the core libraries because it might collide with someone else's subclass. That's not reasonable, nor is that good for Java. > > On the other hand, we must continue to exercise care in many dimensions when adding to libraries that are widely used and implemented -- which we already do (so much so, in fact, that people are often frustrated by our seeming conservatism.) > > > > > > > > On 4/30/2021 4:02 PM, Donald Raab wrote: >> There is a default method getAny defined on the RichIterable interface in Eclipse Collections. Adding a getAny with the same signature to Collection is bound to cause a break similar to CharSequence.isEmpty did with JDK 15 but possibly more extensive since RichIterable is the parent interface for all collection types in Eclipse Collections. Adding it with a different signature (returns Optional) could cause extensive damage. >> >> https://www.eclipse.org/collections/javadoc/10.4.0/org/eclipse/collections/api/RichIterable.html#getAny() >> >> I highly recommend we stop looking to add new zero-argument default methods to 20+ year Collection interfaces and hope that we don?t break anything. There seems to be desire to breathe life into the old Collection interfaces. IMO, we should just start planning and focusing on a Collections 2.0 design. >> >> >>> On Apr 30, 2021, at 2:49 PM, Stuart Marks wrote: >>> >>> Hi Henri, >>> >>> I've changed the subject of this thread because I think it's out of scope of the ReversibleCollection proposal. I don't mean to say that we can't talk about it, but I would like it to be decoupled from ReversibleCollection. I'm somewhat arbitrarily calling it "Collection::getAny" because something similar to that was mentioned by both Remi and Peter elsewhere in this thread. There is also a bunch of history in the bug database that contains related ideas. >>> >>> Before we dive in, I want to explain why this is separate from ReversibleCollection. Most of the ideas, including yours, involve an implementation that does something like `iterator().next()`, in other words, getting the "first" element from an Iterator. Hey, there's getFirst() in ReversibleCollection, let's use that! No. The "first" element of an iterator is in general an arbitrary element, which is different from the "first" element in the structural ordering of elements provided by a ReversibleCollection. The "arbitrary" notion is captured by "getAny" so that's what I'll use as a working term. (Of course any actual API we might add would have a better name if we can find one.) >>> >>> For a historical perspective, let's dig into the bug database and take a look at this bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-4939317 >>> >>> This requests a method Collection.get(Object). This searches the collection for an element that equals() the argument and returns the element, or it returns null if the element isn't found. (Recall in those days it was impossible to add a method to an interface without breaking compatibility, so it also proposes various workarounds that are no longer necessary.) >>> >>> There's a comment from Josh Bloch saying that Collection should have had a get() method as well as a no-arg remove() method. Well ok then! And he points to the then-new Queue interface that was delivered in Java SE 5. Queue adds the following methods that seem relevant to this discussion: >>> >>> * E element() -- gets the head element, throws NSEE if empty >>> * E remove() -- removes and returns the head element, throws NSEE if empty >>> >>> (It also adds peek() and poll(), which are similar to the above except they return null if empty.) >>> >>> This is kind of odd, in that none of these methods satisfy what the bug's submitter was requesting, which is a one-arg get() method. Also, these methods are on Queue, which doesn't really help with collections in general. >>> >>> You're asking for something that's somewhat different, which you called the "find the first element when there is only one" problem. Here, there's a precondition that the collection have a single element. (It's not clear to me what should happen if the collection has zero or more than one element.) >>> >>> To throw a couple more variations into the mix, Guava has a couple Collectors (for streams) that do interesting things. The class is MoreCollectors: >>> >>> https://guava.dev/releases/30.1.1-jre/api/docs/com/google/common/collect/MoreCollectors.html >>> >>> and the collectors are: >>> >>> * onlyElement -- if source has 1 element, returns it; throws NSEE if empty, IAE if > 1 >>> * toOptional -- if source has 0 or 1 elements, returns an Optional; otherwise throws >>> >>> These apply to streams, but I think you can see the applicability to Collection as well. In particular, your proposal is similar to what onlyElement would look like if it were on Collection. >>> >>> Let's summarize the variations so far: >>> >>> * preconditions: exactly one element, at-most-one, at-least-one >>> * behavior if preconditions not met: return null, return empty Optional, throw >>> exception >>> * remove element or just peek >>> * match a particular element, or return an arbitrary element >>> >>> That's a lot of variations! >>> >>> Before we talk about specific APIs, though, I wanted to talk about use cases. Which of these variations are more useful or less useful? Which are likely to appear in code? Henri gave a fairly specific example with a reasonable "success" case (preconditions met) but it's not clear what should happen if the preconditions aren't met. Clearly an API would have to choose. What would the use site look like? In particular, does the use site always have to check for null, or catch an exception, or something? >>> >>> Answers to these questions will help determine what APIs, if any, we might want to add. >>> >>> *** >>> >>> There's another thing looming in the distance, which is pattern matching. You might have seen one of Brian Goetz's talks on pattern matching futures. You can get a glimpse of some upcoming pattern matching features in JEP 405. >>> >>> http://openjdk.java.net/jeps/405 >>> >>> In particular, this JEP extends pattern matching with an /extraction/ step, where, if there is a match, record or array components can be extracted and bound to local variables. This is a step closer to /deconstruction patterns/, where arbitrary classes and interfaces (not just records or arrays) can participate in pattern matching. (See discussion of this at the end of the JEP.) >>> >>> Deconstruction patterns apply directly to this discussion. For example, Henri's example could be rewritten like this, using pattern matching: >>> >>> Set s = ... ; >>> if (s instanceof Set.containing(String string)) { >>> // use string, which is the only element >>> } else { >>> // handle failure >>> } >>> >>> This "containing" thing would be a deconstruction pattern declared on Set or Collection (or possibly elsewhere), and as I've written here, it implicitly matches sets that contain exactly one element. Taking a nod from JEP 405's varargs-style pattern, extracting an arbitrary element from a set that contains one or more elements might look like this: >>> >>> Set s = ... ; >>> if (s instanceof Set.containing(String string, ...)) { // varargs style >>> // use string, which is an arbitrary element >>> } else { >>> // handle failure >>> } >>> >>> This deconstruction pattern addresses a bunch of the design decisions all at once. It handles one or at-least-one element. The preconditions-not-met case is handled by matching failure. Matching failure also sidesteps the issue of whether we return null, return an Optional, or throw an exception. Since pattern matching is inherently conditional, you can't forget to check for null or catch an exception (and you won't have to deal with that darned Optional API). The only thing this doesn't handle is removing an element. I don't think we want pattern matching to have side effects, and element removal is probably pretty rare. But we can still discuss whether it's a valuable case to support. >>> >>> In summary, I think it's important and useful to have a conversation about use cases, what problems we are trying to achieve, and what we think the code at the call site should look like. That can be used to drive API discussions, such as adding new methods. It can /also/ be used to drive discussion about deconstruction patterns that would be useful to add to collections. Furthermore, since the pattern matching language feature is being designed right now, this discussion can help by providing information of the form "libraries need to be able to do this kind of pattern matching". >>> >>> Thanks. >>> >>> s'marks >>> >>> >>> >>> On 4/28/21 6:23 AM, Henri Tremblay wrote: >>>> Hi, >>>> >>>> (I think the first version of this message never went through, so here it goes just in case) >>>> >>>> I just read quickly the proposal and it made me think about another common issue. I wonder if we could tackle it as well. >>>> I will call it the "find the first element when there is only one" problem. >>>> It happens on unordered collections like a HashSet. It forces to do >>>> >>>> Set s = new HashSet<>(); >>>> if (s.size() == 1) { >>>> return s.iterator().next(); >>>> // or >>>> return s.stream().findFirst().get(); >>>> } >>>> >>>> Which is a lot of ugliness and object instantiations just to get the first element. >>>> I would be nice to have a public T findFirst() directly on Iterable. With a default implementation returning iterator().next(). Things like ArrayList will want to override will return elementData[0]. It would return null when the list is empty. Or NoSuchElementException. >>>> It needs to be polished of course but will that be acceptable? >>>> >>>> Thanks, >>>> Henri > From smarks at openjdk.java.net Sat May 1 00:19:08 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Sat, 1 May 2021 00:19:08 GMT Subject: RFR: 8265356: need code example for getting canonical constructor of a Record [v2] In-Reply-To: References: Message-ID: On Sat, 24 Apr 2021 01:32:45 GMT, Tagir F. Valeev wrote: >> I decided to show a complete static method in the example, so it could be copied to user utility class as is. Not sure if it's reasonable to add `assert cls.isRecord();` there. Also I don't know whether there's a limitation on max characters in the sample code. Probable a line break in `static \nConstructor getCanonicalConstructor(Class cls)` is unnecessary. >> >> --- >> Aside from this PR, I've found a couple of things to clean up in `java.lang.Class`: >> 1. There's erroneous JavaDoc link in `getSimpleName()` JavaDoc (introduced by @jddarcy in #3038). It should be `#isArray()` instead of `isArray()`. >> 2. Methods Atomic::casAnnotationType and Atomic::casAnnotationData have unused type parameters ``. >> 3. Probably too much but AnnotationData can be nicely converted to a record! Not sure, probably nobody wants to have `java.lang.Record` initialized too early or increasing the footprint of such a basic class in the metaspace, so I don't insist on this. >> >> >> private record AnnotationData( >> Map, Annotation> annotations, >> Map, Annotation> declaredAnnotations, >> // Value of classRedefinedCount when we created this AnnotationData instance >> int redefinedCount) { >> } >> >> >> Please tell me if it's ok to fix 1 and 2 along with this PR. > > Tagir F. Valeev has updated the pull request incrementally with three additional commits since the last revision: > > - Trailing space removed > - Add a reference from java.lang.Record to related Class methods > - Fix cosmetic issues Overall looks fine modulo adding `@apiNote`. Since the changes are all either editorial/markup or informational, I don't think this needs a CSR. Well, the removal of an unused type variable strictly constitutes a signature change, but those methods aren't public APIs so I still think it's ok without a CSR. src/java.base/share/classes/java/lang/Class.java line 2363: > 2361: * Conversely, if {@link #isRecord()} returns {@code true}, then this method > 2362: * returns a non-null value. > 2363: * I forgot to mention, this example should be within an `@apiNote`. ------------- Marked as reviewed by smarks (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3556 From amaembo at gmail.com Sat May 1 01:25:18 2021 From: amaembo at gmail.com (Tagir Valeev) Date: Sat, 1 May 2021 08:25:18 +0700 Subject: New convenience methods on Stream In-Reply-To: References: Message-ID: Hello! 1. toCollection looks too specific to be added to JDK. Essentially, it's a shortcut for toCollection constructor and unlike toList, it cannot add many optimizations there. So we basically save several characters and nothing more. And toCollection collector is orders of magnitude less used than toList. I think that it's even less used than joining or groupingBy, so why not providing these shortcuts first? It's always about where to draw a line. 2. to() sounds quite specific, as it expects that the target object is ready to accept an array. But why? Probably its API more suitable to accept a collection as an input? It's essentially 'toArrayAndThen' (similar to 'collectingAndThen' collector). There's a suggestion [1] to add transform() method to stream which is much more general, and can be used like `stream.transform(s -> Arrays.asList(s.toArray()))`. Note that collection libraries may provide ready methods that supply the lambdas specific to this library, and this allows to encapsulate the exact implementation detail, like whether we need an array or something else as an intermediate step, like: class MyCustomCollection { ... static Function, MyCustomCollection> toMyCustomCollection() { return s -> createMyCustomCollectionFromStream((T[])s.toArray()); // in the next version we may change to for-each version if we find that it's more performant // or s -> {var c = new MyCustomCollection(); s.forEach(c::add); return c;} } } And use `stream.transform(MyCustomCollection.toMyCustomCollection())` without caring whether it's array or something else in-between. Finally, adding a `(T[])` cast to the standard library sounds a bad idea. Imagine if the custom collection has a fixed element type: class MyStringCollection implements Collection { public MyStringCollection(String[] array) {...} } It looks like stream.to(MyStringCollection::new) should work but in fact, it will throw a ClassCastException 3. into() sounds more interesting as it's indeed useful to dump the stream into an existing collection. It's mostly useful if the collection is non-empty, as you can append into single collection from existing sources. Essentially, into(c) == forEach(c::add), but it's also possible to add optimizations for specific collections (like `if (isSizedStream() && c instanceof ArrayList al) { al.ensureCapacity(...); }`), so it could be faster. With best regards, Tagir Valeev [1] https://bugs.openjdk.java.net/browse/JDK-8140283 On Thu, Apr 29, 2021 at 5:58 AM Donald Raab wrote: > > I looked through a few libraries and found some methods where the option #2 proposal for Steam might be useful. If the JDK had constructors for ArrayList, HashSet and other collection types that take arrays this method would work there as well. > > > default > R to(Function function) > > { > > return function.apply((T[]) this.toArray()); > > } > > > // JDK > Set set = stream.to(Set::of); > List list = stream.to(List::of); > List arraysAsList = stream.to(Arrays::asList); > > // Guava > ArrayList arrayList = stream.to(Lists::newArrayList); > HashSet hashSet = stream.to(Sets::newHashSet); > Multiset multiset = stream.to(ImmutableMultiset::copyOf); > List guavaList = stream.to(ImmutableList::copyOf); > Set guavaSet = stream.to(ImmutableSet::copyOf); > > // Apache Commons Collections > FluentIterable fluentIterable = stream.to(FluentIterable::of); > > // Eclipse Collections > MutableList adapter = stream.to(ArrayAdapter::adapt); > > MutableList mutableList = stream.to(Lists.mutable::with); > MutableSet mutableSet = stream.to(Sets.mutable::with); > MutableBag mutableBag = stream.to(Bags.mutable::with); > > // Eclipse Collections - ListIterable, SetIterable and Bag all extend Iterable, not Collection > ListIterable listIterable = stream.to(Lists.mutable::with); > SetIterable setIterable = stream.to(Sets.mutable::with); > Bag bag = stream.to(Bags.mutable::with); > > // Eclipse Collections - Immutable Collections do not extend Collection > ImmutableList immutableList = stream.to(Lists.immutable::with); > ImmutableSet immutableSet = stream.to(Sets.immutable::with); > ImmutableBag immutableBag = stream.to(Bags.immutable::with); > > // Eclipse Collections - Stack does not extend Collection > StackIterable stackIterable = stream.to(Stacks.mutable::with); > MutableStack mutableStack = stream.to(Stacks.mutable::with); > ImmutableStack immutableStack = stream.to(Stacks.immutable::with); > > // Eclipse Collections - Mutable Map and MutableBiMap are both Iterable so they are valid returns > MutableMap map = > stream.to(array -> ArrayAdapter.adapt(array) > .toMap(String::toLowerCase, String::toUpperCase)); > > MutableBiMap biMap = > stream.to(array -> ArrayAdapter.adapt(array) > .toBiMap(String::toLowerCase, String::toUpperCase)); > > Thanks, > Don > > > On Apr 27, 2021, at 1:35 AM, Donald Raab wrote: > > > > I realized after sending that option 2 can be made more abstract: > > > > default > R to(Function function) > > { > > return function.apply((T[]) this.toArray()); > > } > > > >> > >> 2. Pass the result of toArray directly into a function that can then return a Collection. This should work with Set.of, List.of and any 3rd party collections which take arrays. > >> > >> default > R to(Function function) > >> { > >> return function.apply((T[]) this.toArray()); > >> } > >> > >> Usage Examples: > >> > >> Set set = stream.to(Set::of); > >> List list = stream.to(List::of); > >> List arrayList = stream.to(Arrays::asList); > >> > > > From almatvee at openjdk.java.net Sat May 1 04:04:17 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Sat, 1 May 2021 04:04:17 GMT Subject: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files In-Reply-To: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> References: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> Message-ID: <8VfXOjKyoCsZLhRVGTlXT3LM-MxSNo8IUaVZcE4y4Ro=.63e42d46-3bfb-420a-b234-f789877cf40a@github.com> On Fri, 30 Apr 2021 04:22:37 GMT, Alexander Matveev wrote: > jpackage should specify architecture for produced PKG files via hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable on x64 without specifying hostArchitectures which is not correct and if install on arm Mac it will request Rosetta 2. With proposed fix by setting hostArchitectures="x86_x64" if installer contains x64 binaries, it will be installable on x64 Mac and will require Rosetta 2 on arm Mac. hostArchitectures will be set to arm64 if installer contain aarch64 binaries and will gave error when run on x64 Mac and will be installable on arm Mac without triggering installation of Rosetta 2. Added HostArchPkgTest test to verify hostArchitectures attribute. ------------- PR: https://git.openjdk.java.net/jdk/pull/3807 From almatvee at openjdk.java.net Sat May 1 04:04:17 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Sat, 1 May 2021 04:04:17 GMT Subject: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v2] In-Reply-To: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> References: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> Message-ID: <5YPQQNYy5mwffBKFNKOMl3MQcQG5j3WwuXwRa84PDLY=.54528138-1b33-42b5-91fd-10c7edc67ced@github.com> > jpackage should specify architecture for produced PKG files via hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable on x64 without specifying hostArchitectures which is not correct and if install on arm Mac it will request Rosetta 2. With proposed fix by setting hostArchitectures="x86_x64" if installer contains x64 binaries, it will be installable on x64 Mac and will require Rosetta 2 on arm Mac. hostArchitectures will be set to arm64 if installer contain aarch64 binaries and will gave error when run on x64 Mac and will be installable on arm Mac without triggering installation of Rosetta 2. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8266179: [macos] jpackage should specify architecture for produced pkg files [v2] ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3807/files - new: https://git.openjdk.java.net/jdk/pull/3807/files/1937e9e1..11d9a2cf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3807&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3807&range=00-01 Stats: 96 lines in 2 files changed: 94 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3807.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3807/head:pull/3807 PR: https://git.openjdk.java.net/jdk/pull/3807 From tvaleev at openjdk.java.net Sat May 1 07:34:16 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Sat, 1 May 2021 07:34:16 GMT Subject: RFR: 8265356: need code example for getting canonical constructor of a Record [v3] In-Reply-To: References: Message-ID: <4blKJVgsh-hpY5beMCVLiBNTXMg8Fz33TPOGul5-u_Q=.fe21f12d-0a8d-4e89-81b1-8591f006d801@github.com> > I decided to show a complete static method in the example, so it could be copied to user utility class as is. Not sure if it's reasonable to add `assert cls.isRecord();` there. Also I don't know whether there's a limitation on max characters in the sample code. Probable a line break in `static \nConstructor getCanonicalConstructor(Class cls)` is unnecessary. > > --- > Aside from this PR, I've found a couple of things to clean up in `java.lang.Class`: > 1. There's erroneous JavaDoc link in `getSimpleName()` JavaDoc (introduced by @jddarcy in #3038). It should be `#isArray()` instead of `isArray()`. > 2. Methods Atomic::casAnnotationType and Atomic::casAnnotationData have unused type parameters ``. > 3. Probably too much but AnnotationData can be nicely converted to a record! Not sure, probably nobody wants to have `java.lang.Record` initialized too early or increasing the footprint of such a basic class in the metaspace, so I don't insist on this. > > > private record AnnotationData( > Map, Annotation> annotations, > Map, Annotation> declaredAnnotations, > // Value of classRedefinedCount when we created this AnnotationData instance > int redefinedCount) { > } > > > Please tell me if it's ok to fix 1 and 2 along with this PR. Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: Use @apiNote; this method -> the following method ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3556/files - new: https://git.openjdk.java.net/jdk/pull/3556/files/1133ab7d..86cac681 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3556&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3556&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3556.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3556/head:pull/3556 PR: https://git.openjdk.java.net/jdk/pull/3556 From tvaleev at openjdk.java.net Sat May 1 07:34:17 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Sat, 1 May 2021 07:34:17 GMT Subject: RFR: 8265356: need code example for getting canonical constructor of a Record [v2] In-Reply-To: References: Message-ID: <0P9F9585Pj6W51ESQmDb1HkhpJW9ThmjWnYsTYHcoM4=.a12da5c6-3776-44bb-8f4e-abe6c171a933@github.com> On Sat, 24 Apr 2021 01:32:45 GMT, Tagir F. Valeev wrote: >> I decided to show a complete static method in the example, so it could be copied to user utility class as is. Not sure if it's reasonable to add `assert cls.isRecord();` there. Also I don't know whether there's a limitation on max characters in the sample code. Probable a line break in `static \nConstructor getCanonicalConstructor(Class cls)` is unnecessary. >> >> --- >> Aside from this PR, I've found a couple of things to clean up in `java.lang.Class`: >> 1. There's erroneous JavaDoc link in `getSimpleName()` JavaDoc (introduced by @jddarcy in #3038). It should be `#isArray()` instead of `isArray()`. >> 2. Methods Atomic::casAnnotationType and Atomic::casAnnotationData have unused type parameters ``. >> 3. Probably too much but AnnotationData can be nicely converted to a record! Not sure, probably nobody wants to have `java.lang.Record` initialized too early or increasing the footprint of such a basic class in the metaspace, so I don't insist on this. >> >> >> private record AnnotationData( >> Map, Annotation> annotations, >> Map, Annotation> declaredAnnotations, >> // Value of classRedefinedCount when we created this AnnotationData instance >> int redefinedCount) { >> } >> >> >> Please tell me if it's ok to fix 1 and 2 along with this PR. > > Tagir F. Valeev has updated the pull request incrementally with three additional commits since the last revision: > > - Trailing space removed > - Add a reference from java.lang.Record to related Class methods > - Fix cosmetic issues Thank you! I also changed 'This method' to 'The following method', as it looks like this wording is more commonly used in OpenJDK specs. ------------- PR: https://git.openjdk.java.net/jdk/pull/3556 From tvaleev at openjdk.java.net Sat May 1 07:34:18 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Sat, 1 May 2021 07:34:18 GMT Subject: Integrated: 8265356: need code example for getting canonical constructor of a Record In-Reply-To: References: Message-ID: On Sat, 17 Apr 2021 08:55:59 GMT, Tagir F. Valeev wrote: > I decided to show a complete static method in the example, so it could be copied to user utility class as is. Not sure if it's reasonable to add `assert cls.isRecord();` there. Also I don't know whether there's a limitation on max characters in the sample code. Probable a line break in `static \nConstructor getCanonicalConstructor(Class cls)` is unnecessary. > > --- > Aside from this PR, I've found a couple of things to clean up in `java.lang.Class`: > 1. There's erroneous JavaDoc link in `getSimpleName()` JavaDoc (introduced by @jddarcy in #3038). It should be `#isArray()` instead of `isArray()`. > 2. Methods Atomic::casAnnotationType and Atomic::casAnnotationData have unused type parameters ``. > 3. Probably too much but AnnotationData can be nicely converted to a record! Not sure, probably nobody wants to have `java.lang.Record` initialized too early or increasing the footprint of such a basic class in the metaspace, so I don't insist on this. > > > private record AnnotationData( > Map, Annotation> annotations, > Map, Annotation> declaredAnnotations, > // Value of classRedefinedCount when we created this AnnotationData instance > int redefinedCount) { > } > > > Please tell me if it's ok to fix 1 and 2 along with this PR. This pull request has now been integrated. Changeset: 3e667cc4 Author: Tagir F. Valeev URL: https://git.openjdk.java.net/jdk/commit/3e667cc40521dfb6d07dda07c2f33e37086ee64b Stats: 24 lines in 2 files changed: 17 ins; 0 del; 7 mod 8265356: need code example for getting canonical constructor of a Record Reviewed-by: smarks ------------- PR: https://git.openjdk.java.net/jdk/pull/3556 From kbarrett at openjdk.java.net Sat May 1 09:48:53 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 1 May 2021 09:48:53 GMT Subject: RFR: 8254598: StringDedupTable should use OopStorage In-Reply-To: References: Message-ID: On Sun, 25 Apr 2021 17:32:51 GMT, Zhengyu Gu wrote: >> Please review this change to the String Deduplication facility. It is being >> changed to use OopStorage to hold weak references to relevant objects, >> rather than bespoke data structures requiring dedicated processing phases by >> supporting GCs. >> >> (The Shenandoah update was contributed by Zhengyu Gu.) >> >> This change significantly simplifies the interface between a given GC and >> the String Deduplication facility, which should make it much easier for >> other GCs to opt in. However, this change does not alter the set of GCs >> providing support; currently only G1 and Shenandoah support string >> deduplication. Adding support by other GCs will be in followup RFEs. >> >> Reviewing via the diffs might not be all that useful for some parts, as >> several files have been essentially completely replaced, and a number of >> files have been added or eliminated. The full webrev might be a better >> place to look. >> >> The major changes are in gc/shared/stringdedup/* and in the supporting >> collectors, but there are also some smaller changes in other places, most >> notably classfile/{stringTable,javaClasses}. >> >> This change is additionally labeled for review by core-libs, although there >> are no source changes there. This change injects a byte field of bits into >> java.lang.String, using one of the previously unused padding bytes in that >> class. (There were two unused bytes, now only one.) >> >> Testing: >> mach5 tier1-2 with and without -XX:+UseStringDeduplication >> >> Locally (linux-x64) ran all of the existing tests that use string >> deduplication with both G1 and Shenandoah. Note that >> TestStringDeduplicationInterned.java is disabled for shenandoah, as it >> currently fails, for reasons I haven't figured out but suspect are test >> related. >> >> - gc/stringdedup/ -- these used to be in gc/g1 >> - runtime/cds/SharedStringsDedup.java >> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java >> - runtime/cds/appcds/sharedStrings/* >> >> shenandoah-only: >> - gc/shenandoah/jvmti/TestHeapDump.java >> - gc/shenandoah/TestStringDedup.java >> - gc/shenandoah/TestStringDedupStress.java >> >> Performance tested baseline, baseline + stringdedup, new with stringdedup, >> finding no significant differences. > > src/hotspot/share/classfile/stringTable.cpp line 355: > >> 353: // Notify deduplication support that the string is being interned. A string >> 354: // must never be deduplicated after it has been interned. Doing so interferes >> 355: // with compiler optimizations don on e.g. interned string literals. > > typo: don -> done Fixed locally. ------------- PR: https://git.openjdk.java.net/jdk/pull/3662 From kbarrett at openjdk.java.net Sat May 1 09:48:52 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 1 May 2021 09:48:52 GMT Subject: RFR: 8254598: StringDedupTable should use OopStorage In-Reply-To: <4YgAwCoXuOzm1572oV0RKg3zIpkjr-KtAMmsCVEztoY=.7b93caa9-27f5-4e7e-813d-0ecfa8724043@github.com> References: <4YgAwCoXuOzm1572oV0RKg3zIpkjr-KtAMmsCVEztoY=.7b93caa9-27f5-4e7e-813d-0ecfa8724043@github.com> Message-ID: On Tue, 27 Apr 2021 22:30:04 GMT, Coleen Phillimore wrote: >> Please review this change to the String Deduplication facility. It is being >> changed to use OopStorage to hold weak references to relevant objects, >> rather than bespoke data structures requiring dedicated processing phases by >> supporting GCs. >> >> (The Shenandoah update was contributed by Zhengyu Gu.) >> >> This change significantly simplifies the interface between a given GC and >> the String Deduplication facility, which should make it much easier for >> other GCs to opt in. However, this change does not alter the set of GCs >> providing support; currently only G1 and Shenandoah support string >> deduplication. Adding support by other GCs will be in followup RFEs. >> >> Reviewing via the diffs might not be all that useful for some parts, as >> several files have been essentially completely replaced, and a number of >> files have been added or eliminated. The full webrev might be a better >> place to look. >> >> The major changes are in gc/shared/stringdedup/* and in the supporting >> collectors, but there are also some smaller changes in other places, most >> notably classfile/{stringTable,javaClasses}. >> >> This change is additionally labeled for review by core-libs, although there >> are no source changes there. This change injects a byte field of bits into >> java.lang.String, using one of the previously unused padding bytes in that >> class. (There were two unused bytes, now only one.) >> >> Testing: >> mach5 tier1-2 with and without -XX:+UseStringDeduplication >> >> Locally (linux-x64) ran all of the existing tests that use string >> deduplication with both G1 and Shenandoah. Note that >> TestStringDeduplicationInterned.java is disabled for shenandoah, as it >> currently fails, for reasons I haven't figured out but suspect are test >> related. >> >> - gc/stringdedup/ -- these used to be in gc/g1 >> - runtime/cds/SharedStringsDedup.java >> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java >> - runtime/cds/appcds/sharedStrings/* >> >> shenandoah-only: >> - gc/shenandoah/jvmti/TestHeapDump.java >> - gc/shenandoah/TestStringDedup.java >> - gc/shenandoah/TestStringDedupStress.java >> >> Performance tested baseline, baseline + stringdedup, new with stringdedup, >> finding no significant differences. > > src/hotspot/share/classfile/javaClasses.inline.hpp line 77: > >> 75: >> 76: uint8_t* java_lang_String::flags_addr(oop java_string) { >> 77: assert(_initialized, "Mut be initialized"); > > typo: must Fixed locally. > src/hotspot/share/runtime/globals.hpp line 1994: > >> 1992: \ >> 1993: product(uint64_t, StringDeduplicationHashSeed, 0, DIAGNOSTIC, \ >> 1994: "Seed for the table hashing function; 0 requests computed seed") \ > > Should these two really be develop() options? StringDeduplicationResizeALot is used by a test that we want to run against release builds too. If StringDeduplicationHashSeed isn't a diagnostic option (so available in release builds), I'd be more inclined to just remove it than to make it a develop option. > src/hotspot/share/runtime/mutexLocker.cpp line 239: > >> 237: def(StringDedupQueue_lock , PaddedMonitor, leaf, true, _safepoint_check_never); >> 238: def(StringDedupTable_lock , PaddedMutex , leaf + 1, true, _safepoint_check_never); >> 239: } > > Why weren't these duplicate definitions? This is disturbing. These are assignments, not definitions. Only one of the assignments was being performed because only one of G1 or Shenandoah will be selected. (Not that it matters anymore after this change.) ------------- PR: https://git.openjdk.java.net/jdk/pull/3662 From kbarrett at openjdk.java.net Sat May 1 09:48:53 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 1 May 2021 09:48:53 GMT Subject: RFR: 8254598: StringDedupTable should use OopStorage In-Reply-To: References: <4YgAwCoXuOzm1572oV0RKg3zIpkjr-KtAMmsCVEztoY=.7b93caa9-27f5-4e7e-813d-0ecfa8724043@github.com> Message-ID: <4phWY5RsYDtwmG0Ap_8qV4SID8wKxYi3lUFSBg8NLHg=.da925bdc-2808-436c-a471-ba35519bb590@github.com> On Wed, 28 Apr 2021 00:29:23 GMT, Ioi Lam wrote: >> src/hotspot/share/classfile/stringTable.cpp line 784: >> >>> 782: SharedStringIterator iter(f); >>> 783: _shared_table.iterate(&iter); >>> 784: } >> >> So with this change (somewhere below) do you no longer deduplicate strings from the shared string table? ie >> >> // The CDS archive does not include the string deduplication table. Only the string >> // table is saved in the archive. The shared strings from CDS archive need to be >> // added to the string deduplication table before deduplication occurs. That is >> // done in the beginning of the StringDedupThread (see StringDedupThread::do_deduplication()). >> void StringDedupThread::deduplicate_shared_strings(StringDedupStat* stat) { >> StringDedupSharedClosure sharedStringDedup(stat); >> StringTable::shared_oops_do(&sharedStringDedup); >> } >> Asking @iklam to have a look then. > > If I understand correctly, we no longer need to add the entire set of shared strings into the dedup table. > > > +// As a space optimization, when shared StringTable entries exist the shared > +// part of the StringTable is also used as a source for byte arrays. This > +// permits deduplication of strings against those shared entries without > +// recording them in this table too. > +class StringDedup::Table : AllStatic { > > ... > > +void StringDedup::Table::deduplicate(oop java_string) { > + assert(java_lang_String::is_instance(java_string), "precondition"); > + _cur_stat.inc_inspected(); > + if ((StringTable::shared_entry_count() > 0) && > + try_deduplicate_shared(java_string)) { > + return; // Done if deduplicated against shared StringTable. Ioi is correct; we deduplicate "directly" against the shared string table rather than adding the shared strings to the deduplication table. ------------- PR: https://git.openjdk.java.net/jdk/pull/3662 From kbarrett at openjdk.java.net Sat May 1 09:48:54 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 1 May 2021 09:48:54 GMT Subject: RFR: 8254598: StringDedupTable should use OopStorage In-Reply-To: References: <8yDFk4JdgCTBjvxuLDC1Bkqel_WPwGXibQyU9yyxM0k=.f317ce73-527d-4012-ae50-4142ea0ead76@github.com> Message-ID: On Wed, 28 Apr 2021 06:44:58 GMT, Ioi Lam wrote: >> src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 557: >> >>> 555: // non-latin1, and deduplicating if we find a match. For deduplication we >>> 556: // only care if the arrays consist of the same sequence of bytes. >>> 557: const jchar* chars = static_cast(value->base(T_CHAR)); >> >> The encoding of the shared strings always match CompactStrings. Otherwise the CDS archive will fail to map. E.g., >> >> >> $ java -XX:-CompactStrings -Xshare:dump >> $ java -XX:+CompactStrings -Xlog:cds -version >> ... >> [0.032s][info][cds] UseSharedSpaces: The shared archive file's CompactStrings >> setting (disabled) does not equal the current CompactStrings setting (enabled). >> [0.032s][info][cds] UseSharedSpaces: Unable to map shared spaces >> ... >> >> >> So you can avoid this `if` block when `CompactStrings == true`. The `!java_lang_String::is_latin1(found)` check below can be changed to an assert. >> >> Also, I think we need an explicit test case where you'd return `true` at line 564. I can write a new test case and email to you. I think it will involve dumping an archive with `-XX:-CompactStrings`. > > Oh, I realized that my suggestion above is wrong. When `CompactStrings==true`, you can still have a string whose coder is UTF16: > > https://github.com/openjdk/jdk/blob/75a2354dc276e107d64516d20fc72bc7ef3d5f86/src/java.base/share/classes/java/lang/String.java#L343-L351 Correct. ------------- PR: https://git.openjdk.java.net/jdk/pull/3662 From github.com+3094961+buddyliao at openjdk.java.net Sat May 1 11:37:08 2021 From: github.com+3094961+buddyliao at openjdk.java.net (BuddyLiao) Date: Sat, 1 May 2021 11:37:08 GMT Subject: RFR: 8266193: BasicJMapTest should include testHistoParallel methods Message-ID: <06-HQLQgDE1NeUQ-nPoeF7gKuaeuL1J_YJZwWsPLoAg=.2933c8a7-228d-4502-9057-3554fb07a679@github.com> The testHistoParallel* method are not included in the BasicJMapTest's main() method. They should be included. ------------- Commit messages: - 8266193: BasicJMapTest should include testHistoParallel methods Changes: https://git.openjdk.java.net/jdk/pull/3810/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3810&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266193 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3810.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3810/head:pull/3810 PR: https://git.openjdk.java.net/jdk/pull/3810 From herrick at openjdk.java.net Sat May 1 12:06:52 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Sat, 1 May 2021 12:06:52 GMT Subject: Integrated: JDK-8266129: tools/jpackage/windows/WinInstallerIconTest.java hangs with fastdebug In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 20:19:25 GMT, Andy Herrick wrote: > JDK-8266129: tools/jpackage/windows/WinInstallerIconTest.java hangs with fastdebug > > just disabling this test when vm.debug This pull request has now been integrated. Changeset: 5c083e85 Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/5c083e8560ce9cc78615e3149a558206724cff53 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod 8266129: tools/jpackage/windows/WinInstallerIconTest.java hangs with fastdebug Reviewed-by: asemenyuk, almatvee ------------- PR: https://git.openjdk.java.net/jdk/pull/3827 From forax at univ-mlv.fr Sat May 1 12:57:39 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 1 May 2021 14:57:39 +0200 (CEST) Subject: ReversibleCollection proposal In-Reply-To: References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com> <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr> <839698479.422241.1619098212148.JavaMail.zimbra@u-pem.fr> <7457433b-0836-f45e-4b51-4c2ecdf7e7da@oracle.com> <427897615.2057286.1619612437790.JavaMail.zimbra@u-pem.fr> Message-ID: <906317823.1426529.1619873859193.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Stuart Marks" > ?: "Remi Forax" > Cc: "core-libs-dev" > Envoy?: Samedi 1 Mai 2021 00:42:10 > Objet: Re: ReversibleCollection proposal >> You did not really answer to the real question, why should i use >> ReversibleCollection instead of a Collection as parameter. >> You said that it's a better type because you can not send a HashSet, but as i >> said, sending a HashSet of 0 or 1 element is perfectly valid. >> For me, we are not far from, it's typechecking for the sake of typechecking. > > I thought I did answer it, but it might have been in response to a different > message > on a different part of the thread. But I'll make the case in a more explicit > fashion > here. > > First, a couple background points related to this: > > - ReversibleCollection is not intended to, and indeed cannot represent all > ordered > collections. Queue is ordered and is not a ReversibleCollection, and there are > likely other collections out there that are ordered but that implement > Collection > directly. Also, they might or might not be reversible. > > - I expect that few, if any Java SE APIs will be adjusted to use > ReversibleCollection as a parameter type. Any APIs that use Collection but > require > an ordered type cannot be changed because of compatibility reasons. > > Despite both of these points, I believe ReversibleCollection can be successful, > and > it can be useful in APIs as a parameter type. (The proposal itself uses > ReversibleCollection and ReversibleSet as method return types.) > > Consider the case of a large application or other system, one that's large > enough to > have lots of internal APIs, but that is built as a single unit, so > release-to-release compatibility isn't an issue. Suppose there is some method > > processItemsInOrder(List items) > > that has to process items in the order in which they occur, because processing > of > later items might depend the processing of earlier ones. The maintainer of this > API > chose to accept a List as a parameter, because it's a common interface and it's > clearly an ordered collection. > > Now consider a client that gets items from different places, keeping them in > order, > but removing duplicates. It might do something like this: > > var items = new LinkedHashSet(); > items.addAll(getItemsFromSomeplace()); > items.addAll(getItemsFromAnotherPlace()); > items.addAll(getItemsFromSomeplaceElse()); > processItemsInOrder(new ArrayList<>(items)); > > It turns out the copying of the items into an ArrayList is a performance > bottleneck, > so the maintainer of the client code asks the maintainer of the items processing > code to change the API to accept Collection instead. > > The items processing maintainer demurs, recalling that the API *did* accept > Collection in the past, and a bug where somebody accidentally passed a HashSet > resulted in a customer escalation because of item processing irregularities. In > the > aftermath of that escalation, the API was changed to List. The client maintainer > reluctantly pursues alternatives for generating a deduplicated List. > > But wait! Those Java guys added a ReversibleCollection interface in Java N. It > has > the desired property of being ordered, and conveniently it's a supertype of both > List and LinkedHashSet. The items processing maintainer adjusts the API to > consume > ReversibleCollection, and the client maintainer removes the temporary ArrayList, > and > everybody is happy. I suppose the performance issue comes from the fact that traversing a LinkedHahSet is slow because it's a linked list ? You can replace a LinkedHashSet by a List + Set, the List keeps the values in order, the Set avoids duplicates. Using a Stream, it becomes Stream.of(getItemsFromSomeplace(), getItemsFromAnotherPlace(), getItemsFromSomeplaceElse()) .flatMap(List::stream) .distinct() // use a Set internally .collect(toList()); I think there are maybe some scenarios where ReversibleCollection can be useful, but they are rare, to the point where when there is a good scenario for it people will not recognize it because ReversibleCollection will not be part of their muscle memory. There is a real value to add methods like descendingSet/descendingList()/getFirst/getLast on existing collections, but we don't need a new interface (or two) for that. > > s'marks R?mi From peter.levart at gmail.com Sat May 1 14:36:13 2021 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 1 May 2021 16:36:13 +0200 Subject: [External] : Re: ReversibleCollection proposal In-Reply-To: <0f89b6f8-31e4-bb25-56f2-0a8bbcb6f2ac@oracle.com> References: <38af-60883900-4c5-3a732100@161619996> <056b8d18-3ccf-3dac-d64f-07bd2c586752@gmail.com> <0f89b6f8-31e4-bb25-56f2-0a8bbcb6f2ac@oracle.com> Message-ID: <1360d5bf-cd41-17e2-fb99-0aceb9243795@gmail.com> On 4/30/21 9:25 PM, Stuart Marks wrote: > So I think we're stuck with void-returning add{First,Last} methods. Have you thought of perhaps not adding them at all? Collection.add() for: List(s) - behaves the same as addLast() LinkedHashSet - behaves the same as addLast() Deque - behaves the same as addLast() So for all ReversibleCollection(s) where it works, addLast() would be equivalent to add() addFirst(x) can be written as: reversed().add(x) if reversed() is specified to return a reversed view over the underlying ReversibleCollection. Peter From vromero at openjdk.java.net Sun May 2 02:10:26 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Sun, 2 May 2021 02:10:26 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v6] In-Reply-To: References: Message-ID: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3526/files - new: https://git.openjdk.java.net/jdk/pull/3526/files/2744f615..304fd76a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=04-05 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From iklam at openjdk.java.net Mon May 3 05:28:56 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 3 May 2021 05:28:56 GMT Subject: RFR: 8254598: StringDedupTable should use OopStorage In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 19:48:47 GMT, Kim Barrett wrote: > Please review this change to the String Deduplication facility. It is being > changed to use OopStorage to hold weak references to relevant objects, > rather than bespoke data structures requiring dedicated processing phases by > supporting GCs. > > (The Shenandoah update was contributed by Zhengyu Gu.) > > This change significantly simplifies the interface between a given GC and > the String Deduplication facility, which should make it much easier for > other GCs to opt in. However, this change does not alter the set of GCs > providing support; currently only G1 and Shenandoah support string > deduplication. Adding support by other GCs will be in followup RFEs. > > Reviewing via the diffs might not be all that useful for some parts, as > several files have been essentially completely replaced, and a number of > files have been added or eliminated. The full webrev might be a better > place to look. > > The major changes are in gc/shared/stringdedup/* and in the supporting > collectors, but there are also some smaller changes in other places, most > notably classfile/{stringTable,javaClasses}. > > This change is additionally labeled for review by core-libs, although there > are no source changes there. This change injects a byte field of bits into > java.lang.String, using one of the previously unused padding bytes in that > class. (There were two unused bytes, now only one.) > > Testing: > mach5 tier1-2 with and without -XX:+UseStringDeduplication > > Locally (linux-x64) ran all of the existing tests that use string > deduplication with both G1 and Shenandoah. Note that > TestStringDeduplicationInterned.java is disabled for shenandoah, as it > currently fails, for reasons I haven't figured out but suspect are test > related. > > - gc/stringdedup/ -- these used to be in gc/g1 > - runtime/cds/SharedStringsDedup.java > - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java > - runtime/cds/appcds/sharedStrings/* > > shenandoah-only: > - gc/shenandoah/jvmti/TestHeapDump.java > - gc/shenandoah/TestStringDedup.java > - gc/shenandoah/TestStringDedupStress.java > > Performance tested baseline, baseline + stringdedup, new with stringdedup, > finding no significant differences. The CDS changes look reasonable to me. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3662 From jbhateja at openjdk.java.net Mon May 3 06:51:29 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 3 May 2021 06:51:29 GMT Subject: RFR: 8266054: VectorAPI rotate operation optimization [v3] In-Reply-To: References: Message-ID: > Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:- > > vec1 = lanewise(VectorOperators.LSHL, n) > vec2 = lanewise(VectorOperators.LSHR, n) > res = lanewise(VectorOperations.OR, vec1 , vec2) > > This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction. > > AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations ) instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted. > > Please find below the performance data for included JMH benchmark. > Machine: Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascade lake Server) > > `` > > Benchmark | (TESTSIZE) | Shift | Baseline (ops/ms) | Withopt (ops/ms) | Gain % > -- | -- | -- | -- | -- | -- > RotateBenchmark.testRotateLeftI | (size) | (shift) | 7384.747 | 7706.652 | 4.36 > RotateBenchmark.testRotateLeftI | 64 | 11 | 3723.305 | 3816.968 | 2.52 > RotateBenchmark.testRotateLeftI | 128 | 11 | 1811.521 | 1966.05 | 8.53 > RotateBenchmark.testRotateLeftI | 256 | 11 | 7133.296 | 7715.047 | 8.16 > RotateBenchmark.testRotateLeftI | 64 | 21 | 3612.144 | 3886.225 | 7.59 > RotateBenchmark.testRotateLeftI | 128 | 21 | 1815.422 | 1962.753 | 8.12 > RotateBenchmark.testRotateLeftI | 256 | 21 | 7216.353 | 7677.165 | 6.39 > RotateBenchmark.testRotateLeftI | 64 | 31 | 3602.008 | 3892.297 | 8.06 > RotateBenchmark.testRotateLeftI | 128 | 31 | 1882.163 | 1958.887 | 4.08 > RotateBenchmark.testRotateLeftI | 256 | 31 | 11819.443 | 11912.864 | 0.79 > RotateBenchmark.testRotateLeftI | 64 | 11 | 5978.475 | 6060.189 | 1.37 > RotateBenchmark.testRotateLeftI | 128 | 11 | 2965.179 | 3060.969 | 3.23 > RotateBenchmark.testRotateLeftI | 256 | 11 | 11479.579 | 11684.148 | 1.78 > RotateBenchmark.testRotateLeftI | 64 | 21 | 5904.903 | 6094.409 | 3.21 > RotateBenchmark.testRotateLeftI | 128 | 21 | 2969.879 | 3074.1 | 3.51 > RotateBenchmark.testRotateLeftI | 256 | 21 | 11531.654 | 12155.954 | 5.41 > RotateBenchmark.testRotateLeftI | 64 | 31 | 5730.918 | 6112.514 | 6.66 > RotateBenchmark.testRotateLeftI | 128 | 31 | 2937.19 | 2976.297 | 1.33 > RotateBenchmark.testRotateLeftI | 256 | 31 | 16159.184 | 16459.462 | 1.86 > RotateBenchmark.testRotateLeftI | 64 | 11 | 8154.982 | 8396.089 | 2.96 > RotateBenchmark.testRotateLeftI | 128 | 11 | 4142.224 | 4292.049 | 3.62 > RotateBenchmark.testRotateLeftI | 256 | 11 | 15958.154 | 16163.518 | 1.29 > RotateBenchmark.testRotateLeftI | 64 | 21 | 8098.805 | 8504.279 | 5.01 > RotateBenchmark.testRotateLeftI | 128 | 21 | 4137.598 | 4314.868 | 4.28 > RotateBenchmark.testRotateLeftI | 256 | 21 | 16201.666 | 15992.958 | -1.29 > RotateBenchmark.testRotateLeftI | 64 | 31 | 8027.169 | 8484.379 | 5.70 > RotateBenchmark.testRotateLeftI | 128 | 31 | 4146.29 | 4039.681 | -2.57 > RotateBenchmark.testRotateLeftL | 256 | 31 | 3566.176 | 3805.248 | 6.70 > RotateBenchmark.testRotateLeftL | 64 | 11 | 1820.219 | 1962.866 | 7.84 > RotateBenchmark.testRotateLeftL | 128 | 11 | 917.085 | 1007.334 | 9.84 > RotateBenchmark.testRotateLeftL | 256 | 11 | 3592.139 | 3973.698 | 10.62 > RotateBenchmark.testRotateLeftL | 64 | 21 | 1827.63 | 1999.711 | 9.42 > RotateBenchmark.testRotateLeftL | 128 | 21 | 907.104 | 1002.997 | 10.57 > RotateBenchmark.testRotateLeftL | 256 | 21 | 3780.962 | 3873.489 | 2.45 > RotateBenchmark.testRotateLeftL | 64 | 31 | 1830.121 | 1955.63 | 6.86 > RotateBenchmark.testRotateLeftL | 128 | 31 | 891.411 | 982.138 | 10.18 > RotateBenchmark.testRotateLeftL | 256 | 31 | 5890.544 | 6100.594 | 3.57 > RotateBenchmark.testRotateLeftL | 64 | 11 | 2984.329 | 3021.971 | 1.26 > RotateBenchmark.testRotateLeftL | 128 | 11 | 1485.109 | 1527.689 | 2.87 > RotateBenchmark.testRotateLeftL | 256 | 11 | 5903.411 | 6083.775 | 3.06 > RotateBenchmark.testRotateLeftL | 64 | 21 | 2925.37 | 3050.958 | 4.29 > RotateBenchmark.testRotateLeftL | 128 | 21 | 1486.432 | 1537.155 | 3.41 > RotateBenchmark.testRotateLeftL | 256 | 21 | 5853.721 | 6000.682 | 2.51 > RotateBenchmark.testRotateLeftL | 64 | 31 | 2896.116 | 3072.783 | 6.10 > RotateBenchmark.testRotateLeftL | 128 | 31 | 1483.132 | 1546.588 | 4.28 > RotateBenchmark.testRotateLeftL | 256 | 31 | 8059.206 | 8218.047 | 1.97 > RotateBenchmark.testRotateLeftL | 64 | 11 | 4022.416 | 4195.52 | 4.30 > RotateBenchmark.testRotateLeftL | 128 | 11 | 2084.296 | 2068.238 | -0.77 > RotateBenchmark.testRotateLeftL | 256 | 11 | 7971.832 | 8172.819 | 2.52 > RotateBenchmark.testRotateLeftL | 64 | 21 | 4032.036 | 4344.469 | 7.75 > RotateBenchmark.testRotateLeftL | 128 | 21 | 2068.957 | 2138.685 | 3.37 > RotateBenchmark.testRotateLeftL | 256 | 21 | 8140.63 | 8003.283 | -1.69 > RotateBenchmark.testRotateLeftL | 64 | 31 | 4088.621 | 4296.091 | 5.07 > RotateBenchmark.testRotateLeftL | 128 | 31 | 2007.753 | 2088.455 | 4.02 > RotateBenchmark.testRotateRightI | 256 | 31 | 7358.793 | 7548.976 | 2.58 > RotateBenchmark.testRotateRightI | 64 | 11 | 3648.868 | 3897.47 | 6.81 > RotateBenchmark.testRotateRightI | 128 | 11 | 1862.73 | 1969.964 | 5.76 > RotateBenchmark.testRotateRightI | 256 | 11 | 7268.806 | 7790.588 | 7.18 > RotateBenchmark.testRotateRightI | 64 | 21 | 3577.79 | 3979.675 | 11.23 > RotateBenchmark.testRotateRightI | 128 | 21 | 1773.243 | 1921.088 | 8.34 > RotateBenchmark.testRotateRightI | 256 | 21 | 7084.974 | 7609.912 | 7.41 > RotateBenchmark.testRotateRightI | 64 | 31 | 3688.781 | 3909.65 | 5.99 > RotateBenchmark.testRotateRightI | 128 | 31 | 1845.978 | 1928.316 | 4.46 > RotateBenchmark.testRotateRightI | 256 | 31 | 11463.228 | 12179.833 | 6.25 > RotateBenchmark.testRotateRightI | 64 | 11 | 5678.052 | 6028.573 | 6.17 > RotateBenchmark.testRotateRightI | 128 | 11 | 2990.419 | 3070.409 | 2.67 > RotateBenchmark.testRotateRightI | 256 | 11 | 11780.283 | 12105.261 | 2.76 > RotateBenchmark.testRotateRightI | 64 | 21 | 5827.8 | 6020.208 | 3.30 > RotateBenchmark.testRotateRightI | 128 | 21 | 2904.852 | 3047.154 | 4.90 > RotateBenchmark.testRotateRightI | 256 | 21 | 11359.146 | 12060.401 | 6.17 > RotateBenchmark.testRotateRightI | 64 | 31 | 5823.207 | 6079.82 | 4.41 > RotateBenchmark.testRotateRightI | 128 | 31 | 2984.484 | 3045.719 | 2.05 > RotateBenchmark.testRotateRightI | 256 | 31 | 16200.504 | 16376.475 | 1.09 > RotateBenchmark.testRotateRightI | 64 | 11 | 8118.399 | 8315.407 | 2.43 > RotateBenchmark.testRotateRightI | 128 | 11 | 4130.745 | 4092.588 | -0.92 > RotateBenchmark.testRotateRightI | 256 | 11 | 15842.168 | 16469.119 | 3.96 > RotateBenchmark.testRotateRightI | 64 | 21 | 7855.164 | 8188.913 | 4.25 > RotateBenchmark.testRotateRightI | 128 | 21 | 4114.378 | 4035.56 | -1.92 > RotateBenchmark.testRotateRightI | 256 | 21 | 15636.117 | 16289.632 | 4.18 > RotateBenchmark.testRotateRightI | 64 | 31 | 8108.067 | 7996.517 | -1.38 > RotateBenchmark.testRotateRightI | 128 | 31 | 3997.547 | 4153.58 | 3.90 > RotateBenchmark.testRotateRightL | 256 | 31 | 3685.99 | 3814.384 | 3.48 > RotateBenchmark.testRotateRightL | 64 | 11 | 1787.875 | 1916.541 | 7.20 > RotateBenchmark.testRotateRightL | 128 | 11 | 940.141 | 990.383 | 5.34 > RotateBenchmark.testRotateRightL | 256 | 11 | 3745.968 | 3920.667 | 4.66 > RotateBenchmark.testRotateRightL | 64 | 21 | 1877.94 | 1998.072 | 6.40 > RotateBenchmark.testRotateRightL | 128 | 21 | 933.536 | 1004.61 | 7.61 > RotateBenchmark.testRotateRightL | 256 | 21 | 3744.763 | 3947.427 | 5.41 > RotateBenchmark.testRotateRightL | 64 | 31 | 1864.818 | 1978.277 | 6.08 > RotateBenchmark.testRotateRightL | 128 | 31 | 906.965 | 998.692 | 10.11 > RotateBenchmark.testRotateRightL | 256 | 31 | 5910.469 | 6062.429 | 2.57 > RotateBenchmark.testRotateRightL | 64 | 11 | 2914.64 | 3033.127 | 4.07 > RotateBenchmark.testRotateRightL | 128 | 11 | 1491.344 | 1543.936 | 3.53 > RotateBenchmark.testRotateRightL | 256 | 11 | 5801.818 | 6098.892 | 5.12 > RotateBenchmark.testRotateRightL | 64 | 21 | 2881.328 | 3089.547 | 7.23 > RotateBenchmark.testRotateRightL | 128 | 21 | 1485.969 | 1526.231 | 2.71 > RotateBenchmark.testRotateRightL | 256 | 21 | 5783.495 | 5957.649 | 3.01 > RotateBenchmark.testRotateRightL | 64 | 31 | 3008.182 | 3026.323 | 0.60 > RotateBenchmark.testRotateRightL | 128 | 31 | 1464.566 | 1546.825 | 5.62 > RotateBenchmark.testRotateRightL | 256 | 31 | 8208.124 | 8361.437 | 1.87 > RotateBenchmark.testRotateRightL | 64 | 11 | 4062.465 | 4319.412 | 6.32 > RotateBenchmark.testRotateRightL | 128 | 11 | 2029.995 | 2086.497 | 2.78 > RotateBenchmark.testRotateRightL | 256 | 11 | 8183.789 | 8193.087 | 0.11 > RotateBenchmark.testRotateRightL | 64 | 21 | 4092.686 | 4193.712 | 2.47 > RotateBenchmark.testRotateRightL | 128 | 21 | 2036.854 | 2038.927 | 0.10 > RotateBenchmark.testRotateRightL | 256 | 21 | 8155.015 | 8175.792 | 0.25 > RotateBenchmark.testRotateRightL | 64 | 31 | 3960.629 | 4263.922 | 7.66 > RotateBenchmark.testRotateRightL | 128 | 31 | 1996.862 | 2055.486 | 2.94 > > `` Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8266054: Review comments resolution. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3720/files - new: https://git.openjdk.java.net/jdk/pull/3720/files/eee407b0..f7945bff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3720&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3720&range=01-02 Stats: 1243 lines in 45 files changed: 297 ins; 693 del; 253 mod Patch: https://git.openjdk.java.net/jdk/pull/3720.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3720/head:pull/3720 PR: https://git.openjdk.java.net/jdk/pull/3720 From jbhateja at openjdk.java.net Mon May 3 06:51:31 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 3 May 2021 06:51:31 GMT Subject: RFR: 8266054: VectorAPI rotate operation optimization [v3] In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 18:43:11 GMT, Paul Sandoz wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8266054: Review comments resolution. > > I noticed the tests are only updated for int and long, is that intentional? The HotSpot changes in some cases seem to imply all integral types are supported via the use of `is_integral_type`, contradicted by the use of `is_subword_type`. > > I would recommend trying to leverage Integer/Long.rotateLeft/Right implementations. They are not available for byte/short, so lets add specific methods in those cases, that should make the Java op implementation clearer. Hi @PaulSandoz , thanks your comments have been addressed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3720 From jbhateja at openjdk.java.net Mon May 3 06:51:37 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 3 May 2021 06:51:37 GMT Subject: RFR: 8266054: VectorAPI rotate operation optimization [v2] In-Reply-To: References: Message-ID: <7W-IJ7OChF3wVhl7g1JNB6m-1GPmNxdJHlFx36HjqxI=.e148a846-29dc-4a27-b15f-3a5898e6e97d@github.com> On Fri, 30 Apr 2021 15:44:41 GMT, Paul Sandoz wrote: >> Jatin Bhateja 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 last revision: >> >> - 8266054: Review comments resolution. >> - Merge http://github.com/openjdk/jdk into JDK-8266054 >> - 8266054: Changing gen-src.sh file permissions >> - 8266054: VectorAPI rotate operation optimization > > src/hotspot/cpu/x86/x86.ad line 1652: > >> 1650: case Op_RotateRightV: >> 1651: case Op_RotateLeftV: >> 1652: if (is_subword_type(bt)) { > > Does that have the effect of not intrinsifying for `byte` or `short`? Yes, it makes sure that intrinsification is based on Shifts and Or operations instead of Rotation operation. ------------- PR: https://git.openjdk.java.net/jdk/pull/3720 From jbachorik at openjdk.java.net Mon May 3 13:00:05 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Mon, 3 May 2021 13:00:05 GMT Subject: RFR: 8203359: Container level resources events [v10] In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 21:20:57 GMT, Erik Gahlin wrote: >> Jaroslav Bachorik 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 revision: >> >> - Prevent event container bytecode generation if no container present >> - Fix event metadata >> - Roll back conditional registration of container events >> - Remove container events flag >> - Remove trailing spaces >> - Doh >> - Report container type and register events conditionally >> - Remove unused test files >> - Initial test support for JFR container events >> - Update the JFR control files >> - ... and 3 more: https://git.openjdk.java.net/jdk/compare/c00a534f...04c3f092 > > src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java line 729: > >> 727: >> 728: public static boolean shouldSkipBytecode(String eventName, Class superClass) { >> 729: if (!superClass.getName().equals("jdk.jfr.events.AbstractJDKEvent")) { > > Was there a problem checking against the class instance? If so, perhaps you could add a check that the class is in the boot class loader (null). Yes, `AbstractJDKEvent` is package private so it is not accessible from here. > src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java line 737: > >> 735: private static Metrics getMetrics() { >> 736: if (metrics == null) { >> 737: metrics = Metrics.systemMetrics(); > > Will this not lead to a lookup every time in an non-container environment? Yes. Now I see why you used `Metrics[]` - will fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/3126 From jbachorik at openjdk.java.net Mon May 3 13:00:10 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Mon, 3 May 2021 13:00:10 GMT Subject: RFR: 8203359: Container level resources events [v10] In-Reply-To: References: Message-ID: <3gzOxOsbNLqkeKohG3BBycP32uUhFuq7bOq4EwXZxC8=.a728a469-e3b7-4318-85d4-730550c043b1@github.com> On Tue, 27 Apr 2021 09:40:01 GMT, Severin Gehwolf wrote: >> Jaroslav Bachorik 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 revision: >> >> - Prevent event container bytecode generation if no container present >> - Fix event metadata >> - Roll back conditional registration of container events >> - Remove container events flag >> - Remove trailing spaces >> - Doh >> - Report container type and register events conditionally >> - Remove unused test files >> - Initial test support for JFR container events >> - Update the JFR control files >> - ... and 3 more: https://git.openjdk.java.net/jdk/compare/3322e9ff...04c3f092 > > test/hotspot/jtreg/containers/docker/TestJFREvents.java line 147: > >> 145: .addClassOptions(eventName, "period=endChunk")) >> 146: .shouldHaveExitValue(0) >> 147: .shouldContain(memoryPressureFld) > > This test fails for me on cgroupv1 with: > > > ----------System.err:(42/1407)---------- > stdout: [===== EventType: jdk.ContainerMemoryUsage > startTime = 946400166 > duration = 0 > eventThread = { > osName = "main" > osThreadId = 6 > javaName = "main" > javaThreadId = 1 > group = { > parent = { > parent = N/A > name = "system" > } > name = "main" > } > } > > stackTrace = null > memoryFailCount = 0 > memoryUsage = 57786368 > swapMemoryUsage = 57782272 > ]; > stderr: [] > exitValue = 0 > > java.lang.RuntimeException: 'memoryPressure' missing from stdout/stderr > > at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:206) > at TestJFREvents.testMemoryUsage(TestJFREvents.java:147) > at TestJFREvents.main(TestJFREvents.java:77) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:568) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:831) > > JavaTest Message: Test threw exception: java.lang.RuntimeException: 'memoryPressure' missing from stdout/stderr > > JavaTest Message: shutting down test > > > I think `memoryPressure` got removed from the code and, thus, should get removed from the test. Will fix ------------- PR: https://git.openjdk.java.net/jdk/pull/3126 From jbachorik at openjdk.java.net Mon May 3 13:16:06 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Mon, 3 May 2021 13:16:06 GMT Subject: RFR: 8203359: Container level resources events [v11] In-Reply-To: References: Message-ID: > With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events. > > Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with. > * CPU related metrics > * Memory related metrics > * I/O related metrics > > For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. > By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently). Jaroslav Bachorik 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 10 additional commits since the last revision: - Small fixes - Remove trailing spaces - Doh - Report container type and register events conditionally - Remove unused test files - Initial test support for JFR container events - Update the JFR control files - Split off the CPU throttling metrics - Formatting spaces - 8203359: Container level resources events ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3126/files - new: https://git.openjdk.java.net/jdk/pull/3126/files/04c3f092..fddd1727 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3126&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3126&range=09-10 Stats: 93348 lines in 2177 files changed: 37265 ins; 49988 del; 6095 mod Patch: https://git.openjdk.java.net/jdk/pull/3126.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3126/head:pull/3126 PR: https://git.openjdk.java.net/jdk/pull/3126 From rriggs at openjdk.java.net Mon May 3 14:51:51 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 3 May 2021 14:51:51 GMT Subject: RFR: 8265248: Implementation Specific Properties: change prefix, plus add existing properties [v3] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 18:22:27 GMT, Joe Wang wrote: >> Update module summary, add a few existing properties and features into the tables. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > replace isAssignableFrom with instanceof Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3644 From asemenyuk at openjdk.java.net Mon May 3 15:34:53 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 3 May 2021 15:34:53 GMT Subject: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v2] In-Reply-To: <5YPQQNYy5mwffBKFNKOMl3MQcQG5j3WwuXwRa84PDLY=.54528138-1b33-42b5-91fd-10c7edc67ced@github.com> References: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> <5YPQQNYy5mwffBKFNKOMl3MQcQG5j3WwuXwRa84PDLY=.54528138-1b33-42b5-91fd-10c7edc67ced@github.com> Message-ID: On Sat, 1 May 2021 04:04:17 GMT, Alexander Matveev wrote: >> jpackage should specify architecture for produced PKG files via hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable on x64 without specifying hostArchitectures which is not correct and if install on arm Mac it will request Rosetta 2. With proposed fix by setting hostArchitectures="x86_x64" if installer contains x64 binaries, it will be installable on x64 Mac and will require Rosetta 2 on arm Mac. hostArchitectures will be set to arm64 if installer contain aarch64 binaries and will gave error when run on x64 Mac and will be installable on arm Mac without triggering installation of Rosetta 2. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8266179: [macos] jpackage should specify architecture for produced pkg files [v2] test/jdk/tools/jpackage/macosx/HostArchPkgTest.java line 84: > 82: } > 83: > 84: public static void main(String[] args) throws Exception { Please don't use direct TKit.run() call. Use jdk.jpackage.test.Annotations.Test annotation for test method. You can use SimplePackageTest jtreg test as an example ------------- PR: https://git.openjdk.java.net/jdk/pull/3807 From jvernee at openjdk.java.net Mon May 3 15:52:52 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 3 May 2021 15:52:52 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 08:19:53 GMT, Nick Gasson wrote: > macOS on Apple silicon uses slightly different ABI conventions to the > standard AArch64 ABI. The differences are outlined in [1]. In > particular in the standard (AAPCS) ABI, variadic arguments may be passed > in either registers or on the stack following the normal calling > convention. To handle this, va_list is a struct containing separate > pointers for arguments located in integer registers, floating point > registers, and on the stack. Apple's ABI simplifies this by passing all > variadic arguments on the stack and the va_list type becomes a simple > char* pointer. > > This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to > represent the new ABI variant on macOS. StackVaList is based on > WinVaList lightly modified to handle the different TypeClasses on > AArch64. The original AArch64Linker is renamed to AapcsLinker and is > currently used for all non-Mac platforms. I think we also need to add a > WinAArch64 CABI but I haven't yet been able to test on a Windows system > so will do that later. > > The macOS ABI also uses a different method of spilling arguments to the > stack (the standard ABI pads each argument to a multiple of 8 byte stack > slots, but the Mac ABI packs arguments according to their natural > alignment). None of the existing tests exercise this so I'll open a new > JBS issue and work on that separately. > > Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. > > [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms I've reviewed, but I don't think this should be integrated right now since it will likely conflict with the JEP implementation, and probably a chunk of StackVaList will have to be re-written to take the ResourceScope changes into account. As a point of process; I think this should have been a PR against the panama-foreign repo instead, which would have avoided this conflict. Probably the best course of action right now is to wait until the JEP is integrated, and then update this PR to take those changes (e.g. ResourceScope, virtual calls) into account. src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/CallArranger.java line 394: > 392: TypeClass argumentClass = TypeClass.classifyLayout(layout); > 393: Binding.Builder bindings = Binding.builder(); > 394: storageCalculator.adjustForVarArgs(layout); We don't support variadic upcalls (or returns) currently, so maybe here we should rather assert that the layout is _not_ annotated with `STACK_VARARGS_ATTRIBUTE_NAME` ? src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64Linker.java line 86: > 84: handle = SharedUtils.unboxVaLists(type, handle, MH_unboxVaList); > 85: return handle; > 86: } Looking at this I realize this version of the code doesn't include the support for virtual calls yet. I think this will break once the JEP is merged (because the overload taking no symbol is not implemented). It might be nice to check what conflicts there are with the JEP beforehand https://github.com/openjdk/jdk/pull/3699 Though, if it's too much, I think the JEP should go first (and then fix up & merge this PR afterwards), since the JEP is usually much more tricky to get in due to the size. Sorry. src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/StackVaList.java line 51: > 49: > 50: /** > 51: * Simplified va_list implementation used on macOS and Windows where all This is not being used on Windows AFAICS? Was that the intention? (FWIW, as long as they are split, I think the VaList impls should be named after their ABI/platform. So, StackVaList would be named MacOsAArch64VaList instead). src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/StackVaList.java line 55: > 53: * char* instead of the structure defined in the AAPCS. > 54: */ > 55: class StackVaList implements VaList { VaList impls were one of the things that were affected a lot by the switch to ResourceScope, so this class will also definitely conflict with the JEP. src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/StackVaList.java line 131: > 129: MemorySegment struct = allocator.allocate(layout); > 130: struct.copyFrom(segment.asSlice(0L, layout.byteSize())); > 131: segment = segment.asSlice(VA_SLOT_SIZE_BYTES); Since arguments are packed according to alignment, I guess the offset could be larger or smaller than 8 bytes as well? src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/StackVaList.java line 139: > 137: VarHandle reader = SharedUtils.vhPrimitiveOrAddress(carrier, layout); > 138: res = reader.get(segment); > 139: segment = segment.asSlice(VA_SLOT_SIZE_BYTES); Same here I guess. src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/StackVaList.java line 243: > 241: > 242: // Each argument may occupy up to four slots > 243: MemorySegment segment = allocator.allocate(VA_SLOT_SIZE_BYTES * args.size() * 4); This seems to confirm that always offsetting by VA_SLOT_SIZE_BYTES in the read and write code can be problematic, if arguments can occupy up to 4 slots, always offsetting the read/write cursor by one slot seems incorrect. ------------- PR: https://git.openjdk.java.net/jdk/pull/3617 From jvernee at openjdk.java.net Mon May 3 15:52:52 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 3 May 2021 15:52:52 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 02:14:07 GMT, Nick Gasson wrote: >> How about StandardAArch64Linker? Otherwise MacOsAArch64Linker sounds like it should be a specialisation of AArch64Linker. > > Or LinuxAArch64Linker if we're going to rename the CABI enum AArch64 -> LinuxAArch64? But this would also be used on other OSs that use the Arm ABI spec as-is (e.g. *BSD). I think `LinuxAArch64Linker` makes the most sense, on the assumption that the Windows AArch64 ABI is different enough to warrent another enum value & linker impl. ------------- PR: https://git.openjdk.java.net/jdk/pull/3617 From jvernee at openjdk.java.net Mon May 3 15:52:53 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 3 May 2021 15:52:53 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 14:30:17 GMT, Maurizio Cimadamore wrote: >> macOS on Apple silicon uses slightly different ABI conventions to the >> standard AArch64 ABI. The differences are outlined in [1]. In >> particular in the standard (AAPCS) ABI, variadic arguments may be passed >> in either registers or on the stack following the normal calling >> convention. To handle this, va_list is a struct containing separate >> pointers for arguments located in integer registers, floating point >> registers, and on the stack. Apple's ABI simplifies this by passing all >> variadic arguments on the stack and the va_list type becomes a simple >> char* pointer. >> >> This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to >> represent the new ABI variant on macOS. StackVaList is based on >> WinVaList lightly modified to handle the different TypeClasses on >> AArch64. The original AArch64Linker is renamed to AapcsLinker and is >> currently used for all non-Mac platforms. I think we also need to add a >> WinAArch64 CABI but I haven't yet been able to test on a Windows system >> so will do that later. >> >> The macOS ABI also uses a different method of spilling arguments to the >> stack (the standard ABI pads each argument to a multiple of 8 byte stack >> slots, but the Mac ABI packs arguments according to their natural >> alignment). None of the existing tests exercise this so I'll open a new >> JBS issue and work on that separately. >> >> Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. >> >> [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms > > src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/aapcs/AapcsVaList.java line 54: > >> 52: * Linux. Variadic parameters may be passed in registers or on the stack. >> 53: */ >> 54: public class AapcsVaList implements VaList { > > Same here - not sure I like Aapcs much Right, `LinuxAArch64VaList` seems right here to me to keep consistency. ------------- PR: https://git.openjdk.java.net/jdk/pull/3617 From jvernee at openjdk.java.net Mon May 3 15:52:53 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 3 May 2021 15:52:53 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native In-Reply-To: References: Message-ID: <3KN4x4CVsGIJMhA7Z81hMYgQ_cj3h29ZjwwLjmKL2Cg=.fc35968a-3825-40ee-b97a-130541b9574e@github.com> On Mon, 3 May 2021 15:31:53 GMT, Jorn Vernee wrote: >> macOS on Apple silicon uses slightly different ABI conventions to the >> standard AArch64 ABI. The differences are outlined in [1]. In >> particular in the standard (AAPCS) ABI, variadic arguments may be passed >> in either registers or on the stack following the normal calling >> convention. To handle this, va_list is a struct containing separate >> pointers for arguments located in integer registers, floating point >> registers, and on the stack. Apple's ABI simplifies this by passing all >> variadic arguments on the stack and the va_list type becomes a simple >> char* pointer. >> >> This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to >> represent the new ABI variant on macOS. StackVaList is based on >> WinVaList lightly modified to handle the different TypeClasses on >> AArch64. The original AArch64Linker is renamed to AapcsLinker and is >> currently used for all non-Mac platforms. I think we also need to add a >> WinAArch64 CABI but I haven't yet been able to test on a Windows system >> so will do that later. >> >> The macOS ABI also uses a different method of spilling arguments to the >> stack (the standard ABI pads each argument to a multiple of 8 byte stack >> slots, but the Mac ABI packs arguments according to their natural >> alignment). None of the existing tests exercise this so I'll open a new >> JBS issue and work on that separately. >> >> Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. >> >> [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms > > src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/StackVaList.java line 131: > >> 129: MemorySegment struct = allocator.allocate(layout); >> 130: struct.copyFrom(segment.asSlice(0L, layout.byteSize())); >> 131: segment = segment.asSlice(VA_SLOT_SIZE_BYTES); > > Since arguments are packed according to alignment, I guess the offset could be larger or smaller than 8 bytes as well? This is using `alignUp(arg.layout.byteSize(), VA_SLOT_SIZE_BYTES)` in the writing code, so I think it should be the same here? ------------- PR: https://git.openjdk.java.net/jdk/pull/3617 From asemenyuk at openjdk.java.net Mon May 3 16:04:53 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 3 May 2021 16:04:53 GMT Subject: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v2] In-Reply-To: <5YPQQNYy5mwffBKFNKOMl3MQcQG5j3WwuXwRa84PDLY=.54528138-1b33-42b5-91fd-10c7edc67ced@github.com> References: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> <5YPQQNYy5mwffBKFNKOMl3MQcQG5j3WwuXwRa84PDLY=.54528138-1b33-42b5-91fd-10c7edc67ced@github.com> Message-ID: On Sat, 1 May 2021 04:04:17 GMT, Alexander Matveev wrote: >> jpackage should specify architecture for produced PKG files via hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable on x64 without specifying hostArchitectures which is not correct and if install on arm Mac it will request Rosetta 2. With proposed fix by setting hostArchitectures="x86_x64" if installer contains x64 binaries, it will be installable on x64 Mac and will require Rosetta 2 on arm Mac. hostArchitectures will be set to arm64 if installer contain aarch64 binaries and will gave error when run on x64 Mac and will be installable on arm Mac without triggering installation of Rosetta 2. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8266179: [macos] jpackage should specify architecture for produced pkg files [v2] Changes requested by asemenyuk (Reviewer). test/jdk/tools/jpackage/macosx/HostArchPkgTest.java line 55: > 53: > 54: private static void verifyHostArch(JPackageCommand cmd) throws Exception { > 55: Path distributionFile = cmd.unpackedPackageDirectory() I think `cmd.pathToUnpackedPackageFile("/")` would be the equivalent to `cmd.unpackedPackageDirectory()`. If it is, there would be no need for changes to JPackageCommand. test/jdk/tools/jpackage/macosx/HostArchPkgTest.java line 57: > 55: Path distributionFile = cmd.unpackedPackageDirectory() > 56: .toAbsolutePath() > 57: .getParent() Why .getParent() is needed here? ------------- PR: https://git.openjdk.java.net/jdk/pull/3807 From jlaskey at openjdk.java.net Mon May 3 16:37:49 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 3 May 2021 16:37:49 GMT Subject: RFR: 8260621: Avoid memory leak in ImageBufferCache [v2] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 01:29:02 GMT, Bo Zhang wrote: >> Previously, `ImageBufferCache` contains a ThreadLocal field which holds >> strong reference to `ImageBufferCache$BufferReference.class`. When loaded >> from `jrt-fs.jar`, this will keep `JrtFileSystemProvider$JrtFsLoader` >> in memory forever and never being GCed. >> >> The fix replace the old `ImageBufferCache$BufferReference` class with >> `WeakReference`, which is verified by provided test. > > Bo Zhang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. An alternate approach is pending. ------------- Changes requested by jlaskey (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2307 From jlahoda at openjdk.java.net Mon May 3 16:41:54 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 3 May 2021 16:41:54 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v6] In-Reply-To: References: Message-ID: On Sun, 2 May 2021 02:10:26 GMT, Vicente Romero wrote: >> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) >> >> Thanks >> >> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build javac changes look good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3526 From sviswanathan at openjdk.java.net Mon May 3 16:55:57 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Mon, 3 May 2021 16:55:57 GMT Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice operations [v3] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 01:58:27 GMT, Sandhya Viswanathan wrote: >> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin). >> >> Changes include: >> * Rewrite Vector API slice/unslice using already intrinsic methods >> * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails >> * Vector API conversion tests thresholds adjustment >> >> Base Performance: >> Benchmark (size) Mode Cnt Score Error Units >> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms >> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms >> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms >> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms >> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms >> >> Performance with patch: >> Benchmark (size) Mode Cnt Score Error Units >> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms >> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms >> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms >> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms >> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > Review comments: blendmask etc @iwanowww Could you please review if the change in library_call.cpp looks ok to you? ------------- PR: https://git.openjdk.java.net/jdk/pull/3804 From psandoz at openjdk.java.net Mon May 3 16:57:55 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 3 May 2021 16:57:55 GMT Subject: RFR: 8266054: VectorAPI rotate operation optimization [v3] In-Reply-To: References: Message-ID: On Mon, 3 May 2021 06:51:29 GMT, Jatin Bhateja wrote: >> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:- >> >> vec1 = lanewise(VectorOperators.LSHL, n) >> vec2 = lanewise(VectorOperators.LSHR, n) >> res = lanewise(VectorOperations.OR, vec1 , vec2) >> >> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction. >> >> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations ) instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted. >> >> Please find below the performance data for included JMH benchmark. >> Machine: Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascade lake Server) >> >> `` >> >> Benchmark | (TESTSIZE) | Shift | Baseline (ops/ms) | Withopt (ops/ms) | Gain % >> -- | -- | -- | -- | -- | -- >> RotateBenchmark.testRotateLeftI | (size) | (shift) | 7384.747 | 7706.652 | 4.36 >> RotateBenchmark.testRotateLeftI | 64 | 11 | 3723.305 | 3816.968 | 2.52 >> RotateBenchmark.testRotateLeftI | 128 | 11 | 1811.521 | 1966.05 | 8.53 >> RotateBenchmark.testRotateLeftI | 256 | 11 | 7133.296 | 7715.047 | 8.16 >> RotateBenchmark.testRotateLeftI | 64 | 21 | 3612.144 | 3886.225 | 7.59 >> RotateBenchmark.testRotateLeftI | 128 | 21 | 1815.422 | 1962.753 | 8.12 >> RotateBenchmark.testRotateLeftI | 256 | 21 | 7216.353 | 7677.165 | 6.39 >> RotateBenchmark.testRotateLeftI | 64 | 31 | 3602.008 | 3892.297 | 8.06 >> RotateBenchmark.testRotateLeftI | 128 | 31 | 1882.163 | 1958.887 | 4.08 >> RotateBenchmark.testRotateLeftI | 256 | 31 | 11819.443 | 11912.864 | 0.79 >> RotateBenchmark.testRotateLeftI | 64 | 11 | 5978.475 | 6060.189 | 1.37 >> RotateBenchmark.testRotateLeftI | 128 | 11 | 2965.179 | 3060.969 | 3.23 >> RotateBenchmark.testRotateLeftI | 256 | 11 | 11479.579 | 11684.148 | 1.78 >> RotateBenchmark.testRotateLeftI | 64 | 21 | 5904.903 | 6094.409 | 3.21 >> RotateBenchmark.testRotateLeftI | 128 | 21 | 2969.879 | 3074.1 | 3.51 >> RotateBenchmark.testRotateLeftI | 256 | 21 | 11531.654 | 12155.954 | 5.41 >> RotateBenchmark.testRotateLeftI | 64 | 31 | 5730.918 | 6112.514 | 6.66 >> RotateBenchmark.testRotateLeftI | 128 | 31 | 2937.19 | 2976.297 | 1.33 >> RotateBenchmark.testRotateLeftI | 256 | 31 | 16159.184 | 16459.462 | 1.86 >> RotateBenchmark.testRotateLeftI | 64 | 11 | 8154.982 | 8396.089 | 2.96 >> RotateBenchmark.testRotateLeftI | 128 | 11 | 4142.224 | 4292.049 | 3.62 >> RotateBenchmark.testRotateLeftI | 256 | 11 | 15958.154 | 16163.518 | 1.29 >> RotateBenchmark.testRotateLeftI | 64 | 21 | 8098.805 | 8504.279 | 5.01 >> RotateBenchmark.testRotateLeftI | 128 | 21 | 4137.598 | 4314.868 | 4.28 >> RotateBenchmark.testRotateLeftI | 256 | 21 | 16201.666 | 15992.958 | -1.29 >> RotateBenchmark.testRotateLeftI | 64 | 31 | 8027.169 | 8484.379 | 5.70 >> RotateBenchmark.testRotateLeftI | 128 | 31 | 4146.29 | 4039.681 | -2.57 >> RotateBenchmark.testRotateLeftL | 256 | 31 | 3566.176 | 3805.248 | 6.70 >> RotateBenchmark.testRotateLeftL | 64 | 11 | 1820.219 | 1962.866 | 7.84 >> RotateBenchmark.testRotateLeftL | 128 | 11 | 917.085 | 1007.334 | 9.84 >> RotateBenchmark.testRotateLeftL | 256 | 11 | 3592.139 | 3973.698 | 10.62 >> RotateBenchmark.testRotateLeftL | 64 | 21 | 1827.63 | 1999.711 | 9.42 >> RotateBenchmark.testRotateLeftL | 128 | 21 | 907.104 | 1002.997 | 10.57 >> RotateBenchmark.testRotateLeftL | 256 | 21 | 3780.962 | 3873.489 | 2.45 >> RotateBenchmark.testRotateLeftL | 64 | 31 | 1830.121 | 1955.63 | 6.86 >> RotateBenchmark.testRotateLeftL | 128 | 31 | 891.411 | 982.138 | 10.18 >> RotateBenchmark.testRotateLeftL | 256 | 31 | 5890.544 | 6100.594 | 3.57 >> RotateBenchmark.testRotateLeftL | 64 | 11 | 2984.329 | 3021.971 | 1.26 >> RotateBenchmark.testRotateLeftL | 128 | 11 | 1485.109 | 1527.689 | 2.87 >> RotateBenchmark.testRotateLeftL | 256 | 11 | 5903.411 | 6083.775 | 3.06 >> RotateBenchmark.testRotateLeftL | 64 | 21 | 2925.37 | 3050.958 | 4.29 >> RotateBenchmark.testRotateLeftL | 128 | 21 | 1486.432 | 1537.155 | 3.41 >> RotateBenchmark.testRotateLeftL | 256 | 21 | 5853.721 | 6000.682 | 2.51 >> RotateBenchmark.testRotateLeftL | 64 | 31 | 2896.116 | 3072.783 | 6.10 >> RotateBenchmark.testRotateLeftL | 128 | 31 | 1483.132 | 1546.588 | 4.28 >> RotateBenchmark.testRotateLeftL | 256 | 31 | 8059.206 | 8218.047 | 1.97 >> RotateBenchmark.testRotateLeftL | 64 | 11 | 4022.416 | 4195.52 | 4.30 >> RotateBenchmark.testRotateLeftL | 128 | 11 | 2084.296 | 2068.238 | -0.77 >> RotateBenchmark.testRotateLeftL | 256 | 11 | 7971.832 | 8172.819 | 2.52 >> RotateBenchmark.testRotateLeftL | 64 | 21 | 4032.036 | 4344.469 | 7.75 >> RotateBenchmark.testRotateLeftL | 128 | 21 | 2068.957 | 2138.685 | 3.37 >> RotateBenchmark.testRotateLeftL | 256 | 21 | 8140.63 | 8003.283 | -1.69 >> RotateBenchmark.testRotateLeftL | 64 | 31 | 4088.621 | 4296.091 | 5.07 >> RotateBenchmark.testRotateLeftL | 128 | 31 | 2007.753 | 2088.455 | 4.02 >> RotateBenchmark.testRotateRightI | 256 | 31 | 7358.793 | 7548.976 | 2.58 >> RotateBenchmark.testRotateRightI | 64 | 11 | 3648.868 | 3897.47 | 6.81 >> RotateBenchmark.testRotateRightI | 128 | 11 | 1862.73 | 1969.964 | 5.76 >> RotateBenchmark.testRotateRightI | 256 | 11 | 7268.806 | 7790.588 | 7.18 >> RotateBenchmark.testRotateRightI | 64 | 21 | 3577.79 | 3979.675 | 11.23 >> RotateBenchmark.testRotateRightI | 128 | 21 | 1773.243 | 1921.088 | 8.34 >> RotateBenchmark.testRotateRightI | 256 | 21 | 7084.974 | 7609.912 | 7.41 >> RotateBenchmark.testRotateRightI | 64 | 31 | 3688.781 | 3909.65 | 5.99 >> RotateBenchmark.testRotateRightI | 128 | 31 | 1845.978 | 1928.316 | 4.46 >> RotateBenchmark.testRotateRightI | 256 | 31 | 11463.228 | 12179.833 | 6.25 >> RotateBenchmark.testRotateRightI | 64 | 11 | 5678.052 | 6028.573 | 6.17 >> RotateBenchmark.testRotateRightI | 128 | 11 | 2990.419 | 3070.409 | 2.67 >> RotateBenchmark.testRotateRightI | 256 | 11 | 11780.283 | 12105.261 | 2.76 >> RotateBenchmark.testRotateRightI | 64 | 21 | 5827.8 | 6020.208 | 3.30 >> RotateBenchmark.testRotateRightI | 128 | 21 | 2904.852 | 3047.154 | 4.90 >> RotateBenchmark.testRotateRightI | 256 | 21 | 11359.146 | 12060.401 | 6.17 >> RotateBenchmark.testRotateRightI | 64 | 31 | 5823.207 | 6079.82 | 4.41 >> RotateBenchmark.testRotateRightI | 128 | 31 | 2984.484 | 3045.719 | 2.05 >> RotateBenchmark.testRotateRightI | 256 | 31 | 16200.504 | 16376.475 | 1.09 >> RotateBenchmark.testRotateRightI | 64 | 11 | 8118.399 | 8315.407 | 2.43 >> RotateBenchmark.testRotateRightI | 128 | 11 | 4130.745 | 4092.588 | -0.92 >> RotateBenchmark.testRotateRightI | 256 | 11 | 15842.168 | 16469.119 | 3.96 >> RotateBenchmark.testRotateRightI | 64 | 21 | 7855.164 | 8188.913 | 4.25 >> RotateBenchmark.testRotateRightI | 128 | 21 | 4114.378 | 4035.56 | -1.92 >> RotateBenchmark.testRotateRightI | 256 | 21 | 15636.117 | 16289.632 | 4.18 >> RotateBenchmark.testRotateRightI | 64 | 31 | 8108.067 | 7996.517 | -1.38 >> RotateBenchmark.testRotateRightI | 128 | 31 | 3997.547 | 4153.58 | 3.90 >> RotateBenchmark.testRotateRightL | 256 | 31 | 3685.99 | 3814.384 | 3.48 >> RotateBenchmark.testRotateRightL | 64 | 11 | 1787.875 | 1916.541 | 7.20 >> RotateBenchmark.testRotateRightL | 128 | 11 | 940.141 | 990.383 | 5.34 >> RotateBenchmark.testRotateRightL | 256 | 11 | 3745.968 | 3920.667 | 4.66 >> RotateBenchmark.testRotateRightL | 64 | 21 | 1877.94 | 1998.072 | 6.40 >> RotateBenchmark.testRotateRightL | 128 | 21 | 933.536 | 1004.61 | 7.61 >> RotateBenchmark.testRotateRightL | 256 | 21 | 3744.763 | 3947.427 | 5.41 >> RotateBenchmark.testRotateRightL | 64 | 31 | 1864.818 | 1978.277 | 6.08 >> RotateBenchmark.testRotateRightL | 128 | 31 | 906.965 | 998.692 | 10.11 >> RotateBenchmark.testRotateRightL | 256 | 31 | 5910.469 | 6062.429 | 2.57 >> RotateBenchmark.testRotateRightL | 64 | 11 | 2914.64 | 3033.127 | 4.07 >> RotateBenchmark.testRotateRightL | 128 | 11 | 1491.344 | 1543.936 | 3.53 >> RotateBenchmark.testRotateRightL | 256 | 11 | 5801.818 | 6098.892 | 5.12 >> RotateBenchmark.testRotateRightL | 64 | 21 | 2881.328 | 3089.547 | 7.23 >> RotateBenchmark.testRotateRightL | 128 | 21 | 1485.969 | 1526.231 | 2.71 >> RotateBenchmark.testRotateRightL | 256 | 21 | 5783.495 | 5957.649 | 3.01 >> RotateBenchmark.testRotateRightL | 64 | 31 | 3008.182 | 3026.323 | 0.60 >> RotateBenchmark.testRotateRightL | 128 | 31 | 1464.566 | 1546.825 | 5.62 >> RotateBenchmark.testRotateRightL | 256 | 31 | 8208.124 | 8361.437 | 1.87 >> RotateBenchmark.testRotateRightL | 64 | 11 | 4062.465 | 4319.412 | 6.32 >> RotateBenchmark.testRotateRightL | 128 | 11 | 2029.995 | 2086.497 | 2.78 >> RotateBenchmark.testRotateRightL | 256 | 11 | 8183.789 | 8193.087 | 0.11 >> RotateBenchmark.testRotateRightL | 64 | 21 | 4092.686 | 4193.712 | 2.47 >> RotateBenchmark.testRotateRightL | 128 | 21 | 2036.854 | 2038.927 | 0.10 >> RotateBenchmark.testRotateRightL | 256 | 21 | 8155.015 | 8175.792 | 0.25 >> RotateBenchmark.testRotateRightL | 64 | 31 | 3960.629 | 4263.922 | 7.66 >> RotateBenchmark.testRotateRightL | 128 | 31 | 1996.862 | 2055.486 | 2.94 >> >> `` > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8266054: Review comments resolution. Testing-wise, can we reuse the `Kernel-Binary-*-op.template` files? hence no need for separate templates Further, i think we need to test with the vector accepting lane-wise method and the broadcast accepting method, since they go through different code paths. The broadcast method can use primitive type rather than cast to `int`, likely making it easier to reuse the binary templates. It would be good if the scalar methods for rotating left/right were identical for the main code and tests. I prefer the code in the test methods. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java line 524: > 522: public static final /*bitwise*/ Binary LSHR = binary("LSHR", ">>>", VectorSupport.VECTOR_OP_URSHIFT, VO_SHIFT); > 523: /** Produce {@code rotateLeft(a,n)}. Integral only. */ > 524: public static final /*bitwise*/ Binary ROL = binary("ROL", "rotateLeft", VectorSupport.VECTOR_OP_LROTATE, VO_SHIFT | VO_SPECIAL); I think we can remove the `VO_SPECIAL` flag on `ROL` and `ROR` now it is uniformly managed? ------------- PR: https://git.openjdk.java.net/jdk/pull/3720 From iris at openjdk.java.net Mon May 3 17:01:51 2021 From: iris at openjdk.java.net (Iris Clark) Date: Mon, 3 May 2021 17:01:51 GMT Subject: RFR: 8265989: System property for the native character encoding name [v3] In-Reply-To: <4qrL7j7zaY2RHgH6-d6sZDfwxIa18T0dPWUQ9-RuqMo=.a031b233-9e74-4c82-8c1f-c5eb30fca4ab@github.com> References: <4qrL7j7zaY2RHgH6-d6sZDfwxIa18T0dPWUQ9-RuqMo=.a031b233-9e74-4c82-8c1f-c5eb30fca4ab@github.com> Message-ID: On Fri, 30 Apr 2021 22:10:21 GMT, Naoto Sato wrote: >> After some internal discussion, we thought it was good to expose the native environment's default character encoding, which Charset.defaultCharset() is currently based on. This way applications will have a better migration path after the [JEP 400](https://openjdk.java.net/jeps/400) is implemented, in which Charset.defaultCharset() will return UTF-8, but the value of this new system property will remain intact. A [CSR](https://bugs.openjdk.java.net/browse/JDK-8266075) has been filed with more detailed information. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a typo. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3777 From almatvee at openjdk.java.net Mon May 3 17:27:51 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 3 May 2021 17:27:51 GMT Subject: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v2] In-Reply-To: References: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> <5YPQQNYy5mwffBKFNKOMl3MQcQG5j3WwuXwRa84PDLY=.54528138-1b33-42b5-91fd-10c7edc67ced@github.com> Message-ID: On Mon, 3 May 2021 15:58:56 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8266179: [macos] jpackage should specify architecture for produced pkg files [v2] > > test/jdk/tools/jpackage/macosx/HostArchPkgTest.java line 55: > >> 53: >> 54: private static void verifyHostArch(JPackageCommand cmd) throws Exception { >> 55: Path distributionFile = cmd.unpackedPackageDirectory() > > I think `cmd.pathToUnpackedPackageFile("/")` would be the equivalent to `cmd.unpackedPackageDirectory()`. If it is, there would be no need for changes to JPackageCommand. Fixed. > test/jdk/tools/jpackage/macosx/HostArchPkgTest.java line 84: > >> 82: } >> 83: >> 84: public static void main(String[] args) throws Exception { > > Please don't use direct TKit.run() call. Use jdk.jpackage.test.Annotations.Test annotation for test method. You can use SimplePackageTest jtreg test as an example I will fix it. Do we have a bug or I can file one to fix other tests? We have several tests such as SigningPackageTest which uses TKit.run() call and I just copy paste it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3807 From almatvee at openjdk.java.net Mon May 3 17:32:54 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 3 May 2021 17:32:54 GMT Subject: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v2] In-Reply-To: References: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> <5YPQQNYy5mwffBKFNKOMl3MQcQG5j3WwuXwRa84PDLY=.54528138-1b33-42b5-91fd-10c7edc67ced@github.com> Message-ID: On Mon, 3 May 2021 16:01:36 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8266179: [macos] jpackage should specify architecture for produced pkg files [v2] > > test/jdk/tools/jpackage/macosx/HostArchPkgTest.java line 57: > >> 55: Path distributionFile = cmd.unpackedPackageDirectory() >> 56: .toAbsolutePath() >> 57: .getParent() > > Why .getParent() is needed here? Unpacking pkg is two stage process. First we unpack it to unpacked-pkg/data which contains Distribution file, pkg background images and tar archive with app itself. Then we unpack app tar archive to unpacked-pkg/unpacked. Test needs to check unpacked-pkg/data/Distribution and cmd.pathToUnpackedPackageFile("/") returns path to unpacked-pkg/unpacked. Thus getParent() is used to move up. ------------- PR: https://git.openjdk.java.net/jdk/pull/3807 From rriggs at openjdk.java.net Mon May 3 18:28:58 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 3 May 2021 18:28:58 GMT Subject: RFR: 8265989: System property for the native character encoding name [v3] In-Reply-To: <4qrL7j7zaY2RHgH6-d6sZDfwxIa18T0dPWUQ9-RuqMo=.a031b233-9e74-4c82-8c1f-c5eb30fca4ab@github.com> References: <4qrL7j7zaY2RHgH6-d6sZDfwxIa18T0dPWUQ9-RuqMo=.a031b233-9e74-4c82-8c1f-c5eb30fca4ab@github.com> Message-ID: On Fri, 30 Apr 2021 22:10:21 GMT, Naoto Sato wrote: >> After some internal discussion, we thought it was good to expose the native environment's default character encoding, which Charset.defaultCharset() is currently based on. This way applications will have a better migration path after the [JEP 400](https://openjdk.java.net/jeps/400) is implemented, in which Charset.defaultCharset() will return UTF-8, but the value of this new system property will remain intact. A [CSR](https://bugs.openjdk.java.net/browse/JDK-8266075) has been filed with more detailed information. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a typo. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3777 From mchung at openjdk.java.net Mon May 3 19:07:03 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 3 May 2021 19:07:03 GMT Subject: RFR: JDK-8266391: Replace use of reflection in jdk.internal.platform.Metrics Message-ID: <8U3lxNTE5y9k9FEhwUfS4COdD79OTR_EdiCZVjGokto=.f007a7d6-12db-4521-bcad-37fee2eebb77@github.com> 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 reflection in jdk.internal.platform.Metrics Changes: https://git.openjdk.java.net/jdk/pull/3828/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3828&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266391 Stats: 103 lines in 4 files changed: 93 ins; 8 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3828.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3828/head:pull/3828 PR: https://git.openjdk.java.net/jdk/pull/3828 From asemenyuk at openjdk.java.net Mon May 3 19:16:50 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 3 May 2021 19:16:50 GMT Subject: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v2] In-Reply-To: References: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> <5YPQQNYy5mwffBKFNKOMl3MQcQG5j3WwuXwRa84PDLY=.54528138-1b33-42b5-91fd-10c7edc67ced@github.com> Message-ID: On Mon, 3 May 2021 17:24:16 GMT, Alexander Matveev wrote: >> test/jdk/tools/jpackage/macosx/HostArchPkgTest.java line 84: >> >>> 82: } >>> 83: >>> 84: public static void main(String[] args) throws Exception { >> >> Please don't use direct TKit.run() call. Use jdk.jpackage.test.Annotations.Test annotation for test method. You can use SimplePackageTest jtreg test as an example > > I will fix it. Do we have a bug or I can file one to fix other tests? We have several tests such as SigningPackageTest which uses TKit.run() call and I just copy paste it. No, we don't have a CR to track replacement of direct TKit.run() calls. Please feel free to file one. ------------- PR: https://git.openjdk.java.net/jdk/pull/3807 From asemenyuk at openjdk.java.net Mon May 3 19:19:51 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 3 May 2021 19:19:51 GMT Subject: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v2] In-Reply-To: References: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> <5YPQQNYy5mwffBKFNKOMl3MQcQG5j3WwuXwRa84PDLY=.54528138-1b33-42b5-91fd-10c7edc67ced@github.com> Message-ID: On Mon, 3 May 2021 17:30:15 GMT, Alexander Matveev wrote: >> test/jdk/tools/jpackage/macosx/HostArchPkgTest.java line 57: >> >>> 55: Path distributionFile = cmd.unpackedPackageDirectory() >>> 56: .toAbsolutePath() >>> 57: .getParent() >> >> Why .getParent() is needed here? > > Unpacking pkg is two stage process. First we unpack it to unpacked-pkg/data which contains Distribution file, pkg background images and tar archive with app itself. Then we unpack app tar archive to unpacked-pkg/unpacked. Test needs to check unpacked-pkg/data/Distribution and cmd.pathToUnpackedPackageFile("/") returns path to unpacked-pkg/unpacked. Thus getParent() is used to move up. Understood. Thank you for explanation! ------------- PR: https://git.openjdk.java.net/jdk/pull/3807 From almatvee at openjdk.java.net Mon May 3 19:26:19 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 3 May 2021 19:26:19 GMT Subject: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v3] In-Reply-To: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> References: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> Message-ID: > jpackage should specify architecture for produced PKG files via hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable on x64 without specifying hostArchitectures which is not correct and if install on arm Mac it will request Rosetta 2. With proposed fix by setting hostArchitectures="x86_x64" if installer contains x64 binaries, it will be installable on x64 Mac and will require Rosetta 2 on arm Mac. hostArchitectures will be set to arm64 if installer contain aarch64 binaries and will gave error when run on x64 Mac and will be installable on arm Mac without triggering installation of Rosetta 2. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8266179: [macos] jpackage should specify architecture for produced pkg files [v3] ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3807/files - new: https://git.openjdk.java.net/jdk/pull/3807/files/11d9a2cf..83a59341 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3807&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3807&range=01-02 Stats: 15 lines in 2 files changed: 2 ins; 1 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/3807.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3807/head:pull/3807 PR: https://git.openjdk.java.net/jdk/pull/3807 From asemenyuk at openjdk.java.net Mon May 3 20:09:54 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 3 May 2021 20:09:54 GMT Subject: RFR: JDK-8266227: Fix help text for --mac-signing-keychain In-Reply-To: <-UNmpEVvS4xw89IjWDR7tIpjoNNBS3c9hq_L1TeTEvw=.5eba417e-10ef-4d06-a54c-88a93d177b17@github.com> References: <-UNmpEVvS4xw89IjWDR7tIpjoNNBS3c9hq_L1TeTEvw=.5eba417e-10ef-4d06-a54c-88a93d177b17@github.com> Message-ID: On Fri, 30 Apr 2021 15:25:13 GMT, Andy Herrick wrote: > JDK-8266227: Fix help text for --mac-signing-keychain Marked as reviewed by asemenyuk (Reviewer). The changes seems to be covering more than what the title of the CR states. Would it make sense to update the title accordingly? ------------- PR: https://git.openjdk.java.net/jdk/pull/3819 From redestad at openjdk.java.net Mon May 3 20:21:49 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 3 May 2021 20:21:49 GMT Subject: RFR: JDK-8266391: Replace use of reflection in jdk.internal.platform.Metrics In-Reply-To: <8U3lxNTE5y9k9FEhwUfS4COdD79OTR_EdiCZVjGokto=.f007a7d6-12db-4521-bcad-37fee2eebb77@github.com> References: <8U3lxNTE5y9k9FEhwUfS4COdD79OTR_EdiCZVjGokto=.f007a7d6-12db-4521-bcad-37fee2eebb77@github.com> Message-ID: 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. Looks good to me! ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3828 From asemenyuk at openjdk.java.net Mon May 3 20:24:51 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 3 May 2021 20:24:51 GMT Subject: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v3] In-Reply-To: References: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> Message-ID: On Mon, 3 May 2021 19:26:19 GMT, Alexander Matveev wrote: >> jpackage should specify architecture for produced PKG files via hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable on x64 without specifying hostArchitectures which is not correct and if install on arm Mac it will request Rosetta 2. With proposed fix by setting hostArchitectures="x86_x64" if installer contains x64 binaries, it will be installable on x64 Mac and will require Rosetta 2 on arm Mac. hostArchitectures will be set to arm64 if installer contain aarch64 binaries and will gave error when run on x64 Mac and will be installable on arm Mac without triggering installation of Rosetta 2. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8266179: [macos] jpackage should specify architecture for produced pkg files [v3] Changes requested by asemenyuk (Reviewer). test/jdk/tools/jpackage/macosx/HostArchPkgTest.java line 93: > 91: .forTypes(PackageType.MAC_PKG) > 92: .addInstallVerifier(HostArchPkgTest::verifyHostArch) > 93: .run(); The test is applicable only to the scenario when .pkg installer is unpacked and not when it is installed. So `PackageTest.run()` is not quite a good fit for this execution scenario as it depends on the value of `jpackage.test.action` system property (its default value is indeed to create and unpack installer, but can be overriden). The better option would be to use `PackageTest.run()` with explicit list of actions the test should perform. Suggested fix: new PackageTest() .forTypes(PackageType.MAC_PKG) .configureHelloApp() .addInstallVerifier(HostArchPkgTest::verifyHostArch) .run(PackageTest.Action.CREATE_AND_UNPACK); ------------- PR: https://git.openjdk.java.net/jdk/pull/3807 From asemenyuk at openjdk.java.net Mon May 3 20:24:51 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 3 May 2021 20:24:51 GMT Subject: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v3] In-Reply-To: References: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> Message-ID: On Mon, 3 May 2021 20:20:52 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8266179: [macos] jpackage should specify architecture for produced pkg files [v3] > > test/jdk/tools/jpackage/macosx/HostArchPkgTest.java line 93: > >> 91: .forTypes(PackageType.MAC_PKG) >> 92: .addInstallVerifier(HostArchPkgTest::verifyHostArch) >> 93: .run(); > > The test is applicable only to the scenario when .pkg installer is unpacked and not when it is installed. So `PackageTest.run()` is not quite a good fit for this execution scenario as it depends on the value of `jpackage.test.action` system property (its default value is indeed to create and unpack installer, but can be overriden). The better option would be to use `PackageTest.run()` with explicit list of actions the test should perform. Suggested fix: > > new PackageTest() > .forTypes(PackageType.MAC_PKG) > .configureHelloApp() > .addInstallVerifier(HostArchPkgTest::verifyHostArch) > .run(PackageTest.Action.CREATE_AND_UNPACK); Sorry for the inconvenience, I didn't include this comment in my initial review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3807 From bpb at openjdk.java.net Mon May 3 20:39:02 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 3 May 2021 20:39:02 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes Message-ID: Please consider this request to override the `java.io.InputStream` methods `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more performant implementations. The method overrides attempt to read all requested bytes into a single array of the required size rather than composing the result from a sequence of smaller arrays. An example of the performance improvements is as follows. **readAllBytes** Before Benchmark (length) Mode Cnt Score Error Units ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 2412.031 ? 7.309 ops/s ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 212.181 ? 0.369 ops/s ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 19.860 ? 0.048 ops/s ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.298 ? 0.183 ops/s After Benchmark (length) Mode Cnt Score Error Units ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 8218.473 ? 43.425 ops/s ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 302.781 ? 1.273 ops/s ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 22.461 ? 0.084 ops/s ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.502 ? 0.003 ops/s **readNBytes** `N = file_size / 2` Before Benchmark (length) Mode Cnt Score Error Units ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 5585.500 ? 153.353 ops/s ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 436.164 ? 1.104 ops/s ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 40.167 ? 0.141 ops/s ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 3.291 ? 0.211 ops/s After Benchmark (length) Mode Cnt Score Error Units ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 15463.210 ? 66.045 ops/s ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 561.752 ? 0.951 ops/s ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 45.043 ? 0.102 ops/s ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 4.629 ? 0.035 ops/s ------------- Commit messages: - 8264777: Overload optimized FileInputStream::readAllBytes Changes: https://git.openjdk.java.net/jdk/pull/3845/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3845&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264777 Stats: 221 lines in 4 files changed: 215 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3845/head:pull/3845 PR: https://git.openjdk.java.net/jdk/pull/3845 From psandoz at openjdk.java.net Mon May 3 21:43:54 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 3 May 2021 21:43:54 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 21:11:26 GMT, Sandhya Viswanathan wrote: >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> This work is part of second round of incubation of the Vector API. >> JEP: https://bugs.openjdk.java.net/browse/JDK-8261663 >> >> Please review. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge master > - remove whitespace > - Merge master > - Small fix > - cleanup > - x86 short vector math optimization for Vector API Tier 1 to 3 tests pass for the default set of build profiles. ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From mchung at openjdk.java.net Mon May 3 22:01:51 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 3 May 2021 22:01:51 GMT Subject: Integrated: JDK-8266391: Replace use of reflection in jdk.internal.platform.Metrics In-Reply-To: <8U3lxNTE5y9k9FEhwUfS4COdD79OTR_EdiCZVjGokto=.f007a7d6-12db-4521-bcad-37fee2eebb77@github.com> References: <8U3lxNTE5y9k9FEhwUfS4COdD79OTR_EdiCZVjGokto=.f007a7d6-12db-4521-bcad-37fee2eebb77@github.com> Message-ID: 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. This pull request has now been integrated. Changeset: 3544a9d0 Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/3544a9d0e4a071ad9c82aa17ab113e0101b4020b Stats: 103 lines in 4 files changed: 93 ins; 8 del; 2 mod 8266391: Replace use of reflection in jdk.internal.platform.Metrics Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/3828 From sviswanathan at openjdk.java.net Mon May 3 22:11:59 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Mon, 3 May 2021 22:11:59 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v2] In-Reply-To: References: Message-ID: On Mon, 3 May 2021 21:41:26 GMT, Paul Sandoz wrote: >> Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Merge master >> - remove whitespace >> - Merge master >> - Small fix >> - cleanup >> - x86 short vector math optimization for Vector API > > Tier 1 to 3 tests pass for the default set of build profiles. @PaulSandoz Thanks a lot for running through the tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From almatvee at openjdk.java.net Mon May 3 22:52:21 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 3 May 2021 22:52:21 GMT Subject: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v4] In-Reply-To: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> References: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> Message-ID: > jpackage should specify architecture for produced PKG files via hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable on x64 without specifying hostArchitectures which is not correct and if install on arm Mac it will request Rosetta 2. With proposed fix by setting hostArchitectures="x86_x64" if installer contains x64 binaries, it will be installable on x64 Mac and will require Rosetta 2 on arm Mac. hostArchitectures will be set to arm64 if installer contain aarch64 binaries and will gave error when run on x64 Mac and will be installable on arm Mac without triggering installation of Rosetta 2. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8266179: [macos] jpackage should specify architecture for produced pkg files [v4] ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3807/files - new: https://git.openjdk.java.net/jdk/pull/3807/files/83a59341..735baf93 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3807&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3807&range=02-03 Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3807.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3807/head:pull/3807 PR: https://git.openjdk.java.net/jdk/pull/3807 From asemenyuk at openjdk.java.net Mon May 3 23:29:55 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 3 May 2021 23:29:55 GMT Subject: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v4] In-Reply-To: References: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> Message-ID: <00PuZIfk_SGGRMjxyibf504c2y1xXHmWWLtKL8TPV28=.17bad2a5-500d-4fc6-aecd-ea0f6915f43a@github.com> On Mon, 3 May 2021 22:52:21 GMT, Alexander Matveev wrote: >> jpackage should specify architecture for produced PKG files via hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable on x64 without specifying hostArchitectures which is not correct and if install on arm Mac it will request Rosetta 2. With proposed fix by setting hostArchitectures="x86_x64" if installer contains x64 binaries, it will be installable on x64 Mac and will require Rosetta 2 on arm Mac. hostArchitectures will be set to arm64 if installer contain aarch64 binaries and will gave error when run on x64 Mac and will be installable on arm Mac without triggering installation of Rosetta 2. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8266179: [macos] jpackage should specify architecture for produced pkg files [v4] Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3807 From kcr at openjdk.java.net Mon May 3 23:36:50 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 3 May 2021 23:36:50 GMT Subject: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v4] In-Reply-To: References: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> Message-ID: On Mon, 3 May 2021 22:52:21 GMT, Alexander Matveev wrote: >> jpackage should specify architecture for produced PKG files via hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable on x64 without specifying hostArchitectures which is not correct and if install on arm Mac it will request Rosetta 2. With proposed fix by setting hostArchitectures="x86_x64" if installer contains x64 binaries, it will be installable on x64 Mac and will require Rosetta 2 on arm Mac. hostArchitectures will be set to arm64 if installer contain aarch64 binaries and will gave error when run on x64 Mac and will be installable on arm Mac without triggering installation of Rosetta 2. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8266179: [macos] jpackage should specify architecture for produced pkg files [v4] I presume you've done a CI test build on machines of both architectures? ------------- PR: https://git.openjdk.java.net/jdk/pull/3807 From almatvee at openjdk.java.net Tue May 4 03:05:51 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 4 May 2021 03:05:51 GMT Subject: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v4] In-Reply-To: References: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> Message-ID: On Mon, 3 May 2021 22:52:21 GMT, Alexander Matveev wrote: >> jpackage should specify architecture for produced PKG files via hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable on x64 without specifying hostArchitectures which is not correct and if install on arm Mac it will request Rosetta 2. With proposed fix by setting hostArchitectures="x86_x64" if installer contains x64 binaries, it will be installable on x64 Mac and will require Rosetta 2 on arm Mac. hostArchitectures will be set to arm64 if installer contain aarch64 binaries and will gave error when run on x64 Mac and will be installable on arm Mac without triggering installation of Rosetta 2. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8266179: [macos] jpackage should specify architecture for produced pkg files [v4] Yes, it was tested on both x64 and arm. ------------- PR: https://git.openjdk.java.net/jdk/pull/3807 From alanb at openjdk.java.net Tue May 4 08:23:55 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 4 May 2021 08:23:55 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v7] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 15:20:42 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://openjdk.java.net/jeps/412 > > Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: > > - Revert bad change in benchmark copyright > - Do not apply optimized bound check if accessed offset/length do not fit in an `int` value Just to double, there is no way to enable native access for modules in module layers (other than the boot layer), right? src/java.base/share/classes/java/lang/Module.java line 115: > 113: > 114: // is this module a native module > 115: private volatile boolean enableNativeAccess = false; Can you drop "= false", it's not needed and I don't think we want a volatile-write here. Also the comment may date from a previous iteration as there isn't any concept of a "native module". src/java.base/share/classes/java/lang/System.java line 2346: > 2344: public boolean isEnableNativeAccess(Module m) { > 2345: return m.isEnableNativeAccess(); > 2346: } Can you move this up so they are with the other Module methods? src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 34: > 32: import java.util.Set; > 33: > 34: public final class IllegalNativeAccessChecker { Are you sure about the name of the this class? It doesn't do any checking and it's not concerned with "illegal native access" either, instead it just provides access to the names of modules that have been granted native access. src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 47: > 45: private static IllegalNativeAccessChecker checker; > 46: > 47: static Collection enableNativeAccessModules() { I assume this can be changed to Iterable as you don't want anything outside of this class changing the collection. src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 889: > 887: } else { > 888: // silently skip. > 889: // warnUnknownModule(ENABLE_NATIVE_ACCESS, name); Maybe for later but the other options do emit a warning when unknown module is specified. If the decoding of this command line option is moved to ModuleBootstrap then most of this class will go away and you will be able to use warnUnknownModule. src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 113: > 111: if (!SharedSecrets.getJavaLangAccess().isEnableNativeAccess(module)) { > 112: String moduleName = module.isNamed()? module.getName() : "UNNAMED"; > 113: throw new IllegalCallerException("Illegal native access from module: " + moduleName); "UNNAMED" is a bit inconsistent with the other exception messages. Can you just use Module::toString here instead, meaning "Illegal native access from " + module ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From sundar at openjdk.java.net Tue May 4 09:11:21 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 4 May 2021 09:11:21 GMT Subject: RFR: 8260621: (jrtfs) ThreadLocal memory leak in ImageBufferCache when using jrtfs Message-ID: Instead of BufferReference class, Map.Entry is used as pair implementation. This avoids the metaspace leak seen via thread local. ------------- Commit messages: - added comment. generics cleanup. - 8260621: (jrtfs) ThreadLocal memory leak in ImageBufferCache when using jrtfs Changes: https://git.openjdk.java.net/jdk/pull/3849/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3849&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260621 Stats: 57 lines in 1 file changed: 30 ins; 7 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/3849.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3849/head:pull/3849 PR: https://git.openjdk.java.net/jdk/pull/3849 From mcimadamore at openjdk.java.net Tue May 4 09:54:04 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 4 May 2021 09:54:04 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v7] In-Reply-To: References: Message-ID: On Tue, 4 May 2021 08:20:43 GMT, Alan Bateman wrote: > Just to double, there is no way to enable native access for modules in module layers (other than the boot layer), right? No, at the moment it is not possible to enable native access programmatically. We will explore something along those lines in the future. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Tue May 4 10:06:25 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 4 May 2021 10:06:25 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v8] In-Reply-To: References: Message-ID: > 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://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - Remove redundant initializer in Module - Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/793ea5c5..6a659d87 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=06-07 Stats: 19 lines in 3 files changed: 6 ins; 11 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From kcr at openjdk.java.net Tue May 4 10:58:52 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 4 May 2021 10:58:52 GMT Subject: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v4] In-Reply-To: References: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> Message-ID: On Mon, 3 May 2021 22:52:21 GMT, Alexander Matveev wrote: >> jpackage should specify architecture for produced PKG files via hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable on x64 without specifying hostArchitectures which is not correct and if install on arm Mac it will request Rosetta 2. With proposed fix by setting hostArchitectures="x86_x64" if installer contains x64 binaries, it will be installable on x64 Mac and will require Rosetta 2 on arm Mac. hostArchitectures will be set to arm64 if installer contain aarch64 binaries and will gave error when run on x64 Mac and will be installable on arm Mac without triggering installation of Rosetta 2. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8266179: [macos] jpackage should specify architecture for produced pkg files [v4] Marked as reviewed by kcr (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/3807 From jlaskey at openjdk.java.net Tue May 4 11:21:49 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 4 May 2021 11:21:49 GMT Subject: RFR: 8260621: (jrtfs) ThreadLocal memory leak in ImageBufferCache when using jrtfs In-Reply-To: References: Message-ID: On Tue, 4 May 2021 09:05:38 GMT, Athijegannathan Sundararajan wrote: > Instead of BufferReference class, Map.Entry is used as pair implementation. > This avoids the metaspace leak seen via thread local. Marked as reviewed by jlaskey (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3849 From jlaskey at openjdk.java.net Tue May 4 11:43:48 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 4 May 2021 11:43:48 GMT Subject: RFR: 8265137: java.util.Random suddenly has new public methods nowhere documented [v8] In-Reply-To: References: Message-ID: <2_pQNKMJO3W3fH-P_S5-3LPE5P5FgsuIy7aGN6XxLV0=.8b64613d-7258-4999-9a27-a7bab1ae90b8@github.com> > Move makeXXXSpilterator from public (@hidden) to protected. No API ch Jim Laskey 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 10 additional commits since the last revision: - Merge branch 'master' into 8265137 - Remove unnecessary constructor. - Merge branch 'master' into 8265137 - Remove @hidden - Correct the hierarchy of Random - Remove extraneous references to makeXXXSpliterator - Move makeXXXSpliterator methods to RandomSupport - change static final from 'proxy' to 'PROXY' - Make makeXXXSpliterator final - Move makeXXXSpilterator from public (@hidden) to protected. No API change. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3469/files - new: https://git.openjdk.java.net/jdk/pull/3469/files/482ea0ac..218a7d9d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3469&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3469&range=06-07 Stats: 514343 lines in 4172 files changed: 24106 ins; 486284 del; 3953 mod Patch: https://git.openjdk.java.net/jdk/pull/3469.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3469/head:pull/3469 PR: https://git.openjdk.java.net/jdk/pull/3469 From jlaskey at openjdk.java.net Tue May 4 11:55:54 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 4 May 2021 11:55:54 GMT Subject: Integrated: 8265137: java.util.Random suddenly has new public methods nowhere documented In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 16:33:21 GMT, Jim Laskey wrote: > Move makeXXXSpilterator from public (@hidden) to protected. No API ch This pull request has now been integrated. Changeset: 05e60174 Author: Jim Laskey URL: https://git.openjdk.java.net/jdk/commit/05e601748a35de02a33721199a00a3d6c335c6d9 Stats: 340 lines in 4 files changed: 67 ins; 215 del; 58 mod 8265137: java.util.Random suddenly has new public methods nowhere documented Reviewed-by: uschindler, darcy, smarks ------------- PR: https://git.openjdk.java.net/jdk/pull/3469 From mcimadamore at openjdk.java.net Tue May 4 11:58:22 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 4 May 2021 11:58:22 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v9] In-Reply-To: References: Message-ID: > 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://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision: - Tweak code some more - Use uniform naming convention for implementation metods in Module - Remove IllegalNativeAccessChecker ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/6a659d87..ead71078 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=07-08 Stats: 169 lines in 5 files changed: 41 ins; 114 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Tue May 4 12:05:16 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 4 May 2021 12:05:16 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v7] In-Reply-To: References: Message-ID: <6prALGyA4mz4fP09-t2OrUtApa_WW7iRKsw2lhmilUA=.3ac938b7-422f-4a3d-942b-16bd8c5fd3c6@github.com> On Tue, 4 May 2021 08:12:23 GMT, Alan Bateman wrote: >> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: >> >> - Revert bad change in benchmark copyright >> - Do not apply optimized bound check if accessed offset/length do not fit in an `int` value > > src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 34: > >> 32: import java.util.Set; >> 33: >> 34: public final class IllegalNativeAccessChecker { > > Are you sure about the name of the this class? It doesn't do any checking and it's not concerned with "illegal native access" either, instead it just provides access to the names of modules that have been granted native access. I've decided to drop this class and move the logic in ModuleBootstrap. To handle unnamed modules, I had to piggy back on the special static ALL_UNNAMED module and set the flag there when decoding the command line option. This seems to be consistent with what is done in other areas. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Tue May 4 12:05:15 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 4 May 2021 12:05:15 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v10] In-Reply-To: References: Message-ID: <-ForVlVYhV48Iw44ATh9hmpPNNDJsl3UZnte-RLtuRA=.44826ded-dbaa-4b8a-b58e-473f8ce4a991@github.com> > 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://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Tweak comment in Module::enableNativeAccess ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/ead71078..2a31da40 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From jlaskey at openjdk.java.net Tue May 4 12:07:15 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 4 May 2021 12:07:15 GMT Subject: RFR: 8265279: Remove unused RandomGeneratorFactory.all(Class category) [v2] In-Reply-To: References: Message-ID: > No longer needed Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into 8265279 - RandomGeneratorFactory.all(Class category) no longer needed - Remove extraneous references to makeXXXSpliterator - Move makeXXXSpliterator methods to RandomSupport - change static final from 'proxy' to 'PROXY' - Make makeXXXSpliterator final - Move makeXXXSpilterator from public (@hidden) to protected. No API change. ------------- Changes: https://git.openjdk.java.net/jdk/pull/3516/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3516&range=01 Stats: 25 lines in 1 file changed: 0 ins; 25 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3516.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3516/head:pull/3516 PR: https://git.openjdk.java.net/jdk/pull/3516 From tschatzl at openjdk.java.net Tue May 4 12:21:55 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 4 May 2021 12:21:55 GMT Subject: RFR: 8254598: StringDedupTable should use OopStorage In-Reply-To: References: Message-ID: <6ZAMFTRy3EAApWJryDwCZNHc0P8tF6flss2e4TRVs00=.7f365a2f-ae15-4163-b9ee-b57e188f686f@github.com> On Fri, 23 Apr 2021 19:48:47 GMT, Kim Barrett wrote: > Please review this change to the String Deduplication facility. It is being > changed to use OopStorage to hold weak references to relevant objects, > rather than bespoke data structures requiring dedicated processing phases by > supporting GCs. > > (The Shenandoah update was contributed by Zhengyu Gu.) > > This change significantly simplifies the interface between a given GC and > the String Deduplication facility, which should make it much easier for > other GCs to opt in. However, this change does not alter the set of GCs > providing support; currently only G1 and Shenandoah support string > deduplication. Adding support by other GCs will be in followup RFEs. > > Reviewing via the diffs might not be all that useful for some parts, as > several files have been essentially completely replaced, and a number of > files have been added or eliminated. The full webrev might be a better > place to look. > > The major changes are in gc/shared/stringdedup/* and in the supporting > collectors, but there are also some smaller changes in other places, most > notably classfile/{stringTable,javaClasses}. > > This change is additionally labeled for review by core-libs, although there > are no source changes there. This change injects a byte field of bits into > java.lang.String, using one of the previously unused padding bytes in that > class. (There were two unused bytes, now only one.) > > Testing: > mach5 tier1-2 with and without -XX:+UseStringDeduplication > > Locally (linux-x64) ran all of the existing tests that use string > deduplication with both G1 and Shenandoah. Note that > TestStringDeduplicationInterned.java is disabled for shenandoah, as it > currently fails, for reasons I haven't figured out but suspect are test > related. > > - gc/stringdedup/ -- these used to be in gc/g1 > - runtime/cds/SharedStringsDedup.java > - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java > - runtime/cds/appcds/sharedStrings/* > > shenandoah-only: > - gc/shenandoah/jvmti/TestHeapDump.java > - gc/shenandoah/TestStringDedup.java > - gc/shenandoah/TestStringDedupStress.java > > Performance tested baseline, baseline + stringdedup, new with stringdedup, > finding no significant differences. First pass, just comment suggestions for now. src/hotspot/share/classfile/javaClasses.hpp line 119: > 117: static const uint8_t _deduplication_requested_mask = 1 << 1; > 118: > 119: static int flags_offset() { CHECK_INIT(_flags_offset); } Maybe add some description about the injected `flags` field and its contents here. src/hotspot/share/classfile/javaClasses.hpp line 152: > 150: static inline void set_value(oop string, typeArrayOop buffer); > 151: > 152: // Set the no_deduplication flag true. This flag is sticky; once set it Initially I was a bit confused of the use of "flag" here and that the field is called "flags". Maybe use "deduplication bit" here, or rename the "flags" field but feel free to ignore. src/hotspot/share/classfile/javaClasses.hpp line 154: > 152: // Set the no_deduplication flag true. This flag is sticky; once set it > 153: // never gets cleared. This is set when a string is interned in the > 154: // StringTable, to prevent string deduplication from changing the string's I think this information about the contents of the injected "flags" should be collected somewhere else as piecing together what fields "flags" has from different method documentation seems wrong. src/hotspot/share/classfile/javaClasses.hpp line 170: > 168: static inline bool hash_is_set(oop string); > 169: static inline bool is_latin1(oop java_string); > 170: static inline bool no_deduplication(oop java_string); That identifier is missing a verb to read better, but I do not have a good idea. Maybe it would be easier to use the negation of "no_deduplication", something like "may_deduplicate"? Feel free to ignore. src/hotspot/share/classfile/javaClasses.hpp line 171: > 169: static inline bool is_latin1(oop java_string); > 170: static inline bool no_deduplication(oop java_string); > 171: static inline bool deduplication_requested(oop java_string); Having a verb at the beginning like `is_deduplication_requested` sounds better. src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp line 31: > 29: // > 30: // String deduplication aims to reduce the heap live-set by deduplicating > 31: // identical instances of String so that they share the same backing byte ... by deduplicating instances of (java.lang.)String with identical backing byte array (the String's value). src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp line 69: > 67: // arrays. This permits reclamation of arrays that become unused. This is > 68: // separate from the request storage objects because dead count tracking is > 69: // used by the table implementation as part of resizing decisions and for s/table/string table? I.e. which table is referred to here? src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp line 84: > 82: // interned string might later become a deduplication candidate through the > 83: // normal GC discovery mechanism. This is handled by setting the > 84: // no_deduplication flag in a string before interning it. A string with s/string/String Maybe: s/This is handled.../Deduplication is prevented by setting the no_deduplication flag in the String before.../ ------------- PR: https://git.openjdk.java.net/jdk/pull/3662 From herrick at openjdk.java.net Tue May 4 13:13:55 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 4 May 2021 13:13:55 GMT Subject: RFR: JDK-8266227: Fix help text for --mac-signing-keychain In-Reply-To: <-UNmpEVvS4xw89IjWDR7tIpjoNNBS3c9hq_L1TeTEvw=.5eba417e-10ef-4d06-a54c-88a93d177b17@github.com> References: <-UNmpEVvS4xw89IjWDR7tIpjoNNBS3c9hq_L1TeTEvw=.5eba417e-10ef-4d06-a54c-88a93d177b17@github.com> Message-ID: <7XmdbUP-YwRtaxSOA8nG38pp7dg07ZHudKuVanhcdjc=.712d5aa4-d0a2-4baa-a49a-e121d145f3e1@github.com> On Fri, 30 Apr 2021 15:25:13 GMT, Andy Herrick wrote: > JDK-8266227: Fix help text for --mac-signing-keychain I updated the bug Description to point out that text formatting and other minor wording changes are being applied to the help ------------- PR: https://git.openjdk.java.net/jdk/pull/3819 From jzaugg at openjdk.java.net Tue May 4 13:15:04 2021 From: jzaugg at openjdk.java.net (Jason Zaugg) Date: Tue, 4 May 2021 13:15:04 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem Message-ID: If the given Path represents a file, use the overload of read defined in FileChannel that accepts an explicit position and avoid serializing reads. Note: The underlying NIO implementation is not required to implement FileChannel.read(ByteBuffer, long) concurrently; Windows still appears to lock, as it returns true for NativeDispatcher.needsPositionLock. On MacOS X, the enclosed benchmark improves from: Benchmark Mode Cnt Score Error Units ZipFileSystemBenchmark.read avgt 10 75.311 ? 3.301 ms/op To: Benchmark Mode Cnt Score Error Units ZipFileSystemBenchmark.read avgt 10 12.520 ? 0.875 ms/op ------------- Commit messages: - 8265448: Avoid lock contention in reads from zipfs when possible Changes: https://git.openjdk.java.net/jdk/pull/3853/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3853&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265448 Stats: 101 lines in 2 files changed: 97 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3853/head:pull/3853 PR: https://git.openjdk.java.net/jdk/pull/3853 From rriggs at openjdk.java.net Tue May 4 13:22:57 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 4 May 2021 13:22:57 GMT Subject: RFR: 8265279: Remove unused RandomGeneratorFactory.all(Class category) [v2] In-Reply-To: References: Message-ID: On Tue, 4 May 2021 12:07:15 GMT, Jim Laskey wrote: >> No longer needed > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into 8265279 > - RandomGeneratorFactory.all(Class category) no longer needed > - Remove extraneous references to makeXXXSpliterator > - Move makeXXXSpliterator methods to RandomSupport > - change static final from 'proxy' to 'PROXY' > - Make makeXXXSpliterator final > - Move makeXXXSpilterator from public (@hidden) to protected. No API change. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3516 From jlaskey at openjdk.java.net Tue May 4 13:29:51 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 4 May 2021 13:29:51 GMT Subject: Integrated: 8265279: Remove unused RandomGeneratorFactory.all(Class category) In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 12:48:35 GMT, Jim Laskey wrote: > No longer needed This pull request has now been integrated. Changeset: 770dfc1e Author: Jim Laskey URL: https://git.openjdk.java.net/jdk/commit/770dfc1ec4fe28bc73612c8b0dd8423dd49e1597 Stats: 25 lines in 1 file changed: 0 ins; 25 del; 0 mod 8265279: Remove unused RandomGeneratorFactory.all(Class category) Reviewed-by: rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/3516 From vtewari at openjdk.java.net Tue May 4 13:36:52 2021 From: vtewari at openjdk.java.net (Vyom Tewari) Date: Tue, 4 May 2021 13:36:52 GMT Subject: RFR: 8260621: (jrtfs) ThreadLocal memory leak in ImageBufferCache when using jrtfs In-Reply-To: References: Message-ID: <7kgaiLEPw2oG60RjkK5Nw-chAVLHZCILkQ4J6rSHctA=.944bd2da-2bad-4119-909a-27d14c335eba@github.com> On Tue, 4 May 2021 09:05:38 GMT, Athijegannathan Sundararajan wrote: > Instead of BufferReference class, Map.Entry is used as pair implementation. > This avoids the metaspace leak seen via thread local. looks OK to me. ------------- Marked as reviewed by vtewari (Committer). PR: https://git.openjdk.java.net/jdk/pull/3849 From alanb at openjdk.java.net Tue May 4 14:09:59 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 4 May 2021 14:09:59 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes In-Reply-To: References: Message-ID: <9tQtXd_Kt0D-zQJBlR0pMYnLewa-72ZS3NqmQ8sQjLg=.c5d0a1ca-86a1-4ecd-9c96-64df3e79e7d1@github.com> On Mon, 3 May 2021 20:33:23 GMT, Brian Burkhalter wrote: > Please consider this request to override the `java.io.InputStream` methods `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more performant implementations. The method overrides attempt to read all requested bytes into a single array of the required size rather than composing the result from a sequence of smaller arrays. An example of the performance improvements is as follows. > > **readAllBytes** > Before > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 2412.031 ? 7.309 ops/s > ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 212.181 ? 0.369 ops/s > ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 19.860 ? 0.048 ops/s > ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.298 ? 0.183 ops/s > > After > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 8218.473 ? 43.425 ops/s > ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 302.781 ? 1.273 ops/s > ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 22.461 ? 0.084 ops/s > ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.502 ? 0.003 ops/s > > > **readNBytes** > > `N = file_size / 2` > > Before > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 5585.500 ? 153.353 ops/s > ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 436.164 ? 1.104 ops/s > ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 40.167 ? 0.141 ops/s > ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 3.291 ? 0.211 ops/s > > > After > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 15463.210 ? 66.045 ops/s > ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 561.752 ? 0.951 ops/s > ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 45.043 ? 0.102 ops/s > ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 4.629 ? 0.035 ops/s src/java.base/share/classes/java/io/FileInputStream.java line 342: > 340: > 341: private native long length() throws IOException; > 342: private native long position() throws IOException; Can you confirm that you've tested with special files? It's very likely that there will be cases where lseek will fail. ------------- PR: https://git.openjdk.java.net/jdk/pull/3845 From alanb at openjdk.java.net Tue May 4 14:13:51 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 4 May 2021 14:13:51 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem In-Reply-To: References: Message-ID: On Tue, 4 May 2021 13:07:34 GMT, Jason Zaugg wrote: > If the given Path represents a file, use the overload of read defined > in FileChannel that accepts an explicit position and avoid serializing > reads. > > Note: The underlying NIO implementation is not required to implement > FileChannel.read(ByteBuffer, long) concurrently; Windows still appears > to lock, as it returns true for NativeDispatcher.needsPositionLock. > > > On MacOS X, the enclosed benchmark improves from: > > > Benchmark Mode Cnt Score Error Units > ZipFileSystemBenchmark.read avgt 10 75.311 ? 3.301 ms/op > > > To: > > > Benchmark Mode Cnt Score Error Units > ZipFileSystemBenchmark.read avgt 10 12.520 ? 0.875 ms/op src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 2223: > 2221: synchronized (zfch) { > 2222: n = zfch.position(pos).read(bb); > 2223: } @LanceAndersen Are you planning to look at this? Do you mind checking the async close case to make sure that the synchronization isn't masking anything? Also just to point out that pattern matching for instanceof ca be used here. ------------- PR: https://git.openjdk.java.net/jdk/pull/3853 From alanb at openjdk.java.net Tue May 4 14:24:56 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 4 May 2021 14:24:56 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v10] In-Reply-To: <-ForVlVYhV48Iw44ATh9hmpPNNDJsl3UZnte-RLtuRA=.44826ded-dbaa-4b8a-b58e-473f8ce4a991@github.com> References: <-ForVlVYhV48Iw44ATh9hmpPNNDJsl3UZnte-RLtuRA=.44826ded-dbaa-4b8a-b58e-473f8ce4a991@github.com> Message-ID: On Tue, 4 May 2021 12:05:15 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://openjdk.java.net/jeps/412 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Tweak comment in Module::enableNativeAccess src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 112: > 110: Module module = currentClass.getModule(); > 111: if (!SharedSecrets.getJavaLangAccess().isEnableNativeAccess(module)) { > 112: throw new IllegalCallerException("Illegal native access from module: " + module); You may want to drop "module" from the exception message as Module::toString is specified to return "module XXXX" or "unnamed module XXXX" so you'll end up duplication "module" in the message. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From alanb at openjdk.java.net Tue May 4 14:24:55 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 4 May 2021 14:24:55 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v7] In-Reply-To: <6prALGyA4mz4fP09-t2OrUtApa_WW7iRKsw2lhmilUA=.3ac938b7-422f-4a3d-942b-16bd8c5fd3c6@github.com> References: <6prALGyA4mz4fP09-t2OrUtApa_WW7iRKsw2lhmilUA=.3ac938b7-422f-4a3d-942b-16bd8c5fd3c6@github.com> Message-ID: On Tue, 4 May 2021 12:01:44 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 34: >> >>> 32: import java.util.Set; >>> 33: >>> 34: public final class IllegalNativeAccessChecker { >> >> Are you sure about the name of the this class? It doesn't do any checking and it's not concerned with "illegal native access" either, instead it just provides access to the names of modules that have been granted native access. > > I've decided to drop this class and move the logic in ModuleBootstrap. To handle unnamed modules, I had to piggy back on the special static ALL_UNNAMED module and set the flag there when decoding the command line option. This seems to be consistent with what is done in other areas. Good, this looks much simpler now. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Tue May 4 14:37:25 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 4 May 2021 14:37:25 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v11] In-Reply-To: References: Message-ID: > 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://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix message string in Reflection::ensureNativeAccess ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/2a31da40..72eb9bbc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From asemenyuk at openjdk.java.net Tue May 4 15:14:51 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 4 May 2021 15:14:51 GMT Subject: RFR: JDK-8266227: Fix help text for --mac-signing-keychain In-Reply-To: <-UNmpEVvS4xw89IjWDR7tIpjoNNBS3c9hq_L1TeTEvw=.5eba417e-10ef-4d06-a54c-88a93d177b17@github.com> References: <-UNmpEVvS4xw89IjWDR7tIpjoNNBS3c9hq_L1TeTEvw=.5eba417e-10ef-4d06-a54c-88a93d177b17@github.com> Message-ID: On Fri, 30 Apr 2021 15:25:13 GMT, Andy Herrick wrote: > JDK-8266227: Fix help text for --mac-signing-keychain Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3819 From sirinath1978m at gmail.com Tue May 4 16:14:42 2021 From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena) Date: Tue, 4 May 2021 21:44:42 +0530 Subject: Fast and cheap (Double|Float)::toString Java algorithm In-Reply-To: References: Message-ID: Hello, I hope everything is well with you. Due to other commitments this work has stalled. I was planning to implement: - fast to string conversion - fast string parsing - fast formatting - fast search - fast sort - fast templating - fast buffers The code I have done so far is here: https://github.com/sirinath/moby Wondering if someone can take this forward until I have more time in my hand. Suminda On Sat, 6 Feb 2021 at 09:50, Suminda Sirinath Salpitikorala Dharmasena < sirinath1978m at gmail.com> wrote: > Hello, > > I am working on a port of DragonBox to Java. If there is interest in > contributing this is most welcome. > > Suminda > > On Fri, 5 Feb 2021 at 21:51, Raffaello Giulietti < > raffaello.giulietti at gmail.com> wrote: > >> Hello, >> >> as a reminder, a Java implementation of Schubfach [1] intended to >> replace the current slow and expensive OpenJDK (Double|Float)::toString >> algorithm has been discussed, presented and contributed to this mailing >> list in several posts. The last implementation is available in pre-Skara >> webrev form, as referenced in [2]. On my laptop hardware, the speedup >> factor is 17.7x wrt OpenJDK. >> >> >> >> Recently, Alexander Bolz translated Schubfach to C++ for the purpose of >> comparing the performance of several bin2dec floating-point numbers >> algorithms [3]. >> >> In the meantime, Junekey Jeon implemented and perfected his own >> Dragonbox in C++, a new algorithm based on Schubfach [4]. From [5]: "In >> addition to the core idea of Schubfach, Dragonbox utilizes some >> Grisu-like ideas to minimize the number of expensive 128-bit ? 64-bit >> multiplications, at the cost of having more branches and >> divisions-by-constants." >> >> In the C++ ecosystem, Schubfach has been the fastest known algorithm >> before being gently pushed aside by Dragonbox, as can be seen in the >> graphs in [3]. >> >> >> >> While developing Schubfach back in 2018, I experimented myself with >> blending core Schubfach with my own earlier algorithm similar to Grisu. >> However, probably due to uncontrollable JIT compilation behavior, I >> could not observe any benefit. On the contrary, I measured performance >> drops probably because of the added complexity, which is public enemy >> nr. 1 for JIT compilers. Therefore, I opted for the simpler current >> design that seemed more suitable for (the then 2018 version of) C2. >> >> >> >> I hope this can somehow revive this community's interest and confidence >> toward Schubfach to definitely supplant the current expensive >> (Double|Float)::toString algorithm. >> >> >> Greetings >> Raffaello >> >> ---- >> >> [1] https://drive.google.com/open?id=1luHhyQF9zKlM8yJ1nebU0OgVYhfC6CBN >> [2] >> >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065297.html >> [3] https://github.com/abolz/Drachennest >> [4] https://github.com/jk-jeon/dragonbox >> [5] >> https://github.com/jk-jeon/dragonbox/blob/master/other_files/Dragonbox.pdf >> > From psandoz at openjdk.java.net Tue May 4 16:29:08 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 4 May 2021 16:29:08 GMT Subject: RFR: 8266317: Vector API enhancements Message-ID: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com> This PR contains API and implementation changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. Enhancements are made to the API for the support of operations on characters, such as for UTF-8 character decoding. Specifically, methods for loading/storing a `short` vector from/to a `char[]` array, and new vector comparison operators for unsigned comparisons with integral vectors. The x64 implementation is enhanced to supported unsigned comparisons. Enhancements are made to the API for loading/storing a `byte` vector from/to a `boolean[]` array. The testing of loads/stores can be expanded for scatter/gather, but before doing that i think some refactoring of the tests is required to reposition tests in the right classes. I would like to do that work after integration of the PR. ------------- Commit messages: - Minor clarifications to the specification. - 8266317: Vector API enhancements Changes: https://git.openjdk.java.net/jdk/pull/3803/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3803&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266317 Stats: 10002 lines in 121 files changed: 9070 ins; 190 del; 742 mod Patch: https://git.openjdk.java.net/jdk/pull/3803.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3803/head:pull/3803 PR: https://git.openjdk.java.net/jdk/pull/3803 From psandoz at openjdk.java.net Tue May 4 16:29:08 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 4 May 2021 16:29:08 GMT Subject: RFR: 8266317: Vector API enhancements In-Reply-To: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com> References: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com> Message-ID: <6XDATQRilzomvEwoFXNENdi4dWlYjrw0TLXNJPWs6Q0=.68f2de4f-a964-45ee-8bf2-a9720dfbff35@github.com> On Thu, 29 Apr 2021 21:13:38 GMT, Paul Sandoz wrote: > This PR contains API and implementation changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Enhancements are made to the API for the support of operations on characters, such as for UTF-8 character decoding. Specifically, methods for loading/storing a `short` vector from/to a `char[]` array, and new vector comparison operators for unsigned comparisons with integral vectors. The x64 implementation is enhanced to supported unsigned comparisons. > > Enhancements are made to the API for loading/storing a `byte` vector from/to a `boolean[]` array. > > The testing of loads/stores can be expanded for scatter/gather, but before doing that i think some refactoring of the tests is required to reposition tests in the right classes. I would like to do that work after integration of the PR. All tests pass for tier1,tier2,tier3 for build profiles linux-x64, linux-aarch64, macosx-x64, and windows-x64. ------------- PR: https://git.openjdk.java.net/jdk/pull/3803 From naoto at openjdk.java.net Tue May 4 17:33:54 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 4 May 2021 17:33:54 GMT Subject: Integrated: 8265989: System property for the native character encoding name In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 22:24:31 GMT, Naoto Sato wrote: > After some internal discussion, we thought it was good to expose the native environment's default character encoding, which Charset.defaultCharset() is currently based on. This way applications will have a better migration path after the [JEP 400](https://openjdk.java.net/jeps/400) is implemented, in which Charset.defaultCharset() will return UTF-8, but the value of this new system property will remain intact. A [CSR](https://bugs.openjdk.java.net/browse/JDK-8266075) has been filed with more detailed information. This pull request has now been integrated. Changeset: 4e96b310 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/4e96b310425de541675b28493fdbe195780623c3 Stats: 32 lines in 4 files changed: 23 ins; 3 del; 6 mod 8265989: System property for the native character encoding name Reviewed-by: iris, joehw, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/3777 From bpb at openjdk.java.net Tue May 4 17:48:51 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 4 May 2021 17:48:51 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes In-Reply-To: <9tQtXd_Kt0D-zQJBlR0pMYnLewa-72ZS3NqmQ8sQjLg=.c5d0a1ca-86a1-4ecd-9c96-64df3e79e7d1@github.com> References: <9tQtXd_Kt0D-zQJBlR0pMYnLewa-72ZS3NqmQ8sQjLg=.c5d0a1ca-86a1-4ecd-9c96-64df3e79e7d1@github.com> Message-ID: On Tue, 4 May 2021 14:07:18 GMT, Alan Bateman wrote: >> Please consider this request to override the `java.io.InputStream` methods `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more performant implementations. The method overrides attempt to read all requested bytes into a single array of the required size rather than composing the result from a sequence of smaller arrays. An example of the performance improvements is as follows. >> >> **readAllBytes** >> Before >> >> Benchmark (length) Mode Cnt Score Error Units >> ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 2412.031 ? 7.309 ops/s >> ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 212.181 ? 0.369 ops/s >> ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 19.860 ? 0.048 ops/s >> ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.298 ? 0.183 ops/s >> >> After >> >> Benchmark (length) Mode Cnt Score Error Units >> ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 8218.473 ? 43.425 ops/s >> ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 302.781 ? 1.273 ops/s >> ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 22.461 ? 0.084 ops/s >> ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.502 ? 0.003 ops/s >> >> >> **readNBytes** >> >> `N = file_size / 2` >> >> Before >> >> Benchmark (length) Mode Cnt Score Error Units >> ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 5585.500 ? 153.353 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 436.164 ? 1.104 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 40.167 ? 0.141 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 3.291 ? 0.211 ops/s >> >> >> After >> >> Benchmark (length) Mode Cnt Score Error Units >> ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 15463.210 ? 66.045 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 561.752 ? 0.951 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 45.043 ? 0.102 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 4.629 ? 0.035 ops/s > > src/java.base/share/classes/java/io/FileInputStream.java line 342: > >> 340: >> 341: private native long length() throws IOException; >> 342: private native long position() throws IOException; > > Can you confirm that you've tested with special files? It's very likely that there will be cases where lseek will fail. Only regular files this far. Are there any particular special files which would be of interest? ------------- PR: https://git.openjdk.java.net/jdk/pull/3845 From bpb at openjdk.java.net Tue May 4 19:04:56 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 4 May 2021 19:04:56 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes In-Reply-To: References: <9tQtXd_Kt0D-zQJBlR0pMYnLewa-72ZS3NqmQ8sQjLg=.c5d0a1ca-86a1-4ecd-9c96-64df3e79e7d1@github.com> Message-ID: On Tue, 4 May 2021 17:46:15 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/io/FileInputStream.java line 342: >> >>> 340: >>> 341: private native long length() throws IOException; >>> 342: private native long position() throws IOException; >> >> Can you confirm that you've tested with special files? It's very likely that there will be cases where lseek will fail. > > Only regular files this far. Are there any particular special files which would be of interest? On `/proc/cpuinfo` for example, `fstat()` succeeds but `st_size` in `struct stat` is zero. The correct position is however returned by `lseek()`. Apparently this proposal needs to be reworked to expect size zero when the size is in fact non-zero. ------------- PR: https://git.openjdk.java.net/jdk/pull/3845 From raffaello.giulietti at gmail.com Tue May 4 19:34:26 2021 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 4 May 2021 21:34:26 +0200 Subject: Fast and cheap (Double|Float)::toString Java algorithm In-Reply-To: References: Message-ID: <00199d26-b2b6-3612-b5d7-9361a3901e64@gmail.com> Hi Suminda, as I explained back in February, I already experimented blending Schubfach with a variant of Grisu back in 2018. Contrary to my expectations, I observed noticeable performance drops wrt pure Schubfach. I didn't explore any further, but I think that the more complex control logic required by the blend makes it harder for a JIT compiler to optimize. Thus, I prefer to wait until my own contribution has been reviewed and integrated (if at all) before adding complexity that might not be beneficial in Java. (Junekey measured that a blend *is* beneficial in C++, though. But it's somehow hard to compare a static AOT compilation, as done in C++, and a JIT compilation, as done on the JVM.) Greetings Raffaello On 2021-05-04 18:14, Suminda Sirinath Salpitikorala Dharmasena wrote: > Hello, > > I hope everything is?well with you. > > Due to other commitments this work has stalled. > > I was planning to implement: > - fast to string conversion > - fast string parsing > - fast formatting > - fast search > - fast sort > - fast templating > - fast buffers > > The code I have done so far is here: https://github.com/sirinath/moby > > > Wondering if someone can take this forward until I have more time in my > hand. > > Suminda > > On Sat, 6 Feb 2021 at 09:50, Suminda Sirinath Salpitikorala Dharmasena > > wrote: > > Hello, > > I am working on a port of DragonBox to Java. If there is interest in > contributing this is most welcome. > > Suminda > > On Fri, 5 Feb 2021 at 21:51, Raffaello Giulietti > > wrote: > > Hello, > > as a reminder, a Java implementation of Schubfach [1] intended to > replace the current slow and expensive OpenJDK > (Double|Float)::toString > algorithm has been discussed, presented and contributed to this > mailing > list in several posts. The last implementation is available in > pre-Skara > webrev form, as referenced in [2]. On my laptop hardware, the > speedup > factor is 17.7x wrt OpenJDK. > > > > Recently, Alexander Bolz translated Schubfach to C++ for the > purpose of > comparing the performance of several bin2dec floating-point numbers > algorithms [3]. > > In the meantime, Junekey Jeon implemented and perfected his own > Dragonbox in C++, a new algorithm based on Schubfach [4]. From > [5]: "In > addition to the core idea of Schubfach, Dragonbox utilizes some > Grisu-like ideas to minimize the number of expensive 128-bit ? > 64-bit > multiplications, at the cost of having more branches and > divisions-by-constants." > > In the C++ ecosystem, Schubfach has been the fastest known > algorithm > before being gently pushed aside by Dragonbox, as can be seen in > the > graphs in [3]. > > > > While developing Schubfach back in 2018, I experimented myself with > blending core Schubfach with my own earlier algorithm similar to > Grisu. > However, probably due to uncontrollable JIT compilation behavior, I > could not observe any benefit. On the contrary, I measured > performance > drops probably because of the added complexity, which is public > enemy > nr. 1 for JIT compilers. Therefore, I opted for the simpler current > design that seemed more suitable for (the then 2018 version of) C2. > > > > I hope this can somehow revive this community's interest and > confidence > toward Schubfach to definitely supplant the current expensive > (Double|Float)::toString algorithm. > > > Greetings > Raffaello > > ---- > > [1] > https://drive.google.com/open?id=1luHhyQF9zKlM8yJ1nebU0OgVYhfC6CBN > > [2] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065297.html > > [3] https://github.com/abolz/Drachennest > > [4] https://github.com/jk-jeon/dragonbox > > [5] > https://github.com/jk-jeon/dragonbox/blob/master/other_files/Dragonbox.pdf > > From herrick at openjdk.java.net Tue May 4 20:13:58 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 4 May 2021 20:13:58 GMT Subject: Integrated: JDK-8266227: Fix help text for --mac-signing-keychain In-Reply-To: <-UNmpEVvS4xw89IjWDR7tIpjoNNBS3c9hq_L1TeTEvw=.5eba417e-10ef-4d06-a54c-88a93d177b17@github.com> References: <-UNmpEVvS4xw89IjWDR7tIpjoNNBS3c9hq_L1TeTEvw=.5eba417e-10ef-4d06-a54c-88a93d177b17@github.com> Message-ID: <7afrlLNSxKVZaZK-OOVeR1fO4uUcWTxxmHNW4ozy9u8=.c4ef7e56-5b51-492c-8519-43841e721f1c@github.com> On Fri, 30 Apr 2021 15:25:13 GMT, Andy Herrick wrote: > JDK-8266227: Fix help text for --mac-signing-keychain This pull request has now been integrated. Changeset: c53dee74 Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/c53dee7480858811c32ac718f5a27a00e3483a38 Stats: 89 lines in 3 files changed: 27 ins; 5 del; 57 mod 8266227: Fix help text for --mac-signing-keychain Reviewed-by: almatvee, asemenyuk ------------- PR: https://git.openjdk.java.net/jdk/pull/3819 From bpb at openjdk.java.net Tue May 4 20:18:25 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 4 May 2021 20:18:25 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes [v2] In-Reply-To: References: Message-ID: > Please consider this request to override the `java.io.InputStream` methods `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more performant implementations. The method overrides attempt to read all requested bytes into a single array of the required size rather than composing the result from a sequence of smaller arrays. An example of the performance improvements is as follows. > > **readAllBytes** > Before > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 2412.031 ? 7.309 ops/s > ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 212.181 ? 0.369 ops/s > ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 19.860 ? 0.048 ops/s > ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.298 ? 0.183 ops/s > > After > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 8218.473 ? 43.425 ops/s > ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 302.781 ? 1.273 ops/s > ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 22.461 ? 0.084 ops/s > ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.502 ? 0.003 ops/s > > > **readNBytes** > > `N = file_size / 2` > > Before > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 5585.500 ? 153.353 ops/s > ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 436.164 ? 1.104 ops/s > ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 40.167 ? 0.141 ops/s > ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 3.291 ? 0.211 ops/s > > > After > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 15463.210 ? 66.045 ops/s > ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 561.752 ? 0.951 ops/s > ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 45.043 ? 0.102 ops/s > ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 4.629 ? 0.035 ops/s Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8264777: Handle cases where length() returns zero ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3845/files - new: https://git.openjdk.java.net/jdk/pull/3845/files/8b568686..98a03a55 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3845&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3845&range=00-01 Stats: 25 lines in 1 file changed: 16 ins; 2 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3845/head:pull/3845 PR: https://git.openjdk.java.net/jdk/pull/3845 From bpb at openjdk.java.net Tue May 4 20:18:25 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 4 May 2021 20:18:25 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes [v2] In-Reply-To: References: <9tQtXd_Kt0D-zQJBlR0pMYnLewa-72ZS3NqmQ8sQjLg=.c5d0a1ca-86a1-4ecd-9c96-64df3e79e7d1@github.com> Message-ID: <_i5jAuxQQbKqnUpaAe4ZO3mFiwHRm-QRTlBqBA-2OoU=.833d7b89-a6ad-44c8-bdb1-8e502772a5b7@github.com> On Tue, 4 May 2021 19:01:45 GMT, Brian Burkhalter wrote: >> Only regular files this far. Are there any particular special files which would be of interest? > > On `/proc/cpuinfo` for example, `fstat()` succeeds but `st_size` in `struct stat` is zero. The correct position is however returned by `lseek()`. Apparently this proposal needs to be reworked to expect size zero when the size is in fact non-zero. Updated to handle `length() == 0` case. Not sure however whether for this case it might not be better just to fall back to `super.readXBytes()` instead. ------------- PR: https://git.openjdk.java.net/jdk/pull/3845 From jlaskey at openjdk.java.net Tue May 4 21:16:07 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 4 May 2021 21:16:07 GMT Subject: RFR: JDK-8266527 RandomTestCoverage.java failing due to API removal Message-ID: RandomTestCoverage.java was overlooked when doing local test. Apologies. ------------- Commit messages: - Adjust testing for API removal Changes: https://git.openjdk.java.net/jdk/pull/3867/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3867&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266527 Stats: 15 lines in 1 file changed: 5 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3867.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3867/head:pull/3867 PR: https://git.openjdk.java.net/jdk/pull/3867 From rriggs at openjdk.java.net Tue May 4 21:21:58 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 4 May 2021 21:21:58 GMT Subject: RFR: JDK-8266527 RandomTestCoverage.java failing due to API removal In-Reply-To: References: Message-ID: On Tue, 4 May 2021 21:09:59 GMT, Jim Laskey wrote: > RandomTestCoverage.java was overlooked when doing local test. Apologies. Good to clean those out. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3867 From jlaskey at openjdk.java.net Tue May 4 21:21:58 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 4 May 2021 21:21:58 GMT Subject: Integrated: JDK-8266527 RandomTestCoverage.java failing due to API removal In-Reply-To: References: Message-ID: On Tue, 4 May 2021 21:09:59 GMT, Jim Laskey wrote: > RandomTestCoverage.java was overlooked when doing local test. Apologies. This pull request has now been integrated. Changeset: f00b70e2 Author: Jim Laskey URL: https://git.openjdk.java.net/jdk/commit/f00b70e2caaa9c2bb49bb9eae49a29ffbbf87af8 Stats: 15 lines in 1 file changed: 5 ins; 0 del; 10 mod 8266527: RandomTestCoverage.java failing due to API removal Reviewed-by: rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/3867 From lancea at openjdk.java.net Tue May 4 21:22:14 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 4 May 2021 21:22:14 GMT Subject: RFR: 8266460: java.io tests fail on null stream with upgraded jtreg/TestNG Message-ID: Hi all, This fix addresses a change in TestNG behavior for the Before/AfterGroups annotations that was introduced via https://github.com/cbeust/testng/pull/2167. The tests have been verified against the latest TestNG release and continue to run with the current TestNG release used by jtreg ------------- Commit messages: - remove trailing space - Updates for TestNG 7.4 Changes: https://git.openjdk.java.net/jdk/pull/3866/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3866&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266460 Stats: 122 lines in 4 files changed: 12 ins; 24 del; 86 mod Patch: https://git.openjdk.java.net/jdk/pull/3866.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3866/head:pull/3866 PR: https://git.openjdk.java.net/jdk/pull/3866 From sviswanathan at openjdk.java.net Tue May 4 22:15:59 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 4 May 2021 22:15:59 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 21:11:26 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. >> >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> Looking forward to your review and feedback. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge master > - remove whitespace > - Merge master > - Small fix > - cleanup > - x86 short vector math optimization for Vector API @vnkozlov @AlanBateman @rose00 Looking forward to your review and feedback. This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator](https://openjdk.java.net/jeps/414), in preparation for when targeted. ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From jzaugg at openjdk.java.net Tue May 4 22:24:20 2021 From: jzaugg at openjdk.java.net (Jason Zaugg) Date: Tue, 4 May 2021 22:24:20 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v2] In-Reply-To: References: Message-ID: > If the given Path represents a file, use the overload of read defined > in FileChannel that accepts an explicit position and avoid serializing > reads. > > Note: The underlying NIO implementation is not required to implement > FileChannel.read(ByteBuffer, long) concurrently; Windows still appears > to lock, as it returns true for NativeDispatcher.needsPositionLock. > > > On MacOS X, the enclosed benchmark improves from: > > > Benchmark Mode Cnt Score Error Units > ZipFileSystemBenchmark.read avgt 10 75.311 ? 3.301 ms/op > > > To: > > > Benchmark Mode Cnt Score Error Units > ZipFileSystemBenchmark.read avgt 10 12.520 ? 0.875 ms/op Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: Use pattern matching instanceof ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3853/files - new: https://git.openjdk.java.net/jdk/pull/3853/files/b7b6f9a8..0859d2d6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3853&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3853&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3853/head:pull/3853 PR: https://git.openjdk.java.net/jdk/pull/3853 From bpb at openjdk.java.net Tue May 4 22:38:59 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 4 May 2021 22:38:59 GMT Subject: RFR: 8266460: java.io tests fail on null stream with upgraded jtreg/TestNG In-Reply-To: References: Message-ID: On Tue, 4 May 2021 20:45:43 GMT, Lance Andersen wrote: > Hi all, > > This fix addresses a change in TestNG behavior for the Before/AfterGroups annotations that was introduced via https://github.com/cbeust/testng/pull/2167. The tests have been verified against the latest TestNG release and continue to run with the current TestNG release used by jtreg test/jdk/java/io/InputStream/NullInputStream.java line 33: > 31: import java.io.InputStream; > 32: > 33: import static org.testng.Assert.*; Would it not be more standard to put the new imports just after this import? Same comment applies in the other files. ------------- PR: https://git.openjdk.java.net/jdk/pull/3866 From lancea at openjdk.java.net Tue May 4 22:46:50 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 4 May 2021 22:46:50 GMT Subject: RFR: 8266460: java.io tests fail on null stream with upgraded jtreg/TestNG In-Reply-To: References: Message-ID: On Tue, 4 May 2021 22:36:29 GMT, Brian Burkhalter wrote: >> Hi all, >> >> This fix addresses a change in TestNG behavior for the Before/AfterGroups annotations that was introduced via https://github.com/cbeust/testng/pull/2167. The tests have been verified against the latest TestNG release and continue to run with the current TestNG release used by jtreg > > test/jdk/java/io/InputStream/NullInputStream.java line 33: > >> 31: import java.io.InputStream; >> 32: >> 33: import static org.testng.Assert.*; > > Would it not be more standard to put the new imports just after this import? Same comment applies in the other files. That's IntelliJ magic. I can update if you prefer and can let IntelliJ optimize all of the imports ------------- PR: https://git.openjdk.java.net/jdk/pull/3866 From bpb at openjdk.java.net Tue May 4 22:46:51 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 4 May 2021 22:46:51 GMT Subject: RFR: 8266460: java.io tests fail on null stream with upgraded jtreg/TestNG In-Reply-To: References: Message-ID: On Tue, 4 May 2021 22:42:57 GMT, Lance Andersen wrote: >> test/jdk/java/io/InputStream/NullInputStream.java line 33: >> >>> 31: import java.io.InputStream; >>> 32: >>> 33: import static org.testng.Assert.*; >> >> Would it not be more standard to put the new imports just after this import? Same comment applies in the other files. > > That's IntelliJ magic. I can update if you prefer and can let IntelliJ optimize all of the imports Ah. I was just thinking of consistency with other tests. Up to you. ------------- PR: https://git.openjdk.java.net/jdk/pull/3866 From bpb at openjdk.java.net Tue May 4 22:53:49 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 4 May 2021 22:53:49 GMT Subject: RFR: 8266460: java.io tests fail on null stream with upgraded jtreg/TestNG In-Reply-To: References: Message-ID: On Tue, 4 May 2021 20:45:43 GMT, Lance Andersen wrote: > Hi all, > > This fix addresses a change in TestNG behavior for the Before/AfterGroups annotations that was introduced via https://github.com/cbeust/testng/pull/2167. The tests have been verified against the latest TestNG release and continue to run with the current TestNG release used by jtreg Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3866 From lancea at openjdk.java.net Tue May 4 22:53:49 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 4 May 2021 22:53:49 GMT Subject: RFR: 8266460: java.io tests fail on null stream with upgraded jtreg/TestNG In-Reply-To: References: Message-ID: On Tue, 4 May 2021 22:44:18 GMT, Brian Burkhalter wrote: >> That's IntelliJ magic. I can update if you prefer and can let IntelliJ optimize all of the imports > > Ah. I was just thinking of consistency with other tests. Up to you. I think your milage will vary depending on the author and the IDE being used. My primary concern was to address the issue for the failing test and Intellij arranged the imports as they are above. I guess I am less concerned about the imports as I think in some cases it comes to personal preference. So I would prefer to leave as is if you are OK :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/3866 From bpb at openjdk.java.net Tue May 4 22:53:50 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 4 May 2021 22:53:50 GMT Subject: RFR: 8266460: java.io tests fail on null stream with upgraded jtreg/TestNG In-Reply-To: References: Message-ID: On Tue, 4 May 2021 22:49:22 GMT, Lance Andersen wrote: >> Ah. I was just thinking of consistency with other tests. Up to you. > > I think your milage will vary depending on the author and the IDE being used. My primary concern was to address the issue for the failing test and Intellij arranged the imports as they are above. I guess I am less concerned about the imports as I think in some cases it comes to personal preference. > > So I would prefer to leave as is if you are OK :-) I think that's fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/3866 From darcy at openjdk.java.net Tue May 4 23:14:49 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 4 May 2021 23:14:49 GMT Subject: RFR: 8244146: javac changes for JEP 306 In-Reply-To: References: Message-ID: On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy wrote: > 8244146: javac changes for JEP 306 For core-libs, under JEP 306 strictfp would be a no-op under 17. Therefore, the few uses of the strictfp modifier in the base module can be removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3831 From stuart.marks at oracle.com Tue May 4 23:17:24 2021 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 4 May 2021 16:17:24 -0700 Subject: [External] : Re: ReversibleCollection proposal In-Reply-To: References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com> <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr> <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr> <839698479.422241.1619098212148.JavaMail.zimbra@u-pem.fr> <7457433b-0836-f45e-4b51-4c2ecdf7e7da@oracle.com> <427897615.2057286.1619612437790.JavaMail.zimbra@u-pem.fr> Message-ID: The line of discussion here was introduced by Remi, who was making an argument of the form "introducing a type cannot solve this particular problem, therefore, introducing a new type is not useful at all." I was providing an example of where the new type is useful as a method parameter. That's all. > Have you considered the alternative of a collection providing a Reversed view of itself, in the same sense that unmodifiable collections are views of an underlying collection? The proposal does define ReversibleCollection::reversed as providing a reversed view, through which modifications to the underlying collection are visible, and to which modifications are written through to the underlying collection. Or are you talking about something different? s'marks On 4/30/21 4:15 PM, Alan Snyder wrote: > It sounds like the items processing maintainer would be looking for OrderedCollection and might or might not find ReversibleCollection. :-) > > I suspect you would agree that OrderedCollection by itself is too weak to justify being a type. It?s basically Iterable with the extra bit that the iteration order is not an implementation artifact. > > In this example, using the type system to detect a bug like the old bug seems like overkill. Even if the parameter were Ordered, it still might not be the *right* order. The maintainer of the client code needs to understand that. > > Suppose the items processor wants to require that the parameter collection not contain duplicates. Would you suggest adding a type for that? Clearly Set would be just as unnecessarily restrictive as List was for ordering. Absurdity approaches? > > The issue of Reversible remains, above and beyond Ordered. Have you considered the alternative of a collection providing a Reversed view of itself, in the same sense that unmodifiable collections are views of an underlying collection? > > Alan > > > >> On Apr 30, 2021, at 3:42 PM, Stuart Marks wrote: >> >> Consider the case of a large application or other system, one that's large enough to have lots of internal APIs, but that is built as a single unit, so release-to-release compatibility isn't an issue. Suppose there is some method >> >> processItemsInOrder(List items) >> >> that has to process items in the order in which they occur, because processing of later items might depend the processing of earlier ones. The maintainer of this API chose to accept a List as a parameter, because it's a common interface and it's clearly an ordered collection. >> >> Now consider a client that gets items from different places, keeping them in order, but removing duplicates. It might do something like this: >> >> var items = new LinkedHashSet(); >> items.addAll(getItemsFromSomeplace()); >> items.addAll(getItemsFromAnotherPlace()); >> items.addAll(getItemsFromSomeplaceElse()); >> processItemsInOrder(new ArrayList<>(items)); >> >> It turns out the copying of the items into an ArrayList is a performance bottleneck, so the maintainer of the client code asks the maintainer of the items processing code to change the API to accept Collection instead. >> >> The items processing maintainer demurs, recalling that the API *did* accept Collection in the past, and a bug where somebody accidentally passed a HashSet resulted in a customer escalation because of item processing irregularities. In the aftermath of that escalation, the API was changed to List. The client maintainer reluctantly pursues alternatives for generating a deduplicated List. >> >> But wait! Those Java guys added a ReversibleCollection interface in Java N. It has the desired property of being ordered, and conveniently it's a supertype of both List and LinkedHashSet. The items processing maintainer adjusts the API to consume ReversibleCollection, and the client maintainer removes the temporary ArrayList, and everybody is happy. >> >> s'marks >> > From almatvee at openjdk.java.net Tue May 4 23:38:54 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 4 May 2021 23:38:54 GMT Subject: Integrated: 8266179: [macos] jpackage should specify architecture for produced pkg files In-Reply-To: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> References: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com> Message-ID: <05bKDjsm9CBsS8R6qQOvNaRvaRTzRBqy3QKetdRc0VU=.d41d97f2-2177-4fc2-a9e6-21c0b8315c2c@github.com> On Fri, 30 Apr 2021 04:22:37 GMT, Alexander Matveev wrote: > jpackage should specify architecture for produced PKG files via hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable on x64 without specifying hostArchitectures which is not correct and if install on arm Mac it will request Rosetta 2. With proposed fix by setting hostArchitectures="x86_x64" if installer contains x64 binaries, it will be installable on x64 Mac and will require Rosetta 2 on arm Mac. hostArchitectures will be set to arm64 if installer contain aarch64 binaries and will gave error when run on x64 Mac and will be installable on arm Mac without triggering installation of Rosetta 2. This pull request has now been integrated. Changeset: 2c53654b Author: Alexander Matveev URL: https://git.openjdk.java.net/jdk/commit/2c53654bf1140c7cd243598ebdbff9ca4b9c54ba Stats: 101 lines in 3 files changed: 100 ins; 0 del; 1 mod 8266179: [macos] jpackage should specify architecture for produced pkg files Reviewed-by: herrick, kcr, asemenyuk ------------- PR: https://git.openjdk.java.net/jdk/pull/3807 From stuart.marks at oracle.com Wed May 5 00:00:03 2021 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 4 May 2021 17:00:03 -0700 Subject: [External] : Re: ReversibleCollection proposal In-Reply-To: <906317823.1426529.1619873859193.JavaMail.zimbra@u-pem.fr> References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com> <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr> <839698479.422241.1619098212148.JavaMail.zimbra@u-pem.fr> <7457433b-0836-f45e-4b51-4c2ecdf7e7da@oracle.com> <427897615.2057286.1619612437790.JavaMail.zimbra@u-pem.fr> <906317823.1426529.1619873859193.JavaMail.zimbra@u-pem.fr> Message-ID: On 5/1/21 5:57 AM, forax at univ-mlv.fr wrote: > I suppose the performance issue comes from the fact that traversing a LinkedHahSet is slow because it's a linked list ? > > You can replace a LinkedHashSet by a List + Set, the List keeps the values in order, the Set avoids duplicates. > > Using a Stream, it becomes > Stream.of(getItemsFromSomeplace(), getItemsFromAnotherPlace(), getItemsFromSomeplaceElse()) > .flatMap(List::stream) > .distinct() // use a Set internally > .collect(toList()); The problem with any example is that simplifying assumptions are necessary for showing the example, but those assumptions enable it to be easily picked apart. Of course, the example isn't just a particular example; it is a *template* for a whole space of possible examples. Consider the possibility that the items processing client needs to do some intermediate processing on the first group of items before adding the other groups. This might not be possible to do using streams. Use your imagination. > I think there are maybe some scenarios where ReversibleCollection can be useful, but they are rare, to the point where when there is a good scenario for it people will not recognize it because ReversibleCollection will not be part of their muscle memory. I'm certain that uses of RC/RS will be rare in the beginning, because they will be new, and people won't be familar with them. And then there will the people who say "I can't use them because I'm stuck on JDK 11 / 8 / 7 / 6 ...." It was the same thing with lambdas and streams in Java 8, with List.of() etc in Java 9, records in Java 16, etc. This wan't an argument not to add them, and it isn't an argument not to add RC/RS. > There is a real value to add methods like descendingSet/descendingList()/getFirst/getLast on existing collections, but we don't need a new interface (or two) for that. It depends on what you mean by "need". Sure, we could get away without this; after all, we've survived the past twenty years without it, so we could probably survive the next twenty years as well. It would indeed be useful to add various methods to List, Deque, SortedSet, and LinkedHashSet to provide a full set of methods on all of them. And it would also be nice to have those methods be similar to one another. An interface helps with that, but I agree, that's not really the reason to have an interface though. The reversed-view concept could also be added individually to the different places. A reverse-ordered List is a List, a reverse-ordered Deque is a Deque, a reverse-ordered SortedSet is a SortedSet, and a reverse-ordered LinkedHashSet is a ... ? And what is the type of the keySet of a LinkedHashMap, that enables one to (say) get the last element? After working with a system like this for a while, it begins to emerge that there is an abstraction missing from the collections framework, something like an "ordered collection". People have been missing this for quite a long time. The most recent example (which this proposal builds on) is Tagir's proposal from a year ago. And it's been asked about several times before that. ReversibleCollection fills in that missing abstraction. s'marks From sadayapalam at openjdk.java.net Wed May 5 05:30:03 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Wed, 5 May 2021 05:30:03 GMT Subject: RFR: 8244146: javac changes for JEP 306 In-Reply-To: References: Message-ID: <5yCDuEC96JotYPj3Q1krLkGcCxUW7tg7eo7sMS3zrMI=.85d104d8-35af-4973-9817-ef6d96107318@github.com> On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy wrote: > 8244146: javac changes for JEP 306 src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line 1704: > 1702: if (Feature.REDUNDANT_STRICTFP.allowedInSource(source)) > 1703: result = result & ~STRICTFP; > 1704: Nitpick: Doing in Rome as ... would mean this is better written as result &= ~STRICTFP; to be in harmony with the code in the vicinity Also I am OK with the feature-allowed-in-source-check, but wonder if it is an overkill for smaller focussed changes like this one. I will say I don't know what is the standard operating procedure. See that elsewhere in Lint.java you are doing if (source.compareTo(Source.JDK17) >= 0) { values.add(LintCategory.STRICTFP); } ------------- PR: https://git.openjdk.java.net/jdk/pull/3831 From sadayapalam at openjdk.java.net Wed May 5 05:34:50 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Wed, 5 May 2021 05:34:50 GMT Subject: RFR: 8244146: javac changes for JEP 306 In-Reply-To: References: Message-ID: On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy wrote: > 8244146: javac changes for JEP 306 src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 1769: > 1767: compiler.warn.strictfp=\ > 1768: as of release 17, all floating-point expressions are evaluated strictly and ''strictfp'' is not required > 1769: Nitpick: Three other uses of floating point in the same file use the non-hyphenated form. ------------- PR: https://git.openjdk.java.net/jdk/pull/3831 From stuart.marks at oracle.com Wed May 5 06:12:10 2021 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 4 May 2021 23:12:10 -0700 Subject: New convenience methods on Stream In-Reply-To: References: Message-ID: <0bbacfca-ebea-bf11-699a-c69d62619532@oracle.com> Hi Don, When evaluating new APIs I always find it helpful and educational to look for cases in real code where they might be applied, and what effect the API has at the call site. The search need not be exhaustive, but it's probably sufficient to find a number of representative examples. This does take some effort, though. For now I'll take a look at some examples where your first item can be applied: > 1. Stream contents into a mutable collection created by a Supplier. > > default > R toCollection(Supplier supplier) > { > return this.collect(Collectors.toCollection(supplier)); > } > > Usage Examples: > > HashSet set = stream.toCollection(HashSet::new); > TreeSet sortedSet = stream.toCollection(TreeSet::new); > ArrayDeque deque = stream.toCollection(ArrayDeque::new); Since I have the JDK handy I searched it for 'toCollection('. There are around 60 hits -- but note that 2/3 of these are in java.sql.rowset and refer to an unrelated API. Some are in comments, and some are the implementation of Collectors.toCollection itself, which leaves just 14 cases. Let's look at a few. # src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskPool.java:164 List opts = StreamSupport.stream(options.spliterator(), false) .collect(Collectors.toCollection(ArrayList::new)); Using the proposed API here would result in: List opts = StreamSupport.stream(options.spliterator(), false) .toCollection(ArrayList::new)); This makes the code a little bit nicer. A static import would also haved helped, though not quite as much as the new API: List opts = StreamSupport.stream(options.spliterator(), false) .collect(toCollection(ArrayList::new))); I also note that after some analysis of the usage of the resulting List, it's never modified -- indeed, it's used as the key of a Map -- so this could be replaced with the recently-added Stream::toList. # src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java:381 Set platforms = StreamSupport.stream(providers.spliterator(), false) .flatMap(provider -> StreamSupport.stream(provider.getSupportedPlatformNames() .spliterator(), false)) .collect(Collectors.toCollection(LinkedHashSet :: new)); (Sorry for line wrapping. This file has some long lines.) Again, using the proposal API would shorten things a bit, but it doesn't really make much difference within the overall context: Set platforms = StreamSupport.stream(providers.spliterator(), false) .flatMap(provider -> StreamSupport.stream(provider.getSupportedPlatformNames() .spliterator(), false)) .toCollection(LinkedHashSet :: new)); # src/java.logging/share/classes/java/util/logging/LogManager.java:2138 final Map> loggerConfigs = allKeys.collect(Collectors.groupingBy(ConfigProperty::getLoggerName, TreeMap::new, Collectors.toCollection(TreeSet::new))); This is an interesting case, as the toCollection() method is being used to produce a "downstream" collector passed to groupingBy(). Since the proposed API is on stream, it can't be used here. There are a few other cases like this where toCollection is used as a downstream collector, not as an argument to Stream::collect. # src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java:377 public List getAdditionalStylesheets() { return options.additionalStylesheets().stream() .map(ssf -> DocFile.createFileForInput(this, ssf)) .map(file -> DocPath.create(file.getName())) .collect(Collectors.toCollection(ArrayList::new)); } This is another place where the proposed API can be used straightforwardly: public List getAdditionalStylesheets() { return options.additionalStylesheets().stream() .map(ssf -> DocFile.createFileForInput(this, ssf)) .map(file -> DocPath.create(file.getName())) .toCollection(ArrayList::new)); } # src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/IndexBuilder.java:220 This is a slightly different case, as it uses a lambda to pass a comparator to a constructor instead of using a constructor reference. Before: public SortedSet getItems(DocTree.Kind kind) { Objects.requireNonNull(kind); return itemsByCategory.getOrDefault(IndexItem.Category.TAGS, Collections.emptySortedSet()).stream() .filter(i -> i.isKind(kind)) .collect(Collectors.toCollection(() -> new TreeSet<>(mainComparator))); } After: public SortedSet getItems(DocTree.Kind kind) { Objects.requireNonNull(kind); return itemsByCategory.getOrDefault(IndexItem.Category.TAGS, Collections.emptySortedSet()).stream() .filter(i -> i.isKind(kind)) .toCollection(() -> new TreeSet<>(mainComparator))); } ***** There are a few other cases in the JDK but they don't seem to lead to any new insights. Some observations. - Using this API saves 19 characters compared to Collectors::toCollection, but it saves only eight characters compared to Collectors::toCollection with a static import. - Using this API doesn't relieve the calling code of any burden of tedious or error-prone code. The code it replaces is quite straightforward. - There don't appear to be any opportunities for optimization. In order to handle the parallel case, this pretty much is required to delegate to the collector. I suppose the serial case could be handled specially, but it boils down to constructing the destination and then calling add() on it repeatedly, which is pretty much what the collector ends up doing in the serial case anyway. - Cases seem to occur quite infrequently compared to others such as Collectors::toList and Stream::toList. - Some cases of Collectors::toCollection are used as "downstream" collectors, that is, passed to other collectors instead of Stream::collect. This narrows the range of possible uses of the API still further. - There is a recurring pattern Collectors.toCollection(ArrayList::new) This is useful in place of Collectors::toList for places where the code wants to guarantee the result to be an ArrayList. (Even though Collectors::toList returns an ArrayList, it isn't specified to do so.) But there are cases (such as the one I looked at above) where the return list isn't actually modified -- and indeed it would be an error if it were modified -- so Stream::toList could be used just as well for those. - The JDK is not necessarily a representative code base, but frequencies here do seem to mirror what I've seen in open source: Collectors::toCollection is much less frequent than Collectors::toList. - There doesn't appear to be any semantic difference between the proposed Stream::toCollection and the existing Collectors::toCollection. Based on these observations I'm having a hard time mustering much enthusiasm for this API. You might ask, hasn't the JDK added other convenience APIs? There have probably been a few one-liners, but we are really trying to keep them to a minimum. Mainly, convenience APIs are indeed convenient, but in many cases they add a lot of value in other ways as well. Here are some examples. - Stream::toList. We discussed this recently, so I won't restate everything. Briefly, though, this can be used as a replacement for Collectors::toList, which is used VERY frequently, it provides stronger semantics, and it's faster because it avoids extra array allocation and copying. - String::repeat. Repeating a String is a simple for-loop. However, if you look at the implementation [1] there really is a lot going on here. It's a lot faster than the straightforward code, because it peels off a few special cases, it uses a clever doubling algorithm to call arraycopy a minimal number of times, and it deals with things at the byte level, so it can create a String without any copying or any codeset conversion. In addition to convenience, the value here is that it's much faster than a simple for-loop that one might write instead. It also leverages the JDK-internal String representation, which means that it does less allocation and copying than other utility libraries would. [1] https://github.com/openjdk/jdk16/blob/master/src/java.base/share/classes/java/lang/String.java#L3560 - InputStream::transferTo. This is mostly a straightforward loop [2], but the details are devilishly hard to get right. If you look at user code that does copying like this, it usually gets some edge case wrong, for example, not handling partial reads. The value provided here is not that it's faster than the code it would replace, but that it relieves the caller of the responsibility of writing a loop that's easy to get wrong (or to form a dependency on another library that has this utility method). [2] https://github.com/openjdk/jdk16/blob/master/src/java.base/share/classes/java/io/InputStream.java#L777 Anyway, this is the sort of analysis and justification that I'd like to see for convenience APIs. Such APIs need to be more than just a shorthand for something a bit longer. s'marks From sadayapalam at openjdk.java.net Wed May 5 06:12:50 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Wed, 5 May 2021 06:12:50 GMT Subject: RFR: 8244146: javac changes for JEP 306 In-Reply-To: References: Message-ID: On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy wrote: > 8244146: javac changes for JEP 306 src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 228: > 226: SEALED_CLASSES(JDK17, Fragments.FeatureSealedClasses, DiagKind.PLURAL), > 227: // todo: will need to supplement/replace with target feature for writing out classes > 228: REDUNDANT_STRICTFP(JDK17), Is the todo still relevant ?? test/langtools/tools/javac/annotations/typeAnnotations/classfile/NestedLambdasCastedTest.java line 34: > 32: * @build toolbox.ToolBox toolbox.JavapTask > 33: * @run compile -source 16 -g NestedLambdasCastedTest.java > 34: * @run main NestedLambdasCastedTest To massage the existing tests at some places you are passing -source 16 and at others -release 16. Is there some nuance behind it ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3831 From joe.darcy at oracle.com Wed May 5 06:27:01 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 4 May 2021 23:27:01 -0700 Subject: RFR: 8244146: javac changes for JEP 306 In-Reply-To: <5yCDuEC96JotYPj3Q1krLkGcCxUW7tg7eo7sMS3zrMI=.85d104d8-35af-4973-9817-ef6d96107318@github.com> References: <5yCDuEC96JotYPj3Q1krLkGcCxUW7tg7eo7sMS3zrMI=.85d104d8-35af-4973-9817-ef6d96107318@github.com> Message-ID: <00ea7b11-12ff-58b3-d17e-5d472b0f816a@oracle.com> On 5/4/2021 10:30 PM, Srikanth Adayapalam wrote: > On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy wrote: > >> 8244146: javac changes for JEP 306 > src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line 1704: > >> 1702: if (Feature.REDUNDANT_STRICTFP.allowedInSource(source)) >> 1703: result = result & ~STRICTFP; >> 1704: > Nitpick: Doing in Rome as ... would mean this is better written as > > result &= ~STRICTFP; > > to be in harmony with the code in the vicinity Sure; I had considered writing the update that way initially. > > Also I am OK with the feature-allowed-in-source-check, but wonder if it is an overkill for smaller focussed changes like this one. I will say I don't know what is the standard operating procedure. See that elsewhere in Lint.java you are doing > > if (source.compareTo(Source.JDK17) >= 0) { > values.add(LintCategory.STRICTFP); > } Lint had some other checks directly against Source version enums, but I'm happy to change it to a Source.Feature-based check. Thanks, -Joe From sadayapalam at openjdk.java.net Wed May 5 06:33:02 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Wed, 5 May 2021 06:33:02 GMT Subject: RFR: 8244146: javac changes for JEP 306 In-Reply-To: References: Message-ID: <0ou8zU8wwL-7iYxebr0qd2kjkiFVgVg1DoZ0QLgUabY=.b6ad8ef9-252e-4331-9f6d-26a9b2baf39c@github.com> On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy wrote: > 8244146: javac changes for JEP 306 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 1326: > 1324: private void warnOnExplicitStrictfp(DiagnosticPosition pos, JCTree tree) { > 1325: DiagnosticPosition prevLintPos = deferredLintHandler.setPos(tree.pos()); > 1326: try { Do we need tree passed as a parameter at all ? Why can't we use just pos instead of tree.pos() Looking at the 3 call sites of checkFlags it seems guaranteed that pos is same as tree.pos() ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3831 From vsitnikov at openjdk.java.net Wed May 5 06:52:56 2021 From: vsitnikov at openjdk.java.net (Vladimir Sitnikov) Date: Wed, 5 May 2021 06:52:56 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes [v2] In-Reply-To: References: Message-ID: <_Fts6pm4DVuhgAyQ_5lxu38cPGxDbZuLqNeCjGPttLE=.d04df608-79e2-458c-935d-4bb8dfa52a85@github.com> On Tue, 4 May 2021 20:18:25 GMT, Brian Burkhalter wrote: >> Please consider this request to override the `java.io.InputStream` methods `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more performant implementations. The method overrides attempt to read all requested bytes into a single array of the required size rather than composing the result from a sequence of smaller arrays. An example of the performance improvements is as follows. >> >> **readAllBytes** >> Before >> >> Benchmark (length) Mode Cnt Score Error Units >> ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 2412.031 ? 7.309 ops/s >> ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 212.181 ? 0.369 ops/s >> ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 19.860 ? 0.048 ops/s >> ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.298 ? 0.183 ops/s >> >> After >> >> Benchmark (length) Mode Cnt Score Error Units >> ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 8218.473 ? 43.425 ops/s >> ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 302.781 ? 1.273 ops/s >> ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 22.461 ? 0.084 ops/s >> ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.502 ? 0.003 ops/s >> >> >> **readNBytes** >> >> `N = file_size / 2` >> >> Before >> >> Benchmark (length) Mode Cnt Score Error Units >> ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 5585.500 ? 153.353 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 436.164 ? 1.104 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 40.167 ? 0.141 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 3.291 ? 0.211 ops/s >> >> >> After >> >> Benchmark (length) Mode Cnt Score Error Units >> ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 15463.210 ? 66.045 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 561.752 ? 0.951 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 45.043 ? 0.102 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 4.629 ? 0.035 ops/s > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8264777: Handle cases where length() returns zero src/java.base/share/classes/java/io/FileInputStream.java line 284: > 282: long size = length - position; > 283: if (size > (long)Integer.MAX_VALUE) > 284: throw new OutOfMemoryError("Required array size too large"); What do you think of adding "length, position, and size" to the exception message? ------------- PR: https://git.openjdk.java.net/jdk/pull/3845 From sadayapalam at openjdk.java.net Wed May 5 08:15:01 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Wed, 5 May 2021 08:15:01 GMT Subject: RFR: 8244146: javac changes for JEP 306 In-Reply-To: References: Message-ID: On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy wrote: > 8244146: javac changes for JEP 306 Overall, looks good other than the various minor issues called out. I wonder if the tests would have turned out to be a good bit simpler if we simply checked diagnostics against a golden file and skipped the toolbox approach. Is there a strong benefit to using the toolbox approach for the present need ?? Also, another model for tests could have been test/langtools/tools/javac//7166455/CheckACC_STRICTFlagOnclinitTest.java rather than using an annotation processor. (Not asking for a change, just an academic question/observation) ------------- PR: https://git.openjdk.java.net/jdk/pull/3831 From rafael.wth at gmail.com Wed May 5 08:53:24 2021 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Wed, 5 May 2021 10:53:24 +0200 Subject: Expected behavior for annotation property with duplicate value definition Message-ID: Hello, I was wondering if the current OpenJDK behavior should yield an exception or if it is accidental and if so, if it should be altered to avoid surprising behavior. If an annotation: @interface Sample { String v(); } is added to a member where the property 'v' is assigned a value twice, the last added value is returned by the reflection API and no error is raised. I recently observed this for ASM-generated code where a value was added twice and it led to a longer bug search, but technically this could of course also happen when javac or other language compilers generate code. I wonder therefore if this should rather yield an error or if this behavior should be documented somewhere in case that the change would be possibly too disruptive for existing code. I am happy to provide a patch to OpenJDK but wonder what exception should be thrown when reading the property. Best regards, Rafael From david.holmes at oracle.com Wed May 5 09:55:02 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 May 2021 19:55:02 +1000 Subject: Expected behavior for annotation property with duplicate value definition In-Reply-To: References: Message-ID: Hi Rafael, On 5/05/2021 6:53 pm, Rafael Winterhalter wrote: > Hello, > > I was wondering if the current OpenJDK behavior should yield an exception > or if it is accidental and if so, if it should be altered to avoid > surprising behavior. If an annotation: > > @interface Sample { > String v(); > } > > is added to a member where the property 'v' is assigned a value twice, the > last added value is returned by the reflection API and no error is raised. > I recently observed this for ASM-generated code where a value was added > twice and it led to a longer bug search, but technically this could of > course also happen when javac or other language compilers generate code. I > wonder therefore if this should rather yield an error or if this behavior > should be documented somewhere in case that the change would be possibly > too disruptive for existing code. I think you are describing generated bytecode that violates Java language rules for Annotation types. That is perfectly legal. The VM's notion of what an Annotation type is and how it must behave is much broader than that of the Java language. Cheers, David > I am happy to provide a patch to OpenJDK but wonder what exception should > be thrown when reading the property. > > Best regards, Rafael > From rafael.wth at gmail.com Wed May 5 10:02:11 2021 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Wed, 5 May 2021 12:02:11 +0200 Subject: Expected behavior for annotation property with duplicate value definition In-Reply-To: References: Message-ID: Hi David, yes, of course. However, the JVM already yields exceptions upon illegal constructs, most of the time a class would fail to load through verification. For annotations, there is a whole tree of exceptions such as AnnotationTypeMismatchException but this one scenario with two values for a single property does not seem to be handled but is silently ignored. I mainly wonder if this other illegal scenario should not be handled in the same category of throwing an exception. To my knowledge, there is no other annotation inconsistency that is silently suppressed. Best regards, Rafael Am Mi., 5. Mai 2021 um 11:55 Uhr schrieb David Holmes < david.holmes at oracle.com>: > Hi Rafael, > > On 5/05/2021 6:53 pm, Rafael Winterhalter wrote: > > Hello, > > > > I was wondering if the current OpenJDK behavior should yield an exception > > or if it is accidental and if so, if it should be altered to avoid > > surprising behavior. If an annotation: > > > > @interface Sample { > > String v(); > > } > > > > is added to a member where the property 'v' is assigned a value twice, > the > > last added value is returned by the reflection API and no error is > raised. > > I recently observed this for ASM-generated code where a value was added > > twice and it led to a longer bug search, but technically this could of > > course also happen when javac or other language compilers generate code. > I > > wonder therefore if this should rather yield an error or if this behavior > > should be documented somewhere in case that the change would be possibly > > too disruptive for existing code. > > I think you are describing generated bytecode that violates Java > language rules for Annotation types. That is perfectly legal. The VM's > notion of what an Annotation type is and how it must behave is much > broader than that of the Java language. > > Cheers, > David > > > I am happy to provide a patch to OpenJDK but wonder what exception should > > be thrown when reading the property. > > > > Best regards, Rafael > > > From sundar at openjdk.java.net Wed May 5 10:12:52 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Wed, 5 May 2021 10:12:52 GMT Subject: Integrated: 8260621: (jrtfs) ThreadLocal memory leak in ImageBufferCache when using jrtfs In-Reply-To: References: Message-ID: On Tue, 4 May 2021 09:05:38 GMT, Athijegannathan Sundararajan wrote: > Instead of BufferReference class, Map.Entry is used as pair implementation. > This avoids the metaspace leak seen via thread local. This pull request has now been integrated. Changeset: c9873c41 Author: Athijegannathan Sundararajan URL: https://git.openjdk.java.net/jdk/commit/c9873c416d047ec97c12f77abad3ece407530063 Stats: 57 lines in 1 file changed: 30 ins; 7 del; 20 mod 8260621: (jrtfs) ThreadLocal memory leak in ImageBufferCache when using jrtfs Reviewed-by: jlaskey, vtewari ------------- PR: https://git.openjdk.java.net/jdk/pull/3849 From alanb at openjdk.java.net Wed May 5 10:19:50 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 5 May 2021 10:19:50 GMT Subject: RFR: 8260621: (jrtfs) ThreadLocal memory leak in ImageBufferCache when using jrtfs In-Reply-To: References: Message-ID: On Tue, 4 May 2021 09:05:38 GMT, Athijegannathan Sundararajan wrote: > Instead of BufferReference class, Map.Entry is used as pair implementation. > This avoids the metaspace leak seen via thread local. src/java.base/share/classes/jdk/internal/jimage/ImageBufferCache.java line 46: > 44: > 45: /* > 46: * We used to have a class BufferReference extending from WeakReference. I think this comment needs to be re-worded to drop "We used to have ...", "Solution is ..." and the other history. Instead it should provide a clear paragraph that explains the value of the TL for anyone reading this code. ------------- PR: https://git.openjdk.java.net/jdk/pull/3849 From forax at univ-mlv.fr Wed May 5 10:41:04 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 5 May 2021 12:41:04 +0200 (CEST) Subject: [External] : Re: ReversibleCollection proposal In-Reply-To: References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com> <839698479.422241.1619098212148.JavaMail.zimbra@u-pem.fr> <7457433b-0836-f45e-4b51-4c2ecdf7e7da@oracle.com> <427897615.2057286.1619612437790.JavaMail.zimbra@u-pem.fr> <906317823.1426529.1619873859193.JavaMail.zimbra@u-pem.fr> Message-ID: <2063372755.1742538.1620211264481.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Stuart Marks" > ?: "Remi Forax" > Cc: "core-libs-dev" > Envoy?: Mercredi 5 Mai 2021 02:00:03 > Objet: Re: [External] : Re: ReversibleCollection proposal > On 5/1/21 5:57 AM, forax at univ-mlv.fr wrote: >> I suppose the performance issue comes from the fact that traversing a >> LinkedHahSet is slow because it's a linked list ? >> >> You can replace a LinkedHashSet by a List + Set, the List keeps the values in >> order, the Set avoids duplicates. >> >> Using a Stream, it becomes >> Stream.of(getItemsFromSomeplace(), getItemsFromAnotherPlace(), >> getItemsFromSomeplaceElse()) >> .flatMap(List::stream) >> .distinct() // use a Set internally >> .collect(toList()); > > The problem with any example is that simplifying assumptions are necessary for > showing the example, but those assumptions enable it to be easily picked apart. > Of > course, the example isn't just a particular example; it is a *template* for a > whole > space of possible examples. Consider the possibility that the items processing > client needs to do some intermediate processing on the first group of items > before > adding the other groups. This might not be possible to do using streams. Use > your > imagination. > >> I think there are maybe some scenarios where ReversibleCollection can be useful, >> but they are rare, to the point where when there is a good scenario for it >> people will not recognize it because ReversibleCollection will not be part of >> their muscle memory. > > I'm certain that uses of RC/RS will be rare in the beginning, because they will > be > new, and people won't be familar with them. And then there will the people who > say > "I can't use them because I'm stuck on JDK 11 / 8 / 7 / 6 ...." It was the same > thing with lambdas and streams in Java 8, with List.of() etc in Java 9, records > in > Java 16, etc. This wasn't an argument not to add them, and it isn't an argument > not > to add RC/RS. All the changes you are listing here are "client side" changes, the ones that can be adopted quickly because they do not require to change the API side of any libraries. ReversibleCollection is an API side change, like generics is, those changes have a far higher cost because you have to wait your library dependencies to be updated. On the Valhalla list, we have discussed several times about how to alleviate those API side change cost using automatic bridging or methods forwarding, even for Valhalla, we are currently moving in a state where those mechanisms are not needed. > >> There is a real value to add methods like >> descendingSet/descendingList()/getFirst/getLast on existing collections, but we >> don't need a new interface (or two) for that. > > It depends on what you mean by "need". Sure, we could get away without this; > after > all, we've survived the past twenty years without it, so we could probably > survive > the next twenty years as well. > > It would indeed be useful to add various methods to List, Deque, SortedSet, and > LinkedHashSet to provide a full set of methods on all of them. And it would also > be > nice to have those methods be similar to one another. An interface helps with > that, > but I agree, that's not really the reason to have an interface though. > > The reversed-view concept could also be added individually to the different > places. > A reverse-ordered List is a List, a reverse-ordered Deque is a Deque, a > reverse-ordered SortedSet is a SortedSet, and a reverse-ordered LinkedHashSet is > a > ... ? And what is the type of the keySet of a LinkedHashMap, that enables one to > (say) get the last element? see below > > After working with a system like this for a while, it begins to emerge that > there is > an abstraction missing from the collections framework, something like an > "ordered > collection". People have been missing this for quite a long time. The most > recent > example (which this proposal builds on) is Tagir's proposal from a year ago. And > it's been asked about several times before that. ReversibleCollection fills in > that > missing abstraction. The abstraction already exists but it's not defined in term of interface because it's an implementation decision and those are cleanly separated in the current Collection design. Let take a step back, the collection API defines basic data structure operations in term of interfaces like List, Deque, Set, etc those interfaces are decoupled from implementation capabilities like mutable, nullable, ordered and checked. Depending on the implementation capabilities, the interfaces method implementation may throw an exception, non-mutable implementations use UnsupportedOperationException, non-nullable implementations use NPE and checked implementations use CCE. So what is missing is methods on Collection interfaces that require the collection implementation to be ordered like descendingList(), getFirst(), etc. Those methods that may throw a specific exception if the implementation is not ordered, not UnsupportedOperationException but a new one like NotOrderedException. So to answer to your question about LinkedHashSet, the reverse-ordered LinkedHashSet is a Set with a method descendingSet() that do not throw NotOrderedException like any Set with an order. To summarize, if we introduce ReversibleCollection, we should also introduce ImmutableCollection, NonNullableCollection and CheckedCollection. I think it's better to consider the fact that being ordered as a capability (hint: this is already what the Spliterator API does) and not as a specific interface. > > s'marks R?mi From github.com+828220+forax at openjdk.java.net Wed May 5 11:02:54 2021 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 5 May 2021 11:02:54 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes [v2] In-Reply-To: <_Fts6pm4DVuhgAyQ_5lxu38cPGxDbZuLqNeCjGPttLE=.d04df608-79e2-458c-935d-4bb8dfa52a85@github.com> References: <_Fts6pm4DVuhgAyQ_5lxu38cPGxDbZuLqNeCjGPttLE=.d04df608-79e2-458c-935d-4bb8dfa52a85@github.com> Message-ID: On Wed, 5 May 2021 06:50:17 GMT, Vladimir Sitnikov wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8264777: Handle cases where length() returns zero > > src/java.base/share/classes/java/io/FileInputStream.java line 284: > >> 282: long size = length - position; >> 283: if (size > (long)Integer.MAX_VALUE) >> 284: throw new OutOfMemoryError("Required array size too large"); > > What do you think of adding "length, position, and size" to the exception message? We usually don't do that for OutOfMemoryError because concatenation implies allocation ------------- PR: https://git.openjdk.java.net/jdk/pull/3845 From jlahoda at openjdk.java.net Wed May 5 11:07:51 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 5 May 2021 11:07:51 GMT Subject: RFR: 8244146: javac changes for JEP 306 In-Reply-To: <5yCDuEC96JotYPj3Q1krLkGcCxUW7tg7eo7sMS3zrMI=.85d104d8-35af-4973-9817-ef6d96107318@github.com> References: <5yCDuEC96JotYPj3Q1krLkGcCxUW7tg7eo7sMS3zrMI=.85d104d8-35af-4973-9817-ef6d96107318@github.com> Message-ID: <-M66QLwSbyiS_sX4bV7_wdZaQIG2K0nGi5tHz930Icw=.f79c8e30-44d0-4b30-8c4b-7496f9ef021a@github.com> On Wed, 5 May 2021 05:26:47 GMT, Srikanth Adayapalam wrote: >> 8244146: javac changes for JEP 306 > > src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line 1704: > >> 1702: if (Feature.REDUNDANT_STRICTFP.allowedInSource(source)) >> 1703: result = result & ~STRICTFP; >> 1704: > > Nitpick: Doing in Rome as ... would mean this is better written as > > result &= ~STRICTFP; > > to be in harmony with the code in the vicinity > > Also I am OK with the feature-allowed-in-source-check, but wonder if it is an overkill for smaller focussed changes like this one. I will say I don't know what is the standard operating procedure. See that elsewhere in Lint.java you are doing > > if (source.compareTo(Source.JDK17) >= 0) { > values.add(LintCategory.STRICTFP); > } IMO it is better to have an enum constant in Feature for source level changes. But here, I wonder if a Target method on this place wouldn't be more appropriate. One can write: javac -source 16 -targete 17 Test.java If `Test.java` contains `strictfp`, should the classfile have `STRICTFP` set or not? ------------- PR: https://git.openjdk.java.net/jdk/pull/3831 From jlahoda at openjdk.java.net Wed May 5 11:07:52 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 5 May 2021 11:07:52 GMT Subject: RFR: 8244146: javac changes for JEP 306 In-Reply-To: References: Message-ID: On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy wrote: > 8244146: javac changes for JEP 306 src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java line 170: > 168: > 169: allOptions.add("--should-stop=at=FLOW"); > 170: allOptions.add("-Xlint:unchecked,-strictfp"); I wonder if JShell should also print the `strictfp` warnings, so that the users would learn about this change. If needed, it should be possible to disable this, I think, possibly like: diff --git a/test/langtools/jdk/jshell/ClassesTest.java b/test/langtools/jdk/jshell/ClassesTest.java index 082d757b02f..b0b8156e359 100644 --- a/test/langtools/jdk/jshell/ClassesTest.java +++ b/test/langtools/jdk/jshell/ClassesTest.java @@ -342,4 +342,9 @@ public class ClassesTest extends KullaTesting { assertEval("new A()"); } + @Override + public void setUp() { + setUp(bc -> bc.compilerOptions("-Xlint:-strictfp")); + } + } ------------- PR: https://git.openjdk.java.net/jdk/pull/3831 From david.holmes at oracle.com Wed May 5 11:45:29 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 May 2021 21:45:29 +1000 Subject: Expected behavior for annotation property with duplicate value definition In-Reply-To: References: Message-ID: Hi Rafael, On 5/05/2021 8:02 pm, Rafael Winterhalter wrote: > Hi David, > yes, of course. However, the JVM already yields exceptions upon illegal > constructs, most of the time a class would fail to load through > verification. Yes but verification enforces JVMS rules not JLS rules. There are many things allowed in a classfile that cannot be expressed in the Java language. > For annotations, there is a whole tree of exceptions such > as AnnotationTypeMismatchException but this one scenario with two values > for a single property does not seem to be handled but is silently Reflection can detect some ill-formedness of a classfile and re-apply Java language rules. > ignored. I mainly wonder if this other illegal scenario should not be > handled in the same category of throwing an exception. To my knowledge, > there is no other annotation inconsistency that is silently suppressed. Lets work with specifics. Here's an example description of a Deprecated attribute on method, as output by javap: RuntimeVisibleAnnotations: 0: #14(#15=s#16,#17=Z#18) java.lang.Deprecated( since="17" forRemoval=true ) I think the situation you are describing would show up as e.g.: 0: #14(#15=s#16,#15=s#4,#17=Z#18) where we "assign" the "since" value (cp entry #15) first with cp entry #16 and then with cp entry #4. Is this what you mean? In terms of the RuntimeVisibleAnnotations attribute as defined by JVMS 4.7.16 it doesn't state that the number of element_value pairs in an annotation structure has to match the number of elements expressed in the Java language for that annotation type - indeed no such number exists, it is implicitly defined by this array of element_value structures in the classfile. Nor does the JVMS require that element_value structures be unique within an annotation structure. So the VM would not reject such a classfile. AFAICT the VM just processes things in order as it encounters them so the last value "assigned" is what gets recorded. Reflection will then return that value and there is nothing at all to tell it that anything might have been amiss in the original classfile. David ----- > Best regards, Rafael > > Am Mi., 5. Mai 2021 um 11:55?Uhr schrieb David Holmes > >: > > Hi Rafael, > > On 5/05/2021 6:53 pm, Rafael Winterhalter wrote: > > Hello, > > > > I was wondering if the current OpenJDK behavior should yield an > exception > > or if it is accidental and if so, if it should be altered to avoid > > surprising behavior. If an annotation: > > > > @interface Sample { > >? ? String v(); > > } > > > > is added to a member where the property 'v' is assigned a value > twice, the > > last added value is returned by the reflection API and no error > is raised. > > I recently observed this for ASM-generated code where a value was > added > > twice and it led to a longer bug search, but technically this > could of > > course also happen when javac or other language compilers > generate code. I > > wonder therefore if this should rather yield an error or if this > behavior > > should be documented somewhere in case that the change would be > possibly > > too disruptive for existing code. > > I think you are describing generated bytecode that violates Java > language rules for Annotation types. That is perfectly legal. The VM's > notion of what an Annotation type is and how it must behave is much > broader than that of the Java language. > > Cheers, > David > > > I am happy to provide a patch to OpenJDK but wonder what > exception should > > be thrown when reading the property. > > > > Best regards, Rafael > > > From jlaskey at openjdk.java.net Wed May 5 12:51:14 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 5 May 2021 12:51:14 GMT Subject: RFR: JDK-8266552 Technical corrections to java/util/random/package-info.java Message-ID: The author (Guy Steele) of https://bugs.openjdk.java.net/browse/JDK-8193209 others have post-integration reviewed commentary (javadoc) and has submitted technical corrections. ------------- Commit messages: - Technical corrections to enhanced random numbers javadoc Changes: https://git.openjdk.java.net/jdk/pull/3881/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3881&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266552 Stats: 139 lines in 11 files changed: 10 ins; 20 del; 109 mod Patch: https://git.openjdk.java.net/jdk/pull/3881.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3881/head:pull/3881 PR: https://git.openjdk.java.net/jdk/pull/3881 From vsitnikov at openjdk.java.net Wed May 5 13:22:50 2021 From: vsitnikov at openjdk.java.net (Vladimir Sitnikov) Date: Wed, 5 May 2021 13:22:50 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes [v2] In-Reply-To: References: <_Fts6pm4DVuhgAyQ_5lxu38cPGxDbZuLqNeCjGPttLE=.d04df608-79e2-458c-935d-4bb8dfa52a85@github.com> Message-ID: On Wed, 5 May 2021 11:00:21 GMT, R?mi Forax wrote: >> src/java.base/share/classes/java/io/FileInputStream.java line 284: >> >>> 282: long size = length - position; >>> 283: if (size > (long)Integer.MAX_VALUE) >>> 284: throw new OutOfMemoryError("Required array size too large"); >> >> What do you think of adding "length, position, and size" to the exception message? > > We usually don't do that for OutOfMemoryError because concatenation implies allocation Well, here `OutOfMemory` is more like "I can't read all the data since the array won't fit". It would definitely help to have actual file size there, especially in case filesystem returns weird values (e.g. negative file length). This branch will almost never be taken, and even if taken, it won't be "low memory" condition. So the allocation does not hurt, however, it would simplify the analysis should the case trigger. ------------- PR: https://git.openjdk.java.net/jdk/pull/3845 From lancea at openjdk.java.net Wed May 5 15:52:00 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 5 May 2021 15:52:00 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v2] In-Reply-To: References: Message-ID: On Tue, 4 May 2021 14:10:52 GMT, Alan Bateman wrote: >> Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: >> >> Use pattern matching instanceof > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 2223: > >> 2221: synchronized (zfch) { >> 2222: n = zfch.position(pos).read(bb); >> 2223: } > > @LanceAndersen Are you planning to look at this? Do you mind checking the async close case to make sure that the synchronization isn't masking anything? > > Also just to point out that pattern matching for instanceof ca be used here. Yes, I plan to look at this. It would also be good to have a couple of additional reviews as well :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/3853 From alanb at openjdk.java.net Wed May 5 16:06:53 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 5 May 2021 16:06:53 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v2] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 15:49:00 GMT, Lance Andersen wrote: >> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 2223: >> >>> 2221: synchronized (zfch) { >>> 2222: n = zfch.position(pos).read(bb); >>> 2223: } >> >> @LanceAndersen Are you planning to look at this? Do you mind checking the async close case to make sure that the synchronization isn't masking anything? >> >> Also just to point out that pattern matching for instanceof ca be used here. > > Yes, I plan to look at this. It would also be good to have a couple of additional reviews as well :-) I think using the positional read on the underlying FileChannel is okay. I'm puzzled by the previous code as I would have expected it to restore the position (make me wonder if there are zipfs tests for this). ------------- PR: https://git.openjdk.java.net/jdk/pull/3853 From minqi at openjdk.java.net Wed May 5 16:17:15 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 5 May 2021 16:17:15 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens Message-ID: Hi, Please review When using jcmd to dump shared archive, if the archive name exists, it will be deleted first. If exception happens during dumping process, there is no new archive created. This PR changes to first dump the archive with a temporary file name. With successful dump, the temporary file will be rename to its given name. This way the old archive will not be touched on exception. The newly added test case skipped testing on Windows since File operation result is not same as on Linux. Tests: tier1,tier2,tier3,tier4 Thanks Yumin ------------- Commit messages: - 8265465: jcmd VM.cds should keep already dumped archive when exception happens Changes: https://git.openjdk.java.net/jdk/pull/3886/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3886&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265465 Stats: 188 lines in 3 files changed: 158 ins; 5 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/3886.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3886/head:pull/3886 PR: https://git.openjdk.java.net/jdk/pull/3886 From minqi at openjdk.java.net Wed May 5 16:34:20 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 5 May 2021 16:34:20 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v2] In-Reply-To: References: Message-ID: > Hi, Please review > When using jcmd to dump shared archive, if the archive name exists, it will be deleted first. If exception happens during dumping process, there is no new archive created. This PR changes to first dump the archive with a temporary file name. With successful dump, the temporary file will be rename to its given name. This way the old archive will not be touched on exception. > The newly added test case skipped testing on Windows since File operation result is not same as on Linux. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: JCmdTestFileSecurity.java should be excluded from dynamic test group ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3886/files - new: https://git.openjdk.java.net/jdk/pull/3886/files/9ba99117..b420da7b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3886&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3886&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3886.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3886/head:pull/3886 PR: https://git.openjdk.java.net/jdk/pull/3886 From github.com+19194678+scientificware at openjdk.java.net Wed May 5 16:43:08 2021 From: github.com+19194678+scientificware at openjdk.java.net (ScientificWare) Date: Wed, 5 May 2021 16:43:08 GMT Subject: RFR: 8265909 : build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home Message-ID: <_w5ZE_R0t_GeIFXIJaRhbqf00DRk4VFDuWU3h-lsVcY=.dfd54449-9e96-49f6-93ff-7c5c52242763@github.com> This concern [dtdbuilder tools](https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/dtdbuilder). In jshell, try `System.getProperty("html32") + ""` you'll get a `String`. So, in `DTDBuilder.java` when none `dtd_home` property is set, the `dtd_home` string value is not `null`, causing an exception with the present test. The expect value is `"Must set property 'dtd_home'"` And in this case, should'nt we have a `System.exit(1)` too rather than a simple `return` ? ------------- Commit messages: - Change test none dtd_home property is set. Changes: https://git.openjdk.java.net/jdk/pull/3626/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3626&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265909 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3626.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3626/head:pull/3626 PR: https://git.openjdk.java.net/jdk/pull/3626 From github.com+19194678+scientificware at openjdk.java.net Wed May 5 16:43:08 2021 From: github.com+19194678+scientificware at openjdk.java.net (ScientificWare) Date: Wed, 5 May 2021 16:43:08 GMT Subject: RFR: 8265909 : build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home In-Reply-To: <_w5ZE_R0t_GeIFXIJaRhbqf00DRk4VFDuWU3h-lsVcY=.dfd54449-9e96-49f6-93ff-7c5c52242763@github.com> References: <_w5ZE_R0t_GeIFXIJaRhbqf00DRk4VFDuWU3h-lsVcY=.dfd54449-9e96-49f6-93ff-7c5c52242763@github.com> Message-ID: On Thu, 22 Apr 2021 13:47:03 GMT, ScientificWare wrote: > This concern [dtdbuilder tools](https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/dtdbuilder). > > In jshell, try `System.getProperty("html32") + ""` you'll get a `String`. > > So, in `DTDBuilder.java` when none `dtd_home` property is set, the `dtd_home` string value is not `null`, causing an exception with the present test. > > The expect value is `"Must set property 'dtd_home'"` > > And in this case, should'nt we have a `System.exit(1)` too rather than a simple `return` ? Simple reproducer : In raw mode, save the 4 java files from [https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/dtdbuilde](https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/dtdbuilder) in the folder `/test_dtdbuilder` for example. In this folder type following commands : `javac -d . *.java` `java build.tools.dtdbuilder.DTDBuilder html32` ------------- PR: https://git.openjdk.java.net/jdk/pull/3626 From kofemann at gmail.com Wed May 5 16:58:08 2021 From: kofemann at gmail.com (Tiramisu Mokka) Date: Wed, 5 May 2021 18:58:08 +0200 Subject: Accessing stream in random order Message-ID: Hi all, The Stream API makes a great job to work with various collections. However some simple operations are quite hard to achieve, for example collect the result into a random order list. The best solution I came with is: Arrays.asList("a", "b", "c", "d").stream() .collect(collectingAndThen(toList(), l -> { Collections.shuffle(l); return l;})); If Collections#shuffle would return the shuffled list, then this can be written even more elegant: Arrays.asList("a", "b", "c", "d").stream() .collect(collectingAndThen(toList(), Collections::shuffle)); Thus two questions: 1) why stream has a way to sort, but not to shuffle 2) why Collections#shuffle doesn't returns the suffld list Are there objectives to address those cases? Thanks in advance, -kofemann /** caffeinated mutations of the core personality */ From bpb at openjdk.java.net Wed May 5 17:01:14 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 5 May 2021 17:01:14 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes [v3] In-Reply-To: References: Message-ID: <_91uLSseAbQgq47AuVGQnyYlEugwl1Sgba1CZMoF7_Q=.17cdb8f0-76b4-41f2-b606-c14266ddda11@github.com> > Please consider this request to override the `java.io.InputStream` methods `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more performant implementations. The method overrides attempt to read all requested bytes into a single array of the required size rather than composing the result from a sequence of smaller arrays. An example of the performance improvements is as follows. > > **readAllBytes** > Before > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 2412.031 ? 7.309 ops/s > ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 212.181 ? 0.369 ops/s > ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 19.860 ? 0.048 ops/s > ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.298 ? 0.183 ops/s > > After > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 8218.473 ? 43.425 ops/s > ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 302.781 ? 1.273 ops/s > ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 22.461 ? 0.084 ops/s > ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.502 ? 0.003 ops/s > > > **readNBytes** > > `N = file_size / 2` > > Before > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 5585.500 ? 153.353 ops/s > ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 436.164 ? 1.104 ops/s > ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 40.167 ? 0.141 ops/s > ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 3.291 ? 0.211 ops/s > > > After > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 15463.210 ? 66.045 ops/s > ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 561.752 ? 0.951 ops/s > ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 45.043 ? 0.102 ops/s > ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 4.629 ? 0.035 ops/s Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8264777: Change length == 0 case to fall back to superclass method; add dimensions to OutOfMemoryError message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3845/files - new: https://git.openjdk.java.net/jdk/pull/3845/files/98a03a55..bfc5598b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3845&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3845&range=01-02 Stats: 29 lines in 1 file changed: 8 ins; 11 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3845/head:pull/3845 PR: https://git.openjdk.java.net/jdk/pull/3845 From bpb at openjdk.java.net Wed May 5 17:10:13 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 5 May 2021 17:10:13 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes [v4] In-Reply-To: References: Message-ID: > Please consider this request to override the `java.io.InputStream` methods `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more performant implementations. The method overrides attempt to read all requested bytes into a single array of the required size rather than composing the result from a sequence of smaller arrays. An example of the performance improvements is as follows. > > **readAllBytes** > Before > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 2412.031 ? 7.309 ops/s > ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 212.181 ? 0.369 ops/s > ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 19.860 ? 0.048 ops/s > ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.298 ? 0.183 ops/s > > After > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 8218.473 ? 43.425 ops/s > ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 302.781 ? 1.273 ops/s > ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 22.461 ? 0.084 ops/s > ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.502 ? 0.003 ops/s > > > **readNBytes** > > `N = file_size / 2` > > Before > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 5585.500 ? 153.353 ops/s > ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 436.164 ? 1.104 ops/s > ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 40.167 ? 0.141 ops/s > ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 3.291 ? 0.211 ops/s > > > After > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 15463.210 ? 66.045 ops/s > ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 561.752 ? 0.951 ops/s > ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 45.043 ? 0.102 ops/s > ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 4.629 ? 0.035 ops/s Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8264777: Fix typo in error message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3845/files - new: https://git.openjdk.java.net/jdk/pull/3845/files/bfc5598b..5a4d9114 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3845&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3845&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3845/head:pull/3845 PR: https://git.openjdk.java.net/jdk/pull/3845 From dfuchs at openjdk.java.net Wed May 5 17:21:54 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 5 May 2021 17:21:54 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes [v4] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 17:10:13 GMT, Brian Burkhalter wrote: >> Please consider this request to override the `java.io.InputStream` methods `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more performant implementations. The method overrides attempt to read all requested bytes into a single array of the required size rather than composing the result from a sequence of smaller arrays. An example of the performance improvements is as follows. >> >> **readAllBytes** >> Before >> >> Benchmark (length) Mode Cnt Score Error Units >> ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 2412.031 ? 7.309 ops/s >> ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 212.181 ? 0.369 ops/s >> ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 19.860 ? 0.048 ops/s >> ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.298 ? 0.183 ops/s >> >> After >> >> Benchmark (length) Mode Cnt Score Error Units >> ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 8218.473 ? 43.425 ops/s >> ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 302.781 ? 1.273 ops/s >> ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 22.461 ? 0.084 ops/s >> ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.502 ? 0.003 ops/s >> >> >> **readNBytes** >> >> `N = file_size / 2` >> >> Before >> >> Benchmark (length) Mode Cnt Score Error Units >> ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 5585.500 ? 153.353 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 436.164 ? 1.104 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 40.167 ? 0.141 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 3.291 ? 0.211 ops/s >> >> >> After >> >> Benchmark (length) Mode Cnt Score Error Units >> ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 15463.210 ? 66.045 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 561.752 ? 0.951 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 45.043 ? 0.102 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 4.629 ? 0.035 ops/s > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8264777: Fix typo in error message src/java.base/share/classes/java/io/FileInputStream.java line 289: > 287: } > 288: if (size <= 0L) > 289: return new byte[0]; Maybe the case where size <= 0L should also default to `return super.readAllBytes()`? ------------- PR: https://git.openjdk.java.net/jdk/pull/3845 From darcy at openjdk.java.net Wed May 5 17:38:53 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 5 May 2021 17:38:53 GMT Subject: RFR: 8244146: javac changes for JEP 306 In-Reply-To: References: Message-ID: On Wed, 5 May 2021 06:07:23 GMT, Srikanth Adayapalam wrote: >> 8244146: javac changes for JEP 306 > > test/langtools/tools/javac/annotations/typeAnnotations/classfile/NestedLambdasCastedTest.java line 34: > >> 32: * @build toolbox.ToolBox toolbox.JavapTask >> 33: * @run compile -source 16 -g NestedLambdasCastedTest.java >> 34: * @run main NestedLambdasCastedTest > > To massage the existing tests at some places you are passing -source 16 and at others -release 16. Is there some nuance behind it ? Yes; --release 16 is generally preferred as a cleaner, more complete way of requesting 16-ness from javac. However, use of features like the @modules tag in jtreg can preclude use from --release because of interactions like: exporting a package from system module jdk.jdeps is not allowed with --release ------------- PR: https://git.openjdk.java.net/jdk/pull/3831 From bpb at openjdk.java.net Wed May 5 17:42:52 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 5 May 2021 17:42:52 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes [v4] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 17:18:08 GMT, Daniel Fuchs wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8264777: Fix typo in error message > > src/java.base/share/classes/java/io/FileInputStream.java line 289: > >> 287: } >> 288: if (size <= 0L) >> 289: return new byte[0]; > > Maybe the case where size <= 0L should also default to `return super.readAllBytes()`? Yes, that might be better. ------------- PR: https://git.openjdk.java.net/jdk/pull/3845 From darcy at openjdk.java.net Wed May 5 17:56:09 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 5 May 2021 17:56:09 GMT Subject: RFR: 8244146: javac changes for JEP 306 [v2] In-Reply-To: References: Message-ID: > 8244146: javac changes for JEP 306 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3831/files - new: https://git.openjdk.java.net/jdk/pull/3831/files/a0a68baa..ec4d163a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3831&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3831&range=00-01 Stats: 19 lines in 9 files changed: 10 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3831.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3831/head:pull/3831 PR: https://git.openjdk.java.net/jdk/pull/3831 From bpb at openjdk.java.net Wed May 5 17:56:09 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 5 May 2021 17:56:09 GMT Subject: RFR: 8244146: javac changes for JEP 306 [v2] In-Reply-To: References: Message-ID: <6uVQVYTcinOxRiwYsbc1KYsLX65bA1S8UT6-usy-nJo=.291ee69f-c8bc-40a2-b9e3-089db7dbf2b9@github.com> On Wed, 5 May 2021 17:53:43 GMT, Joe Darcy wrote: >> 8244146: javac changes for JEP 306 > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Changes to `java.base` look fine. The other changes should be approved by a separate reviewer. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3831 From naoto at openjdk.java.net Wed May 5 18:06:52 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 5 May 2021 18:06:52 GMT Subject: RFR: 8244146: javac changes for JEP 306 [v2] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 17:56:09 GMT, Joe Darcy wrote: >> 8244146: javac changes for JEP 306 > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 290: > 288: > 289: /** > 290: * Warning about unnecessary uses of the strictfp modifier Could be better to align with other comments that use "Warn" as a verb. ------------- PR: https://git.openjdk.java.net/jdk/pull/3831 From robert at marcanoonline.com Wed May 5 18:09:12 2021 From: robert at marcanoonline.com (Robert Marcano) Date: Wed, 5 May 2021 14:09:12 -0400 Subject: DataInputStream readUTF related field initialization Message-ID: <658d871a-f00e-24dc-391f-46d63ca73835@marcanoonline.com> Greetings. DataInputStream has some fields with the comment "working arrays initialized on demand by readUTF" but these fields are being initialized at object instantiation. On the other hand DataOutputStream has one field with a likewise comment initialized to null. I think DataInputStream could be optimized the same way as DataOutputStream and help in the memoty footprint of DataInputStream when used for other reads not related to readUTF. Sounds reasonable? From iklam at openjdk.java.net Wed May 5 18:37:54 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 5 May 2021 18:37:54 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v2] In-Reply-To: References: Message-ID: <71lDNVjApEHqSRtBg1ysBe1KtxeLzTrBCf4YML4wD6g=.d3a1defb-f9d2-41bb-8b9d-00f60c9db8c9@github.com> On Wed, 5 May 2021 16:34:20 GMT, Yumin Qi wrote: >> Hi, Please review >> When using jcmd to dump shared archive, if the archive name exists, it will be deleted first. If exception happens during dumping process, there is no new archive created. This PR changes to first dump the archive with a temporary file name. With successful dump, the temporary file will be rename to its given name. This way the old archive will not be touched on exception. >> The newly added test case skipped testing on Windows since File operation result is not same as on Linux. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > JCmdTestFileSecurity.java should be excluded from dynamic test group Changes requested by iklam (Reviewer). src/java.base/share/classes/jdk/internal/misc/CDS.java line 284: > 282: > 283: String tempFileName = getArchiveFileName(archiveFileName); > 284: File tempArchiveFile = new File(tempFileName); I think the logic is too complicated. We can always write the archive to a temp file, and then rename it to the actual file. Also, to be consistent with the other variables, it should be `tempArchiveFileName` String tempArchiveFileName = archiveFileName + ".tmp"; src/java.base/share/classes/jdk/internal/misc/CDS.java line 288: > 286: if (isStatic) { > 287: String listFileName = tempFileName + ".classlist"; > 288: File listFile = new File(listFileName); There's no need to use tempFileName for the classlist. The list file is always deleted after the dump has finished. test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSecurity.java line 37: > 35: * @run driver jdk.test.lib.helpers.ClassFileInstaller sun.hotspot.WhiteBox > 36: * @run main/othervm/timeout=480 -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI JCmdTestFileSecurity > 37: */ "Security" is usually used for Java language security. I think it's better to call this test JCmdTestFileSafety. test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSecurity.java line 63: > 61: test(localFileName, pid, noBoot, EXPECT_PASS); > 62: File targetFile = CDSTestUtils.getOutputDirAsFile(); > 63: targetFile.setWritable(false); getOutputDirAsFile returns the current directory. Other test code may write to this directory. I think it's better to specify: localFileName = "subdir" + File.separator() + "MyStaticDump.jsa"; and set `subdir` to be non-writeable. Also, the local variable should be `targetDir` instead of `targetFile`. test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSecurity.java line 92: > 90: public static void main(String... args) throws Exception { > 91: if (Platform.isWindows()) { > 92: // ON windows, File operation resulted difference from other OS. Could you explain what the differences are? ------------- PR: https://git.openjdk.java.net/jdk/pull/3886 From minqi at openjdk.java.net Wed May 5 18:47:54 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 5 May 2021 18:47:54 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v2] In-Reply-To: <71lDNVjApEHqSRtBg1ysBe1KtxeLzTrBCf4YML4wD6g=.d3a1defb-f9d2-41bb-8b9d-00f60c9db8c9@github.com> References: <71lDNVjApEHqSRtBg1ysBe1KtxeLzTrBCf4YML4wD6g=.d3a1defb-f9d2-41bb-8b9d-00f60c9db8c9@github.com> Message-ID: <8aAiaSoL9zISBD9jyPEg_z9TWXj1ds6Gl0nJ9NhmCuc=.179dfd00-88fb-4080-b186-30d9179f5c99@github.com> On Wed, 5 May 2021 18:20:43 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> JCmdTestFileSecurity.java should be excluded from dynamic test group > > src/java.base/share/classes/jdk/internal/misc/CDS.java line 284: > >> 282: >> 283: String tempFileName = getArchiveFileName(archiveFileName); >> 284: File tempArchiveFile = new File(tempFileName); > > I think the logic is too complicated. We can always write the archive to a temp file, and then rename it to the actual file. Also, to be consistent with the other variables, it should be `tempArchiveFileName` > > > String tempArchiveFileName = archiveFileName + ".tmp"; getArchiveFileName also operates on create/delete temp file, so if that fails, throw exception back to caller. Do you think the logic should be kept? > src/java.base/share/classes/jdk/internal/misc/CDS.java line 288: > >> 286: if (isStatic) { >> 287: String listFileName = tempFileName + ".classlist"; >> 288: File listFile = new File(listFileName); > > There's no need to use tempFileName for the classlist. The list file is always deleted after the dump has finished. Yes, will revert it back. > test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSecurity.java line 37: > >> 35: * @run driver jdk.test.lib.helpers.ClassFileInstaller sun.hotspot.WhiteBox >> 36: * @run main/othervm/timeout=480 -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI JCmdTestFileSecurity >> 37: */ > > "Security" is usually used for Java language security. I think it's better to call this test JCmdTestFileSafety. Sure. > test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSecurity.java line 63: > >> 61: test(localFileName, pid, noBoot, EXPECT_PASS); >> 62: File targetFile = CDSTestUtils.getOutputDirAsFile(); >> 63: targetFile.setWritable(false); > > getOutputDirAsFile returns the current directory. Other test code may write to this directory. I think it's better to specify: > > > localFileName = "subdir" + File.separator() + "MyStaticDump.jsa"; > > > and set `subdir` to be non-writeable. > > Also, the local variable should be `targetDir` instead of `targetFile`. Will try this, not sure if the subdir and the file can be created with current code. May be some extra code needed. Thanks for the review! > test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSecurity.java line 92: > >> 90: public static void main(String... args) throws Exception { >> 91: if (Platform.isWindows()) { >> 92: // ON windows, File operation resulted difference from other OS. > > Could you explain what the differences are? Will add detail explanation. ------------- PR: https://git.openjdk.java.net/jdk/pull/3886 From brian.burkhalter at oracle.com Wed May 5 18:52:49 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 5 May 2021 18:52:49 +0000 Subject: DataInputStream readUTF related field initialization In-Reply-To: <658d871a-f00e-24dc-391f-46d63ca73835@marcanoonline.com> References: <658d871a-f00e-24dc-391f-46d63ca73835@marcanoonline.com> Message-ID: > On May 5, 2021, at 11:09 AM, Robert Marcano wrote: > > Greetings. DataInputStream has some fields with the comment "working arrays initialized on demand by readUTF" but these fields are being initialized at object instantiation. > > On the other hand DataOutputStream has one field with a likewise comment initialized to null. > > I think DataInputStream could be optimized the same way as DataOutputStream and help in the memoty footprint of DataInputStream when used for other reads not related to readUTF. > > Sounds reasonable? Yes, this could help a bit with the footprint. Brian From darcy at openjdk.java.net Wed May 5 18:56:50 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 5 May 2021 18:56:50 GMT Subject: RFR: 8244146: javac changes for JEP 306 [v2] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 05:31:40 GMT, Srikanth Adayapalam wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedback. > > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 1769: > >> 1767: compiler.warn.strictfp=\ >> 1768: as of release 17, all floating-point expressions are evaluated strictly and ''strictfp'' is not required >> 1769: > > Nitpick: Three other uses of floating point in the same file use the non-hyphenated form. As an adjective "floating-point" rather than "floating point" is the more correct construction. JLS uses "floating-point" consistently. I'd prefer to change the other three occurrences to "floating-point" for consistency rather than changing this one to "floating point". ------------- PR: https://git.openjdk.java.net/jdk/pull/3831 From lancea at openjdk.java.net Wed May 5 19:17:01 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 5 May 2021 19:17:01 GMT Subject: RFR: 8266579: Update test/jdk/java/lang/ProcessHandle/PermissionTest.java & test/jdk/java/sql/testng/util/TestPolicy.java Message-ID: Hi all, Please review this patch which updates test/jdk/java/lang/ProcessHandle/PermissionTest.java & test/jdk/java/sql/testng/util/TestPolicy.java to include : `new PropertyPermission("testng.memory.friendly", "read"); ` Which will be needed by TestNG 7.4 Best, Lance ------------- Commit messages: - Add additional permission required by TestNG 7.4 Changes: https://git.openjdk.java.net/jdk/pull/3888/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3888&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266579 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3888/head:pull/3888 PR: https://git.openjdk.java.net/jdk/pull/3888 From iklam at openjdk.java.net Wed May 5 19:27:52 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 5 May 2021 19:27:52 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v2] In-Reply-To: <8aAiaSoL9zISBD9jyPEg_z9TWXj1ds6Gl0nJ9NhmCuc=.179dfd00-88fb-4080-b186-30d9179f5c99@github.com> References: <71lDNVjApEHqSRtBg1ysBe1KtxeLzTrBCf4YML4wD6g=.d3a1defb-f9d2-41bb-8b9d-00f60c9db8c9@github.com> <8aAiaSoL9zISBD9jyPEg_z9TWXj1ds6Gl0nJ9NhmCuc=.179dfd00-88fb-4080-b186-30d9179f5c99@github.com> Message-ID: On Wed, 5 May 2021 18:42:20 GMT, Yumin Qi wrote: >> src/java.base/share/classes/jdk/internal/misc/CDS.java line 284: >> >>> 282: >>> 283: String tempFileName = getArchiveFileName(archiveFileName); >>> 284: File tempArchiveFile = new File(tempFileName); >> >> I think the logic is too complicated. We can always write the archive to a temp file, and then rename it to the actual file. Also, to be consistent with the other variables, it should be `tempArchiveFileName` >> >> >> String tempArchiveFileName = archiveFileName + ".tmp"; > > getArchiveFileName also operates on create/delete temp file, so if that fails, throw exception back to caller. Do you think the logic should be kept? How about: File tempArchiveFile = new File(tempArchiveFileName); tempArchiveFile.createNewFile(); // will throw exception if we cannot write to the directory. tempArchiveFile.delete(); ------------- PR: https://git.openjdk.java.net/jdk/pull/3886 From darcy at openjdk.java.net Wed May 5 19:37:19 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 5 May 2021 19:37:19 GMT Subject: RFR: 8244146: javac changes for JEP 306 [v3] In-Reply-To: References: Message-ID: > 8244146: javac changes for JEP 306 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3831/files - new: https://git.openjdk.java.net/jdk/pull/3831/files/ec4d163a..9773a8a5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3831&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3831&range=01-02 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3831.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3831/head:pull/3831 PR: https://git.openjdk.java.net/jdk/pull/3831 From darcy at openjdk.java.net Wed May 5 19:37:20 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 5 May 2021 19:37:20 GMT Subject: RFR: 8244146: javac changes for JEP 306 [v2] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 18:03:54 GMT, Naoto Sato wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedback. > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 290: > >> 288: >> 289: /** >> 290: * Warning about unnecessary uses of the strictfp modifier > > Could be better to align with other comments that use "Warn" as a verb. Good catch; fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3831 From darcy at openjdk.java.net Wed May 5 19:37:21 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 5 May 2021 19:37:21 GMT Subject: RFR: 8244146: javac changes for JEP 306 [v3] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 18:53:50 GMT, Joe Darcy wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 1769: >> >>> 1767: compiler.warn.strictfp=\ >>> 1768: as of release 17, all floating-point expressions are evaluated strictly and ''strictfp'' is not required >>> 1769: >> >> Nitpick: Three other uses of floating point in the same file use the non-hyphenated form. > > As an adjective "floating-point" rather than "floating point" is the more correct construction. JLS uses "floating-point" consistently. I'd prefer to change the other three occurrences to "floating-point" for consistency rather than changing this one to "floating point". Pushed an update to use "floating-point" consistently. ------------- PR: https://git.openjdk.java.net/jdk/pull/3831 From darcy at openjdk.java.net Wed May 5 19:42:54 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 5 May 2021 19:42:54 GMT Subject: RFR: 8244146: javac changes for JEP 306 [v3] In-Reply-To: <-M66QLwSbyiS_sX4bV7_wdZaQIG2K0nGi5tHz930Icw=.f79c8e30-44d0-4b30-8c4b-7496f9ef021a@github.com> References: <5yCDuEC96JotYPj3Q1krLkGcCxUW7tg7eo7sMS3zrMI=.85d104d8-35af-4973-9817-ef6d96107318@github.com> <-M66QLwSbyiS_sX4bV7_wdZaQIG2K0nGi5tHz930Icw=.f79c8e30-44d0-4b30-8c4b-7496f9ef021a@github.com> Message-ID: On Wed, 5 May 2021 11:05:11 GMT, Jan Lahoda wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line 1704: >> >>> 1702: if (Feature.REDUNDANT_STRICTFP.allowedInSource(source)) >>> 1703: result = result & ~STRICTFP; >>> 1704: >> >> Nitpick: Doing in Rome as ... would mean this is better written as >> >> result &= ~STRICTFP; >> >> to be in harmony with the code in the vicinity >> >> Also I am OK with the feature-allowed-in-source-check, but wonder if it is an overkill for smaller focussed changes like this one. I will say I don't know what is the standard operating procedure. See that elsewhere in Lint.java you are doing >> >> if (source.compareTo(Source.JDK17) >= 0) { >> values.add(LintCategory.STRICTFP); >> } > > IMO it is better to have an enum constant in Feature for source level changes. > > But here, I wonder if a Target method on this place wouldn't be more appropriate. One can write: > > javac -source 16 -targete 17 Test.java > > > If `Test.java` contains `strictfp`, should the classfile have `STRICTFP` set or not? Suggestions taken. ------------- PR: https://git.openjdk.java.net/jdk/pull/3831 From joehw at openjdk.java.net Wed May 5 20:10:51 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 5 May 2021 20:10:51 GMT Subject: RFR: 8266579: Update test/jdk/java/lang/ProcessHandle/PermissionTest.java & test/jdk/java/sql/testng/util/TestPolicy.java In-Reply-To: References: Message-ID: <0zDzqPWnWn0eFujYdaH7bldGH3HU-iLlkZ4KdnSNIBQ=.3f3fed8a-9273-4489-b22a-cb40c69ee5a5@github.com> On Wed, 5 May 2021 19:10:21 GMT, Lance Andersen wrote: > Hi all, > > Please review this patch which updates test/jdk/java/lang/ProcessHandle/PermissionTest.java & test/jdk/java/sql/testng/util/TestPolicy.java to include : > > `new PropertyPermission("testng.memory.friendly", "read"); > ` > Which will be needed by TestNG 7.4 > > Best, > Lance Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3888 From naoto at openjdk.java.net Wed May 5 20:46:49 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 5 May 2021 20:46:49 GMT Subject: RFR: 8266579: Update test/jdk/java/lang/ProcessHandle/PermissionTest.java & test/jdk/java/sql/testng/util/TestPolicy.java In-Reply-To: References: Message-ID: <6OoKw6tPa6GiIQtwUdWbEIpnkgv3kInyr6q_uHo1Jds=.1535771e-7136-418c-a31d-0780fd18a3b5@github.com> On Wed, 5 May 2021 19:10:21 GMT, Lance Andersen wrote: > Hi all, > > Please review this patch which updates test/jdk/java/lang/ProcessHandle/PermissionTest.java & test/jdk/java/sql/testng/util/TestPolicy.java to include : > > `new PropertyPermission("testng.memory.friendly", "read"); > ` > Which will be needed by TestNG 7.4 > > Best, > Lance Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3888 From darcy at openjdk.java.net Wed May 5 21:21:49 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 5 May 2021 21:21:49 GMT Subject: RFR: JDK-8266552 Technical corrections to java/util/random/package-info.java In-Reply-To: References: Message-ID: On Wed, 5 May 2021 12:41:50 GMT, Jim Laskey wrote: > The author (Guy Steele) of https://bugs.openjdk.java.net/browse/JDK-8193209 others have post-integration reviewed commentary (javadoc) and has submitted technical corrections. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3881 From bpb at openjdk.java.net Wed May 5 21:22:53 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 5 May 2021 21:22:53 GMT Subject: RFR: 8266579: Update test/jdk/java/lang/ProcessHandle/PermissionTest.java & test/jdk/java/sql/testng/util/TestPolicy.java In-Reply-To: References: Message-ID: <0wDOCFTvTNaeX9fVqGNkuzSgJ7-awcTuEw8gFc84dL8=.58a43637-33dd-4af1-9e0e-3de66b2e8467@github.com> On Wed, 5 May 2021 19:10:21 GMT, Lance Andersen wrote: > Hi all, > > Please review this patch which updates test/jdk/java/lang/ProcessHandle/PermissionTest.java & test/jdk/java/sql/testng/util/TestPolicy.java to include : > > `new PropertyPermission("testng.memory.friendly", "read"); > ` > Which will be needed by TestNG 7.4 > > Best, > Lance Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3888 From winterhalter at openjdk.java.net Wed May 5 21:43:01 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Wed, 5 May 2021 21:43:01 GMT Subject: RFR: 8266598: Exception values for AnnotationTypeMismatchException are not always informative Message-ID: This improves the messages that are provided by `AnnotationTypeMismatchException`s. The message provided by AnnotationTypeMismatchExceptions is deliberately undefined such that this should not break any contract. ------------- Commit messages: - 8266598: Exception values for AnnotationTypeMismatchException are not always informative Changes: https://git.openjdk.java.net/jdk/pull/3892/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3892&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266598 Stats: 21 lines in 3 files changed: 12 ins; 3 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3892.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3892/head:pull/3892 PR: https://git.openjdk.java.net/jdk/pull/3892 From darcy at openjdk.java.net Wed May 5 22:25:03 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 5 May 2021 22:25:03 GMT Subject: RFR: 8266598: Exception values for AnnotationTypeMismatchException are not always informative In-Reply-To: References: Message-ID: On Wed, 5 May 2021 21:36:45 GMT, Rafael Winterhalter wrote: > This improves the messages that are provided by `AnnotationTypeMismatchException`s. The message provided by AnnotationTypeMismatchExceptions is deliberately undefined such that this should not break any contract. Please add 8266598 to the @bug lines of the regression tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/3892 From bpb at openjdk.java.net Wed May 5 22:44:22 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 5 May 2021 22:44:22 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes [v5] In-Reply-To: References: Message-ID: > Please consider this request to override the `java.io.InputStream` methods `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more performant implementations. The method overrides attempt to read all requested bytes into a single array of the required size rather than composing the result from a sequence of smaller arrays. An example of the performance improvements is as follows. > > **readAllBytes** > Before > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 2412.031 ? 7.309 ops/s > ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 212.181 ? 0.369 ops/s > ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 19.860 ? 0.048 ops/s > ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.298 ? 0.183 ops/s > > After > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 8218.473 ? 43.425 ops/s > ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 302.781 ? 1.273 ops/s > ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 22.461 ? 0.084 ops/s > ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.502 ? 0.003 ops/s > > > **readNBytes** > > `N = file_size / 2` > > Before > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 5585.500 ? 153.353 ops/s > ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 436.164 ? 1.104 ops/s > ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 40.167 ? 0.141 ops/s > ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 3.291 ? 0.211 ops/s > > > After > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 15463.210 ? 66.045 ops/s > ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 561.752 ? 0.951 ops/s > ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 45.043 ? 0.102 ops/s > ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 4.629 ? 0.035 ops/s Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8264777: Improve handling of position, length, and size checks ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3845/files - new: https://git.openjdk.java.net/jdk/pull/3845/files/5a4d9114..0e476822 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3845&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3845&range=03-04 Stats: 16 lines in 1 file changed: 5 ins; 4 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3845/head:pull/3845 PR: https://git.openjdk.java.net/jdk/pull/3845 From jzaugg at openjdk.java.net Wed May 5 23:25:50 2021 From: jzaugg at openjdk.java.net (Jason Zaugg) Date: Wed, 5 May 2021 23:25:50 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v2] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 16:03:17 GMT, Alan Bateman wrote: >> Yes, I plan to look at this. It would also be good to have a couple of additional reviews as well :-) > > I think using the positional read on the underlying FileChannel is okay. I'm puzzled by the previous code as I would have expected it to restore the position (make me wonder if there are zipfs tests for this). My reading of the existing code is that the only position-influenced method called on the channel (either via `ZipFileSystem.ch` or `ZipFileSystem$EntryInputStream.zfch`) is `read`, and this is only called in the `.position(pos).read(...)` idiom. The failure to reset the position doesn't affect correctness. However the `synchronzized` _is_ definitely needed to avoid races. Incidentally, regarding this comment: private class EntryInputStream extends InputStream { private final SeekableByteChannel zfch; // local ref to zipfs's "ch". zipfs.ch might // point to a new channel after sync() If the file system is writable and updated, the underlying file is deleted and replaced with a temporary file by `close()` / `sync()`, but `ZipFileSystem.ch` is itself final since d581e4f4. I believe the comment is outdated and `EntryInputStream` could just access ch via the outer pointer. That change would simplify this patch marginally. ------------- PR: https://git.openjdk.java.net/jdk/pull/3853 From jzaugg at openjdk.java.net Wed May 5 23:40:20 2021 From: jzaugg at openjdk.java.net (Jason Zaugg) Date: Wed, 5 May 2021 23:40:20 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v3] In-Reply-To: References: Message-ID: > If the given Path represents a file, use the overload of read defined > in FileChannel that accepts an explicit position and avoid serializing > reads. > > Note: The underlying NIO implementation is not required to implement > FileChannel.read(ByteBuffer, long) concurrently; Windows still appears > to lock, as it returns true for NativeDispatcher.needsPositionLock. > > > On MacOS X, the enclosed benchmark improves from: > > > Benchmark Mode Cnt Score Error Units > ZipFileSystemBenchmark.read avgt 10 75.311 ? 3.301 ms/op > > > To: > > > Benchmark Mode Cnt Score Error Units > ZipFileSystemBenchmark.read avgt 10 12.520 ? 0.875 ms/op Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: Access ZipFileSystem.ch via outer pointer as it is now final ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3853/files - new: https://git.openjdk.java.net/jdk/pull/3853/files/0859d2d6..bccf5d3c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3853&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3853&range=01-02 Stats: 15 lines in 1 file changed: 0 ins; 11 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3853/head:pull/3853 PR: https://git.openjdk.java.net/jdk/pull/3853 From jzaugg at openjdk.java.net Wed May 5 23:40:21 2021 From: jzaugg at openjdk.java.net (Jason Zaugg) Date: Wed, 5 May 2021 23:40:21 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v3] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 23:23:21 GMT, Jason Zaugg wrote: >> I think using the positional read on the underlying FileChannel is okay. I'm puzzled by the previous code as I would have expected it to restore the position (make me wonder if there are zipfs tests for this). > > My reading of the existing code is that the only position-influenced method called on the channel (either via `ZipFileSystem.ch` or `ZipFileSystem$EntryInputStream.zfch`) is `read`, and this is only called in the `.position(pos).read(...)` idiom. The failure to reset the position doesn't affect correctness. However the `synchronzized` _is_ definitely needed to avoid races. > > Incidentally, regarding this comment: > > private class EntryInputStream extends InputStream { > private final SeekableByteChannel zfch; // local ref to zipfs's "ch". zipfs.ch might > // point to a new channel after sync() > > If the file system is writable and updated, the underlying file is deleted and replaced with a temporary file by `close()` / `sync()`, but `ZipFileSystem.ch` is itself final since d581e4f4. I believe the comment is outdated and `EntryInputStream` could just access ch via the outer pointer. That change would simplify this patch marginally. I've added the simplifying commit for now, but I'm happy to split that to a separate change if you prefer. ------------- PR: https://git.openjdk.java.net/jdk/pull/3853 From jzaugg at openjdk.java.net Thu May 6 00:03:20 2021 From: jzaugg at openjdk.java.net (Jason Zaugg) Date: Thu, 6 May 2021 00:03:20 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v4] In-Reply-To: References: Message-ID: > If the given Path represents a file, use the overload of read defined > in FileChannel that accepts an explicit position and avoid serializing > reads. > > Note: The underlying NIO implementation is not required to implement > FileChannel.read(ByteBuffer, long) concurrently; Windows still appears > to lock, as it returns true for NativeDispatcher.needsPositionLock. > > > On MacOS X, the enclosed benchmark improves from: > > > Benchmark Mode Cnt Score Error Units > ZipFileSystemBenchmark.read avgt 10 75.311 ? 3.301 ms/op > > > To: > > > Benchmark Mode Cnt Score Error Units > ZipFileSystemBenchmark.read avgt 10 12.520 ? 0.875 ms/op Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: Remove redundant cast from previous commit. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3853/files - new: https://git.openjdk.java.net/jdk/pull/3853/files/bccf5d3c..c9758c58 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3853&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3853&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3853/head:pull/3853 PR: https://git.openjdk.java.net/jdk/pull/3853 From joehw at openjdk.java.net Thu May 6 00:25:17 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 6 May 2021 00:25:17 GMT Subject: RFR: 8255035: Update BCEL to Version 6.5.0 Message-ID: Update BCEL to the latest version (6.5.0). The majority of the changes were code refactoring (name format changes). XML tests passed on both Linux and Windows. ------------- Commit messages: - 8255035: Update BCEL to Version 6.5.0 Changes: https://git.openjdk.java.net/jdk/pull/3893/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3893&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255035 Stats: 2148 lines in 94 files changed: 98 ins; 33 del; 2017 mod Patch: https://git.openjdk.java.net/jdk/pull/3893.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3893/head:pull/3893 PR: https://git.openjdk.java.net/jdk/pull/3893 From buddyliao at tencent.com Thu May 6 03:47:32 2021 From: buddyliao at tencent.com (=?utf-8?B?YnVkZHlsaWFvKOW7luW9rCk=?=) Date: Thu, 6 May 2021 03:47:32 +0000 Subject: =?utf-8?B?WzExdV0gUkZSIDgyNjYzNTI6IEFkZCBwYXJhbGxlbCBoZWFwIGl0ZXJhdGlv?= =?utf-8?B?biBmb3Igam1hcCDigJNoaXN0bw==?= Message-ID: <51C22C0C-781C-41FD-9F5C-FFF58BC05353@tencent.com> Dear all, Would you help me to review the following backport from jdk-master? Original bug: https://bugs.openjdk.java.net/browse/JDK-8215624 http://hg.openjdk.java.net/jdk/jdk/rev/b1afb7c82d59 Original CSR: https://bugs.openjdk.java.net/browse/JDK-8266353 Original patch does not apply cleanly to 11u, because jmap command parameter is different between each other, and the code structure has little changed. Notably, I had to change the src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java to make it matches 11u-dev 11u webrev: https://cr.openjdk.java.net/~lzang/BuddyLiao/8266352/webrev01/ Testing: x86_64 build, affected tests, tier1 Thanks, -Buddy From buddyliao at tencent.com Thu May 6 03:55:24 2021 From: buddyliao at tencent.com (=?utf-8?B?YnVkZHlsaWFvKOW7luW9rCk=?=) Date: Thu, 6 May 2021 03:55:24 +0000 Subject: [11u] RFR 8266354: JDK-8215624 causes assert(worker_id < _n_workers) failed: Invalid worker_id Message-ID: <1CA90AA9-7438-42F4-A92C-E020B20C9915@tencent.com> Dear all, Would you help me to review the following backport from jdk-master? This backport is bugfix for the prefer backport https://bugs.openjdk.java.net/browse/JDK-8266352 Original bug: https://bugs.openjdk.java.net/browse/JDK-8251570 https://hg.openjdk.java.net/jdk/jdk/rev/dd827a012e43 Original patch does not apply cleanly to 11u, since the code structure has changed. Notably, I had to make it fit with 11u-dev. 11u webrev: https://cr.openjdk.java.net/~lzang/BuddyLiao/8266354/webrev01/ Testing: x86_64 build, affected tests, tier1 Thanks, -Buddy From github.com+10835776+stsypanov at openjdk.java.net Thu May 6 06:08:52 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 6 May 2021 06:08:52 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes [v2] In-Reply-To: References: <_Fts6pm4DVuhgAyQ_5lxu38cPGxDbZuLqNeCjGPttLE=.d04df608-79e2-458c-935d-4bb8dfa52a85@github.com> Message-ID: On Wed, 5 May 2021 13:20:13 GMT, Vladimir Sitnikov wrote: >> We usually don't do that for OutOfMemoryError because concatenation implies allocation > > Well, here `OutOfMemory` is more like "I can't read all the data since the array won't fit". > It would definitely help to have actual file size there, especially in case filesystem returns weird values (e.g. negative file length). > > This branch will almost never be taken, and even if taken, it won't be "low memory" condition. So the allocation does not hurt, however, it would simplify the analysis should the case trigger. What about adding the filename into exception message? ------------- PR: https://git.openjdk.java.net/jdk/pull/3845 From winterhalter at openjdk.java.net Thu May 6 06:13:11 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Thu, 6 May 2021 06:13:11 GMT Subject: RFR: 8266598: Exception values for AnnotationTypeMismatchException are not always informative [v2] In-Reply-To: References: Message-ID: > This improves the messages that are provided by `AnnotationTypeMismatchException`s. The message provided by AnnotationTypeMismatchExceptions is deliberately undefined such that this should not break any contract. Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8266598: Exception values for AnnotationTypeMismatchException are not always informative ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3892/files - new: https://git.openjdk.java.net/jdk/pull/3892/files/5e61d239..57ab3721 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3892&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3892&range=00-01 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3892.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3892/head:pull/3892 PR: https://git.openjdk.java.net/jdk/pull/3892 From ngasson at openjdk.java.net Thu May 6 06:22:51 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 6 May 2021 06:22:51 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native In-Reply-To: References: Message-ID: <3wVA2QxMkPwtvKB3EUtERWG608pln5IADuW7Yxn4ePs=.9809a6a1-c7b7-4ad9-9c90-125abed9dcfe@github.com> On Mon, 26 Apr 2021 12:52:54 GMT, Jorn Vernee wrote: >> macOS on Apple silicon uses slightly different ABI conventions to the >> standard AArch64 ABI. The differences are outlined in [1]. In >> particular in the standard (AAPCS) ABI, variadic arguments may be passed >> in either registers or on the stack following the normal calling >> convention. To handle this, va_list is a struct containing separate >> pointers for arguments located in integer registers, floating point >> registers, and on the stack. Apple's ABI simplifies this by passing all >> variadic arguments on the stack and the va_list type becomes a simple >> char* pointer. >> >> This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to >> represent the new ABI variant on macOS. StackVaList is based on >> WinVaList lightly modified to handle the different TypeClasses on >> AArch64. The original AArch64Linker is renamed to AapcsLinker and is >> currently used for all non-Mac platforms. I think we also need to add a >> WinAArch64 CABI but I haven't yet been able to test on a Windows system >> so will do that later. >> >> The macOS ABI also uses a different method of spilling arguments to the >> stack (the standard ABI pads each argument to a multiple of 8 byte stack >> slots, but the Mac ABI packs arguments according to their natural >> alignment). None of the existing tests exercise this so I'll open a new >> JBS issue and work on that separately. >> >> Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. >> >> [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms > > Hi Nick. Sorry for the late reply, I've been out sick. I'll hopefully be taking a thorough look at this soon (still catching up on things). > > I'm pretty impressed that such a large amount of code can just be shared between the two platforms :) @JornVernee thanks for the review. I'll park this until the JEP is integrated and then fix it up afterwards. ------------- PR: https://git.openjdk.java.net/jdk/pull/3617 From ysuenaga at openjdk.java.net Thu May 6 06:59:51 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 6 May 2021 06:59:51 GMT Subject: RFR: 8266168: -Wmaybe-uninitialized happens in check_code.c In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 06:54:33 GMT, Yasumasa Suenaga wrote: > We can see following compiler warning in check_code.c on GCC 11. Ping: Could you review this PR? We still see this warning with GCC 11.1. ------------- PR: https://git.openjdk.java.net/jdk/pull/3787 From Alan.Bateman at oracle.com Thu May 6 07:29:33 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 6 May 2021 08:29:33 +0100 Subject: =?UTF-8?Q?Re=3a_=5b11u=5d_RFR_8266352=3a_Add_parallel_heap_iteratio?= =?UTF-8?Q?n_for_jmap_=e2=80=93histo?= In-Reply-To: <51C22C0C-781C-41FD-9F5C-FFF58BC05353@tencent.com> References: <51C22C0C-781C-41FD-9F5C-FFF58BC05353@tencent.com> Message-ID: On 06/05/2021 04:47, buddyliao(??) wrote: > Dear all, > > Would you help me to review the following backport from jdk-master? > I think you are looking for jdk-updates-dev, the folks there will guide you through how to get approval for these serviceability and GC changes. -Alan From stuefe at openjdk.java.net Thu May 6 07:28:50 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 07:28:50 GMT Subject: RFR: 8266168: -Wmaybe-uninitialized happens in check_code.c In-Reply-To: References: Message-ID: <7h_9EydZNbHPn-Fs8OB8Bs7yVqJwoK1GfFfwlewcyNs=.d538be87-de07-423c-8235-78e5c1ef1bd0@github.com> On Thu, 29 Apr 2021 06:54:33 GMT, Yasumasa Suenaga wrote: > We can see following compiler warning in check_code.c on GCC 11. LGTM. I am not aware of any platform where sizeof(char) is not 1, but good to be prepared :) ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3787 From alanb at openjdk.java.net Thu May 6 07:43:54 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 6 May 2021 07:43:54 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v4] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 00:03:20 GMT, Jason Zaugg wrote: >> If the given Path represents a file, use the overload of read defined >> in FileChannel that accepts an explicit position and avoid serializing >> reads. >> >> Note: The underlying NIO implementation is not required to implement >> FileChannel.read(ByteBuffer, long) concurrently; Windows still appears >> to lock, as it returns true for NativeDispatcher.needsPositionLock. >> >> >> On MacOS X, the enclosed benchmark improves from: >> >> >> Benchmark Mode Cnt Score Error Units >> ZipFileSystemBenchmark.read avgt 10 75.311 ? 3.301 ms/op >> >> >> To: >> >> >> Benchmark Mode Cnt Score Error Units >> ZipFileSystemBenchmark.read avgt 10 12.520 ? 0.875 ms/op > > Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: > > Remove redundant cast from previous commit. src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1235: > 1233: synchronized(ch) { > 1234: return ch.position(pos).read(bb); > 1235: } I think it's okay to include the update to EntryInputStream, that part looks fine, as does the directly use of the FileChannel positional read. I'm still mulling over the case where ch is not a FileChannel as I would expected it to capture the existing position and restore it after the read. I think this is the degenerative case when the zip file is located in a custom file system that doesn't support FileChannel. In that case, positional read has to be implemented on the most basic SeekableByteChannel. It would only be observed when mixing positional read ops with other ops that depend on the current position. ------------- PR: https://git.openjdk.java.net/jdk/pull/3853 From jzaugg at openjdk.java.net Thu May 6 08:07:51 2021 From: jzaugg at openjdk.java.net (Jason Zaugg) Date: Thu, 6 May 2021 08:07:51 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v4] In-Reply-To: References: Message-ID: <2yiP6HEx1W_6XobXJxeo_NuQjFROQpRVZZp8_RP1jrE=.9aa6c044-442e-4435-83b3-bd3f68c3c043@github.com> On Thu, 6 May 2021 07:41:00 GMT, Alan Bateman wrote: >> Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove redundant cast from previous commit. > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1235: > >> 1233: synchronized(ch) { >> 1234: return ch.position(pos).read(bb); >> 1235: } > > I think it's okay to include the update to EntryInputStream, that part looks fine, as does the directly use of the FileChannel positional read. > > I'm still mulling over the case where ch is not a FileChannel as I would expected it to capture the existing position and restore it after the read. I think this is the degenerative case when the zip file is located in a custom file system that doesn't support FileChannel. In that case, positional read has to be implemented on the most basic SeekableByteChannel. It would only be observed when mixing positional read ops with other ops that depend on the current position. Here are all the references to `ch`. this.ch = Files.newByteChannel(zfpath, READ); ... this.ch.close(); ... ch.close(); // close the ch just in case no update ... if (ch instanceof FileChannel fch) { return fch.read(bb, pos); } else { synchronized(ch) { return ch.position(pos).read(bb); } } ... long ziplen = ch.size(); ... ch.close(); It appears the only position-dependent operation called `read(ByteBuffer)`. This is performed together with the `pos` call within the `synchronized(ch)` lock. ------------- PR: https://git.openjdk.java.net/jdk/pull/3853 From ngasson at openjdk.java.net Thu May 6 08:25:52 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 6 May 2021 08:25:52 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native In-Reply-To: <3KN4x4CVsGIJMhA7Z81hMYgQ_cj3h29ZjwwLjmKL2Cg=.fc35968a-3825-40ee-b97a-130541b9574e@github.com> References: <3KN4x4CVsGIJMhA7Z81hMYgQ_cj3h29ZjwwLjmKL2Cg=.fc35968a-3825-40ee-b97a-130541b9574e@github.com> Message-ID: On Mon, 3 May 2021 15:37:44 GMT, Jorn Vernee wrote: >> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/StackVaList.java line 131: >> >>> 129: MemorySegment struct = allocator.allocate(layout); >>> 130: struct.copyFrom(segment.asSlice(0L, layout.byteSize())); >>> 131: segment = segment.asSlice(VA_SLOT_SIZE_BYTES); >> >> Since arguments are packed according to alignment, I guess the offset could be larger or smaller than 8 bytes as well? > > This is using `alignUp(arg.layout.byteSize(), VA_SLOT_SIZE_BYTES)` in the writing code, so I think it should be the same here? Yes this is a mistake (`skip()` has the same problem). I'll add an extra case to VaListTest to catch it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3617 From yyang at openjdk.java.net Thu May 6 10:14:16 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 6 May 2021 10:14:16 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v7] In-Reply-To: References: Message-ID: > The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. > > In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. > > But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: > > 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. > 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag > > Testing: cds, compiler and jdk Yi Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - cmp clobbers its left argument on x86_32 - Merge branch 'master' into consolidate_checkindex - better check1-4 - AssertionError when expected exception was not thrown - remove extra newline - remove InlineNIOCheckIndex flag - remove java_nio_Buffer in javaClasses.hpp - consolidate ------------- Changes: https://git.openjdk.java.net/jdk/pull/3615/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=06 Stats: 331 lines in 11 files changed: 235 ins; 78 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/3615.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615 PR: https://git.openjdk.java.net/jdk/pull/3615 From yyang at openjdk.java.net Thu May 6 11:17:18 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 6 May 2021 11:17:18 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v8] In-Reply-To: References: Message-ID: > The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. > > In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. > > But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: > > 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. > 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag > > Testing: cds, compiler and jdk Yi Yang has updated the pull request incrementally with one additional commit since the last revision: build failed ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3615/files - new: https://git.openjdk.java.net/jdk/pull/3615/files/e4959148..f996c99f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=06-07 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3615.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615 PR: https://git.openjdk.java.net/jdk/pull/3615 From github.com+762126+ignasi35 at openjdk.java.net Thu May 6 11:57:13 2021 From: github.com+762126+ignasi35 at openjdk.java.net (Ignasi Marimon-Clos) Date: Thu, 6 May 2021 11:57:13 GMT Subject: RFR: 8266578: Disambiguate BigDecimal description of scale Message-ID: The API Docs for `BigDecimal` introduce the meaning of `scale`. The current writeup can be missleading when presenting the meaning of a `scale` value that's negative. Hopefully, with this PR, the sentence is more clear. The ambiguity is on this sentence: > If negative, the unscaled value of the number is ... Instead, I suggest the more verbose: > If the scale is negative, the unscaled value of the number is ... To keep symmetry, I've also reviewed the positive case from: > If zero or positive, the scale is the number of digits ... to: > If the scale is zero or positive, the scale is the number of digits ... ------------- Commit messages: - Merge branch 'master' into minor-disambiguation - Disambiguate the BigDecimal docs Changes: https://git.openjdk.java.net/jdk/pull/582/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=582&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266578 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/582.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/582/head:pull/582 PR: https://git.openjdk.java.net/jdk/pull/582 From github.com+762126+ignasi35 at openjdk.java.net Thu May 6 11:57:14 2021 From: github.com+762126+ignasi35 at openjdk.java.net (Ignasi Marimon-Clos) Date: Thu, 6 May 2021 11:57:14 GMT Subject: RFR: 8266578: Disambiguate BigDecimal description of scale In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 16:14:59 GMT, Ignasi Marimon-Clos wrote: > The API Docs for `BigDecimal` introduce the meaning of `scale`. The current writeup can be missleading when presenting the meaning of a `scale` value that's negative. Hopefully, with this PR, the sentence is more clear. > > The ambiguity is on this sentence: > >> If negative, the unscaled value of the number is ... > > Instead, I suggest the more verbose: > >> If the scale is negative, the unscaled value of the number is ... > > To keep symmetry, I've also reviewed the positive case from: > >> If zero or positive, the scale is the number of digits ... > > to: > >> If the scale is zero or positive, the scale is the number of digits ... I'm trying to see what's the cause for the Check failure in `jcheck` but clicking `Details` opens http://openjdk.java.net/ without too much information to point me to the actual issue causing the check failure. ------------- PR: https://git.openjdk.java.net/jdk/pull/582 From bpb at openjdk.java.net Thu May 6 11:57:14 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 6 May 2021 11:57:14 GMT Subject: RFR: 8266578: Disambiguate BigDecimal description of scale In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 16:14:59 GMT, Ignasi Marimon-Clos wrote: > The API Docs for `BigDecimal` introduce the meaning of `scale`. The current writeup can be missleading when presenting the meaning of a `scale` value that's negative. Hopefully, with this PR, the sentence is more clear. > > The ambiguity is on this sentence: > >> If negative, the unscaled value of the number is ... > > Instead, I suggest the more verbose: > >> If the scale is negative, the unscaled value of the number is ... > > To keep symmetry, I've also reviewed the positive case from: > >> If zero or positive, the scale is the number of digits ... > > to: > >> If the scale is zero or positive, the scale is the number of digits ... The `jcheck` test fails because "The commit message does not reference any issue. To add an issue reference to this PR, edit the title to be of the format `issue number: message`." ------------- PR: https://git.openjdk.java.net/jdk/pull/582 From bpb at openjdk.java.net Thu May 6 11:57:14 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 6 May 2021 11:57:14 GMT Subject: RFR: 8266578: Disambiguate BigDecimal description of scale In-Reply-To: <-poU2zYk5Di1PwXpSe2F8pkhKHD7rXuSVf43zDKDx0U=.e6ab5868-1f5a-462c-9e59-3f5754874980@github.com> References: <-poU2zYk5Di1PwXpSe2F8pkhKHD7rXuSVf43zDKDx0U=.e6ab5868-1f5a-462c-9e59-3f5754874980@github.com> Message-ID: On Tue, 12 Jan 2021 14:07:23 GMT, Ignasi Marimon-Clos wrote: >> The `jcheck` test fails because "The commit message does not reference any issue. To add an issue reference to this PR, edit the title to be of the format `issue number: message`." > > Thanks @bplb. I'm afraid I'm not an [author](http://openjdk.java.net/bylaws#author) or have access to create or read the issues in [JIRA](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1). > > I am a first-time crontributor and I'm unfamiliar with the specifics on contributing. @ignasi35 Do you wish to continue this PR? If so I will file an issue. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/582 From github.com+762126+ignasi35 at openjdk.java.net Thu May 6 11:57:14 2021 From: github.com+762126+ignasi35 at openjdk.java.net (Ignasi Marimon-Clos) Date: Thu, 6 May 2021 11:57:14 GMT Subject: RFR: 8266578: Disambiguate BigDecimal description of scale In-Reply-To: References: Message-ID: <-poU2zYk5Di1PwXpSe2F8pkhKHD7rXuSVf43zDKDx0U=.e6ab5868-1f5a-462c-9e59-3f5754874980@github.com> On Mon, 4 Jan 2021 19:31:40 GMT, Brian Burkhalter wrote: >> The API Docs for `BigDecimal` introduce the meaning of `scale`. The current writeup can be missleading when presenting the meaning of a `scale` value that's negative. Hopefully, with this PR, the sentence is more clear. >> >> The ambiguity is on this sentence: >> >>> If negative, the unscaled value of the number is ... >> >> Instead, I suggest the more verbose: >> >>> If the scale is negative, the unscaled value of the number is ... >> >> To keep symmetry, I've also reviewed the positive case from: >> >>> If zero or positive, the scale is the number of digits ... >> >> to: >> >>> If the scale is zero or positive, the scale is the number of digits ... > > The `jcheck` test fails because "The commit message does not reference any issue. To add an issue reference to this PR, edit the title to be of the format `issue number: message`." Thanks @bplb. I'm afraid I'm not an [author](http://openjdk.java.net/bylaws#author) or have access to create or read the issues in [JIRA](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1). I am a first-time crontributor and I'm unfamiliar with the specifics on contributing. ------------- PR: https://git.openjdk.java.net/jdk/pull/582 From bpb at openjdk.java.net Thu May 6 11:57:14 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 6 May 2021 11:57:14 GMT Subject: RFR: 8266578: Disambiguate BigDecimal description of scale In-Reply-To: References: <-poU2zYk5Di1PwXpSe2F8pkhKHD7rXuSVf43zDKDx0U=.e6ab5868-1f5a-462c-9e59-3f5754874980@github.com> Message-ID: <9gPFpTfPobzh9wUlx9Q4KAo5V7TXidqZUGqwGl-zml0=.0c80c124-dded-41e7-94d1-5073032b84fc@github.com> On Mon, 3 May 2021 16:45:22 GMT, Ignasi Marimon-Clos wrote: >> Thanks @bplb. I'm afraid I'm not an [author](http://openjdk.java.net/bylaws#author) or have access to create or read the issues in [JIRA](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1). >> >> I am a first-time crontributor and I'm unfamiliar with the specifics on contributing. > >> @ignasi35 Do you wish to continue this PR? If so I will file an issue. Thanks. > > Hi @bplb, this completely fell through the cracks. If you could file the issue for me I'd really appreciate it. Thanks. @ignasi35 I have created JDK-8266578. Please change the name of this PR to: `8266578: Disambiguate BigDecimal description of scale` Please resolve any conflicts and commit the updated file. Once the update is available, I will file a CSR and mark this PR accordingly. ------------- PR: https://git.openjdk.java.net/jdk/pull/582 From github.com+762126+ignasi35 at openjdk.java.net Thu May 6 11:57:14 2021 From: github.com+762126+ignasi35 at openjdk.java.net (Ignasi Marimon-Clos) Date: Thu, 6 May 2021 11:57:14 GMT Subject: RFR: 8266578: Disambiguate BigDecimal description of scale In-Reply-To: <-poU2zYk5Di1PwXpSe2F8pkhKHD7rXuSVf43zDKDx0U=.e6ab5868-1f5a-462c-9e59-3f5754874980@github.com> References: <-poU2zYk5Di1PwXpSe2F8pkhKHD7rXuSVf43zDKDx0U=.e6ab5868-1f5a-462c-9e59-3f5754874980@github.com> Message-ID: On Tue, 12 Jan 2021 14:07:23 GMT, Ignasi Marimon-Clos wrote: >> The `jcheck` test fails because "The commit message does not reference any issue. To add an issue reference to this PR, edit the title to be of the format `issue number: message`." > > Thanks @bplb. I'm afraid I'm not an [author](http://openjdk.java.net/bylaws#author) or have access to create or read the issues in [JIRA](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1). > > I am a first-time crontributor and I'm unfamiliar with the specifics on contributing. > @ignasi35 Do you wish to continue this PR? If so I will file an issue. Thanks. Hi @bplb, this completely fell through the cracks. If you could file the issue for me I'd really appreciate it. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/582 From github.com+762126+ignasi35 at openjdk.java.net Thu May 6 11:57:15 2021 From: github.com+762126+ignasi35 at openjdk.java.net (Ignasi Marimon-Clos) Date: Thu, 6 May 2021 11:57:15 GMT Subject: RFR: 8266578: Disambiguate BigDecimal description of scale In-Reply-To: <9gPFpTfPobzh9wUlx9Q4KAo5V7TXidqZUGqwGl-zml0=.0c80c124-dded-41e7-94d1-5073032b84fc@github.com> References: <-poU2zYk5Di1PwXpSe2F8pkhKHD7rXuSVf43zDKDx0U=.e6ab5868-1f5a-462c-9e59-3f5754874980@github.com> <9gPFpTfPobzh9wUlx9Q4KAo5V7TXidqZUGqwGl-zml0=.0c80c124-dded-41e7-94d1-5073032b84fc@github.com> Message-ID: On Wed, 5 May 2021 20:29:59 GMT, Brian Burkhalter wrote: >>> @ignasi35 Do you wish to continue this PR? If so I will file an issue. Thanks. >> >> Hi @bplb, this completely fell through the cracks. If you could file the issue for me I'd really appreciate it. Thanks. > > @ignasi35 I have created JDK-8266578. Please change the name of this PR to: > > `8266578: Disambiguate BigDecimal description of scale` > > Please resolve any conflicts and commit the updated file. Once the update is available, I will file a CSR and mark this PR accordingly. Thanks @bplb for doing the heavy lifting. I've updated the PR title and solved the conflict. ------------- PR: https://git.openjdk.java.net/jdk/pull/582 From ysuenaga at openjdk.java.net Thu May 6 11:57:53 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 6 May 2021 11:57:53 GMT Subject: Integrated: 8266168: -Wmaybe-uninitialized happens in check_code.c In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 06:54:33 GMT, Yasumasa Suenaga wrote: > We can see following compiler warning in check_code.c on GCC 11. This pull request has now been integrated. Changeset: 0f9852c6 Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/0f9852c63b12c43b52615ea003a4fc1d69ad3ada Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8266168: -Wmaybe-uninitialized happens in check_code.c Reviewed-by: stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/3787 From github.com+3019228+codonell at openjdk.java.net Thu May 6 12:21:54 2021 From: github.com+3019228+codonell at openjdk.java.net (Carlos O'Donell) Date: Thu, 6 May 2021 12:21:54 GMT Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64. In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne wrote: > Glibc 2.29 onwards provides optimised versions of log,log10,exp. > These functions have an accuracy of 0.9ulp or better in glibc > 2.29. > > Therefore this patch adds code to parse, store and check > the runtime glibcs version in os_linux.cpp/hpp. > This is then used to select the glibcs implementation of > log, log10, exp at runtime for c1 and c2, iff we have > glibc 2.29 or greater. > > This will ensure OpenJDK can benefit from future improvements > to glibc. > > Glibc adheres to the ieee754 standard, unless stated otherwise > in its spec. > > As there are no stated exceptions in the current glibc spec > for dlog, dlog10 and dexp, we can assume they currently follow > ieee754 (which testing confirms). As such, future version of > glibc are unlikely to lose this compliance with ieee754 in > future. > > W.r.t performance this patch sees ~15-30% performance improvements for > log and log10, with ~50-80% performance improvements for exp for the > common input ranged (which output real numbers). However for the NaN > and inf output ranges we see a slow down of up to a factor of 2 for > some functions and architectures. > > Due to this being the uncommon case we assert that this is a > worthwhile tradeoff. Where does the requirement for monotonicity come from? ------------- PR: https://git.openjdk.java.net/jdk/pull/3510 From alanb at openjdk.java.net Thu May 6 13:49:51 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 6 May 2021 13:49:51 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes [v5] In-Reply-To: <_i5jAuxQQbKqnUpaAe4ZO3mFiwHRm-QRTlBqBA-2OoU=.833d7b89-a6ad-44c8-bdb1-8e502772a5b7@github.com> References: <9tQtXd_Kt0D-zQJBlR0pMYnLewa-72ZS3NqmQ8sQjLg=.c5d0a1ca-86a1-4ecd-9c96-64df3e79e7d1@github.com> <_i5jAuxQQbKqnUpaAe4ZO3mFiwHRm-QRTlBqBA-2OoU=.833d7b89-a6ad-44c8-bdb1-8e502772a5b7@github.com> Message-ID: On Tue, 4 May 2021 20:13:20 GMT, Brian Burkhalter wrote: >> On `/proc/cpuinfo` for example, `fstat()` succeeds but `st_size` in `struct stat` is zero. The correct position is however returned by `lseek()`. Apparently this proposal needs to be reworked to expect size zero when the size is in fact non-zero. > > Updated to handle `length() == 0` case. Not sure however whether for this case it might not be better just to fall back to `super.readXBytes()` instead. Can you rename the native length and position methods to length0 and position0 as we will need to wrap these methods later. Also it will keep them consistent with RAF. ------------- PR: https://git.openjdk.java.net/jdk/pull/3845 From lancea at openjdk.java.net Thu May 6 14:16:52 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 6 May 2021 14:16:52 GMT Subject: Integrated: 8266579: Update test/jdk/java/lang/ProcessHandle/PermissionTest.java & test/jdk/java/sql/testng/util/TestPolicy.java In-Reply-To: References: Message-ID: On Wed, 5 May 2021 19:10:21 GMT, Lance Andersen wrote: > Hi all, > > Please review this patch which updates test/jdk/java/lang/ProcessHandle/PermissionTest.java & test/jdk/java/sql/testng/util/TestPolicy.java to include : > > `new PropertyPermission("testng.memory.friendly", "read"); > ` > Which will be needed by TestNG 7.4 > > Best, > Lance This pull request has now been integrated. Changeset: fcedfc8a Author: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/fcedfc8a3b4299372f195cae036129dcd7b740ea Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod 8266579: Update test/jdk/java/lang/ProcessHandle/PermissionTest.java & test/jdk/java/sql/testng/util/TestPolicy.java Reviewed-by: joehw, naoto, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/3888 From lancea at openjdk.java.net Thu May 6 14:21:55 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 6 May 2021 14:21:55 GMT Subject: Integrated: 8266460: java.io tests fail on null stream with upgraded jtreg/TestNG In-Reply-To: References: Message-ID: <7PLT1skFOwasmoVlONjhbb33k32-OCoUD8bokPI_-Jo=.0754afc6-1d5e-42b7-8399-d11697f3b10b@github.com> On Tue, 4 May 2021 20:45:43 GMT, Lance Andersen wrote: > Hi all, > > This fix addresses a change in TestNG behavior for the Before/AfterGroups annotations that was introduced via https://github.com/cbeust/testng/pull/2167. The tests have been verified against the latest TestNG release and continue to run with the current TestNG release used by jtreg This pull request has now been integrated. Changeset: e8405970 Author: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/e8405970b9998ff8f77bcf196f1456713a98c47f Stats: 122 lines in 4 files changed: 12 ins; 24 del; 86 mod 8266460: java.io tests fail on null stream with upgraded jtreg/TestNG Reviewed-by: bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/3866 From mcimadamore at openjdk.java.net Thu May 6 14:23:27 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 6 May 2021 14:23:27 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v12] In-Reply-To: References: Message-ID: <8JEQ3a0tEdpDPGWsHEDFpvegIsnUtoGBQwIga55kVYY=.ac069eb8-fa51-4a13-8349-d655d19eab10@github.com> > 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://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Replace uses of -Djdk.foreign.restricted (useless now) with --enable-native-access ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/72eb9bbc..926229ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=10-11 Stats: 45 lines in 8 files changed: 0 ins; 0 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From kbarrett at openjdk.java.net Thu May 6 15:11:55 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 6 May 2021 15:11:55 GMT Subject: RFR: 8254598: StringDedupTable should use OopStorage In-Reply-To: References: Message-ID: <2VNBXmGCpt8UsMoUEK3erio92KDhFawnW0ynzG78T1I=.096bcc7b-7051-4452-be67-aa99947d18eb@github.com> On Fri, 23 Apr 2021 19:48:47 GMT, Kim Barrett wrote: > Please review this change to the String Deduplication facility. It is being > changed to use OopStorage to hold weak references to relevant objects, > rather than bespoke data structures requiring dedicated processing phases by > supporting GCs. > > (The Shenandoah update was contributed by Zhengyu Gu.) > > This change significantly simplifies the interface between a given GC and > the String Deduplication facility, which should make it much easier for > other GCs to opt in. However, this change does not alter the set of GCs > providing support; currently only G1 and Shenandoah support string > deduplication. Adding support by other GCs will be in followup RFEs. > > Reviewing via the diffs might not be all that useful for some parts, as > several files have been essentially completely replaced, and a number of > files have been added or eliminated. The full webrev might be a better > place to look. > > The major changes are in gc/shared/stringdedup/* and in the supporting > collectors, but there are also some smaller changes in other places, most > notably classfile/{stringTable,javaClasses}. > > This change is additionally labeled for review by core-libs, although there > are no source changes there. This change injects a byte field of bits into > java.lang.String, using one of the previously unused padding bytes in that > class. (There were two unused bytes, now only one.) > > Testing: > mach5 tier1-2 with and without -XX:+UseStringDeduplication > > Locally (linux-x64) ran all of the existing tests that use string > deduplication with both G1 and Shenandoah. Note that > TestStringDeduplicationInterned.java is disabled for shenandoah, as it > currently fails, for reasons I haven't figured out but suspect are test > related. > > - gc/stringdedup/ -- these used to be in gc/g1 > - runtime/cds/SharedStringsDedup.java > - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java > - runtime/cds/appcds/sharedStrings/* > > shenandoah-only: > - gc/shenandoah/jvmti/TestHeapDump.java > - gc/shenandoah/TestStringDedup.java > - gc/shenandoah/TestStringDedupStress.java > > Performance tested baseline, baseline + stringdedup, new with stringdedup, > finding no significant differences. src/hotspot/share/classfile/vmSymbols.hpp line 490: > 488: template(data_cache_line_flush_size_name, "DATA_CACHE_LINE_FLUSH_SIZE") \ > 489: template(during_unsafe_access_name, "during_unsafe_access") \ > 490: template(no_deduplication_name, "no_deduplication") \ This addition was left over from an earlier version of the change, where I'd added an ordinary private boolean member of this name to String. That was before I learned about injected members and before the idea of adding "duplication requested" came up. This name is no longer needed, and I'll be removing it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3662 From github.com+10835776+stsypanov at openjdk.java.net Thu May 6 15:26:10 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 6 May 2021 15:26:10 GMT Subject: RFR: 8266622: Optimize Class.descriptorString() and Class.getCanonicalName0() Message-ID: Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 it appears, that in `j.l.Class` expressions like String str = baseName.replace('.', '/') + '/' + name; are not compiled into invokedynamic-based code, but into one using `StringBuilder`. This happens due to some bootstraping issues. Currently the bytecode for the last (most often used) branch of `Class.descriptorString()` looks like public sb()Ljava/lang/String; L0 LINENUMBER 21 L0 NEW java/lang/StringBuilder DUP INVOKESPECIAL java/lang/StringBuilder. ()V ASTORE 1 L1 LINENUMBER 23 L1 ALOAD 1 LDC "a" INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder; POP L2 LINENUMBER 24 L2 ALOAD 1 LDC "b" INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder; POP L3 LINENUMBER 26 L3 ALOAD 1 INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String; ARETURN Here the `StringBuilder` is created with default constructor and then expands if necessary while appending. This can be improved by manually allocating `StringBuilder` of exact size. The benchmark demonstrates measurable improvement: @State(Scope.Benchmark) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class ClassDescriptorStringBenchmark { private final Class clazzWithShortDescriptor = Object.class; private final Class clazzWithLongDescriptor = getClass(); @Benchmark public String descriptorString_short() { return clazzWithShortDescriptor.descriptorString(); } @Benchmark public String descriptorString_long() { return clazzWithLongDescriptor.descriptorString(); } } original -Xint Mode Score Error Units descriptorString_long avgt 6326.478 ? 107.251 ns/op descriptorString_short avgt 5220.729 ? 103.545 ns/op descriptorString_long:?gc.alloc.rate.norm avgt 528.089 ? 0.021 B/op descriptorString_short:?gc.alloc.rate.norm avgt 232.036 ? 0.015 B/op -XX:TieredStopAtLevel=1 Mode Score Error Units descriptorString_long avgt 230.223 ? 1.254 ns/op descriptorString_short avgt 164.255 ? 0.755 ns/op descriptorString_long:?gc.alloc.rate.norm avgt 528.046 ? 0.002 B/op descriptorString_short:?gc.alloc.rate.norm avgt 232.022 ? 0.001 B/op full Mode Score Error Units descriptorString_long avgt 74.835 ? 0.262 ns/op descriptorString_short avgt 43.822 ? 0.788 ns/op descriptorString_long:?gc.alloc.rate.norm avgt 504.010 ? 0.001 B/op descriptorString_short:?gc.alloc.rate.norm avgt 208.004 ? 0.001 B/op ------------------------ patched -Xint Mode Score Error Units descriptorString_long avgt 4485.994 ? 60.173 ns/op descriptorString_short avgt 3949.965 ? 278.143 ns/op descriptorString_long:?gc.alloc.rate.norm avgt 336.051 ? 0.004 B/op descriptorString_short:?gc.alloc.rate.norm avgt 184.027 ? 0.010 B/op -XX:TieredStopAtLevel=1 Mode Score Error Units descriptorString_long avgt 185.774 ? 1.100 ns/op descriptorString_short avgt 135.338 ? 1.066 ns/op descriptorString_long:?gc.alloc.rate.norm avgt 336.030 ? 0.001 B/op descriptorString_short:?gc.alloc.rate.norm avgt 184.019 ? 0.001 B/op full Mode Score Error Units descriptorString_long avgt 42.864 ? 0.160 ns/op descriptorString_short avgt 27.255 ? 0.381 ns/op descriptorString_long:?gc.alloc.rate.norm avgt 224.005 ? 0.001 B/op descriptorString_short:?gc.alloc.rate.norm avgt 120.002 ? 0.001 B/op Same can be done also for Class.isHidden() branch in Class.descriptorString() and for Class.getCanonicalName0() ------------- Commit messages: - 8266622: Optimize Class.descriptorString() and Class.getCanonicalName0() Changes: https://git.openjdk.java.net/jdk/pull/3903/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3903&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266622 Stats: 19 lines in 1 file changed: 15 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3903.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3903/head:pull/3903 PR: https://git.openjdk.java.net/jdk/pull/3903 From dfuchs at openjdk.java.net Thu May 6 15:32:11 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 6 May 2021 15:32:11 GMT Subject: RFR: 8266646: Add more diagnostic to java/lang/System/LoggerFinder/modules Message-ID: Hi, please find here a trivial test change that adds some diagnostic (time stamps) to the LoggerFinder/modules subprocess test logs. ------------- Commit messages: - 8266646: Add more diagnostic to java/lang/System/LoggerFinder/modules Changes: https://git.openjdk.java.net/jdk/pull/3904/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3904&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266646 Stats: 38 lines in 4 files changed: 27 ins; 2 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3904.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3904/head:pull/3904 PR: https://git.openjdk.java.net/jdk/pull/3904 From naoto at openjdk.java.net Thu May 6 16:09:53 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 6 May 2021 16:09:53 GMT Subject: RFR: 8266646: Add more diagnostic to java/lang/System/LoggerFinder/modules In-Reply-To: References: Message-ID: <_7ohwrPRJoxdkyFQ8sjG1mKUEkOY-pg4iJhiw1W4rPI=.722e3741-11f8-4dee-a37a-7802c34d2903@github.com> On Thu, 6 May 2021 15:25:10 GMT, Daniel Fuchs wrote: > Hi, please find here a trivial test change that adds some diagnostic (time stamps) to the LoggerFinder/modules subprocess test logs. Could those be replaced with just `Instant.now()`? `Instant.toString()` uses the same formatter as `ISO_INSTANT`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3904 From joe.darcy at oracle.com Thu May 6 16:29:49 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 6 May 2021 09:29:49 -0700 Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64. In-Reply-To: References: Message-ID: <8f0f75d9-294b-0770-684f-4b291e4399b9@oracle.com> On 5/6/2021 5:21 AM, Carlos O'Donell wrote: > On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne wrote: > >> Glibc 2.29 onwards provides optimised versions of log,log10,exp. >> These functions have an accuracy of 0.9ulp or better in glibc >> 2.29. >> >> Therefore this patch adds code to parse, store and check >> the runtime glibcs version in os_linux.cpp/hpp. >> This is then used to select the glibcs implementation of >> log, log10, exp at runtime for c1 and c2, iff we have >> glibc 2.29 or greater. >> >> This will ensure OpenJDK can benefit from future improvements >> to glibc. >> >> Glibc adheres to the ieee754 standard, unless stated otherwise >> in its spec. >> >> As there are no stated exceptions in the current glibc spec >> for dlog, dlog10 and dexp, we can assume they currently follow >> ieee754 (which testing confirms). As such, future version of >> glibc are unlikely to lose this compliance with ieee754 in >> future. >> >> W.r.t performance this patch sees ~15-30% performance improvements for >> log and log10, with ~50-80% performance improvements for exp for the >> common input ranged (which output real numbers). However for the NaN >> and inf output ranges we see a slow down of up to a factor of 2 for >> some functions and architectures. >> >> Due to this being the uncommon case we assert that this is a >> worthwhile tradeoff. > Where does the requirement for monotonicity come from? > From the specifications: "The computed result [of log] must be within 1 ulp of the exact result. Results must be semi-monotonic." https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/Math.html#log(double) and similarly for the other method. -Joe From minqi at openjdk.java.net Thu May 6 16:29:32 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 6 May 2021 16:29:32 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v3] In-Reply-To: References: Message-ID: <8fMjK5oCjC9P53PPQ56P-oHIuj8PImVj8m-RWpw-WrY=.f932094b-8936-40e7-9d6c-692564a2f293@github.com> > Hi, Please review > When using jcmd to dump shared archive, if the archive name exists, it will be deleted first. If exception happens during dumping process, there is no new archive created. This PR changes to first dump the archive with a temporary file name. With successful dump, the temporary file will be rename to its given name. This way the old archive will not be touched on exception. > The newly added test case skipped testing on Windows since File operation result is not same as on Linux. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Fixed temp file operation, archive and temp file name consistency ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3886/files - new: https://git.openjdk.java.net/jdk/pull/3886/files/b420da7b..83478dd1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3886&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3886&range=01-02 Stats: 289 lines in 5 files changed: 120 ins; 138 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/3886.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3886/head:pull/3886 PR: https://git.openjdk.java.net/jdk/pull/3886 From plevart at openjdk.java.net Thu May 6 16:36:50 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Thu, 6 May 2021 16:36:50 GMT Subject: RFR: 8266622: Optimize Class.descriptorString() and Class.getCanonicalName0() In-Reply-To: References: Message-ID: On Thu, 6 May 2021 15:20:23 GMT, ?????? ??????? wrote: > Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 and https://github.com/openjdk/jdk/pull/2212 it appears, that in `j.l.Class` expressions like > > String str = baseName.replace('.', '/') + '/' + name; > > are not compiled into invokedynamic-based code, but into one using `StringBuilder`. > > This happens due to some bootstraping issues. Currently the bytecode for the last (most often used) branch of `Class.descriptorString()` looks like > > public sb()Ljava/lang/String; > L0 > LINENUMBER 21 L0 > NEW java/lang/StringBuilder > DUP > INVOKESPECIAL java/lang/StringBuilder. ()V > ASTORE 1 > L1 > LINENUMBER 23 L1 > ALOAD 1 > LDC "a" > INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder; > POP > L2 > LINENUMBER 24 L2 > ALOAD 1 > LDC "b" > INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder; > POP > L3 > LINENUMBER 26 L3 > ALOAD 1 > INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String; > ARETURN > > Here the `StringBuilder` is created with default constructor and then expands if necessary while appending. > > This can be improved by manually allocating `StringBuilder` of exact size. The benchmark demonstrates measurable improvement: > > @State(Scope.Benchmark) > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class ClassDescriptorStringBenchmark { > > private final Class clazzWithShortDescriptor = Object.class; > private final Class clazzWithLongDescriptor = getClass(); > > @Benchmark > public String descriptorString_short() { > return clazzWithShortDescriptor.descriptorString(); > } > > @Benchmark > public String descriptorString_long() { > return clazzWithLongDescriptor.descriptorString(); > } > } > > > > original > -Xint > Mode Score Error Units > descriptorString_long avgt 6326.478 ? 107.251 ns/op > descriptorString_short avgt 5220.729 ? 103.545 ns/op > descriptorString_long:?gc.alloc.rate.norm avgt 528.089 ? 0.021 B/op > descriptorString_short:?gc.alloc.rate.norm avgt 232.036 ? 0.015 B/op > > -XX:TieredStopAtLevel=1 > Mode Score Error Units > descriptorString_long avgt 230.223 ? 1.254 ns/op > descriptorString_short avgt 164.255 ? 0.755 ns/op > descriptorString_long:?gc.alloc.rate.norm avgt 528.046 ? 0.002 B/op > descriptorString_short:?gc.alloc.rate.norm avgt 232.022 ? 0.001 B/op > > full > Mode Score Error Units > descriptorString_long avgt 74.835 ? 0.262 ns/op > descriptorString_short avgt 43.822 ? 0.788 ns/op > descriptorString_long:?gc.alloc.rate.norm avgt 504.010 ? 0.001 B/op > descriptorString_short:?gc.alloc.rate.norm avgt 208.004 ? 0.001 B/op > > ------------------------ > patched > -Xint > Mode Score Error Units > descriptorString_long avgt 4485.994 ? 60.173 ns/op > descriptorString_short avgt 3949.965 ? 278.143 ns/op > descriptorString_long:?gc.alloc.rate.norm avgt 336.051 ? 0.004 B/op > descriptorString_short:?gc.alloc.rate.norm avgt 184.027 ? 0.010 B/op > > -XX:TieredStopAtLevel=1 > Mode Score Error Units > descriptorString_long avgt 185.774 ? 1.100 ns/op > descriptorString_short avgt 135.338 ? 1.066 ns/op > descriptorString_long:?gc.alloc.rate.norm avgt 336.030 ? 0.001 B/op > descriptorString_short:?gc.alloc.rate.norm avgt 184.019 ? 0.001 B/op > > full > Mode Score Error Units > descriptorString_long avgt 42.864 ? 0.160 ns/op > descriptorString_short avgt 27.255 ? 0.381 ns/op > descriptorString_long:?gc.alloc.rate.norm avgt 224.005 ? 0.001 B/op > descriptorString_short:?gc.alloc.rate.norm avgt 120.002 ? 0.001 B/op > > Same can be done also for Class.isHidden() branch in Class.descriptorString() and for Class.getCanonicalName0() Hi Sergei, You are right that what javac generates is sub-optimal as it doesn't take into account the possible known final lenght of the string. So manually doing so is better. Since your 1st attempt a patch for String.join() method improved it quite a bit and is now not using StringBuilder under the hood any more. Could you try to measure the following: String str = String.join("/", baseName.replace('.', '/'), name); as an alternative to: String str = baseName.replace('.', '/') + '/' + name; and see how it compares? Regards, Peter ------------- PR: https://git.openjdk.java.net/jdk/pull/3903 From bpb at openjdk.java.net Thu May 6 16:40:31 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 6 May 2021 16:40:31 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes [v6] In-Reply-To: References: Message-ID: > Please consider this request to override the `java.io.InputStream` methods `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more performant implementations. The method overrides attempt to read all requested bytes into a single array of the required size rather than composing the result from a sequence of smaller arrays. An example of the performance improvements is as follows. > > **readAllBytes** > Before > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 2412.031 ? 7.309 ops/s > ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 212.181 ? 0.369 ops/s > ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 19.860 ? 0.048 ops/s > ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.298 ? 0.183 ops/s > > After > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 8218.473 ? 43.425 ops/s > ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 302.781 ? 1.273 ops/s > ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 22.461 ? 0.084 ops/s > ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.502 ? 0.003 ops/s > > > **readNBytes** > > `N = file_size / 2` > > Before > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 5585.500 ? 153.353 ops/s > ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 436.164 ? 1.104 ops/s > ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 40.167 ? 0.141 ops/s > ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 3.291 ? 0.211 ops/s > > > After > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 15463.210 ? 66.045 ops/s > ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 561.752 ? 0.951 ops/s > ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 45.043 ? 0.102 ops/s > ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 4.629 ? 0.035 ops/s Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8264777: Make length and position consistent with RAF; add path to OOME message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3845/files - new: https://git.openjdk.java.net/jdk/pull/3845/files/0e476822..5272d5ef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3845&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3845&range=04-05 Stats: 13 lines in 2 files changed: 7 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3845/head:pull/3845 PR: https://git.openjdk.java.net/jdk/pull/3845 From dfuchs at openjdk.java.net Thu May 6 16:42:16 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 6 May 2021 16:42:16 GMT Subject: RFR: 8266646: Add more diagnostic to java/lang/System/LoggerFinder/modules [v2] In-Reply-To: References: Message-ID: > Hi, please find here a trivial test change that adds some diagnostic (time stamps) to the LoggerFinder/modules subprocess test logs. Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: Use + Instant.now(); Instant.toString() uses the same formatter as ISO_INSTANT. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3904/files - new: https://git.openjdk.java.net/jdk/pull/3904/files/f027f8e0..3e6b436c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3904&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3904&range=00-01 Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3904.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3904/head:pull/3904 PR: https://git.openjdk.java.net/jdk/pull/3904 From dfuchs at openjdk.java.net Thu May 6 16:42:16 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 6 May 2021 16:42:16 GMT Subject: RFR: 8266646: Add more diagnostic to java/lang/System/LoggerFinder/modules In-Reply-To: References: Message-ID: On Thu, 6 May 2021 15:25:10 GMT, Daniel Fuchs wrote: > Hi, please find here a trivial test change that adds some diagnostic (time stamps) to the LoggerFinder/modules subprocess test logs. Oh - good point Naoto! Thanks for the suggestion. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/3904 From naoto at openjdk.java.net Thu May 6 16:49:53 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 6 May 2021 16:49:53 GMT Subject: RFR: 8266646: Add more diagnostic to java/lang/System/LoggerFinder/modules [v2] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 16:42:16 GMT, Daniel Fuchs wrote: >> Hi, please find here a trivial test change that adds some diagnostic (time stamps) to the LoggerFinder/modules subprocess test logs. > > Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: > > Use + Instant.now(); Instant.toString() uses the same formatter as ISO_INSTANT. Looks good. I guess you could also remove `DateTimeFormatter` import statement now. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3904 From jbhateja at openjdk.java.net Thu May 6 16:49:54 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 6 May 2021 16:49:54 GMT Subject: RFR: 8266317: Vector API enhancements In-Reply-To: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com> References: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com> Message-ID: On Thu, 29 Apr 2021 21:13:38 GMT, Paul Sandoz wrote: > This PR contains API and implementation changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Enhancements are made to the API for the support of operations on characters, such as for UTF-8 character decoding. Specifically, methods for loading/storing a `short` vector from/to a `char[]` array, and new vector comparison operators for unsigned comparisons with integral vectors. The x64 implementation is enhanced to supported unsigned comparisons. > > Enhancements are made to the API for loading/storing a `byte` vector from/to a `boolean[]` array. > > The testing of loads/stores can be expanded for scatter/gather, but before doing that i think some refactoring of the tests is required to reposition tests in the right classes. I would like to do that work after integration of the PR. Reviewed X86 backend changes for unsigned comparison. ------------- Marked as reviewed by jbhateja (Committer). PR: https://git.openjdk.java.net/jdk/pull/3803 From hchao at openjdk.java.net Thu May 6 16:55:09 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 6 May 2021 16:55:09 GMT Subject: RFR: 8266225: jarsigner is using incorrect security property to show weakness of certs Message-ID: Please review the change to jarsigner so it uses certpath security property in order to properly display the weakness of the certificate algorithms. ------------- Commit messages: - 8266225:jarsigner is using incorrect security property to show weakness of certs Changes: https://git.openjdk.java.net/jdk/pull/3905/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3905&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266225 Stats: 39 lines in 2 files changed: 31 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3905.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3905/head:pull/3905 PR: https://git.openjdk.java.net/jdk/pull/3905 From dfuchs at openjdk.java.net Thu May 6 16:57:12 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 6 May 2021 16:57:12 GMT Subject: RFR: 8266646: Add more diagnostic to java/lang/System/LoggerFinder/modules [v3] In-Reply-To: References: Message-ID: > Hi, please find here a trivial test change that adds some diagnostic (time stamps) to the LoggerFinder/modules subprocess test logs. Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: removed unused import statement ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3904/files - new: https://git.openjdk.java.net/jdk/pull/3904/files/3e6b436c..c101347a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3904&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3904&range=01-02 Stats: 4 lines in 4 files changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3904.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3904/head:pull/3904 PR: https://git.openjdk.java.net/jdk/pull/3904 From dfuchs at openjdk.java.net Thu May 6 16:57:13 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 6 May 2021 16:57:13 GMT Subject: RFR: 8266646: Add more diagnostic to java/lang/System/LoggerFinder/modules [v2] In-Reply-To: References: Message-ID: <6c-jWwdVjP5b23gRGWQRp9M4sYNKqYjXVBseyjsLekY=.262926e3-b8b9-44c1-80cb-37338c8f0dbf@github.com> On Thu, 6 May 2021 16:42:16 GMT, Daniel Fuchs wrote: >> Hi, please find here a trivial test change that adds some diagnostic (time stamps) to the LoggerFinder/modules subprocess test logs. > > Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: > > Use + Instant.now(); Instant.toString() uses the same formatter as ISO_INSTANT. Doh. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/3904 From naoto at openjdk.java.net Thu May 6 17:00:53 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 6 May 2021 17:00:53 GMT Subject: RFR: 8266646: Add more diagnostic to java/lang/System/LoggerFinder/modules [v3] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 16:57:12 GMT, Daniel Fuchs wrote: >> Hi, please find here a trivial test change that adds some diagnostic (time stamps) to the LoggerFinder/modules subprocess test logs. > > Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: > > removed unused import statement Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3904 From iris at openjdk.java.net Thu May 6 17:06:52 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 6 May 2021 17:06:52 GMT Subject: RFR: 8266646: Add more diagnostic to java/lang/System/LoggerFinder/modules [v3] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 16:57:12 GMT, Daniel Fuchs wrote: >> Hi, please find here a trivial test change that adds some diagnostic (time stamps) to the LoggerFinder/modules subprocess test logs. > > Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: > > removed unused import statement Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3904 From bpb at openjdk.java.net Thu May 6 17:12:00 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 6 May 2021 17:12:00 GMT Subject: RFR: 8266646: Add more diagnostic to java/lang/System/LoggerFinder/modules [v3] In-Reply-To: References: Message-ID: <3JN9eGH0WDPmE4gOrckL1-T4Uq9OSqGBE7Ex8IbAw-0=.8812b10b-ae30-473f-a1e8-4fc2fa2d5dfc@github.com> On Thu, 6 May 2021 16:57:12 GMT, Daniel Fuchs wrote: >> Hi, please find here a trivial test change that adds some diagnostic (time stamps) to the LoggerFinder/modules subprocess test logs. > > Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: > > removed unused import statement Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3904 From lancea at openjdk.java.net Thu May 6 17:16:51 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 6 May 2021 17:16:51 GMT Subject: RFR: 8266646: Add more diagnostic to java/lang/System/LoggerFinder/modules [v3] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 16:57:12 GMT, Daniel Fuchs wrote: >> Hi, please find here a trivial test change that adds some diagnostic (time stamps) to the LoggerFinder/modules subprocess test logs. > > Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: > > removed unused import statement Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3904 From darcy at openjdk.java.net Thu May 6 18:33:50 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 6 May 2021 18:33:50 GMT Subject: RFR: 8266578: Disambiguate BigDecimal description of scale In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 16:14:59 GMT, Ignasi Marimon-Clos wrote: > The API Docs for `BigDecimal` introduce the meaning of `scale`. The current writeup can be missleading when presenting the meaning of a `scale` value that's negative. Hopefully, with this PR, the sentence is more clear. > > The ambiguity is on this sentence: > >> If negative, the unscaled value of the number is ... > > Instead, I suggest the more verbose: > >> If the scale is negative, the unscaled value of the number is ... > > To keep symmetry, I've also reviewed the positive case from: > >> If zero or positive, the scale is the number of digits ... > > to: > >> If the scale is zero or positive, the scale is the number of digits ... Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/582 From bpb at openjdk.java.net Thu May 6 18:33:51 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 6 May 2021 18:33:51 GMT Subject: RFR: 8266578: Disambiguate BigDecimal description of scale In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 16:14:59 GMT, Ignasi Marimon-Clos wrote: > The API Docs for `BigDecimal` introduce the meaning of `scale`. The current writeup can be missleading when presenting the meaning of a `scale` value that's negative. Hopefully, with this PR, the sentence is more clear. > > The ambiguity is on this sentence: > >> If negative, the unscaled value of the number is ... > > Instead, I suggest the more verbose: > >> If the scale is negative, the unscaled value of the number is ... > > To keep symmetry, I've also reviewed the positive case from: > >> If zero or positive, the scale is the number of digits ... > > to: > >> If the scale is zero or positive, the scale is the number of digits ... Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/582 From bpb at openjdk.java.net Thu May 6 18:37:04 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 6 May 2021 18:37:04 GMT Subject: RFR: 8266578: Disambiguate BigDecimal description of scale In-Reply-To: References: <-poU2zYk5Di1PwXpSe2F8pkhKHD7rXuSVf43zDKDx0U=.e6ab5868-1f5a-462c-9e59-3f5754874980@github.com> <9gPFpTfPobzh9wUlx9Q4KAo5V7TXidqZUGqwGl-zml0=.0c80c124-dded-41e7-94d1-5073032b84fc@github.com> Message-ID: On Thu, 6 May 2021 11:52:09 GMT, Ignasi Marimon-Clos wrote: >> @ignasi35 I have created JDK-8266578. Please change the name of this PR to: >> >> `8266578: Disambiguate BigDecimal description of scale` >> >> Please resolve any conflicts and commit the updated file. Once the update is available, I will file a CSR and mark this PR accordingly. > > Thanks @bplb for doing the heavy lifting. I've updated the PR title and solved the conflict. @ignasi35 This PR has been approved, so once you have issued the [integrate](https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/integrate) command I can sponsor it. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/582 From vromero at openjdk.java.net Thu May 6 19:06:41 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 6 May 2021 19:06:41 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v7] In-Reply-To: References: Message-ID: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. Vicente Romero 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 11 additional commits since the last revision: - Merge branch 'master' into JDK-8260517 - restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - updating comment after review feedback - removing javax.lang.model changes - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - fixing failing regression tests - JVM related changes - ... and 1 more: https://git.openjdk.java.net/jdk/compare/10336a26...0208dcf0 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3526/files - new: https://git.openjdk.java.net/jdk/pull/3526/files/304fd76a..0208dcf0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=05-06 Stats: 18908 lines in 391 files changed: 9887 ins; 4814 del; 4207 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From minqi at openjdk.java.net Thu May 6 19:51:20 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 6 May 2021 19:51:20 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v4] In-Reply-To: References: Message-ID: > Hi, Please review > When using jcmd to dump shared archive, if the archive name exists, it will be deleted first. If exception happens during dumping process, there is no new archive created. This PR changes to first dump the archive with a temporary file name. With successful dump, the temporary file will be rename to its given name. This way the old archive will not be touched on exception. > The newly added test case skipped testing on Windows since File operation result is not same as on Linux. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Removed using temporary file in test case ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3886/files - new: https://git.openjdk.java.net/jdk/pull/3886/files/83478dd1..e3363915 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3886&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3886&range=02-03 Stats: 17 lines in 1 file changed: 2 ins; 10 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3886.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3886/head:pull/3886 PR: https://git.openjdk.java.net/jdk/pull/3886 From minqi at openjdk.java.net Thu May 6 21:37:35 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 6 May 2021 21:37:35 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v5] In-Reply-To: References: Message-ID: > Hi, Please review > When using jcmd to dump shared archive, if the archive name exists, it will be deleted first. If exception happens during dumping process, there is no new archive created. This PR changes to first dump the archive with a temporary file name. With successful dump, the temporary file will be rename to its given name. This way the old archive will not be touched on exception. > The newly added test case skipped testing on Windows since File operation result is not same as on Linux. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Remove tab space ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3886/files - new: https://git.openjdk.java.net/jdk/pull/3886/files/e3363915..ab43e478 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3886&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3886&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3886.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3886/head:pull/3886 PR: https://git.openjdk.java.net/jdk/pull/3886 From iklam at openjdk.java.net Thu May 6 22:02:52 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 6 May 2021 22:02:52 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v5] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 21:37:35 GMT, Yumin Qi wrote: >> Hi, Please review >> When using jcmd to dump shared archive, if the archive name exists, it will be deleted first. If exception happens during dumping process, there is no new archive created. This PR changes to first dump the archive with a temporary file name. With successful dump, the temporary file will be rename to its given name. This way the old archive will not be touched on exception. >> The newly added test case skipped testing on Windows since File operation result is not same as on Linux. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Remove tab space The latest version LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3886 From mark.reinhold at oracle.com Thu May 6 22:37:07 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 6 May 2021 15:37:07 -0700 (PDT) Subject: New candidate JEP: 415: Context-Specific Deserialization Filters Message-ID: <20210506223707.46CC23E2F2C@eggemoggin.niobe.net> https://openjdk.java.net/jeps/415 Summary: Allow applications to configure context-specific and dynamically-selected deserialization filters via a JVM-wide filter factory that is invoked to select a filter for each individual deserialization operation. - Mark From scolebourne at joda.org Thu May 6 23:27:41 2021 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 7 May 2021 00:27:41 +0100 Subject: Proposal for new interface: TimeSource Message-ID: This is a proposal to add a new interface to java.time.* public interface TimeSource { public static TimeSource system() { ... } public abstract Instant instant(); public default long millis() { return instant().toEpochMilli(); } public default Clock withZone(ZoneId zoneId) { return Clock.of(this, zoneId); } } The existing `Clock` abstract class would be altered to implement the interface. A new static method `Clock.of(TimeSource, ZoneId)` would be added. No changes are needed to any other part of the API. (Could add `Instant.now(TimeSource)`, but it isn't entirely necessary) Callers would pass around and use `TimeSource` directly, for example by dependency injection. Why add this interface? I've seen various indications that there is a desire for an interface representing a supplier of `Instant`. Specifically this desire is driven by the "unnecessary" time zone that `java.time.Clock` contains. Put simply, if the only thing you want is an `Instant`, then `Clock` isn't the right API because it forces you to think about time zones. A key thing that this interface allows is the separation of the OS Clock from the time-zone (which should generally be linked to user localization). A good architecture would pass `TimeSource` around the system and combine it with a time-zone held in a `UserContext` to get a `Clock`. The current design of java.time.* does not enable that because the `TimeSource` concept does not exist. Developers either have to write their own interface, or use `Clock` and ignore the time zone. A `Supplier` obviously performs similar functionality, but it lacks discoverability and understandability. Plus, injecting generified interfaces tends to be painful. Downsides? None really, other than a new type in the JDK that probably should have been in Java 8. See this ThreeTen-Extra discussion - https://github.com/ThreeTen/threeten-extra/issues/150 Joda-Time has a `MillisProvider` that is similar: - https://www.joda.org/joda-time/apidocs/org/joda/time/DateTimeUtils.MillisProvider.html Time4J has a `TimeSource`: - https://github.com/MenoData/Time4J/blob/master/base/src/main/java/net/time4j/base/TimeSource.java Spring has a `DateTimeContext` that separates the user localization as per the `UserContext` described above: - https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/format/datetime/standard/DateTimeContext.html There is a similar concept `TimeSource` in `sun.net.httpserver` There may be a case to name the interface `InstantSource`, however `TimeSource` is a fairly widely understood name for this concept. There is the potential to extend the interface with something similar to Kotlin's `TimeMark` that would allow access to the monotonic clock, suitable for measurement of durations without any leap second effects: - https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.time/-time-mark/ Feedback? Stephen From minqi at openjdk.java.net Fri May 7 00:07:11 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 7 May 2021 00:07:11 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v5] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 23:59:21 GMT, Calvin Cheung wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove tab space > > test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java line 78: > >> 76: print2ln(test_count++ + " Set target dir not writable, do dynamic dump"); >> 77: setKeepArchive(true); >> 78: outputDirFile.setWritable(true); > > Should the comment be `// Set target dir writable ...` ? (since you're setting the dir to writable at line 78) The comment is for the testing item --- that is consistent with println contents. The first set 'true' is for get the archive and keep the archive, the real test is after set it to 'false', the test will fail and we check the previous archive still available. > test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java line 89: > >> 87: outputDirFile.setWritable(false); >> 88: test(localFileName, pid, noBoot, EXPECT_FAIL); >> 89: outputDirFile.setWritable(true); > > Would the test fail without setting the dir not writable at line 87? See reply above. ------------- PR: https://git.openjdk.java.net/jdk/pull/3886 From ccheung at openjdk.java.net Fri May 7 00:07:09 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 7 May 2021 00:07:09 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v5] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 21:37:35 GMT, Yumin Qi wrote: >> Hi, Please review >> When using jcmd to dump shared archive, if the archive name exists, it will be deleted first. If exception happens during dumping process, there is no new archive created. This PR changes to first dump the archive with a temporary file name. With successful dump, the temporary file will be rename to its given name. This way the old archive will not be touched on exception. >> The newly added test case skipped testing on Windows since File operation result is not same as on Linux. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Remove tab space I have 2 questions on the test. test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java line 78: > 76: print2ln(test_count++ + " Set target dir not writable, do dynamic dump"); > 77: setKeepArchive(true); > 78: outputDirFile.setWritable(true); Should the comment be `// Set target dir writable ...` ? (since you're setting the dir to writable at line 78) test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java line 89: > 87: outputDirFile.setWritable(false); > 88: test(localFileName, pid, noBoot, EXPECT_FAIL); > 89: outputDirFile.setWritable(true); Would the test fail without setting the dir not writable at line 87? ------------- PR: https://git.openjdk.java.net/jdk/pull/3886 From ccheung at openjdk.java.net Fri May 7 00:12:09 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 7 May 2021 00:12:09 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v5] In-Reply-To: References: Message-ID: On Fri, 7 May 2021 00:02:56 GMT, Yumin Qi wrote: >> test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java line 78: >> >>> 76: print2ln(test_count++ + " Set target dir not writable, do dynamic dump"); >>> 77: setKeepArchive(true); >>> 78: outputDirFile.setWritable(true); >> >> Should the comment be `// Set target dir writable ...` ? (since you're setting the dir to writable at line 78) > > The comment is for the testing item --- that is consistent with println contents. > The first set 'true' is for get the archive and keep the archive, the real test is after set it to 'false', the test will fail and we check the previous archive still available. I see. ------------- PR: https://git.openjdk.java.net/jdk/pull/3886 From ccheung at openjdk.java.net Fri May 7 00:12:09 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 7 May 2021 00:12:09 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v5] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 21:37:35 GMT, Yumin Qi wrote: >> Hi, Please review >> When using jcmd to dump shared archive, if the archive name exists, it will be deleted first. If exception happens during dumping process, there is no new archive created. This PR changes to first dump the archive with a temporary file name. With successful dump, the temporary file will be rename to its given name. This way the old archive will not be touched on exception. >> The newly added test case skipped testing on Windows since File operation result is not same as on Linux. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Remove tab space Marked as reviewed by ccheung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3886 From minqi at openjdk.java.net Fri May 7 00:15:17 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 7 May 2021 00:15:17 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v5] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 21:59:32 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove tab space > > The latest version LGTM @iklam @calvinccheung Thanks for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3886 From almatvee at openjdk.java.net Fri May 7 02:57:05 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 7 May 2021 02:57:05 GMT Subject: RFR: 8266456: Replace direct TKit.run() calls with jdk.jpackage.test.Annotations.Test annotation Message-ID: - Replaced direct TKit.run() calls with Test annotation. - Increased timeout for SigningPackageTest from default to 360 due to timeout. This is regression from JDK-8248904 due to changes done in signing and --remove-signature adds additional time since it is run per file. - Fixed issue with jtreg.SkippedException which caused test to fail instead of being skipped, since it was wrapped in ExceptionBox. ------------- Commit messages: - 8266456: Replace direct TKit.run() calls with jdk.jpackage.test.Annotations.Test annotation Changes: https://git.openjdk.java.net/jdk/pull/3911/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3911&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266456 Stats: 214 lines in 12 files changed: 23 ins; 16 del; 175 mod Patch: https://git.openjdk.java.net/jdk/pull/3911.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3911/head:pull/3911 PR: https://git.openjdk.java.net/jdk/pull/3911 From jzaugg at openjdk.java.net Fri May 7 03:10:32 2021 From: jzaugg at openjdk.java.net (Jason Zaugg) Date: Fri, 7 May 2021 03:10:32 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v5] In-Reply-To: References: Message-ID: > If the given Path represents a file, use the overload of read defined > in FileChannel that accepts an explicit position and avoid serializing > reads. > > Note: The underlying NIO implementation is not required to implement > FileChannel.read(ByteBuffer, long) concurrently; Windows still appears > to lock, as it returns true for NativeDispatcher.needsPositionLock. > > > On MacOS X, the enclosed benchmark improves from: > > > Benchmark Mode Cnt Score Error Units > ZipFileSystemBenchmark.read avgt 10 75.311 ? 3.301 ms/op > > > To: > > > Benchmark Mode Cnt Score Error Units > ZipFileSystemBenchmark.read avgt 10 12.520 ? 0.875 ms/op Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: [zipfs] Add missing check-failed exception to position/read test This appears to have been omitted when this test was added. To avoid false error reports, the condition must deal with the edge case of zero-length entries, for which read will return -1. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3853/files - new: https://git.openjdk.java.net/jdk/pull/3853/files/c9758c58..9106096e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3853&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3853&range=03-04 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3853/head:pull/3853 PR: https://git.openjdk.java.net/jdk/pull/3853 From jzaugg at openjdk.java.net Fri May 7 03:18:12 2021 From: jzaugg at openjdk.java.net (Jason Zaugg) Date: Fri, 7 May 2021 03:18:12 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v4] In-Reply-To: <2yiP6HEx1W_6XobXJxeo_NuQjFROQpRVZZp8_RP1jrE=.9aa6c044-442e-4435-83b3-bd3f68c3c043@github.com> References: <2yiP6HEx1W_6XobXJxeo_NuQjFROQpRVZZp8_RP1jrE=.9aa6c044-442e-4435-83b3-bd3f68c3c043@github.com> Message-ID: On Thu, 6 May 2021 08:05:12 GMT, Jason Zaugg wrote: >> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1235: >> >>> 1233: synchronized(ch) { >>> 1234: return ch.position(pos).read(bb); >>> 1235: } >> >> I think it's okay to include the update to EntryInputStream, that part looks fine, as does the directly use of the FileChannel positional read. >> >> I'm still mulling over the case where ch is not a FileChannel as I would expected it to capture the existing position and restore it after the read. I think this is the degenerative case when the zip file is located in a custom file system that doesn't support FileChannel. In that case, positional read has to be implemented on the most basic SeekableByteChannel. It would only be observed when mixing positional read ops with other ops that depend on the current position. > > Here are all the references to `ch`. > > > this.ch = Files.newByteChannel(zfpath, READ); > ... > this.ch.close(); > ... > ch.close(); // close the ch just in case no update > ... > if (ch instanceof FileChannel fch) { > return fch.read(bb, pos); > } else { > synchronized(ch) { > return ch.position(pos).read(bb); > } > } > ... > long ziplen = ch.size(); > ... > ch.close(); > > > It appears the only position-dependent operation called `read(ByteBuffer)`. This is performed together with the `pos` call within the `synchronized(ch)` lock. I have confirmed that the non-`FileChannel` code path is exercised by existing tests. test/jdk/jdk/nio/zipfs/ZipFSTester.java includes a test that forms a file system based on a JAR that is itself an entry within another `ZipFileSystem`. Sample stacks: java.lang.Throwable: readFullyAt. ch.getClass=class jdk.nio.zipfs.ByteArrayChannel at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.readFullyAt(ZipFileSystem.java:1234) at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.readFullyAt(ZipFileSystem.java:1226) at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$EntryInputStream.initDataPos(ZipFileSystem.java:2259) at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$EntryInputStream.read(ZipFileSystem.java:2201) at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$2.fill(ZipFileSystem.java:2151) at java.base/java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158) at ZipFSTester.checkEqual(ZipFSTester.java:858) at ZipFSTester.test1(ZipFSTester.java:259) java.lang.Throwable: readFullyAt. ch.getClass=class jdk.nio.zipfs.ByteArrayChannel at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.readFullyAt(ZipFileSystem.java:1234) at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$EntryInputStream.read(ZipFileSystem.java:2214) at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$2.fill(ZipFileSystem.java:2151) at java.base/java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158) at ZipFSTester.checkEqual(ZipFSTester.java:858) at ZipFSTester.test1(ZipFSTester.java:259) This use case is not covered by the `ZipFSTester.test2`, a multi-threaded test. While looking at the test I noticed false warnings in the output: `read()/position() failed`. This did not actually fail the test. I investigated this and a) fixed the condition to deal with the edge case of zero-length entries and b) throw an "check failed" exception when the assertion fails. ------------- PR: https://git.openjdk.java.net/jdk/pull/3853 From vtewari at openjdk.java.net Fri May 7 06:24:13 2021 From: vtewari at openjdk.java.net (Vyom Tewari) Date: Fri, 7 May 2021 06:24:13 GMT Subject: RFR: 8266610: Method RandomAccessFile#length() returns 0 for block devices on linux. Message-ID: RandomAccessFile.length() method for block device return always 0 ------------- Commit messages: - JDK-8266610: Method RandomAccessFile#length() returns 0 for block devices on linux. Changes: https://git.openjdk.java.net/jdk/pull/3914/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3914&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266610 Stats: 13 lines in 1 file changed: 10 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3914.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3914/head:pull/3914 PR: https://git.openjdk.java.net/jdk/pull/3914 From github.com+10835776+stsypanov at openjdk.java.net Fri May 7 06:27:56 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 7 May 2021 06:27:56 GMT Subject: RFR: 8266622: Optimize Class.descriptorString() and Class.getCanonicalName0() In-Reply-To: References: Message-ID: On Thu, 6 May 2021 16:34:04 GMT, Peter Levart wrote: >> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 and https://github.com/openjdk/jdk/pull/2212 it appears, that in `j.l.Class` expressions like >> >> String str = baseName.replace('.', '/') + '/' + name; >> >> are not compiled into invokedynamic-based code, but into one using `StringBuilder`. >> >> This happens due to some bootstraping issues. Currently the bytecode for the last (most often used) branch of `Class.descriptorString()` looks like >> >> public sb()Ljava/lang/String; >> L0 >> LINENUMBER 21 L0 >> NEW java/lang/StringBuilder >> DUP >> INVOKESPECIAL java/lang/StringBuilder. ()V >> ASTORE 1 >> L1 >> LINENUMBER 23 L1 >> ALOAD 1 >> LDC "a" >> INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder; >> POP >> L2 >> LINENUMBER 24 L2 >> ALOAD 1 >> LDC "b" >> INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder; >> POP >> L3 >> LINENUMBER 26 L3 >> ALOAD 1 >> INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String; >> ARETURN >> >> Here the `StringBuilder` is created with default constructor and then expands if necessary while appending. >> >> This can be improved by manually allocating `StringBuilder` of exact size. The benchmark demonstrates measurable improvement: >> >> @State(Scope.Benchmark) >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> public class ClassDescriptorStringBenchmark { >> >> private final Class clazzWithShortDescriptor = Object.class; >> private final Class clazzWithLongDescriptor = getClass(); >> >> @Benchmark >> public String descriptorString_short() { >> return clazzWithShortDescriptor.descriptorString(); >> } >> >> @Benchmark >> public String descriptorString_long() { >> return clazzWithLongDescriptor.descriptorString(); >> } >> } >> >> >> >> original >> -Xint >> Mode Score Error Units >> descriptorString_long avgt 6326.478 ? 107.251 ns/op >> descriptorString_short avgt 5220.729 ? 103.545 ns/op >> descriptorString_long:?gc.alloc.rate.norm avgt 528.089 ? 0.021 B/op >> descriptorString_short:?gc.alloc.rate.norm avgt 232.036 ? 0.015 B/op >> >> -XX:TieredStopAtLevel=1 >> Mode Score Error Units >> descriptorString_long avgt 230.223 ? 1.254 ns/op >> descriptorString_short avgt 164.255 ? 0.755 ns/op >> descriptorString_long:?gc.alloc.rate.norm avgt 528.046 ? 0.002 B/op >> descriptorString_short:?gc.alloc.rate.norm avgt 232.022 ? 0.001 B/op >> >> full >> Mode Score Error Units >> descriptorString_long avgt 74.835 ? 0.262 ns/op >> descriptorString_short avgt 43.822 ? 0.788 ns/op >> descriptorString_long:?gc.alloc.rate.norm avgt 504.010 ? 0.001 B/op >> descriptorString_short:?gc.alloc.rate.norm avgt 208.004 ? 0.001 B/op >> >> ------------------------ >> patched >> -Xint >> Mode Score Error Units >> descriptorString_long avgt 4485.994 ? 60.173 ns/op >> descriptorString_short avgt 3949.965 ? 278.143 ns/op >> descriptorString_long:?gc.alloc.rate.norm avgt 336.051 ? 0.004 B/op >> descriptorString_short:?gc.alloc.rate.norm avgt 184.027 ? 0.010 B/op >> >> -XX:TieredStopAtLevel=1 >> Mode Score Error Units >> descriptorString_long avgt 185.774 ? 1.100 ns/op >> descriptorString_short avgt 135.338 ? 1.066 ns/op >> descriptorString_long:?gc.alloc.rate.norm avgt 336.030 ? 0.001 B/op >> descriptorString_short:?gc.alloc.rate.norm avgt 184.019 ? 0.001 B/op >> >> full >> Mode Score Error Units >> descriptorString_long avgt 42.864 ? 0.160 ns/op >> descriptorString_short avgt 27.255 ? 0.381 ns/op >> descriptorString_long:?gc.alloc.rate.norm avgt 224.005 ? 0.001 B/op >> descriptorString_short:?gc.alloc.rate.norm avgt 120.002 ? 0.001 B/op >> >> Same can be done also for Class.isHidden() branch in Class.descriptorString() and for Class.getCanonicalName0() > > Hi Sergei, > You are right that what javac generates is sub-optimal as it doesn't take into account the possible known final lenght of the string. So manually doing so is better. Since your 1st attempt a patch for String.join() method improved it quite a bit and is now not using StringBuilder under the hood any more. Could you try to measure for example the following: > > > String str = String.join("/", baseName.replace('.', '/'), name); > > as an alternative to: > > String str = baseName.replace('.', '/') + '/' + name; > > > or for example: > > > return String.join( > "", // delimiter > "L", name.substring(0, index).replace('.', '/'), > ".", name.substring(index+1), ";"); > > as an alternative for: > > return "L" + name.substring(0, index).replace('.', '/') > + "." + name.substring(index+1) + ";"; > > and see how it compares? > > Regards, Peter @plevart hi, to my surprise `String.join()` makes it worse: Mode Cnt Score Error Units descriptorString_long avgt 50 77.644 ? 0.846 ns/op descriptorString_short avgt 50 61.591 ? 2.044 ns/op descriptorString_long:?gc.alloc.rate.norm avgt 50 288.006 ? 0.001 B/op descriptorString_short:?gc.alloc.rate.norm avgt 50 184.004 ? 0.001 B/op ------------- PR: https://git.openjdk.java.net/jdk/pull/3903 From aph at openjdk.java.net Fri May 7 08:23:53 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 7 May 2021 08:23:53 GMT Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64. In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 20:24:25 GMT, Carlos O'Donell wrote: > Where does the requirement for monotonicity come from? Semi-monotonicity, to be precise. In the spec of java.lang.Math, "Besides accuracy at individual arguments, maintaining proper relations between the method at different arguments is also important. Therefore, most methods with more than 0.5 ulp errors are required to be semi-monotonic: whenever the mathematical function is non-decreasing, so is the floating-point approximation, likewise, whenever the mathematical function is non-increasing, so is the floating-point approximation. Not all approximations that have 1 ulp accuracy will automatically meet the monotonicity requirements." I wouldn't be surprised if the approximations we need in glibc meet this anyway. We just need to check. ------------- PR: https://git.openjdk.java.net/jdk/pull/3510 From kbarrett at openjdk.java.net Fri May 7 08:28:44 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 7 May 2021 08:28:44 GMT Subject: RFR: 8254598: StringDedupTable should use OopStorage In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 19:48:47 GMT, Kim Barrett wrote: > Please review this change to the String Deduplication facility. It is being > changed to use OopStorage to hold weak references to relevant objects, > rather than bespoke data structures requiring dedicated processing phases by > supporting GCs. > > (The Shenandoah update was contributed by Zhengyu Gu.) > > This change significantly simplifies the interface between a given GC and > the String Deduplication facility, which should make it much easier for > other GCs to opt in. However, this change does not alter the set of GCs > providing support; currently only G1 and Shenandoah support string > deduplication. Adding support by other GCs will be in followup RFEs. > > Reviewing via the diffs might not be all that useful for some parts, as > several files have been essentially completely replaced, and a number of > files have been added or eliminated. The full webrev might be a better > place to look. > > The major changes are in gc/shared/stringdedup/* and in the supporting > collectors, but there are also some smaller changes in other places, most > notably classfile/{stringTable,javaClasses}. > > This change is additionally labeled for review by core-libs, although there > are no source changes there. This change injects a byte field of bits into > java.lang.String, using one of the previously unused padding bytes in that > class. (There were two unused bytes, now only one.) > > Testing: > mach5 tier1-2 with and without -XX:+UseStringDeduplication > > Locally (linux-x64) ran all of the existing tests that use string > deduplication with both G1 and Shenandoah. Note that > TestStringDeduplicationInterned.java is disabled for shenandoah, as it > currently fails, for reasons I haven't figured out but suspect are test > related. > > - gc/stringdedup/ -- these used to be in gc/g1 > - runtime/cds/SharedStringsDedup.java > - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java > - runtime/cds/appcds/sharedStrings/* > > shenandoah-only: > - gc/shenandoah/jvmti/TestHeapDump.java > - gc/shenandoah/TestStringDedup.java > - gc/shenandoah/TestStringDedupStress.java > > Performance tested baseline, baseline + stringdedup, new with stringdedup, > finding no significant differences. I've made some improvements to comments, responding to Thomas's suggestions. Ive also changed some of the naming around the injected java.lang.String flags, with modification now using test-and-set semantics (and named accordingly), i.e. returning true if already set rather than if changed. I've not yet dealt with the merge conflict in Shenandoah, but it looks like it should be fairly easy. Just waiting for more comments before dealing with merging updates. ------------- PR: https://git.openjdk.java.net/jdk/pull/3662 From kbarrett at openjdk.java.net Fri May 7 08:28:43 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 7 May 2021 08:28:43 GMT Subject: RFR: 8254598: StringDedupTable should use OopStorage [v2] In-Reply-To: References: Message-ID: > Please review this change to the String Deduplication facility. It is being > changed to use OopStorage to hold weak references to relevant objects, > rather than bespoke data structures requiring dedicated processing phases by > supporting GCs. > > (The Shenandoah update was contributed by Zhengyu Gu.) > > This change significantly simplifies the interface between a given GC and > the String Deduplication facility, which should make it much easier for > other GCs to opt in. However, this change does not alter the set of GCs > providing support; currently only G1 and Shenandoah support string > deduplication. Adding support by other GCs will be in followup RFEs. > > Reviewing via the diffs might not be all that useful for some parts, as > several files have been essentially completely replaced, and a number of > files have been added or eliminated. The full webrev might be a better > place to look. > > The major changes are in gc/shared/stringdedup/* and in the supporting > collectors, but there are also some smaller changes in other places, most > notably classfile/{stringTable,javaClasses}. > > This change is additionally labeled for review by core-libs, although there > are no source changes there. This change injects a byte field of bits into > java.lang.String, using one of the previously unused padding bytes in that > class. (There were two unused bytes, now only one.) > > Testing: > mach5 tier1-2 with and without -XX:+UseStringDeduplication > > Locally (linux-x64) ran all of the existing tests that use string > deduplication with both G1 and Shenandoah. Note that > TestStringDeduplicationInterned.java is disabled for shenandoah, as it > currently fails, for reasons I haven't figured out but suspect are test > related. > > - gc/stringdedup/ -- these used to be in gc/g1 > - runtime/cds/SharedStringsDedup.java > - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java > - runtime/cds/appcds/sharedStrings/* > > shenandoah-only: > - gc/shenandoah/jvmti/TestHeapDump.java > - gc/shenandoah/TestStringDedup.java > - gc/shenandoah/TestStringDedupStress.java > > Performance tested baseline, baseline + stringdedup, new with stringdedup, > finding no significant differences. Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: - more comment improvements - improve naming and comments around injected String flags - fix some typos in comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3662/files - new: https://git.openjdk.java.net/jdk/pull/3662/files/2df362cb..656e2426 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3662&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3662&range=00-01 Stats: 70 lines in 8 files changed: 8 ins; 2 del; 60 mod Patch: https://git.openjdk.java.net/jdk/pull/3662.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3662/head:pull/3662 PR: https://git.openjdk.java.net/jdk/pull/3662 From kbarrett at openjdk.java.net Fri May 7 08:28:47 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 7 May 2021 08:28:47 GMT Subject: RFR: 8254598: StringDedupTable should use OopStorage [v2] In-Reply-To: <6ZAMFTRy3EAApWJryDwCZNHc0P8tF6flss2e4TRVs00=.7f365a2f-ae15-4163-b9ee-b57e188f686f@github.com> References: <6ZAMFTRy3EAApWJryDwCZNHc0P8tF6flss2e4TRVs00=.7f365a2f-ae15-4163-b9ee-b57e188f686f@github.com> Message-ID: <9jVZLn0ARJw8ZQH6zIyly1AVN9RF9HdQn8hvpDMqMLg=.dfd10f63-e445-44f9-a599-6c627404c64e@github.com> On Tue, 4 May 2021 11:47:25 GMT, Thomas Schatzl wrote: >> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: >> >> - more comment improvements >> - improve naming and comments around injected String flags >> - fix some typos in comments > > src/hotspot/share/classfile/javaClasses.hpp line 171: > >> 169: static inline bool is_latin1(oop java_string); >> 170: static inline bool no_deduplication(oop java_string); >> 171: static inline bool deduplication_requested(oop java_string); > > Having a verb at the beginning like `is_deduplication_requested` sounds better. "is_deduplication_requested" suggests there is currently a request, but this flag remains true even after the request is processed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3662 From kbarrett at openjdk.java.net Fri May 7 08:30:55 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 7 May 2021 08:30:55 GMT Subject: RFR: 8254598: StringDedupTable should use OopStorage [v2] In-Reply-To: <6ZAMFTRy3EAApWJryDwCZNHc0P8tF6flss2e4TRVs00=.7f365a2f-ae15-4163-b9ee-b57e188f686f@github.com> References: <6ZAMFTRy3EAApWJryDwCZNHc0P8tF6flss2e4TRVs00=.7f365a2f-ae15-4163-b9ee-b57e188f686f@github.com> Message-ID: On Tue, 4 May 2021 11:46:21 GMT, Thomas Schatzl wrote: >> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: >> >> - more comment improvements >> - improve naming and comments around injected String flags >> - fix some typos in comments > > src/hotspot/share/classfile/javaClasses.hpp line 170: > >> 168: static inline bool hash_is_set(oop string); >> 169: static inline bool is_latin1(oop java_string); >> 170: static inline bool no_deduplication(oop java_string); > > That identifier is missing a verb to read better, but I do not have a good idea. Maybe it would be easier to use the negation of "no_deduplication", something like "may_deduplicate"? > Feel free to ignore. "may_deduplicate" would require internally flipping the sense, to account for the initial value being false because of zero-initialization. I've changed it to "deduplication_forbidden"; hopefully that helps. ------------- PR: https://git.openjdk.java.net/jdk/pull/3662 From alanb at openjdk.java.net Fri May 7 10:07:56 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 7 May 2021 10:07:56 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v12] In-Reply-To: <8JEQ3a0tEdpDPGWsHEDFpvegIsnUtoGBQwIga55kVYY=.ac069eb8-fa51-4a13-8349-d655d19eab10@github.com> References: <8JEQ3a0tEdpDPGWsHEDFpvegIsnUtoGBQwIga55kVYY=.ac069eb8-fa51-4a13-8349-d655d19eab10@github.com> Message-ID: On Thu, 6 May 2021 14:23:27 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://openjdk.java.net/jeps/412 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Replace uses of -Djdk.foreign.restricted (useless now) with --enable-native-access src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/package-info.java line 72: > 70: * > 71: * 
{@code
> 72: try (ResourceScope scope = ResourceScope.ofConfined()) {

The example might be out of date, I assume this should be newConfinedScope.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Fri May  7 11:18:21 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 7 May 2021 11:18:21 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v13]
In-Reply-To: 
References: 
Message-ID: 

> 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://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix issue in snippet in package-info

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/926229ed..1ce6366a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From vtewari at openjdk.java.net  Fri May  7 12:17:11 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Fri, 7 May 2021 12:17:11 GMT
Subject: RFR: 8266610: Method RandomAccessFile#length() returns 0 for
 block devices on linux. [v2]
In-Reply-To: 
References: 
Message-ID: 

> RandomAccessFile.length() method for block device return always 0

Vyom Tewari has updated the pull request incrementally with one additional commit since the last revision:

  fixed assigning -1 to uint64_t

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3914/files
  - new: https://git.openjdk.java.net/jdk/pull/3914/files/8f348ef9..72beb715

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3914&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3914&range=00-01

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3914.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3914/head:pull/3914

PR: https://git.openjdk.java.net/jdk/pull/3914

From dfuchs at openjdk.java.net  Fri May  7 12:59:52 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 7 May 2021 12:59:52 GMT
Subject: Integrated: 8266646: Add more diagnostic to
 java/lang/System/LoggerFinder/modules
In-Reply-To: 
References: 
Message-ID: 

On Thu, 6 May 2021 15:25:10 GMT, Daniel Fuchs  wrote:

> Hi, please find here a trivial test change that adds some diagnostic (time stamps) to the LoggerFinder/modules subprocess test logs.

This pull request has now been integrated.

Changeset: 3fcdc50e
Author:    Daniel Fuchs 
URL:       https://git.openjdk.java.net/jdk/commit/3fcdc50e4425b10181a2a3d82718994597dc8364
Stats:     34 lines in 4 files changed: 23 ins; 2 del; 9 mod

8266646: Add more diagnostic to java/lang/System/LoggerFinder/modules

Reviewed-by: naoto, iris, bpb, lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/3904

From alanb at openjdk.java.net  Fri May  7 14:11:56 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 7 May 2021 14:11:56 GMT
Subject: RFR: 8266610: Method RandomAccessFile#length() returns 0 for
 block devices on linux. [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 May 2021 12:17:11 GMT, Vyom Tewari  wrote:

>> RandomAccessFile.length() method for block device return always 0
>
> Vyom Tewari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed assigning -1 to uint64_t

I think this look okay, and consistent with the file dispatcher implementation.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3914

From plevart at openjdk.java.net  Fri May  7 14:50:02 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 7 May 2021 14:50:02 GMT
Subject: RFR: 8266622: Optimize Class.descriptorString() and
 Class.getCanonicalName0()
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 6 May 2021 16:34:04 GMT, Peter Levart  wrote:

>> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 and https://github.com/openjdk/jdk/pull/2212 it appears, that in `j.l.Class` expressions like
>> 
>> String str = baseName.replace('.', '/') + '/' + name;
>> 
>> are not compiled into invokedynamic-based code, but into one using `StringBuilder`.
>> 
>> This happens due to some bootstraping issues. Currently the bytecode for the last (most often used) branch of `Class.descriptorString()` looks like
>> 
>> public sb()Ljava/lang/String;
>>    L0
>>     LINENUMBER 21 L0
>>     NEW java/lang/StringBuilder
>>     DUP
>>     INVOKESPECIAL java/lang/StringBuilder. ()V
>>     ASTORE 1
>>    L1
>>     LINENUMBER 23 L1
>>     ALOAD 1
>>     LDC "a"
>>     INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
>>     POP
>>    L2
>>     LINENUMBER 24 L2
>>     ALOAD 1
>>     LDC "b"
>>     INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
>>     POP
>>    L3
>>     LINENUMBER 26 L3
>>     ALOAD 1
>>     INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String;
>>     ARETURN
>> 
>> Here the `StringBuilder` is created with default constructor and then expands if necessary while appending. 
>> 
>> This can be improved by manually allocating `StringBuilder` of exact size. The benchmark demonstrates measurable improvement:
>> 
>> @State(Scope.Benchmark)
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
>> public class ClassDescriptorStringBenchmark {
>> 
>>     private final Class clazzWithShortDescriptor = Object.class;
>>     private final Class clazzWithLongDescriptor = getClass();
>> 
>>     @Benchmark
>>     public String descriptorString_short() {
>>         return clazzWithShortDescriptor.descriptorString();
>>     }
>> 
>>     @Benchmark
>>     public String descriptorString_long() {
>>         return clazzWithLongDescriptor.descriptorString();
>>     }
>> }
>> 
>> 
>> 
>> original
>> -Xint
>>                                                Mode     Score     Error   Units
>> descriptorString_long                          avgt  6326.478 ? 107.251   ns/op
>> descriptorString_short                         avgt  5220.729 ? 103.545   ns/op
>> descriptorString_long:?gc.alloc.rate.norm      avgt   528.089 ?   0.021    B/op
>> descriptorString_short:?gc.alloc.rate.norm     avgt   232.036 ?   0.015    B/op
>> 
>> -XX:TieredStopAtLevel=1
>>                                                Mode      Score    Error   Units
>> descriptorString_long                          avgt    230.223 ?  1.254   ns/op
>> descriptorString_short                         avgt    164.255 ?  0.755   ns/op
>> descriptorString_long:?gc.alloc.rate.norm      avgt    528.046 ?  0.002    B/op
>> descriptorString_short:?gc.alloc.rate.norm     avgt    232.022 ?  0.001    B/op
>> 
>> full
>>                                                Mode      Score     Error   Units
>> descriptorString_long                          avgt     74.835 ?   0.262   ns/op
>> descriptorString_short                         avgt     43.822 ?   0.788   ns/op
>> descriptorString_long:?gc.alloc.rate.norm      avgt    504.010 ?   0.001    B/op
>> descriptorString_short:?gc.alloc.rate.norm     avgt    208.004 ?   0.001    B/op
>> 
>> ------------------------
>> patched
>> -Xint
>>                                                Mode      Score     Error   Units
>> descriptorString_long                          avgt   4485.994 ?  60.173   ns/op
>> descriptorString_short                         avgt   3949.965 ? 278.143   ns/op
>> descriptorString_long:?gc.alloc.rate.norm      avgt    336.051 ?   0.004    B/op
>> descriptorString_short:?gc.alloc.rate.norm     avgt    184.027 ?   0.010    B/op
>> 
>> -XX:TieredStopAtLevel=1
>>                                                Mode        Score    Error   Units
>> descriptorString_long                          avgt      185.774 ?  1.100   ns/op
>> descriptorString_short                         avgt      135.338 ?  1.066   ns/op
>> descriptorString_long:?gc.alloc.rate.norm      avgt      336.030 ?  0.001    B/op
>> descriptorString_short:?gc.alloc.rate.norm     avgt      184.019 ?  0.001    B/op
>> 
>> full
>>                                                Mode      Score     Error   Units
>> descriptorString_long                          avgt     42.864 ?   0.160   ns/op
>> descriptorString_short                         avgt     27.255 ?   0.381   ns/op
>> descriptorString_long:?gc.alloc.rate.norm      avgt    224.005 ?   0.001    B/op
>> descriptorString_short:?gc.alloc.rate.norm     avgt    120.002 ?   0.001    B/op
>> 
>> Same can be done also for Class.isHidden() branch in Class.descriptorString() and for Class.getCanonicalName0()
>
> Hi Sergei,
> You are right that what javac generates is sub-optimal as it doesn't take into account the possible known final lenght of the string. So manually doing so is better. Since your 1st attempt a patch for String.join() method improved it quite a bit and is now not using StringBuilder under the hood any more. Could you try to measure for example the following:
> 
> 
> String str = String.join("/", baseName.replace('.', '/'), name);
> 
> as an alternative to:
> 
> String str = baseName.replace('.', '/') + '/' + name;
> 
> 
> or for example:
> 
> 
>             return String.join(
>                         "", // delimiter
>                         "L", name.substring(0, index).replace('.', '/'),
>                         ".", name.substring(index+1), ";");
> 
> as an alternative for:
> 
>             return "L" + name.substring(0, index).replace('.', '/')
>                        + "." + name.substring(index+1) + ";";
> 
> and see how it compares?
> 
> Regards, Peter

> @plevart hi, to my surprise `String.join()` makes it worse:
> 

Yeah, it seems JIT does a very good job with StringBuilder in this form.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3903

From bpb at openjdk.java.net  Fri May  7 15:46:11 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 7 May 2021 15:46:11 GMT
Subject: RFR: 8266610: Method RandomAccessFile#length() returns 0 for
 block devices on linux. [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 May 2021 12:17:11 GMT, Vyom Tewari  wrote:

>> RandomAccessFile.length() method for block device return always 0
>
> Vyom Tewari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed assigning -1 to uint64_t

Covers updated `FileInputStream` as well (JDK-8264777).

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3914

From bpb at openjdk.java.net  Fri May  7 16:13:07 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 7 May 2021 16:13:07 GMT
Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes
 [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 6 May 2021 16:40:31 GMT, Brian Burkhalter  wrote:

>> Please consider this request to override the `java.io.InputStream` methods `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more performant implementations. The method overrides attempt to read all requested bytes into a single array of the required size rather than composing the result from a sequence of smaller arrays. An example of the performance improvements is as follows.
>> 
>> **readAllBytes**
>> Before
>> 
>> Benchmark                                    (length)   Mode  Cnt      Score     Error  Units
>> ReadAllBytes.readAllBytesFileInputStream      1000000  thrpt   20   2412.031 ?   7.309  ops/s
>> ReadAllBytes.readAllBytesFileInputStream     10000000  thrpt   20    212.181 ?   0.369  ops/s
>> ReadAllBytes.readAllBytesFileInputStream    100000000  thrpt   20     19.860 ?   0.048  ops/s
>> ReadAllBytes.readAllBytesFileInputStream   1000000000  thrpt   20      1.298 ?   0.183  ops/s
>> 
>> After
>> 
>> Benchmark                                    (length)   Mode  Cnt      Score     Error  Units
>> ReadAllBytes.readAllBytesFileInputStream      1000000  thrpt   20   8218.473 ?  43.425  ops/s
>> ReadAllBytes.readAllBytesFileInputStream     10000000  thrpt   20    302.781 ?   1.273  ops/s
>> ReadAllBytes.readAllBytesFileInputStream    100000000  thrpt   20     22.461 ?   0.084  ops/s
>> ReadAllBytes.readAllBytesFileInputStream   1000000000  thrpt   20      1.502 ?   0.003  ops/s
>> 
>> 
>> **readNBytes**
>> 
>> `N = file_size / 2`
>> 
>> Before
>> 
>> Benchmark                                    (length)   Mode  Cnt      Score     Error  Units
>> ReadAllBytes.readHalfBytesFileInputStream     1000000  thrpt   20   5585.500 ? 153.353  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream    10000000  thrpt   20    436.164 ?   1.104  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream   100000000  thrpt   20     40.167 ?   0.141  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream  1000000000  thrpt   20      3.291 ?   0.211  ops/s
>> 
>> 
>> After
>> 
>> Benchmark                                    (length)   Mode  Cnt      Score     Error  Units
>> ReadAllBytes.readHalfBytesFileInputStream     1000000  thrpt   20  15463.210 ?  66.045  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream    10000000  thrpt   20    561.752 ?   0.951  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream   100000000  thrpt   20     45.043 ?   0.102  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream  1000000000  thrpt   20      4.629 ?   0.035  ops/s
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8264777: Make length and position consistent with RAF; add path to OOME message

All comments have been addressed. Are there any more? Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3845

From asemenyuk at openjdk.java.net  Fri May  7 17:32:21 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 7 May 2021 17:32:21 GMT
Subject: RFR: 8266456: Replace direct TKit.run() calls with
 jdk.jpackage.test.Annotations.Test annotation
In-Reply-To: 
References: 
Message-ID: 

On Fri, 7 May 2021 02:48:44 GMT, Alexander Matveev  wrote:

> - Replaced direct TKit.run() calls with Test annotation.
>  - Increased timeout for SigningPackageTest from default to 360 due to timeout. This is regression from JDK-8248904 due to changes done in signing and --remove-signature adds additional time since it is run per file.
>  - Fixed issue with jtreg.SkippedException which caused test to fail instead of being skipped, since it was wrapped in ExceptionBox.

I'd also make TKit.run() method package private as it is not called from outside of jdk.jpackage.test package any more.

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Functional.java line 161:

> 159:         }
> 160: 
> 161:         if (throwable.getClass().getName().equals("jtreg.SkippedException")) {

Would it make sense to have check: `if (throwable instanceof Runnable)`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3911

From asemenyuk at openjdk.java.net  Fri May  7 18:31:09 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 7 May 2021 18:31:09 GMT
Subject: RFR: 8266603: jpackage: Add missing copyright file in Java runtime
 .deb installers
Message-ID: 

jpackage should create copyright file in /usr/share/doc directory tree when building .deb package for Java runtime with installation directory in /usr directory tree.

jpackage creates share/doc/copyright file in installation directory for apps installed outside of /usr tree.

jpackage creates /usr/share/doc/${package_name}/copyright file for apps installed in /usr tree .

jpackage doesn't create copyright file at all for Java runtime. The reason for this behavior was that jpackage should not place additional files in installation directory of Java runtime. However when installing Java runtime or app in /usr tree, copyright file will be placed outside of installation directory. Thus copyright file should be always created if package installation directory is inside of /usr tree.

-------------

Commit messages:
 - trailing whitespaces removed
 - 8266603: jpackage: Add missing copyright file in Java runtime .deb installers

Changes: https://git.openjdk.java.net/jdk/pull/3894/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3894&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266603
  Stats: 27 lines in 2 files changed: 24 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3894.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3894/head:pull/3894

PR: https://git.openjdk.java.net/jdk/pull/3894

From jbhateja at openjdk.java.net  Fri May  7 18:31:15 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 7 May 2021 18:31:15 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v4]
In-Reply-To: 
References: 
Message-ID: 

> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
> 
>     vec1 = lanewise(VectorOperators.LSHL, n)
>     vec2 = lanewise(VectorOperators.LSHR, n)
>     res = lanewise(VectorOperations.OR, vec1 , vec2)
> 
> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
> 
> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
> 
> Please find below the performance data for included JMH benchmark.
> Machine:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascade lake Server)
> 
> ``
> 
> Benchmark | (TESTSIZE) | Shift | Baseline (ops/ms) | Withopt (ops/ms) | Gain %
> -- | -- | -- | -- | -- | --
> RotateBenchmark.testRotateLeftI | (size) | (shift) | 7384.747 | 7706.652 | 4.36
> RotateBenchmark.testRotateLeftI | 64 | 11 | 3723.305 | 3816.968 | 2.52
> RotateBenchmark.testRotateLeftI | 128 | 11 | 1811.521 | 1966.05 | 8.53
> RotateBenchmark.testRotateLeftI | 256 | 11 | 7133.296 | 7715.047 | 8.16
> RotateBenchmark.testRotateLeftI | 64 | 21 | 3612.144 | 3886.225 | 7.59
> RotateBenchmark.testRotateLeftI | 128 | 21 | 1815.422 | 1962.753 | 8.12
> RotateBenchmark.testRotateLeftI | 256 | 21 | 7216.353 | 7677.165 | 6.39
> RotateBenchmark.testRotateLeftI | 64 | 31 | 3602.008 | 3892.297 | 8.06
> RotateBenchmark.testRotateLeftI | 128 | 31 | 1882.163 | 1958.887 | 4.08
> RotateBenchmark.testRotateLeftI | 256 | 31 | 11819.443 | 11912.864 | 0.79
> RotateBenchmark.testRotateLeftI | 64 | 11 | 5978.475 | 6060.189 | 1.37
> RotateBenchmark.testRotateLeftI | 128 | 11 | 2965.179 | 3060.969 | 3.23
> RotateBenchmark.testRotateLeftI | 256 | 11 | 11479.579 | 11684.148 | 1.78
> RotateBenchmark.testRotateLeftI | 64 | 21 | 5904.903 | 6094.409 | 3.21
> RotateBenchmark.testRotateLeftI | 128 | 21 | 2969.879 | 3074.1 | 3.51
> RotateBenchmark.testRotateLeftI | 256 | 21 | 11531.654 | 12155.954 | 5.41
> RotateBenchmark.testRotateLeftI | 64 | 31 | 5730.918 | 6112.514 | 6.66
> RotateBenchmark.testRotateLeftI | 128 | 31 | 2937.19 | 2976.297 | 1.33
> RotateBenchmark.testRotateLeftI | 256 | 31 | 16159.184 | 16459.462 | 1.86
> RotateBenchmark.testRotateLeftI | 64 | 11 | 8154.982 | 8396.089 | 2.96
> RotateBenchmark.testRotateLeftI | 128 | 11 | 4142.224 | 4292.049 | 3.62
> RotateBenchmark.testRotateLeftI | 256 | 11 | 15958.154 | 16163.518 | 1.29
> RotateBenchmark.testRotateLeftI | 64 | 21 | 8098.805 | 8504.279 | 5.01
> RotateBenchmark.testRotateLeftI | 128 | 21 | 4137.598 | 4314.868 | 4.28
> RotateBenchmark.testRotateLeftI | 256 | 21 | 16201.666 | 15992.958 | -1.29
> RotateBenchmark.testRotateLeftI | 64 | 31 | 8027.169 | 8484.379 | 5.70
> RotateBenchmark.testRotateLeftI | 128 | 31 | 4146.29 | 4039.681 | -2.57
> RotateBenchmark.testRotateLeftL | 256 | 31 | 3566.176 | 3805.248 | 6.70
> RotateBenchmark.testRotateLeftL | 64 | 11 | 1820.219 | 1962.866 | 7.84
> RotateBenchmark.testRotateLeftL | 128 | 11 | 917.085 | 1007.334 | 9.84
> RotateBenchmark.testRotateLeftL | 256 | 11 | 3592.139 | 3973.698 | 10.62
> RotateBenchmark.testRotateLeftL | 64 | 21 | 1827.63 | 1999.711 | 9.42
> RotateBenchmark.testRotateLeftL | 128 | 21 | 907.104 | 1002.997 | 10.57
> RotateBenchmark.testRotateLeftL | 256 | 21 | 3780.962 | 3873.489 | 2.45
> RotateBenchmark.testRotateLeftL | 64 | 31 | 1830.121 | 1955.63 | 6.86
> RotateBenchmark.testRotateLeftL | 128 | 31 | 891.411 | 982.138 | 10.18
> RotateBenchmark.testRotateLeftL | 256 | 31 | 5890.544 | 6100.594 | 3.57
> RotateBenchmark.testRotateLeftL | 64 | 11 | 2984.329 | 3021.971 | 1.26
> RotateBenchmark.testRotateLeftL | 128 | 11 | 1485.109 | 1527.689 | 2.87
> RotateBenchmark.testRotateLeftL | 256 | 11 | 5903.411 | 6083.775 | 3.06
> RotateBenchmark.testRotateLeftL | 64 | 21 | 2925.37 | 3050.958 | 4.29
> RotateBenchmark.testRotateLeftL | 128 | 21 | 1486.432 | 1537.155 | 3.41
> RotateBenchmark.testRotateLeftL | 256 | 21 | 5853.721 | 6000.682 | 2.51
> RotateBenchmark.testRotateLeftL | 64 | 31 | 2896.116 | 3072.783 | 6.10
> RotateBenchmark.testRotateLeftL | 128 | 31 | 1483.132 | 1546.588 | 4.28
> RotateBenchmark.testRotateLeftL | 256 | 31 | 8059.206 | 8218.047 | 1.97
> RotateBenchmark.testRotateLeftL | 64 | 11 | 4022.416 | 4195.52 | 4.30
> RotateBenchmark.testRotateLeftL | 128 | 11 | 2084.296 | 2068.238 | -0.77
> RotateBenchmark.testRotateLeftL | 256 | 11 | 7971.832 | 8172.819 | 2.52
> RotateBenchmark.testRotateLeftL | 64 | 21 | 4032.036 | 4344.469 | 7.75
> RotateBenchmark.testRotateLeftL | 128 | 21 | 2068.957 | 2138.685 | 3.37
> RotateBenchmark.testRotateLeftL | 256 | 21 | 8140.63 | 8003.283 | -1.69
> RotateBenchmark.testRotateLeftL | 64 | 31 | 4088.621 | 4296.091 | 5.07
> RotateBenchmark.testRotateLeftL | 128 | 31 | 2007.753 | 2088.455 | 4.02
> RotateBenchmark.testRotateRightI | 256 | 31 | 7358.793 | 7548.976 | 2.58
> RotateBenchmark.testRotateRightI | 64 | 11 | 3648.868 | 3897.47 | 6.81
> RotateBenchmark.testRotateRightI | 128 | 11 | 1862.73 | 1969.964 | 5.76
> RotateBenchmark.testRotateRightI | 256 | 11 | 7268.806 | 7790.588 | 7.18
> RotateBenchmark.testRotateRightI | 64 | 21 | 3577.79 | 3979.675 | 11.23
> RotateBenchmark.testRotateRightI | 128 | 21 | 1773.243 | 1921.088 | 8.34
> RotateBenchmark.testRotateRightI | 256 | 21 | 7084.974 | 7609.912 | 7.41
> RotateBenchmark.testRotateRightI | 64 | 31 | 3688.781 | 3909.65 | 5.99
> RotateBenchmark.testRotateRightI | 128 | 31 | 1845.978 | 1928.316 | 4.46
> RotateBenchmark.testRotateRightI | 256 | 31 | 11463.228 | 12179.833 | 6.25
> RotateBenchmark.testRotateRightI | 64 | 11 | 5678.052 | 6028.573 | 6.17
> RotateBenchmark.testRotateRightI | 128 | 11 | 2990.419 | 3070.409 | 2.67
> RotateBenchmark.testRotateRightI | 256 | 11 | 11780.283 | 12105.261 | 2.76
> RotateBenchmark.testRotateRightI | 64 | 21 | 5827.8 | 6020.208 | 3.30
> RotateBenchmark.testRotateRightI | 128 | 21 | 2904.852 | 3047.154 | 4.90
> RotateBenchmark.testRotateRightI | 256 | 21 | 11359.146 | 12060.401 | 6.17
> RotateBenchmark.testRotateRightI | 64 | 31 | 5823.207 | 6079.82 | 4.41
> RotateBenchmark.testRotateRightI | 128 | 31 | 2984.484 | 3045.719 | 2.05
> RotateBenchmark.testRotateRightI | 256 | 31 | 16200.504 | 16376.475 | 1.09
> RotateBenchmark.testRotateRightI | 64 | 11 | 8118.399 | 8315.407 | 2.43
> RotateBenchmark.testRotateRightI | 128 | 11 | 4130.745 | 4092.588 | -0.92
> RotateBenchmark.testRotateRightI | 256 | 11 | 15842.168 | 16469.119 | 3.96
> RotateBenchmark.testRotateRightI | 64 | 21 | 7855.164 | 8188.913 | 4.25
> RotateBenchmark.testRotateRightI | 128 | 21 | 4114.378 | 4035.56 | -1.92
> RotateBenchmark.testRotateRightI | 256 | 21 | 15636.117 | 16289.632 | 4.18
> RotateBenchmark.testRotateRightI | 64 | 31 | 8108.067 | 7996.517 | -1.38
> RotateBenchmark.testRotateRightI | 128 | 31 | 3997.547 | 4153.58 | 3.90
> RotateBenchmark.testRotateRightL | 256 | 31 | 3685.99 | 3814.384 | 3.48
> RotateBenchmark.testRotateRightL | 64 | 11 | 1787.875 | 1916.541 | 7.20
> RotateBenchmark.testRotateRightL | 128 | 11 | 940.141 | 990.383 | 5.34
> RotateBenchmark.testRotateRightL | 256 | 11 | 3745.968 | 3920.667 | 4.66
> RotateBenchmark.testRotateRightL | 64 | 21 | 1877.94 | 1998.072 | 6.40
> RotateBenchmark.testRotateRightL | 128 | 21 | 933.536 | 1004.61 | 7.61
> RotateBenchmark.testRotateRightL | 256 | 21 | 3744.763 | 3947.427 | 5.41
> RotateBenchmark.testRotateRightL | 64 | 31 | 1864.818 | 1978.277 | 6.08
> RotateBenchmark.testRotateRightL | 128 | 31 | 906.965 | 998.692 | 10.11
> RotateBenchmark.testRotateRightL | 256 | 31 | 5910.469 | 6062.429 | 2.57
> RotateBenchmark.testRotateRightL | 64 | 11 | 2914.64 | 3033.127 | 4.07
> RotateBenchmark.testRotateRightL | 128 | 11 | 1491.344 | 1543.936 | 3.53
> RotateBenchmark.testRotateRightL | 256 | 11 | 5801.818 | 6098.892 | 5.12
> RotateBenchmark.testRotateRightL | 64 | 21 | 2881.328 | 3089.547 | 7.23
> RotateBenchmark.testRotateRightL | 128 | 21 | 1485.969 | 1526.231 | 2.71
> RotateBenchmark.testRotateRightL | 256 | 21 | 5783.495 | 5957.649 | 3.01
> RotateBenchmark.testRotateRightL | 64 | 31 | 3008.182 | 3026.323 | 0.60
> RotateBenchmark.testRotateRightL | 128 | 31 | 1464.566 | 1546.825 | 5.62
> RotateBenchmark.testRotateRightL | 256 | 31 | 8208.124 | 8361.437 | 1.87
> RotateBenchmark.testRotateRightL | 64 | 11 | 4062.465 | 4319.412 | 6.32
> RotateBenchmark.testRotateRightL | 128 | 11 | 2029.995 | 2086.497 | 2.78
> RotateBenchmark.testRotateRightL | 256 | 11 | 8183.789 | 8193.087 | 0.11
> RotateBenchmark.testRotateRightL | 64 | 21 | 4092.686 | 4193.712 | 2.47
> RotateBenchmark.testRotateRightL | 128 | 21 | 2036.854 | 2038.927 | 0.10
> RotateBenchmark.testRotateRightL | 256 | 21 | 8155.015 | 8175.792 | 0.25
> RotateBenchmark.testRotateRightL | 64 | 31 | 3960.629 | 4263.922 | 7.66
> RotateBenchmark.testRotateRightL | 128 | 31 | 1996.862 | 2055.486 | 2.94
> 
> ``

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8266054: Review comments resolution.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3720/files
  - new: https://git.openjdk.java.net/jdk/pull/3720/files/f7945bff..8042aa23

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3720&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3720&range=02-03

  Stats: 2651 lines in 39 files changed: 2328 ins; 10 del; 313 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3720.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3720/head:pull/3720

PR: https://git.openjdk.java.net/jdk/pull/3720

From asemenyuk at openjdk.java.net  Fri May  7 19:57:17 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 7 May 2021 19:57:17 GMT
Subject: RFR: 8266603: jpackage: Add missing copyright file in Java
 runtime .deb installers [v2]
In-Reply-To: 
References: 
Message-ID: 

> jpackage should create copyright file in /usr/share/doc directory tree when building .deb package for Java runtime with installation directory in /usr directory tree.
> 
> jpackage creates share/doc/copyright file in installation directory for apps installed outside of /usr tree.
> 
> jpackage creates /usr/share/doc/${package_name}/copyright file for apps installed in /usr tree .
> 
> jpackage doesn't create copyright file at all for Java runtime. The reason for this behavior was that jpackage should not place additional files in installation directory of Java runtime. However when installing Java runtime or app in /usr tree, copyright file will be placed outside of installation directory. Thus copyright file should be always created if package installation directory is inside of /usr tree.

Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - trailing whitespaces removed
 - 8266603: jpackage: Add missing copyright file in Java runtime .deb installers

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3894/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3894&range=01
  Stats: 27 lines in 2 files changed: 24 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3894.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3894/head:pull/3894

PR: https://git.openjdk.java.net/jdk/pull/3894

From winterhalter at openjdk.java.net  Fri May  7 19:57:49 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Fri, 7 May 2021 19:57:49 GMT
Subject: RFR: 8266766: Arrays of types that cannot be an annotation member do
 not yield exceptions
Message-ID: 

If a type is changed from a type that can be a member of an annotation which is used in an array, changing it to a type that cannot be an array member will be treated as if the type is an annotation type. As a result, no exception proxy is created and the type is returned as if it was correctly defined.

-------------

Commit messages:
 - 8266766: Arrays of types that cannot be an annotation member do not yield exceptions

Changes: https://git.openjdk.java.net/jdk/pull/3925/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3925&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266766
  Stats: 130 lines in 2 files changed: 128 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3925.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3925/head:pull/3925

PR: https://git.openjdk.java.net/jdk/pull/3925

From lancea at openjdk.java.net  Fri May  7 21:33:23 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 7 May 2021 21:33:23 GMT
Subject: RFR: 8255035: Update BCEL to Version 6.5.0
In-Reply-To: 
References: 
Message-ID: <2LTRAdO4W-WoIOYZ1R8I33tSZ0kdRz6q6Z9PDJ60LM0=.6f520b3f-10c7-4029-893d-661830ca1982@github.com>

On Thu, 6 May 2021 00:17:40 GMT, Joe Wang  wrote:

> Update BCEL to the latest version (6.5.0). The majority of the changes were code refactoring (name format changes).
> 
> XML tests passed on both Linux and Windows.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3893

From psandoz at openjdk.java.net  Fri May  7 21:33:53 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 7 May 2021 21:33:53 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 May 2021 18:31:15 GMT, Jatin Bhateja  wrote:

>> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
>> 
>>     vec1 = lanewise(VectorOperators.LSHL, n)
>>     vec2 = lanewise(VectorOperators.LSHR, n)
>>     res = lanewise(VectorOperations.OR, vec1 , vec2)
>> 
>> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
>> 
>> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
>> 
>> Please find below the performance data for included JMH benchmark.
>> Machine:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascade lake Server)
>> 
>> ``
>> 
>> Benchmark | (TESTSIZE) | Shift | Baseline (ops/ms) | Withopt (ops/ms) | Gain %
>> -- | -- | -- | -- | -- | --
>> RotateBenchmark.testRotateLeftI | (size) | (shift) | 7384.747 | 7706.652 | 4.36
>> RotateBenchmark.testRotateLeftI | 64 | 11 | 3723.305 | 3816.968 | 2.52
>> RotateBenchmark.testRotateLeftI | 128 | 11 | 1811.521 | 1966.05 | 8.53
>> RotateBenchmark.testRotateLeftI | 256 | 11 | 7133.296 | 7715.047 | 8.16
>> RotateBenchmark.testRotateLeftI | 64 | 21 | 3612.144 | 3886.225 | 7.59
>> RotateBenchmark.testRotateLeftI | 128 | 21 | 1815.422 | 1962.753 | 8.12
>> RotateBenchmark.testRotateLeftI | 256 | 21 | 7216.353 | 7677.165 | 6.39
>> RotateBenchmark.testRotateLeftI | 64 | 31 | 3602.008 | 3892.297 | 8.06
>> RotateBenchmark.testRotateLeftI | 128 | 31 | 1882.163 | 1958.887 | 4.08
>> RotateBenchmark.testRotateLeftI | 256 | 31 | 11819.443 | 11912.864 | 0.79
>> RotateBenchmark.testRotateLeftI | 64 | 11 | 5978.475 | 6060.189 | 1.37
>> RotateBenchmark.testRotateLeftI | 128 | 11 | 2965.179 | 3060.969 | 3.23
>> RotateBenchmark.testRotateLeftI | 256 | 11 | 11479.579 | 11684.148 | 1.78
>> RotateBenchmark.testRotateLeftI | 64 | 21 | 5904.903 | 6094.409 | 3.21
>> RotateBenchmark.testRotateLeftI | 128 | 21 | 2969.879 | 3074.1 | 3.51
>> RotateBenchmark.testRotateLeftI | 256 | 21 | 11531.654 | 12155.954 | 5.41
>> RotateBenchmark.testRotateLeftI | 64 | 31 | 5730.918 | 6112.514 | 6.66
>> RotateBenchmark.testRotateLeftI | 128 | 31 | 2937.19 | 2976.297 | 1.33
>> RotateBenchmark.testRotateLeftI | 256 | 31 | 16159.184 | 16459.462 | 1.86
>> RotateBenchmark.testRotateLeftI | 64 | 11 | 8154.982 | 8396.089 | 2.96
>> RotateBenchmark.testRotateLeftI | 128 | 11 | 4142.224 | 4292.049 | 3.62
>> RotateBenchmark.testRotateLeftI | 256 | 11 | 15958.154 | 16163.518 | 1.29
>> RotateBenchmark.testRotateLeftI | 64 | 21 | 8098.805 | 8504.279 | 5.01
>> RotateBenchmark.testRotateLeftI | 128 | 21 | 4137.598 | 4314.868 | 4.28
>> RotateBenchmark.testRotateLeftI | 256 | 21 | 16201.666 | 15992.958 | -1.29
>> RotateBenchmark.testRotateLeftI | 64 | 31 | 8027.169 | 8484.379 | 5.70
>> RotateBenchmark.testRotateLeftI | 128 | 31 | 4146.29 | 4039.681 | -2.57
>> RotateBenchmark.testRotateLeftL | 256 | 31 | 3566.176 | 3805.248 | 6.70
>> RotateBenchmark.testRotateLeftL | 64 | 11 | 1820.219 | 1962.866 | 7.84
>> RotateBenchmark.testRotateLeftL | 128 | 11 | 917.085 | 1007.334 | 9.84
>> RotateBenchmark.testRotateLeftL | 256 | 11 | 3592.139 | 3973.698 | 10.62
>> RotateBenchmark.testRotateLeftL | 64 | 21 | 1827.63 | 1999.711 | 9.42
>> RotateBenchmark.testRotateLeftL | 128 | 21 | 907.104 | 1002.997 | 10.57
>> RotateBenchmark.testRotateLeftL | 256 | 21 | 3780.962 | 3873.489 | 2.45
>> RotateBenchmark.testRotateLeftL | 64 | 31 | 1830.121 | 1955.63 | 6.86
>> RotateBenchmark.testRotateLeftL | 128 | 31 | 891.411 | 982.138 | 10.18
>> RotateBenchmark.testRotateLeftL | 256 | 31 | 5890.544 | 6100.594 | 3.57
>> RotateBenchmark.testRotateLeftL | 64 | 11 | 2984.329 | 3021.971 | 1.26
>> RotateBenchmark.testRotateLeftL | 128 | 11 | 1485.109 | 1527.689 | 2.87
>> RotateBenchmark.testRotateLeftL | 256 | 11 | 5903.411 | 6083.775 | 3.06
>> RotateBenchmark.testRotateLeftL | 64 | 21 | 2925.37 | 3050.958 | 4.29
>> RotateBenchmark.testRotateLeftL | 128 | 21 | 1486.432 | 1537.155 | 3.41
>> RotateBenchmark.testRotateLeftL | 256 | 21 | 5853.721 | 6000.682 | 2.51
>> RotateBenchmark.testRotateLeftL | 64 | 31 | 2896.116 | 3072.783 | 6.10
>> RotateBenchmark.testRotateLeftL | 128 | 31 | 1483.132 | 1546.588 | 4.28
>> RotateBenchmark.testRotateLeftL | 256 | 31 | 8059.206 | 8218.047 | 1.97
>> RotateBenchmark.testRotateLeftL | 64 | 11 | 4022.416 | 4195.52 | 4.30
>> RotateBenchmark.testRotateLeftL | 128 | 11 | 2084.296 | 2068.238 | -0.77
>> RotateBenchmark.testRotateLeftL | 256 | 11 | 7971.832 | 8172.819 | 2.52
>> RotateBenchmark.testRotateLeftL | 64 | 21 | 4032.036 | 4344.469 | 7.75
>> RotateBenchmark.testRotateLeftL | 128 | 21 | 2068.957 | 2138.685 | 3.37
>> RotateBenchmark.testRotateLeftL | 256 | 21 | 8140.63 | 8003.283 | -1.69
>> RotateBenchmark.testRotateLeftL | 64 | 31 | 4088.621 | 4296.091 | 5.07
>> RotateBenchmark.testRotateLeftL | 128 | 31 | 2007.753 | 2088.455 | 4.02
>> RotateBenchmark.testRotateRightI | 256 | 31 | 7358.793 | 7548.976 | 2.58
>> RotateBenchmark.testRotateRightI | 64 | 11 | 3648.868 | 3897.47 | 6.81
>> RotateBenchmark.testRotateRightI | 128 | 11 | 1862.73 | 1969.964 | 5.76
>> RotateBenchmark.testRotateRightI | 256 | 11 | 7268.806 | 7790.588 | 7.18
>> RotateBenchmark.testRotateRightI | 64 | 21 | 3577.79 | 3979.675 | 11.23
>> RotateBenchmark.testRotateRightI | 128 | 21 | 1773.243 | 1921.088 | 8.34
>> RotateBenchmark.testRotateRightI | 256 | 21 | 7084.974 | 7609.912 | 7.41
>> RotateBenchmark.testRotateRightI | 64 | 31 | 3688.781 | 3909.65 | 5.99
>> RotateBenchmark.testRotateRightI | 128 | 31 | 1845.978 | 1928.316 | 4.46
>> RotateBenchmark.testRotateRightI | 256 | 31 | 11463.228 | 12179.833 | 6.25
>> RotateBenchmark.testRotateRightI | 64 | 11 | 5678.052 | 6028.573 | 6.17
>> RotateBenchmark.testRotateRightI | 128 | 11 | 2990.419 | 3070.409 | 2.67
>> RotateBenchmark.testRotateRightI | 256 | 11 | 11780.283 | 12105.261 | 2.76
>> RotateBenchmark.testRotateRightI | 64 | 21 | 5827.8 | 6020.208 | 3.30
>> RotateBenchmark.testRotateRightI | 128 | 21 | 2904.852 | 3047.154 | 4.90
>> RotateBenchmark.testRotateRightI | 256 | 21 | 11359.146 | 12060.401 | 6.17
>> RotateBenchmark.testRotateRightI | 64 | 31 | 5823.207 | 6079.82 | 4.41
>> RotateBenchmark.testRotateRightI | 128 | 31 | 2984.484 | 3045.719 | 2.05
>> RotateBenchmark.testRotateRightI | 256 | 31 | 16200.504 | 16376.475 | 1.09
>> RotateBenchmark.testRotateRightI | 64 | 11 | 8118.399 | 8315.407 | 2.43
>> RotateBenchmark.testRotateRightI | 128 | 11 | 4130.745 | 4092.588 | -0.92
>> RotateBenchmark.testRotateRightI | 256 | 11 | 15842.168 | 16469.119 | 3.96
>> RotateBenchmark.testRotateRightI | 64 | 21 | 7855.164 | 8188.913 | 4.25
>> RotateBenchmark.testRotateRightI | 128 | 21 | 4114.378 | 4035.56 | -1.92
>> RotateBenchmark.testRotateRightI | 256 | 21 | 15636.117 | 16289.632 | 4.18
>> RotateBenchmark.testRotateRightI | 64 | 31 | 8108.067 | 7996.517 | -1.38
>> RotateBenchmark.testRotateRightI | 128 | 31 | 3997.547 | 4153.58 | 3.90
>> RotateBenchmark.testRotateRightL | 256 | 31 | 3685.99 | 3814.384 | 3.48
>> RotateBenchmark.testRotateRightL | 64 | 11 | 1787.875 | 1916.541 | 7.20
>> RotateBenchmark.testRotateRightL | 128 | 11 | 940.141 | 990.383 | 5.34
>> RotateBenchmark.testRotateRightL | 256 | 11 | 3745.968 | 3920.667 | 4.66
>> RotateBenchmark.testRotateRightL | 64 | 21 | 1877.94 | 1998.072 | 6.40
>> RotateBenchmark.testRotateRightL | 128 | 21 | 933.536 | 1004.61 | 7.61
>> RotateBenchmark.testRotateRightL | 256 | 21 | 3744.763 | 3947.427 | 5.41
>> RotateBenchmark.testRotateRightL | 64 | 31 | 1864.818 | 1978.277 | 6.08
>> RotateBenchmark.testRotateRightL | 128 | 31 | 906.965 | 998.692 | 10.11
>> RotateBenchmark.testRotateRightL | 256 | 31 | 5910.469 | 6062.429 | 2.57
>> RotateBenchmark.testRotateRightL | 64 | 11 | 2914.64 | 3033.127 | 4.07
>> RotateBenchmark.testRotateRightL | 128 | 11 | 1491.344 | 1543.936 | 3.53
>> RotateBenchmark.testRotateRightL | 256 | 11 | 5801.818 | 6098.892 | 5.12
>> RotateBenchmark.testRotateRightL | 64 | 21 | 2881.328 | 3089.547 | 7.23
>> RotateBenchmark.testRotateRightL | 128 | 21 | 1485.969 | 1526.231 | 2.71
>> RotateBenchmark.testRotateRightL | 256 | 21 | 5783.495 | 5957.649 | 3.01
>> RotateBenchmark.testRotateRightL | 64 | 31 | 3008.182 | 3026.323 | 0.60
>> RotateBenchmark.testRotateRightL | 128 | 31 | 1464.566 | 1546.825 | 5.62
>> RotateBenchmark.testRotateRightL | 256 | 31 | 8208.124 | 8361.437 | 1.87
>> RotateBenchmark.testRotateRightL | 64 | 11 | 4062.465 | 4319.412 | 6.32
>> RotateBenchmark.testRotateRightL | 128 | 11 | 2029.995 | 2086.497 | 2.78
>> RotateBenchmark.testRotateRightL | 256 | 11 | 8183.789 | 8193.087 | 0.11
>> RotateBenchmark.testRotateRightL | 64 | 21 | 4092.686 | 4193.712 | 2.47
>> RotateBenchmark.testRotateRightL | 128 | 21 | 2036.854 | 2038.927 | 0.10
>> RotateBenchmark.testRotateRightL | 256 | 21 | 8155.015 | 8175.792 | 0.25
>> RotateBenchmark.testRotateRightL | 64 | 31 | 3960.629 | 4263.922 | 7.66
>> RotateBenchmark.testRotateRightL | 128 | 31 | 1996.862 | 2055.486 | 2.94
>> 
>> ``
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266054: Review comments resolution.

Java code updates look good

I believe you can now remove the four "*-Rotate_*.template" files now that you leverage exiting templates?

Also, i believe ancillary changes to `gen-template.sh` are no longer strictly required, now that we defer to method calls for ROL/ROR?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From almatvee at openjdk.java.net  Fri May  7 23:21:47 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 7 May 2021 23:21:47 GMT
Subject: RFR: 8266456: Replace direct TKit.run() calls with
 jdk.jpackage.test.Annotations.Test annotation
In-Reply-To: 
References: 
Message-ID: 

On Fri, 7 May 2021 02:48:44 GMT, Alexander Matveev  wrote:

> - Replaced direct TKit.run() calls with Test annotation.
>  - Increased timeout for SigningPackageTest from default to 360 due to timeout. This is regression from JDK-8248904 due to changes done in signing and --remove-signature adds additional time since it is run per file.
>  - Fixed issue with jtreg.SkippedException which caused test to fail instead of being skipped, since it was wrapped in ExceptionBox.

TKit.run() is no longer used, so I will remove it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3911

From almatvee at openjdk.java.net  Fri May  7 23:21:49 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 7 May 2021 23:21:49 GMT
Subject: RFR: 8266456: Replace direct TKit.run() calls with
 jdk.jpackage.test.Annotations.Test annotation
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 May 2021 16:50:15 GMT, Alexey Semenyuk  wrote:

>> - Replaced direct TKit.run() calls with Test annotation.
>>  - Increased timeout for SigningPackageTest from default to 360 due to timeout. This is regression from JDK-8248904 due to changes done in signing and --remove-signature adds additional time since it is run per file.
>>  - Fixed issue with jtreg.SkippedException which caused test to fail instead of being skipped, since it was wrapped in ExceptionBox.
>
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Functional.java line 161:
> 
>> 159:         }
>> 160: 
>> 161:         if (throwable.getClass().getName().equals("jtreg.SkippedException")) {
> 
> Would it make sense to have check: `if (throwable instanceof Runnable)`?

Not sure. I do not think it will work. SkippedException extends RuntimeException, so not sure why we need to check it with Runnable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3911

From almatvee at openjdk.java.net  Fri May  7 23:54:54 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 7 May 2021 23:54:54 GMT
Subject: RFR: 8266603: jpackage: Add missing copyright file in Java
 runtime .deb installers [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 May 2021 19:57:17 GMT, Alexey Semenyuk  wrote:

>> jpackage should create copyright file in /usr/share/doc directory tree when building .deb package for Java runtime with installation directory in /usr directory tree.
>> 
>> jpackage creates share/doc/copyright file in installation directory for apps installed outside of /usr tree.
>> 
>> jpackage creates /usr/share/doc/${package_name}/copyright file for apps installed in /usr tree .
>> 
>> jpackage doesn't create copyright file at all for Java runtime. The reason for this behavior was that jpackage should not place additional files in installation directory of Java runtime. However when installing Java runtime or app in /usr tree, copyright file will be placed outside of installation directory. Thus copyright file should be always created if package installation directory is inside of /usr tree.
>
> Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - trailing whitespaces removed
>  - 8266603: jpackage: Add missing copyright file in Java runtime .deb installers

Marked as reviewed by almatvee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3894

From naoto at openjdk.java.net  Sat May  8 00:03:38 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Sat, 8 May 2021 00:03:38 GMT
Subject: RFR: 8266774: System property values for stdout/err on Windows UTF-8
Message-ID: <9jYN7sQh6DrukhjCgUco9DmnHkAqw2W3kb3TlonGLeM=.0cccb7ae-ad98-4453-a0e5-15efa3c71ca1@github.com>

Please review this small fix to Windows system property init code. This is leftover from the support for `Console.charset()` method, where it lacked to initialize `sun.stdout/err.encoding` to `UTF-8` for the code page `cp65001`.  The fix has been manually verified, but no automated test case is provided, as automatically setting `UTF-8` for the system locale on Windows test machine seems not possible.

-------------

Commit messages:
 - 8266774: System property values for stdout/err on Windows UTF-8

Changes: https://git.openjdk.java.net/jdk/pull/3931/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3931&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266774
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3931.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3931/head:pull/3931

PR: https://git.openjdk.java.net/jdk/pull/3931

From bpb at openjdk.java.net  Sat May  8 00:20:22 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Sat, 8 May 2021 00:20:22 GMT
Subject: RFR: 8266774: System property values for stdout/err on Windows
 UTF-8
In-Reply-To: <9jYN7sQh6DrukhjCgUco9DmnHkAqw2W3kb3TlonGLeM=.0cccb7ae-ad98-4453-a0e5-15efa3c71ca1@github.com>
References: <9jYN7sQh6DrukhjCgUco9DmnHkAqw2W3kb3TlonGLeM=.0cccb7ae-ad98-4453-a0e5-15efa3c71ca1@github.com>
Message-ID: 

On Fri, 7 May 2021 22:46:08 GMT, Naoto Sato  wrote:

> Please review this small fix to Windows system property init code. This is leftover from the support for `Console.charset()` method, where it lacked to initialize `sun.stdout/err.encoding` to `UTF-8` for the code page `cp65001`.  The fix has been manually verified, but no automated test case is provided, as automatically setting `UTF-8` for the system locale on Windows test machine seems not possible.

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3931

From almatvee at openjdk.java.net  Sat May  8 01:44:46 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Sat, 8 May 2021 01:44:46 GMT
Subject: RFR: 8266456: Replace direct TKit.run() calls with
 jdk.jpackage.test.Annotations.Test annotation [v2]
In-Reply-To: 
References: 
Message-ID: 

> - Replaced direct TKit.run() calls with Test annotation.
>  - Increased timeout for SigningPackageTest from default to 360 due to timeout. This is regression from JDK-8248904 due to changes done in signing and --remove-signature adds additional time since it is run per file.
>  - Fixed issue with jtreg.SkippedException which caused test to fail instead of being skipped, since it was wrapped in ExceptionBox.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8266456: Replace direct TKit.run() calls with jdk.jpackage.test.Annotations.Test annotation [v2]

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3911/files
  - new: https://git.openjdk.java.net/jdk/pull/3911/files/687b5c81..b382561f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3911&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3911&range=00-01

  Stats: 15 lines in 1 file changed: 0 ins; 14 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3911.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3911/head:pull/3911

PR: https://git.openjdk.java.net/jdk/pull/3911

From yyang at openjdk.java.net  Sat May  8 03:00:14 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Sat, 8 May 2021 03:00:14 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v9]
In-Reply-To: 
References: 
Message-ID: 

> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
> 
> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
> 
> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
> 
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
> 
> Testing: cds, compiler and jdk

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  x86_32 fails

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3615/files
  - new: https://git.openjdk.java.net/jdk/pull/3615/files/f996c99f..307d7a10

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=07-08

  Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615

PR: https://git.openjdk.java.net/jdk/pull/3615

From yyang at openjdk.java.net  Sat May  8 05:36:17 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Sat, 8 May 2021 05:36:17 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 30 Apr 2021 19:20:54 GMT, Igor Veresov  wrote:

> Looks like now the test fails in the pre-submit tests?

Hi Igor,

Can you take a look at the latest version? Now it passes all pre-submit tests.

Best Regards,
Yang

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From yyang at openjdk.java.net  Sat May  8 05:36:17 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Sat, 8 May 2021 05:36:17 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: <9Z_DkUjmqefCjf9mvecHUtoLHhw1qGNWJPxufuwvXI0=.36498a86-d09f-4eea-ab89-74844dd862cf@github.com>
References: 
 
 <9Z_DkUjmqefCjf9mvecHUtoLHhw1qGNWJPxufuwvXI0=.36498a86-d09f-4eea-ab89-74844dd862cf@github.com>
Message-ID: <4IY0_Zr94l_aZTe-fYIva28aZw8uYJ5k6d48uByI70E=.19f2b9e5-4958-4bb3-b016-d9f809fe3347@github.com>

On Fri, 30 Apr 2021 17:30:33 GMT, Paul Sandoz  wrote:

> It was my hope this would eventually happen when we added `Objects.checkIndex` and the underlying intrinsic. Very good!

Hi Paul,

Thank you for noticing this PR.
> It was my hope this would eventually happen when we added `Objects.checkIndex` and the underlying intrinsic.
Yes, this patch adds C1 intrinsic supports for checkIndex, I will replace all variants of checkIndex with Objects.checkIndex in follow-up PRs.

It seems that Object.checkIndex can not meet our needs because it implicitly passes null to Preconditions.checkIndex, but we want to customize exception messages, so we might add extra APIs in Objects while doing the replacement.

> Very good!
Thank you Paul~

Best Regards,
Yang

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From jbhateja at openjdk.java.net  Sat May  8 05:54:38 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sat, 8 May 2021 05:54:38 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v5]
In-Reply-To: 
References: 
Message-ID: 

> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
> 
>     vec1 = lanewise(VectorOperators.LSHL, n)
>     vec2 = lanewise(VectorOperators.LSHR, n)
>     res = lanewise(VectorOperations.OR, vec1 , vec2)
> 
> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
> 
> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
> 
> Please find below the performance data for included JMH benchmark.
> Machine:  Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz)
> 
> 
> Benchmark | (TESTSIZE) | Shift | Baseline AVX3 (ops/ms) | Withopt? AVX3 (ops/ms) | Gain % | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain %
> -- | -- | -- | -- | -- | -- | -- | -- | --
> ? | ? | ? | ? | ? | ? | ? | ? | ?
> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 17223.35 | 17094.69 | -0.75 | 17008.32 | 17488.06 | 2.82
> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 8944.98 | 8811.34 | -1.49 | 8878.17 | 9218.68 | 3.84
> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 17195.75 | 17137.32 | -0.34 | 16789.01 | 17780.34 | 5.90
> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 9052.67 | 8838.60 | -2.36 | 8814.62 | 9206.01 | 4.44
> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 17100.19 | 16950.64 | -0.87 | 16827.73 | 17720.37 | 5.30
> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 9079.95 | 8471.26 | -6.70 | 8888.44 | 9167.68 | 3.14
> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 21231.33 | 21513.08 | 1.33 | 21824.51 | 21479.48 | -1.58
> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 11103.62 | 11180.16 | 0.69 | 11173.67 | 11529.22 | 3.18
> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 21119.14 | 21552.04 | 2.05 | 21693.05 | 21915.37 | 1.02
> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 11048.68 | 11094.20 | 0.41 | 11049.90 | 11439.07 | 3.52
> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 21506.31 | 21391.41 | -0.53 | 21263.18 | 21986.29 | 3.40
> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 11056.12 | 11232.78 | 1.60 | 10941.59 | 11397.09 | 4.16
> RotateBenchmark.testRotateLeftB | 512.00 | 7.00 | 17976.56 | 18180.85 | 1.14 | 1212.26 | 2533.34 | 108.98
> RotateBenchmark.testRotateLeftB | 512.00 | 15.00 | 17553.70 | 18219.07 | 3.79 | 1256.73 | 2537.41 | 101.91
> RotateBenchmark.testRotateLeftB | 512.00 | 31.00 | 17618.03 | 17738.15 | 0.68 | 1214.69 | 2533.83 | 108.60
> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 7258.87 | 7468.88 | 2.89 | 7115.12 | 7117.26 | 0.03
> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 3586.65 | 3950.85 | 10.15 | 3532.17 | 3595.80 | 1.80
> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 1835.07 | 1999.68 | 8.97 | 1789.90 | 1819.93 | 1.68
> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 7273.36 | 7410.91 | 1.89 | 7198.60 | 6994.79 | -2.83
> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 3674.98 | 3926.27 | 6.84 | 3549.90 | 3755.09 | 5.78
> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 1840.94 | 1882.25 | 2.24 | 1801.56 | 1872.89 | 3.96
> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 7457.11 | 7361.48 | -1.28 | 6975.33 | 7385.94 | 5.89
> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 3570.74 | 3929.30 | 10.04 | 3635.37 | 3736.67 | 2.79
> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 1902.32 | 1960.46 | 3.06 | 1812.32 | 1813.88 | 0.09
> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 11174.24 | 12044.52 | 7.79 | 11509.87 | 11273.44 | -2.05
> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 5981.47 | 6073.70 | 1.54 | 5593.66 | 5661.93 | 1.22
> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 2932.49 | 3069.54 | 4.67 | 2950.86 | 2892.42 | -1.98
> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 11764.11 | 12098.63 | 2.84 | 11069.52 | 11476.93 | 3.68
> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 5855.20 | 6080.40 | 3.85 | 5919.11 | 5607.04 | -5.27
> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 2989.05 | 3048.56 | 1.99 | 2902.63 | 2821.83 | -2.78
> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 11652.84 | 11965.40 | 2.68 | 11525.62 | 11459.83 | -0.57
> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 5851.82 | 6164.94 | 5.35 | 5882.60 | 5842.30 | -0.69
> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 3015.99 | 3043.79 | 0.92 | 2963.71 | 2947.97 | -0.53
> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 16029.15 | 16189.79 | 1.00 | 860.43 | 2339.32 | 171.88
> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 8078.25 | 8081.84 | 0.04 | 427.39 | 1147.92 | 168.59
> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 4021.49 | 4294.03 | 6.78 | 209.25 | 582.28 | 178.27
> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 15912.98 | 16329.03 | 2.61 | 848.23 | 2296.78 | 170.77
> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 8054.10 | 8306.37 | 3.13 | 429.93 | 1146.90 | 166.77
> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 4102.58 | 4071.08 | -0.77 | 217.86 | 582.20 | 167.24
> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 16177.79 | 16287.85 | 0.68 | 857.84 | 2243.15 | 161.49
> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 8187.47 | 8410.48 | 2.72 | 434.60 | 1128.20 | 159.60
> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 4109.15 | 4233.80 | 3.03 | 208.71 | 572.43 | 174.27
> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 3755.09 | 3930.29 | 4.67 | 3604.19 | 3598.47 | -0.16
> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 1829.03 | 1957.39 | 7.02 | 1833.95 | 1808.38 | -1.39
> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 915.35 | 970.55 | 6.03 | 916.25 | 899.08 | -1.87
> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 3664.85 | 3812.26 | 4.02 | 3629.37 | 3579.23 | -1.38
> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 1829.51 | 1877.76 | 2.64 | 1781.05 | 1807.57 | 1.49
> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 913.37 | 953.42 | 4.38 | 912.26 | 908.73 | -0.39
> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 3648.45 | 3899.20 | 6.87 | 3552.67 | 3581.04 | 0.80
> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 1816.50 | 1959.68 | 7.88 | 1820.88 | 1819.71 | -0.06
> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 901.05 | 955.13 | 6.00 | 913.74 | 907.90 | -0.64
> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 5850.99 | 6108.64 | 4.40 | 5882.65 | 5755.21 | -2.17
> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 2962.21 | 3060.47 | 3.32 | 2955.20 | 2909.18 | -1.56
> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 1480.46 | 1534.72 | 3.66 | 1467.78 | 1430.60 | -2.53
> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 5858.23 | 6047.51 | 3.23 | 5770.02 | 5773.19 | 0.05
> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 2951.49 | 3096.53 | 4.91 | 2885.21 | 2899.31 | 0.49
> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 1486.26 | 1527.94 | 2.80 | 1441.93 | 1454.25 | 0.85
> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 5873.21 | 6089.75 | 3.69 | 5767.58 | 5664.11 | -1.79
> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 2969.67 | 3081.39 | 3.76 | 2878.50 | 2905.86 | 0.95
> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 1452.21 | 1520.03 | 4.67 | 1430.30 | 1485.63 | 3.87
> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 8088.65 | 8443.63 | 4.39 | 455.67 | 1226.33 | 169.13
> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 4011.95 | 4120.25 | 2.70 | 229.77 | 619.87 | 169.77
> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 2090.57 | 2109.53 | 0.91 | 115.21 | 310.36 | 169.37
> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 8166.84 | 8557.28 | 4.78 | 457.67 | 1242.86 | 171.56
> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 4137.02 | 4287.95 | 3.65 | 227.26 | 624.80 | 174.93
> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 2095.01 | 2102.86 | 0.37 | 114.26 | 310.83 | 172.03
> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 8082.68 | 8400.56 | 3.93 | 459.59 | 1230.07 | 167.64
> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 4047.67 | 4147.58 | 2.47 | 229.01 | 606.38 | 164.78
> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 2086.83 | 2126.72 | 1.91 | 111.93 | 305.66 | 173.08
> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 13597.19 | 13255.09 | -2.52 | 13818.39 | 13242.40 | -4.17
> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 7028.26 | 6826.59 | -2.87 | 6765.15 | 6907.87 | 2.11
> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 3570.40 | 3468.01 | -2.87 | 3449.66 | 3533.50 | 2.43
> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 13615.99 | 13464.40 | -1.11 | 13330.02 | 13870.57 | 4.06
> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 7043.31 | 6763.34 | -3.97 | 6928.88 | 7063.57 | 1.94
> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 3495.12 | 3537.62 | 1.22 | 3503.41 | 3457.67 | -1.31
> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 13591.66 | 13665.84 | 0.55 | 13773.27 | 13126.08 | -4.70
> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 7027.08 | 7011.24 | -0.23 | 6974.98 | 6815.50 | -2.29
> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 3568.28 | 3569.62 | 0.04 | 3580.67 | 3463.58 | -3.27
> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 21154.03 | 21416.32 | 1.24 | 21187.01 | 21401.61 | 1.01
> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 11194.24 | 10865.47 | -2.94 | 11063.19 | 10977.60 | -0.77
> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 5797.80 | 5523.94 | -4.72 | 5654.63 | 5468.78 | -3.29
> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 21333.89 | 21412.74 | 0.37 | 21610.94 | 20908.96 | -3.25
> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 11327.07 | 11113.48 | -1.89 | 11148.25 | 10678.14 | -4.22
> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 5810.69 | 5569.72 | -4.15 | 5663.26 | 5618.87 | -0.78
> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 21753.20 | 21198.43 | -2.55 | 21567.90 | 21929.81 | 1.68
> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 11517.08 | 11039.64 | -4.15 | 11103.08 | 10871.59 | -2.08
> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 5897.16 | 5606.75 | -4.92 | 5459.87 | 5604.12 | 2.64
> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 29748.53 | 28883.73 | -2.91 | 1549.02 | 3928.53 | 153.61
> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 15197.09 | 15878.19 | 4.48 | 772.59 | 1924.35 | 149.08
> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 8046.30 | 8081.19 | 0.43 | 388.11 | 990.28 | 155.16
> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 30618.04 | 29419.19 | -3.92 | 1524.22 | 3915.97 | 156.92
> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 15854.43 | 15846.37 | -0.05 | 766.09 | 1953.60 | 155.01
> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 7814.77 | 7899.30 | 1.08 | 390.82 | 970.37 | 148.29
> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 29596.82 | 28538.69 | -3.58 | 1530.45 | 3906.91 | 155.28
> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 15662.48 | 15849.25 | 1.19 | 778.08 | 1934.31 | 148.60
> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 8121.14 | 7758.59 | -4.46 | 392.78 | 959.73 | 144.34
> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 17465.84 | 17069.34 | -2.27 | 16849.73 | 17842.08 | 5.89
> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 9049.19 | 8864.15 | -2.04 | 8786.67 | 9105.34 | 3.63
> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 17703.38 | 17070.98 | -3.57 | 16595.85 | 17784.68 | 7.16
> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 9007.68 | 8817.41 | -2.11 | 8704.49 | 9185.87 | 5.53
> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 17531.05 | 16983.40 | -3.12 | 16947.69 | 17655.40 | 4.18
> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 8986.30 | 8794.15 | -2.14 | 8816.62 | 9225.95 | 4.64
> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 21293.95 | 21506.74 | 1.00 | 21163.29 | 21854.03 | 3.26
> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 11258.47 | 11072.92 | -1.65 | 11118.12 | 11338.96 | 1.99
> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 21253.36 | 21292.37 | 0.18 | 21224.39 | 21763.88 | 2.54
> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 11064.80 | 11198.35 | 1.21 | 10960.98 | 11294.14 | 3.04
> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 21358.14 | 21346.21 | -0.06 | 21487.25 | 21854.42 | 1.71
> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 11045.61 | 11208.26 | 1.47 | 10907.03 | 11415.18 | 4.66
> RotateBenchmark.testRotateRightB | 512.00 | 7.00 | 17898.61 | 18307.54 | 2.28 | 1214.65 | 2546.64 | 109.66
> RotateBenchmark.testRotateRightB | 512.00 | 15.00 | 17909.25 | 18242.51 | 1.86 | 1215.05 | 2563.98 | 111.02
> RotateBenchmark.testRotateRightB | 512.00 | 31.00 | 17883.35 | 17928.44 | 0.25 | 1220.77 | 2543.30 | 108.34
> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 7139.97 | 7626.72 | 6.82 | 6994.86 | 7075.65 | 1.15
> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 3657.37 | 3898.34 | 6.59 | 3617.06 | 3576.12 | -1.13
> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 1804.26 | 1969.19 | 9.14 | 1796.62 | 1858.84 | 3.46
> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 7404.31 | 7760.09 | 4.80 | 7036.77 | 7401.52 | 5.18
> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 3600.52 | 3956.35 | 9.88 | 3595.28 | 3560.36 | -0.97
> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 1813.32 | 1966.41 | 8.44 | 1839.95 | 1852.53 | 0.68
> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 7118.48 | 7724.81 | 8.52 | 7151.56 | 7021.09 | -1.82
> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 3529.70 | 3881.63 | 9.97 | 3623.08 | 3601.01 | -0.61
> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 1823.61 | 1961.34 | 7.55 | 1786.86 | 1748.85 | -2.13
> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 11697.98 | 11835.25 | 1.17 | 11513.16 | 11184.87 | -2.85
> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 5890.11 | 6102.57 | 3.61 | 5658.79 | 5696.08 | 0.66
> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 2964.94 | 3070.26 | 3.55 | 2945.00 | 2962.08 | 0.58
> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 11562.51 | 12151.29 | 5.09 | 11404.17 | 11120.28 | -2.49
> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 5702.93 | 6130.57 | 7.50 | 5799.54 | 5779.08 | -0.35
> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 2861.96 | 3051.44 | 6.62 | 2943.99 | 2860.65 | -2.83
> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 11203.13 | 11710.59 | 4.53 | 11363.18 | 11112.16 | -2.21
> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 5893.97 | 6070.71 | 3.00 | 5776.67 | 5648.84 | -2.21
> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 2971.83 | 3046.76 | 2.52 | 2903.35 | 2833.88 | -2.39
> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 16064.71 | 15851.35 | -1.33 | 861.93 | 2256.88 | 161.84
> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 7916.80 | 8462.65 | 6.89 | 430.23 | 1147.30 | 166.67
> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 4104.64 | 4068.28 | -0.89 | 216.30 | 572.86 | 164.84
> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 16133.09 | 16281.59 | 0.92 | 856.36 | 2229.58 | 160.35
> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 8127.26 | 8117.59 | -0.12 | 419.16 | 1176.42 | 180.66
> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 4080.11 | 4063.26 | -0.41 | 218.32 | 571.93 | 161.97
> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 15834.26 | 16314.64 | 3.03 | 865.96 | 2297.74 | 165.34
> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 7965.62 | 8270.48 | 3.83 | 428.55 | 1148.87 | 168.08
> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 4161.69 | 4034.76 | -3.05 | 215.63 | 570.19 | 164.43
> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 3556.70 | 3877.08 | 9.01 | 3596.46 | 3558.32 | -1.06
> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 1772.93 | 1993.86 | 12.46 | 1856.79 | 1783.22 | -3.96
> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 908.66 | 1000.37 | 10.09 | 944.79 | 922.91 | -2.32
> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 3742.44 | 3748.41 | 0.16 | 3788.07 | 3570.67 | -5.74
> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 1817.53 | 1985.69 | 9.25 | 1892.38 | 1833.16 | -3.13
> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 941.03 | 952.68 | 1.24 | 915.79 | 910.21 | -0.61
> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 3649.48 | 3896.56 | 6.77 | 3637.59 | 3557.53 | -2.20
> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 1840.12 | 1997.19 | 8.54 | 1821.47 | 1799.82 | -1.19
> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 901.33 | 995.67 | 10.47 | 909.20 | 902.73 | -0.71
> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 5789.93 | 5960.54 | 2.95 | 5758.14 | 5736.30 | -0.38
> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 2963.20 | 3063.30 | 3.38 | 2943.48 | 2833.84 | -3.72
> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 1501.81 | 1510.23 | 0.56 | 1463.85 | 1462.26 | -0.11
> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 5870.05 | 5951.43 | 1.39 | 5794.74 | 5604.58 | -3.28
> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 2971.36 | 3047.00 | 2.55 | 2931.19 | 2907.30 | -0.82
> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 1473.97 | 1530.54 | 3.84 | 1473.45 | 1442.40 | -2.11
> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 5858.08 | 6080.49 | 3.80 | 5863.69 | 5549.85 | -5.35
> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 2916.24 | 3045.77 | 4.44 | 2981.59 | 2815.07 | -5.58
> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 1441.20 | 1531.56 | 6.27 | 1492.47 | 1473.25 | -1.29
> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 8147.24 | 8310.05 | 2.00 | 469.45 | 1235.21 | 163.12
> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 4142.95 | 4258.86 | 2.80 | 234.14 | 615.52 | 162.88
> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 2095.48 | 2087.20 | -0.40 | 113.55 | 311.19 | 174.05
> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 8222.94 | 8246.58 | 0.29 | 458.91 | 1244.32 | 171.15
> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 4160.04 | 4226.46 | 1.60 | 227.78 | 625.38 | 174.56
> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 2064.63 | 2162.44 | 4.74 | 113.27 | 314.15 | 177.36
> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 8157.94 | 8466.90 | 3.79 | 450.26 | 1221.90 | 171.37
> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 4039.74 | 4283.33 | 6.03 | 224.82 | 612.68 | 172.53
> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 2066.88 | 2147.51 | 3.90 | 110.97 | 303.43 | 173.42
> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 13548.39 | 13245.87 | -2.23 | 13490.93 | 13084.76 | -3.01
> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 7020.16 | 6768.85 | -3.58 | 6991.39 | 7044.32 | 0.76
> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 3550.50 | 3505.19 | -1.28 | 3507.12 | 3612.86 | 3.01
> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 13743.43 | 13325.44 | -3.04 | 13696.15 | 13255.80 | -3.22
> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 6856.02 | 6969.18 | 1.65 | 6886.29 | 6834.12 | -0.76
> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 3569.53 | 3492.76 | -2.15 | 3539.02 | 3470.02 | -1.95
> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 13704.18 | 13495.07 | -1.53 | 13649.14 | 13583.87 | -0.48
> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 7011.77 | 6953.93 | -0.82 | 6978.28 | 6740.30 | -3.41
> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 3591.62 | 3620.12 | 0.79 | 3502.04 | 3510.05 | 0.23
> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 21950.71 | 22113.60 | 0.74 | 21484.27 | 21596.64 | 0.52
> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 11616.88 | 11099.73 | -4.45 | 11188.29 | 10737.68 | -4.03
> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 5872.72 | 5579.12 | -5.00 | 5784.05 | 5454.57 | -5.70
> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 22017.83 | 20817.97 | -5.45 | 21934.65 | 21356.90 | -2.63
> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 11414.27 | 11044.86 | -3.24 | 11454.35 | 11140.34 | -2.74
> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 5786.64 | 5634.05 | -2.64 | 5724.93 | 5639.99 | -1.48
> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 21754.77 | 21466.01 | -1.33 | 21140.67 | 21970.03 | 3.92
> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 11676.46 | 11358.64 | -2.72 | 11204.90 | 11213.48 | 0.08
> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 5728.20 | 5772.49 | 0.77 | 5594.33 | 5544.25 | -0.90
> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 30247.03 | 30179.41 | -0.22 | 1538.75 | 3975.82 | 158.38
> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 15988.73 | 15621.42 | -2.30 | 776.04 | 1910.91 | 146.24
> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 8115.84 | 8025.28 | -1.12 | 389.12 | 984.46 | 152.99
> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 30110.91 | 30200.69 | 0.30 | 1532.49 | 3983.77 | 159.95
> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 15957.90 | 15690.73 | -1.67 | 774.90 | 1931.00 | 149.19
> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 8113.26 | 8037.93 | -0.93 | 391.90 | 965.53 | 146.37
> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 29816.97 | 29891.54 | 0.25 | 1538.12 | 3881.93 | 152.38
> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 15405.95 | 15619.17 | 1.38 | 762.49 | 1871.00 | 145.38
> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 7919.80 | 7957.35 | 0.47 | 393.63 | 972.49 | 147.06

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8266054: Removing redundant teat templates.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3720/files
  - new: https://git.openjdk.java.net/jdk/pull/3720/files/8042aa23..ef46c0a8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3720&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3720&range=03-04

  Stats: 37 lines in 4 files changed: 0 ins; 37 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3720.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3720/head:pull/3720

PR: https://git.openjdk.java.net/jdk/pull/3720

From jbhateja at openjdk.java.net  Sat May  8 05:54:41 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sat, 8 May 2021 05:54:41 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 May 2021 18:31:15 GMT, Jatin Bhateja  wrote:

>> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
>> 
>>     vec1 = lanewise(VectorOperators.LSHL, n)
>>     vec2 = lanewise(VectorOperators.LSHR, n)
>>     res = lanewise(VectorOperations.OR, vec1 , vec2)
>> 
>> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
>> 
>> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
>> 
>> Please find below the performance data for included JMH benchmark.
>> Machine:  Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz)
>> 
>> 
>> Benchmark | (TESTSIZE) | Shift | Baseline AVX3 (ops/ms) | Withopt? AVX3 (ops/ms) | Gain % | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain %
>> -- | -- | -- | -- | -- | -- | -- | -- | --
>> ? | ? | ? | ? | ? | ? | ? | ? | ?
>> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 17223.35 | 17094.69 | -0.75 | 17008.32 | 17488.06 | 2.82
>> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 8944.98 | 8811.34 | -1.49 | 8878.17 | 9218.68 | 3.84
>> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 17195.75 | 17137.32 | -0.34 | 16789.01 | 17780.34 | 5.90
>> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 9052.67 | 8838.60 | -2.36 | 8814.62 | 9206.01 | 4.44
>> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 17100.19 | 16950.64 | -0.87 | 16827.73 | 17720.37 | 5.30
>> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 9079.95 | 8471.26 | -6.70 | 8888.44 | 9167.68 | 3.14
>> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 21231.33 | 21513.08 | 1.33 | 21824.51 | 21479.48 | -1.58
>> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 11103.62 | 11180.16 | 0.69 | 11173.67 | 11529.22 | 3.18
>> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 21119.14 | 21552.04 | 2.05 | 21693.05 | 21915.37 | 1.02
>> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 11048.68 | 11094.20 | 0.41 | 11049.90 | 11439.07 | 3.52
>> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 21506.31 | 21391.41 | -0.53 | 21263.18 | 21986.29 | 3.40
>> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 11056.12 | 11232.78 | 1.60 | 10941.59 | 11397.09 | 4.16
>> RotateBenchmark.testRotateLeftB | 512.00 | 7.00 | 17976.56 | 18180.85 | 1.14 | 1212.26 | 2533.34 | 108.98
>> RotateBenchmark.testRotateLeftB | 512.00 | 15.00 | 17553.70 | 18219.07 | 3.79 | 1256.73 | 2537.41 | 101.91
>> RotateBenchmark.testRotateLeftB | 512.00 | 31.00 | 17618.03 | 17738.15 | 0.68 | 1214.69 | 2533.83 | 108.60
>> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 7258.87 | 7468.88 | 2.89 | 7115.12 | 7117.26 | 0.03
>> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 3586.65 | 3950.85 | 10.15 | 3532.17 | 3595.80 | 1.80
>> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 1835.07 | 1999.68 | 8.97 | 1789.90 | 1819.93 | 1.68
>> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 7273.36 | 7410.91 | 1.89 | 7198.60 | 6994.79 | -2.83
>> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 3674.98 | 3926.27 | 6.84 | 3549.90 | 3755.09 | 5.78
>> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 1840.94 | 1882.25 | 2.24 | 1801.56 | 1872.89 | 3.96
>> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 7457.11 | 7361.48 | -1.28 | 6975.33 | 7385.94 | 5.89
>> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 3570.74 | 3929.30 | 10.04 | 3635.37 | 3736.67 | 2.79
>> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 1902.32 | 1960.46 | 3.06 | 1812.32 | 1813.88 | 0.09
>> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 11174.24 | 12044.52 | 7.79 | 11509.87 | 11273.44 | -2.05
>> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 5981.47 | 6073.70 | 1.54 | 5593.66 | 5661.93 | 1.22
>> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 2932.49 | 3069.54 | 4.67 | 2950.86 | 2892.42 | -1.98
>> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 11764.11 | 12098.63 | 2.84 | 11069.52 | 11476.93 | 3.68
>> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 5855.20 | 6080.40 | 3.85 | 5919.11 | 5607.04 | -5.27
>> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 2989.05 | 3048.56 | 1.99 | 2902.63 | 2821.83 | -2.78
>> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 11652.84 | 11965.40 | 2.68 | 11525.62 | 11459.83 | -0.57
>> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 5851.82 | 6164.94 | 5.35 | 5882.60 | 5842.30 | -0.69
>> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 3015.99 | 3043.79 | 0.92 | 2963.71 | 2947.97 | -0.53
>> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 16029.15 | 16189.79 | 1.00 | 860.43 | 2339.32 | 171.88
>> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 8078.25 | 8081.84 | 0.04 | 427.39 | 1147.92 | 168.59
>> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 4021.49 | 4294.03 | 6.78 | 209.25 | 582.28 | 178.27
>> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 15912.98 | 16329.03 | 2.61 | 848.23 | 2296.78 | 170.77
>> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 8054.10 | 8306.37 | 3.13 | 429.93 | 1146.90 | 166.77
>> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 4102.58 | 4071.08 | -0.77 | 217.86 | 582.20 | 167.24
>> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 16177.79 | 16287.85 | 0.68 | 857.84 | 2243.15 | 161.49
>> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 8187.47 | 8410.48 | 2.72 | 434.60 | 1128.20 | 159.60
>> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 4109.15 | 4233.80 | 3.03 | 208.71 | 572.43 | 174.27
>> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 3755.09 | 3930.29 | 4.67 | 3604.19 | 3598.47 | -0.16
>> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 1829.03 | 1957.39 | 7.02 | 1833.95 | 1808.38 | -1.39
>> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 915.35 | 970.55 | 6.03 | 916.25 | 899.08 | -1.87
>> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 3664.85 | 3812.26 | 4.02 | 3629.37 | 3579.23 | -1.38
>> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 1829.51 | 1877.76 | 2.64 | 1781.05 | 1807.57 | 1.49
>> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 913.37 | 953.42 | 4.38 | 912.26 | 908.73 | -0.39
>> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 3648.45 | 3899.20 | 6.87 | 3552.67 | 3581.04 | 0.80
>> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 1816.50 | 1959.68 | 7.88 | 1820.88 | 1819.71 | -0.06
>> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 901.05 | 955.13 | 6.00 | 913.74 | 907.90 | -0.64
>> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 5850.99 | 6108.64 | 4.40 | 5882.65 | 5755.21 | -2.17
>> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 2962.21 | 3060.47 | 3.32 | 2955.20 | 2909.18 | -1.56
>> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 1480.46 | 1534.72 | 3.66 | 1467.78 | 1430.60 | -2.53
>> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 5858.23 | 6047.51 | 3.23 | 5770.02 | 5773.19 | 0.05
>> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 2951.49 | 3096.53 | 4.91 | 2885.21 | 2899.31 | 0.49
>> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 1486.26 | 1527.94 | 2.80 | 1441.93 | 1454.25 | 0.85
>> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 5873.21 | 6089.75 | 3.69 | 5767.58 | 5664.11 | -1.79
>> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 2969.67 | 3081.39 | 3.76 | 2878.50 | 2905.86 | 0.95
>> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 1452.21 | 1520.03 | 4.67 | 1430.30 | 1485.63 | 3.87
>> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 8088.65 | 8443.63 | 4.39 | 455.67 | 1226.33 | 169.13
>> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 4011.95 | 4120.25 | 2.70 | 229.77 | 619.87 | 169.77
>> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 2090.57 | 2109.53 | 0.91 | 115.21 | 310.36 | 169.37
>> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 8166.84 | 8557.28 | 4.78 | 457.67 | 1242.86 | 171.56
>> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 4137.02 | 4287.95 | 3.65 | 227.26 | 624.80 | 174.93
>> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 2095.01 | 2102.86 | 0.37 | 114.26 | 310.83 | 172.03
>> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 8082.68 | 8400.56 | 3.93 | 459.59 | 1230.07 | 167.64
>> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 4047.67 | 4147.58 | 2.47 | 229.01 | 606.38 | 164.78
>> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 2086.83 | 2126.72 | 1.91 | 111.93 | 305.66 | 173.08
>> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 13597.19 | 13255.09 | -2.52 | 13818.39 | 13242.40 | -4.17
>> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 7028.26 | 6826.59 | -2.87 | 6765.15 | 6907.87 | 2.11
>> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 3570.40 | 3468.01 | -2.87 | 3449.66 | 3533.50 | 2.43
>> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 13615.99 | 13464.40 | -1.11 | 13330.02 | 13870.57 | 4.06
>> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 7043.31 | 6763.34 | -3.97 | 6928.88 | 7063.57 | 1.94
>> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 3495.12 | 3537.62 | 1.22 | 3503.41 | 3457.67 | -1.31
>> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 13591.66 | 13665.84 | 0.55 | 13773.27 | 13126.08 | -4.70
>> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 7027.08 | 7011.24 | -0.23 | 6974.98 | 6815.50 | -2.29
>> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 3568.28 | 3569.62 | 0.04 | 3580.67 | 3463.58 | -3.27
>> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 21154.03 | 21416.32 | 1.24 | 21187.01 | 21401.61 | 1.01
>> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 11194.24 | 10865.47 | -2.94 | 11063.19 | 10977.60 | -0.77
>> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 5797.80 | 5523.94 | -4.72 | 5654.63 | 5468.78 | -3.29
>> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 21333.89 | 21412.74 | 0.37 | 21610.94 | 20908.96 | -3.25
>> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 11327.07 | 11113.48 | -1.89 | 11148.25 | 10678.14 | -4.22
>> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 5810.69 | 5569.72 | -4.15 | 5663.26 | 5618.87 | -0.78
>> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 21753.20 | 21198.43 | -2.55 | 21567.90 | 21929.81 | 1.68
>> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 11517.08 | 11039.64 | -4.15 | 11103.08 | 10871.59 | -2.08
>> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 5897.16 | 5606.75 | -4.92 | 5459.87 | 5604.12 | 2.64
>> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 29748.53 | 28883.73 | -2.91 | 1549.02 | 3928.53 | 153.61
>> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 15197.09 | 15878.19 | 4.48 | 772.59 | 1924.35 | 149.08
>> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 8046.30 | 8081.19 | 0.43 | 388.11 | 990.28 | 155.16
>> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 30618.04 | 29419.19 | -3.92 | 1524.22 | 3915.97 | 156.92
>> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 15854.43 | 15846.37 | -0.05 | 766.09 | 1953.60 | 155.01
>> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 7814.77 | 7899.30 | 1.08 | 390.82 | 970.37 | 148.29
>> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 29596.82 | 28538.69 | -3.58 | 1530.45 | 3906.91 | 155.28
>> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 15662.48 | 15849.25 | 1.19 | 778.08 | 1934.31 | 148.60
>> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 8121.14 | 7758.59 | -4.46 | 392.78 | 959.73 | 144.34
>> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 17465.84 | 17069.34 | -2.27 | 16849.73 | 17842.08 | 5.89
>> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 9049.19 | 8864.15 | -2.04 | 8786.67 | 9105.34 | 3.63
>> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 17703.38 | 17070.98 | -3.57 | 16595.85 | 17784.68 | 7.16
>> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 9007.68 | 8817.41 | -2.11 | 8704.49 | 9185.87 | 5.53
>> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 17531.05 | 16983.40 | -3.12 | 16947.69 | 17655.40 | 4.18
>> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 8986.30 | 8794.15 | -2.14 | 8816.62 | 9225.95 | 4.64
>> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 21293.95 | 21506.74 | 1.00 | 21163.29 | 21854.03 | 3.26
>> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 11258.47 | 11072.92 | -1.65 | 11118.12 | 11338.96 | 1.99
>> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 21253.36 | 21292.37 | 0.18 | 21224.39 | 21763.88 | 2.54
>> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 11064.80 | 11198.35 | 1.21 | 10960.98 | 11294.14 | 3.04
>> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 21358.14 | 21346.21 | -0.06 | 21487.25 | 21854.42 | 1.71
>> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 11045.61 | 11208.26 | 1.47 | 10907.03 | 11415.18 | 4.66
>> RotateBenchmark.testRotateRightB | 512.00 | 7.00 | 17898.61 | 18307.54 | 2.28 | 1214.65 | 2546.64 | 109.66
>> RotateBenchmark.testRotateRightB | 512.00 | 15.00 | 17909.25 | 18242.51 | 1.86 | 1215.05 | 2563.98 | 111.02
>> RotateBenchmark.testRotateRightB | 512.00 | 31.00 | 17883.35 | 17928.44 | 0.25 | 1220.77 | 2543.30 | 108.34
>> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 7139.97 | 7626.72 | 6.82 | 6994.86 | 7075.65 | 1.15
>> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 3657.37 | 3898.34 | 6.59 | 3617.06 | 3576.12 | -1.13
>> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 1804.26 | 1969.19 | 9.14 | 1796.62 | 1858.84 | 3.46
>> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 7404.31 | 7760.09 | 4.80 | 7036.77 | 7401.52 | 5.18
>> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 3600.52 | 3956.35 | 9.88 | 3595.28 | 3560.36 | -0.97
>> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 1813.32 | 1966.41 | 8.44 | 1839.95 | 1852.53 | 0.68
>> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 7118.48 | 7724.81 | 8.52 | 7151.56 | 7021.09 | -1.82
>> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 3529.70 | 3881.63 | 9.97 | 3623.08 | 3601.01 | -0.61
>> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 1823.61 | 1961.34 | 7.55 | 1786.86 | 1748.85 | -2.13
>> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 11697.98 | 11835.25 | 1.17 | 11513.16 | 11184.87 | -2.85
>> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 5890.11 | 6102.57 | 3.61 | 5658.79 | 5696.08 | 0.66
>> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 2964.94 | 3070.26 | 3.55 | 2945.00 | 2962.08 | 0.58
>> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 11562.51 | 12151.29 | 5.09 | 11404.17 | 11120.28 | -2.49
>> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 5702.93 | 6130.57 | 7.50 | 5799.54 | 5779.08 | -0.35
>> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 2861.96 | 3051.44 | 6.62 | 2943.99 | 2860.65 | -2.83
>> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 11203.13 | 11710.59 | 4.53 | 11363.18 | 11112.16 | -2.21
>> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 5893.97 | 6070.71 | 3.00 | 5776.67 | 5648.84 | -2.21
>> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 2971.83 | 3046.76 | 2.52 | 2903.35 | 2833.88 | -2.39
>> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 16064.71 | 15851.35 | -1.33 | 861.93 | 2256.88 | 161.84
>> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 7916.80 | 8462.65 | 6.89 | 430.23 | 1147.30 | 166.67
>> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 4104.64 | 4068.28 | -0.89 | 216.30 | 572.86 | 164.84
>> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 16133.09 | 16281.59 | 0.92 | 856.36 | 2229.58 | 160.35
>> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 8127.26 | 8117.59 | -0.12 | 419.16 | 1176.42 | 180.66
>> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 4080.11 | 4063.26 | -0.41 | 218.32 | 571.93 | 161.97
>> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 15834.26 | 16314.64 | 3.03 | 865.96 | 2297.74 | 165.34
>> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 7965.62 | 8270.48 | 3.83 | 428.55 | 1148.87 | 168.08
>> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 4161.69 | 4034.76 | -3.05 | 215.63 | 570.19 | 164.43
>> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 3556.70 | 3877.08 | 9.01 | 3596.46 | 3558.32 | -1.06
>> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 1772.93 | 1993.86 | 12.46 | 1856.79 | 1783.22 | -3.96
>> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 908.66 | 1000.37 | 10.09 | 944.79 | 922.91 | -2.32
>> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 3742.44 | 3748.41 | 0.16 | 3788.07 | 3570.67 | -5.74
>> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 1817.53 | 1985.69 | 9.25 | 1892.38 | 1833.16 | -3.13
>> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 941.03 | 952.68 | 1.24 | 915.79 | 910.21 | -0.61
>> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 3649.48 | 3896.56 | 6.77 | 3637.59 | 3557.53 | -2.20
>> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 1840.12 | 1997.19 | 8.54 | 1821.47 | 1799.82 | -1.19
>> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 901.33 | 995.67 | 10.47 | 909.20 | 902.73 | -0.71
>> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 5789.93 | 5960.54 | 2.95 | 5758.14 | 5736.30 | -0.38
>> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 2963.20 | 3063.30 | 3.38 | 2943.48 | 2833.84 | -3.72
>> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 1501.81 | 1510.23 | 0.56 | 1463.85 | 1462.26 | -0.11
>> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 5870.05 | 5951.43 | 1.39 | 5794.74 | 5604.58 | -3.28
>> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 2971.36 | 3047.00 | 2.55 | 2931.19 | 2907.30 | -0.82
>> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 1473.97 | 1530.54 | 3.84 | 1473.45 | 1442.40 | -2.11
>> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 5858.08 | 6080.49 | 3.80 | 5863.69 | 5549.85 | -5.35
>> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 2916.24 | 3045.77 | 4.44 | 2981.59 | 2815.07 | -5.58
>> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 1441.20 | 1531.56 | 6.27 | 1492.47 | 1473.25 | -1.29
>> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 8147.24 | 8310.05 | 2.00 | 469.45 | 1235.21 | 163.12
>> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 4142.95 | 4258.86 | 2.80 | 234.14 | 615.52 | 162.88
>> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 2095.48 | 2087.20 | -0.40 | 113.55 | 311.19 | 174.05
>> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 8222.94 | 8246.58 | 0.29 | 458.91 | 1244.32 | 171.15
>> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 4160.04 | 4226.46 | 1.60 | 227.78 | 625.38 | 174.56
>> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 2064.63 | 2162.44 | 4.74 | 113.27 | 314.15 | 177.36
>> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 8157.94 | 8466.90 | 3.79 | 450.26 | 1221.90 | 171.37
>> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 4039.74 | 4283.33 | 6.03 | 224.82 | 612.68 | 172.53
>> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 2066.88 | 2147.51 | 3.90 | 110.97 | 303.43 | 173.42
>> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 13548.39 | 13245.87 | -2.23 | 13490.93 | 13084.76 | -3.01
>> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 7020.16 | 6768.85 | -3.58 | 6991.39 | 7044.32 | 0.76
>> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 3550.50 | 3505.19 | -1.28 | 3507.12 | 3612.86 | 3.01
>> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 13743.43 | 13325.44 | -3.04 | 13696.15 | 13255.80 | -3.22
>> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 6856.02 | 6969.18 | 1.65 | 6886.29 | 6834.12 | -0.76
>> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 3569.53 | 3492.76 | -2.15 | 3539.02 | 3470.02 | -1.95
>> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 13704.18 | 13495.07 | -1.53 | 13649.14 | 13583.87 | -0.48
>> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 7011.77 | 6953.93 | -0.82 | 6978.28 | 6740.30 | -3.41
>> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 3591.62 | 3620.12 | 0.79 | 3502.04 | 3510.05 | 0.23
>> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 21950.71 | 22113.60 | 0.74 | 21484.27 | 21596.64 | 0.52
>> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 11616.88 | 11099.73 | -4.45 | 11188.29 | 10737.68 | -4.03
>> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 5872.72 | 5579.12 | -5.00 | 5784.05 | 5454.57 | -5.70
>> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 22017.83 | 20817.97 | -5.45 | 21934.65 | 21356.90 | -2.63
>> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 11414.27 | 11044.86 | -3.24 | 11454.35 | 11140.34 | -2.74
>> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 5786.64 | 5634.05 | -2.64 | 5724.93 | 5639.99 | -1.48
>> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 21754.77 | 21466.01 | -1.33 | 21140.67 | 21970.03 | 3.92
>> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 11676.46 | 11358.64 | -2.72 | 11204.90 | 11213.48 | 0.08
>> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 5728.20 | 5772.49 | 0.77 | 5594.33 | 5544.25 | -0.90
>> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 30247.03 | 30179.41 | -0.22 | 1538.75 | 3975.82 | 158.38
>> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 15988.73 | 15621.42 | -2.30 | 776.04 | 1910.91 | 146.24
>> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 8115.84 | 8025.28 | -1.12 | 389.12 | 984.46 | 152.99
>> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 30110.91 | 30200.69 | 0.30 | 1532.49 | 3983.77 | 159.95
>> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 15957.90 | 15690.73 | -1.67 | 774.90 | 1931.00 | 149.19
>> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 8113.26 | 8037.93 | -0.93 | 391.90 | 965.53 | 146.37
>> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 29816.97 | 29891.54 | 0.25 | 1538.12 | 3881.93 | 152.38
>> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 15405.95 | 15619.17 | 1.38 | 762.49 | 1871.00 | 145.38
>> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 7919.80 | 7957.35 | 0.47 | 393.63 | 972.49 | 147.06
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266054: Review comments resolution.

> Java code updates look good
> 
> I believe you can now remove the four "_-Rotate__.template" files now that you leverage exiting templates?
> 
> Also, i believe ancillary changes to `gen-template.sh` are no longer strictly required, now that we defer to method calls for ROL/ROR?

Thanks Paul, redundant files (missed in last check-in) have been removed and benchmark results with latest code updated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From alanb at openjdk.java.net  Sat May  8 07:17:19 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 8 May 2021 07:17:19 GMT
Subject: RFR: 8266774: System property values for stdout/err on Windows
 UTF-8
In-Reply-To: <9jYN7sQh6DrukhjCgUco9DmnHkAqw2W3kb3TlonGLeM=.0cccb7ae-ad98-4453-a0e5-15efa3c71ca1@github.com>
References: <9jYN7sQh6DrukhjCgUco9DmnHkAqw2W3kb3TlonGLeM=.0cccb7ae-ad98-4453-a0e5-15efa3c71ca1@github.com>
Message-ID: 

On Fri, 7 May 2021 22:46:08 GMT, Naoto Sato  wrote:

> Please review this small fix to Windows system property init code. This is leftover from the support for `Console.charset()` method, where it lacked to initialize `sun.stdout/err.encoding` to `UTF-8` for the code page `cp65001`.  The fix has been manually verified, but no automated test case is provided, as automatically setting `UTF-8` for the system locale on Windows test machine seems not possible.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3931

From winterhalter at openjdk.java.net  Sat May  8 09:51:46 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Sat, 8 May 2021 09:51:46 GMT
Subject: RFR: 8266598: Exception values for
 AnnotationTypeMismatchException are not always informative [v3]
In-Reply-To: 
References: 
Message-ID: 

> This improves the messages that are provided by `AnnotationTypeMismatchException`s. The message provided by AnnotationTypeMismatchExceptions is deliberately undefined such that this should not break any contract.

Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8266598: Exception values for AnnotationTypeMismatchException are not always informative

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3892/files
  - new: https://git.openjdk.java.net/jdk/pull/3892/files/57ab3721..9acdb5d0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3892&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3892&range=01-02

  Stats: 9 lines in 2 files changed: 3 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3892.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3892/head:pull/3892

PR: https://git.openjdk.java.net/jdk/pull/3892

From psandoz at openjdk.java.net  Sat May  8 15:43:56 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Sat, 8 May 2021 15:43:56 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 8 May 2021 05:54:38 GMT, Jatin Bhateja  wrote:

>> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
>> 
>>     vec1 = lanewise(VectorOperators.LSHL, n)
>>     vec2 = lanewise(VectorOperators.LSHR, n)
>>     res = lanewise(VectorOperations.OR, vec1 , vec2)
>> 
>> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
>> 
>> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
>> 
>> Please find below the performance data for included JMH benchmark.
>> Machine:  Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz)
>> 
>> 
>> Benchmark | (TESTSIZE) | Shift | Baseline AVX3 (ops/ms) | Withopt? AVX3 (ops/ms) | Gain % | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain %
>> -- | -- | -- | -- | -- | -- | -- | -- | --
>> ? | ? | ? | ? | ? | ? | ? | ? | ?
>> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 17223.35 | 17094.69 | -0.75 | 17008.32 | 17488.06 | 2.82
>> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 8944.98 | 8811.34 | -1.49 | 8878.17 | 9218.68 | 3.84
>> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 17195.75 | 17137.32 | -0.34 | 16789.01 | 17780.34 | 5.90
>> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 9052.67 | 8838.60 | -2.36 | 8814.62 | 9206.01 | 4.44
>> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 17100.19 | 16950.64 | -0.87 | 16827.73 | 17720.37 | 5.30
>> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 9079.95 | 8471.26 | -6.70 | 8888.44 | 9167.68 | 3.14
>> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 21231.33 | 21513.08 | 1.33 | 21824.51 | 21479.48 | -1.58
>> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 11103.62 | 11180.16 | 0.69 | 11173.67 | 11529.22 | 3.18
>> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 21119.14 | 21552.04 | 2.05 | 21693.05 | 21915.37 | 1.02
>> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 11048.68 | 11094.20 | 0.41 | 11049.90 | 11439.07 | 3.52
>> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 21506.31 | 21391.41 | -0.53 | 21263.18 | 21986.29 | 3.40
>> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 11056.12 | 11232.78 | 1.60 | 10941.59 | 11397.09 | 4.16
>> RotateBenchmark.testRotateLeftB | 512.00 | 7.00 | 17976.56 | 18180.85 | 1.14 | 1212.26 | 2533.34 | 108.98
>> RotateBenchmark.testRotateLeftB | 512.00 | 15.00 | 17553.70 | 18219.07 | 3.79 | 1256.73 | 2537.41 | 101.91
>> RotateBenchmark.testRotateLeftB | 512.00 | 31.00 | 17618.03 | 17738.15 | 0.68 | 1214.69 | 2533.83 | 108.60
>> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 7258.87 | 7468.88 | 2.89 | 7115.12 | 7117.26 | 0.03
>> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 3586.65 | 3950.85 | 10.15 | 3532.17 | 3595.80 | 1.80
>> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 1835.07 | 1999.68 | 8.97 | 1789.90 | 1819.93 | 1.68
>> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 7273.36 | 7410.91 | 1.89 | 7198.60 | 6994.79 | -2.83
>> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 3674.98 | 3926.27 | 6.84 | 3549.90 | 3755.09 | 5.78
>> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 1840.94 | 1882.25 | 2.24 | 1801.56 | 1872.89 | 3.96
>> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 7457.11 | 7361.48 | -1.28 | 6975.33 | 7385.94 | 5.89
>> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 3570.74 | 3929.30 | 10.04 | 3635.37 | 3736.67 | 2.79
>> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 1902.32 | 1960.46 | 3.06 | 1812.32 | 1813.88 | 0.09
>> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 11174.24 | 12044.52 | 7.79 | 11509.87 | 11273.44 | -2.05
>> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 5981.47 | 6073.70 | 1.54 | 5593.66 | 5661.93 | 1.22
>> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 2932.49 | 3069.54 | 4.67 | 2950.86 | 2892.42 | -1.98
>> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 11764.11 | 12098.63 | 2.84 | 11069.52 | 11476.93 | 3.68
>> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 5855.20 | 6080.40 | 3.85 | 5919.11 | 5607.04 | -5.27
>> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 2989.05 | 3048.56 | 1.99 | 2902.63 | 2821.83 | -2.78
>> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 11652.84 | 11965.40 | 2.68 | 11525.62 | 11459.83 | -0.57
>> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 5851.82 | 6164.94 | 5.35 | 5882.60 | 5842.30 | -0.69
>> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 3015.99 | 3043.79 | 0.92 | 2963.71 | 2947.97 | -0.53
>> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 16029.15 | 16189.79 | 1.00 | 860.43 | 2339.32 | 171.88
>> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 8078.25 | 8081.84 | 0.04 | 427.39 | 1147.92 | 168.59
>> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 4021.49 | 4294.03 | 6.78 | 209.25 | 582.28 | 178.27
>> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 15912.98 | 16329.03 | 2.61 | 848.23 | 2296.78 | 170.77
>> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 8054.10 | 8306.37 | 3.13 | 429.93 | 1146.90 | 166.77
>> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 4102.58 | 4071.08 | -0.77 | 217.86 | 582.20 | 167.24
>> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 16177.79 | 16287.85 | 0.68 | 857.84 | 2243.15 | 161.49
>> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 8187.47 | 8410.48 | 2.72 | 434.60 | 1128.20 | 159.60
>> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 4109.15 | 4233.80 | 3.03 | 208.71 | 572.43 | 174.27
>> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 3755.09 | 3930.29 | 4.67 | 3604.19 | 3598.47 | -0.16
>> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 1829.03 | 1957.39 | 7.02 | 1833.95 | 1808.38 | -1.39
>> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 915.35 | 970.55 | 6.03 | 916.25 | 899.08 | -1.87
>> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 3664.85 | 3812.26 | 4.02 | 3629.37 | 3579.23 | -1.38
>> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 1829.51 | 1877.76 | 2.64 | 1781.05 | 1807.57 | 1.49
>> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 913.37 | 953.42 | 4.38 | 912.26 | 908.73 | -0.39
>> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 3648.45 | 3899.20 | 6.87 | 3552.67 | 3581.04 | 0.80
>> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 1816.50 | 1959.68 | 7.88 | 1820.88 | 1819.71 | -0.06
>> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 901.05 | 955.13 | 6.00 | 913.74 | 907.90 | -0.64
>> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 5850.99 | 6108.64 | 4.40 | 5882.65 | 5755.21 | -2.17
>> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 2962.21 | 3060.47 | 3.32 | 2955.20 | 2909.18 | -1.56
>> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 1480.46 | 1534.72 | 3.66 | 1467.78 | 1430.60 | -2.53
>> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 5858.23 | 6047.51 | 3.23 | 5770.02 | 5773.19 | 0.05
>> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 2951.49 | 3096.53 | 4.91 | 2885.21 | 2899.31 | 0.49
>> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 1486.26 | 1527.94 | 2.80 | 1441.93 | 1454.25 | 0.85
>> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 5873.21 | 6089.75 | 3.69 | 5767.58 | 5664.11 | -1.79
>> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 2969.67 | 3081.39 | 3.76 | 2878.50 | 2905.86 | 0.95
>> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 1452.21 | 1520.03 | 4.67 | 1430.30 | 1485.63 | 3.87
>> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 8088.65 | 8443.63 | 4.39 | 455.67 | 1226.33 | 169.13
>> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 4011.95 | 4120.25 | 2.70 | 229.77 | 619.87 | 169.77
>> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 2090.57 | 2109.53 | 0.91 | 115.21 | 310.36 | 169.37
>> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 8166.84 | 8557.28 | 4.78 | 457.67 | 1242.86 | 171.56
>> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 4137.02 | 4287.95 | 3.65 | 227.26 | 624.80 | 174.93
>> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 2095.01 | 2102.86 | 0.37 | 114.26 | 310.83 | 172.03
>> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 8082.68 | 8400.56 | 3.93 | 459.59 | 1230.07 | 167.64
>> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 4047.67 | 4147.58 | 2.47 | 229.01 | 606.38 | 164.78
>> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 2086.83 | 2126.72 | 1.91 | 111.93 | 305.66 | 173.08
>> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 13597.19 | 13255.09 | -2.52 | 13818.39 | 13242.40 | -4.17
>> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 7028.26 | 6826.59 | -2.87 | 6765.15 | 6907.87 | 2.11
>> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 3570.40 | 3468.01 | -2.87 | 3449.66 | 3533.50 | 2.43
>> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 13615.99 | 13464.40 | -1.11 | 13330.02 | 13870.57 | 4.06
>> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 7043.31 | 6763.34 | -3.97 | 6928.88 | 7063.57 | 1.94
>> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 3495.12 | 3537.62 | 1.22 | 3503.41 | 3457.67 | -1.31
>> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 13591.66 | 13665.84 | 0.55 | 13773.27 | 13126.08 | -4.70
>> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 7027.08 | 7011.24 | -0.23 | 6974.98 | 6815.50 | -2.29
>> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 3568.28 | 3569.62 | 0.04 | 3580.67 | 3463.58 | -3.27
>> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 21154.03 | 21416.32 | 1.24 | 21187.01 | 21401.61 | 1.01
>> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 11194.24 | 10865.47 | -2.94 | 11063.19 | 10977.60 | -0.77
>> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 5797.80 | 5523.94 | -4.72 | 5654.63 | 5468.78 | -3.29
>> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 21333.89 | 21412.74 | 0.37 | 21610.94 | 20908.96 | -3.25
>> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 11327.07 | 11113.48 | -1.89 | 11148.25 | 10678.14 | -4.22
>> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 5810.69 | 5569.72 | -4.15 | 5663.26 | 5618.87 | -0.78
>> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 21753.20 | 21198.43 | -2.55 | 21567.90 | 21929.81 | 1.68
>> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 11517.08 | 11039.64 | -4.15 | 11103.08 | 10871.59 | -2.08
>> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 5897.16 | 5606.75 | -4.92 | 5459.87 | 5604.12 | 2.64
>> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 29748.53 | 28883.73 | -2.91 | 1549.02 | 3928.53 | 153.61
>> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 15197.09 | 15878.19 | 4.48 | 772.59 | 1924.35 | 149.08
>> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 8046.30 | 8081.19 | 0.43 | 388.11 | 990.28 | 155.16
>> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 30618.04 | 29419.19 | -3.92 | 1524.22 | 3915.97 | 156.92
>> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 15854.43 | 15846.37 | -0.05 | 766.09 | 1953.60 | 155.01
>> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 7814.77 | 7899.30 | 1.08 | 390.82 | 970.37 | 148.29
>> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 29596.82 | 28538.69 | -3.58 | 1530.45 | 3906.91 | 155.28
>> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 15662.48 | 15849.25 | 1.19 | 778.08 | 1934.31 | 148.60
>> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 8121.14 | 7758.59 | -4.46 | 392.78 | 959.73 | 144.34
>> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 17465.84 | 17069.34 | -2.27 | 16849.73 | 17842.08 | 5.89
>> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 9049.19 | 8864.15 | -2.04 | 8786.67 | 9105.34 | 3.63
>> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 17703.38 | 17070.98 | -3.57 | 16595.85 | 17784.68 | 7.16
>> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 9007.68 | 8817.41 | -2.11 | 8704.49 | 9185.87 | 5.53
>> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 17531.05 | 16983.40 | -3.12 | 16947.69 | 17655.40 | 4.18
>> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 8986.30 | 8794.15 | -2.14 | 8816.62 | 9225.95 | 4.64
>> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 21293.95 | 21506.74 | 1.00 | 21163.29 | 21854.03 | 3.26
>> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 11258.47 | 11072.92 | -1.65 | 11118.12 | 11338.96 | 1.99
>> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 21253.36 | 21292.37 | 0.18 | 21224.39 | 21763.88 | 2.54
>> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 11064.80 | 11198.35 | 1.21 | 10960.98 | 11294.14 | 3.04
>> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 21358.14 | 21346.21 | -0.06 | 21487.25 | 21854.42 | 1.71
>> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 11045.61 | 11208.26 | 1.47 | 10907.03 | 11415.18 | 4.66
>> RotateBenchmark.testRotateRightB | 512.00 | 7.00 | 17898.61 | 18307.54 | 2.28 | 1214.65 | 2546.64 | 109.66
>> RotateBenchmark.testRotateRightB | 512.00 | 15.00 | 17909.25 | 18242.51 | 1.86 | 1215.05 | 2563.98 | 111.02
>> RotateBenchmark.testRotateRightB | 512.00 | 31.00 | 17883.35 | 17928.44 | 0.25 | 1220.77 | 2543.30 | 108.34
>> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 7139.97 | 7626.72 | 6.82 | 6994.86 | 7075.65 | 1.15
>> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 3657.37 | 3898.34 | 6.59 | 3617.06 | 3576.12 | -1.13
>> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 1804.26 | 1969.19 | 9.14 | 1796.62 | 1858.84 | 3.46
>> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 7404.31 | 7760.09 | 4.80 | 7036.77 | 7401.52 | 5.18
>> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 3600.52 | 3956.35 | 9.88 | 3595.28 | 3560.36 | -0.97
>> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 1813.32 | 1966.41 | 8.44 | 1839.95 | 1852.53 | 0.68
>> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 7118.48 | 7724.81 | 8.52 | 7151.56 | 7021.09 | -1.82
>> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 3529.70 | 3881.63 | 9.97 | 3623.08 | 3601.01 | -0.61
>> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 1823.61 | 1961.34 | 7.55 | 1786.86 | 1748.85 | -2.13
>> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 11697.98 | 11835.25 | 1.17 | 11513.16 | 11184.87 | -2.85
>> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 5890.11 | 6102.57 | 3.61 | 5658.79 | 5696.08 | 0.66
>> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 2964.94 | 3070.26 | 3.55 | 2945.00 | 2962.08 | 0.58
>> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 11562.51 | 12151.29 | 5.09 | 11404.17 | 11120.28 | -2.49
>> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 5702.93 | 6130.57 | 7.50 | 5799.54 | 5779.08 | -0.35
>> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 2861.96 | 3051.44 | 6.62 | 2943.99 | 2860.65 | -2.83
>> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 11203.13 | 11710.59 | 4.53 | 11363.18 | 11112.16 | -2.21
>> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 5893.97 | 6070.71 | 3.00 | 5776.67 | 5648.84 | -2.21
>> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 2971.83 | 3046.76 | 2.52 | 2903.35 | 2833.88 | -2.39
>> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 16064.71 | 15851.35 | -1.33 | 861.93 | 2256.88 | 161.84
>> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 7916.80 | 8462.65 | 6.89 | 430.23 | 1147.30 | 166.67
>> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 4104.64 | 4068.28 | -0.89 | 216.30 | 572.86 | 164.84
>> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 16133.09 | 16281.59 | 0.92 | 856.36 | 2229.58 | 160.35
>> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 8127.26 | 8117.59 | -0.12 | 419.16 | 1176.42 | 180.66
>> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 4080.11 | 4063.26 | -0.41 | 218.32 | 571.93 | 161.97
>> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 15834.26 | 16314.64 | 3.03 | 865.96 | 2297.74 | 165.34
>> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 7965.62 | 8270.48 | 3.83 | 428.55 | 1148.87 | 168.08
>> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 4161.69 | 4034.76 | -3.05 | 215.63 | 570.19 | 164.43
>> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 3556.70 | 3877.08 | 9.01 | 3596.46 | 3558.32 | -1.06
>> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 1772.93 | 1993.86 | 12.46 | 1856.79 | 1783.22 | -3.96
>> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 908.66 | 1000.37 | 10.09 | 944.79 | 922.91 | -2.32
>> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 3742.44 | 3748.41 | 0.16 | 3788.07 | 3570.67 | -5.74
>> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 1817.53 | 1985.69 | 9.25 | 1892.38 | 1833.16 | -3.13
>> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 941.03 | 952.68 | 1.24 | 915.79 | 910.21 | -0.61
>> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 3649.48 | 3896.56 | 6.77 | 3637.59 | 3557.53 | -2.20
>> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 1840.12 | 1997.19 | 8.54 | 1821.47 | 1799.82 | -1.19
>> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 901.33 | 995.67 | 10.47 | 909.20 | 902.73 | -0.71
>> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 5789.93 | 5960.54 | 2.95 | 5758.14 | 5736.30 | -0.38
>> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 2963.20 | 3063.30 | 3.38 | 2943.48 | 2833.84 | -3.72
>> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 1501.81 | 1510.23 | 0.56 | 1463.85 | 1462.26 | -0.11
>> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 5870.05 | 5951.43 | 1.39 | 5794.74 | 5604.58 | -3.28
>> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 2971.36 | 3047.00 | 2.55 | 2931.19 | 2907.30 | -0.82
>> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 1473.97 | 1530.54 | 3.84 | 1473.45 | 1442.40 | -2.11
>> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 5858.08 | 6080.49 | 3.80 | 5863.69 | 5549.85 | -5.35
>> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 2916.24 | 3045.77 | 4.44 | 2981.59 | 2815.07 | -5.58
>> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 1441.20 | 1531.56 | 6.27 | 1492.47 | 1473.25 | -1.29
>> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 8147.24 | 8310.05 | 2.00 | 469.45 | 1235.21 | 163.12
>> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 4142.95 | 4258.86 | 2.80 | 234.14 | 615.52 | 162.88
>> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 2095.48 | 2087.20 | -0.40 | 113.55 | 311.19 | 174.05
>> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 8222.94 | 8246.58 | 0.29 | 458.91 | 1244.32 | 171.15
>> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 4160.04 | 4226.46 | 1.60 | 227.78 | 625.38 | 174.56
>> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 2064.63 | 2162.44 | 4.74 | 113.27 | 314.15 | 177.36
>> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 8157.94 | 8466.90 | 3.79 | 450.26 | 1221.90 | 171.37
>> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 4039.74 | 4283.33 | 6.03 | 224.82 | 612.68 | 172.53
>> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 2066.88 | 2147.51 | 3.90 | 110.97 | 303.43 | 173.42
>> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 13548.39 | 13245.87 | -2.23 | 13490.93 | 13084.76 | -3.01
>> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 7020.16 | 6768.85 | -3.58 | 6991.39 | 7044.32 | 0.76
>> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 3550.50 | 3505.19 | -1.28 | 3507.12 | 3612.86 | 3.01
>> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 13743.43 | 13325.44 | -3.04 | 13696.15 | 13255.80 | -3.22
>> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 6856.02 | 6969.18 | 1.65 | 6886.29 | 6834.12 | -0.76
>> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 3569.53 | 3492.76 | -2.15 | 3539.02 | 3470.02 | -1.95
>> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 13704.18 | 13495.07 | -1.53 | 13649.14 | 13583.87 | -0.48
>> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 7011.77 | 6953.93 | -0.82 | 6978.28 | 6740.30 | -3.41
>> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 3591.62 | 3620.12 | 0.79 | 3502.04 | 3510.05 | 0.23
>> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 21950.71 | 22113.60 | 0.74 | 21484.27 | 21596.64 | 0.52
>> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 11616.88 | 11099.73 | -4.45 | 11188.29 | 10737.68 | -4.03
>> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 5872.72 | 5579.12 | -5.00 | 5784.05 | 5454.57 | -5.70
>> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 22017.83 | 20817.97 | -5.45 | 21934.65 | 21356.90 | -2.63
>> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 11414.27 | 11044.86 | -3.24 | 11454.35 | 11140.34 | -2.74
>> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 5786.64 | 5634.05 | -2.64 | 5724.93 | 5639.99 | -1.48
>> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 21754.77 | 21466.01 | -1.33 | 21140.67 | 21970.03 | 3.92
>> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 11676.46 | 11358.64 | -2.72 | 11204.90 | 11213.48 | 0.08
>> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 5728.20 | 5772.49 | 0.77 | 5594.33 | 5544.25 | -0.90
>> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 30247.03 | 30179.41 | -0.22 | 1538.75 | 3975.82 | 158.38
>> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 15988.73 | 15621.42 | -2.30 | 776.04 | 1910.91 | 146.24
>> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 8115.84 | 8025.28 | -1.12 | 389.12 | 984.46 | 152.99
>> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 30110.91 | 30200.69 | 0.30 | 1532.49 | 3983.77 | 159.95
>> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 15957.90 | 15690.73 | -1.67 | 774.90 | 1931.00 | 149.19
>> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 8113.26 | 8037.93 | -0.93 | 391.90 | 965.53 | 146.37
>> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 29816.97 | 29891.54 | 0.25 | 1538.12 | 3881.93 | 152.38
>> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 15405.95 | 15619.17 | 1.38 | 762.49 | 1871.00 | 145.38
>> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 7919.80 | 7957.35 | 0.47 | 393.63 | 972.49 | 147.06
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266054: Removing redundant teat templates.

Looks good. Someone from the HotSpot side needs to review related changes.

The way i read the perf numbers is that on non AVX512 systems the numbers are in the noise (no worse, no better), with significant improvement on AVX512.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3720

From 93q62q at gmail.com  Sat May  8 15:47:48 2021
From: 93q62q at gmail.com (Andrew Oliver)
Date: Sat, 8 May 2021 08:47:48 -0700
Subject: Proposal to add JavaScript platform to jpackage
In-Reply-To: <03adccfa-0253-ff1a-0620-9d5e3e925b96@oracle.com>
References: 
 <99221D16-7066-495F-8AA8-E828F31EB831@gmail.com>
 
 <03adccfa-0253-ff1a-0620-9d5e3e925b96@oracle.com>
Message-ID: 

Much of the feedback (public and private) from this proposal has focused on
integration with jpackage.  There is concern that jpackage is strictly for
platforms where the OpenJDK runtime is bundled with the class files in an
installer for distribution on that platform.  I have a couple of questions
for this list:

1. Is it the intent that jpackage _only_ be used for platforms where the
OpenJDK runtime is bundled, in whole or in part?  The descriptions from the
jpackage docs mentions taking a Java run-time image as input, but then says
it produces an application that "includes all the necessary dependencies":
"The jpackage tool will take as input a Java application and a Java
run-time image, and produce a Java application image that includes all the
necessary dependencies. It will be able to produce a native package in a
platform-specific format, such as an exe on Windows or a dmg on macOS."

In this case, the Java application will be converted to JavaScript, and the
required code to meet JLS semantics will be provided.  Since the runtime
binary (java.exe) isn't needed, it is not a necessary dependency and is
omitted.  The resulting native package is provided in a platform-specific
format (WAR or ZIP), as appropriate for a web application.  To me, this
certainly meets the letter of the jpackage description, but perhaps not the
spirit.  I'm interested in more feedback on this point.

2. If the answer to (1) above is 'yes', jpackage is only suitable if you
plan to bundle OpenJDK VM code, then I will propose a new tool, separate
from jpackage.  The tentative name is "jspackage".

The jspackage command will take as input a Java application, and produce a
web application that includes all of the necessary dependencies.  It will
produce a cross-platform web application bundle in either WAR or ZIP format.


On Mon, Apr 26, 2021 at 5:39 AM Kevin Rushforth 
wrote:

> Without commenting on the value proposition of what you propose to do, I
> am fairly certain that jpackage is not the way to do it. The job of
> jpackage is to take an application, bundle it with a Java Runtime, and
> create a native package / installer from it. What you are describing
> goes far beyond that. You are describing a new capability of the JDK
> that would take Java bytecode and compile it to run it on top of a
> JavaScript engine.
>
> > jpackage will use a JavaScript AOT compiler (TeaVM) to convert the Java
> > code to JavaScript, with the main class compiled to a JavaScript method
> > called 'main()'.
>
> This is a good indicator that your proposal isn't simply targeting a new
> platform that already exists, and for which there is a Java runtime that
> supports running on this platform.
>
> -- Kevin
>
>
> On 4/25/2021 5:10 PM, Andrew Oliver wrote:
> > While I agree it is a somewhat different platform than Linux, Mac, or
> > Windows, I do think the web is a platform worth targeting.  And when seen
> > through just a slightly different lens, it is more like the others than
> it
> > might first seem:
> >
> > On the platform:
> > * It is difficult for users to run Java bytecode or JARs directly
> > * Bytecode needs some form of transformation to operate efficiently
> > * Packaging into a platform-specific format is required for easy
> > distribution
> > * Without a packager tool, developers have to surmount significant
> > obstacles to distribute on the platform, reducing the appeal and adoption
> > of Java
> >
> > Yes, there are maven and gradle plugins available to allow Java to target
> > the JavaScript platform.  ( For example,
> > https://teavm.org/docs/intro/getting-started.html )
> >
> > However, for many users a browser-friendly solution with a small number
> of
> > dependencies is going to be the only option.  Take, for example, new
> users,
> > students, and educational settings.  In many cases, programming
> assignments
> > are required to be posted on the web.  If the JDK could target
> > self-contained web applications, as per this proposal, students could
> > easily post their assignments for the whole class to see.  This would be
> > much more reasonable than asking students to learn Java and maven and POM
> > files (and I'm saying that as a fan of maven).
> >
> > Lest people misinterpret the above as suggesting this JEP is useful only
> in
> > an educational context, many business projects these days need to be web
> > applications.  Users are often unwilling or unable to download and
> install
> > applications for short, quick, or one-off transactions.  Thus there is a
> > large market for projects that absolutely require a web presence.  This
> JEP
> > would help illustrate how Java could be used even for front-end web
> > development.  Yes, large-scale projects would likely use maven or gradle.
> > But for quick proofs-of-concept, little could make it easier to
> demonstrate
> > the ability to do front-end development in Java then easily packaging a
> > Java code into a ZIP and deploying on any web server (or a WAR on an
> > application server, if desired).
> >
> >    -Andrew
> >
> > On Sat, Apr 24, 2021 at 10:39 PM Scott Palmer 
> wrote:
> >
> >> This doesn?t seem like something that should be the job of jpackage.
> The
> >> jpackage tool is currently used for producing platform-specific
> packages or
> >> installers targeted at end-users that include native launchers and a
> JRE.
> >> Web-based applications are an entirely different beast. This seems like
> >> more of a job for a Maven or Gradle plugin.
> >>
> >> Regards,
> >>
> >> Scott
> >>
> >>
> >>> On Apr 24, 2021, at 5:59 PM, Andrew Oliver <93q62q at gmail.com> wrote:
> >>>
> >>> Below is a Java Enhancement Proposal for your consideration to add
> >>> JavaScript to jpackage as a new target platform.  I would appreciate
> >>> feedback on the proposal contents.  I am also interested in learning
> >> about
> >>> the process, specifically what approvals are required prior to start of
> >>> implementation, should sufficient consensus be reached.
> >>>
> >>> ( To view this proposal as a web page, please visit:
> >>> https://frequal.com/TeaVM/openjdk/jdk-list-draft1.html )
> >>>
> >>> Thank you!
> >>>
> >>>   -Andrew Oliver
> >>>
> >>> Title: Add JavaScript platform to jpackage
> >>> Author: Andrew Oliver
> >>> Created: 2021/04/24
> >>> Type: Feature
> >>> State: Draft
> >>> Exposure: Open
> >>> Component: tools/jpackage
> >>> Scope: JDK
> >>> Discussion: core-libs-dev at openjdk.java.net
> >>> Template: 1.0
> >>>
> >>> Summary
> >>> -------
> >>>
> >>> jpackage already allows packaging Java applications for several
> >> platforms.
> >>> This proposal adds a new platform: JavaScript.
> >>>
> >>> This effort will enable jpackage to convert bytecode from the provided
> >>> classes into JavaScript, and generate the required HTML to invoke the
> >>> specified main method when opened in a web browser. These files will be
> >>> bundled into a WAR file for easy deployment.
> >>>
> >>> Goals
> >>> -----
> >>>
> >>> *   Enabling JVM languages to build client-side web applications
> >>> *   Allow easy generation of JavaScript from JVM bytecode
> >>> *   Allow easy deployment and execution of generated JavaScript in web
> >>> browsers
> >>> *   Allow easy deployment of the generated JavaScript in all web server
> >>> environments
> >>>     *   Java web application container (like Tomcat)
> >>>     *   Static file web servers
> >>>     *   Static file web hosting services
> >>>
> >>> Non-Goals
> >>> ---------
> >>>
> >>> *   Allowing execution of JavaScript server-side. (Java already has
> >>> numerous options for executing bytecode server-side.)
> >>>
> >>> Motivation
> >>> ----------
> >>>
> >>> Java was once used to create client-side web applications via applets
> >> that
> >>> could be launched by visiting a web page. Applets could draw on an area
> >> of
> >>> the screen (like HTML5 Canvas) or manipulate the page DOM to create
> >> dynamic
> >>> front-end applications (like JS single-page apps).
> >>>
> >>> However, as evident in JEP 398 ([
> >>> https://openjdk.java.net/jeps/398](https://openjdk.java.net/jeps/398)
> ),
> >>> applets are no longer feasible due to the actions of browser vendors.
> >> While
> >>> browsers have lost the ability to execute Java bytecode or invoke
> methods
> >>> from the Java class libraries, they do have mature engines for
> executing
> >> a
> >>> different sort of code (JavaScript) and an extensive list of useful
> APIs.
> >>> By converting class files to JavaScript, and providing mechanisms to
> >> invoke
> >>> browser APIs, Java can again be used to create in-browser applications.
> >>> [TeaVM](https://teavm.org) has demonstrated that this is feasible and
> >> has
> >>> numerous benefits:
> >>>
> >>> *   Provides a strongly-typed language for client-side web development
> >>> *   Provides a wealth of IDEs, build tools, and testing tools for
> >>> client-side web development
> >>> *   Allows teams with Java experience to produce apps with familiar
> >>> technology
> >>> *   Allows sharing of POJO and business logic classes, simplifying
> >>> development
> >>> *   Allows options for porting applet- and JNLP-based systems to
> >>> present-day browsers
> >>>
> >>> Details
> >>> -------
> >>>
> >>> An additional jpackage option for type will be added: `js`
> >>>
> >>> jpackage will use a JavaScript AOT compiler (TeaVM) to convert the Java
> >>> code to JavaScript, with the main class compiled to a JavaScript method
> >>> called 'main()'.
> >>>
> >>> jpackage bundles application code, runtime, and resources into a
> >>> platform-specific format. For this new JavaScript type, the layout will
> >> be
> >>> either a ZIP file or a standard WAR file. The ZIP format will contain
> the
> >>> files ready to be extracted to a static file webserver or HTML hosting
> >>> service. Generated WARs will have the required structure to be
> deployable
> >>> in a Java web application container.
> >>>
> >>> ### WAR layout
> >>>
> >>> *   HelloApp.war
> >>>     *   index.html (Main application page, loads classes.js and invokes
> >>> main())
> >>>     *   teavm
> >>>         *   classes.js (Class files, templates, and resources compiled
> to
> >>> JavaScript)
> >>>     *   css
> >>>         *   (CSS files from application)
> >>>     *   META-INF
> >>>         *   MANIFEST.MF
> >>>     *   WEB-INF
> >>>         *   web.xml
> >>>
> >>> ### ZIP Layout
> >>>
> >>> *   HelloApp.zip
> >>>     *   index.html (Main application page, loads classes.js and invokes
> >>> main())
> >>>     *   teavm
> >>>         *   classes.js (Class files, templates, and resources compiled
> to
> >>> JavaScript)
> >>>     *   css
> >>>         *   (CSS files from application)
> >>>
> >>> Basic usage: Non-modular applications
> >>> -------------------------------------
> >>>
> >>> Command-line usage is similar to jpackage today, except you use the
> >> `--type
> >>> js`. For example, if you have your application JARs in a folder called
> >>> `lib` and the JAR with the declared `main()` method is `main.jar`, you
> >>> could use this command:
> >>>
> >>> ```
> >>> $ jpackage --type js --name myapp --input lib --main-jar main.jar
> >>> ```
> >>>
> >>> This will produce `myapp.war` in the current directory. This is a
> >> standard
> >>> WAR file ready for deployment in any web application container (like
> >>> Tomcat). When myapp/index.html is opened in a browser, the code in
> main()
> >>> will be executed, in-browser. A typical Hello World main() method like
> >>>
> >>> ```
> >>>     public static void main(String args\[\]) {
> >>>         System.out.println("Hello, Browser!");
> >>>     }
> >>> ```
> >>>
> >>> will print the message on the browser developer console.
> >>>
> >>> Processing
> >>> ----------
> >>>
> >>> Conversion of the input JAR files to the classes.js file will be done
> by
> >>> TeaVM. It will
> >>>
> >>> *   Convert provided class files to JavaScript
> >>> *   Expose the specified main method as main()
> >>> *   Provide implementation of selected core Java classes that function
> >> in a
> >>> browser environment
> >>> *   Bundle resources into the generated JavaScript
> >>> *   Include images, css, and web.xml in the generated package, if
> >> provided
> >>> *   Provide default index.html if omitted
> >>> *   Provide default web.xml if omitted and WAR format specified
> >>> *   Optionally minify the generated JavaScript
> >>>
> >>> ### js-specific options
> >>>
> >>> 1.  `--minify`: Perform a minification pass after generating
> JavaScript,
> >>> renaming classes and methods to short, generated names to reduce
> download
> >>> sizes and provide some obfuscation.
> >>> 2.  `--debug`: Enable generation of source maps.
> >>> 3.  `--debug-full`: Enable generation of source maps and bundled source
> >>> files.
> >>> 4.  `--optimization`: Choose simple, advanced, or full.
> >>>     *   simple: Perform only basic optimizations
> >>>     *   advanced: Perform more optimizations. Recommended for
> production.
> >>>     *   full: Perform aggressive optimizations. Increases compilation
> >> time.
> >>> 5.  `--timezone-support`: Enables timezone support, at the cost of
> >>> increased application size
> >>> 6.  `--locale-list`: Add extra locales via a list, at the cost of
> >> increased
> >>> application size. Format: comma-separated list of locale IDs like
> >> "en\_US,
> >>> ru\_RU"
> >>>
> >>> ### Unsupported options for the JavaScript type
> >>>
> >>> These options are unsupported for `--type js`
> >>>
> >>> *   `--file-associations`: Not yet meaningful for a web-based app,
> though
> >>> it may be in the future once PWAs support file types: [
> >>>
> >>
> https://github.com/WICG/file-handling](https://github.com/WICG/file-handling)
> >>> *   `--app-version, --copyright, --description, --license-file,
> >> --vendor`:
> >>> jpackage will only support --name initially. Users can customize
> >> index.html
> >>> (and the rest of the application) to show branding and metadata as
> >> desired.
> >>> *   `--java-options`: Not yet supported, use `--arguments` instead.
> >>>
> >>> Caveats
> >>> -------
> >>>
> >>> Certain Java classes are not feasible to implement in a browser
> setting.
> >>> Socket, for example, is not useful in a browser since JavaScript cannot
> >>> open arbitrary socket connections. Code using unavailable classes will
> >> fail
> >>> during packaging time with warnings about the missing classes.
> >>>
> >>> Testing
> >>> -------
> >>>
> >>> Since TeaVM is Java-based, tests will be able to run on any platform.
> >>>
> >>> Testing will focus on the new jpackage code and added functionality.
> >> Tests
> >>> will confirm that when valid parameters are provided, that output is
> >>> generated with the right name and in the right folder. Contents of the
> >>> generated ZIP and WAR files will be checked for the presence of
> expected
> >>> files. Testing generated files in a browser will be done manually.
> >>>
> >>> A thorough test of TeaVM itself is out of scope for the jpackage
> testing.
> >>> This is in line with jpackage testing for other platforms, in which the
> >>> external packaging tool (like Wix on Windows) isn't exhaustively
> tested.
> >>>
> >>> Dependencies
> >>> ------------
> >>>
> >>> The jpackage `js` type will require TeaVM binaries to be present.
> >>>
> >>> Implementation options:
> >>>
> >>> *   Download TeaVM on-demand and cache it. (This is the likely option.)
> >>>     *   Look for TeaVM in local repositories for popular build tools
> like
> >>> Maven and Gradle
> >>>     *   If not found locally, download TeaVM binaries from the
> read-only
> >>> central repository and store in the cache folder
> >>>     *   Invoke TeaVM from the local repository or cache
> >>> *   Require that TeaVM binaries be installed locally
> >>>     *   Provide the path to TeaVM binaries on the command line
> >>> *   Bundle TeaVM
> >>>     *   Challenging due to incompatible licenses (Apache v2 vs. GPL v2
> >> with
> >>> CPE)
> >>>     *   Probably unnecessary given the options above. Other jpackage
> >>> options require pre-installed tools, this will be no different.
> >>>
> >>> High-Level Design
> >>> -----------------
> >>>
> >>> A new bundler will be added to the jpackage Java source code.
> >>>
> >>> It will first ensure that TeaVM binaries (JAR files) are available
> >> locally,
> >>> as described in the section above.
> >>>
> >>> The new bundler will use TeaVM's TeaVMRunner ([
> >>>
> >>
> https://github.com/konsoletyper/teavm/blob/master/tools/cli/src/main/java/org/teavm/cli/TeaVMRunner.java](https://github.com/konsoletyper/teavm/blob/master/tools/cli/src/main/java/org/teavm/cli/TeaVMRunner.java)
> >> ),
> >>> which conveniently accepts options similar to jpackage itself.
> >> TeaVMRunner
> >>> will do the heavy lifting of converting the application JAR files and
> >>> resources into `classes.js`.
> >>>
> >>> The bundler will provide additional files required to make a web
> >>> application, including an `index.html` to launch the `main()` method.
> The
> >>> bundler will create the final archive (ZIP or WAR) using Java's
> >>> ZipOutputStream. For the WAR format, the bundler will also add
> `web.xml`
> >>> and `MANIFEST.MF` if not present to create a deployable, standard WAR
> >> file.
> >>
> >>
>
>

From psandoz at openjdk.java.net  Sat May  8 15:56:05 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Sat, 8 May 2021 15:56:05 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: <4IY0_Zr94l_aZTe-fYIva28aZw8uYJ5k6d48uByI70E=.19f2b9e5-4958-4bb3-b016-d9f809fe3347@github.com>
References: 
 
 <9Z_DkUjmqefCjf9mvecHUtoLHhw1qGNWJPxufuwvXI0=.36498a86-d09f-4eea-ab89-74844dd862cf@github.com>
 <4IY0_Zr94l_aZTe-fYIva28aZw8uYJ5k6d48uByI70E=.19f2b9e5-4958-4bb3-b016-d9f809fe3347@github.com>
Message-ID: 

On Sat, 8 May 2021 05:32:00 GMT, Yi Yang  wrote:

> It seems that Object.checkIndex can not meet our needs because it implicitly passes null to Preconditions.checkIndex, but we want to customize exception messages, so we might add extra APIs in Objects while doing the replacement.
>

It might be possible to directly use `Preconditions.checkIndex` for such purposes, its package is non-exported but public for reuse within `java.base`. It's used in `VarHandle` `byte` array access code, see [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template#L117).

I would caution against adding a public API to support this. The work in  `Preconditions` was the basis for a public API, but it proved complicated. I am glad we did not expose that, it would of made exposing the long accepting `Objects.checkIndex` methods more difficult.

Paul.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From vlv.spb.ru at mail.ru  Sat May  8 21:21:15 2021
From: vlv.spb.ru at mail.ru (=?UTF-8?B?VmxhZGltaXIgWWFyb3NsYXZza2l5?=)
Date: Sun, 09 May 2021 00:21:15 +0300
Subject: =?UTF-8?B?SW1wcm92ZW1lbnQgb2YgRHVhbC1QaXZvdCBRdWlja3NvcnQgKFJhZGl4IHNv?=
 =?UTF-8?B?cnQp?=
Message-ID: <1620508875.734159306@f387.i.mail.ru>


Hi,
?
I?d like to?share new?improvement of Dual-Pivot Quicksort: new algorithm of sorting,?Radix sort,
is suggested. Also performance was improved in?case of corner?merging of runs. The changes are:
?
Sorting:
- adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
- fix tryMergeRuns() to better handle case when the last run is a single element
- minor javadoc and comment changes
Testing:
- add new data inputs in tests for sorting
- add min/max/infinity values to float/double testing
- add tests for radix sort
?
See related JDB and?PR
https://bugs.openjdk.java.net/browse/JDK-8266431
https://github.com/openjdk/jdk/pull/3938
?
Laurent Bourges has tested?new version?of Dual-Pivot Quicksort,?it shows better performance.
?
--- STATS ---
Comparing sorters SYSTEM vs NEW_DPQS_REF
winners : 75 / 197
avg (%): 125.5317
stats (%): [360: ?=146.05562 ?=106.212036 rms=252.26765 min=29.021154 max=618.46735]
Stats per keys:
IDENT_____:SPIRAL stats (%): [12: ?=146.85367 ?=67.929474 rms=214.78313 min=81.47126 max=301.9469]
IDENT_____:STAGGER stats (%): [12: ?=124.82189 ?=85.498825 rms=210.32072 min=81.963005 max=395.48715]
IDENT_____:SAWTOTH stats (%): [12: ?=121.015236 ?=48.471672 rms=169.48691 min=92.21825 max=227.12547]
IDENT_____:_RANDOM stats (%): [12: ?=235.53735 ?=204.9386 rms=440.47595 min=84.627625 max=613.981]
IDENT_____:PLATEAU stats (%): [12: ?=99.05677 ?=1.7938316 rms=100.85061 min=95.937035 max=100.65806]
IDENT_____:SHUFFLE stats (%): [12: ?=91.41511 ?=19.296474 rms=110.71158 min=57.53845 max=117.839775]
REVERSE___:SPIRAL stats (%): [12: ?=214.24744 ?=86.17577 rms=300.42322 min=90.77709 max=355.51056]
REVERSE___:STAGGER stats (%): [12: ?=127.6578 ?=87.32062 rms=214.97841 min=94.24164 max=404.43817]
REVERSE___:SAWTOTH stats (%): [12: ?=121.37123 ?=39.691704 rms=161.06294 min=95.34109 max=209.51929]
REVERSE___:_RANDOM stats (%): [12: ?=251.44595 ?=221.17654 rms=472.6225 min=86.738144 max=618.46735]
REVERSE___:PLATEAU stats (%): [12: ?=104.74188 ?=6.7017303 rms=111.44361 min=97.345634 max=120.3795]
REVERSE___:SHUFFLE stats (%): [12: ?=100.18308 ?=19.42561 rms=119.608696 min=69.78542 max=135.48901]
DITHER____:SPIRAL stats (%): [12: ?=183.42812 ?=64.67034 rms=248.09845 min=99.713776 max=268.3382]
DITHER____:STAGGER stats (%): [12: ?=174.41586 ?=123.18825 rms=297.60413 min=99.123314 max=459.56564]
DITHER____:SAWTOTH stats (%): [12: ?=187.5975 ?=110.62237 rms=298.21988 min=97.2715 max=367.14056]
DITHER____:_RANDOM stats (%): [12: ?=185.65709 ?=129.0605 rms=314.7176 min=70.168724 max=434.8079]
DITHER____:PLATEAU stats (%): [12: ?=100.72014 ?=3.9355173 rms=104.655655 min=94.559074 max=107.78911]
DITHER____:SHUFFLE stats (%): [12: ?=86.45017 ?=42.46921 rms=128.91939 min=29.021154 max=171.31981]
REVERSE_BA:SPIRAL stats (%): [12: ?=177.85292 ?=85.1786 rms=263.03152 min=94.477264 max=315.87576]
REVERSE_BA:STAGGER stats (%): [12: ?=132.4794 ?=103.280464 rms=235.75987 min=97.76542 max=460.07227]
REVERSE_BA:SAWTOTH stats (%): [12: ?=110.42876 ?=23.894398 rms=134.32315 min=98.04496 max=182.87247]
REVERSE_BA:_RANDOM stats (%): [12: ?=223.70018 ?=185.21355 rms=408.91373 min=86.62554 max=618.0156]
REVERSE_BA:PLATEAU stats (%): [12: ?=99.096275 ?=1.8192571 rms=100.91553 min=95.90717 max=100.805466]
REVERSE_BA:SHUFFLE stats (%): [12: ?=101.3669 ?=22.24021 rms=123.60711 min=65.73001 max=144.21266]
REVERSE_FR:SPIRAL stats (%): [12: ?=190.94035 ?=74.251236 rms=265.1916 min=97.7578 max=358.39563]
REVERSE_FR:STAGGER stats (%): [12: ?=134.06009 ?=104.719696 rms=238.77979 min=98.797386 max=466.2626]
REVERSE_FR:SAWTOTH stats (%): [12: ?=110.6682 ?=27.3231 rms=137.9913 min=94.27639 max=195.0114]
REVERSE_FR:_RANDOM stats (%): [12: ?=248.0682 ?=201.4303 rms=449.4985 min=97.789764 max=614.1303]
REVERSE_FR:PLATEAU stats (%): [12: ?=99.416336 ?=7.2677627 rms=106.6841 min=87.80682 max=115.78382]
REVERSE_FR:SHUFFLE stats (%): [12: ?=96.97448 ?=18.399363 rms=115.37385 min=64.20668 max=130.8938]
?
https://github.com/bourgesl/nearly-optimal-mergesort-code/tree/master/sort-bench/results/2021/2105-final
?
Radix Sort benchmark
https://github.com/bourgesl/radix-sort-benchmark/blob/main/results/2021-ref/cmp-16-1M-global-final-2.log
?
Thank you,
Vladimir

From hshi at openjdk.java.net  Sun May  9 01:43:00 2021
From: hshi at openjdk.java.net (Hui Shi)
Date: Sun, 9 May 2021 01:43:00 GMT
Subject: RFR: 8266610: Method RandomAccessFile#length() returns 0 for
 block devices on linux. [v2]
In-Reply-To: 
References: 
 
Message-ID: <1ozB7BjOCtV2kIuoczRaJMKX67EZKkZmnCEuKRgZfbg=.1ccb05de-03d3-4296-acca-bd710e3bd679@github.com>

On Fri, 7 May 2021 12:17:11 GMT, Vyom Tewari  wrote:

>> RandomAccessFile.length() method for block device return always 0
>
> Vyom Tewari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed assigning -1 to uint64_t

Could required os = linux added for test/jdk/java/nio/channels/FileChannel/BlockDeviceSize.java? As it is decribed only run as linux.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3914

From vtewari at openjdk.java.net  Sun May  9 03:41:00 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Sun, 9 May 2021 03:41:00 GMT
Subject: RFR: 8266610: Method RandomAccessFile#length() returns 0 for
 block devices on linux. [v2]
In-Reply-To: <1ozB7BjOCtV2kIuoczRaJMKX67EZKkZmnCEuKRgZfbg=.1ccb05de-03d3-4296-acca-bd710e3bd679@github.com>
References: 
 
 <1ozB7BjOCtV2kIuoczRaJMKX67EZKkZmnCEuKRgZfbg=.1ccb05de-03d3-4296-acca-bd710e3bd679@github.com>
Message-ID: 

On Sun, 9 May 2021 01:39:40 GMT, Hui Shi  wrote:

> Could required os = linux added for test/jdk/java/nio/channels/FileChannel/BlockDeviceSize.java? As it is decribed only run as linux.

Sure, this is separate issue(https://bugs.openjdk.java.net/browse/JDK-8150539). We will fix it separately.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3914

From alanb at openjdk.java.net  Sun May  9 06:28:15 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 9 May 2021 06:28:15 GMT
Subject: RFR: 8266610: Method RandomAccessFile#length() returns 0 for
 block devices on linux. [v2]
In-Reply-To: 
References: 
 
 <1ozB7BjOCtV2kIuoczRaJMKX67EZKkZmnCEuKRgZfbg=.1ccb05de-03d3-4296-acca-bd710e3bd679@github.com>
 
Message-ID: 

On Sun, 9 May 2021 03:38:49 GMT, Vyom Tewari  wrote:

> Could required os = linux added for test/jdk/java/nio/channels/FileChannel/BlockDeviceSize.java? As it is decribed only run as linux.

Yes, good idea. Also maybe we can see about changing it to avoid the dependency on /dev/sda1.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3914

From dfranken.jdk at gmail.com  Sun May  9 10:13:58 2021
From: dfranken.jdk at gmail.com (dfranken.jdk at gmail.com)
Date: Sun, 09 May 2021 12:13:58 +0200
Subject: [External] : Re: ReversibleCollection proposal
In-Reply-To: <2063372755.1742538.1620211264481.JavaMail.zimbra@u-pem.fr>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 
 <839698479.422241.1619098212148.JavaMail.zimbra@u-pem.fr>
 <7457433b-0836-f45e-4b51-4c2ecdf7e7da@oracle.com>
 <427897615.2057286.1619612437790.JavaMail.zimbra@u-pem.fr>
 
 <906317823.1426529.1619873859193.JavaMail.zimbra@u-pem.fr>
 
 <2063372755.1742538.1620211264481.JavaMail.zimbra@u-pem.fr>
Message-ID: 

When I thought about Collection's role in the hierarchy, it seemed to
me that 'Collection' is an interface for describing how elements are
stored in a cardboard box (we can and and remove them) and that we
might need a different, yet related, interface to describe how to
retrieve the items from the box. This way we are not tied to the
Collection hierarchy and we could have one Set implementation which is
ordered and another Set implementation which is not and they would both
still implement Collection, but only one would implement the interface.

Imagine an interface like 'java.lang.OrderedEnumerable` if you will
with methods such as 'first(), last(), etc', then each implementation
would be free to choose to implement the interface or not. I also
thought about 'OrderedIterable', but there would be too much confusion
with 'Iterable', but I think these are related too. Retrieving items is
an iteration problem, not a storage problem.

While I would love to see the Collection hierarchy redesigned to also
allow for ImmutableCollection which for instance would not have an
`add(T e)` method, I don't think we can simply do something like that
without breaking too many things.

So in short, separating retrieval aspects from storage aspects with a
different interface might be the way to go.

Kind regards,

Dave Franken

On Wed, 2021-05-05 at 12:41 +0200, forax at univ-mlv.fr wrote:
> ----- Mail original -----
> > De: "Stuart Marks" 
> > ?: "Remi Forax" 
> > Cc: "core-libs-dev" 
> > Envoy?: Mercredi 5 Mai 2021 02:00:03
> > Objet: Re: [External] : Re: ReversibleCollection proposal
> 
> > On 5/1/21 5:57 AM, forax at univ-mlv.fr?wrote:
> > > I suppose the performance issue comes from the fact that
> > > traversing a
> > > LinkedHahSet is slow because it's a linked list ?
> > > 
> > > You can replace a LinkedHashSet by a List + Set, the List keeps
> > > the values in
> > > order, the Set avoids duplicates.
> > > 
> > > Using a Stream, it becomes
> > > ?? Stream.of(getItemsFromSomeplace(), getItemsFromAnotherPlace(),
> > > ?? getItemsFromSomeplaceElse())
> > > ??? .flatMap(List::stream)
> > > ??? .distinct()????????????? // use a Set internally
> > > ??? .collect(toList());
> > 
> > The problem with any example is that simplifying assumptions are
> > necessary for
> > showing the example, but those assumptions enable it to be easily
> > picked apart.
> > Of
> > course, the example isn't just a particular example; it is a
> > *template* for a
> > whole
> > space of possible examples. Consider the possibility that the items
> > processing
> > client needs to do some intermediate processing on the first group
> > of items
> > before
> > adding the other groups. This might not be possible to do using
> > streams. Use
> > your
> > imagination.
> > 
> > > I think there are maybe some scenarios where ReversibleCollection
> > > can be useful,
> > > but they are rare, to the point where when there is a good
> > > scenario for it
> > > people will not recognize it because ReversibleCollection will
> > > not be part of
> > > their muscle memory.
> > 
> > I'm certain that uses of RC/RS will be rare in the beginning,
> > because they will
> > be
> > new, and people won't be familar with them. And then there will the
> > people who
> > say
> > "I can't use them because I'm stuck on JDK 11 / 8 / 7 / 6 ...." It
> > was the same
> > thing with lambdas and streams in Java 8, with List.of() etc in
> > Java 9, records
> > in
> > Java 16, etc. This wasn't an argument not to add them, and it isn't
> > an argument
> > not
> > to add RC/RS.
> 
> All the changes you are listing here are "client side" changes, the
> ones that can be adopted quickly because they do not require to
> change the API side of any libraries.
> ReversibleCollection is an API side change, like generics is, those
> changes have a far higher cost because you have to wait your library
> dependencies to be updated.
> On the Valhalla list, we have discussed several times about how to
> alleviate those API side change cost using automatic bridging or
> methods forwarding, even for Valhalla, we are currently moving in a
> state where those mechanisms are not needed. 
> 
> > 
> > > There is a real value to add methods like
> > > descendingSet/descendingList()/getFirst/getLast on existing
> > > collections, but we
> > > don't need a new interface (or two) for that.
> > 
> > It depends on what you mean by "need". Sure, we could get away
> > without this;
> > after
> > all, we've survived the past twenty years without it, so we could
> > probably
> > survive
> > the next twenty years as well.
> > 
> > It would indeed be useful to add various methods to List, Deque,
> > SortedSet, and
> > LinkedHashSet to provide a full set of methods on all of them. And
> > it would also
> > be
> > nice to have those methods be similar to one another. An interface
> > helps with
> > that,
> > but I agree, that's not really the reason to have an interface
> > though.
> > 
> > The reversed-view concept could also be added individually to the
> > different
> > places.
> > A reverse-ordered List is a List, a reverse-ordered Deque is a
> > Deque, a
> > reverse-ordered SortedSet is a SortedSet, and a reverse-ordered
> > LinkedHashSet is
> > a
> > ... ? And what is the type of the keySet of a LinkedHashMap, that
> > enables one to
> > (say) get the last element?
> 
> see below
> 
> > 
> > After working with a system like this for a while, it begins to
> > emerge that
> > there is
> > an abstraction missing from the collections framework, something
> > like an
> > "ordered
> > collection". People have been missing this for quite a long time.
> > The most
> > recent
> > example (which this proposal builds on) is Tagir's proposal from a
> > year ago. And
> > it's been asked about several times before that.
> > ReversibleCollection fills in
> > that
> > missing abstraction.
> 
> The abstraction already exists but it's not defined in term of
> interface because it's an implementation decision and those are
> cleanly separated in the current Collection design.
> 
> Let take a step back, the collection API defines basic data structure
> operations in term of interfaces like List, Deque, Set, etc those
> interfaces are decoupled from implementation capabilities like
> mutable, nullable, ordered and checked.
> 
> Depending on the implementation capabilities, the interfaces method
> implementation may throw an exception, non-mutable implementations
> use UnsupportedOperationException, non-nullable implementations use
> NPE and checked implementations use CCE. 
> 
> So what is missing is methods on Collection interfaces that require
> the collection implementation to be ordered like descendingList(),
> getFirst(), etc.
> Those methods that may throw a specific exception if the
> implementation is not ordered, not UnsupportedOperationException but
> a new one like NotOrderedException.
> 
> So to answer to your question about LinkedHashSet, the reverse-
> ordered LinkedHashSet is a Set with a method descendingSet() that do
> not throw NotOrderedException like any Set with an order.
> 
> To summarize, if we introduce ReversibleCollection, we should also
> introduce ImmutableCollection, NonNullableCollection and
> CheckedCollection.
> I think it's better to consider the fact that being ordered as a
> capability (hint: this is already what the Spliterator API does) and
> not as a specific interface.
> 
> > 
> > s'marks
> 
> R?mi



From lancea at openjdk.java.net  Sun May  9 11:08:46 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sun, 9 May 2021 11:08:46 GMT
Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 May 2021 03:10:32 GMT, Jason Zaugg  wrote:

>> If the given Path represents a file, use the overload of read defined
>> in FileChannel that accepts an explicit position and avoid serializing
>> reads.
>> 
>> Note: The underlying NIO implementation is not required to implement
>> FileChannel.read(ByteBuffer, long) concurrently; Windows still appears
>> to lock, as it returns true for NativeDispatcher.needsPositionLock.
>> 
>> 
>> On MacOS X, the enclosed benchmark improves from:
>> 
>> 
>> Benchmark                    Mode  Cnt   Score   Error  Units
>> ZipFileSystemBenchmark.read  avgt   10  75.311 ? 3.301  ms/op
>> 
>> 
>> To:
>> 
>> 
>> Benchmark                    Mode  Cnt   Score   Error  Units
>> ZipFileSystemBenchmark.read  avgt   10  12.520 ? 0.875  ms/op
>
> Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   [zipfs] Add missing check-failed exception to position/read test
>   
>   This appears to have been omitted when this test was added.
>   To avoid false error reports, the condition must deal with the
>   edge case of zero-length entries, for which read will return -1.

Hi Jason,

I have made a pass through your proposed changes and they look OK.  I am in the process of running our various Mach5 tiers against your patch to see if any unforeseen issues arise

Best
Lance

-------------

PR: https://git.openjdk.java.net/jdk/pull/3853

From itakiguchi at openjdk.java.net  Sun May  9 14:25:57 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Sun, 9 May 2021 14:25:57 GMT
Subject: RFR: 8266013: Unexpected replacement character handling on
 stateful CharsetEncoder [v2]
In-Reply-To: <8MYxd4bq0m2zaz9_M8ty4OcFqCkzDGTcXcRLFbzKdoU=.58825ee2-dd9f-4690-8bdc-8d5955bb7d51@github.com>
References: 
 <8MYxd4bq0m2zaz9_M8ty4OcFqCkzDGTcXcRLFbzKdoU=.58825ee2-dd9f-4690-8bdc-8d5955bb7d51@github.com>
Message-ID: <94Rf74KQTJDLr-YK0cmH4YSDOMYtbCLILpomr1FlfMA=.150b4787-99fa-4cc3-b08e-e57382f5e28d@github.com>

On Fri, 30 Apr 2021 16:11:30 GMT, Ichiroh Takiguchi  wrote:

>> When an invalid character is converted by getBytes() method, the character is converted to replacement byte data.
>> Shift code (SO/SI) may not be added into right place by EBCDIC Mix charset.
>> EBCDIC Mix charset encoder is stateful encoder.
>> Shift code should be added by switching character set.
>> On x-IBM1364, "\u3000\uD800" should be converted to "\x0E\x40\x40\x0F\x6F", but "\x0E\x40\x40\x6F\x0F"
>> SI is not in right place.
>> 
>> Also ISO2022 related charsets use escape sequence to switch character set.
>> But same kind of issue is there.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266013: Unexpected replacement character handling on stateful CharsetEncoder

Gentle reminder

Currently stateful CharsetEncoder (like EBCDIC Mix, ISO2022 related) cannot handle replacement characters.
Please give me your suggestion or advice.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3719

From alanb at openjdk.java.net  Sun May  9 15:02:06 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 9 May 2021 15:02:06 GMT
Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 May 2021 03:10:32 GMT, Jason Zaugg  wrote:

>> If the given Path represents a file, use the overload of read defined
>> in FileChannel that accepts an explicit position and avoid serializing
>> reads.
>> 
>> Note: The underlying NIO implementation is not required to implement
>> FileChannel.read(ByteBuffer, long) concurrently; Windows still appears
>> to lock, as it returns true for NativeDispatcher.needsPositionLock.
>> 
>> 
>> On MacOS X, the enclosed benchmark improves from:
>> 
>> 
>> Benchmark                    Mode  Cnt   Score   Error  Units
>> ZipFileSystemBenchmark.read  avgt   10  75.311 ? 3.301  ms/op
>> 
>> 
>> To:
>> 
>> 
>> Benchmark                    Mode  Cnt   Score   Error  Units
>> ZipFileSystemBenchmark.read  avgt   10  12.520 ? 0.875  ms/op
>
> Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   [zipfs] Add missing check-failed exception to position/read test
>   
>   This appears to have been omitted when this test was added.
>   To avoid false error reports, the condition must deal with the
>   edge case of zero-length entries, for which read will return -1.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3853

From alanb at openjdk.java.net  Sun May  9 16:38:13 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 9 May 2021 16:38:13 GMT
Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes
 [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 6 May 2021 16:40:31 GMT, Brian Burkhalter  wrote:

>> Please consider this request to override the `java.io.InputStream` methods `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more performant implementations. The method overrides attempt to read all requested bytes into a single array of the required size rather than composing the result from a sequence of smaller arrays. An example of the performance improvements is as follows.
>> 
>> **readAllBytes**
>> Before
>> 
>> Benchmark                                    (length)   Mode  Cnt      Score     Error  Units
>> ReadAllBytes.readAllBytesFileInputStream      1000000  thrpt   20   2412.031 ?   7.309  ops/s
>> ReadAllBytes.readAllBytesFileInputStream     10000000  thrpt   20    212.181 ?   0.369  ops/s
>> ReadAllBytes.readAllBytesFileInputStream    100000000  thrpt   20     19.860 ?   0.048  ops/s
>> ReadAllBytes.readAllBytesFileInputStream   1000000000  thrpt   20      1.298 ?   0.183  ops/s
>> 
>> After
>> 
>> Benchmark                                    (length)   Mode  Cnt      Score     Error  Units
>> ReadAllBytes.readAllBytesFileInputStream      1000000  thrpt   20   8218.473 ?  43.425  ops/s
>> ReadAllBytes.readAllBytesFileInputStream     10000000  thrpt   20    302.781 ?   1.273  ops/s
>> ReadAllBytes.readAllBytesFileInputStream    100000000  thrpt   20     22.461 ?   0.084  ops/s
>> ReadAllBytes.readAllBytesFileInputStream   1000000000  thrpt   20      1.502 ?   0.003  ops/s
>> 
>> 
>> **readNBytes**
>> 
>> `N = file_size / 2`
>> 
>> Before
>> 
>> Benchmark                                    (length)   Mode  Cnt      Score     Error  Units
>> ReadAllBytes.readHalfBytesFileInputStream     1000000  thrpt   20   5585.500 ? 153.353  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream    10000000  thrpt   20    436.164 ?   1.104  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream   100000000  thrpt   20     40.167 ?   0.141  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream  1000000000  thrpt   20      3.291 ?   0.211  ops/s
>> 
>> 
>> After
>> 
>> Benchmark                                    (length)   Mode  Cnt      Score     Error  Units
>> ReadAllBytes.readHalfBytesFileInputStream     1000000  thrpt   20  15463.210 ?  66.045  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream    10000000  thrpt   20    561.752 ?   0.951  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream   100000000  thrpt   20     45.043 ?   0.102  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream  1000000000  thrpt   20      4.629 ?   0.035  ops/s
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8264777: Make length and position consistent with RAF; add path to OOME message

src/java.base/share/classes/java/io/FileInputStream.java line 319:

> 317:     }
> 318: 
> 319:     public byte[] readNBytes(int len) throws IOException {

readNBytes(0) is specified to return an empty array, it looks like this implementation will throw IIOBE. Can you check this?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3845

From dfranken.jdk at gmail.com  Sun May  9 17:33:47 2021
From: dfranken.jdk at gmail.com (dfranken.jdk at gmail.com)
Date: Sun, 09 May 2021 19:33:47 +0200
Subject: New convenience methods on Stream
In-Reply-To: <0bbacfca-ebea-bf11-699a-c69d62619532@oracle.com>
References: 
 
 
 <0bbacfca-ebea-bf11-699a-c69d62619532@oracle.com>
Message-ID: <6b5ac01f2fed0ab6ee907892bdf93f846072a99a.camel@gmail.com>

>From my own limited experience, I've seen .collect(Supplier) often when
an explicitly mutable collection is needed, such as with ArrayList::new
or HashSet::new.

Even though you could in theory use Stream.toList() for the ArrayList
version, I don't think this is advisable as toList isn't guaranteed to
return an ArrayList. It may even return a different type at runtime
based on the input size for instance, that's all up to the
implementation and we should not care about it.

Given these use cases where explicitly modifiable collections are
wanted, it could be more useful to add methods such as
.toModifiableList() and .toModifiableSet() rather than a shorthand
collector.
But these methods really belong to the Collectors API.

Note that for instance for Collectors.toList "there are no guarantees
on the type, mutability, serializability, or thread-safety of the List
returned" and there exists a Collectors.toUnmodifiableList() which does
guarantee an unmodifiable list. Adding explicit .toModifiableList() and
.toModifiableSet() with their respective guarantees might be helpful as
we would create more symmetry between modifiable and unmodifiable
collectors.

Adding these methods also allows returning more specialized
implementations, but it also frees up any optimizations we might want
to do for `Collectors.toList()` because we can now offer a more
explicit choice between modifiable and unmodifiable variants.

Kind regards,

Dave Franken

On Tue, 2021-05-04 at 23:12 -0700, Stuart Marks wrote:
> Hi Don,
> 
> When evaluating new APIs I always find it helpful and educational to
> look for cases 
> in real code where they might be applied, and what effect the API has
> at the call 
> site. The search need not be exhaustive, but it's probably sufficient
> to find a 
> number of representative examples. This does take some effort,
> though. For now I'll 
> take a look at some examples where your first item can be applied:
> 
> > 
> > default > R toCollection(Supplier
> > supplier)
> > {
> > ??? return this.collect(Collectors.toCollection(supplier));
> > }
> > 
> > Usage Examples:
> > 
> > HashSet set = stream.toCollection(HashSet::new);
> > TreeSet sortedSet = stream.toCollection(TreeSet::new);
> > ArrayDeque deque = stream.toCollection(ArrayDeque::new);
> 
> Since I have the JDK handy I searched it for 'toCollection('. There
> are around 60 
> hits -- but note that 2/3 of these are in java.sql.rowset and refer
> to an unrelated 
> API. Some are in comments, and some are the implementation of 
> Collectors.toCollection itself, which leaves just 14 cases. Let's
> look at a few.
> 
> 
> #
> src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskPool.
> java:164
> 
> 
> ???????? List opts =
> ???????????????? StreamSupport.stream(options.spliterator(), false)
> ?????????????????????????????
> .collect(Collectors.toCollection(ArrayList::new));
> 
> Using the proposed API here would result in:
> 
> ???????? List opts =
> ???????????????? StreamSupport.stream(options.spliterator(), false)
> ????????????????????????????? .toCollection(ArrayList::new));
> 
> This makes the code a little bit nicer. A static import would also
> haved helped, 
> though not quite as much as the new API:
> 
> ???????? List opts =
> ???????????????? StreamSupport.stream(options.spliterator(), false)
> ?????????????????????????????
> .collect(toCollection(ArrayList::new)));
> 
> I also note that after some analysis of the usage of the resulting
> List, it's never 
> modified -- indeed, it's used as the key of a Map -- so this could be
> replaced with 
> the recently-added Stream::toList.
> 
> 
> #
> src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java:3
> 81
> 
> 
> ???????????? Set platforms =
> StreamSupport.stream(providers.spliterator(), 
> false)
> ????????????????????????????????????????????????? .flatMap(provider -
> > 
> StreamSupport.stream(provider.getSupportedPlatformNames()
> ?
> ???????????????? .spliterator(),
> ?
> ???????? false))
> ?
> .collect(Collectors.toCollection(LinkedHashSet :: new));
> 
> (Sorry for line wrapping. This file has some long lines.) Again,
> using the proposal 
> API would shorten things a bit, but it doesn't really make much
> difference within 
> the overall context:
> 
> ???????????? Set platforms =
> StreamSupport.stream(providers.spliterator(), 
> false)
> ????????????????????????????????????????????????? .flatMap(provider -
> > 
> StreamSupport.stream(provider.getSupportedPlatformNames()
> ?
> ???????????????? .spliterator(),
> ?
> ???????? false))
> ?????????????????????????????????????????????????
> .toCollection(LinkedHashSet :: new));
> 
> 
> #
> src/java.logging/share/classes/java/util/logging/LogManager.java:2138
> 
> 
> ???????????? final Map> loggerConfigs =
> ?
> allKeys.collect(Collectors.groupingBy(ConfigProperty::getLoggerName,
> ???????????????????????????????????? TreeMap::new,
> ????????????????????????????????????
> Collectors.toCollection(TreeSet::new)));
> 
> This is an interesting case, as the toCollection() method is being
> used to produce a 
> "downstream" collector passed to groupingBy(). Since the proposed API
> is on stream, 
> it can't be used here. There are a few other cases like this where
> toCollection is 
> used as a downstream collector, not as an argument to
> Stream::collect.
> 
> 
> # 
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/ht
> ml/HtmlConfiguration.java:377
> 
> 
> ???? public List getAdditionalStylesheets() {
> ???????? return options.additionalStylesheets().stream()
> ???????????????? .map(ssf -> DocFile.createFileForInput(this, ssf))
> ???????????????? .map(file -> DocPath.create(file.getName()))
> ???????????????? .collect(Collectors.toCollection(ArrayList::new));
> ???? }
> 
> This is another place where the proposed API can be used
> straightforwardly:
> 
> ???? public List getAdditionalStylesheets() {
> ???????? return options.additionalStylesheets().stream()
> ???????????????? .map(ssf -> DocFile.createFileForInput(this, ssf))
> ???????????????? .map(file -> DocPath.create(file.getName()))
> ???????????????? .toCollection(ArrayList::new));
> ???? }
> 
> 
> # 
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ut
> il/IndexBuilder.java:220
> 
> 
> This is a slightly different case, as it uses a lambda to pass a
> comparator to a 
> constructor instead of using a constructor reference. Before:
> 
> ???? public SortedSet getItems(DocTree.Kind kind) {
> ???????? Objects.requireNonNull(kind);
> Collections.emptySortedSet()).stream()
> ???????????????? .filter(i -> i.isKind(kind))
> ???????????????? .collect(Collectors.toCollection(() -> new
> TreeSet<>(mainComparator)));
> ???? }
> 
> After:
> 
> ???? public SortedSet getItems(DocTree.Kind kind) {
> ???????? Objects.requireNonNull(kind);
> Collections.emptySortedSet()).stream()
> ???????????????? .filter(i -> i.isKind(kind))
> ???????????????? .toCollection(() -> new TreeSet<>(mainComparator)));
> ???? }
> 
> 
> *****
> 
> 
> There are a few other cases in the JDK but they don't seem to lead to
> any new insights.
> 
> Some observations.
> 
> ? - Using this API saves 19 characters compared to
> Collectors::toCollection, but it 
> saves only eight characters compared to Collectors::toCollection with
> a static import.
> 
> ? - Using this API doesn't relieve the calling code of any burden of
> tedious or 
> error-prone code. The code it replaces is quite straightforward.
> 
> ? - There don't appear to be any opportunities for optimization. In
> order to handle 
> the parallel case, this pretty much is required to delegate to the
> collector. I 
> suppose the serial case could be handled specially, but it boils down
> to 
> constructing the destination and then calling add() on it repeatedly,
> which is 
> pretty much what the collector ends up doing in the serial case
> anyway.
> 
> Collectors::toList and Stream::toList.
> 
> ? - Some cases of Collectors::toCollection are used as "downstream"
> collectors, that 
> is, passed to other collectors instead of Stream::collect. This
> narrows the range of 
> possible uses of the API still further.
> 
> ? - There is a recurring pattern
> 
> ????? Collectors.toCollection(ArrayList::new)
> 
> This is useful in place of Collectors::toList for places where the
> code wants to 
> guarantee the result to be an ArrayList. (Even though
> Collectors::toList returns an 
> ArrayList, it isn't specified to do so.) But there are cases (such as
> the one I 
> looked at above) where the return list isn't actually modified -- and
> indeed it 
> would be an error if it were modified -- so Stream::toList could be
> used just as 
> well for those.
> 
> ? - The JDK is not necessarily a representative code base, but
> frequencies here do 
> seem to mirror what I've seen in open source:
> Collectors::toCollection is much less 
> frequent than Collectors::toList.
> 
> ? - There doesn't appear to be any semantic difference between the
> proposed 
> Stream::toCollection and the existing Collectors::toCollection.
> 
> Based on these observations I'm having a hard time mustering much
> enthusiasm for 
> this API.
> 
> You might ask, hasn't the JDK added other convenience APIs? There
> have probably been 
> a few one-liners, but we are really trying to keep them to a minimum.
> Mainly, 
> convenience APIs are indeed convenient, but in many cases they add a
> lot of value in 
> other ways as well. Here are some examples.
> 
> ? - Stream::toList. We discussed this recently, so I won't restate
> everything. 
> Briefly, though, this can be used as a replacement for
> Collectors::toList, which is 
> used VERY frequently, it provides stronger semantics, and it's faster
> because it 
> avoids extra array allocation and copying.
> 
> ? - String::repeat. Repeating a String is a simple for-loop. However,
> if you look at 
> the implementation [1] there really is a lot going on here. It's a
> lot faster than 
> the straightforward code, because it peels off a few special cases,
> it uses a clever 
> doubling algorithm to call arraycopy a minimal number of times, and
> it deals with 
> things at the byte level, so it can create a String without any
> copying or any 
> codeset conversion. In addition to convenience, the value here is
> that it's much 
> faster than a simple for-loop that one might write instead. It also
> leverages the 
> JDK-internal String representation, which means that it does less
> allocation and 
> copying than other utility libraries would.
> 
> [1] 
> https://github.com/openjdk/jdk16/blob/master/src/java.base/share/classes/java/lang/String.java#L3560
> 
> ? - InputStream::transferTo. This is mostly a straightforward loop
> [2], but the 
> details are devilishly hard to get right. If you look at user code
> that does copying 
> like this, it usually gets some edge case wrong, for example, not
> handling partial 
> reads. The value provided here is not that it's faster than the code
> it would 
> replace, but that it relieves the caller of the responsibility of
> writing a loop 
> that's easy to get wrong (or to form a dependency on another library
> that has this 
> utility method).
> 
> [2] 
> https://github.com/openjdk/jdk16/blob/master/src/java.base/share/classes/java/io/InputStream.java#L777
> 
> Anyway, this is the sort of analysis and justification that I'd like
> to see for 
> convenience APIs. Such APIs need to be more than just a shorthand for
> something a 
> bit longer.
> 
> s'marks
> 



From vtewari at openjdk.java.net  Mon May 10 03:53:58 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Mon, 10 May 2021 03:53:58 GMT
Subject: RFR: 8266610: Method RandomAccessFile#length() returns 0 for
 block devices on linux. [v2]
In-Reply-To: 
References: 
 
 <1ozB7BjOCtV2kIuoczRaJMKX67EZKkZmnCEuKRgZfbg=.1ccb05de-03d3-4296-acca-bd710e3bd679@github.com>
 
 
Message-ID: 

On Sun, 9 May 2021 06:26:13 GMT, Alan Bateman  wrote:

> Could required os = linux added for test/jdk/java/nio/channels/FileChannel/BlockDeviceSize.java? As it is decribed only run as linux.

Sure, this is separate issue(https://bugs.openjdk.java.net/browse/JDK-8150539). We will fix it separately.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3914

From vtewari at openjdk.java.net  Mon May 10 03:53:59 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Mon, 10 May 2021 03:53:59 GMT
Subject: Integrated: 8266610: Method RandomAccessFile#length() returns 0 for
 block devices on linux.
In-Reply-To: 
References: 
Message-ID: 

On Fri, 7 May 2021 06:16:07 GMT, Vyom Tewari  wrote:

> RandomAccessFile.length() method for block device return always 0

This pull request has now been integrated.

Changeset: 69b96f9a
Author:    Vyom Tewari 
URL:       https://git.openjdk.java.net/jdk/commit/69b96f9a1b4a959c6b86f41c2259d9e4d47c8ede
Stats:     15 lines in 1 file changed: 12 ins; 2 del; 1 mod

8266610: Method RandomAccessFile#length() returns 0 for block devices on linux.

Reviewed-by: alanb, bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/3914

From dholmes at openjdk.java.net  Mon May 10 04:46:00 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 10 May 2021 04:46:00 GMT
Subject: RFR: 8266610: Method RandomAccessFile#length() returns 0 for
 block devices on linux. [v2]
In-Reply-To: 
References: 
 
 <1ozB7BjOCtV2kIuoczRaJMKX67EZKkZmnCEuKRgZfbg=.1ccb05de-03d3-4296-acca-bd710e3bd679@github.com>
 
 
 
Message-ID: 

On Mon, 10 May 2021 03:48:43 GMT, Vyom Tewari  wrote:

>>> Could required os = linux added for test/jdk/java/nio/channels/FileChannel/BlockDeviceSize.java? As it is decribed only run as linux.
>> 
>> Yes, good idea. Also maybe we can see about changing it to avoid the dependency on /dev/sda1.
>
>> Could required os = linux added for test/jdk/java/nio/channels/FileChannel/BlockDeviceSize.java? As it is decribed only run as linux.
> 
> Sure, this is separate issue(https://bugs.openjdk.java.net/browse/JDK-8150539). We will fix it separately.

@vyommani this has broken the build on macos as you are including a linux specific header file in non-linux code! Please backout or fix ASAP. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3914

From talden at gmail.com  Mon May 10 05:06:36 2021
From: talden at gmail.com (Aaron Scott-Boddendijk)
Date: Mon, 10 May 2021 17:06:36 +1200
Subject: Proposal for new interface: TimeSource
In-Reply-To: 
References: 
Message-ID: 

Yes please.

I often have people ask how they should solve exactly this problem and we
have several code-bases that have their own implementations of essentially
this interface.

We've used it not only for the request-contextual time localisation but for
controlling the stepping for data-processing and simulation.

A standard interface might also mean this makes its way into 1st-class
testing framework parameterisation.

--
Aaron Scott-Boddendijk


On Fri, May 7, 2021 at 11:28 AM Stephen Colebourne 
wrote:

> This is a proposal to add a new interface to java.time.*
>
>   public interface TimeSource {
>     public static TimeSource system() { ... }
>     public abstract Instant instant();
>     public default long millis() {
>       return instant().toEpochMilli();
>     }
>     public default Clock withZone(ZoneId zoneId) {
>       return Clock.of(this, zoneId);
>    }
>   }
>
> The existing `Clock` abstract class would be altered to implement the
> interface.
> A new static method `Clock.of(TimeSource, ZoneId)` would be added.
> No changes are needed to any other part of the API.
> (Could add `Instant.now(TimeSource)`, but it isn't entirely necessary)
>
> Callers would pass around and use `TimeSource` directly, for example
> by dependency injection.
>
>
> Why add this interface?
> I've seen various indications that there is a desire for an interface
> representing a supplier of `Instant`. Specifically this desire is
> driven by the "unnecessary" time zone that `java.time.Clock` contains.
> Put simply, if the only thing you want is an `Instant`, then `Clock`
> isn't the right API because it forces you to think about time zones.
>
> A key thing that this interface allows is the separation of the OS
> Clock from the time-zone (which should generally be linked to user
> localization). A good architecture would pass `TimeSource` around the
> system and combine it with a time-zone held in a `UserContext` to get
> a `Clock`. The current design of java.time.* does not enable that
> because the `TimeSource` concept does not exist. Developers either
> have to write their own interface, or use `Clock` and ignore the time
> zone.
>
> A `Supplier` obviously performs similar functionality, but it
> lacks discoverability and understandability. Plus, injecting
> generified interfaces tends to be painful.
>
> Downsides?
> None really, other than a new type in the JDK that probably should
> have been in Java 8.
>
>
> See this ThreeTen-Extra discussion
> - https://github.com/ThreeTen/threeten-extra/issues/150
>
> Joda-Time has a `MillisProvider` that is similar:
> -
> https://www.joda.org/joda-time/apidocs/org/joda/time/DateTimeUtils.MillisProvider.html
>
> Time4J has a `TimeSource`:
> -
> https://github.com/MenoData/Time4J/blob/master/base/src/main/java/net/time4j/base/TimeSource.java
>
> Spring has a `DateTimeContext` that separates the user localization as
> per the `UserContext` described above:
> -
> https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/format/datetime/standard/DateTimeContext.html
>
> There is a similar concept `TimeSource` in `sun.net.httpserver`
>
> There may be a case to name the interface `InstantSource`, however
> `TimeSource` is a fairly widely understood name for this concept.
>
>
> There is the potential to extend the interface with something similar
> to Kotlin's `TimeMark` that would allow access to the monotonic clock,
> suitable for measurement of durations without any leap second effects:
> - https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.time/-time-mark/
>
> Feedback?
>
> Stephen
>

From vtewari at openjdk.java.net  Mon May 10 05:42:13 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Mon, 10 May 2021 05:42:13 GMT
Subject: RFR: 8266610: Method RandomAccessFile#length() returns 0 for
 block devices on linux. [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 May 2021 12:17:11 GMT, Vyom Tewari  wrote:

>> RandomAccessFile.length() method for block device return always 0
>
> Vyom Tewari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed assigning -1 to uint64_t

I am working on it. i will provide fix ASAP.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3914

From orionllmain at gmail.com  Mon May 10 05:45:14 2021
From: orionllmain at gmail.com (Zheka Kozlov)
Date: Mon, 10 May 2021 12:45:14 +0700
Subject: Package-private members in java.util.ArrayList
Message-ID: 

Hi!

JEP 181 (Nestmates) was implemented in Java 11, however, there are still
many library classes with members that were declared package-private to
avoid synthetic bridge methods. For example, ArrayList and its friends have
the following declarations:

? transient Object[] elementData; // non-private to simplify nested class
access
? private class Itr implements Iterator {
        int cursor;       // index of next element to return
        int lastRet = -1; // index of last element returned; -1 if no such
        int expectedModCount = modCount;

        // prevent creating a synthetic constructor
        Itr() {}
        ...

        final void checkForComodification() {
            ...
        }
  }
? private class ListItr extends Itr implements ListIterator {
        ListItr(int index) {
            super();
            cursor = index;
        }
        ...
   }
? final class ArrayListSpliterator implements Spliterator {
        ArrayListSpliterator(int origin, int fence, int expectedModCount) {
            this.index = origin;
            this.fence = fence;
            this.expectedModCount = expectedModCount;
        }
        ...
   }

As far as I understand, this is no longer relevant and we can freely make
all these members private without undermining performance. This will make
the code more readable and will stop confusing readers. Can we do it?

Zheka.

From forax at univ-mlv.fr  Mon May 10 10:22:44 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 10 May 2021 12:22:44 +0200 (CEST)
Subject: [External] : Re: ReversibleCollection proposal
In-Reply-To: 
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <7457433b-0836-f45e-4b51-4c2ecdf7e7da@oracle.com>
 <427897615.2057286.1619612437790.JavaMail.zimbra@u-pem.fr>
 
 <906317823.1426529.1619873859193.JavaMail.zimbra@u-pem.fr>
 
 <2063372755.1742538.1620211264481.JavaMail.zimbra@u-pem.fr>
 
Message-ID: <255012227.325293.1620642164845.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "dfranken jdk" 
> ?: "Remi Forax" , "Stuart Marks" 
> Cc: "core-libs-dev" 
> Envoy?: Dimanche 9 Mai 2021 12:13:58
> Objet: Re: [External] : Re: ReversibleCollection proposal

> When I thought about Collection's role in the hierarchy, it seemed to
> me that 'Collection' is an interface for describing how elements are
> stored in a cardboard box (we can and and remove them) and that we
> might need a different, yet related, interface to describe how to
> retrieve the items from the box. This way we are not tied to the
> Collection hierarchy and we could have one Set implementation which is
> ordered and another Set implementation which is not and they would both
> still implement Collection, but only one would implement the interface.

So you want to model ReversibleSet as Set + Reversible,
Reversible being an interface with a small number of method specific to the fact that the implementation is reversible. 

This does not work well for two reasons,
- there is no syntax to represent the union of types in Java,
   Set & Reversible set = ...
  is not a valid syntax. You can use a type variable with several bounds instead but it does work nicely with the rest of the language (overidding, overloading, etc).

- having public methods that takes an interface with few methods is a common design error.
  Let suppose you have a method foo that only prints the elements of a collection, in that case you may want to type the first parameter as Iterable or Collection.
  But requirements change an now you want to prints the elements sorted, oops, you have to change the signature of the public method which may be something not possible
  depending how many "clients" this method has.
  Providing interfaces with a small number of access methods will lead to this kind of issue. 

> 
> Imagine an interface like 'java.lang.OrderedEnumerable` if you will
> with methods such as 'first(), last(), etc', then each implementation
> would be free to choose to implement the interface or not. I also
> thought about 'OrderedIterable', but there would be too much confusion
> with 'Iterable', but I think these are related too. Retrieving items is
> an iteration problem, not a storage problem.

The problem is that is you multiply the number of interfaces to access the elements, you add the dilemma of choice in the mix.
The first iteration of the Scala Collection were like this, too many interfaces, at least for my taste. 

> 
> While I would love to see the Collection hierarchy redesigned to also
> allow for ImmutableCollection which for instance would not have an
> `add(T e)` method, I don't think we can simply do something like that
> without breaking too many things.

Dear Santa, i want an interface BuilderCollection that only allows add() but no remove()/clear(), because if you can not remove elements, then all the iterators can implement the snapshot at the beginning semantics,
so no ConcurrentModificationException anymore. For me, being able to snapshot/freeze a collection is better than an ImmutableCollection, because it can be immutable when you want. 

Anyway, it's not gonna to happen, there is so many ways to slice an onion and each have pros and cons and providing all the possible interfaces is a good.way to make something simple complex.

> 
> So in short, separating retrieval aspects from storage aspects with a
> different interface might be the way to go.
> 
> Kind regards,
> 
> Dave Franken
> 

regards,
R?mi

> On Wed, 2021-05-05 at 12:41 +0200, forax at univ-mlv.fr wrote:
>> ----- Mail original -----
>> > De: "Stuart Marks" 
>> > ?: "Remi Forax" 
>> > Cc: "core-libs-dev" 
>> > Envoy?: Mercredi 5 Mai 2021 02:00:03
>> > Objet: Re: [External] : Re: ReversibleCollection proposal
>> 
>> > On 5/1/21 5:57 AM, forax at univ-mlv.fr?wrote:
>> > > I suppose the performance issue comes from the fact that
>> > > traversing a
>> > > LinkedHahSet is slow because it's a linked list ?
>> > > 
>> > > You can replace a LinkedHashSet by a List + Set, the List keeps
>> > > the values in
>> > > order, the Set avoids duplicates.
>> > > 
>> > > Using a Stream, it becomes
>> > > ?? Stream.of(getItemsFromSomeplace(), getItemsFromAnotherPlace(),
>> > > ?? getItemsFromSomeplaceElse())
>> > > ??? .flatMap(List::stream)
>> > > ??? .distinct()????????????? // use a Set internally
>> > > ??? .collect(toList());
>> > 
>> > The problem with any example is that simplifying assumptions are
>> > necessary for
>> > showing the example, but those assumptions enable it to be easily
>> > picked apart.
>> > Of
>> > course, the example isn't just a particular example; it is a
>> > *template* for a
>> > whole
>> > space of possible examples. Consider the possibility that the items
>> > processing
>> > client needs to do some intermediate processing on the first group
>> > of items
>> > before
>> > adding the other groups. This might not be possible to do using
>> > streams. Use
>> > your
>> > imagination.
>> > 
>> > > I think there are maybe some scenarios where ReversibleCollection
>> > > can be useful,
>> > > but they are rare, to the point where when there is a good
>> > > scenario for it
>> > > people will not recognize it because ReversibleCollection will
>> > > not be part of
>> > > their muscle memory.
>> > 
>> > I'm certain that uses of RC/RS will be rare in the beginning,
>> > because they will
>> > be
>> > new, and people won't be familar with them. And then there will the
>> > people who
>> > say
>> > "I can't use them because I'm stuck on JDK 11 / 8 / 7 / 6 ...." It
>> > was the same
>> > thing with lambdas and streams in Java 8, with List.of() etc in
>> > Java 9, records
>> > in
>> > Java 16, etc. This wasn't an argument not to add them, and it isn't
>> > an argument
>> > not
>> > to add RC/RS.
>> 
>> All the changes you are listing here are "client side" changes, the
>> ones that can be adopted quickly because they do not require to
>> change the API side of any libraries.
>> ReversibleCollection is an API side change, like generics is, those
>> changes have a far higher cost because you have to wait your library
>> dependencies to be updated.
>> On the Valhalla list, we have discussed several times about how to
>> alleviate those API side change cost using automatic bridging or
>> methods forwarding, even for Valhalla, we are currently moving in a
>> state where those mechanisms are not needed.
>> 
>> > 
>> > > There is a real value to add methods like
>> > > descendingSet/descendingList()/getFirst/getLast on existing
>> > > collections, but we
>> > > don't need a new interface (or two) for that.
>> > 
>> > It depends on what you mean by "need". Sure, we could get away
>> > without this;
>> > after
>> > all, we've survived the past twenty years without it, so we could
>> > probably
>> > survive
>> > the next twenty years as well.
>> > 
>> > It would indeed be useful to add various methods to List, Deque,
>> > SortedSet, and
>> > LinkedHashSet to provide a full set of methods on all of them. And
>> > it would also
>> > be
>> > nice to have those methods be similar to one another. An interface
>> > helps with
>> > that,
>> > but I agree, that's not really the reason to have an interface
>> > though.
>> > 
>> > The reversed-view concept could also be added individually to the
>> > different
>> > places.
>> > A reverse-ordered List is a List, a reverse-ordered Deque is a
>> > Deque, a
>> > reverse-ordered SortedSet is a SortedSet, and a reverse-ordered
>> > LinkedHashSet is
>> > a
>> > ... ? And what is the type of the keySet of a LinkedHashMap, that
>> > enables one to
>> > (say) get the last element?
>> 
>> see below
>> 
>> > 
>> > After working with a system like this for a while, it begins to
>> > emerge that
>> > there is
>> > an abstraction missing from the collections framework, something
>> > like an
>> > "ordered
>> > collection". People have been missing this for quite a long time.
>> > The most
>> > recent
>> > example (which this proposal builds on) is Tagir's proposal from a
>> > year ago. And
>> > it's been asked about several times before that.
>> > ReversibleCollection fills in
>> > that
>> > missing abstraction.
>> 
>> The abstraction already exists but it's not defined in term of
>> interface because it's an implementation decision and those are
>> cleanly separated in the current Collection design.
>> 
>> Let take a step back, the collection API defines basic data structure
>> operations in term of interfaces like List, Deque, Set, etc those
>> interfaces are decoupled from implementation capabilities like
>> mutable, nullable, ordered and checked.
>> 
>> Depending on the implementation capabilities, the interfaces method
>> implementation may throw an exception, non-mutable implementations
>> use UnsupportedOperationException, non-nullable implementations use
>> NPE and checked implementations use CCE.
>> 
>> So what is missing is methods on Collection interfaces that require
>> the collection implementation to be ordered like descendingList(),
>> getFirst(), etc.
>> Those methods that may throw a specific exception if the
>> implementation is not ordered, not UnsupportedOperationException but
>> a new one like NotOrderedException.
>> 
>> So to answer to your question about LinkedHashSet, the reverse-
>> ordered LinkedHashSet is a Set with a method descendingSet() that do
>> not throw NotOrderedException like any Set with an order.
>> 
>> To summarize, if we introduce ReversibleCollection, we should also
>> introduce ImmutableCollection, NonNullableCollection and
>> CheckedCollection.
>> I think it's better to consider the fact that being ordered as a
>> capability (hint: this is already what the Spliterator API does) and
>> not as a specific interface.
>> 
>> > 
>> > s'marks
>> 
> > R?mi

From forax at univ-mlv.fr  Mon May 10 10:31:34 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 10 May 2021 12:31:34 +0200 (CEST)
Subject: Collection::getAny discussion
In-Reply-To: 
References: <38af-60883900-4c5-3a732100@161619996>
 
 
 <838b3ee1-20ac-2baa-f477-03e92f4697c3@oracle.com>
 
Message-ID: <493527554.337130.1620642694051.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Stephen Colebourne" 
> ?: "core-libs-dev" 
> Envoy?: Vendredi 30 Avril 2021 23:15:45
> Objet: Re: Collection::getAny discussion

> On Fri, 30 Apr 2021 at 19:50, Stuart Marks  wrote:
>> You're asking for something that's somewhat different, which you called the
>> "find
>> the first element when there is only one" problem. Here, there's a precondition
>> that
>> the collection have a single element. (It's not clear to me what should happen
>> if
>> the collection has zero or more than one element.)
> 
> I think any get() or getAny() method on Collection is semantically
> equivalent to iterator.next(). I'm not sure there is another viable
> option.

Thinking a little more about conflating "first" and "any".
I wonder if we have not already cross the Rubicon on that matter,

If we have a HashSet or any collections and using Stream.findFirst()
  var collection = new HashSet<>(...); 
  var result = collection.stream().findFirst().orElseThrow();

We will get the result of collection.iterator().next()

So adding a default method getFirst() on Collection that returns the result of iterator().next() is pretty coherent, no ?

[...]

> 
> Stephen

R?mi

From lancea at openjdk.java.net  Mon May 10 10:45:05 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 10 May 2021 10:45:05 GMT
Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem
 [v5]
In-Reply-To: 
References: 
 
Message-ID: <6GQziWxp_-MON82UG9q0qaLJkmw_zreNfebpdlm5lzc=.c1687e50-28bd-4db5-8695-8ee2920b7ac6@github.com>

On Fri, 7 May 2021 03:10:32 GMT, Jason Zaugg  wrote:

>> If the given Path represents a file, use the overload of read defined
>> in FileChannel that accepts an explicit position and avoid serializing
>> reads.
>> 
>> Note: The underlying NIO implementation is not required to implement
>> FileChannel.read(ByteBuffer, long) concurrently; Windows still appears
>> to lock, as it returns true for NativeDispatcher.needsPositionLock.
>> 
>> 
>> On MacOS X, the enclosed benchmark improves from:
>> 
>> 
>> Benchmark                    Mode  Cnt   Score   Error  Units
>> ZipFileSystemBenchmark.read  avgt   10  75.311 ? 3.301  ms/op
>> 
>> 
>> To:
>> 
>> 
>> Benchmark                    Mode  Cnt   Score   Error  Units
>> ZipFileSystemBenchmark.read  avgt   10  12.520 ? 0.875  ms/op
>
> Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   [zipfs] Add missing check-failed exception to position/read test
>   
>   This appears to have been omitted when this test was added.
>   To avoid false error reports, the condition must deal with the
>   edge case of zero-length entries, for which read will return -1.

Mach5 jdk-tier1, jdk-tier, jdk-tier3 completed successfully

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3853

From thihup at gmail.com  Mon May 10 12:13:55 2021
From: thihup at gmail.com (Thiago Henrique Hupner)
Date: Mon, 10 May 2021 09:13:55 -0300
Subject: JDK Dynalink only works with unconditionally exported packages
Message-ID: 

Hi all.

I've been testing the JDK Dynalink recently and
I think I've found a bug.

The class jdk.dynalink.beans.CheckRestrictedPackage checks
if a package is restricted.

So, I have a class that has some static methods. But to Dynalink find the
class,
the class needs to be public. OK,
I've changed my class to be public. However, it needs that
the package of the class is exported in the module too.

I think this is a little too restrictive. I don't want to expose
to my users some internal implementation.

The main problem is that the method
CheckRestrictedPackage::isRestrictedClass
does the following check:

// ...
final String pkgName = name.substring(0, i);
final Module module = clazz.getModule();
if (module != null && !module.isExported(pkgName)) {
    return true;
 }
// ...

I have a feeling that this check should be changed to something like

// ...
final String pkgName = name.substring(0, i);
final Module module = clazz.getModule();
if (module != null && !module.isOpen(pkgName,
CheckRestrictedPackage.class.getModule())) {
    return true;
 }
// ...

In this way, my code can only "opens" a single package to the jdk.dynalink
module,
not having to unconditionally export a package.

>From what I could understand, in Nashorn, the generated classes
were defined in the unnamed module, that always exports all the packages,
so the access always worked.

The code can be found here:
https://github.com/openjdk/jdk/blob/master/src/jdk.dynalink/share/classes/jdk/dynalink/beans/CheckRestrictedPackage.java#L94

Best regards.

Thiago

From kevin.rushforth at oracle.com  Mon May 10 13:14:10 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 10 May 2021 06:14:10 -0700
Subject: [External] : Re: Proposal to add JavaScript platform to jpackage
In-Reply-To: 
References: 
 <99221D16-7066-495F-8AA8-E828F31EB831@gmail.com>
 
 <03adccfa-0253-ff1a-0620-9d5e3e925b96@oracle.com>
 
Message-ID: 

Regardless of whether you integrate into jpackage or provide a new 
"jspackage" tool, this presupposes the capability of running a set of 
Java class files on top of a JavaScript engine. Pointing to a 
third-party library that happens to implement this isn't sufficient to 
define this new platform. Given that you are targeting a platform / 
runtime environment that isn't part of the JDK, then I don't see why the 
packaging tool for that platform should be part of the JDK.

-- Kevin


On 5/8/2021 8:47 AM, Andrew Oliver wrote:
> Much of the feedback (public and private) from this proposal has 
> focused on integration with jpackage.? There is concern that jpackage 
> is strictly for platforms where the OpenJDK runtime is bundled with 
> the class files in an installer for distribution on that platform.? I 
> have a couple of questions for this list:
>
> 1. Is it the intent that jpackage _only_ be used for platforms where 
> the OpenJDK runtime is bundled, in whole or in part?? The descriptions 
> from the jpackage docs mentions taking a Java run-time image as input, 
> but then says it produces an application that "includes all the 
> necessary dependencies": "The |jpackage| tool will take as input a 
> Java application and a Java run-time image, and produce a Java 
> application image that includes all the necessary dependencies. It 
> will be able to produce a native package in a platform-specific 
> format, such as an exe on Windows or a dmg on macOS."
>
> In this case, the Java application will be converted to JavaScript, 
> and the required code to meet JLS semantics will be provided.? Since 
> the runtime binary (java.exe) isn't needed, it is not a necessary 
> dependency and is omitted.? The resulting native package is provided 
> in a platform-specific format (WAR or ZIP), as appropriate for a web 
> application.? To me, this certainly meets the letter of the jpackage 
> description, but perhaps not the spirit.? I'm interested in more 
> feedback on this point.
>
> 2. If the answer to (1) above is 'yes', jpackage is only suitable if 
> you plan to bundle OpenJDK VM code, then I will propose a new tool, 
> separate from jpackage.? The tentative name is "jspackage".
>
> The jspackage command will take as input a Java application, and 
> produce a web application that includes all of the necessary 
> dependencies.? It will produce a cross-platform web application bundle 
> in either WAR or ZIP format.
>
>
> On Mon, Apr 26, 2021 at 5:39 AM Kevin Rushforth 
> > wrote:
>
>     Without commenting on the value proposition of what you propose to
>     do, I
>     am fairly certain that jpackage is not the way to do it. The job of
>     jpackage is to take an application, bundle it with a Java Runtime,
>     and
>     create a native package / installer from it. What you are describing
>     goes far beyond that. You are describing a new capability of the JDK
>     that would take Java bytecode and compile it to run it on top of a
>     JavaScript engine.
>
>     > jpackage will use a JavaScript AOT compiler (TeaVM) to convert
>     the Java
>     > code to JavaScript, with the main class compiled to a JavaScript
>     method
>     > called 'main()'.
>
>     This is a good indicator that your proposal isn't simply targeting
>     a new
>     platform that already exists, and for which there is a Java
>     runtime that
>     supports running on this platform.
>
>     -- Kevin
>
>
>     On 4/25/2021 5:10 PM, Andrew Oliver wrote:
>     > While I agree it is a somewhat different platform than Linux,
>     Mac, or
>     > Windows, I do think the web is a platform worth targeting.? And
>     when seen
>     > through just a slightly different lens, it is more like the
>     others than it
>     > might first seem:
>     >
>     > On the platform:
>     > * It is difficult for users to run Java bytecode or JARs directly
>     > * Bytecode needs some form of transformation to operate efficiently
>     > * Packaging into a platform-specific format is required for easy
>     > distribution
>     > * Without a packager tool, developers have to surmount significant
>     > obstacles to distribute on the platform, reducing the appeal and
>     adoption
>     > of Java
>     >
>     > Yes, there are maven and gradle plugins available to allow Java
>     to target
>     > the JavaScript platform.? ( For example,
>     > https://teavm.org/docs/intro/getting-started.html
>     
>     )
>     >
>     > However, for many users a browser-friendly solution with a small
>     number of
>     > dependencies is going to be the only option.? Take, for example,
>     new users,
>     > students, and educational settings.? In many cases, programming
>     assignments
>     > are required to be posted on the web.? If the JDK could target
>     > self-contained web applications, as per this proposal, students
>     could
>     > easily post their assignments for the whole class to see.? This
>     would be
>     > much more reasonable than asking students to learn Java and
>     maven and POM
>     > files (and I'm saying that as a fan of maven).
>     >
>     > Lest people misinterpret the above as suggesting this JEP is
>     useful only in
>     > an educational context, many business projects these days need
>     to be web
>     > applications.? Users are often unwilling or unable to download
>     and install
>     > applications for short, quick, or one-off transactions. Thus
>     there is a
>     > large market for projects that absolutely require a web
>     presence.? This JEP
>     > would help illustrate how Java could be used even for front-end web
>     > development.? Yes, large-scale projects would likely use maven
>     or gradle.
>     > But for quick proofs-of-concept, little could make it easier to
>     demonstrate
>     > the ability to do front-end development in Java then easily
>     packaging a
>     > Java code into a ZIP and deploying on any web server (or a WAR on an
>     > application server, if desired).
>     >
>     >? ? -Andrew
>     >
>     > On Sat, Apr 24, 2021 at 10:39 PM Scott Palmer
>     > wrote:
>     >
>     >> This doesn?t seem like something that should be the job of
>     jpackage.? The
>     >> jpackage tool is currently used for producing platform-specific
>     packages or
>     >> installers targeted at end-users that include native launchers
>     and a JRE.
>     >> Web-based applications are an entirely different beast. This
>     seems like
>     >> more of a job for a Maven or Gradle plugin.
>     >>
>     >> Regards,
>     >>
>     >> Scott
>     >>
>     >>
>     >>> On Apr 24, 2021, at 5:59 PM, Andrew Oliver <93q62q at gmail.com
>     > wrote:
>     >>>
>     >>> Below is a Java Enhancement Proposal for your consideration to add
>     >>> JavaScript to jpackage as a new target platform. I would
>     appreciate
>     >>> feedback on the proposal contents.? I am also interested in
>     learning
>     >> about
>     >>> the process, specifically what approvals are required prior to
>     start of
>     >>> implementation, should sufficient consensus be reached.
>     >>>
>     >>> ( To view this proposal as a web page, please visit:
>     >>> https://frequal.com/TeaVM/openjdk/jdk-list-draft1.html
>     
>     )
>     >>>
>     >>> Thank you!
>     >>>
>     >>>? ?-Andrew Oliver
>     >>>
>     >>> Title: Add JavaScript platform to jpackage
>     >>> Author: Andrew Oliver
>     >>> Created: 2021/04/24
>     >>> Type: Feature
>     >>> State: Draft
>     >>> Exposure: Open
>     >>> Component: tools/jpackage
>     >>> Scope: JDK
>     >>> Discussion: core-libs-dev at openjdk.java.net
>     
>     >>> Template: 1.0
>     >>>
>     >>> Summary
>     >>> -------
>     >>>
>     >>> jpackage already allows packaging Java applications for several
>     >> platforms.
>     >>> This proposal adds a new platform: JavaScript.
>     >>>
>     >>> This effort will enable jpackage to convert bytecode from the
>     provided
>     >>> classes into JavaScript, and generate the required HTML to
>     invoke the
>     >>> specified main method when opened in a web browser. These
>     files will be
>     >>> bundled into a WAR file for easy deployment.
>     >>>
>     >>> Goals
>     >>> -----
>     >>>
>     >>> *? ?Enabling JVM languages to build client-side web applications
>     >>> *? ?Allow easy generation of JavaScript from JVM bytecode
>     >>> *? ?Allow easy deployment and execution of generated
>     JavaScript in web
>     >>> browsers
>     >>> *? ?Allow easy deployment of the generated JavaScript in all
>     web server
>     >>> environments
>     >>>? ? ?*? ?Java web application container (like Tomcat)
>     >>>? ? ?*? ?Static file web servers
>     >>>? ? ?*? ?Static file web hosting services
>     >>>
>     >>> Non-Goals
>     >>> ---------
>     >>>
>     >>> *? ?Allowing execution of JavaScript server-side. (Java
>     already has
>     >>> numerous options for executing bytecode server-side.)
>     >>>
>     >>> Motivation
>     >>> ----------
>     >>>
>     >>> Java was once used to create client-side web applications via
>     applets
>     >> that
>     >>> could be launched by visiting a web page. Applets could draw
>     on an area
>     >> of
>     >>> the screen (like HTML5 Canvas) or manipulate the page DOM to
>     create
>     >> dynamic
>     >>> front-end applications (like JS single-page apps).
>     >>>
>     >>> However, as evident in JEP 398 ([
>     >>>
>     https://openjdk.java.net/jeps/398](https://openjdk.java.net/jeps/398)
>     ),
>     >>> applets are no longer feasible due to the actions of browser
>     vendors.
>     >> While
>     >>> browsers have lost the ability to execute Java bytecode or
>     invoke methods
>     >>> from the Java class libraries, they do have mature engines for
>     executing
>     >> a
>     >>> different sort of code (JavaScript) and an extensive list of
>     useful APIs.
>     >>> By converting class files to JavaScript, and providing
>     mechanisms to
>     >> invoke
>     >>> browser APIs, Java can again be used to create in-browser
>     applications.
>     >>> [TeaVM](https://teavm.org
>     )
>     has demonstrated that this is feasible and
>     >> has
>     >>> numerous benefits:
>     >>>
>     >>> *? ?Provides a strongly-typed language for client-side web
>     development
>     >>> *? ?Provides a wealth of IDEs, build tools, and testing tools for
>     >>> client-side web development
>     >>> *? ?Allows teams with Java experience to produce apps with
>     familiar
>     >>> technology
>     >>> *? ?Allows sharing of POJO and business logic classes, simplifying
>     >>> development
>     >>> *? ?Allows options for porting applet- and JNLP-based systems to
>     >>> present-day browsers
>     >>>
>     >>> Details
>     >>> -------
>     >>>
>     >>> An additional jpackage option for type will be added: `js`
>     >>>
>     >>> jpackage will use a JavaScript AOT compiler (TeaVM) to convert
>     the Java
>     >>> code to JavaScript, with the main class compiled to a
>     JavaScript method
>     >>> called 'main()'.
>     >>>
>     >>> jpackage bundles application code, runtime, and resources into a
>     >>> platform-specific format. For this new JavaScript type, the
>     layout will
>     >> be
>     >>> either a ZIP file or a standard WAR file. The ZIP format will
>     contain the
>     >>> files ready to be extracted to a static file webserver or HTML
>     hosting
>     >>> service. Generated WARs will have the required structure to be
>     deployable
>     >>> in a Java web application container.
>     >>>
>     >>> ### WAR layout
>     >>>
>     >>> *? ?HelloApp.war
>     >>>? ? ?*? ?index.html (Main application page, loads classes.js
>     and invokes
>     >>> main())
>     >>>? ? ?*? ?teavm
>     >>>? ? ? ? ?*? ?classes.js (Class files, templates, and resources
>     compiled to
>     >>> JavaScript)
>     >>>? ? ?*? ?css
>     >>>? ? ? ? ?*? ?(CSS files from application)
>     >>>? ? ?*? ?META-INF
>     >>>? ? ? ? ?*? ?MANIFEST.MF
>     >>>? ? ?*? ?WEB-INF
>     >>>? ? ? ? ?*? ?web.xml
>     >>>
>     >>> ### ZIP Layout
>     >>>
>     >>> *? ?HelloApp.zip
>     >>>? ? ?*? ?index.html (Main application page, loads classes.js
>     and invokes
>     >>> main())
>     >>>? ? ?*? ?teavm
>     >>>? ? ? ? ?*? ?classes.js (Class files, templates, and resources
>     compiled to
>     >>> JavaScript)
>     >>>? ? ?*? ?css
>     >>>? ? ? ? ?*? ?(CSS files from application)
>     >>>
>     >>> Basic usage: Non-modular applications
>     >>> -------------------------------------
>     >>>
>     >>> Command-line usage is similar to jpackage today, except you
>     use the
>     >> `--type
>     >>> js`. For example, if you have your application JARs in a
>     folder called
>     >>> `lib` and the JAR with the declared `main()` method is
>     `main.jar`, you
>     >>> could use this command:
>     >>>
>     >>> ```
>     >>> $ jpackage --type js --name myapp --input lib --main-jar main.jar
>     >>> ```
>     >>>
>     >>> This will produce `myapp.war` in the current directory. This is a
>     >> standard
>     >>> WAR file ready for deployment in any web application container
>     (like
>     >>> Tomcat). When myapp/index.html is opened in a browser, the
>     code in main()
>     >>> will be executed, in-browser. A typical Hello World main()
>     method like
>     >>>
>     >>> ```
>     >>>? ? ?public static void main(String args\[\]) {
>     >>>? ? ? ? ?System.out.println("Hello, Browser!");
>     >>>? ? ?}
>     >>> ```
>     >>>
>     >>> will print the message on the browser developer console.
>     >>>
>     >>> Processing
>     >>> ----------
>     >>>
>     >>> Conversion of the input JAR files to the classes.js file will
>     be done by
>     >>> TeaVM. It will
>     >>>
>     >>> *? ?Convert provided class files to JavaScript
>     >>> *? ?Expose the specified main method as main()
>     >>> *? ?Provide implementation of selected core Java classes that
>     function
>     >> in a
>     >>> browser environment
>     >>> *? ?Bundle resources into the generated JavaScript
>     >>> *? ?Include images, css, and web.xml in the generated package, if
>     >> provided
>     >>> *? ?Provide default index.html if omitted
>     >>> *? ?Provide default web.xml if omitted and WAR format specified
>     >>> *? ?Optionally minify the generated JavaScript
>     >>>
>     >>> ### js-specific options
>     >>>
>     >>> 1.? `--minify`: Perform a minification pass after generating
>     JavaScript,
>     >>> renaming classes and methods to short, generated names to
>     reduce download
>     >>> sizes and provide some obfuscation.
>     >>> 2.? `--debug`: Enable generation of source maps.
>     >>> 3.? `--debug-full`: Enable generation of source maps and
>     bundled source
>     >>> files.
>     >>> 4.? `--optimization`: Choose simple, advanced, or full.
>     >>>? ? ?*? ?simple: Perform only basic optimizations
>     >>>? ? ?*? ?advanced: Perform more optimizations. Recommended for
>     production.
>     >>>? ? ?*? ?full: Perform aggressive optimizations. Increases
>     compilation
>     >> time.
>     >>> 5.? `--timezone-support`: Enables timezone support, at the cost of
>     >>> increased application size
>     >>> 6.? `--locale-list`: Add extra locales via a list, at the cost of
>     >> increased
>     >>> application size. Format: comma-separated list of locale IDs like
>     >> "en\_US,
>     >>> ru\_RU"
>     >>>
>     >>> ### Unsupported options for the JavaScript type
>     >>>
>     >>> These options are unsupported for `--type js`
>     >>>
>     >>> *? ?`--file-associations`: Not yet meaningful for a web-based
>     app, though
>     >>> it may be in the future once PWAs support file types: [
>     >>>
>     >>
>     https://github.com/WICG/file-handling](https://github.com/WICG/file-handling)
>     
>     >>> *? ?`--app-version, --copyright, --description, --license-file,
>     >> --vendor`:
>     >>> jpackage will only support --name initially. Users can customize
>     >> index.html
>     >>> (and the rest of the application) to show branding and metadata as
>     >> desired.
>     >>> *? ?`--java-options`: Not yet supported, use `--arguments`
>     instead.
>     >>>
>     >>> Caveats
>     >>> -------
>     >>>
>     >>> Certain Java classes are not feasible to implement in a
>     browser setting.
>     >>> Socket, for example, is not useful in a browser since
>     JavaScript cannot
>     >>> open arbitrary socket connections. Code using unavailable
>     classes will
>     >> fail
>     >>> during packaging time with warnings about the missing classes.
>     >>>
>     >>> Testing
>     >>> -------
>     >>>
>     >>> Since TeaVM is Java-based, tests will be able to run on any
>     platform.
>     >>>
>     >>> Testing will focus on the new jpackage code and added
>     functionality.
>     >> Tests
>     >>> will confirm that when valid parameters are provided, that
>     output is
>     >>> generated with the right name and in the right folder.
>     Contents of the
>     >>> generated ZIP and WAR files will be checked for the presence
>     of expected
>     >>> files. Testing generated files in a browser will be done manually.
>     >>>
>     >>> A thorough test of TeaVM itself is out of scope for the
>     jpackage testing.
>     >>> This is in line with jpackage testing for other platforms, in
>     which the
>     >>> external packaging tool (like Wix on Windows) isn't
>     exhaustively tested.
>     >>>
>     >>> Dependencies
>     >>> ------------
>     >>>
>     >>> The jpackage `js` type will require TeaVM binaries to be present.
>     >>>
>     >>> Implementation options:
>     >>>
>     >>> *? ?Download TeaVM on-demand and cache it. (This is the likely
>     option.)
>     >>>? ? ?*? ?Look for TeaVM in local repositories for popular build
>     tools like
>     >>> Maven and Gradle
>     >>>? ? ?*? ?If not found locally, download TeaVM binaries from the
>     read-only
>     >>> central repository and store in the cache folder
>     >>>? ? ?*? ?Invoke TeaVM from the local repository or cache
>     >>> *? ?Require that TeaVM binaries be installed locally
>     >>>? ? ?*? ?Provide the path to TeaVM binaries on the command line
>     >>> *? ?Bundle TeaVM
>     >>>? ? ?*? ?Challenging due to incompatible licenses (Apache v2
>     vs. GPL v2
>     >> with
>     >>> CPE)
>     >>>? ? ?*? ?Probably unnecessary given the options above. Other
>     jpackage
>     >>> options require pre-installed tools, this will be no different.
>     >>>
>     >>> High-Level Design
>     >>> -----------------
>     >>>
>     >>> A new bundler will be added to the jpackage Java source code.
>     >>>
>     >>> It will first ensure that TeaVM binaries (JAR files) are available
>     >> locally,
>     >>> as described in the section above.
>     >>>
>     >>> The new bundler will use TeaVM's TeaVMRunner ([
>     >>>
>     >>
>     https://github.com/konsoletyper/teavm/blob/master/tools/cli/src/main/java/org/teavm/cli/TeaVMRunner.java](https://github.com/konsoletyper/teavm/blob/master/tools/cli/src/main/java/org/teavm/cli/TeaVMRunner.java)
>     
>     >> ),
>     >>> which conveniently accepts options similar to jpackage itself.
>     >> TeaVMRunner
>     >>> will do the heavy lifting of converting the application JAR
>     files and
>     >>> resources into `classes.js`.
>     >>>
>     >>> The bundler will provide additional files required to make a web
>     >>> application, including an `index.html` to launch the `main()`
>     method. The
>     >>> bundler will create the final archive (ZIP or WAR) using Java's
>     >>> ZipOutputStream. For the WAR format, the bundler will also add
>     `web.xml`
>     >>> and `MANIFEST.MF` if not present to create a deployable,
>     standard WAR
>     >> file.
>     >>
>     >>
>


From vtewari at openjdk.java.net  Mon May 10 13:34:44 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Mon, 10 May 2021 13:34:44 GMT
Subject: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos
Message-ID: 

this change will  include  the below headers files to Linux only. 
#include 
#include 

-------------

Commit messages:
 - fixed the indentation
 - added the additional check so that modified code get executed on linux only.
 - JDK-8266797: Fix for 8266610 breaks the build on macos

Changes: https://git.openjdk.java.net/jdk/pull/3943/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3943&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266797
  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3943.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3943/head:pull/3943

PR: https://git.openjdk.java.net/jdk/pull/3943

From shade at openjdk.java.net  Mon May 10 13:34:45 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 10 May 2021 13:34:45 GMT
Subject: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 May 2021 06:34:36 GMT, Vyom Tewari  wrote:

> this change will  include  the below headers files to Linux only. 
> #include 
> #include 

MacOS builds fail with GHA since recently. So enabling GHA would serve a basic test for this to work.

src/java.base/unix/native/libjava/io_util_md.c line 39:

> 37: #if defined(__linux__)
> 38: #include 
> 39: #include 

Does Mac OS need `sys/stat.h`, though?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3943

From dholmes at openjdk.java.net  Mon May 10 13:34:44 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 10 May 2021 13:34:44 GMT
Subject: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 May 2021 06:34:36 GMT, Vyom Tewari  wrote:

> this change will  include  the below headers files to Linux only. 
> #include 
> #include 

Hi Vyom,

That fixes the include file problem but as this was obviously not tested on non-Linux have you checked that the rest of the fix for 8266610 works okay on non-Linux?

Thanks,
David

The /test functionality doesn't work. You need to either test locally or using GitHub actions.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3943

From jdv at openjdk.java.net  Mon May 10 13:34:46 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 10 May 2021 13:34:46 GMT
Subject: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 May 2021 06:34:36 GMT, Vyom Tewari  wrote:

> this change will  include  the below headers files to Linux only. 
> #include 
> #include 

Marked as reviewed by jdv (Reviewer).

In internal CI with fix tier 1 builds are running fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3943

From winterhalter at openjdk.java.net  Mon May 10 13:35:27 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Mon, 10 May 2021 13:35:27 GMT
Subject: RFR: 8266791: Annotation property which is compiled as an array
 property but changed to a single element throws NullPointerException
Message-ID: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com>

During annotation parsing, the parser assumes that a declared property is of an array type if the parsed annotation property is defined as an array. In this case, the component type is `null`, and a `NullPointerException` is thrown. This change discovers the mismatch and throws an `AnnotationTypeMismatchException`.

-------------

Commit messages:
 - 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException
 - 8266766: Arrays of types that cannot be an annotation member do not yield exceptions

Changes: https://git.openjdk.java.net/jdk/pull/3940/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3940&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266791
  Stats: 218 lines in 3 files changed: 216 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3940.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3940/head:pull/3940

PR: https://git.openjdk.java.net/jdk/pull/3940

From vtewari at openjdk.java.net  Mon May 10 13:34:46 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Mon, 10 May 2021 13:34:46 GMT
Subject: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos
In-Reply-To: 
References: 
 
Message-ID: <3Jr7VVGhJ7bQoTojaWRbMEq-lBPviJlX6zx9cxqu2QA=.d1d94683-30aa-4899-9181-cd4512dcb538@github.com>

On Mon, 10 May 2021 07:39:44 GMT, David Holmes  wrote:

> Hi Vyom,
> 
> That fixes the include file problem but as this was obviously not tested on non-Linux have you checked that the rest of the fix for 8266610 works okay on non-Linux?
> 
> Thanks,
> David

Hi David,

Original fix  was intended to  Linux specific. Current  Fix  will not impact other platforms. 

There is existing test (java/nio/channels/FileChannel/BlockDeviceSize.java) which test the new code but currently it is silently passing without running the test. This test requires root access.

Please see the bug( https://bugs.openjdk.java.net/browse/JDK-8150539) 

Thanks,
Vyom

-------------

PR: https://git.openjdk.java.net/jdk/pull/3943

From winterhalter at openjdk.java.net  Mon May 10 13:35:27 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Mon, 10 May 2021 13:35:27 GMT
Subject: RFR: 8266791: Annotation property which is compiled as an array
 property but changed to a single element throws NullPointerException
In-Reply-To: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com>
References: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com>
Message-ID: 

On Sun, 9 May 2021 21:59:29 GMT, Rafael Winterhalter  wrote:

> During annotation parsing, the parser assumes that a declared property is of an array type if the parsed annotation property is defined as an array. In this case, the component type is `null`, and a `NullPointerException` is thrown. This change discovers the mismatch and throws an `AnnotationTypeMismatchException`.

I implemented this change on top of https://bugs.openjdk.java.net/browse/JDK-8266766 to avoid replicating most of that pull requests changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3940

From prappo at openjdk.java.net  Mon May 10 13:34:47 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 10 May 2021 13:34:47 GMT
Subject: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos
In-Reply-To: <3Jr7VVGhJ7bQoTojaWRbMEq-lBPviJlX6zx9cxqu2QA=.d1d94683-30aa-4899-9181-cd4512dcb538@github.com>
References: 
 
 <3Jr7VVGhJ7bQoTojaWRbMEq-lBPviJlX6zx9cxqu2QA=.d1d94683-30aa-4899-9181-cd4512dcb538@github.com>
Message-ID: 

On Mon, 10 May 2021 08:46:15 GMT, Vyom Tewari  wrote:

>> Hi Vyom,
>> 
>> That fixes the include file problem but as this was obviously not tested on non-Linux have you checked that the rest of the fix for 8266610 works okay on non-Linux?
>> 
>> Thanks,
>> David
>
>> Hi Vyom,
>> 
>> That fixes the include file problem but as this was obviously not tested on non-Linux have you checked that the rest of the fix for 8266610 works okay on non-Linux?
>> 
>> Thanks,
>> David
> 
> Hi David,
> 
> Original fix  was intended to  Linux specific. Current  Fix  will not impact other platforms. 
> 
> There is existing test (java/nio/channels/FileChannel/BlockDeviceSize.java) which test the new code but currently it is silently passing without running the test. This test requires root access.
> 
> Please see the bug( https://bugs.openjdk.java.net/browse/JDK-8150539) 
> 
> Thanks,
> Vyom

@vyommani how are you going to test this?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3943

From vtewari at openjdk.java.net  Mon May 10 13:34:48 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Mon, 10 May 2021 13:34:48 GMT
Subject: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos
In-Reply-To: <3Jr7VVGhJ7bQoTojaWRbMEq-lBPviJlX6zx9cxqu2QA=.d1d94683-30aa-4899-9181-cd4512dcb538@github.com>
References: 
 
 <3Jr7VVGhJ7bQoTojaWRbMEq-lBPviJlX6zx9cxqu2QA=.d1d94683-30aa-4899-9181-cd4512dcb538@github.com>
Message-ID: 

On Mon, 10 May 2021 08:46:15 GMT, Vyom Tewari  wrote:

>> Hi Vyom,
>> 
>> That fixes the include file problem but as this was obviously not tested on non-Linux have you checked that the rest of the fix for 8266610 works okay on non-Linux?
>> 
>> Thanks,
>> David
>
>> Hi Vyom,
>> 
>> That fixes the include file problem but as this was obviously not tested on non-Linux have you checked that the rest of the fix for 8266610 works okay on non-Linux?
>> 
>> Thanks,
>> David
> 
> Hi David,
> 
> Original fix  was intended to  Linux specific. Current  Fix  will not impact other platforms. 
> 
> There is existing test (java/nio/channels/FileChannel/BlockDeviceSize.java) which test the new code but currently it is silently passing without running the test. This test requires root access.
> 
> Please see the bug( https://bugs.openjdk.java.net/browse/JDK-8150539) 
> 
> Thanks,
> Vyom

> @vyommani how are you going to test this?

I tested locally at my Linux environment. we have a test "java/nio/channels/FileChannel/BlockDeviceSize.java" but  it requires root privileged , i ran this as well as a root.  Please  have a look into this(https://bugs.openjdk.java.net/browse/JDK-8150539).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3943

From prappo at openjdk.java.net  Mon May 10 13:34:49 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 10 May 2021 13:34:49 GMT
Subject: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos
In-Reply-To: 
References: 
Message-ID: <5_yYWGa8o0ogFqz7Wrc4rpzbZ2nojBsOoip8gAmVVqo=.ba561d99-5457-4ff7-8a82-f351c6e36a5c@github.com>

On Mon, 10 May 2021 06:34:36 GMT, Vyom Tewari  wrote:

> this change will  include  the below headers files to Linux only. 
> #include 
> #include 

The fix to 8266610 caused a build failure on macOS. What is your plan to make sure this won't happen with this change?

I would recommend enabling [GitHub Actions](https://docs.github.com/en/github/administering-a-repository/disabling-or-limiting-github-actions-for-a-repository) for the "vyommani/jdk" repo.

I have run this PR through our CI: the tier1 tests are fine on all supported platforms. Please integrate this PR as soon as possible. 

Separately, please sort out the way you test your PRs. Read the error message that the failed GitHub Actions gave you:
> Prerequisites
> Actions jobs for this repository have been disabled by GitHub staff. If you are the repository owner, you can contact support via github.com/contact for more information.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3943

From jdv at openjdk.java.net  Mon May 10 13:34:49 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 10 May 2021 13:34:49 GMT
Subject: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos
In-Reply-To: 
References: 
 
 <3Jr7VVGhJ7bQoTojaWRbMEq-lBPviJlX6zx9cxqu2QA=.d1d94683-30aa-4899-9181-cd4512dcb538@github.com>
 
Message-ID: <7GpmINdOeimzs5Ytd0pe_LUFZmH2SpPnSS-y5IvSs0A=.304b3174-7f03-4f5a-931a-2de53956cc54@github.com>

On Mon, 10 May 2021 11:21:34 GMT, Vyom Tewari  wrote:

>>> Hi Vyom,
>>> 
>>> That fixes the include file problem but as this was obviously not tested on non-Linux have you checked that the rest of the fix for 8266610 works okay on non-Linux?
>>> 
>>> Thanks,
>>> David
>> 
>> Hi David,
>> 
>> Original fix  was intended to  Linux specific. Current  Fix  will not impact other platforms. 
>> 
>> There is existing test (java/nio/channels/FileChannel/BlockDeviceSize.java) which test the new code but currently it is silently passing without running the test. This test requires root access.
>> 
>> Please see the bug( https://bugs.openjdk.java.net/browse/JDK-8150539) 
>> 
>> Thanks,
>> Vyom
>
>> @vyommani how are you going to test this?
> 
> I tested locally at my Linux environment. we have a test "java/nio/channels/FileChannel/BlockDeviceSize.java" but  it requires root privileged , i ran this as well as a root.  Please  have a look into this(https://bugs.openjdk.java.net/browse/JDK-8150539).

@vyommani You can start tier1 CI build to make sure build passes with this fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3943

From vtewari at openjdk.java.net  Mon May 10 13:34:52 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Mon, 10 May 2021 13:34:52 GMT
Subject: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 May 2021 13:01:45 GMT, Jayathirth D V  wrote:

> In internal CI with fix tier 1 builds are running fine.

Ok i will integrate my changes now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3943

From dholmes at openjdk.java.net  Mon May 10 13:34:50 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 10 May 2021 13:34:50 GMT
Subject: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos
In-Reply-To: <3Jr7VVGhJ7bQoTojaWRbMEq-lBPviJlX6zx9cxqu2QA=.d1d94683-30aa-4899-9181-cd4512dcb538@github.com>
References: 
 
 <3Jr7VVGhJ7bQoTojaWRbMEq-lBPviJlX6zx9cxqu2QA=.d1d94683-30aa-4899-9181-cd4512dcb538@github.com>
Message-ID: 

On Mon, 10 May 2021 08:46:15 GMT, Vyom Tewari  wrote:

> Original fix was intended to Linux specific. Current Fix will not impact other platforms.

Your original fix failed to be Linux specific, so given you never actually tested it on other platforms you don't know whether another part of the fix is also not actually Linux-specific.

At a minimum ensure you have GitHub actions enabled so that your fixes get some basic cross-platform testing before they are integrated. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3943

From vtewari at openjdk.java.net  Mon May 10 13:34:49 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Mon, 10 May 2021 13:34:49 GMT
Subject: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos
In-Reply-To: 
References: 
 
 <3Jr7VVGhJ7bQoTojaWRbMEq-lBPviJlX6zx9cxqu2QA=.d1d94683-30aa-4899-9181-cd4512dcb538@github.com>
 
Message-ID: 

On Mon, 10 May 2021 11:21:34 GMT, Vyom Tewari  wrote:

>>> Hi Vyom,
>>> 
>>> That fixes the include file problem but as this was obviously not tested on non-Linux have you checked that the rest of the fix for 8266610 works okay on non-Linux?
>>> 
>>> Thanks,
>>> David
>> 
>> Hi David,
>> 
>> Original fix  was intended to  Linux specific. Current  Fix  will not impact other platforms. 
>> 
>> There is existing test (java/nio/channels/FileChannel/BlockDeviceSize.java) which test the new code but currently it is silently passing without running the test. This test requires root access.
>> 
>> Please see the bug( https://bugs.openjdk.java.net/browse/JDK-8150539) 
>> 
>> Thanks,
>> Vyom
>
>> @vyommani how are you going to test this?
> 
> I tested locally at my Linux environment. we have a test "java/nio/channels/FileChannel/BlockDeviceSize.java" but  it requires root privileged , i ran this as well as a root.  Please  have a look into this(https://bugs.openjdk.java.net/browse/JDK-8150539).

> @vyommani You can start tier1 CI build to make sure build passes with this fix.

can you please do let me know how to  start tier1 CI build ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3943

From vtewari at openjdk.java.net  Mon May 10 13:34:51 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Mon, 10 May 2021 13:34:51 GMT
Subject: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 May 2021 06:34:36 GMT, Vyom Tewari  wrote:

> this change will  include  the below headers files to Linux only. 
> #include 
> #include 

somehow tests not working for me. https://github.com/vyommani/jdk/actions/runs/827989185

-------------

PR: https://git.openjdk.java.net/jdk/pull/3943

From shade at openjdk.java.net  Mon May 10 13:34:57 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 10 May 2021 13:34:57 GMT
Subject: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 10 May 2021 10:27:34 GMT, Vyom Tewari  wrote:

>> src/java.base/unix/native/libjava/io_util_md.c line 39:
>> 
>>> 37: #if defined(__linux__)
>>> 38: #include 
>>> 39: #include 
>> 
>> Does Mac OS need `sys/stat.h`, though?
>
> No, change is specific to Linux. Please see(https://github.com/openjdk/jdk/commit/69b96f9a1b4a959c6b86f41c2259d9e4d47c8ede).

OK, so what you are saying is that the path that references `S_ISBLK` is protected by `BLKGETSIZE64` that is guaranteed to be undefined on OS X? If so, this is (awkwardly) fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3943

From vtewari at openjdk.java.net  Mon May 10 13:34:56 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Mon, 10 May 2021 13:34:56 GMT
Subject: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 May 2021 09:50:44 GMT, Aleksey Shipilev  wrote:

>> this change will  include  the below headers files to Linux only. 
>> #include 
>> #include 
>
> src/java.base/unix/native/libjava/io_util_md.c line 39:
> 
>> 37: #if defined(__linux__)
>> 38: #include 
>> 39: #include 
> 
> Does Mac OS need `sys/stat.h`, though?

No, change is specific to Linux. Please see(https://github.com/openjdk/jdk/commit/69b96f9a1b4a959c6b86f41c2259d9e4d47c8ede).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3943

From vtewari at openjdk.java.net  Mon May 10 13:34:59 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Mon, 10 May 2021 13:34:59 GMT
Subject: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Mon, 10 May 2021 10:44:10 GMT, Alan Bateman  wrote:

>> OK, so what you are saying is that the path that references `S_ISBLK` is protected by `BLKGETSIZE64` that is guaranteed to be undefined on OS X? If so, this is (awkwardly) fine.
>
> I think Vymon took the code from FileDispatcherImpl_size0, which has been compiling on macOS without issues. I don't mind if we fix the issue with this PR or just back it out and fix it with another PR.

I am not the Mac expert, but i checked on my MacOS Laptop and i did not found "BLKGETSIZE64" defined in sys/stat.h.
As Alan already told that i  took the code from FileDispatcherImpl.size0 and followed the same pattern.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3943

From alanb at openjdk.java.net  Mon May 10 13:34:59 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 10 May 2021 13:34:59 GMT
Subject: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 10 May 2021 10:31:40 GMT, Aleksey Shipilev  wrote:

>> No, change is specific to Linux. Please see(https://github.com/openjdk/jdk/commit/69b96f9a1b4a959c6b86f41c2259d9e4d47c8ede).
>
> OK, so what you are saying is that the path that references `S_ISBLK` is protected by `BLKGETSIZE64` that is guaranteed to be undefined on OS X? If so, this is (awkwardly) fine.

I think Vymon took the code from FileDispatcherImpl_size0, which has been compiling on macOS without issues. I don't mind if we fix the issue with this PR or just back it out and fix it with another PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3943

From vtewari at openjdk.java.net  Mon May 10 13:35:03 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Mon, 10 May 2021 13:35:03 GMT
Subject: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 May 2021 11:26:30 GMT, Alan Bateman  wrote:

>> this change will  include  the below headers files to Linux only. 
>> #include 
>> #include 
>
> src/java.base/unix/native/libjava/io_util_md.c line 256:
> 
>> 254:         return -1;
>> 255:     }
>> 256:     #if defined(__linux__) && defined(BLKGETSIZE64)
> 
> Looks okay although would be good to fix the indentation at L256 before you integrate.

done fixed the indentation

-------------

PR: https://git.openjdk.java.net/jdk/pull/3943

From vtewari at openjdk.java.net  Mon May 10 13:34:59 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Mon, 10 May 2021 13:34:59 GMT
Subject: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Mon, 10 May 2021 10:59:37 GMT, Vyom Tewari  wrote:

>> I think Vymon took the code from FileDispatcherImpl_size0, which has been compiling on macOS without issues. I don't mind if we fix the issue with this PR or just back it out and fix it with another PR.
>
> I am not the Mac expert, but i checked on my MacOS Laptop and i did not found "BLKGETSIZE64" defined in sys/stat.h.
> As Alan already told that i  took the code from FileDispatcherImpl.size0 and followed the same pattern.

I will fix in this PR only. i will do the changes for only "io_util_md.c".

-------------

PR: https://git.openjdk.java.net/jdk/pull/3943

From alanb at openjdk.java.net  Mon May 10 13:35:02 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 10 May 2021 13:35:02 GMT
Subject: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 May 2021 06:34:36 GMT, Vyom Tewari  wrote:

> this change will  include  the below headers files to Linux only. 
> #include 
> #include 

src/java.base/unix/native/libjava/io_util_md.c line 256:

> 254:         return -1;
> 255:     }
> 256:     #if defined(__linux__) && defined(BLKGETSIZE64)

Looks okay although would be good to fix the indentation at L256 before you integrate.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3943

From vtewari at openjdk.java.net  Mon May 10 13:34:59 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Mon, 10 May 2021 13:34:59 GMT
Subject: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: 

On Mon, 10 May 2021 11:09:07 GMT, Vyom Tewari  wrote:

>> I am not the Mac expert, but i checked on my MacOS Laptop and i did not found "BLKGETSIZE64" defined in sys/stat.h.
>> As Alan already told that i  took the code from FileDispatcherImpl.size0 and followed the same pattern.
>
> I will fix in this PR only. i will do the changes for only "io_util_md.c".

updated the PR as suggested.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3943

From vtewari at openjdk.java.net  Mon May 10 13:45:52 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Mon, 10 May 2021 13:45:52 GMT
Subject: Integrated: JDK-8266797: Fix for 8266610 breaks the build on macos
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 May 2021 06:34:36 GMT, Vyom Tewari  wrote:

> this change will  include  the below headers files to Linux only. 
> #include 
> #include 

This pull request has now been integrated.

Changeset: b823b3ef
Author:    Vyom Tewari 
URL:       https://git.openjdk.java.net/jdk/commit/b823b3ef2912c4c3b8412dff6ff4e9af81c5b910
Stats:     5 lines in 1 file changed: 3 ins; 0 del; 2 mod

8266797: Fix for 8266610 breaks the build on macos

Reviewed-by: dholmes, jdv

-------------

PR: https://git.openjdk.java.net/jdk/pull/3943

From asemenyuk at openjdk.java.net  Mon May 10 15:36:26 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 10 May 2021 15:36:26 GMT
Subject: RFR: 8266456: Replace direct TKit.run() calls with
 jdk.jpackage.test.Annotations.Test annotation [v2]
In-Reply-To: 
References: 
 
Message-ID: <2nurl9FvUInsxB0h6OPzQinEyfTe5MmfOYUlttdzhoI=.314ff190-278b-4b76-803c-161a1853bbaf@github.com>

On Sat, 8 May 2021 01:44:46 GMT, Alexander Matveev  wrote:

>> - Replaced direct TKit.run() calls with Test annotation.
>>  - Increased timeout for SigningPackageTest from default to 360 due to timeout. This is regression from JDK-8248904 due to changes done in signing and --remove-signature adds additional time since it is run per file.
>>  - Fixed issue with jtreg.SkippedException which caused test to fail instead of being skipped, since it was wrapped in ExceptionBox.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266456: Replace direct TKit.run() calls with jdk.jpackage.test.Annotations.Test annotation [v2]

Changes requested by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3911

From asemenyuk at openjdk.java.net  Mon May 10 15:36:26 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 10 May 2021 15:36:26 GMT
Subject: RFR: 8266456: Replace direct TKit.run() calls with
 jdk.jpackage.test.Annotations.Test annotation [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 7 May 2021 23:07:02 GMT, Alexander Matveev  wrote:

>> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Functional.java line 161:
>> 
>>> 159:         }
>>> 160: 
>>> 161:         if (throwable.getClass().getName().equals("jtreg.SkippedException")) {
>> 
>> Would it make sense to have check: `if (throwable instanceof Runnable)`?
>
> Not sure. I do not think it will work. SkippedException extends RuntimeException, so not sure why we need to check it with Runnable.

My point is that if the exception is Runnable, there is no need to wrap it in ExceptionBox instance.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3911

From naoto at openjdk.java.net  Mon May 10 16:28:54 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 10 May 2021 16:28:54 GMT
Subject: Integrated: 8266774: System property values for stdout/err on Windows
 UTF-8
In-Reply-To: <9jYN7sQh6DrukhjCgUco9DmnHkAqw2W3kb3TlonGLeM=.0cccb7ae-ad98-4453-a0e5-15efa3c71ca1@github.com>
References: <9jYN7sQh6DrukhjCgUco9DmnHkAqw2W3kb3TlonGLeM=.0cccb7ae-ad98-4453-a0e5-15efa3c71ca1@github.com>
Message-ID: 

On Fri, 7 May 2021 22:46:08 GMT, Naoto Sato  wrote:

> Please review this small fix to Windows system property init code. This is leftover from the support for `Console.charset()` method, where it lacked to initialize `sun.stdout/err.encoding` to `UTF-8` for the code page `cp65001`.  The fix has been manually verified, but no automated test case is provided, as automatically setting `UTF-8` for the system locale on Windows test machine seems not possible.

This pull request has now been integrated.

Changeset: c494efc5
Author:    Naoto Sato 
URL:       https://git.openjdk.java.net/jdk/commit/c494efc5b5d9a142fceff600285fd4c8c883e795
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8266774: System property values for stdout/err on Windows UTF-8

Reviewed-by: bpb, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/3931

From herrick at openjdk.java.net  Mon May 10 16:37:19 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 10 May 2021 16:37:19 GMT
Subject: RFR: 8266603: jpackage: Add missing copyright file in Java
 runtime .deb installers [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 May 2021 19:57:17 GMT, Alexey Semenyuk  wrote:

>> jpackage should create copyright file in /usr/share/doc directory tree when building .deb package for Java runtime with installation directory in /usr directory tree.
>> 
>> jpackage creates share/doc/copyright file in installation directory for apps installed outside of /usr tree.
>> 
>> jpackage creates /usr/share/doc/${package_name}/copyright file for apps installed in /usr tree .
>> 
>> jpackage doesn't create copyright file at all for Java runtime. The reason for this behavior was that jpackage should not place additional files in installation directory of Java runtime. However when installing Java runtime or app in /usr tree, copyright file will be placed outside of installation directory. Thus copyright file should be always created if package installation directory is inside of /usr tree.
>
> Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - trailing whitespaces removed
>  - 8266603: jpackage: Add missing copyright file in Java runtime .deb installers

Marked as reviewed by herrick (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3894

From herrick at openjdk.java.net  Mon May 10 16:40:56 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 10 May 2021 16:40:56 GMT
Subject: RFR: 8266456: Replace direct TKit.run() calls with
 jdk.jpackage.test.Annotations.Test annotation [v2]
In-Reply-To: 
References: 
 
Message-ID: <_mNqysqNTLpJWUO5tzC_yD3yyQ7rQCao8ysl-1mefeM=.c1729e62-4b5c-4102-99e2-d024756cd83f@github.com>

On Sat, 8 May 2021 01:44:46 GMT, Alexander Matveev  wrote:

>> - Replaced direct TKit.run() calls with Test annotation.
>>  - Increased timeout for SigningPackageTest from default to 360 due to timeout. This is regression from JDK-8248904 due to changes done in signing and --remove-signature adds additional time since it is run per file.
>>  - Fixed issue with jtreg.SkippedException which caused test to fail instead of being skipped, since it was wrapped in ExceptionBox.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266456: Replace direct TKit.run() calls with jdk.jpackage.test.Annotations.Test annotation [v2]

Marked as reviewed by herrick (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3911

From asemenyuk at openjdk.java.net  Mon May 10 16:43:25 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 10 May 2021 16:43:25 GMT
Subject: Integrated: 8266603: jpackage: Add missing copyright file in Java
 runtime .deb installers
In-Reply-To: 
References: 
Message-ID: 

On Thu, 6 May 2021 01:22:41 GMT, Alexey Semenyuk  wrote:

> jpackage should create copyright file in /usr/share/doc directory tree when building .deb package for Java runtime with installation directory in /usr directory tree.
> 
> jpackage creates share/doc/copyright file in installation directory for apps installed outside of /usr tree.
> 
> jpackage creates /usr/share/doc/${package_name}/copyright file for apps installed in /usr tree .
> 
> jpackage doesn't create copyright file at all for Java runtime. The reason for this behavior was that jpackage should not place additional files in installation directory of Java runtime. However when installing Java runtime or app in /usr tree, copyright file will be placed outside of installation directory. Thus copyright file should be always created if package installation directory is inside of /usr tree.

This pull request has now been integrated.

Changeset: c8b74474
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.java.net/jdk/commit/c8b744743bd54a00a4f7bf1e852d454fcd942abd
Stats:     27 lines in 2 files changed: 24 ins; 1 del; 2 mod

8266603: jpackage: Add missing copyright file in Java runtime .deb installers

Reviewed-by: almatvee, herrick

-------------

PR: https://git.openjdk.java.net/jdk/pull/3894

From wickund at gmail.com  Mon May 10 14:28:44 2021
From: wickund at gmail.com (Jim Laskey)
Date: Mon, 10 May 2021 11:28:44 -0300
Subject: RFR: CSR JDK-8266553 Technical corrections to
 java/util/random/package-info.java
Message-ID: 

Could I get a CSR review. Technical clarification in the javadoc.

Cheers,

-- Jim


CSR: https://bugs.openjdk.java.net/browse/JDK-8266553 
PR: https://github.com/openjdk/jdk/pull/3881 
Bug: https://bugs.openjdk.java.net/browse/JDK-8266552 


From mcimadamore at openjdk.java.net  Mon May 10 17:45:24 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 10 May 2021 17:45:24 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v14]
In-Reply-To: 
References: 
Message-ID: 

> 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://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant checks for --enable-native-access

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/1ce6366a..3aaeb09f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=12-13

  Stats: 64 lines in 7 files changed: 0 ins; 63 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From bpb at openjdk.java.net  Mon May 10 17:54:52 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 10 May 2021 17:54:52 GMT
Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes
 [v7]
In-Reply-To: 
References: 
Message-ID: <7DNAsNlR9qOFQ60l-pSzc1SfH9GdecjrZ9re51Jo9vQ=.54273097-3573-4d4d-98b4-d29a964a41ad@github.com>

> Please consider this request to override the `java.io.InputStream` methods `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more performant implementations. The method overrides attempt to read all requested bytes into a single array of the required size rather than composing the result from a sequence of smaller arrays. An example of the performance improvements is as follows.
> 
> **readAllBytes**
> Before
> 
> Benchmark                                    (length)   Mode  Cnt      Score     Error  Units
> ReadAllBytes.readAllBytesFileInputStream      1000000  thrpt   20   2412.031 ?   7.309  ops/s
> ReadAllBytes.readAllBytesFileInputStream     10000000  thrpt   20    212.181 ?   0.369  ops/s
> ReadAllBytes.readAllBytesFileInputStream    100000000  thrpt   20     19.860 ?   0.048  ops/s
> ReadAllBytes.readAllBytesFileInputStream   1000000000  thrpt   20      1.298 ?   0.183  ops/s
> 
> After
> 
> Benchmark                                    (length)   Mode  Cnt      Score     Error  Units
> ReadAllBytes.readAllBytesFileInputStream      1000000  thrpt   20   8218.473 ?  43.425  ops/s
> ReadAllBytes.readAllBytesFileInputStream     10000000  thrpt   20    302.781 ?   1.273  ops/s
> ReadAllBytes.readAllBytesFileInputStream    100000000  thrpt   20     22.461 ?   0.084  ops/s
> ReadAllBytes.readAllBytesFileInputStream   1000000000  thrpt   20      1.502 ?   0.003  ops/s
> 
> 
> **readNBytes**
> 
> `N = file_size / 2`
> 
> Before
> 
> Benchmark                                    (length)   Mode  Cnt      Score     Error  Units
> ReadAllBytes.readHalfBytesFileInputStream     1000000  thrpt   20   5585.500 ? 153.353  ops/s
> ReadAllBytes.readHalfBytesFileInputStream    10000000  thrpt   20    436.164 ?   1.104  ops/s
> ReadAllBytes.readHalfBytesFileInputStream   100000000  thrpt   20     40.167 ?   0.141  ops/s
> ReadAllBytes.readHalfBytesFileInputStream  1000000000  thrpt   20      3.291 ?   0.211  ops/s
> 
> 
> After
> 
> Benchmark                                    (length)   Mode  Cnt      Score     Error  Units
> ReadAllBytes.readHalfBytesFileInputStream     1000000  thrpt   20  15463.210 ?  66.045  ops/s
> ReadAllBytes.readHalfBytesFileInputStream    10000000  thrpt   20    561.752 ?   0.951  ops/s
> ReadAllBytes.readHalfBytesFileInputStream   100000000  thrpt   20     45.043 ?   0.102  ops/s
> ReadAllBytes.readHalfBytesFileInputStream  1000000000  thrpt   20      4.629 ?   0.035  ops/s

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8264777: Handle readNBytes(0): src/test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3845/files
  - new: https://git.openjdk.java.net/jdk/pull/3845/files/5272d5ef..4fae0209

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3845&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3845&range=05-06

  Stats: 6 lines in 2 files changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3845.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3845/head:pull/3845

PR: https://git.openjdk.java.net/jdk/pull/3845

From mcimadamore at openjdk.java.net  Mon May 10 18:15:01 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 10 May 2021 18:15:01 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v15]
In-Reply-To: 
References: 
Message-ID: 

> 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://openjdk.java.net/jeps/412

Maurizio Cimadamore 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 23 additional commits since the last revision:

 - Merge branch 'master' into JEP-412
 - Remove redundant checks for --enable-native-access
 - Fix issue in snippet in package-info
 - Replace uses of -Djdk.foreign.restricted (useless now) with --enable-native-access
 - Fix message string in Reflection::ensureNativeAccess
 - Tweak comment in Module::enableNativeAccess
 - Tweak code some more
 - Use uniform naming convention for implementation metods in Module
 - Remove IllegalNativeAccessChecker
 - Remove redundant initializer in Module
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/bb4038eb...8de9da36

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/3aaeb09f..8de9da36

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=13-14

  Stats: 33173 lines in 668 files changed: 19837 ins; 7268 del; 6068 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From jlaskey at openjdk.java.net  Mon May 10 18:17:30 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 10 May 2021 18:17:30 GMT
Subject: RFR: 8265208: [JEP-356] : SplittableRandom and
 SplittableGenerators - splits() methods does not throw NullPointerException
 when source is null [v2]
In-Reply-To: 
References: 
Message-ID: 

> Add check for null.

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into 8265208
 - Check for null source
 - Make makeXXXSpliterator final
 - Move makeXXXSpilterator from public (@hidden) to protected. No API change.

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3495/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3495&range=01
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3495.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3495/head:pull/3495

PR: https://git.openjdk.java.net/jdk/pull/3495

From rriggs at openjdk.java.net  Mon May 10 18:25:02 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 10 May 2021 18:25:02 GMT
Subject: RFR: 8265208: [JEP-356] : SplittableRandom and
 SplittableGenerators - splits() methods does not throw NullPointerException
 when source is null [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 May 2021 18:17:30 GMT, Jim Laskey  wrote:

>> Add check for null.
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into 8265208
>  - Check for null source
>  - Make makeXXXSpliterator final
>  - Move makeXXXSpilterator from public (@hidden) to protected. No API change.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3495

From sviswanathan at openjdk.java.net  Mon May 10 18:31:30 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Mon, 10 May 2021 18:31:30 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v4]
In-Reply-To: 
References: 
Message-ID: 

> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).
> 
> Changes include:
>  * Rewrite Vector API slice/unslice using already intrinsic methods
>  * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
>  * Vector API conversion tests thresholds adjustment
>  
> Base Performance:
> Benchmark (size) Mode Cnt Score Error Units
> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms
> 
> Performance with patch:
> Benchmark (size) Mode Cnt Score Error Units
> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  library_call.cpp changes not needed after Objects.checkIndex arguments fixed

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3804/files
  - new: https://git.openjdk.java.net/jdk/pull/3804/files/94f184ef..14439667

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3804&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3804&range=02-03

  Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3804.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3804/head:pull/3804

PR: https://git.openjdk.java.net/jdk/pull/3804

From sviswanathan at openjdk.java.net  Mon May 10 18:36:45 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Mon, 10 May 2021 18:36:45 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v3]
In-Reply-To: 
References: 
 
 
 <-VJVRq98DoOIRYPdSB8b2k1oOAI2vHeyKgo00bvGbSE=.00ef20ca-d072-4426-9e8e-c0e5433d3440@github.com>
 
Message-ID: <5EgHtRxBzhDqAo_lhlf8yYWw5J9yPaYsHUtlf7Db1mw=.836e61e6-0caf-4ff7-ad83-cfbcfb907723@github.com>

On Fri, 30 Apr 2021 23:34:15 GMT, Paul Sandoz  wrote:

>>> @PaulSandoz would it be possible for you to run this through your testing?
>> 
>> Started, will report back when done.
>
>> > @PaulSandoz would it be possible for you to run this through your testing?
>> 
>> Started, will report back when done.
> 
> Tier 1 to 3 tests all pass on build profiles linux-x64 linux-aarch64 macosx-x64 windows-x64

@PaulSandoz After we fixed the Objects.checkIndex arguments per your review comment, the changes in library_call.cpp are no more needed so I have backed them out.  That leaves only changes in vector api code which you have reviewed. Please let me know if it is ok to push.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From jlaskey at openjdk.java.net  Mon May 10 18:54:57 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 10 May 2021 18:54:57 GMT
Subject: Integrated: 8265208: [JEP-356] : SplittableRandom and
 SplittableGenerators - splits() methods does not throw NullPointerException
 when source is null
In-Reply-To: 
References: 
Message-ID: 

On Wed, 14 Apr 2021 17:33:30 GMT, Jim Laskey  wrote:

> Add check for null.

This pull request has now been integrated.

Changeset: 0cc7833f
Author:    Jim Laskey 
URL:       https://git.openjdk.java.net/jdk/commit/0cc7833f3d84971dd03a9a620585152a6debb40e
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8265208: [JEP-356] : SplittableRandom and SplittableGenerators - splits() methods does not throw NullPointerException when source is null

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/3495

From psandoz at openjdk.java.net  Mon May 10 19:05:20 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 10 May 2021 19:05:20 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 May 2021 18:31:30 GMT, Sandhya Viswanathan  wrote:

>> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).
>> 
>> Changes include:
>>  * Rewrite Vector API slice/unslice using already intrinsic methods
>>  * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
>>  * Vector API conversion tests thresholds adjustment
>>  
>> Base Performance:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms
>> 
>> Performance with patch:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   library_call.cpp changes not needed after Objects.checkIndex arguments fixed

I don't claim to understand the HotSpot details, but Java changes still look good.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3804

From mchung at openjdk.java.net  Mon May 10 19:20:27 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 10 May 2021 19:20:27 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v15]
In-Reply-To: 
References: 
 
Message-ID: 

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://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore 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 23 additional commits since the last revision:
> 
>  - Merge branch 'master' into JEP-412
>  - Remove redundant checks for --enable-native-access
>  - Fix issue in snippet in package-info
>  - Replace uses of -Djdk.foreign.restricted (useless now) with --enable-native-access
>  - Fix message string in Reflection::ensureNativeAccess
>  - Tweak comment in Module::enableNativeAccess
>  - Tweak code some more
>  - Use uniform naming convention for implementation metods in Module
>  - Remove IllegalNativeAccessChecker
>  - Remove redundant initializer in Module
>  - ... and 13 more: https://git.openjdk.java.net/jdk/compare/5a35ba03...8de9da36

The caller-sensitive cleanup change looks good.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 148:

> 146:      * @throws IllegalArgumentException in the case of a method type and function descriptor mismatch.
> 147:      * {@code --enable-native-access} is either absent, or does not mention the module name {@code M}, or
> 148:      * {@code ALL-UNNAMED} in case {@code M} is an unnamed module.

line 147-148 are leftover from ICE and they should be removed.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 209:

> 207:      * than the thread owning {@code scope}.
> 208:      * {@code --enable-native-access} is either absent, or does not mention the module name {@code M}, or
> 209:      * {@code ALL-UNNAMED} in case {@code M} is an unnamed module.

line 208-209 are also left-over from the last patch.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractCLinker.java line 44:

> 42:     @CallerSensitive
> 43:     public final MethodHandle downcallHandle(Addressable symbol, MethodType type, FunctionDescriptor function) {
> 44:         Reflection.ensureNativeAccess(Reflection.getCallerClass());

`downcallHandle` method is no longer caller-sensitive.  `@CallerSensitive` and `Reflection.ensureNativeAccess` are no longer needed.    Same for the 4-arg `downcallHandle` method.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/LibrariesHelper.java line 38:

> 36: import jdk.internal.loader.NativeLibrary;
> 37: import jdk.internal.reflect.CallerSensitive;
> 38: import jdk.internal.reflect.Reflection;

I think these 2 imports are no longer used.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/AArch64Linker.java line 37:

> 35: import jdk.internal.foreign.abi.UpcallStubs;
> 36: import jdk.internal.reflect.CallerSensitive;
> 37: import jdk.internal.reflect.Reflection;

These 2 imports are no longer needed.  Same for other CLinker implementation classes.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3699

From mandy.chung at oracle.com  Mon May 10 19:26:33 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 10 May 2021 12:26:33 -0700
Subject: Review CSR JDK-8266760: Remove sun.misc.Unsafe::defineAnonymousClass
Message-ID: <07d57bb9-1787-b86a-0009-d7690745986c@oracle.com>

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.net/browse/JDK-8266760

Comments?

Mandy

From forax at univ-mlv.fr  Mon May 10 19:36:03 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 10 May 2021 21:36:03 +0200 (CEST)
Subject: Review CSR JDK-8266760: Remove
 sun.misc.Unsafe::defineAnonymousClass
In-Reply-To: <07d57bb9-1787-b86a-0009-d7690745986c@oracle.com>
References: <07d57bb9-1787-b86a-0009-d7690745986c@oracle.com>
Message-ID: <132617846.862177.1620675363150.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "mandy chung" 
> ?: "core-libs-dev" , "valhalla-dev" 
> Envoy?: Lundi 10 Mai 2021 21:26:33
> Objet: Review CSR JDK-8266760: Remove sun.misc.Unsafe::defineAnonymousClass

> 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.net/browse/JDK-8266760
> 
> Comments?

Do it.

I will be brave and not cry too much :)

> 
> Mandy

R?mi

From mcimadamore at openjdk.java.net  Mon May 10 20:43:20 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 10 May 2021 20:43:20 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: 
References: 
Message-ID: 

> 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://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  * Remove unused imports
  * Fix broken javadoc after removal of @throws clauses
  * Remove other `@CallerSensitive` annotations from `AbstractCLinker`

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/8de9da36..6701654c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=14-15

  Stats: 24 lines in 7 files changed: 0 ins; 23 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Mon May 10 20:47:15 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 10 May 2021 20:47:15 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v3]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 
Message-ID: 

On Fri, 30 Apr 2021 17:20:21 GMT, Mandy Chung  wrote:

>>> I think the implementation does not support that. I will also need to look into how this impacts JDK-8266010. As I suggest earlier, I'm fine to do this as a follow up after integration.
>> 
>> 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 access enabled), and make sure that all call fails as expected (e.g. that caller context is that of the lookup module).
>> 
>> Surprisingly, CheckCSMs does NOT fail if both interface and implementation methods are `@CS` annotated - but if only interface is annotated, the test fails. This seems odd - since I can't find any logic in the test which check for overriding. Is the test accidentally passing?
>
>> 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 access enabled), and make sure that all call fails as expected (e.g. that caller context is that of the lookup module).
> 
> Thanks.
>  
>> Surprisingly, CheckCSMs does NOT fail if both interface and implementation methods are `@CS` annotated - but if only interface is annotated, the test fails. This seems odd - since I can't find any logic in the test which check for overriding. Is the test accidentally passing?
> 
> I create JDK-8266383 and I will look into that.

Thanks for the review @mlchung - hopefully looks better now!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From vlivanov at openjdk.java.net  Mon May 10 21:03:56 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 10 May 2021 21:03:56 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 May 2021 18:31:30 GMT, Sandhya Viswanathan  wrote:

>> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).
>> 
>> Changes include:
>>  * Rewrite Vector API slice/unslice using already intrinsic methods
>>  * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
>>  * Vector API conversion tests thresholds adjustment
>>  
>> Base Performance:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms
>> 
>> Performance with patch:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   library_call.cpp changes not needed after Objects.checkIndex arguments fixed

Looks good.

PS: I still think there's a problem with `LibraryCallKit::inline_preconditions_checkIndex`: it shouldn't bail out intrinsification in the middle of the process leaving a partially constructed graph behind. I don't see why short-circuiting the logic once the path is dead (`if (stopped()) return true;`) won't work. But that's a topic for another fix.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3804

From vlivanov at openjdk.java.net  Mon May 10 21:07:55 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 10 May 2021 21:07:55 GMT
Subject: RFR: 8266317: Vector API enhancements
In-Reply-To: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com>
References: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com>
Message-ID: 

On Thu, 29 Apr 2021 21:13:38 GMT, Paul Sandoz  wrote:

> This PR contains API and implementation changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Enhancements are made to the API for the support of operations on characters, such as for UTF-8 character decoding. Specifically, methods for loading/storing a `short` vector from/to a `char[]` array, and new vector comparison operators for unsigned comparisons with integral vectors. The x64 implementation is enhanced to supported unsigned comparisons.
> 
> Enhancements are made to the API for loading/storing a `byte` vector from/to a `boolean[]` array.
> 
> The testing of loads/stores can be expanded for scatter/gather, but before doing that i think some refactoring of the tests is required to reposition tests in the right classes. I would like to do that work after integration of the PR.

Looks good.

src/hotspot/cpu/aarch64/aarch64.ad line 2440:

> 2438: }
> 2439: 
> 2440: bool Matcher::supports_unsigned_vector_comparison(int vlen, BasicType bt) {

`Matcher::supports_vector_comparison_unsigned()` looks a better fit.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3803

From paul.sandoz at oracle.com  Mon May 10 21:27:07 2021
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 10 May 2021 21:27:07 +0000
Subject: Review CSR JDK-8266760: Remove
 sun.misc.Unsafe::defineAnonymousClass
In-Reply-To: <07d57bb9-1787-b86a-0009-d7690745986c@oracle.com>
References: <07d57bb9-1787-b86a-0009-d7690745986c@oracle.com>
Message-ID: 

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. `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.net/browse/JDK-8266760
> 
> Comments?
> 
> Mandy


From psandoz at openjdk.java.net  Mon May 10 21:37:26 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 10 May 2021 21:37:26 GMT
Subject: RFR: 8266317: Vector API enhancements [v2]
In-Reply-To: 
References: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com>
 
Message-ID: <-VH0nuTVCK1JwXG0B_4BUmrxhqKX6T1I5e6B81Gcj6E=.23cc42c0-7b89-48d5-bbe2-bf7b0557b3c6@github.com>

On Mon, 10 May 2021 21:05:02 GMT, Vladimir Ivanov  wrote:

>> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename method.
>
> src/hotspot/cpu/aarch64/aarch64.ad line 2440:
> 
>> 2438: }
>> 2439: 
>> 2440: bool Matcher::supports_unsigned_vector_comparison(int vlen, BasicType bt) {
> 
> `Matcher::supports_vector_comparison_unsigned()` looks a better fit.

I renamed the method (see commit).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3803

From psandoz at openjdk.java.net  Mon May 10 21:37:25 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 10 May 2021 21:37:25 GMT
Subject: RFR: 8266317: Vector API enhancements [v2]
In-Reply-To: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com>
References: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com>
Message-ID: 

> This PR contains API and implementation changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Enhancements are made to the API for the support of operations on characters, such as for UTF-8 character decoding. Specifically, methods for loading/storing a `short` vector from/to a `char[]` array, and new vector comparison operators for unsigned comparisons with integral vectors. The x64 implementation is enhanced to supported unsigned comparisons.
> 
> Enhancements are made to the API for loading/storing a `byte` vector from/to a `boolean[]` array.
> 
> The testing of loads/stores can be expanded for scatter/gather, but before doing that i think some refactoring of the tests is required to reposition tests in the right classes. I would like to do that work after integration of the PR.

Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:

  Rename method.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3803/files
  - new: https://git.openjdk.java.net/jdk/pull/3803/files/de210a88..93b093c1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3803&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3803&range=00-01

  Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3803.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3803/head:pull/3803

PR: https://git.openjdk.java.net/jdk/pull/3803

From rafael.wth at gmail.com  Mon May 10 21:40:01 2021
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Mon, 10 May 2021 23:40:01 +0200
Subject: Would lambda expressions be meaningful annotation properties?
Message-ID: 

Hello, I was wondering if there was ever any consideration of allowing
(stateless) lambda expressions as annotation members. As an example, this
would make the following lambda expression possible:

@interface MyAnnotation {
  Supplier value();
}

In many enterprise applications, this would be a very helpful addition and
replace a rather complicated pattern with little type-safety. For example,
in Spring, beans can be registered conditionally. Today, this requires
declaring a class that implements the Condition interface which then can be
supplied as an argument to the Conditional annotation:

public class MyCondition implements Condition {
  @Override
  public boolean matches(ConditionContext context, AnnotatedTypeMetadata
metadata) {
    return MyCode.isEnabled(context, metadata)
  }
}

which is then used in:

@Conditional(MyCondition.class) @Bean
public MyBean myBean() { ... }

By allowing stateless lambda expressions as annotation members, this could
be simplified to:

@Conditional(MyCode::isEnabled) @Bean
public MyBean myBean() { ... }

Another example where this would improve code readability a lot would be
bean validation frameworks, where custom constraints could be moved
directly to a property:

class MyBean {
  @Valid(value -> value != null && MyCode.validate(value))
  String property;
}

I observe such patterns regularly and therefore, I was curious if such a
feature was ever discussed or if this would be considered for a future
version. I understand that the intention of annotations is to provide
declarative metadata which can be processed also for unloaded code, but I
still feel like this would be a useful extension. The lambda expression
would be implicitly stateless, but of course they represent code that
requires class loading and would therefore be not necessarily meaningful to
annotation processors or other static code processing tools. If this would
be a feature to consider and only not a priority, I would be happy to
contribute, given I could get some help around the formalities of such a
process.

Thanks, Rafael

From vlivanov at openjdk.java.net  Mon May 10 21:45:59 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 10 May 2021 21:45:59 GMT
Subject: RFR: 8266317: Vector API enhancements [v2]
In-Reply-To: 
References: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com>
 
Message-ID: <_XzaNLzjaTHQjUkhPO6Ur4ZR1hneCfa-gnqBS397jpA=.3685e964-bf60-4b04-9fdc-2e3d01960d6b@github.com>

On Mon, 10 May 2021 21:37:25 GMT, Paul Sandoz  wrote:

>> This PR contains API and implementation changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
>> 
>> Enhancements are made to the API for the support of operations on characters, such as for UTF-8 character decoding. Specifically, methods for loading/storing a `short` vector from/to a `char[]` array, and new vector comparison operators for unsigned comparisons with integral vectors. The x64 implementation is enhanced to supported unsigned comparisons.
>> 
>> Enhancements are made to the API for loading/storing a `byte` vector from/to a `boolean[]` array.
>> 
>> The testing of loads/stores can be expanded for scatter/gather, but before doing that i think some refactoring of the tests is required to reposition tests in the right classes. I would like to do that work after integration of the PR.
>
> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename method.

Marked as reviewed by vlivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3803

From sviswanathan at openjdk.java.net  Mon May 10 21:49:14 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Mon, 10 May 2021 21:49:14 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 May 2021 18:31:30 GMT, Sandhya Viswanathan  wrote:

>> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).
>> 
>> Changes include:
>>  * Rewrite Vector API slice/unslice using already intrinsic methods
>>  * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
>>  * Vector API conversion tests thresholds adjustment
>>  
>> Base Performance:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms
>> 
>> Performance with patch:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   library_call.cpp changes not needed after Objects.checkIndex arguments fixed

Thanks a lot for the review Paul and Vladimir.
Vladimir, I will submit a separate patch for LibraryCallKit::inline_preconditions_checkIndex fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From brian.goetz at oracle.com  Mon May 10 21:52:45 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 10 May 2021 17:52:45 -0400
Subject: Would lambda expressions be meaningful annotation properties?
In-Reply-To: 
References: 
Message-ID: <73225475-0248-08b0-62db-cd727144a606@oracle.com>

Yes, this has been considered at some length.? The summary verdict is:

 ?- Method references for static/unbound methods seem like reasonable 
constant literals to put in annotations, not unlike class literals.
 ?- Lambdas, on the other hand: absolutely, positively, not.

To actually get to method refs in annotations, there's a lot of tedious 
but not terribly hard work at a number of levels: JVMS, JLS, reflection, 
plus of course JVM runtime and javac.? Given the relatively broad cost, 
it hasn't been too high on the priority list, but it is a 
reasonable-to-have feature.

On 5/10/2021 5:40 PM, Rafael Winterhalter wrote:
> Hello, I was wondering if there was ever any consideration of allowing
> (stateless) lambda expressions as annotation members. As an example, this
> would make the following lambda expression possible:
>
> @interface MyAnnotation {
>    Supplier value();
> }
>
> In many enterprise applications, this would be a very helpful addition and
> replace a rather complicated pattern with little type-safety. For example,
> in Spring, beans can be registered conditionally. Today, this requires
> declaring a class that implements the Condition interface which then can be
> supplied as an argument to the Conditional annotation:
>
> public class MyCondition implements Condition {
>    @Override
>    public boolean matches(ConditionContext context, AnnotatedTypeMetadata
> metadata) {
>      return MyCode.isEnabled(context, metadata)
>    }
> }
>
> which is then used in:
>
> @Conditional(MyCondition.class) @Bean
> public MyBean myBean() { ... }
>
> By allowing stateless lambda expressions as annotation members, this could
> be simplified to:
>
> @Conditional(MyCode::isEnabled) @Bean
> public MyBean myBean() { ... }
>
> Another example where this would improve code readability a lot would be
> bean validation frameworks, where custom constraints could be moved
> directly to a property:
>
> class MyBean {
>    @Valid(value -> value != null && MyCode.validate(value))
>    String property;
> }
>
> I observe such patterns regularly and therefore, I was curious if such a
> feature was ever discussed or if this would be considered for a future
> version. I understand that the intention of annotations is to provide
> declarative metadata which can be processed also for unloaded code, but I
> still feel like this would be a useful extension. The lambda expression
> would be implicitly stateless, but of course they represent code that
> requires class loading and would therefore be not necessarily meaningful to
> annotation processors or other static code processing tools. If this would
> be a feature to consider and only not a priority, I would be happy to
> contribute, given I could get some help around the formalities of such a
> process.
>
> Thanks, Rafael


From sviswanathan at openjdk.java.net  Mon May 10 21:52:56 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Mon, 10 May 2021 21:52:56 GMT
Subject: Integrated: 8265128: [REDO] Optimize Vector API slice and unslice
 operations
In-Reply-To: 
References: 
Message-ID: 

On Thu, 29 Apr 2021 21:29:03 GMT, Sandhya Viswanathan  wrote:

> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).
> 
> Changes include:
>  * Rewrite Vector API slice/unslice using already intrinsic methods
>  * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
>  * Vector API conversion tests thresholds adjustment
>  
> Base Performance:
> Benchmark (size) Mode Cnt Score Error Units
> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms
> 
> Performance with patch:
> Benchmark (size) Mode Cnt Score Error Units
> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms

This pull request has now been integrated.

Changeset: 23446f1f
Author:    Sandhya Viswanathan 
URL:       https://git.openjdk.java.net/jdk/commit/23446f1f5ee087376bc1ab89413a011fc52bde1f
Stats:     881 lines in 43 files changed: 172 ins; 518 del; 191 mod

8265128: [REDO] Optimize Vector API slice and unslice operations

Reviewed-by: psandoz, vlivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From psandoz at openjdk.java.net  Mon May 10 21:58:14 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 10 May 2021 21:58:14 GMT
Subject: RFR: 8266317: Vector API enhancements [v3]
In-Reply-To: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com>
References: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com>
Message-ID: 

> This PR contains API and implementation changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Enhancements are made to the API for the support of operations on characters, such as for UTF-8 character decoding. Specifically, methods for loading/storing a `short` vector from/to a `char[]` array, and new vector comparison operators for unsigned comparisons with integral vectors. The x64 implementation is enhanced to supported unsigned comparisons.
> 
> Enhancements are made to the API for loading/storing a `byte` vector from/to a `boolean[]` array.
> 
> The testing of loads/stores can be expanded for scatter/gather, but before doing that i think some refactoring of the tests is required to reposition tests in the right classes. I would like to do that work after integration of the PR.

Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:

  JavaDoc refs for unsigned operators.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3803/files
  - new: https://git.openjdk.java.net/jdk/pull/3803/files/93b093c1..aa6bb717

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3803&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3803&range=01-02

  Stats: 16 lines in 1 file changed: 12 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3803.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3803/head:pull/3803

PR: https://git.openjdk.java.net/jdk/pull/3803

From mandy.chung at oracle.com  Mon May 10 23:03:02 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 10 May 2021 16:03:02 -0700
Subject: Review CSR JDK-8266760: Remove
 sun.misc.Unsafe::defineAnonymousClass
In-Reply-To: 
References: <07d57bb9-1787-b86a-0009-d7690745986c@oracle.com>
 
Message-ID: <86151eab-7beb-1e56-a389-1860cbd8e554@oracle.com>

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. `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.net/browse/JDK-8266760
>>
>> Comments?
>>
>> Mandy


From naoto at openjdk.java.net  Mon May 10 23:26:32 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 10 May 2021 23:26:32 GMT
Subject: RFR: 8266784: java/text/Collator/RuleBasedCollatorTest.java fails
 with jtreg 6
Message-ID: 

Please review this test case fix for the upcoming jtreg 6. The test was using `@BeforeGroups` annotation, and the behavior of it has changed in TestNG 7.1 so that it is only issued when the test was configured with filtering. Changed to use `@BeforeClass` instead.

-------------

Commit messages:
 - 8266784: java/text/Collator/RuleBasedCollatorTest.java fails with jtreg 6

Changes: https://git.openjdk.java.net/jdk/pull/3959/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3959&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266784
  Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3959/head:pull/3959

PR: https://git.openjdk.java.net/jdk/pull/3959

From cushon at openjdk.java.net  Mon May 10 23:33:24 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Mon, 10 May 2021 23:33:24 GMT
Subject: RFR: 8266857: PipedOutputStream.sink should be volatile
Message-ID: 

8266857: PipedOutputStream.sink should be volatile

-------------

Commit messages:
 - 8266857: PipedOutputStream.sink should be volatile

Changes: https://git.openjdk.java.net/jdk/pull/3960/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3960&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266857
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3960.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3960/head:pull/3960

PR: https://git.openjdk.java.net/jdk/pull/3960

From almatvee at openjdk.java.net  Tue May 11 03:40:19 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Tue, 11 May 2021 03:40:19 GMT
Subject: RFR: 8266456: Replace direct TKit.run() calls with
 jdk.jpackage.test.Annotations.Test annotation [v3]
In-Reply-To: 
References: 
Message-ID: <1pmsq6L7d7NEh3pOIvpLYADieU90dodd-KTpfiQeeck=.92a2c3e9-e252-453e-9da2-8ccea61f1294@github.com>

> - Replaced direct TKit.run() calls with Test annotation.
>  - Increased timeout for SigningPackageTest from default to 360 due to timeout. This is regression from JDK-8248904 due to changes done in signing and --remove-signature adds additional time since it is run per file.
>  - Fixed issue with jtreg.SkippedException which caused test to fail instead of being skipped, since it was wrapped in ExceptionBox.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8266456: Replace direct TKit.run() calls with jdk.jpackage.test.Annotations.Test annotation [v3]

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3911/files
  - new: https://git.openjdk.java.net/jdk/pull/3911/files/b382561f..523a2c65

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3911&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3911&range=01-02

  Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3911.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3911/head:pull/3911

PR: https://git.openjdk.java.net/jdk/pull/3911

From almatvee at openjdk.java.net  Tue May 11 03:40:20 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Tue, 11 May 2021 03:40:20 GMT
Subject: RFR: 8266456: Replace direct TKit.run() calls with
 jdk.jpackage.test.Annotations.Test annotation [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 8 May 2021 01:44:46 GMT, Alexander Matveev  wrote:

>> - Replaced direct TKit.run() calls with Test annotation.
>>  - Increased timeout for SigningPackageTest from default to 360 due to timeout. This is regression from JDK-8248904 due to changes done in signing and --remove-signature adds additional time since it is run per file.
>>  - Fixed issue with jtreg.SkippedException which caused test to fail instead of being skipped, since it was wrapped in ExceptionBox.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266456: Replace direct TKit.run() calls with jdk.jpackage.test.Annotations.Test annotation [v2]

Changed to check for RuntimeException as Alexey suggested. Also, added missing throw at line 158 in Functional.java.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3911

From joehw at openjdk.java.net  Tue May 11 04:27:02 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 11 May 2021 04:27:02 GMT
Subject: RFR: 8266784: java/text/Collator/RuleBasedCollatorTest.java fails
 with jtreg 6
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 May 2021 23:12:04 GMT, Naoto Sato  wrote:

> Please review this test case fix for the upcoming jtreg 6. The test was using `@BeforeGroups` annotation, and the behavior of it has changed in TestNG 7.1 so that it is only issued when the test was configured with filtering. Changed to use `@BeforeClass` instead.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3959

From jbhateja at openjdk.java.net  Tue May 11 04:49:56 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 11 May 2021 04:49:56 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sat, 8 May 2021 15:40:53 GMT, Paul Sandoz  wrote:

> Looks good. Someone from the HotSpot side needs to review related changes.
> 
> The way i read the perf numbers is that on non AVX512 systems the numbers are in the noise (no worse, no better), with significant improvement on AVX512.

Hi @PaulSandoz, thanks for your suggestions and review, yes AVX2 speedup is an artifact of the code re-organization, since C2 now directly dismantles the rotates thus this offer better in-lining behavior compared to existing implementation and this is what show up in the performance data.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From dfranken.jdk at gmail.com  Tue May 11 06:45:15 2021
From: dfranken.jdk at gmail.com (dfranken.jdk at gmail.com)
Date: Tue, 11 May 2021 08:45:15 +0200
Subject: [External] : Re: ReversibleCollection proposal
In-Reply-To: <255012227.325293.1620642164845.JavaMail.zimbra@u-pem.fr>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <7457433b-0836-f45e-4b51-4c2ecdf7e7da@oracle.com>
 <427897615.2057286.1619612437790.JavaMail.zimbra@u-pem.fr>
 
 <906317823.1426529.1619873859193.JavaMail.zimbra@u-pem.fr>
 
 <2063372755.1742538.1620211264481.JavaMail.zimbra@u-pem.fr>
 
 <255012227.325293.1620642164845.JavaMail.zimbra@u-pem.fr>
Message-ID: <9de1615b4961bf39f7ec6b7f514774d14583aa31.camel@gmail.com>

Dear mr. Forax,

I understand your point of view. You don't like to have separate
standalone interfaces for things that seem to belong in a hierarchy, is
that correct? Now that I thought about it, I agree.

So if a reversable/ordered set is a specialized form of a reversable
collection where reversable collection is a specialized form of a
collection, it makes sense to add it into the hierarchy.

Are you proposing to just add methods to the root Collection interface,
because it already has methods which may or may not be implemented or
throw Exceptions by its implementations? Or were you just pointing out
that's just how it works now? That the capabilities a certain
collection has, like unmodifiability or not allowing null elements, are
not exposed through a proper interface but through what it returns for
certain methods?

But we could also view "having (possibly duplicate) items in a
sequence" as a capability and that is defined by an actual interface,
List.

I do fear that if we add methods to the Collection interface, users
might not expect them to throw exceptions. E.g. if we add getFirst(),
users may just expect it to return the element that iterator().next()
or .stream().findFirst().orElseThrow() would return instead of an
UnsupportedOperationException. And while HashSet does not have a
defined order, it would in practice always return the same element.

So while I accept that some hidden capabilities are surfaced only
through return values of certain methods, I think an interface is still
a better choice here. However, if we go that route, I also agree on the
fact that we might need to explore defining proper interfaces for the
other capabilities at some point.

Kind regards,

Dave

On Mon, 2021-05-10 at 12:22 +0200, forax at univ-mlv.fr wrote:
> ----- Mail original -----
> > De: "dfranken jdk" 
> > ?: "Remi Forax" , "Stuart Marks"
> > 
> > Cc: "core-libs-dev" 
> > Envoy?: Dimanche 9 Mai 2021 12:13:58
> > Objet: Re: [External] : Re: ReversibleCollection proposal
> 
> > When I thought about Collection's role in the hierarchy, it seemed
> > to
> > me that 'Collection' is an interface for describing how elements
> > are
> > stored in a cardboard box (we can and and remove them) and that we
> > might need a different, yet related, interface to describe how to
> > retrieve the items from the box. This way we are not tied to the
> > Collection hierarchy and we could have one Set implementation which
> > is
> > ordered and another Set implementation which is not and they would
> > both
> > still implement Collection, but only one would implement the
> > interface.
> 
> So you want to model ReversibleSet as Set + Reversible,
> Reversible being an interface with a small number of method specific
> to the fact that the implementation is reversible. 
> 
> This does not work well for two reasons,
> - there is no syntax to represent the union of types in Java,
> ?? Set & Reversible set = ...
> ? is not a valid syntax. You can use a type variable with several
> bounds instead but it does work nicely with the rest of the language
> (overidding, overloading, etc).
> 
> - having public methods that takes an interface with few methods is a
> common design error.
> ? Let suppose you have a method foo that only prints the elements of
> a collection, in that case you may want to type the first parameter
> as Iterable or Collection.
> ? But requirements change an now you want to prints the elements
> sorted, oops, you have to change the signature of the public method
> which may be something not possible
> ? depending how many "clients" this method has.
> ? Providing interfaces with a small number of access methods will
> lead to this kind of issue. 
> 
> > 
> > Imagine an interface like 'java.lang.OrderedEnumerable` if you will
> > with methods such as 'first(), last(), etc', then each
> > implementation
> > would be free to choose to implement the interface or not. I also
> > thought about 'OrderedIterable', but there would be too much
> > confusion
> > with 'Iterable', but I think these are related too. Retrieving
> > items is
> > an iteration problem, not a storage problem.
> 
> The problem is that is you multiply the number of interfaces to
> access the elements, you add the dilemma of choice in the mix.
> The first iteration of the Scala Collection were like this, too many
> interfaces, at least for my taste. 
> 
> > 
> > While I would love to see the Collection hierarchy redesigned to
> > also
> > allow for ImmutableCollection which for instance would not have an
> > `add(T e)` method, I don't think we can simply do something like
> > that
> > without breaking too many things.
> 
> Dear Santa, i want an interface BuilderCollection that only allows
> add() but no remove()/clear(), because if you can not remove
> elements, then all the iterators can implement the snapshot at the
> beginning semantics,
> so no ConcurrentModificationException anymore. For me, being able to
> snapshot/freeze a collection is better than an ImmutableCollection,
> because it can be immutable when you want. 
> 
> Anyway, it's not gonna to happen, there is so many ways to slice an
> onion and each have pros and cons and providing all the possible
> interfaces is a good.way to make something simple complex.
> 
> > 
> > So in short, separating retrieval aspects from storage aspects with
> > a
> > different interface might be the way to go.
> > 
> > Kind regards,
> > 
> > Dave Franken
> > 
> 
> regards,
> R?mi
> 
> > On Wed, 2021-05-05 at 12:41 +0200, forax at univ-mlv.fr?wrote:
> > > ----- Mail original -----
> > > > De: "Stuart Marks" 
> > > > ?: "Remi Forax" 
> > > > Cc: "core-libs-dev" 
> > > > Envoy?: Mercredi 5 Mai 2021 02:00:03
> > > > Objet: Re: [External] : Re: ReversibleCollection proposal
> > > 
> > > > On 5/1/21 5:57 AM, forax at univ-mlv.fr?wrote:
> > > > > I suppose the performance issue comes from the fact that
> > > > > traversing a
> > > > > LinkedHahSet is slow because it's a linked list ?
> > > > > 
> > > > > You can replace a LinkedHashSet by a List + Set, the List
> > > > > keeps
> > > > > the values in
> > > > > order, the Set avoids duplicates.
> > > > > 
> > > > > Using a Stream, it becomes
> > > > > ?? Stream.of(getItemsFromSomeplace(),
> > > > > getItemsFromAnotherPlace(),
> > > > > ?? getItemsFromSomeplaceElse())
> > > > > ??? .flatMap(List::stream)
> > > > > ??? .distinct()????????????? // use a Set internally
> > > > > ??? .collect(toList());
> > > > 
> > > > The problem with any example is that simplifying assumptions
> > > > are
> > > > necessary for
> > > > showing the example, but those assumptions enable it to be
> > > > easily
> > > > picked apart.
> > > > Of
> > > > course, the example isn't just a particular example; it is a
> > > > *template* for a
> > > > whole
> > > > space of possible examples. Consider the possibility that the
> > > > items
> > > > processing
> > > > client needs to do some intermediate processing on the first
> > > > group
> > > > of items
> > > > before
> > > > adding the other groups. This might not be possible to do using
> > > > streams. Use
> > > > your
> > > > imagination.
> > > > 
> > > > > I think there are maybe some scenarios where
> > > > > ReversibleCollection
> > > > > can be useful,
> > > > > but they are rare, to the point where when there is a good
> > > > > scenario for it
> > > > > people will not recognize it because ReversibleCollection
> > > > > will
> > > > > not be part of
> > > > > their muscle memory.
> > > > 
> > > > I'm certain that uses of RC/RS will be rare in the beginning,
> > > > because they will
> > > > be
> > > > new, and people won't be familar with them. And then there will
> > > > the
> > > > people who
> > > > say
> > > > "I can't use them because I'm stuck on JDK 11 / 8 / 7 / 6 ...."
> > > > It
> > > > was the same
> > > > thing with lambdas and streams in Java 8, with List.of() etc in
> > > > Java 9, records
> > > > in
> > > > Java 16, etc. This wasn't an argument not to add them, and it
> > > > isn't
> > > > an argument
> > > > not
> > > > to add RC/RS.
> > > 
> > > All the changes you are listing here are "client side" changes,
> > > the
> > > ones that can be adopted quickly because they do not require to
> > > change the API side of any libraries.
> > > ReversibleCollection is an API side change, like generics is,
> > > those
> > > changes have a far higher cost because you have to wait your
> > > library
> > > dependencies to be updated.
> > > On the Valhalla list, we have discussed several times about how
> > > to
> > > alleviate those API side change cost using automatic bridging or
> > > methods forwarding, even for Valhalla, we are currently moving in
> > > a
> > > state where those mechanisms are not needed.
> > > 
> > > > 
> > > > > There is a real value to add methods like
> > > > > descendingSet/descendingList()/getFirst/getLast on existing
> > > > > collections, but we
> > > > > don't need a new interface (or two) for that.
> > > > 
> > > > It depends on what you mean by "need". Sure, we could get away
> > > > without this;
> > > > after
> > > > all, we've survived the past twenty years without it, so we
> > > > could
> > > > probably
> > > > survive
> > > > the next twenty years as well.
> > > > 
> > > > It would indeed be useful to add various methods to List,
> > > > Deque,
> > > > SortedSet, and
> > > > LinkedHashSet to provide a full set of methods on all of them.
> > > > And
> > > > it would also
> > > > be
> > > > nice to have those methods be similar to one another. An
> > > > interface
> > > > helps with
> > > > that,
> > > > but I agree, that's not really the reason to have an interface
> > > > though.
> > > > 
> > > > The reversed-view concept could also be added individually to
> > > > the
> > > > different
> > > > places.
> > > > A reverse-ordered List is a List, a reverse-ordered Deque is a
> > > > Deque, a
> > > > reverse-ordered SortedSet is a SortedSet, and a reverse-ordered
> > > > LinkedHashSet is
> > > > a
> > > > ... ? And what is the type of the keySet of a LinkedHashMap,
> > > > that
> > > > enables one to
> > > > (say) get the last element?
> > > 
> > > see below
> > > 
> > > > 
> > > > After working with a system like this for a while, it begins to
> > > > emerge that
> > > > there is
> > > > an abstraction missing from the collections framework,
> > > > something
> > > > like an
> > > > "ordered
> > > > collection". People have been missing this for quite a long
> > > > time.
> > > > The most
> > > > recent
> > > > example (which this proposal builds on) is Tagir's proposal
> > > > from a
> > > > year ago. And
> > > > it's been asked about several times before that.
> > > > ReversibleCollection fills in
> > > > that
> > > > missing abstraction.
> > > 
> > > The abstraction already exists but it's not defined in term of
> > > interface because it's an implementation decision and those are
> > > cleanly separated in the current Collection design.
> > > 
> > > Let take a step back, the collection API defines basic data
> > > structure
> > > operations in term of interfaces like List, Deque, Set, etc those
> > > interfaces are decoupled from implementation capabilities like
> > > mutable, nullable, ordered and checked.
> > > 
> > > Depending on the implementation capabilities, the interfaces
> > > method
> > > implementation may throw an exception, non-mutable
> > > implementations
> > > use UnsupportedOperationException, non-nullable implementations
> > > use
> > > NPE and checked implementations use CCE.
> > > 
> > > So what is missing is methods on Collection interfaces that
> > > require
> > > the collection implementation to be ordered like
> > > descendingList(),
> > > getFirst(), etc.
> > > Those methods that may throw a specific exception if the
> > > implementation is not ordered, not UnsupportedOperationException
> > > but
> > > a new one like NotOrderedException.
> > > 
> > > So to answer to your question about LinkedHashSet, the reverse-
> > > ordered LinkedHashSet is a Set with a method descendingSet() that
> > > do
> > > not throw NotOrderedException like any Set with an order.
> > > 
> > > To summarize, if we introduce ReversibleCollection, we should
> > > also
> > > introduce ImmutableCollection, NonNullableCollection and
> > > CheckedCollection.
> > > I think it's better to consider the fact that being ordered as a
> > > capability (hint: this is already what the Spliterator API does)
> > > and
> > > not as a specific interface.
> > > 
> > > > 
> > > > s'marks
> > > 
> > > R?mi



From forax at univ-mlv.fr  Tue May 11 07:26:42 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 11 May 2021 09:26:42 +0200 (CEST)
Subject: [External] : Re: ReversibleCollection proposal
In-Reply-To: <9de1615b4961bf39f7ec6b7f514774d14583aa31.camel@gmail.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 
 <906317823.1426529.1619873859193.JavaMail.zimbra@u-pem.fr>
 
 <2063372755.1742538.1620211264481.JavaMail.zimbra@u-pem.fr>
 
 <255012227.325293.1620642164845.JavaMail.zimbra@u-pem.fr>
 <9de1615b4961bf39f7ec6b7f514774d14583aa31.camel@gmail.com>
Message-ID: <295457227.1124853.1620718002979.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "dfranken jdk" 
> ?: "Remi Forax" 
> Cc: "Stuart Marks" , "core-libs-dev" 
> Envoy?: Mardi 11 Mai 2021 08:45:15
> Objet: Re: [External] : Re: ReversibleCollection proposal

> Dear mr. Forax,

Hi Dave,

> 
> I understand your point of view. You don't like to have separate
> standalone interfaces for things that seem to belong in a hierarchy, is
> that correct? Now that I thought about it, I agree.

yes,

> 
> So if a reversable/ordered set is a specialized form of a reversable
> collection where reversable collection is a specialized form of a
> collection, it makes sense to add it into the hierarchy.
> 
> Are you proposing to just add methods to the root Collection interface,
> because it already has methods which may or may not be implemented or
> throw Exceptions by its implementations ?

yes, the idea is to add getFirst/getLast/removeFirst/removeLast and reversed on Collection as default methods.
Something like

interface Collection {
  /**
   * throws NoSuchElementException if the collection is empty
   */
  public default E getFirst() {
    return iterator().next();
  }

  /**
   * throws NoSuchElementException if the collection is empty
   * throws UnsupportedOperationException if the collection is non mutable
   */
  public default E removeFirst() {
    var it = iterator();
    var element = it.next();
    it.remove();
    return element;
  }

  /**
   * throws NonOrderedCollectionException if the collection is non ordered
   */
  public default Collection reversed() {
    throw new NonOrderedCollectionException();
  }

  /**
   * throws NoSuchElementException if the collection is empty
   * throws NonOrderedCollectionException if the collection is non ordered
   */
  public default E getLast() {
    return reversed().getFirst();
  }

  /**
   * throws NoSuchElementException if the collection is empty
   * throws UnsupportedOperationException if the collection is non mutable
   * throws NonOrderedCollectionException if the collection is non ordered
   */
  public default E removeLast() {
    return reversed().removeFirst();
  }
}


And adds an implementation of reversed(), getLast() and removeLast() on NavigableSet/LinkedHashSet/EnumSet/Deque and List.

And do the same thing for Map:

interface Map {
  /**
   * throws NoSuchElementException if the map is empty
   */
  public default Map.Entry getFirstEntry() {
    return entrySet().iterator().next();
  }

  /**
   * throws NoSuchElementException if the map is empty
   * throws UnsupportedOperationException if the map is non mutable
   */
  public default  Map.Entry removeFirstEntry() {
    var it = entrySet().iterator();
    var element = it.next();
    it.remove();
    return element;
  }

  /**
   * throws NonOrderedCollectionException if the map.keySet() is non ordered
   */
  public default Map reversedMap() {
    throw new NonOrderedCollectionException();
  }

  /**
   * throws NoSuchElementException if the map is empty
   * throws NonOrderedCollectionException if the map.keySet() is non ordered
   */
  public default E getLastEntry() {
    return reversedMap().getFirstEntry();
  }

  /**
   * throws NoSuchElementException if the map is empty
   * throws UnsupportedOperationException if the map is non mutable
   * throws NonOrderedCollectionException if the map.keySet() is non ordered
   */
  public default E removeLast() {
    return reversedMap().removeFirstEntry();
  }
}

And adds an implementation of reversedMap(), getLastEntry() and removeLastEntry() on NavigableMap/LinkedHasMap and EnumMap.


> 
> But we could also view "having (possibly duplicate) items in a
> sequence" as a capability and that is defined by an actual interface,
> List.

It already exist for a Spliterator, the capability is called DISTINCT, by example, set.stream() and list.stream().distinct() are both Streams with no duplicate.

> 
> I do fear that if we add methods to the Collection interface, users
> might not expect them to throw exceptions. E.g. if we add getFirst(),
> users may just expect it to return the element that iterator().next()
> or .stream().findFirst().orElseThrow() would return instead of an
> UnsupportedOperationException. And while HashSet does not have a
> defined order, it would in practice always return the same element.

I agree, getFirst() and removeFirst() should have their semantics based on iterator (see above),
because as you said, it's already how findFirst() is specified.

> 
> So while I accept that some hidden capabilities are surfaced only
> through return values of certain methods, I think an interface is still
> a better choice here. However, if we go that route, I also agree on the
> fact that we might need to explore defining proper interfaces for the
> other capabilities at some point.
> 
> Kind regards,
> 
> Dave

regards,
R?mi

> 
> On Mon, 2021-05-10 at 12:22 +0200, forax at univ-mlv.fr wrote:
>> ----- Mail original -----
>> > De: "dfranken jdk" 
>> > ?: "Remi Forax" , "Stuart Marks"
>> > 
>> > Cc: "core-libs-dev" 
>> > Envoy?: Dimanche 9 Mai 2021 12:13:58
>> > Objet: Re: [External] : Re: ReversibleCollection proposal
>> 
>> > When I thought about Collection's role in the hierarchy, it seemed
>> > to
>> > me that 'Collection' is an interface for describing how elements
>> > are
>> > stored in a cardboard box (we can and and remove them) and that we
>> > might need a different, yet related, interface to describe how to
>> > retrieve the items from the box. This way we are not tied to the
>> > Collection hierarchy and we could have one Set implementation which
>> > is
>> > ordered and another Set implementation which is not and they would
>> > both
>> > still implement Collection, but only one would implement the
>> > interface.
>> 
>> So you want to model ReversibleSet as Set + Reversible,
>> Reversible being an interface with a small number of method specific
>> to the fact that the implementation is reversible.
>> 
>> This does not work well for two reasons,
>> - there is no syntax to represent the union of types in Java,
>> ?? Set & Reversible set = ...
>> ? is not a valid syntax. You can use a type variable with several
>> bounds instead but it does work nicely with the rest of the language
>> (overidding, overloading, etc).
>> 
>> - having public methods that takes an interface with few methods is a
>> common design error.
>> ? Let suppose you have a method foo that only prints the elements of
>> a collection, in that case you may want to type the first parameter
>> as Iterable or Collection.
>> ? But requirements change an now you want to prints the elements
>> sorted, oops, you have to change the signature of the public method
>> which may be something not possible
>> ? depending how many "clients" this method has.
>> ? Providing interfaces with a small number of access methods will
>> lead to this kind of issue.
>> 
>> > 
>> > Imagine an interface like 'java.lang.OrderedEnumerable` if you will
>> > with methods such as 'first(), last(), etc', then each
>> > implementation
>> > would be free to choose to implement the interface or not. I also
>> > thought about 'OrderedIterable', but there would be too much
>> > confusion
>> > with 'Iterable', but I think these are related too. Retrieving
>> > items is
>> > an iteration problem, not a storage problem.
>> 
>> The problem is that is you multiply the number of interfaces to
>> access the elements, you add the dilemma of choice in the mix.
>> The first iteration of the Scala Collection were like this, too many
>> interfaces, at least for my taste.
>> 
>> > 
>> > While I would love to see the Collection hierarchy redesigned to
>> > also
>> > allow for ImmutableCollection which for instance would not have an
>> > `add(T e)` method, I don't think we can simply do something like
>> > that
>> > without breaking too many things.
>> 
>> Dear Santa, i want an interface BuilderCollection that only allows
>> add() but no remove()/clear(), because if you can not remove
>> elements, then all the iterators can implement the snapshot at the
>> beginning semantics,
>> so no ConcurrentModificationException anymore. For me, being able to
>> snapshot/freeze a collection is better than an ImmutableCollection,
>> because it can be immutable when you want.
>> 
>> Anyway, it's not gonna to happen, there is so many ways to slice an
>> onion and each have pros and cons and providing all the possible
>> interfaces is a good.way to make something simple complex.
>> 
>> > 
>> > So in short, separating retrieval aspects from storage aspects with
>> > a
>> > different interface might be the way to go.
>> > 
>> > Kind regards,
>> > 
>> > Dave Franken
>> > 
>> 
>> regards,
>> R?mi
>> 
>> > On Wed, 2021-05-05 at 12:41 +0200, forax at univ-mlv.fr?wrote:
>> > > ----- Mail original -----
>> > > > De: "Stuart Marks" 
>> > > > ?: "Remi Forax" 
>> > > > Cc: "core-libs-dev" 
>> > > > Envoy?: Mercredi 5 Mai 2021 02:00:03
>> > > > Objet: Re: [External] : Re: ReversibleCollection proposal
>> > > 
>> > > > On 5/1/21 5:57 AM, forax at univ-mlv.fr?wrote:
>> > > > > I suppose the performance issue comes from the fact that
>> > > > > traversing a
>> > > > > LinkedHahSet is slow because it's a linked list ?
>> > > > > 
>> > > > > You can replace a LinkedHashSet by a List + Set, the List
>> > > > > keeps
>> > > > > the values in
>> > > > > order, the Set avoids duplicates.
>> > > > > 
>> > > > > Using a Stream, it becomes
>> > > > > ?? Stream.of(getItemsFromSomeplace(),
>> > > > > getItemsFromAnotherPlace(),
>> > > > > ?? getItemsFromSomeplaceElse())
>> > > > > ??? .flatMap(List::stream)
>> > > > > ??? .distinct()????????????? // use a Set internally
>> > > > > ??? .collect(toList());
>> > > > 
>> > > > The problem with any example is that simplifying assumptions
>> > > > are
>> > > > necessary for
>> > > > showing the example, but those assumptions enable it to be
>> > > > easily
>> > > > picked apart.
>> > > > Of
>> > > > course, the example isn't just a particular example; it is a
>> > > > *template* for a
>> > > > whole
>> > > > space of possible examples. Consider the possibility that the
>> > > > items
>> > > > processing
>> > > > client needs to do some intermediate processing on the first
>> > > > group
>> > > > of items
>> > > > before
>> > > > adding the other groups. This might not be possible to do using
>> > > > streams. Use
>> > > > your
>> > > > imagination.
>> > > > 
>> > > > > I think there are maybe some scenarios where
>> > > > > ReversibleCollection
>> > > > > can be useful,
>> > > > > but they are rare, to the point where when there is a good
>> > > > > scenario for it
>> > > > > people will not recognize it because ReversibleCollection
>> > > > > will
>> > > > > not be part of
>> > > > > their muscle memory.
>> > > > 
>> > > > I'm certain that uses of RC/RS will be rare in the beginning,
>> > > > because they will
>> > > > be
>> > > > new, and people won't be familar with them. And then there will
>> > > > the
>> > > > people who
>> > > > say
>> > > > "I can't use them because I'm stuck on JDK 11 / 8 / 7 / 6 ...."
>> > > > It
>> > > > was the same
>> > > > thing with lambdas and streams in Java 8, with List.of() etc in
>> > > > Java 9, records
>> > > > in
>> > > > Java 16, etc. This wasn't an argument not to add them, and it
>> > > > isn't
>> > > > an argument
>> > > > not
>> > > > to add RC/RS.
>> > > 
>> > > All the changes you are listing here are "client side" changes,
>> > > the
>> > > ones that can be adopted quickly because they do not require to
>> > > change the API side of any libraries.
>> > > ReversibleCollection is an API side change, like generics is,
>> > > those
>> > > changes have a far higher cost because you have to wait your
>> > > library
>> > > dependencies to be updated.
>> > > On the Valhalla list, we have discussed several times about how
>> > > to
>> > > alleviate those API side change cost using automatic bridging or
>> > > methods forwarding, even for Valhalla, we are currently moving in
>> > > a
>> > > state where those mechanisms are not needed.
>> > > 
>> > > > 
>> > > > > There is a real value to add methods like
>> > > > > descendingSet/descendingList()/getFirst/getLast on existing
>> > > > > collections, but we
>> > > > > don't need a new interface (or two) for that.
>> > > > 
>> > > > It depends on what you mean by "need". Sure, we could get away
>> > > > without this;
>> > > > after
>> > > > all, we've survived the past twenty years without it, so we
>> > > > could
>> > > > probably
>> > > > survive
>> > > > the next twenty years as well.
>> > > > 
>> > > > It would indeed be useful to add various methods to List,
>> > > > Deque,
>> > > > SortedSet, and
>> > > > LinkedHashSet to provide a full set of methods on all of them.
>> > > > And
>> > > > it would also
>> > > > be
>> > > > nice to have those methods be similar to one another. An
>> > > > interface
>> > > > helps with
>> > > > that,
>> > > > but I agree, that's not really the reason to have an interface
>> > > > though.
>> > > > 
>> > > > The reversed-view concept could also be added individually to
>> > > > the
>> > > > different
>> > > > places.
>> > > > A reverse-ordered List is a List, a reverse-ordered Deque is a
>> > > > Deque, a
>> > > > reverse-ordered SortedSet is a SortedSet, and a reverse-ordered
>> > > > LinkedHashSet is
>> > > > a
>> > > > ... ? And what is the type of the keySet of a LinkedHashMap,
>> > > > that
>> > > > enables one to
>> > > > (say) get the last element?
>> > > 
>> > > see below
>> > > 
>> > > > 
>> > > > After working with a system like this for a while, it begins to
>> > > > emerge that
>> > > > there is
>> > > > an abstraction missing from the collections framework,
>> > > > something
>> > > > like an
>> > > > "ordered
>> > > > collection". People have been missing this for quite a long
>> > > > time.
>> > > > The most
>> > > > recent
>> > > > example (which this proposal builds on) is Tagir's proposal
>> > > > from a
>> > > > year ago. And
>> > > > it's been asked about several times before that.
>> > > > ReversibleCollection fills in
>> > > > that
>> > > > missing abstraction.
>> > > 
>> > > The abstraction already exists but it's not defined in term of
>> > > interface because it's an implementation decision and those are
>> > > cleanly separated in the current Collection design.
>> > > 
>> > > Let take a step back, the collection API defines basic data
>> > > structure
>> > > operations in term of interfaces like List, Deque, Set, etc those
>> > > interfaces are decoupled from implementation capabilities like
>> > > mutable, nullable, ordered and checked.
>> > > 
>> > > Depending on the implementation capabilities, the interfaces
>> > > method
>> > > implementation may throw an exception, non-mutable
>> > > implementations
>> > > use UnsupportedOperationException, non-nullable implementations
>> > > use
>> > > NPE and checked implementations use CCE.
>> > > 
>> > > So what is missing is methods on Collection interfaces that
>> > > require
>> > > the collection implementation to be ordered like
>> > > descendingList(),
>> > > getFirst(), etc.
>> > > Those methods that may throw a specific exception if the
>> > > implementation is not ordered, not UnsupportedOperationException
>> > > but
>> > > a new one like NotOrderedException.
>> > > 
>> > > So to answer to your question about LinkedHashSet, the reverse-
>> > > ordered LinkedHashSet is a Set with a method descendingSet() that
>> > > do
>> > > not throw NotOrderedException like any Set with an order.
>> > > 
>> > > To summarize, if we introduce ReversibleCollection, we should
>> > > also
>> > > introduce ImmutableCollection, NonNullableCollection and
>> > > CheckedCollection.
>> > > I think it's better to consider the fact that being ordered as a
>> > > capability (hint: this is already what the Spliterator API does)
>> > > and
>> > > not as a specific interface.
>> > > 
>> > > > 
>> > > > s'marks
>> > > 
> > > > R?mi

From dfuchs at openjdk.java.net  Tue May 11 10:23:24 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 11 May 2021 10:23:24 GMT
Subject: RFR: 8266857: PipedOutputStream.sink should be volatile
In-Reply-To: 
References: 
Message-ID: <-RLwMiJ-R4D_MNQCTA2HJlFp0Cvi2IFCIvmAeFUO1uw=.88eff355-86e8-4689-a971-91acba7aa0b9@github.com>

On Mon, 10 May 2021 23:25:46 GMT, Liam Miller-Cushon  wrote:

> 8266857: PipedOutputStream.sink should be volatile

For correctness (and peace of mind)- we should probably introduce a local variable in all the places where `sink` is read more than once outside of a synchronized block (the two `write` and `close` methods).
I'd suggest simply inserting a first line in each of these methods:


    var sink = this.sink;


This will ensure that there's only one volatile read.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3960

From szegedia at gmail.com  Tue May 11 10:41:00 2021
From: szegedia at gmail.com (Attila Szegedi)
Date: Tue, 11 May 2021 12:41:00 +0200
Subject: Review CSR JDK-8266760: Remove
 sun.misc.Unsafe::defineAnonymousClass
In-Reply-To: <86151eab-7beb-1e56-a389-1860cbd8e554@oracle.com>
References: <07d57bb9-1787-b86a-0009-d7690745986c@oracle.com>
 
 <86151eab-7beb-1e56-a389-1860cbd8e554@oracle.com>
Message-ID: 

I'm fine with the removal, although if you remember we use it in Nashorn
too[0], and when I tried to replace it with the hidden classes facility the
issue we run into was that hidden classes' methods didn't show up in stack
traces the way anonymous classes' methods did[1]. Since Nashorn uses
anonymous classes to install compiled JavaScript application code, it is
important to be able to report stack traces from them. It unfortunately
can't just use StackWalker, as it has to post-edit traces of already thrown
exceptions.

So ensuring JDK-8212620 is implemented as well, and/or maybe having
a MethodHandles.Lookup.ClassOption to specify the class should show up in
stack traces would be important to implement alongside the removal. It's
not a show-stopper, Nashorn will be able to gracefully fail over to
ordinary class loading in absence of anonymous class loading, but I'd
really like to be able to transition to using hidden classes if we could
get them to show up in stack traces.

Attila.

[0]
https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/Context.java#L329
[1]
https://mail.openjdk.java.net/pipermail/nashorn-dev/2020-October/007578.html

On Tue, May 11, 2021 at 1:03 AM Mandy Chung  wrote:

> 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. `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.net/browse/JDK-8266760
> >>
> >> Comments?
> >>
> >> Mandy
>
>

From peter.levart at gmail.com  Tue May 11 11:44:08 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 11 May 2021 13:44:08 +0200
Subject: [External] : Re: ReversibleCollection proposal
In-Reply-To: <295457227.1124853.1620718002979.JavaMail.zimbra@u-pem.fr>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 
 <906317823.1426529.1619873859193.JavaMail.zimbra@u-pem.fr>
 
 <2063372755.1742538.1620211264481.JavaMail.zimbra@u-pem.fr>
 
 <255012227.325293.1620642164845.JavaMail.zimbra@u-pem.fr>
 <9de1615b4961bf39f7ec6b7f514774d14583aa31.camel@gmail.com>
 <295457227.1124853.1620718002979.JavaMail.zimbra@u-pem.fr>
Message-ID: 

Hi Remi,


I see you avoided addFirst/addLast methods. While getFirst/removeFirst 
could be specified to be consistent with iterator().next(), so the 
"first" part of the name would be softer, addFirst is cursed two times: 
it has no equivalent in current API and it clashes with void returning 
method in Deque. So the best "soft" alternative seems to be the existing 
Collection.add(E) method which is equivalent to addFirst() when 
Collection is ordered or something totally different when it is sorted 
(i.e. SortedSet) and again different when it is neither.

To avoid bugs when an API expects an ordered Collection but has no 
static type to express that, a means to perform a runtime check would be 
needed. Marker interface is a way to add a bit of static typing to be 
used in generic methods like:


 & Ordered> void doSomething(C 
orderedCollection);


...but that's very limited. So probably not worth it. Stream API choose 
a different approach: Spliterator.characteristics(). So probably, 
Collection.characteristics() could also be added. The set of bit 
constants in Spliterator is applicable also to Collection (except 
SUBSIZED which has no sense in Collection, while SIZED is always present):

 ???? ORDERED
 ???? DISTINCT
 ???? SORTED
 ???? SIZED
 ???? NONNULL
 ???? IMMUTABLE
 ???? CONCURRENT

Specifically for Collection I would also add:

 ??? REVERSIBLE

...to indicate that Collection.reversed() would succeed.


The question is what would the default value of 
Collection.characteristics() be. The most sensible would be SIZED with 
overrides in:

- List (SIZED | ORDERED | REVERSIBLE)
- Set (SIZED | DISTINCT)
- SortedSet (SIZED | SORTED | REVERSIBLE | DISTINCT)
- LinkedHashSet (SIZED | ORDERED | REVERSIBLE | DISTINCT)
- Queue (SIZED | ORDERED)
- Deque (SIZED | ORDERED | REVERSIBLE)

... Immutable JDK List and Set implementations could also add IMMUTABLE 
| NONNULL, while concurrent JDK implementations would add CONCURRENT | 
NONNULL.


...but one could also base default value on something like this:


default int characteristics() {
 ??? return stream().spliterator().characteristics() & 
~Spliterator.SUBSIZED;
}



Wrappers like Collections.unmodifiableXXX() would just delegate to the 
underlying Collection and augment the returned bits (with IMMUTABLE for 
example).


An API that expects a particular kind of collection could then check 
that at runtime. Some of existing collections would have to be updated 
to express the correct characteristics, but defaults in interfaces would 
be sufficient for most and conservative.


WDYT?

Peter


On 5/11/21 9:26 AM, forax at univ-mlv.fr wrote:
>
>> Are you proposing to just add methods to the root Collection interface,
>> because it already has methods which may or may not be implemented or
>> throw Exceptions by its implementations ?
> yes, the idea is to add getFirst/getLast/removeFirst/removeLast and reversed on Collection as default methods.
> Something like
>
> interface Collection {
>    /**
>     * throws NoSuchElementException if the collection is empty
>     */
>    public default E getFirst() {
>      return iterator().next();
>    }
>
>    /**
>     * throws NoSuchElementException if the collection is empty
>     * throws UnsupportedOperationException if the collection is non mutable
>     */
>    public default E removeFirst() {
>      var it = iterator();
>      var element = it.next();
>      it.remove();
>      return element;
>    }
>
>    /**
>     * throws NonOrderedCollectionException if the collection is non ordered
>     */
>    public default Collection reversed() {
>      throw new NonOrderedCollectionException();
>    }
>
>    /**
>     * throws NoSuchElementException if the collection is empty
>     * throws NonOrderedCollectionException if the collection is non ordered
>     */
>    public default E getLast() {
>      return reversed().getFirst();
>    }
>
>    /**
>     * throws NoSuchElementException if the collection is empty
>     * throws UnsupportedOperationException if the collection is non mutable
>     * throws NonOrderedCollectionException if the collection is non ordered
>     */
>    public default E removeLast() {
>      return reversed().removeFirst();
>    }
> }
>
>
> And adds an implementation of reversed(), getLast() and removeLast() on NavigableSet/LinkedHashSet/EnumSet/Deque and List.
>
> And do the same thing for Map:
>
> interface Map {
>    /**
>     * throws NoSuchElementException if the map is empty
>     */
>    public default Map.Entry getFirstEntry() {
>      return entrySet().iterator().next();
>    }
>
>    /**
>     * throws NoSuchElementException if the map is empty
>     * throws UnsupportedOperationException if the map is non mutable
>     */
>    public default  Map.Entry removeFirstEntry() {
>      var it = entrySet().iterator();
>      var element = it.next();
>      it.remove();
>      return element;
>    }
>
>    /**
>     * throws NonOrderedCollectionException if the map.keySet() is non ordered
>     */
>    public default Map reversedMap() {
>      throw new NonOrderedCollectionException();
>    }
>
>    /**
>     * throws NoSuchElementException if the map is empty
>     * throws NonOrderedCollectionException if the map.keySet() is non ordered
>     */
>    public default E getLastEntry() {
>      return reversedMap().getFirstEntry();
>    }
>
>    /**
>     * throws NoSuchElementException if the map is empty
>     * throws UnsupportedOperationException if the map is non mutable
>     * throws NonOrderedCollectionException if the map.keySet() is non ordered
>     */
>    public default E removeLast() {
>      return reversedMap().removeFirstEntry();
>    }
> }
>
> And adds an implementation of reversedMap(), getLastEntry() and removeLastEntry() on NavigableMap/LinkedHasMap and EnumMap.
>
>
>> But we could also view "having (possibly duplicate) items in a
>> sequence" as a capability and that is defined by an actual interface,
>> List.
> It already exist for a Spliterator, the capability is called DISTINCT, by example, set.stream() and list.stream().distinct() are both Streams with no duplicate.
>
>> I do fear that if we add methods to the Collection interface, users
>> might not expect them to throw exceptions. E.g. if we add getFirst(),
>> users may just expect it to return the element that iterator().next()
>> or .stream().findFirst().orElseThrow() would return instead of an
>> UnsupportedOperationException. And while HashSet does not have a
>> defined order, it would in practice always return the same element.
> I agree, getFirst() and removeFirst() should have their semantics based on iterator (see above),
> because as you said, it's already how findFirst() is specified.
>
>> So while I accept that some hidden capabilities are surfaced only
>> through return values of certain methods, I think an interface is still
>> a better choice here. However, if we go that route, I also agree on the
>> fact that we might need to explore defining proper interfaces for the
>> other capabilities at some point.
>>
>> Kind regards,
>>
>> Dave
> regards,
> R?mi
>
>> On Mon, 2021-05-10 at 12:22 +0200, forax at univ-mlv.fr wrote:
>>> ----- Mail original -----
>>>> De: "dfranken jdk" 
>>>> ?: "Remi Forax" , "Stuart Marks"
>>>> 
>>>> Cc: "core-libs-dev" 
>>>> Envoy?: Dimanche 9 Mai 2021 12:13:58
>>>> Objet: Re: [External] : Re: ReversibleCollection proposal
>>>> When I thought about Collection's role in the hierarchy, it seemed
>>>> to
>>>> me that 'Collection' is an interface for describing how elements
>>>> are
>>>> stored in a cardboard box (we can and and remove them) and that we
>>>> might need a different, yet related, interface to describe how to
>>>> retrieve the items from the box. This way we are not tied to the
>>>> Collection hierarchy and we could have one Set implementation which
>>>> is
>>>> ordered and another Set implementation which is not and they would
>>>> both
>>>> still implement Collection, but only one would implement the
>>>> interface.
>>> So you want to model ReversibleSet as Set + Reversible,
>>> Reversible being an interface with a small number of method specific
>>> to the fact that the implementation is reversible.
>>>
>>> This does not work well for two reasons,
>>> - there is no syntax to represent the union of types in Java,
>>>  ?? Set & Reversible set = ...
>>>  ? is not a valid syntax. You can use a type variable with several
>>> bounds instead but it does work nicely with the rest of the language
>>> (overidding, overloading, etc).
>>>
>>> - having public methods that takes an interface with few methods is a
>>> common design error.
>>>  ? Let suppose you have a method foo that only prints the elements of
>>> a collection, in that case you may want to type the first parameter
>>> as Iterable or Collection.
>>>  ? But requirements change an now you want to prints the elements
>>> sorted, oops, you have to change the signature of the public method
>>> which may be something not possible
>>>  ? depending how many "clients" this method has.
>>>  ? Providing interfaces with a small number of access methods will
>>> lead to this kind of issue.
>>>
>>>> Imagine an interface like 'java.lang.OrderedEnumerable` if you will
>>>> with methods such as 'first(), last(), etc', then each
>>>> implementation
>>>> would be free to choose to implement the interface or not. I also
>>>> thought about 'OrderedIterable', but there would be too much
>>>> confusion
>>>> with 'Iterable', but I think these are related too. Retrieving
>>>> items is
>>>> an iteration problem, not a storage problem.
>>> The problem is that is you multiply the number of interfaces to
>>> access the elements, you add the dilemma of choice in the mix.
>>> The first iteration of the Scala Collection were like this, too many
>>> interfaces, at least for my taste.
>>>
>>>> While I would love to see the Collection hierarchy redesigned to
>>>> also
>>>> allow for ImmutableCollection which for instance would not have an
>>>> `add(T e)` method, I don't think we can simply do something like
>>>> that
>>>> without breaking too many things.
>>> Dear Santa, i want an interface BuilderCollection that only allows
>>> add() but no remove()/clear(), because if you can not remove
>>> elements, then all the iterators can implement the snapshot at the
>>> beginning semantics,
>>> so no ConcurrentModificationException anymore. For me, being able to
>>> snapshot/freeze a collection is better than an ImmutableCollection,
>>> because it can be immutable when you want.
>>>
>>> Anyway, it's not gonna to happen, there is so many ways to slice an
>>> onion and each have pros and cons and providing all the possible
>>> interfaces is a good.way to make something simple complex.
>>>
>>>> So in short, separating retrieval aspects from storage aspects with
>>>> a
>>>> different interface might be the way to go.
>>>>
>>>> Kind regards,
>>>>
>>>> Dave Franken
>>>>
>>> regards,
>>> R?mi
>>>
>>>> On Wed, 2021-05-05 at 12:41 +0200, forax at univ-mlv.fr?wrote:
>>>>> ----- Mail original -----
>>>>>> De: "Stuart Marks" 
>>>>>> ?: "Remi Forax" 
>>>>>> Cc: "core-libs-dev" 
>>>>>> Envoy?: Mercredi 5 Mai 2021 02:00:03
>>>>>> Objet: Re: [External] : Re: ReversibleCollection proposal
>>>>>> On 5/1/21 5:57 AM, forax at univ-mlv.fr?wrote:
>>>>>>> I suppose the performance issue comes from the fact that
>>>>>>> traversing a
>>>>>>> LinkedHahSet is slow because it's a linked list ?
>>>>>>>
>>>>>>> You can replace a LinkedHashSet by a List + Set, the List
>>>>>>> keeps
>>>>>>> the values in
>>>>>>> order, the Set avoids duplicates.
>>>>>>>
>>>>>>> Using a Stream, it becomes
>>>>>>>  ?? Stream.of(getItemsFromSomeplace(),
>>>>>>> getItemsFromAnotherPlace(),
>>>>>>>  ?? getItemsFromSomeplaceElse())
>>>>>>>  ??? .flatMap(List::stream)
>>>>>>>  ??? .distinct()????????????? // use a Set internally
>>>>>>>  ??? .collect(toList());
>>>>>> The problem with any example is that simplifying assumptions
>>>>>> are
>>>>>> necessary for
>>>>>> showing the example, but those assumptions enable it to be
>>>>>> easily
>>>>>> picked apart.
>>>>>> Of
>>>>>> course, the example isn't just a particular example; it is a
>>>>>> *template* for a
>>>>>> whole
>>>>>> space of possible examples. Consider the possibility that the
>>>>>> items
>>>>>> processing
>>>>>> client needs to do some intermediate processing on the first
>>>>>> group
>>>>>> of items
>>>>>> before
>>>>>> adding the other groups. This might not be possible to do using
>>>>>> streams. Use
>>>>>> your
>>>>>> imagination.
>>>>>>
>>>>>>> I think there are maybe some scenarios where
>>>>>>> ReversibleCollection
>>>>>>> can be useful,
>>>>>>> but they are rare, to the point where when there is a good
>>>>>>> scenario for it
>>>>>>> people will not recognize it because ReversibleCollection
>>>>>>> will
>>>>>>> not be part of
>>>>>>> their muscle memory.
>>>>>> I'm certain that uses of RC/RS will be rare in the beginning,
>>>>>> because they will
>>>>>> be
>>>>>> new, and people won't be familar with them. And then there will
>>>>>> the
>>>>>> people who
>>>>>> say
>>>>>> "I can't use them because I'm stuck on JDK 11 / 8 / 7 / 6 ...."
>>>>>> It
>>>>>> was the same
>>>>>> thing with lambdas and streams in Java 8, with List.of() etc in
>>>>>> Java 9, records
>>>>>> in
>>>>>> Java 16, etc. This wasn't an argument not to add them, and it
>>>>>> isn't
>>>>>> an argument
>>>>>> not
>>>>>> to add RC/RS.
>>>>> All the changes you are listing here are "client side" changes,
>>>>> the
>>>>> ones that can be adopted quickly because they do not require to
>>>>> change the API side of any libraries.
>>>>> ReversibleCollection is an API side change, like generics is,
>>>>> those
>>>>> changes have a far higher cost because you have to wait your
>>>>> library
>>>>> dependencies to be updated.
>>>>> On the Valhalla list, we have discussed several times about how
>>>>> to
>>>>> alleviate those API side change cost using automatic bridging or
>>>>> methods forwarding, even for Valhalla, we are currently moving in
>>>>> a
>>>>> state where those mechanisms are not needed.
>>>>>
>>>>>>> There is a real value to add methods like
>>>>>>> descendingSet/descendingList()/getFirst/getLast on existing
>>>>>>> collections, but we
>>>>>>> don't need a new interface (or two) for that.
>>>>>> It depends on what you mean by "need". Sure, we could get away
>>>>>> without this;
>>>>>> after
>>>>>> all, we've survived the past twenty years without it, so we
>>>>>> could
>>>>>> probably
>>>>>> survive
>>>>>> the next twenty years as well.
>>>>>>
>>>>>> It would indeed be useful to add various methods to List,
>>>>>> Deque,
>>>>>> SortedSet, and
>>>>>> LinkedHashSet to provide a full set of methods on all of them.
>>>>>> And
>>>>>> it would also
>>>>>> be
>>>>>> nice to have those methods be similar to one another. An
>>>>>> interface
>>>>>> helps with
>>>>>> that,
>>>>>> but I agree, that's not really the reason to have an interface
>>>>>> though.
>>>>>>
>>>>>> The reversed-view concept could also be added individually to
>>>>>> the
>>>>>> different
>>>>>> places.
>>>>>> A reverse-ordered List is a List, a reverse-ordered Deque is a
>>>>>> Deque, a
>>>>>> reverse-ordered SortedSet is a SortedSet, and a reverse-ordered
>>>>>> LinkedHashSet is
>>>>>> a
>>>>>> ... ? And what is the type of the keySet of a LinkedHashMap,
>>>>>> that
>>>>>> enables one to
>>>>>> (say) get the last element?
>>>>> see below
>>>>>
>>>>>> After working with a system like this for a while, it begins to
>>>>>> emerge that
>>>>>> there is
>>>>>> an abstraction missing from the collections framework,
>>>>>> something
>>>>>> like an
>>>>>> "ordered
>>>>>> collection". People have been missing this for quite a long
>>>>>> time.
>>>>>> The most
>>>>>> recent
>>>>>> example (which this proposal builds on) is Tagir's proposal
>>>>>> from a
>>>>>> year ago. And
>>>>>> it's been asked about several times before that.
>>>>>> ReversibleCollection fills in
>>>>>> that
>>>>>> missing abstraction.
>>>>> The abstraction already exists but it's not defined in term of
>>>>> interface because it's an implementation decision and those are
>>>>> cleanly separated in the current Collection design.
>>>>>
>>>>> Let take a step back, the collection API defines basic data
>>>>> structure
>>>>> operations in term of interfaces like List, Deque, Set, etc those
>>>>> interfaces are decoupled from implementation capabilities like
>>>>> mutable, nullable, ordered and checked.
>>>>>
>>>>> Depending on the implementation capabilities, the interfaces
>>>>> method
>>>>> implementation may throw an exception, non-mutable
>>>>> implementations
>>>>> use UnsupportedOperationException, non-nullable implementations
>>>>> use
>>>>> NPE and checked implementations use CCE.
>>>>>
>>>>> So what is missing is methods on Collection interfaces that
>>>>> require
>>>>> the collection implementation to be ordered like
>>>>> descendingList(),
>>>>> getFirst(), etc.
>>>>> Those methods that may throw a specific exception if the
>>>>> implementation is not ordered, not UnsupportedOperationException
>>>>> but
>>>>> a new one like NotOrderedException.
>>>>>
>>>>> So to answer to your question about LinkedHashSet, the reverse-
>>>>> ordered LinkedHashSet is a Set with a method descendingSet() that
>>>>> do
>>>>> not throw NotOrderedException like any Set with an order.
>>>>>
>>>>> To summarize, if we introduce ReversibleCollection, we should
>>>>> also
>>>>> introduce ImmutableCollection, NonNullableCollection and
>>>>> CheckedCollection.
>>>>> I think it's better to consider the fact that being ordered as a
>>>>> capability (hint: this is already what the Spliterator API does)
>>>>> and
>>>>> not as a specific interface.
>>>>>
>>>>>> s'marks
>>>>> R?mi

From hseigel at openjdk.java.net  Tue May 11 12:58:07 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 11 May 2021 12:58:07 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
Message-ID: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>

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 of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.

This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.

Thanks, Harold

-------------

Commit messages:
 - 8243287: Removal of Unsafe::defineAnonymousClass

Changes: https://git.openjdk.java.net/jdk/pull/3974/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8243287
  Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3974.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974

PR: https://git.openjdk.java.net/jdk/pull/3974

From mitsuru.kariya at oss.nttdata.com  Tue May 11 12:59:45 2021
From: mitsuru.kariya at oss.nttdata.com (Mitsuru Kariya)
Date: Tue, 11 May 2021 21:59:45 +0900
Subject: May I make a pull request for JDK-8153490?
Message-ID: <7bc586721a98b11760e1338c0676dd9c@oss.nttdata.com>

Hi,

While reading the SerialBlob source, I found that it's been over a year 
and a half since the JDK-8153490 was last updated.

Furthermore, according to the documentation of Blog.setBytes() (not 
SerialBlob.setBytes()), there are the following problems:

1. It says "If the end of the Blob value is reached while writing the 
array of bytes, then the length of the Blob value will be increased to 
accommodate the extra bytes."
But the current implementation throws SerialException.

2. It says "If the value specified for pos is greater than the length+1 
of the BLOB value then the behavior is undefined."
So I think that it should work correctly when pos == length+1 of the 
BLOB value.

May I make a pull request for these problems?

Also, if I may, SerialClob.setString() has the same problem, may I fix 
it together?

JDK-8153490:Cannot setBytes() if incoming buffer's length is bigger than 
number of elements we want to insert.
https://bugs.openjdk.java.net/browse/JDK-8153490

Please let me know if there is a better place to do so.

Thanks

From mitsuru.kariya at oss.nttdata.com  Tue May 11 13:11:00 2021
From: mitsuru.kariya at oss.nttdata.com (Mitsuru Kariya)
Date: Tue, 11 May 2021 22:11:00 +0900
Subject: Would anyone please reopen JDK-4991002?
Message-ID: <5a182c946c75707b7deb5c95175818a1@oss.nttdata.com>

Hi,

While reading the source for SerialBlob, I found that 
SerialBlob.position() does not work correctly.
So, I searched JBS and found the description in JDK-4991002 point 1, but 
it was closed by Cannot Reproduce.

It can be reproduced easily like below.

SerialBlob sb = new SerialBlob(new byte[]{1, 2, 3, 4, 5});
System.out.println(sb.position(new byte[]{1, 3, 5}, 1));

It should output "-1"(not found) but the current implementation outputs 
"3"(found at position 3).

So, would anyone please reopen JDK-4991002 for me?
(I cannot reopen it because I don't have an Author role.)

Furthermore, SerialClob has same problem and JDK-4991036 describes it.
So, may I fix it together?
Or do I need to separate the PR from JDK-4991002?

JDK-4991002:The class javax.sql.rowset.serial.SerialBlob is too buggy
https://bugs.openjdk.java.net/browse/JDK-4991002

JDK-4991036:The class javax.sql.rowset.serial.SerialClob is too buggy
https://bugs.openjdk.java.net/browse/JDK-4991036


Please let me know if there is a better place to do so.

Thanks

From brian.goetz at oracle.com  Tue May 11 13:20:27 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 11 May 2021 13:20:27 +0000
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
Message-ID: <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com>

There may be some JDK code that checks for anon classes by comparing the name to see if it contains a slash, especially tests, but which don?t say ?anonymous?.  Did you do a search for these idioms too, which are now dead tests?

Sent from my iPad

> On May 11, 2021, at 8:59 AM, 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 of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
> 
> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
> 
> Thanks, Harold
> 
> -------------
> 
> Commit messages:
> - 8243287: Removal of Unsafe::defineAnonymousClass
> 
> Changes: https://git.openjdk.java.net/jdk/pull/3974/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8243287
>  Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/3974.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974
> 
> PR: https://git.openjdk.java.net/jdk/pull/3974

From avoitylov at openjdk.java.net  Tue May 11 13:19:56 2021
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Tue, 11 May 2021 13:19:56 GMT
Subject: RFR: 8266310: deadlock while loading the JNI code
Message-ID: 

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 library load operation.

Problem being fixed:

The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread.

Proposed fix:

The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method.

The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared.

Testing:  jtreg and jck testing with no regressions. A new regression test was developed.

-------------

Commit messages:
 - JDK-8266310: deadlock while loading the JNI code
 - JDK-8266310: deadlock while loading the JNI code

Changes: https://git.openjdk.java.net/jdk/pull/3976/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3976&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266310
  Stats: 475 lines in 6 files changed: 456 ins; 0 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3976.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3976/head:pull/3976

PR: https://git.openjdk.java.net/jdk/pull/3976

From szegedia at gmail.com  Tue May 11 13:29:14 2021
From: szegedia at gmail.com (Attila Szegedi)
Date: Tue, 11 May 2021 15:29:14 +0200
Subject: JDK Dynalink only works with unconditionally exported packages
In-Reply-To: 
References: 
Message-ID: <50952190-5013-491D-B295-5A28E7833B61@gmail.com>

On 2021. May 11., at 1:51, Thiago Henrique Hupner  wrote:
> 
> Hi all.
> 
> I've been testing the JDK Dynalink recently and
> I think I've found a bug.
> 
> The class jdk.dynalink.beans.CheckRestrictedPackage checks
> if a package is restricted.
> 
> So, I have a class that has some static methods. But to Dynalink find the
> class,
> the class needs to be public. OK,
> I've changed my class to be public. However, it needs that
> the package of the class is exported in the module too.
> 
> I think this is a little too restrictive. I don't want to expose
> to my users some internal implementation.

The module exports is exactly the feature used to regulate what are you exposing from the module. In this case, you could have a class in a different package exposing those static methods (even if only just delegating to the original unexported class), and export those methods. 

Dynalink?s BeansLinker deliberately implemented in such a manner that it only allows access to entirely unrestricted classes. So what you?re experiencing is not a bug, it is the expected behavior. It?s admittedly a compromise between a simpler security model vs. losing some power.

> 
> The main problem is that the method
> CheckRestrictedPackage::isRestrictedClass
> does the following check:
> 
> // ...
> final String pkgName = name.substring(0, i);
> final Module module = clazz.getModule();
> if (module != null && !module.isExported(pkgName)) {
>    return true;
> }
> // ...
> 
> I have a feeling that this check should be changed to something like
> 
> // ...
> final String pkgName = name.substring(0, i);
> final Module module = clazz.getModule();
> if (module != null && !module.isOpen(pkgName,
> CheckRestrictedPackage.class.getModule())) {
>    return true;
> }
> // ...
> 
> In this way, my code can only "opens" a single package to the jdk.dynalink
> module,
> not having to unconditionally export a package.

If we did just what you suggested, then every package you?d open to jdk.dynalink would become wide open accessible to everyone through Dynalink. That?d obviously be a problem as it?d allow circumventing module visibility rules.

That would be fixable with some more work, though. It would be possible to create an enhancement where Dynalink allows linking to methods of non-globally-exported classes if it?d verify each such link attempt through sun.invoke.util.VerifyAccess.isMemberAccessible, using the data from the MethodHandle.Lookup object passed in LinkRequest. These lookup objects typically originate from the bootstrap methods for invokedynamic call sites in the target class.

Then you?d also indeed need to ensure that Dynalink can reflect on those packages, so you?d still have to open the package towards Dynalink, but Dynalink itself would enforce that it itself only allows linking call sites according to JVM linkage rules. 

This is not very simple to implement though, as the isRestrictedClass is used for various purposes right now, and would need to be replaced with something more granular, and then calls to VerifyAccess.isMemberAccessible would be needed to be added into the logic for resolving property getters and setters and method getters.

Dynalink already uses the Lookup objects for various purposes; it is used for linking invocations of @CallerSensitive-marked methods (which Dynalink supports) as well as for linkage-rules respecting creation of type conversions (it?s somewhat surprising that the concern would pop up there, but it does?) All just to say that Dynalink having to deal with JVM linkage rules isn?t foreign to it, it?s already doing it in some contexts, but it indeed currently doesn?t support linking to classes that aren?t world-exported.

Attila.

> 
> From what I could understand, in Nashorn, the generated classes
> were defined in the unnamed module, that always exports all the packages,
> so the access always worked.
> 
> The code can be found here:
> https://github.com/openjdk/jdk/blob/master/src/jdk.dynalink/share/classes/jdk/dynalink/beans/CheckRestrictedPackage.java#L94
> 
> Best regards.
> 
> Thiago


From alanb at openjdk.java.net  Tue May 11 13:31:02 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 11 May 2021 13:31:02 GMT
Subject: RFR: 8266310: deadlock while loading the JNI code
In-Reply-To: 
References: 
Message-ID: 

On Tue, 11 May 2021 13:10:30 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 library load operation.
> 
> Problem being fixed:
> 
> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread.
> 
> Proposed fix:
> 
> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method.
> 
> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared.
> 
> Testing:  jtreg and jck testing with no regressions. A new regression test was developed.

src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 478:

> 476: 
> 477:     // thread local native libraries stack
> 478:     private static final ThreadLocal> nativeLibraryThreadContext =

I would prefer not see thread locals introduced here. We've put a lot of effort into recent releases to eliminate the use of TLs from java.base.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3976

From alanb at openjdk.java.net  Tue May 11 13:40:54 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 11 May 2021 13:40:54 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
Message-ID: 

On Tue, 11 May 2021 12:50:31 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 of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
> 
> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
> 
> Thanks, Harold

test/jdk/java/lang/Class/GetModuleTest.java line 42:

> 40: import static org.testng.Assert.*;
> 41: 
> 42: public class GetModuleTest {

testGetModuleOnVMAnonymousClass is the only test here that uses ASM so you can remove the imports as part of the removal.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3974

From jlahoda at openjdk.java.net  Tue May 11 13:42:32 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 11 May 2021 13:42:32 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch
 (Preview)
Message-ID: 

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/jep406/jep406-20210430/specs/patterns-switch-jls.html

A summary of notable parts of the patch:
-to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
-to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
-in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
-Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
-TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
-nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.

The specdiff for the change is here (to be updated):
http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html

-------------

Commit messages:
 - Trailing whitespaces.
 - Cleanup, reflecting review comments.
 - Merge branch 'master' into JDK-8262891
 - JDK-8262891: Compiler implementation for Pattern Matching for switch

Changes: https://git.openjdk.java.net/jdk/pull/3863/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262891
  Stats: 3927 lines in 70 files changed: 3636 ins; 97 del; 194 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3863.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863

PR: https://git.openjdk.java.net/jdk/pull/3863

From mcimadamore at openjdk.java.net  Tue May 11 13:42:50 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 11 May 2021 13:42:50 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview)
In-Reply-To: 
References: 
Message-ID: 

On Tue, 4 May 2021 16:41:44 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/jep406/jep406-20210430/specs/patterns-switch-jls.html
> 
> A summary of notable parts of the patch:
> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
> 
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html

Good work. There's a lot to take in here. I think overall, it holds up well - I like how case labels have been extended to accommodate for patterns. In the front-end, I think there are some questions over the split between Attr and Flow - maybe it is unavoidable, but I'm not sure why some control-flow analysis happens in Attr instead of Flow and I left some questions to make sure I understand what's happening.

In the backend it's mostly good work - but overall the structure of the code, both in Lower and in TransPattern is getting very difficult to follow, given there are many different kind of switches each with its own little twist attached to it. It would be nice, I think (maybe in a separate cleanup?) if the code paths serving the different switch kinds could be made more separate, so that, when reading the code we can worry only about one possible code shape. That would make the code easier to document as well.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 100:

> 98:      *                       the {@code NameAndType} of the {@code InvokeDynamic}
> 99:      *                       structure and is stacked automatically by the VM.
> 100:      * @param labels non-null case labels - {@code String} and {@code Integer} constants

Can these types be mixed? E.g. can I pass, as static args: `42`, `Runnable.class`, `"hello"` ? If not, should be document, and throw?

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 102:

> 100:      * @param labels non-null case labels - {@code String} and {@code Integer} constants
> 101:      *                        and {@code Class} instances
> 102:      * @return the index into {@code labels} of the target value, if the target

Doesn't return an index. Returns a CallSite which, when invoked with an argument of type E (where E is the type of the target expression), returns the index into...

src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java line 306:

> 304: 
> 305:     /**
> 306:      * Visits an GuardPatternTree node.

Suggestion:

     * Visits a GuardPatternTree node.

src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java line 316:

> 314: 
> 315:     /**
> 316:      * Visits an AndPatternTree node.

Is this comment correct?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1685:

> 1683:                         log.error(DiagnosticFlag.SOURCE_LEVEL, selector.pos(),
> 1684:                                   Feature.PATTERN_SWITCH.error(this.sourceName));
> 1685:                         allowPatternSwitch = true;

I assume this logic is to show only one error in case we're compiling multiple methods with pattern switches and preview features are not enabled? Is this consistent with what happens with other preview features though?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1725:

> 1723:                                     log.error(DiagnosticFlag.SOURCE_LEVEL, expr.pos(),
> 1724:                                               Feature.CASE_NULL.error(this.sourceName));
> 1725:                                     allowCaseNull = true;

Same here about error recovery and minimize messages - if this is what we'd like to do, perhaps centralizing the check in Preview would be better (so that e.g. we'd return that a given preview feature is not supported only once).

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1790:

> 1788:                         if (isTotal) {
> 1789:                             if (hasTotalPattern) {
> 1790:                                 log.error(pat.pos(), Errors.DuplicateTotalPattern);

Hard to explain - but a lot of the code here feels more like it belongs to `Flow` than to `Attr`. E.g. these "duplicateXYZ" labels really want to say "unreachable code", I think. Is there a strong reason as to why all this code shouldn't (apart from code computing bindings) move to Flow? Seems that the logic is partially duplicated anyway...

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1861:

> 1859:         return null;
> 1860:     }
> 1861:     private Pair primaryType(JCPattern pat) {

Maybe a record here would lead for better code (no boxing of Boolean, but, more importantly, better field names for fst/snd). More generally, now that we have records I think we should think twice before using Pairs :-)

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 757:

> 755:         }
> 756: 
> 757:         private TypeSymbol patternType(JCPattern p) {

If we need to keep duplicated code, this could move to TreeInfo

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 757:

> 755:         }
> 756: 
> 757:         private TypeSymbol patternType(JCPattern p) {

If we need to keep duplicated code, this could move to TreeInfo

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2917:

> 2915:         void reportEffectivelyFinalError(DiagnosticPosition pos, Symbol sym) {
> 2916:             String subKey = switch (currentTree.getTag()) {
> 2917:                 case LAMBDA -> "lambda";

Can we make the switch return the fragment constant (e.g. Fragments.XYZ) rather than a String which is then re-wrapped?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3649:

> 3647:         if (!enumSwitch && !stringSwitch && !selector.type.isPrimitive() &&
> 3648:             cases.stream().anyMatch(c -> TreeInfo.isNull(c.labels.head))) {
> 3649:             //a switch over a boxed primitive, with a null case. Pick two constants that are

Is this comment correct? If we're here, can't this be just any pattern switch?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3729:

> 3727:         if (cases.stream().anyMatch(c -> TreeInfo.isNull(c.labels.head))) {
> 3728:             //for enum switches with case null, do:
> 3729:             //switch ($selector != null ? $mapVar[$selector.ordinal()] : -1) {...}

Very  clever trick to handle away null treatment with just an extra default label. I wonder if this logic isn't big enough to deserve its own `visitXYZSwitch` method, as we do for strings and enums in switch. It seems asymmetric that we do some bits of null handling here (in certain cases) but then enum switches will deal with null in a different way. We should probably test what kind of switch we're dealing with earlier, and then branch out to completely disjoint pieces of code, each with its own null handling

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MatchBindingsComputer.java line 124:

> 122:         // e.T = union(x.T, y.T)
> 123:         // e.F = intersection(x.F, y.F) (error recovery)
> 124:         List bindingsWhenTrue =

Is this duplicate code for MatchBindingComputer::binary(AND) ? If so, should at least the impl delegate to that?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 193:

> 191:                     : tree.expr.type;
> 192:             VarSymbol prevCurrentValue = currentValue;
> 193:             try {

IIUC, the changes here are to handle recursion of pattern in the instanceof case - e.g. `x instanceof (Foo foo)`. If so, it would be nice to have that reflected in the comment above.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 305:

> 303:                 selector = make.Ident(temp);
> 304:             } else {
> 305:                 List staticArgTypes = List.of(syms.methodHandleLookupType,

I guess strategy here is to convert the various labels into loadable constants and then pass them up to the bootstrap method which will give us back an int, which we'll use for a plain switch. If so, all this needs to be documented somehow.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 368:

> 366:                         JCContinue continueSwitch = make.Continue(null);
> 367:                         continueSwitch.target = tree;
> 368:                         c.stats = c.stats.prepend(make.If(makeUnary(Tag.NOT, test).setType(syms.booleanType),

I assume this is code which "resumes" to the following `case` if the pattern doesn't match. I guess in most cases the bootstrap method would do the check anyway - but I suppose that with guards, the bootstrap method, alone, cannot guarantee the match. Also, it seems like this requires backend support for `continue` in switch. Again, all this needs to be better documented, it's pretty hard to infer all this by looking at the code.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 776:

> 774:         } else {
> 775:             JCPattern pattern;
> 776:             JCExpression e = parsedType == null ? term(EXPR | TYPE | NOLAMBDA/* | NOINVOCATION*/) : parsedType;

what's up with NO_INVOCATION?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3004:

> 3002:                 JCCaseLabel label = parseCaseLabel();
> 3003: 
> 3004:                 //TODO: final

What does this `todo` refers to?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3078:

> 3076:                 }
> 3077:                 Token twoBack;
> 3078:                 boolean pattern = S.token(lookahead - 1).kind == IDENTIFIER && ((twoBack = S.token(lookahead - 2)).kind == IDENTIFIER || twoBack.kind == GT || twoBack.kind == GTGT || twoBack.kind == GTGTGT);

tricky - but I think correct.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3085:

> 3083:                 }
> 3084:             }
> 3085:             //XXX: modifiers!

Another todo here

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 501:

> 499: 
> 500: compiler.err.pattern.dominated=\
> 501:     this pattern is dominated by a preceding pattern

Not sure whether the concept of "dominance" is the one that will work best here. As I said elsewhere, this is, morally, unreachable code.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 520:

> 518: 
> 519: compiler.err.multiple.patterns=\
> 520:     multiple pattern declarations

This text is very terse and doesn't really say what's wrong with the code. I think the point here is that we don't want code like this:


case String s, Integer i: ...

because this is morally:


case String s:
case Integer i: ...

which is, again, fall-through to a pattern. Maybe, just reusing the same "fall-through" message would be ok here?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3863

From jlahoda at openjdk.java.net  Tue May 11 13:42:54 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 11 May 2021 13:42:54 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview)
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 May 2021 20:48:34 GMT, Maurizio Cimadamore  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/jep406/jep406-20210430/specs/patterns-switch-jls.html
>> 
>> A summary of notable parts of the patch:
>> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
>> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
>> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
>> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
>> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
>> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
>> 
>> The specdiff for the change is here (to be updated):
>> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html
>
> Good work. There's a lot to take in here. I think overall, it holds up well - I like how case labels have been extended to accommodate for patterns. In the front-end, I think there are some questions over the split between Attr and Flow - maybe it is unavoidable, but I'm not sure why some control-flow analysis happens in Attr instead of Flow and I left some questions to make sure I understand what's happening.
> 
> In the backend it's mostly good work - but overall the structure of the code, both in Lower and in TransPattern is getting very difficult to follow, given there are many different kind of switches each with its own little twist attached to it. It would be nice, I think (maybe in a separate cleanup?) if the code paths serving the different switch kinds could be made more separate, so that, when reading the code we can worry only about one possible code shape. That would make the code easier to document as well.

@mcimadamore, thanks a lot for the comments! I tried to reflect most of them in https://github.com/openjdk/jdk/pull/3863/commits/1a5a424139a52d0f93e16980c6b42cf29dd908ef - please let me know how that looks. Thanks!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1790:
> 
>> 1788:                         if (isTotal) {
>> 1789:                             if (hasTotalPattern) {
>> 1790:                                 log.error(pat.pos(), Errors.DuplicateTotalPattern);
> 
> Hard to explain - but a lot of the code here feels more like it belongs to `Flow` than to `Attr`. E.g. these "duplicateXYZ" labels really want to say "unreachable code", I think. Is there a strong reason as to why all this code shouldn't (apart from code computing bindings) move to Flow? Seems that the logic is partially duplicated anyway...

`Attr` was always checking duplicated constants and duplicated default, so checking for pattern dominance (which could be seen as an extension to duplicate constant labels) and total patterns (which is an extension to duplicated default) here seemed reasonable. We also have a couple of other similar checks performed by `Attr`, like duplicated statement labels, or that exception types in multicatch are disjoint. These are checks that don't need DA/DU, while I think `Flow` does mostly checks that require DA/DU.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3649:
> 
>> 3647:         if (!enumSwitch && !stringSwitch && !selector.type.isPrimitive() &&
>> 3648:             cases.stream().anyMatch(c -> TreeInfo.isNull(c.labels.head))) {
>> 3649:             //a switch over a boxed primitive, with a null case. Pick two constants that are
> 
> Is this comment correct? If we're here, can't this be just any pattern switch?

Patterns switches are resolved before Lower, so in Lower there should be no pattern switches. I'll add a comment in this sense at an appropriate place.

> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 501:
> 
>> 499: 
>> 500: compiler.err.pattern.dominated=\
>> 501:     this pattern is dominated by a preceding pattern
> 
> Not sure whether the concept of "dominance" is the one that will work best here. As I said elsewhere, this is, morally, unreachable code.

The specification uses "dominance", so it seemed appropriate to use the same term that is used by the specification. We can say "unreachable code", of course, but it will not be consistent with what the specification says, and also with what we do for duplicate constant labels. Also considering code like:

switch (o) {
     case A a -> {}
     case B b -> {} //error on this line
}


It may not be obvious why the code is "unreachable", while saying "dominated" might be more helpful/clear.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3863

From mcimadamore at openjdk.java.net  Tue May 11 13:42:55 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 11 May 2021 13:42:55 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview)
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 May 2021 20:35:45 GMT, Maurizio Cimadamore  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/jep406/jep406-20210430/specs/patterns-switch-jls.html
>> 
>> A summary of notable parts of the patch:
>> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
>> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
>> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
>> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
>> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
>> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
>> 
>> The specdiff for the change is here (to be updated):
>> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 102:
> 
>> 100:      * @param labels non-null case labels - {@code String} and {@code Integer} constants
>> 101:      *                        and {@code Class} instances
>> 102:      * @return the index into {@code labels} of the target value, if the target
> 
> Doesn't return an index. Returns a CallSite which, when invoked with an argument of type E (where E is the type of the target expression), returns the index into...

It should also mention that the handle returned accepts a start index (which is used by the continue logic)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3863

From alanb at openjdk.java.net  Tue May 11 13:45:01 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 11 May 2021 13:45:01 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: 
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 
Message-ID: 

On Tue, 11 May 2021 13:37:32 GMT, Alan Bateman  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 of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> test/jdk/java/lang/Class/GetModuleTest.java line 42:
> 
>> 40: import static org.testng.Assert.*;
>> 41: 
>> 42: public class GetModuleTest {
> 
> testGetModuleOnVMAnonymousClass is the only test here that uses ASM so you can remove the imports as part of the removal.

Can you check test/jdkjava/lang/Class/attributes/ClassAttributesTest.java? It may minimally need a comment to be updated. That's the only additional test that I could find in test/jdk.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3974

From forax at univ-mlv.fr  Tue May 11 13:50:13 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 11 May 2021 15:50:13 +0200 (CEST)
Subject: [External] : Re: ReversibleCollection proposal
In-Reply-To: 
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 
 <2063372755.1742538.1620211264481.JavaMail.zimbra@u-pem.fr>
 
 <255012227.325293.1620642164845.JavaMail.zimbra@u-pem.fr>
 <9de1615b4961bf39f7ec6b7f514774d14583aa31.camel@gmail.com>
 <295457227.1124853.1620718002979.JavaMail.zimbra@u-pem.fr>
 
Message-ID: <1380137551.1496419.1620741013377.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Peter Levart" 
> ?: "Remi Forax" , "dfranken jdk" 
> Cc: "Stuart Marks" , "core-libs-dev" 
> Envoy?: Mardi 11 Mai 2021 13:44:08
> Objet: Re: [External] : Re: ReversibleCollection proposal

> Hi Remi,

Hi Peter,

> 
> 
> I see you avoided addFirst/addLast methods. While getFirst/removeFirst
> could be specified to be consistent with iterator().next(), so the
> "first" part of the name would be softer, addFirst is cursed two times:
> it has no equivalent in current API and it clashes with void returning
> method in Deque. So the best "soft" alternative seems to be the existing
> Collection.add(E) method which is equivalent to addFirst() when
> Collection is ordered or something totally different when it is sorted
> (i.e. SortedSet) and again different when it is neither.

yes, i've chosen to not have addFirst/addLast because of addFirst/addLast on Deque returning void.

To simplify the issue of adding addFirst/addLast on List, SortedSet/NavigableSet, EnumSet, LinkedHashSet and adding addFirstEntry/addLastEntry on SortedMap/NavigableMap, EnumMap and LinkedHashMap can be discussed separately. 

> 
> To avoid bugs when an API expects an ordered Collection but has no
> static type to express that, a means to perform a runtime check would be
> needed. Marker interface is a way to add a bit of static typing to be
> used in generic methods like:
> 
> 
>  & Ordered> void doSomething(C
> orderedCollection);
> 
> 
> ...but that's very limited. So probably not worth it.

yes,
and also if we go with Ordered people will also want Sorted, NoDuplicate, NonNullable, etc.


> Stream API choose a different approach: Spliterator.characteristics(). So probably,
> Collection.characteristics() could also be added. The set of bit
> constants in Spliterator is applicable also to Collection (except
> SUBSIZED which has no sense in Collection, while SIZED is always present):
> 
> ???? ORDERED
> ???? DISTINCT
> ???? SORTED
> ???? SIZED
> ???? NONNULL
> ???? IMMUTABLE
> ???? CONCURRENT
> 
> Specifically for Collection I would also add:
> 
> ??? REVERSIBLE
> 
> ...to indicate that Collection.reversed() would succeed.
> 
> 
> The question is what would the default value of
> Collection.characteristics() be. The most sensible would be SIZED with
> overrides in:
> 
> - List (SIZED | ORDERED | REVERSIBLE)
> - Set (SIZED | DISTINCT)
> - SortedSet (SIZED | SORTED | REVERSIBLE | DISTINCT)
> - LinkedHashSet (SIZED | ORDERED | REVERSIBLE | DISTINCT)
> - Queue (SIZED | ORDERED)
> - Deque (SIZED | ORDERED | REVERSIBLE)
> 
> ... Immutable JDK List and Set implementations could also add IMMUTABLE
>| NONNULL, while concurrent JDK implementations would add CONCURRENT |
> NONNULL.
> 
> 
> ...but one could also base default value on something like this:
> 
> 
> default int characteristics() {
> ??? return stream().spliterator().characteristics() &
> ~Spliterator.SUBSIZED;
> }


There is already a method Collection.spliterator() [1], no need to use an intermediary stream
and also collection.spliterator() != collection.stream().spliterator(), but i'm not sure if it is specified somewhere.

For me, adding a method characteristics() to Collection is also a separate issue,
perhaps it's more a documentation issue, so adding a paragraph in the javadoc explaining what are the Spliterator characteristics of each collections is enough.

> 
> 
> Wrappers like Collections.unmodifiableXXX() would just delegate to the
> underlying Collection and augment the returned bits (with IMMUTABLE for
> example).
> 
> 
> An API that expects a particular kind of collection could then check
> that at runtime. Some of existing collections would have to be updated
> to express the correct characteristics, but defaults in interfaces would
> be sufficient for most and conservative.
> 
> 
> WDYT?
> 
> Peter

R?mi

[1] https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/Collection.html#spliterator()

> 
> 
> On 5/11/21 9:26 AM, forax at univ-mlv.fr wrote:
>>
>>> Are you proposing to just add methods to the root Collection interface,
>>> because it already has methods which may or may not be implemented or
>>> throw Exceptions by its implementations ?
>> yes, the idea is to add getFirst/getLast/removeFirst/removeLast and reversed on
>> Collection as default methods.
>> Something like
>>
>> interface Collection {
>>    /**
>>     * throws NoSuchElementException if the collection is empty
>>     */
>>    public default E getFirst() {
>>      return iterator().next();
>>    }
>>
>>    /**
>>     * throws NoSuchElementException if the collection is empty
>>     * throws UnsupportedOperationException if the collection is non mutable
>>     */
>>    public default E removeFirst() {
>>      var it = iterator();
>>      var element = it.next();
>>      it.remove();
>>      return element;
>>    }
>>
>>    /**
>>     * throws NonOrderedCollectionException if the collection is non ordered
>>     */
>>    public default Collection reversed() {
>>      throw new NonOrderedCollectionException();
>>    }
>>
>>    /**
>>     * throws NoSuchElementException if the collection is empty
>>     * throws NonOrderedCollectionException if the collection is non ordered
>>     */
>>    public default E getLast() {
>>      return reversed().getFirst();
>>    }
>>
>>    /**
>>     * throws NoSuchElementException if the collection is empty
>>     * throws UnsupportedOperationException if the collection is non mutable
>>     * throws NonOrderedCollectionException if the collection is non ordered
>>     */
>>    public default E removeLast() {
>>      return reversed().removeFirst();
>>    }
>> }
>>
>>
>> And adds an implementation of reversed(), getLast() and removeLast() on
>> NavigableSet/LinkedHashSet/EnumSet/Deque and List.
>>
>> And do the same thing for Map:
>>
>> interface Map {
>>    /**
>>     * throws NoSuchElementException if the map is empty
>>     */
>>    public default Map.Entry getFirstEntry() {
>>      return entrySet().iterator().next();
>>    }
>>
>>    /**
>>     * throws NoSuchElementException if the map is empty
>>     * throws UnsupportedOperationException if the map is non mutable
>>     */
>>    public default  Map.Entry removeFirstEntry() {
>>      var it = entrySet().iterator();
>>      var element = it.next();
>>      it.remove();
>>      return element;
>>    }
>>
>>    /**
>>     * throws NonOrderedCollectionException if the map.keySet() is non ordered
>>     */
>>    public default Map reversedMap() {
>>      throw new NonOrderedCollectionException();
>>    }
>>
>>    /**
>>     * throws NoSuchElementException if the map is empty
>>     * throws NonOrderedCollectionException if the map.keySet() is non ordered
>>     */
>>    public default E getLastEntry() {
>>      return reversedMap().getFirstEntry();
>>    }
>>
>>    /**
>>     * throws NoSuchElementException if the map is empty
>>     * throws UnsupportedOperationException if the map is non mutable
>>     * throws NonOrderedCollectionException if the map.keySet() is non ordered
>>     */
>>    public default E removeLast() {
>>      return reversedMap().removeFirstEntry();
>>    }
>> }
>>
>> And adds an implementation of reversedMap(), getLastEntry() and
>> removeLastEntry() on NavigableMap/LinkedHasMap and EnumMap.
>>
>>
>>> But we could also view "having (possibly duplicate) items in a
>>> sequence" as a capability and that is defined by an actual interface,
>>> List.
>> It already exist for a Spliterator, the capability is called DISTINCT, by
>> example, set.stream() and list.stream().distinct() are both Streams with no
>> duplicate.
>>
>>> I do fear that if we add methods to the Collection interface, users
>>> might not expect them to throw exceptions. E.g. if we add getFirst(),
>>> users may just expect it to return the element that iterator().next()
>>> or .stream().findFirst().orElseThrow() would return instead of an
>>> UnsupportedOperationException. And while HashSet does not have a
>>> defined order, it would in practice always return the same element.
>> I agree, getFirst() and removeFirst() should have their semantics based on
>> iterator (see above),
>> because as you said, it's already how findFirst() is specified.
>>
>>> So while I accept that some hidden capabilities are surfaced only
>>> through return values of certain methods, I think an interface is still
>>> a better choice here. However, if we go that route, I also agree on the
>>> fact that we might need to explore defining proper interfaces for the
>>> other capabilities at some point.
>>>
>>> Kind regards,
>>>
>>> Dave
>> regards,
>> R?mi
>>
>>> On Mon, 2021-05-10 at 12:22 +0200, forax at univ-mlv.fr wrote:
>>>> ----- Mail original -----
>>>>> De: "dfranken jdk" 
>>>>> ?: "Remi Forax" , "Stuart Marks"
>>>>> 
>>>>> Cc: "core-libs-dev" 
>>>>> Envoy?: Dimanche 9 Mai 2021 12:13:58
>>>>> Objet: Re: [External] : Re: ReversibleCollection proposal
>>>>> When I thought about Collection's role in the hierarchy, it seemed
>>>>> to
>>>>> me that 'Collection' is an interface for describing how elements
>>>>> are
>>>>> stored in a cardboard box (we can and and remove them) and that we
>>>>> might need a different, yet related, interface to describe how to
>>>>> retrieve the items from the box. This way we are not tied to the
>>>>> Collection hierarchy and we could have one Set implementation which
>>>>> is
>>>>> ordered and another Set implementation which is not and they would
>>>>> both
>>>>> still implement Collection, but only one would implement the
>>>>> interface.
>>>> So you want to model ReversibleSet as Set + Reversible,
>>>> Reversible being an interface with a small number of method specific
>>>> to the fact that the implementation is reversible.
>>>>
>>>> This does not work well for two reasons,
>>>> - there is no syntax to represent the union of types in Java,
>>>>  ?? Set & Reversible set = ...
>>>>  ? is not a valid syntax. You can use a type variable with several
>>>> bounds instead but it does work nicely with the rest of the language
>>>> (overidding, overloading, etc).
>>>>
>>>> - having public methods that takes an interface with few methods is a
>>>> common design error.
>>>>  ? Let suppose you have a method foo that only prints the elements of
>>>> a collection, in that case you may want to type the first parameter
>>>> as Iterable or Collection.
>>>>  ? But requirements change an now you want to prints the elements
>>>> sorted, oops, you have to change the signature of the public method
>>>> which may be something not possible
>>>>  ? depending how many "clients" this method has.
>>>>  ? Providing interfaces with a small number of access methods will
>>>> lead to this kind of issue.
>>>>
>>>>> Imagine an interface like 'java.lang.OrderedEnumerable` if you will
>>>>> with methods such as 'first(), last(), etc', then each
>>>>> implementation
>>>>> would be free to choose to implement the interface or not. I also
>>>>> thought about 'OrderedIterable', but there would be too much
>>>>> confusion
>>>>> with 'Iterable', but I think these are related too. Retrieving
>>>>> items is
>>>>> an iteration problem, not a storage problem.
>>>> The problem is that is you multiply the number of interfaces to
>>>> access the elements, you add the dilemma of choice in the mix.
>>>> The first iteration of the Scala Collection were like this, too many
>>>> interfaces, at least for my taste.
>>>>
>>>>> While I would love to see the Collection hierarchy redesigned to
>>>>> also
>>>>> allow for ImmutableCollection which for instance would not have an
>>>>> `add(T e)` method, I don't think we can simply do something like
>>>>> that
>>>>> without breaking too many things.
>>>> Dear Santa, i want an interface BuilderCollection that only allows
>>>> add() but no remove()/clear(), because if you can not remove
>>>> elements, then all the iterators can implement the snapshot at the
>>>> beginning semantics,
>>>> so no ConcurrentModificationException anymore. For me, being able to
>>>> snapshot/freeze a collection is better than an ImmutableCollection,
>>>> because it can be immutable when you want.
>>>>
>>>> Anyway, it's not gonna to happen, there is so many ways to slice an
>>>> onion and each have pros and cons and providing all the possible
>>>> interfaces is a good.way to make something simple complex.
>>>>
>>>>> So in short, separating retrieval aspects from storage aspects with
>>>>> a
>>>>> different interface might be the way to go.
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Dave Franken
>>>>>
>>>> regards,
>>>> R?mi
>>>>
>>>>> On Wed, 2021-05-05 at 12:41 +0200, forax at univ-mlv.fr?wrote:
>>>>>> ----- Mail original -----
>>>>>>> De: "Stuart Marks" 
>>>>>>> ?: "Remi Forax" 
>>>>>>> Cc: "core-libs-dev" 
>>>>>>> Envoy?: Mercredi 5 Mai 2021 02:00:03
>>>>>>> Objet: Re: [External] : Re: ReversibleCollection proposal
>>>>>>> On 5/1/21 5:57 AM, forax at univ-mlv.fr?wrote:
>>>>>>>> I suppose the performance issue comes from the fact that
>>>>>>>> traversing a
>>>>>>>> LinkedHahSet is slow because it's a linked list ?
>>>>>>>>
>>>>>>>> You can replace a LinkedHashSet by a List + Set, the List
>>>>>>>> keeps
>>>>>>>> the values in
>>>>>>>> order, the Set avoids duplicates.
>>>>>>>>
>>>>>>>> Using a Stream, it becomes
>>>>>>>>  ?? Stream.of(getItemsFromSomeplace(),
>>>>>>>> getItemsFromAnotherPlace(),
>>>>>>>>  ?? getItemsFromSomeplaceElse())
>>>>>>>>  ??? .flatMap(List::stream)
>>>>>>>>  ??? .distinct()????????????? // use a Set internally
>>>>>>>>  ??? .collect(toList());
>>>>>>> The problem with any example is that simplifying assumptions
>>>>>>> are
>>>>>>> necessary for
>>>>>>> showing the example, but those assumptions enable it to be
>>>>>>> easily
>>>>>>> picked apart.
>>>>>>> Of
>>>>>>> course, the example isn't just a particular example; it is a
>>>>>>> *template* for a
>>>>>>> whole
>>>>>>> space of possible examples. Consider the possibility that the
>>>>>>> items
>>>>>>> processing
>>>>>>> client needs to do some intermediate processing on the first
>>>>>>> group
>>>>>>> of items
>>>>>>> before
>>>>>>> adding the other groups. This might not be possible to do using
>>>>>>> streams. Use
>>>>>>> your
>>>>>>> imagination.
>>>>>>>
>>>>>>>> I think there are maybe some scenarios where
>>>>>>>> ReversibleCollection
>>>>>>>> can be useful,
>>>>>>>> but they are rare, to the point where when there is a good
>>>>>>>> scenario for it
>>>>>>>> people will not recognize it because ReversibleCollection
>>>>>>>> will
>>>>>>>> not be part of
>>>>>>>> their muscle memory.
>>>>>>> I'm certain that uses of RC/RS will be rare in the beginning,
>>>>>>> because they will
>>>>>>> be
>>>>>>> new, and people won't be familar with them. And then there will
>>>>>>> the
>>>>>>> people who
>>>>>>> say
>>>>>>> "I can't use them because I'm stuck on JDK 11 / 8 / 7 / 6 ...."
>>>>>>> It
>>>>>>> was the same
>>>>>>> thing with lambdas and streams in Java 8, with List.of() etc in
>>>>>>> Java 9, records
>>>>>>> in
>>>>>>> Java 16, etc. This wasn't an argument not to add them, and it
>>>>>>> isn't
>>>>>>> an argument
>>>>>>> not
>>>>>>> to add RC/RS.
>>>>>> All the changes you are listing here are "client side" changes,
>>>>>> the
>>>>>> ones that can be adopted quickly because they do not require to
>>>>>> change the API side of any libraries.
>>>>>> ReversibleCollection is an API side change, like generics is,
>>>>>> those
>>>>>> changes have a far higher cost because you have to wait your
>>>>>> library
>>>>>> dependencies to be updated.
>>>>>> On the Valhalla list, we have discussed several times about how
>>>>>> to
>>>>>> alleviate those API side change cost using automatic bridging or
>>>>>> methods forwarding, even for Valhalla, we are currently moving in
>>>>>> a
>>>>>> state where those mechanisms are not needed.
>>>>>>
>>>>>>>> There is a real value to add methods like
>>>>>>>> descendingSet/descendingList()/getFirst/getLast on existing
>>>>>>>> collections, but we
>>>>>>>> don't need a new interface (or two) for that.
>>>>>>> It depends on what you mean by "need". Sure, we could get away
>>>>>>> without this;
>>>>>>> after
>>>>>>> all, we've survived the past twenty years without it, so we
>>>>>>> could
>>>>>>> probably
>>>>>>> survive
>>>>>>> the next twenty years as well.
>>>>>>>
>>>>>>> It would indeed be useful to add various methods to List,
>>>>>>> Deque,
>>>>>>> SortedSet, and
>>>>>>> LinkedHashSet to provide a full set of methods on all of them.
>>>>>>> And
>>>>>>> it would also
>>>>>>> be
>>>>>>> nice to have those methods be similar to one another. An
>>>>>>> interface
>>>>>>> helps with
>>>>>>> that,
>>>>>>> but I agree, that's not really the reason to have an interface
>>>>>>> though.
>>>>>>>
>>>>>>> The reversed-view concept could also be added individually to
>>>>>>> the
>>>>>>> different
>>>>>>> places.
>>>>>>> A reverse-ordered List is a List, a reverse-ordered Deque is a
>>>>>>> Deque, a
>>>>>>> reverse-ordered SortedSet is a SortedSet, and a reverse-ordered
>>>>>>> LinkedHashSet is
>>>>>>> a
>>>>>>> ... ? And what is the type of the keySet of a LinkedHashMap,
>>>>>>> that
>>>>>>> enables one to
>>>>>>> (say) get the last element?
>>>>>> see below
>>>>>>
>>>>>>> After working with a system like this for a while, it begins to
>>>>>>> emerge that
>>>>>>> there is
>>>>>>> an abstraction missing from the collections framework,
>>>>>>> something
>>>>>>> like an
>>>>>>> "ordered
>>>>>>> collection". People have been missing this for quite a long
>>>>>>> time.
>>>>>>> The most
>>>>>>> recent
>>>>>>> example (which this proposal builds on) is Tagir's proposal
>>>>>>> from a
>>>>>>> year ago. And
>>>>>>> it's been asked about several times before that.
>>>>>>> ReversibleCollection fills in
>>>>>>> that
>>>>>>> missing abstraction.
>>>>>> The abstraction already exists but it's not defined in term of
>>>>>> interface because it's an implementation decision and those are
>>>>>> cleanly separated in the current Collection design.
>>>>>>
>>>>>> Let take a step back, the collection API defines basic data
>>>>>> structure
>>>>>> operations in term of interfaces like List, Deque, Set, etc those
>>>>>> interfaces are decoupled from implementation capabilities like
>>>>>> mutable, nullable, ordered and checked.
>>>>>>
>>>>>> Depending on the implementation capabilities, the interfaces
>>>>>> method
>>>>>> implementation may throw an exception, non-mutable
>>>>>> implementations
>>>>>> use UnsupportedOperationException, non-nullable implementations
>>>>>> use
>>>>>> NPE and checked implementations use CCE.
>>>>>>
>>>>>> So what is missing is methods on Collection interfaces that
>>>>>> require
>>>>>> the collection implementation to be ordered like
>>>>>> descendingList(),
>>>>>> getFirst(), etc.
>>>>>> Those methods that may throw a specific exception if the
>>>>>> implementation is not ordered, not UnsupportedOperationException
>>>>>> but
>>>>>> a new one like NotOrderedException.
>>>>>>
>>>>>> So to answer to your question about LinkedHashSet, the reverse-
>>>>>> ordered LinkedHashSet is a Set with a method descendingSet() that
>>>>>> do
>>>>>> not throw NotOrderedException like any Set with an order.
>>>>>>
>>>>>> To summarize, if we introduce ReversibleCollection, we should
>>>>>> also
>>>>>> introduce ImmutableCollection, NonNullableCollection and
>>>>>> CheckedCollection.
>>>>>> I think it's better to consider the fact that being ordered as a
>>>>>> capability (hint: this is already what the Spliterator API does)
>>>>>> and
>>>>>> not as a specific interface.
>>>>>>
>>>>>>> s'marks
> >>>>> R?mi

From mitsuru.kariya at oss.nttdata.com  Tue May 11 13:53:23 2021
From: mitsuru.kariya at oss.nttdata.com (Mitsuru Kariya)
Date: Tue, 11 May 2021 22:53:23 +0900
Subject: SerialBlob has an inconsistency between equals() and hashCode()
Message-ID: <632457ae1d297a00c02c7709642ff4d6@oss.nttdata.com>

Hi,

Please see the sample code below.

SerialBlob sb1 = new SerialBlob(new byte[]{1, 2, 3});
SerialBlob sb2 = new SerialBlob(new byte[]{1, 2, 3, 4, 5});
sb2.truncate(3);
System.out.println(sb1.equals(sb2));
System.out.println(sb1.hashCode() == sb2.hashCode());

I think that it should output "true" & "true" but the current 
implementation outputs "true" & "false".

I know the use of SerialBlob.hashCode() is uncommon, but I think it is 
better to be fixed.
If it's worth changing, could anyone submit this issue to JBS for me?
I'm ready to submit a pull request, but I don't have an Author role.

Please let me know if there is a better place to do so.

Thanks

From erikj at openjdk.java.net  Tue May 11 13:56:03 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 11 May 2021 13:56:03 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview)
In-Reply-To: 
References: 
Message-ID: <5tkFlMzpxFP1UFGuwI7u0mpFCt_hExf6SLwQVCJnfJs=.8878adb9-f423-408a-9a62-41334467e49f@github.com>

On Tue, 4 May 2021 16:41:44 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/jep406/jep406-20210430/specs/patterns-switch-jls.html
> 
> A summary of notable parts of the patch:
> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
> 
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html

make/CompileInterimLangtools.gmk line 52:

> 50: 
> 51: $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \
> 52:     FILES := $(TOPDIR)/src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java $(TOPDIR)/src/java.base/share/classes/jdk/internal/javac/NoPreview.java, \

Please break this line (adding 4 additional space indent from the original line). Otherwise build changes ok.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3863

From hseigel at openjdk.java.net  Tue May 11 14:10:42 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 11 May 2021 14:10:42 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v2]
In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
Message-ID: 

> 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 of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
> 
> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
> 
> Thanks, Harold

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  test fixes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3974/files
  - new: https://git.openjdk.java.net/jdk/pull/3974/files/233a4725..35c6634c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00-01

  Stats: 5 lines in 2 files changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3974.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974

PR: https://git.openjdk.java.net/jdk/pull/3974

From hseigel at openjdk.java.net  Tue May 11 14:13:49 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 11 May 2021 14:13:49 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
Message-ID: <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>

> 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 of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
> 
> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
> 
> Thanks, Harold

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  fix GetModuleTest.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3974/files
  - new: https://git.openjdk.java.net/jdk/pull/3974/files/35c6634c..874a1603

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3974.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974

PR: https://git.openjdk.java.net/jdk/pull/3974

From hseigel at openjdk.java.net  Tue May 11 14:13:51 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 11 May 2021 14:13:51 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: 
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 
 
Message-ID: 

On Tue, 11 May 2021 13:41:53 GMT, Alan Bateman  wrote:

>> test/jdk/java/lang/Class/GetModuleTest.java line 42:
>> 
>>> 40: import static org.testng.Assert.*;
>>> 41: 
>>> 42: public class GetModuleTest {
>> 
>> testGetModuleOnVMAnonymousClass is the only test here that uses ASM so you can remove the imports as part of the removal.
>
> Can you check test/jdkjava/lang/Class/attributes/ClassAttributesTest.java? It may minimally need a comment to be updated. That's the only additional test that I could find in test/jdk.

Hi Alan,
Thanks for find this.  I removed the unneeded imports and @modules from GetModulesTest.java and updated the comment in ClassAttributesTest.java.
Thanks, Harold

-------------

PR: https://git.openjdk.java.net/jdk/pull/3974

From harold.seigel at oracle.com  Tue May 11 14:15:10 2021
From: harold.seigel at oracle.com (Harold Seigel)
Date: Tue, 11 May 2021 10:15:10 -0400
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com>
Message-ID: <8013d5ad-b06f-29c1-9287-e3408ec86413@oracle.com>

Hi Brian,

Thanks for looking at this.

The JDK no longer creates unsafe anon classes.? So, those tests could 
only find an unsafe anonymous class if they explicitly created one.? In 
which case, the tests would need to call Unsafe.defineAnonymousClass().? 
And, hopefully, those tests have been handled in this webrev.

If there are dead tests then they probably died when the JDK stopped 
creating unsafe anon classes.? Note that none of them showed up as 
failures during regression testing.

Harold

On 5/11/2021 9:20 AM, Brian Goetz wrote:
> There may be some JDK code that checks for anon classes by comparing the name to see if it contains a slash, especially tests, but which don?t say ?anonymous?.  Did you do a search for these idioms too, which are now dead tests?
>
> Sent from my iPad
>
>> On May 11, 2021, at 8:59 AM, 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 of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>>
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>>
>> Thanks, Harold
>>
>> -------------
>>
>> Commit messages:
>> - 8243287: Removal of Unsafe::defineAnonymousClass
>>
>> Changes: https://git.openjdk.java.net/jdk/pull/3974/files
>> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8243287
>>   Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod
>>   Patch: https://git.openjdk.java.net/jdk/pull/3974.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974
>>
>> PR: https://git.openjdk.java.net/jdk/pull/3974

From github.com+828220+forax at openjdk.java.net  Tue May 11 14:24:54 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 11 May 2021 14:24:54 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview)
In-Reply-To: 
References: 
Message-ID: 

On Tue, 4 May 2021 16:41:44 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/jep406/jep406-20210430/specs/patterns-switch-jls.html
> 
> A summary of notable parts of the patch:
> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
> 
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 77:

> 75:     }
> 76: 
> 77:     private static MethodHandle typeInitHook(T receiver) {

There is no point to have a type parameter here,

  private static MethodHandle typeInitHook(CallSite receiver) {

will work the same

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 131:

> 129: 
> 130:     private static void verifyLabel(Object label) {
> 131:         if (Objects.isNull(label)) {

`if (label == true) {` is more readable as said in the javadoc of `Objects.isNull`

-------------

PR: https://git.openjdk.java.net/jdk/pull/3863

From mitsuru.kariya at oss.nttdata.com  Tue May 11 15:00:10 2021
From: mitsuru.kariya at oss.nttdata.com (Mitsuru Kariya)
Date: Wed, 12 May 2021 00:00:10 +0900
Subject: SerialBlob.getBytes() may throw ArrayIndexOutOfBoundsException when
 pos > 1
Message-ID: 

Hi,

Please see the sample code below.

SerialBlob sb = new SerialBlob(new byte[]{1, 2, 3});
System.out.println(Arrays.toString(sb.getBytes(3, 3)));

I think that it should output "[3]" but the current implementation 
throws ArrayIndexOutOfBoundsException.

If it's worth changing, could anyone submit this issue to JBS for me?
I'm ready to submit a pull request, but I don't have an Author role.

Please let me know if there is a better place to do so.

Thanks

From mbaesken at openjdk.java.net  Tue May 11 14:59:06 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 11 May 2021 14:59:06 GMT
Subject: RFR: JDK-8266918: merge_stack in check_code.c add NULL check
Message-ID: 

Hello, please review this small Sonar finding.
Sonar reports a potential NULL pointer dereference here :
https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8CPLBBG2CXpcnh_z&resolved=false&severities=MAJOR&types=BUG
"Access to field 'item' results in a dereference of a null pointer (loaded from variable 'new')"
It would be better to add a check .

-------------

Commit messages:
 - JDK-8266918

Changes: https://git.openjdk.java.net/jdk/pull/3979/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3979&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266918
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3979.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3979/head:pull/3979

PR: https://git.openjdk.java.net/jdk/pull/3979

From asemenyuk at openjdk.java.net  Tue May 11 15:14:55 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 11 May 2021 15:14:55 GMT
Subject: RFR: 8266456: Replace direct TKit.run() calls with
 jdk.jpackage.test.Annotations.Test annotation [v3]
In-Reply-To: <1pmsq6L7d7NEh3pOIvpLYADieU90dodd-KTpfiQeeck=.92a2c3e9-e252-453e-9da2-8ccea61f1294@github.com>
References: 
 <1pmsq6L7d7NEh3pOIvpLYADieU90dodd-KTpfiQeeck=.92a2c3e9-e252-453e-9da2-8ccea61f1294@github.com>
Message-ID: 

On Tue, 11 May 2021 03:40:19 GMT, Alexander Matveev  wrote:

>> - Replaced direct TKit.run() calls with Test annotation.
>>  - Increased timeout for SigningPackageTest from default to 360 due to timeout. This is regression from JDK-8248904 due to changes done in signing and --remove-signature adds additional time since it is run per file.
>>  - Fixed issue with jtreg.SkippedException which caused test to fail instead of being skipped, since it was wrapped in ExceptionBox.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266456: Replace direct TKit.run() calls with jdk.jpackage.test.Annotations.Test annotation [v3]

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3911

From dfuchs at openjdk.java.net  Tue May 11 15:26:02 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 11 May 2021 15:26:02 GMT
Subject: Integrated: 8266753: jdk/test/lib/process/ProcTest.java failed
 with "Exception: Proc abnormal end"
In-Reply-To: 
References: 
Message-ID: <3ug0LRrBdkLB_tgpJmR1ZdNnrmZBTLisILu3HcIdOSQ=.8a7f98a7-f6bc-4816-8bc3-79feaa033029@github.com>

On Tue, 11 May 2021 15:04:25 GMT, Weijun Wang  wrote:

> There is a tiny probability that the `Random` objects in the 2 child processes might be created at the same nano time and they will always produce the same output and the game will never end. This code change explicitly provides them with different seeds.

As long as the purpose of this test is not to test the entropy of java.util.Random that looks fine to me. Thanks for looking into this Max!

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3981

From weijun at openjdk.java.net  Tue May 11 15:26:01 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 11 May 2021 15:26:01 GMT
Subject: Integrated: 8266753: jdk/test/lib/process/ProcTest.java failed with
 "Exception: Proc abnormal end"
Message-ID: 

There is a tiny probability that the `Random` objects in the 2 child processes might be created at the same nano time and they will always produce the same output and the game will never end. This code change explicitly provides them with different seeds.

-------------

Commit messages:
 - 8266753: jdk/test/lib/process/ProcTest.java failed with "Exception: Proc abnormal end"

Changes: https://git.openjdk.java.net/jdk/pull/3981/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3981&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266753
  Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3981.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3981/head:pull/3981

PR: https://git.openjdk.java.net/jdk/pull/3981

From weijun at openjdk.java.net  Tue May 11 15:26:02 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 11 May 2021 15:26:02 GMT
Subject: Integrated: 8266753: jdk/test/lib/process/ProcTest.java failed with
 "Exception: Proc abnormal end"
In-Reply-To: 
References: 
Message-ID: 

On Tue, 11 May 2021 15:04:25 GMT, Weijun Wang  wrote:

> There is a tiny probability that the `Random` objects in the 2 child processes might be created at the same nano time and they will always produce the same output and the game will never end. This code change explicitly provides them with different seeds.

This pull request has now been integrated.

Changeset: 381de0c1
Author:    Weijun Wang 
URL:       https://git.openjdk.java.net/jdk/commit/381de0c1d024f7e0711fadf384d8625cf7ab8178
Stats:     6 lines in 1 file changed: 2 ins; 0 del; 4 mod

8266753: jdk/test/lib/process/ProcTest.java failed with "Exception: Proc abnormal end"

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.java.net/jdk/pull/3981

From cushon at openjdk.java.net  Tue May 11 15:54:48 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 11 May 2021 15:54:48 GMT
Subject: RFR: 8266857: PipedOutputStream.sink should be volatile [v2]
In-Reply-To: 
References: 
Message-ID: 

> 8266857: PipedOutputStream.sink should be volatile

Liam Miller-Cushon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8266857: PipedOutputStream.sink should be volatile

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3960/files
  - new: https://git.openjdk.java.net/jdk/pull/3960/files/4093362f..05795385

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3960&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3960&range=00-01

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3960.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3960/head:pull/3960

PR: https://git.openjdk.java.net/jdk/pull/3960

From cushon at openjdk.java.net  Tue May 11 15:54:51 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 11 May 2021 15:54:51 GMT
Subject: RFR: 8266857: PipedOutputStream.sink should be volatile
In-Reply-To: <-RLwMiJ-R4D_MNQCTA2HJlFp0Cvi2IFCIvmAeFUO1uw=.88eff355-86e8-4689-a971-91acba7aa0b9@github.com>
References: 
 <-RLwMiJ-R4D_MNQCTA2HJlFp0Cvi2IFCIvmAeFUO1uw=.88eff355-86e8-4689-a971-91acba7aa0b9@github.com>
Message-ID: <-eWPYz7-Q2bbIOyY99w1vl_-KW4k_MIKrazlOGtnhvo=.50d344a0-bd99-41ea-821a-825c57eab0bc@github.com>

On Tue, 11 May 2021 10:19:52 GMT, Daniel Fuchs  wrote:

> For correctness (and peace of mind)- we should probably introduce a local variable in all the places where `sink` is read more than once outside of a synchronized block

Done, thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3960

From dfuchs at openjdk.java.net  Tue May 11 15:54:49 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 11 May 2021 15:54:49 GMT
Subject: RFR: 8266857: PipedOutputStream.sink should be volatile [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 11 May 2021 15:47:37 GMT, Liam Miller-Cushon  wrote:

>> 8266857: PipedOutputStream.sink should be volatile
>
> Liam Miller-Cushon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8266857: PipedOutputStream.sink should be volatile

LGTM!

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3960

From cushon at openjdk.java.net  Tue May 11 15:54:52 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 11 May 2021 15:54:52 GMT
Subject: Integrated: 8266857: PipedOutputStream.sink should be volatile
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 May 2021 23:25:46 GMT, Liam Miller-Cushon  wrote:

> 8266857: PipedOutputStream.sink should be volatile

This pull request has now been integrated.

Changeset: d0daa725
Author:    Liam Miller-Cushon 
URL:       https://git.openjdk.java.net/jdk/commit/d0daa72592815fcdd9d550b9cc7dd70a06ae0968
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8266857: PipedOutputStream.sink should be volatile

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.java.net/jdk/pull/3960

From sergei.tsypanov at yandex.ru  Tue May 11 16:04:35 2021
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Tue, 11 May 2021 18:04:35 +0200
Subject: Unexpected behaviour when using Class.gerResource() with JDK ad hoc
 build
Message-ID: <1985981620739325@iva7-919bb0034794.qloud-c.yandex.net>

Hello

I've run into performance drop-down when using Class.gerResource().

When I run the following benchmark with JDK 16 downloaded from the internet

@State(Scope.Benchmark)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
public class ClassGetResourceBenchmark {
  private final Class clazz = getClass();

  @Benchmark
  public URL getResource() {
    return clazz.getResource("/com/tsypanov/sbb/ClassGetResourceBenchmark.class");
  }
}

getResource() method takes about 2 us and consumes 1704 bytes.

But then I take the code from https://github.com/openjdk/jdk and build it as

~ bash configure --with-boot-jdk=/home/s.tsypanov/.jdks/openjdk-16.0.1 --with-jtreg=/home/s.tsypanov/jtreg5
~ make images

the same benchmark run on this ad hoc build takes 129 us and consumes 111506 bytes.

The hot spot is the loop in jdk.internal.loader.URLClassPath.getResource():

private final ArrayList loaders;

public Resource getResource(String name, boolean check) {
  Loader loader;
  for (int i = 0; (loader = getLoader(i)) != null; i++) {
    Resource res = loader.getResource(name, check);
    if (res != null) {
      return res;
    }
  }
  return null;
}

in case of downloaded JDK `loaders` list contains 25 items and the one responsible for application's
classpath has index 0 (see screenshot https://disk.yandex.ru/i/yj16_tYs0xphSQ)

In case of JDK built locally the same list contains 90 items and the one responsible for application's
classpath has index 67 (see screenshot https://disk.yandex.ru/i/HXJOxpZrrdXPBA) while the first 66
items are responsible for modules of the JDK (see screenshot https://disk.yandex.ru/i/FkESrb_9Mo3nUw).

As a result the program iterates over the list until it comes to item 67 and at each iteration two URLs are
allocated in jdk.internal.loader.URLClassPath$FileLoader.getResource():

Resource getResource(final String name, boolean check) {
  final URL url;
  try {
    URL normalizedBase = new URL(getBaseURL(), ".");
    url = new URL(getBaseURL(), ParseUtil.encodePath(name, false));
    //...
  }
}

So the reason of the slow-down is different number and sequence of loaders in JDKs downloaded and built locally.
I've got two questions:

1) is there a way to build JDK locally with 'normal' list of loaders to have the same time for Class.getResource()?
2) would it be reasonable to cache 'normalizedBase' URL as a final field of FileLoader?

As getBaseURL() returns final field and is not overridden and the context is always "." we can initialize 'normalizedBase' in constructor.
In my case this allows to reduce consumed time from 129 to 104 us and allocation rate from 111506 to about 60000 bytes.

With best regards,
Sergey Tsypanov

From joehw at openjdk.java.net  Tue May 11 16:32:25 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 11 May 2021 16:32:25 GMT
Subject: RFR: 8255035: Update BCEL to Version 6.5.0 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Update BCEL to the latest version (6.5.0). The majority of the changes were code refactoring (name format changes).
> 
> XML tests passed on both Linux and Windows.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  update MD file

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3893/files
  - new: https://git.openjdk.java.net/jdk/pull/3893/files/033c3143..e6faa764

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3893&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3893&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3893.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3893/head:pull/3893

PR: https://git.openjdk.java.net/jdk/pull/3893

From Alan.Bateman at oracle.com  Tue May 11 16:35:35 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 11 May 2021 17:35:35 +0100
Subject: Unexpected behaviour when using Class.gerResource() with JDK ad
 hoc build
In-Reply-To: <1985981620739325@iva7-919bb0034794.qloud-c.yandex.net>
References: <1985981620739325@iva7-919bb0034794.qloud-c.yandex.net>
Message-ID: <2ed5ad99-bcda-b496-578a-7c09d9afacb5@oracle.com>

On 11/05/2021 17:04, ?????? ??????? wrote:
> Hello
>
> I've run into performance drop-down when using Class.gerResource().
>
> When I run the following benchmark with JDK 16 downloaded from the internet
>
> @State(Scope.Benchmark)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ClassGetResourceBenchmark {
>    private final Class clazz = getClass();
>
>    @Benchmark
>    public URL getResource() {
>      return clazz.getResource("/com/tsypanov/sbb/ClassGetResourceBenchmark.class");
>    }
> }
>
> getResource() method takes about 2 us and consumes 1704 bytes.
>
> But then I take the code from https://github.com/openjdk/jdk and build it as
>
> ~ bash configure --with-boot-jdk=/home/s.tsypanov/.jdks/openjdk-16.0.1 --with-jtreg=/home/s.tsypanov/jtreg5
> ~ make images
>
> the same benchmark run on this ad hoc build takes 129 us and consumes 111506 bytes.
>
>
Can you check if you are using an exploded build? In the output directly 
you need to configure the IDE to use images/jdk for an images-build. 
Also part of the issue may be an IDE bug where it puts the directories 
for all the system modules on the class path.

-Alan

From mchung at openjdk.java.net  Tue May 11 16:56:31 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 11 May 2021 16:56:31 GMT
Subject: RFR: 8266783: java\lang\reflect\Proxy\DefaultMethods.java fails with
 jtreg 6
Message-ID: 

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/pull/3984/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3984&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266783
  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3984.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3984/head:pull/3984

PR: https://git.openjdk.java.net/jdk/pull/3984

From mr at openjdk.java.net  Tue May 11 17:05:05 2021
From: mr at openjdk.java.net (Mark Reinhold)
Date: Tue, 11 May 2021 17:05:05 GMT
Subject: RFR: 8266783: java\lang\reflect\Proxy\DefaultMethods.java fails
 with jtreg 6
In-Reply-To: 
References: 
Message-ID: 

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.

All those backslashes hurt my eyes. Could we please use forward slashes, both in the commit message and the issue summary? This isn?t a regular expression.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3984

From iklam at openjdk.java.net  Tue May 11 17:12:23 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 11 May 2021 17:12:23 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
Message-ID: 

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 of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix GetModuleTest.java

The CDS VM and test changes look OK to me.

src/hotspot/share/oops/instanceMirrorKlass.inline.hpp line 65:

> 63:         // so when handling the java mirror for the class we need to make sure its class
> 64:         // loader data is claimed, this is done by calling do_cld explicitly.
> 65:         // For non-string hidden classes the call to do_cld is made when the class

Typo: non-strong

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3974

From mchung at openjdk.java.net  Tue May 11 17:15:54 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 11 May 2021 17:15:54 GMT
Subject: RFR: 8266783: java/lang/reflect/Proxy/DefaultMethods.java fails
 with jtreg 6
In-Reply-To: 
References: 
Message-ID: <1g_UvQfkZrdKp74CZpM5uw6RZkrSLdv3HLj-g-Q-Tag=.c8396162-16fa-4f3f-817d-d60a77ed074e@github.com>

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: https://git.openjdk.java.net/jdk/pull/3984

From lancea at openjdk.java.net  Tue May 11 17:17:55 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 11 May 2021 17:17:55 GMT
Subject: RFR: 8255035: Update BCEL to Version 6.5.0 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 11 May 2021 16:32:25 GMT, Joe Wang  wrote:

>> Update BCEL to the latest version (6.5.0). The majority of the changes were code refactoring (name format changes).
>> 
>> XML tests passed on both Linux and Windows.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update MD file

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3893

From iris at openjdk.java.net  Tue May 11 17:25:11 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 11 May 2021 17:25:11 GMT
Subject: RFR: 8266783: java/lang/reflect/Proxy/DefaultMethods.java fails
 with jtreg 6
In-Reply-To: 
References: 
Message-ID: 

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.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3984

From mchung at openjdk.java.net  Tue May 11 17:47:21 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 11 May 2021 17:47:21 GMT
Subject: RFR: 8266925: Add a test to verify that hidden class's members are
 not statically invocable
Message-ID: 

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/jdk/pull/3985/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3985&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266925
  Stats: 165 lines in 2 files changed: 165 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3985.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3985/head:pull/3985

PR: https://git.openjdk.java.net/jdk/pull/3985

From lance.andersen at oracle.com  Tue May 11 17:59:31 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 11 May 2021 17:59:31 +0000
Subject: Would anyone please reopen JDK-4991002?
In-Reply-To: <5a182c946c75707b7deb5c95175818a1@oss.nttdata.com>
References: <5a182c946c75707b7deb5c95175818a1@oss.nttdata.com>
Message-ID: 

Hi Mitsuru,

Thank you for your interest in contributing to the OpenJDK project

If you are not an Author, you can file bugs via https://bugreport.java.com/bugreport/

To contribute fixes,  you will need to sign an Oracle Committer Agreement(OCA).  Please see https://openjdk.java.net/contribute/ for more info

Please enter a new issue which you can use to address your SerialBlob/Clob fixes.  You will also need to  add the tests to verify the fix to the relevant tests in open/test/jdk/javax/sql/testng/test

 RowSets, in particular the Serialxxx classes, are seldom used (if at all) as there are better alternatives for an API.

Once you have signed your OCA and have generated your proposed patch, feel free to create your PR.

Best
Lance

On May 11, 2021, at 9:11 AM, Mitsuru Kariya > wrote:

Hi,

While reading the source for SerialBlob, I found that SerialBlob.position() does not work correctly.
So, I searched JBS and found the description in JDK-4991002 point 1, but it was closed by Cannot Reproduce.

It can be reproduced easily like below.

SerialBlob sb = new SerialBlob(new byte[]{1, 2, 3, 4, 5});
System.out.println(sb.position(new byte[]{1, 3, 5}, 1));

It should output "-1"(not found) but the current implementation outputs "3"(found at position 3).

So, would anyone please reopen JDK-4991002 for me?
(I cannot reopen it because I don't have an Author role.)

Furthermore, SerialClob has same problem and JDK-4991036 describes it.
So, may I fix it together?
Or do I need to separate the PR from JDK-4991002?

JDK-4991002:The class javax.sql.rowset.serial.SerialBlob is too buggy
https://bugs.openjdk.java.net/browse/JDK-4991002

JDK-4991036:The class javax.sql.rowset.serial.SerialClob is too buggy
https://bugs.openjdk.java.net/browse/JDK-4991036


Please let me know if there is a better place to do so.

Thanks

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com




From alanb at openjdk.java.net  Tue May 11 18:03:15 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 11 May 2021 18:03:15 GMT
Subject: RFR: 8266925: Add a test to verify that hidden class's members
 are not statically invocable
In-Reply-To: 
References: 
Message-ID: 

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.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3985

From jzaugg at openjdk.java.net  Tue May 11 18:10:01 2021
From: jzaugg at openjdk.java.net (Jason Zaugg)
Date: Tue, 11 May 2021 18:10:01 GMT
Subject: Integrated: 8265448: (zipfs): Reduce read contention in ZipFileSystem
In-Reply-To: 
References: 
Message-ID: 

On Tue, 4 May 2021 13:07:34 GMT, Jason Zaugg  wrote:

> If the given Path represents a file, use the overload of read defined
> in FileChannel that accepts an explicit position and avoid serializing
> reads.
> 
> Note: The underlying NIO implementation is not required to implement
> FileChannel.read(ByteBuffer, long) concurrently; Windows still appears
> to lock, as it returns true for NativeDispatcher.needsPositionLock.
> 
> 
> On MacOS X, the enclosed benchmark improves from:
> 
> 
> Benchmark                    Mode  Cnt   Score   Error  Units
> ZipFileSystemBenchmark.read  avgt   10  75.311 ? 3.301  ms/op
> 
> 
> To:
> 
> 
> Benchmark                    Mode  Cnt   Score   Error  Units
> ZipFileSystemBenchmark.read  avgt   10  12.520 ? 0.875  ms/op

This pull request has now been integrated.

Changeset: 0a12605d
Author:    Jason Zaugg 
Committer: Lance Andersen 
URL:       https://git.openjdk.java.net/jdk/commit/0a12605df893d782867529812b1d8c10380f603c
Stats:     108 lines in 3 files changed: 95 ins; 7 del; 6 mod

8265448: (zipfs): Reduce read contention in ZipFileSystem

Reviewed-by: alanb, lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/3853

From naoto at openjdk.java.net  Tue May 11 18:13:55 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 11 May 2021 18:13:55 GMT
Subject: RFR: 8266013: Unexpected replacement character handling on
 stateful CharsetEncoder [v2]
In-Reply-To: <8MYxd4bq0m2zaz9_M8ty4OcFqCkzDGTcXcRLFbzKdoU=.58825ee2-dd9f-4690-8bdc-8d5955bb7d51@github.com>
References: 
 <8MYxd4bq0m2zaz9_M8ty4OcFqCkzDGTcXcRLFbzKdoU=.58825ee2-dd9f-4690-8bdc-8d5955bb7d51@github.com>
Message-ID: 

On Fri, 30 Apr 2021 16:11:30 GMT, Ichiroh Takiguchi  wrote:

>> When an invalid character is converted by getBytes() method, the character is converted to replacement byte data.
>> Shift code (SO/SI) may not be added into right place by EBCDIC Mix charset.
>> EBCDIC Mix charset encoder is stateful encoder.
>> Shift code should be added by switching character set.
>> On x-IBM1364, "\u3000\uD800" should be converted to "\x0E\x40\x40\x0F\x6F", but "\x0E\x40\x40\x6F\x0F"
>> SI is not in right place.
>> 
>> Also ISO2022 related charsets use escape sequence to switch character set.
>> But same kind of issue is there.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266013: Unexpected replacement character handling on stateful CharsetEncoder

src/java.base/share/classes/java/nio/charset/Charset-X-Coder.java.template line 632:

> 630:             if (action == CodingErrorAction.REPLACE) {
> 631: #if[encoder]
> 632:                 if (maxBytesPerChar > 3.0) {

Does this check imply it is for stateful encoder? Since the fix is for incorrect SO/SI handling, should the fix be localized in those EBCDIC/ISO2022 encoders, not in the generic Charset-X-Coder?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3719

From bpb at openjdk.java.net  Tue May 11 19:07:54 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 11 May 2021 19:07:54 GMT
Subject: RFR: 8266578: Disambiguate BigDecimal description of scale
In-Reply-To: 
References: 
 
 <-poU2zYk5Di1PwXpSe2F8pkhKHD7rXuSVf43zDKDx0U=.e6ab5868-1f5a-462c-9e59-3f5754874980@github.com>
 
 <9gPFpTfPobzh9wUlx9Q4KAo5V7TXidqZUGqwGl-zml0=.0c80c124-dded-41e7-94d1-5073032b84fc@github.com>
 
Message-ID: 

On Thu, 6 May 2021 11:52:09 GMT, Ignasi Marimon-Clos  wrote:

>> @ignasi35 I have created JDK-8266578. Please change the name of this PR to:
>> 
>> `8266578: Disambiguate BigDecimal description of scale`
>> 
>> Please resolve any conflicts and commit the updated file. Once the update is available, I will file a CSR and mark this PR accordingly.
>
> Thanks @bplb for doing the heavy lifting. I've updated the PR title and solved the conflict.

@ignasi35 Friendly reminder that this PR cannot progress until you issue the [integrate](https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/integrate) command. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/582

From mchung at openjdk.java.net  Tue May 11 20:25:56 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 11 May 2021 20:25:56 GMT
Subject: Integrated: 8266783: java/lang/reflect/Proxy/DefaultMethods.java
 fails with jtreg 6
In-Reply-To: 
References: 
Message-ID: 

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 Chung 
URL:       https://git.openjdk.java.net/jdk/commit/dfe8833f5d9a9ac59857143a86d07f85769b8eae
Stats:     7 lines in 1 file changed: 0 ins; 0 del; 7 mod

8266783: java/lang/reflect/Proxy/DefaultMethods.java fails with jtreg 6

Reviewed-by: iris

-------------

PR: https://git.openjdk.java.net/jdk/pull/3984

From mandy.chung at oracle.com  Tue May 11 20:39:48 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 11 May 2021 13:39:48 -0700
Subject: Review CSR JDK-8266760: Remove
 sun.misc.Unsafe::defineAnonymousClass
In-Reply-To: 
References: <07d57bb9-1787-b86a-0009-d7690745986c@oracle.com>
 
 <86151eab-7beb-1e56-a389-1860cbd8e554@oracle.com>
 
Message-ID: 

Hi Attila,

Thanks for the input.? I added the Nashorn use case in JDK-8212620.

Mandy

On 5/11/21 3:41 AM, Attila Szegedi wrote:
> I'm fine with the removal, although if you remember we use it in 
> Nashorn too[0], and when I tried to replace it with the hidden classes 
> facility the issue we run into was that hidden classes' methods didn't 
> show up in stack traces the way anonymous classes' methods did[1]. 
> Since Nashorn uses anonymous classes to install compiled JavaScript 
> application code, it is important to be able to report stack traces 
> from them. It unfortunately can't just use StackWalker, as it has to 
> post-edit traces of already thrown exceptions.
>
> So ensuring JDK-8212620 is implemented as well, and/or maybe having 
> a?MethodHandles.Lookup.ClassOption to specify the class should show up 
> in stack traces would be important to implement alongside the removal. 
> It's not a show-stopper, Nashorn will be able to gracefully fail over 
> to ordinary class loading in absence of anonymous class loading, but 
> I'd really like to be able to transition to using hidden classes if we 
> could get them to show up in stack traces.
>
> Attila.
>
> [0] 
> https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/Context.java#L329 
> 
> [1] 
> https://mail.openjdk.java.net/pipermail/nashorn-dev/2020-October/007578.html 
> 
>
> On Tue, May 11, 2021 at 1:03 AM Mandy Chung  > wrote:
>
>     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. `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.net/browse/JDK-8266760
>     
>     >>
>     >> Comments?
>     >>
>     >> Mandy
>


From mandy.chung at oracle.com  Tue May 11 20:42:01 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 11 May 2021 13:42:01 -0700
Subject: Draft JEP: Reimplement Core Reflection on Method Handles
Message-ID: 

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

From sergei.tsypanov at yandex.ru  Tue May 11 20:44:49 2021
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Tue, 11 May 2021 22:44:49 +0200
Subject: Unexpected behaviour when using Class.gerResource() with JDK ad
 hoc build
In-Reply-To: <2ed5ad99-bcda-b496-578a-7c09d9afacb5@oracle.com>
References: <1985981620739325@iva7-919bb0034794.qloud-c.yandex.net>
 <2ed5ad99-bcda-b496-578a-7c09d9afacb5@oracle.com>
Message-ID: <17592581620765889@myt5-bc0f9d8e5f27.qloud-c.yandex.net>

> 
> Can you check if you are using an exploded build? In the output directly
> you need to configure the IDE to use images/jdk for an images-build.
> Also part of the issue may be an IDE bug where it puts the directories
> for all the system modules on the class path.
> 
> -Alan

Hi, looks like I've used the one from /build/linux-x86_64-server-release/jdk.

After switching to /build/linux-x86_64-server-release/images/jdk numbers are fine again, thanks!

Sergey

From mchung at openjdk.java.net  Tue May 11 20:52:59 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 11 May 2021 20:52:59 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
Message-ID: <6jFp2B7imcUETfAlhzQUDtp45nwnPauD7rcSfqG4CI8=.39e2a9ab-42ec-4633-9bfc-82a327ed2564@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 of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix GetModuleTest.java

src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MetaUtil.java line 53:

> 51:             return simpleName;
> 52:         }
> 53:         // Must be a local class

This file should not be changed.  It refers to the Java language anonymous class (not VM anonymous class).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3974

From brian.goetz at oracle.com  Tue May 11 21:01:57 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 11 May 2021 17:01:57 -0400
Subject: Draft JEP: Reimplement Core Reflection on Method Handles
In-Reply-To: 
References: 
Message-ID: <0dcdae1f-5d76-3c8e-eaf8-ce3b73cf7de4@oracle.com>

Yes, please!

To add to the list of motivations/things to remove: the current 
implementation relies on the special `MagicAccessorImpl` to relax 
accessibility.? The notes in this class are frightening; getting rid of 
it would be a mercy.



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/mlchung/jdk/tree/reimplement-method-invoke


From almatvee at openjdk.java.net  Tue May 11 22:04:25 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Tue, 11 May 2021 22:04:25 GMT
Subject: Integrated: 8266456: Replace direct TKit.run() calls with
 jdk.jpackage.test.Annotations.Test annotation
In-Reply-To: 
References: 
Message-ID: <6k0opLyI4GsCaCmlbZ0rxizap3_frTef_83iEJsbXPA=.2a8f3045-d1a5-496e-8fdf-4766464976f6@github.com>

On Fri, 7 May 2021 02:48:44 GMT, Alexander Matveev  wrote:

> - Replaced direct TKit.run() calls with Test annotation.
>  - Increased timeout for SigningPackageTest from default to 360 due to timeout. This is regression from JDK-8248904 due to changes done in signing and --remove-signature adds additional time since it is run per file.
>  - Fixed issue with jtreg.SkippedException which caused test to fail instead of being skipped, since it was wrapped in ExceptionBox.

This pull request has now been integrated.

Changeset: 1356116d
Author:    Alexander Matveev 
URL:       https://git.openjdk.java.net/jdk/commit/1356116d3fb0cf9bee6796862e8015adc36590fb
Stats:     228 lines in 13 files changed: 19 ins; 30 del; 179 mod

8266456: Replace direct TKit.run() calls with jdk.jpackage.test.Annotations.Test annotation

Reviewed-by: asemenyuk, herrick

-------------

PR: https://git.openjdk.java.net/jdk/pull/3911

From forax at univ-mlv.fr  Tue May 11 22:14:27 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 12 May 2021 00:14:27 +0200 (CEST)
Subject: Draft JEP: Reimplement Core Reflection on Method Handles
In-Reply-To: 
References: 
Message-ID: <1529811052.1759622.1620771267201.JavaMail.zimbra@u-pem.fr>

Hi Mandy,
impressive work !

I think that the method that are a caller-sensitive adapter (the one that takes a supplementary class as last parameter) should be annotated with a specific JDK internal annotation,
so the link between the caller sensitive method and it's adapter is obvious for the humans that read the code.

Otherwise, i've only taken a look to the parts of the code that are using ASM.

This line is weird, it uses 52 which is Java 8
https://github.com/mlchung/jdk/commit/320efd2e5697627243f6fe058485fb8708a0cd41#diff-4e4fca8bb2eb6320ff485ee724248e1641b4bb3f6dbae8526e87c5cf15905d9aR1262

Perhaps all versions should be updated to 61 (Java 17), unit the internal version of ASM is refreshed so the constant V17 can be used.

R?mi

----- Mail original -----
> De: "mandy chung" 
> ?: "core-libs-dev" , "hotspot compiler" 
> Envoy?: Mardi 11 Mai 2021 22:42:01
> Objet: Draft JEP: Reimplement Core Reflection on Method Handles

> 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

From mandy.chung at oracle.com  Tue May 11 22:36:37 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 11 May 2021 15:36:37 -0700
Subject: Draft JEP: Reimplement Core Reflection on Method Handles
In-Reply-To: <0dcdae1f-5d76-3c8e-eaf8-ce3b73cf7de4@oracle.com>
References: 
 <0dcdae1f-5d76-3c8e-eaf8-ce3b73cf7de4@oracle.com>
Message-ID: <5a8859f2-5bcd-e5ec-cf82-bd530c9b7b52@oracle.com>



On 5/11/21 2:01 PM, Brian Goetz wrote:
> Yes, please!
>
> To add to the list of motivations/things to remove: the current 
> implementation relies on the special `MagicAccessorImpl` to relax 
> accessibility.? The notes in this class are frightening; getting rid 
> of it would be a mercy.
>
>

Thanks, 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/mlchung/jdk/tree/reimplement-method-invoke
>


From mandy.chung at oracle.com  Tue May 11 22:39:56 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 11 May 2021 15:39:56 -0700
Subject: Draft JEP: Reimplement Core Reflection on Method Handles
In-Reply-To: <1529811052.1759622.1620771267201.JavaMail.zimbra@u-pem.fr>
References: 
 <1529811052.1759622.1620771267201.JavaMail.zimbra@u-pem.fr>
Message-ID: <92148095-eef0-d6a5-a3d5-dfc9c0548c8e@oracle.com>



On 5/11/21 3:14 PM, Remi Forax wrote:
> Hi Mandy,
> impressive work !
>
> I think that the method that are a caller-sensitive adapter (the one that takes a supplementary class as last parameter) should be annotated with a specific JDK internal annotation,
> so the link between the caller sensitive method and it's adapter is obvious for the humans that read the code.

This is exactly what I am considering.? May get to it soon.

> Otherwise, i've only taken a look to the parts of the code that are using ASM.
>
> This line is weird, it uses 52 which is Java 8
> https://urldefense.com/v3/__https://github.com/mlchung/jdk/commit/320efd2e5697627243f6fe058485fb8708a0cd41*diff-4e4fca8bb2eb6320ff485ee724248e1641b4bb3f6dbae8526e87c5cf15905d9aR1262__;Iw!!GqivPVa7Brio!LiAwZ1SmPNk8ETBmjRBbMoL7c2XB4M4N29I5lhAULQTtwDxEd6B1ERlcn8PyovcSaQ$
>
> Perhaps all versions should be updated to 61 (Java 17), 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: Reimplement Core Reflection on Method Handles
>> 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://urldefense.com/v3/__https://github.com/mlchung/jdk/tree/reimplement-method-invoke__;!!GqivPVa7Brio!LiAwZ1SmPNk8ETBmjRBbMoL7c2XB4M4N29I5lhAULQTtwDxEd6B1ERlcn8MsCgr-dg$


From naoto at openjdk.java.net  Tue May 11 22:44:58 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 11 May 2021 22:44:58 GMT
Subject: Integrated: 8266784: java/text/Collator/RuleBasedCollatorTest.java
 fails with jtreg 6
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 May 2021 23:12:04 GMT, Naoto Sato  wrote:

> Please review this test case fix for the upcoming jtreg 6. The test was using `@BeforeGroups` annotation, and the behavior of it has changed in TestNG 7.1 so that it is only issued when the test was configured with filtering. Changed to use `@BeforeClass` instead.

This pull request has now been integrated.

Changeset: f6c5a6bb
Author:    Naoto Sato 
URL:       https://git.openjdk.java.net/jdk/commit/f6c5a6bbf14603c0f4832e5793c48ae1308a7414
Stats:     8 lines in 1 file changed: 0 ins; 0 del; 8 mod

8266784: java/text/Collator/RuleBasedCollatorTest.java fails with jtreg 6

Reviewed-by: joehw

-------------

PR: https://git.openjdk.java.net/jdk/pull/3959

From joehw at openjdk.java.net  Tue May 11 23:56:59 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 11 May 2021 23:56:59 GMT
Subject: Integrated: 8255035: Update BCEL to Version 6.5.0
In-Reply-To: 
References: 
Message-ID: 

On Thu, 6 May 2021 00:17:40 GMT, Joe Wang  wrote:

> Update BCEL to the latest version (6.5.0). The majority of the changes were code refactoring (name format changes).
> 
> XML tests passed on both Linux and Windows.

This pull request has now been integrated.

Changeset: 1a0ff28e
Author:    Joe Wang 
URL:       https://git.openjdk.java.net/jdk/commit/1a0ff28ea10aaba53c5fbeb59800d3bcb1d228bc
Stats:     2149 lines in 95 files changed: 98 ins; 33 del; 2018 mod

8255035: Update BCEL to Version 6.5.0

Reviewed-by: lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/3893

From joehw at openjdk.java.net  Wed May 12 00:42:57 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 12 May 2021 00:42:57 GMT
Subject: RFR: 8265248: Implementation Specific Properties: change prefix,
 plus add existing properties [v4]
In-Reply-To: 
References: 
Message-ID: 

> Update module summary, add a few existing properties and features into the tables.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  Add legacy property names table

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3644/files
  - new: https://git.openjdk.java.net/jdk/pull/3644/files/78047dcc..466dc3b7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3644&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3644&range=02-03

  Stats: 69 lines in 1 file changed: 68 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3644.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3644/head:pull/3644

PR: https://git.openjdk.java.net/jdk/pull/3644

From stuart.marks at oracle.com  Wed May 12 00:55:25 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 11 May 2021 17:55:25 -0700
Subject: [External] : Re: ReversibleCollection proposal
In-Reply-To: <1360d5bf-cd41-17e2-fb99-0aceb9243795@gmail.com>
References: <38af-60883900-4c5-3a732100@161619996>
 
 <056b8d18-3ccf-3dac-d64f-07bd2c586752@gmail.com>
 <0f89b6f8-31e4-bb25-56f2-0a8bbcb6f2ac@oracle.com>
 <1360d5bf-cd41-17e2-fb99-0aceb9243795@gmail.com>
Message-ID: <22074d0d-56a8-172e-fe85-2358a424fe4f@oracle.com>



On 5/1/21 7:36 AM, Peter Levart wrote:
> On 4/30/21 9:25 PM, Stuart Marks wrote:
>> So I think we're stuck with void-returning add{First,Last} methods. 
> 
> Have you thought of perhaps not adding them at all?
> 
> Collection.add() for:
> 
> List(s) - behaves the same as addLast()
> 
> LinkedHashSet - behaves the same as addLast()
> 
> Deque - behaves the same as addLast()
> 
> So for all ReversibleCollection(s) where it works, addLast() would be equivalent to 
> add()
> 
> addFirst(x) can be written as: reversed().add(x) if reversed() is specified to 
> return a reversed view over the underlying ReversibleCollection.

To me, and I think to most people, add, get, and remove all belong together, just 
like offer/peek/poll. (See the tables in the Deque class spec.) Of course the issue 
is that addX can't be implemented for SortedSet (or it can be, but only with some 
contrivances discussed previously). The choice is between which asymmetry we want:

1. add/get/remove across most of the ReversibleCollection implementations except for 
SortedSet, or

2. get/remove across all ReversibleCollection implementations, with addX() "missing" 
from the set of operations.

As you point out, add() is kind of like addLast(), except without the reordering 
semantics for LinkedHashSet. And reversed().add() is a roundabout way of saying 
addFirst() -- also without the reordering semantics for LinkedHashSet. I think most 
people's reactions would be "Why didn't they just provide addFirst/addLast?" Plus 
the reordering would be missing for LHS.

A second-order issue is performance. I'd expect that implementations would want to 
provide a fast-path for addFirst() that is amenable to JIT optimization; this seems 
harder to achieve with reversed().add().

s'marks

From mchung at openjdk.java.net  Wed May 12 00:56:08 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 12 May 2021 00:56:08 GMT
Subject: Integrated: 8266925: Add a test to verify that hidden class's members
 are not statically invocable
In-Reply-To: 
References: 
Message-ID: 

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:    Mandy Chung 
URL:       https://git.openjdk.java.net/jdk/commit/cc03734b996c41c93efadf22e73685164bfe6b46
Stats:     165 lines in 2 files changed: 165 ins; 0 del; 0 mod

8266925: Add a test to verify that hidden class's members are not statically invocable

Reviewed-by: alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/3985

From stuart.marks at oracle.com  Wed May 12 01:03:33 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 11 May 2021 18:03:33 -0700
Subject: [External] : Re: Collection::getAny discussion
In-Reply-To: <493527554.337130.1620642694051.JavaMail.zimbra@u-pem.fr>
References: <38af-60883900-4c5-3a732100@161619996>
 
 
 <838b3ee1-20ac-2baa-f477-03e92f4697c3@oracle.com>
 
 <493527554.337130.1620642694051.JavaMail.zimbra@u-pem.fr>
Message-ID: 



On 5/10/21 3:31 AM, Remi Forax wrote:
> Thinking a little more about conflating "first" and "any".
> I wonder if we have not already cross the Rubicon on that matter,
> 
> If we have a HashSet or any collections and using Stream.findFirst()
>    var collection = new HashSet<>(...);
>    var result = collection.stream().findFirst().orElseThrow();
> 
> We will get the result of collection.iterator().next()
> 
> So adding a default method getFirst() on Collection that returns the result of iterator().next() is pretty coherent, no ?

Not really. Streams have a runtime notion of being ORDERED, and no static type. 
Adding Collection.getFirst() has no similar runtime notion. This proposal is to add 
a static type for ordering/reversibility and corresponding operations for it.

I'd still like to hear about the use cases for getAny or whatever we want to call 
the thing. Are callers interested in the collection having zero-or-one, exactly one, 
zero or more, or one or more elements? Talking about iterator().next() without 
considering the use cases, and their implications for pattern matching, is 
short-sighted.

s'marks

From mchung at openjdk.java.net  Wed May 12 02:50:58 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 12 May 2021 02:50:58 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
Message-ID: 

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 of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix GetModuleTest.java

I reviewed java.base and took a pass on the test changes.  Here are some comments:
 
test/hotspot/jtreg/runtime/HiddenClasses/TestHiddenClassUnloading.java has this comment:


+// This is based on test compiler/classUnloading/anonymousClass/TestAnonymousClassUnloading.java


This comment can be removed as this test will be removed.   A few tests under  test/hotspot/jtreg/runtime/HiddenClasses also have similar comment that should be removed.

test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/func/castToGrandparent/Test.java
test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/func/classNameInStackTrace/Test.java
- I think these tests are already well covered by test/hotspot/jtreg/runtime/HiddenClasses/CastToParentTest.java
and test/hotspot/jtreg/runtime/HiddenClasses/HiddenClassStack.java 
- I suggest to copy the description from the anonloader tests to these hidden class tests

test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/share/StressClassLoadingTest.java
   - test/hotspot/jtreg/runtime/HiddenClasses/StressClassLoadingTest.java is a subset of this test.  Should we remove test/hotspot/jtreg/runtime/HiddenClasses/StressClassLoadingTest.java?
   
test/jdk/java/lang/invoke/VMAnonymousClass.java
- FYI.  I have added a new test to verify hidden class (see JDK-8266925)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3974

From stuart.marks at oracle.com  Wed May 12 05:27:51 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 11 May 2021 22:27:51 -0700
Subject: [External] : Re: ReversibleCollection proposal
In-Reply-To: <2063372755.1742538.1620211264481.JavaMail.zimbra@u-pem.fr>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 
 <839698479.422241.1619098212148.JavaMail.zimbra@u-pem.fr>
 <7457433b-0836-f45e-4b51-4c2ecdf7e7da@oracle.com>
 <427897615.2057286.1619612437790.JavaMail.zimbra@u-pem.fr>
 
 <906317823.1426529.1619873859193.JavaMail.zimbra@u-pem.fr>
 
 <2063372755.1742538.1620211264481.JavaMail.zimbra@u-pem.fr>
Message-ID: 

>> I'm certain that uses of RC/RS will be rare in the beginning, because they will
>> be
>> new, and people won't be familar with them. And then there will the people who
>> say
>> "I can't use them because I'm stuck on JDK 11 / 8 / 7 / 6 ...." It was the same
>> thing with lambdas and streams in Java 8, with List.of() etc in Java 9, records
>> in
>> Java 16, etc. This wasn't an argument not to add them, and it isn't an argument
>> not
>> to add RC/RS.
> 
> All the changes you are listing here are "client side" changes, the ones that can be adopted quickly because they do not require to change the API side of any libraries.
> ReversibleCollection is an API side change, like generics is, those changes have a far higher cost because you have to wait your library dependencies to be updated.
> On the Valhalla list, we have discussed several times about how to alleviate those API side change cost using automatic bridging or methods forwarding, even for Valhalla, we are currently moving in a state where those mechanisms are not needed.

This isn't an argument against RC/RS. Application code can find uses for the new 
APIs, e.g. getFirst and addLast on List, or more ordering flexibility on 
LinkedHashSet, on day one. Applications' internal APIs can also benefit on day one. 
Certainly libraries will have to wait for their clients to catch up to later JDKs. 
This has *always* been the case, even for library internals (such as use of lambdas 
or APIs introduced in newer JDKs) because libraries need to be compiled for the 
lowest version of the JDK their clients support. For example, you can't use 
List.of() in a library -- even internally -- if your clients are still on JDK 8. 
There are no new issues here.

> The abstraction already exists but it's not defined in term of interface because it's an implementation decision and those are cleanly separated in the current Collection design.
> 
> Let take a step back, the collection API defines basic data structure operations in term of interfaces like List, Deque, Set, etc those interfaces are decoupled from implementation capabilities like mutable, nullable, ordered and checked.
> 
> Depending on the implementation capabilities, the interfaces method implementation may throw an exception, non-mutable implementations use UnsupportedOperationException, non-nullable implementations use NPE and checked implementations use CCE.
> 
> So what is missing is methods on Collection interfaces that require the collection implementation to be ordered like descendingList(), getFirst(), etc.
> Those methods that may throw a specific exception if the implementation is not ordered, not UnsupportedOperationException but a new one like NotOrderedException.
> 
> So to answer to your question about LinkedHashSet, the reverse-ordered LinkedHashSet is a Set with a method descendingSet() that do not throw NotOrderedException like any Set with an order.
> 
> To summarize, if we introduce ReversibleCollection, we should also introduce ImmutableCollection, NonNullableCollection and CheckedCollection.
> I think it's better to consider the fact that being ordered as a capability (hint: this is already what the Spliterator API does) and not as a specific interface.

This discussion, and your ensuing proposal to add a bunch of throwing default 
methods to Collection, is based on a flawed premise. That premise is that there is a 
fundamental distinction between "data structure operations" which must be embodied 
as types, and "implementation capabilities" which must manifest at runtime either by 
allowing the operation or by throwing an exception.

But this distinction isn't fundamental. In what way is being ordered not a "basic 
data structure" issue? In what way is indexed access (as for List) not an 
"implementation capability"? Really, these are two different aspects of the same 
thing. Over time, new "data structure operations" and new "implementation 
capabilities" have been added to the collections framework. Some of them were 
embodied as types, and some were not. Which ones were embodied as types was the 
result of design decisions that considered a bunch of tradeoffs.

What you're attempting to do is to declare absolutes. This drives you to one of two 
extremes, which is either 1) to never add new types and to always add 
possibly-throwing operations to existing types (which seems to be what you're 
describing as an alternative); or 2) to claim that everything needs to be manifested 
as a new type (giving rise to your straw-man argument that we should also have 
ImmutableCollection, NonNullableCollection, CheckedCollection, etc.). The argument 
seems to be that we wouldn't want to add all those other types, so we mustn't add 
ReversibleCollection either. No.

In summary, I reject the premise that adding ReversibleCollection implies that a 
bunch of other types also need to be added, so I don't accept this line of reasoning 
as an argument against ReversibleCollection.

s'marks

From peter.levart at gmail.com  Wed May 12 06:28:07 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 12 May 2021 08:28:07 +0200
Subject: [External] : Re: ReversibleCollection proposal
In-Reply-To: <22074d0d-56a8-172e-fe85-2358a424fe4f@oracle.com>
References: <38af-60883900-4c5-3a732100@161619996>
 
 <056b8d18-3ccf-3dac-d64f-07bd2c586752@gmail.com>
 <0f89b6f8-31e4-bb25-56f2-0a8bbcb6f2ac@oracle.com>
 <1360d5bf-cd41-17e2-fb99-0aceb9243795@gmail.com>
 <22074d0d-56a8-172e-fe85-2358a424fe4f@oracle.com>
Message-ID: <034a4c7b-feba-04f7-7d74-2c8afcb84930@gmail.com>


On 5/12/21 2:55 AM, Stuart Marks wrote:
> As you point out, add() is kind of like addLast(), except without the 
> reordering semantics for LinkedHashSet. And reversed().add() is a 
> roundabout way of saying addFirst() -- also without the reordering 
> semantics for LinkedHashSet. I think most people's reactions would be 
> "Why didn't they just provide addFirst/addLast?" Plus the reordering 
> would be missing for LHS.
>
> A second-order issue is performance. I'd expect that implementations 
> would want to provide a fast-path for addFirst() that is amenable to 
> JIT optimization; this seems harder to achieve with reversed().add(). 


The allocation of a reversed view instance typically goes away when C2 
compiles the method (if the instance isn't cached like in 
AbstractMap.keySet/values) so this can be as performant as specialized 
addFirst(), but lack of reordering of existent element in LinkedHashSet 
is a different problem I haven thought about.


Regards, Peter



From iklam at openjdk.java.net  Wed May 12 06:52:45 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 12 May 2021 06:52:45 GMT
Subject: RFR: 8265605: Cannot call BootLoader::loadClassOrNull before
 initPhase2
Message-ID: <5Z-hLKzLSdUeUjO5w8WS9PuGfd7se3IAjo18YaUIWEg=.cccb3896-f58f-4f39-838b-f8e4201fc7ea@github.com>

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 of the archived module graph in the wrong order. Because of unanticipated nesting of `` methods, `BootLoader::SERVICES_CATALOG` becomes empty, causing future `ServiceLoader` operations to fail.

The fix has 2 parts:

- `BootLoader::loadClassOrNull` no longer calls `ClassLoaders::bootLoader()`. This avoids triggering the archived module graph initialization. Instead, it makes a direct call to `Classloader::findBootstrapClassOrNull()`. We don't actually need a `ClassLoader` instance for this call, so I changed `Classloader::findBootstrapClassOrNull()` to be a static method.
- The object returned by `BootLoader::getServicesCatalog()` is now maintained inside `jdk.internal.loader.ClassLoaders`.  Although not strictly required for the fix, this simplifies the initialization of the archived module graph. It also makes the logic consistent for the 3 built-in loaders (boot/platform/app).

Testing: tiers1-4 in progress. I also verified that the bug reported by Mandy is no longer reproducible after I applied this patch on her branch.

-------------

Commit messages:
 - 8265605: Cannot call BootLoader::loadClassOrNull before initPhase2

Changes: https://git.openjdk.java.net/jdk/pull/3992/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3992&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265605
  Stats: 42 lines in 8 files changed: 8 ins; 13 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3992.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3992/head:pull/3992

PR: https://git.openjdk.java.net/jdk/pull/3992

From david.holmes at oracle.com  Wed May 12 07:56:17 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 12 May 2021 17:56:17 +1000
Subject: RFR: 8266310: deadlock while loading the JNI code
In-Reply-To: 
References: 
Message-ID: <9cca1e8d-d9d9-4bb8-080e-195239023e79@oracle.com>

Hi Aleksei,

On 11/05/2021 11:19 pm, 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 library load operation.
> 
> Problem being fixed:
> 
> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread.
> 
> Proposed fix:
> 
> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method.

The ClassLoader per-name locking map has a number of problems so I'm not 
sure using it as a model is a good idea. In particular your new map only 
grows, with entries never being removed AFAICS.

This is a difficult deadlock to solve. Even using a per-entry lock it 
isn't obvious to me that you can't still get a deadlock.

My own thoughts on this problem were that we should not be calling 
JNI_OnLoad with any lock held. But that risks use of a library in a 
separate thread before the JNI+OnLoad has completed. As I said this is a 
difficult deadlock to solve - and may not have a complete solution.

David
-----

> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared.
> 
> Testing:  jtreg and jck testing with no regressions. A new regression test was developed.
> 
> -------------
> 
> Commit messages:
>   - JDK-8266310: deadlock while loading the JNI code
>   - JDK-8266310: deadlock while loading the JNI code
> 
> Changes: https://git.openjdk.java.net/jdk/pull/3976/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3976&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8266310
>    Stats: 475 lines in 6 files changed: 456 ins; 0 del; 19 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/3976.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/3976/head:pull/3976
> 
> PR: https://git.openjdk.java.net/jdk/pull/3976
> 

From github.com+10835776+stsypanov at openjdk.java.net  Wed May 12 07:56:09 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 12 May 2021 07:56:09 GMT
Subject: RFR: 8266622: Optimize Class.descriptorString() and
 Class.getCanonicalName0()
In-Reply-To: 
References: 
Message-ID: 

On Thu, 6 May 2021 15:20:23 GMT, ?????? ???????  wrote:

> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 and https://github.com/openjdk/jdk/pull/2212 it appears, that in `j.l.Class` expressions like
> 
> String str = baseName.replace('.', '/') + '/' + name;
> 
> are not compiled into invokedynamic-based code, but into one using `StringBuilder`.
> 
> This happens due to some bootstraping issues. Currently the bytecode for the last (most often used) branch of `Class.descriptorString()` looks like
> 
> public sb()Ljava/lang/String;
>    L0
>     LINENUMBER 21 L0
>     NEW java/lang/StringBuilder
>     DUP
>     INVOKESPECIAL java/lang/StringBuilder. ()V
>     ASTORE 1
>    L1
>     LINENUMBER 23 L1
>     ALOAD 1
>     LDC "a"
>     INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
>     POP
>    L2
>     LINENUMBER 24 L2
>     ALOAD 1
>     LDC "b"
>     INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
>     POP
>    L3
>     LINENUMBER 26 L3
>     ALOAD 1
>     INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String;
>     ARETURN
> 
> Here the `StringBuilder` is created with default constructor and then expands if necessary while appending. 
> 
> This can be improved by manually allocating `StringBuilder` of exact size. The benchmark demonstrates measurable improvement:
> 
> @State(Scope.Benchmark)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ClassDescriptorStringBenchmark {
> 
>     private final Class clazzWithShortDescriptor = Object.class;
>     private final Class clazzWithLongDescriptor = getClass();
> 
>     @Benchmark
>     public String descriptorString_short() {
>         return clazzWithShortDescriptor.descriptorString();
>     }
> 
>     @Benchmark
>     public String descriptorString_long() {
>         return clazzWithLongDescriptor.descriptorString();
>     }
> }
> 
> 
> 
> original
> -Xint
>                                                Mode     Score     Error   Units
> descriptorString_long                          avgt  6326.478 ? 107.251   ns/op
> descriptorString_short                         avgt  5220.729 ? 103.545   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt   528.089 ?   0.021    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt   232.036 ?   0.015    B/op
> 
> -XX:TieredStopAtLevel=1
>                                                Mode      Score    Error   Units
> descriptorString_long                          avgt    230.223 ?  1.254   ns/op
> descriptorString_short                         avgt    164.255 ?  0.755   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt    528.046 ?  0.002    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt    232.022 ?  0.001    B/op
> 
> full
>                                                Mode      Score     Error   Units
> descriptorString_long                          avgt     74.835 ?   0.262   ns/op
> descriptorString_short                         avgt     43.822 ?   0.788   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt    504.010 ?   0.001    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt    208.004 ?   0.001    B/op
> 
> ------------------------
> patched
> -Xint
>                                                Mode      Score     Error   Units
> descriptorString_long                          avgt   4485.994 ?  60.173   ns/op
> descriptorString_short                         avgt   3949.965 ? 278.143   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt    336.051 ?   0.004    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt    184.027 ?   0.010    B/op
> 
> -XX:TieredStopAtLevel=1
>                                                Mode        Score    Error   Units
> descriptorString_long                          avgt      185.774 ?  1.100   ns/op
> descriptorString_short                         avgt      135.338 ?  1.066   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt      336.030 ?  0.001    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt      184.019 ?  0.001    B/op
> 
> full
>                                                Mode      Score     Error   Units
> descriptorString_long                          avgt     42.864 ?   0.160   ns/op
> descriptorString_short                         avgt     27.255 ?   0.381   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt    224.005 ?   0.001    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt    120.002 ?   0.001    B/op
> 
> Same can be done also for Class.isHidden() branch in Class.descriptorString() and for Class.getCanonicalName0()

Together with https://github.com/openjdk/jdk/pull/3627 this allows to reduce [minimalistic Spring Boot application start-up](https://github.com/stsypanov/spring-boot-benchmark/blob/master/src/main/java/com/tsypanov/sbb/SpringBootApplicationBenchmark.java) time from 653 to 645 milliseconds and memory consumprion from 43804 to 43668 kB.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3903

From redestad at openjdk.java.net  Wed May 12 10:30:57 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 12 May 2021 10:30:57 GMT
Subject: RFR: 8266622: Optimize Class.descriptorString() and
 Class.getCanonicalName0()
In-Reply-To: 
References: 
Message-ID: 

On Thu, 6 May 2021 15:20:23 GMT, ?????? ???????  wrote:

> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 and https://github.com/openjdk/jdk/pull/2212 it appears, that in `j.l.Class` expressions like
> 
> String str = baseName.replace('.', '/') + '/' + name;
> 
> are not compiled into invokedynamic-based code, but into one using `StringBuilder`.
> 
> This happens due to some bootstraping issues. Currently the bytecode for the last (most often used) branch of `Class.descriptorString()` looks like
> 
> public sb()Ljava/lang/String;
>    L0
>     LINENUMBER 21 L0
>     NEW java/lang/StringBuilder
>     DUP
>     INVOKESPECIAL java/lang/StringBuilder. ()V
>     ASTORE 1
>    L1
>     LINENUMBER 23 L1
>     ALOAD 1
>     LDC "a"
>     INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
>     POP
>    L2
>     LINENUMBER 24 L2
>     ALOAD 1
>     LDC "b"
>     INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
>     POP
>    L3
>     LINENUMBER 26 L3
>     ALOAD 1
>     INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String;
>     ARETURN
> 
> Here the `StringBuilder` is created with default constructor and then expands if necessary while appending. 
> 
> This can be improved by manually allocating `StringBuilder` of exact size. The benchmark demonstrates measurable improvement:
> 
> @State(Scope.Benchmark)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ClassDescriptorStringBenchmark {
> 
>     private final Class clazzWithShortDescriptor = Object.class;
>     private final Class clazzWithLongDescriptor = getClass();
> 
>     @Benchmark
>     public String descriptorString_short() {
>         return clazzWithShortDescriptor.descriptorString();
>     }
> 
>     @Benchmark
>     public String descriptorString_long() {
>         return clazzWithLongDescriptor.descriptorString();
>     }
> }
> 
> 
> 
> original
> -Xint
>                                                Mode     Score     Error   Units
> descriptorString_long                          avgt  6326.478 ? 107.251   ns/op
> descriptorString_short                         avgt  5220.729 ? 103.545   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt   528.089 ?   0.021    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt   232.036 ?   0.015    B/op
> 
> -XX:TieredStopAtLevel=1
>                                                Mode      Score    Error   Units
> descriptorString_long                          avgt    230.223 ?  1.254   ns/op
> descriptorString_short                         avgt    164.255 ?  0.755   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt    528.046 ?  0.002    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt    232.022 ?  0.001    B/op
> 
> full
>                                                Mode      Score     Error   Units
> descriptorString_long                          avgt     74.835 ?   0.262   ns/op
> descriptorString_short                         avgt     43.822 ?   0.788   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt    504.010 ?   0.001    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt    208.004 ?   0.001    B/op
> 
> ------------------------
> patched
> -Xint
>                                                Mode      Score     Error   Units
> descriptorString_long                          avgt   4485.994 ?  60.173   ns/op
> descriptorString_short                         avgt   3949.965 ? 278.143   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt    336.051 ?   0.004    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt    184.027 ?   0.010    B/op
> 
> -XX:TieredStopAtLevel=1
>                                                Mode        Score    Error   Units
> descriptorString_long                          avgt      185.774 ?  1.100   ns/op
> descriptorString_short                         avgt      135.338 ?  1.066   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt      336.030 ?  0.001    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt      184.019 ?  0.001    B/op
> 
> full
>                                                Mode      Score     Error   Units
> descriptorString_long                          avgt     42.864 ?   0.160   ns/op
> descriptorString_short                         avgt     27.255 ?   0.381   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt    224.005 ?   0.001    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt    120.002 ?   0.001    B/op
> 
> Same can be done also for Class.isHidden() branch in Class.descriptorString() and for Class.getCanonicalName0()

I'm a bit apprehensive about desugaring like this, but if as you claim it's linked to a decent Spring Boot startup gain then I think we should accept it.

src/java.base/share/classes/java/lang/Class.java line 4377:

> 4375:                     .append(name.substring(0, index).replace('.', '/'))
> 4376:                     .append('.')
> 4377:                     .append(name.substring(index + 1))

`.append(name, index + 1, name.length())` might be a small win here, but it might be hard to benchmark this branch since it's only for hidden classes.

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3903

From redestad at openjdk.java.net  Wed May 12 10:42:06 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 12 May 2021 10:42:06 GMT
Subject: RFR: 8266622: Optimize Class.descriptorString() and
 Class.getCanonicalName0()
In-Reply-To: 
References: 
Message-ID: 

On Thu, 6 May 2021 15:20:23 GMT, ?????? ???????  wrote:

> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 and https://github.com/openjdk/jdk/pull/2212 it appears, that in `j.l.Class` expressions like
> 
> String str = baseName.replace('.', '/') + '/' + name;
> 
> are not compiled into invokedynamic-based code, but into one using `StringBuilder`.
> 
> This happens due to some bootstraping issues. Currently the bytecode for the last (most often used) branch of `Class.descriptorString()` looks like
> 
> public sb()Ljava/lang/String;
>    L0
>     LINENUMBER 21 L0
>     NEW java/lang/StringBuilder
>     DUP
>     INVOKESPECIAL java/lang/StringBuilder. ()V
>     ASTORE 1
>    L1
>     LINENUMBER 23 L1
>     ALOAD 1
>     LDC "a"
>     INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
>     POP
>    L2
>     LINENUMBER 24 L2
>     ALOAD 1
>     LDC "b"
>     INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
>     POP
>    L3
>     LINENUMBER 26 L3
>     ALOAD 1
>     INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String;
>     ARETURN
> 
> Here the `StringBuilder` is created with default constructor and then expands if necessary while appending. 
> 
> This can be improved by manually allocating `StringBuilder` of exact size. The benchmark demonstrates measurable improvement:
> 
> @State(Scope.Benchmark)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ClassDescriptorStringBenchmark {
> 
>     private final Class clazzWithShortDescriptor = Object.class;
>     private final Class clazzWithLongDescriptor = getClass();
> 
>     @Benchmark
>     public String descriptorString_short() {
>         return clazzWithShortDescriptor.descriptorString();
>     }
> 
>     @Benchmark
>     public String descriptorString_long() {
>         return clazzWithLongDescriptor.descriptorString();
>     }
> }
> 
> 
> 
> original
> -Xint
>                                                Mode     Score     Error   Units
> descriptorString_long                          avgt  6326.478 ? 107.251   ns/op
> descriptorString_short                         avgt  5220.729 ? 103.545   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt   528.089 ?   0.021    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt   232.036 ?   0.015    B/op
> 
> -XX:TieredStopAtLevel=1
>                                                Mode      Score    Error   Units
> descriptorString_long                          avgt    230.223 ?  1.254   ns/op
> descriptorString_short                         avgt    164.255 ?  0.755   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt    528.046 ?  0.002    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt    232.022 ?  0.001    B/op
> 
> full
>                                                Mode      Score     Error   Units
> descriptorString_long                          avgt     74.835 ?   0.262   ns/op
> descriptorString_short                         avgt     43.822 ?   0.788   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt    504.010 ?   0.001    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt    208.004 ?   0.001    B/op
> 
> ------------------------
> patched
> -Xint
>                                                Mode      Score     Error   Units
> descriptorString_long                          avgt   4485.994 ?  60.173   ns/op
> descriptorString_short                         avgt   3949.965 ? 278.143   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt    336.051 ?   0.004    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt    184.027 ?   0.010    B/op
> 
> -XX:TieredStopAtLevel=1
>                                                Mode        Score    Error   Units
> descriptorString_long                          avgt      185.774 ?  1.100   ns/op
> descriptorString_short                         avgt      135.338 ?  1.066   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt      336.030 ?  0.001    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt      184.019 ?  0.001    B/op
> 
> full
>                                                Mode      Score     Error   Units
> descriptorString_long                          avgt     42.864 ?   0.160   ns/op
> descriptorString_short                         avgt     27.255 ?   0.381   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt    224.005 ?   0.001    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt    120.002 ?   0.001    B/op
> 
> Same can be done also for Class.isHidden() branch in Class.descriptorString() and for Class.getCanonicalName0()

> Together with #3627 this allows to reduce [minimalistic Spring Boot application start-up](https://github.com/stsypanov/spring-boot-benchmark/blob/master/src/main/java/com/tsypanov/sbb/SpringBootApplicationBenchmark.java) time from 653 to 645 milliseconds and memory consumprion from 43804 to 43668 kB.

How do you run this benchmark? Something like `-bm ss -f 20`? Otherwise repeatedly invoking the spring boot initialization in a JMH benchmark method doesn't seem to model startup very realistically - unless that capture some iterative development scenario. Since JMH itself loads quite a bit of things on startup it likely skews your results somewhat - our startup tests are typically more barebone scripts that repeatedly run the app and capture the time to "start" and time to run the JVM to completion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3903

From lancea at openjdk.java.net  Wed May 12 10:53:15 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 12 May 2021 10:53:15 GMT
Subject: RFR: 8265248: Implementation Specific Properties: change prefix,
 plus add existing properties [v4]
In-Reply-To: 
References: 
 
Message-ID: <3hhiLPqmqB81j4TuGKIHA3Im1jsKtscN9Y_iw4mTuk8=.b6907925-ce02-4ab2-ae72-565e63cf1961@github.com>

On Wed, 12 May 2021 00:42:57 GMT, Joe Wang  wrote:

>> Update module summary, add a few existing properties and features into the tables.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add legacy property names table

Looks fine Joe.  Thank you for the additional updates for clarity

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3644

From jorn.vernee at oracle.com  Wed May 12 10:58:31 2021
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Wed, 12 May 2021 12:58:31 +0200
Subject: RFC: Add a --validate option to the jar tool
Message-ID: <49af48ea-64b2-67fb-2457-838be780d925@oracle.com>

Hi,

I see that the jar tool has validation logic for multi-release jars that 
is triggered when creating or updating a jar that has a versioned file 
as an input. I wanted to ask what people think about the idea of 
exposing this validation logic directly under a --validate command line 
flag as well.

Malformed multi-release jars can cause compilation and runtime problems 
because the API exposed by the jar is different across different Java 
versions. Exposing the validation logic directly would allow for easy 
validation of jar files that are suspected of being malformed 
multi-release jars.

The validation logic is already cleanly separated into a separate 
Validator class in the source code, and adding a command line flag that 
exposes it directly is a relatively minimal change [1]. It seems like 
maybe the intent in the past was also to expose this validation logic 
directly?

What's the history here? Any opinions about exposing this validation 
logic through a command line option?

Thanks,
Jorn

[1] : https://github.com/openjdk/jdk/pull/3971


From github.com+10835776+stsypanov at openjdk.java.net  Wed May 12 11:01:03 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 12 May 2021 11:01:03 GMT
Subject: RFR: 8266622: Optimize Class.descriptorString() and
 Class.getCanonicalName0()
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 12 May 2021 10:38:11 GMT, Claes Redestad  wrote:

> Something like -bm ss -f 20

Yes, I use SingleShotTime as the mode and 400 forks

-------------

PR: https://git.openjdk.java.net/jdk/pull/3903

From forax at univ-mlv.fr  Wed May 12 11:22:43 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 12 May 2021 13:22:43 +0200 (CEST)
Subject: [External] : Re: ReversibleCollection proposal
In-Reply-To: 
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <7457433b-0836-f45e-4b51-4c2ecdf7e7da@oracle.com>
 <427897615.2057286.1619612437790.JavaMail.zimbra@u-pem.fr>
 
 <906317823.1426529.1619873859193.JavaMail.zimbra@u-pem.fr>
 
 <2063372755.1742538.1620211264481.JavaMail.zimbra@u-pem.fr>
 
Message-ID: <197055291.2061771.1620818563131.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Stuart Marks" 
> ?: "Remi Forax" 
> Cc: "core-libs-dev" 
> Envoy?: Mercredi 12 Mai 2021 07:27:51
> Objet: Re: [External] : Re: ReversibleCollection proposal

>>> I'm certain that uses of RC/RS will be rare in the beginning, because they will
>>> be
>>> new, and people won't be familar with them. And then there will the people who
>>> say
>>> "I can't use them because I'm stuck on JDK 11 / 8 / 7 / 6 ...." It was the same
>>> thing with lambdas and streams in Java 8, with List.of() etc in Java 9, records
>>> in
>>> Java 16, etc. This wasn't an argument not to add them, and it isn't an argument
>>> not
>>> to add RC/RS.
>> 
>> All the changes you are listing here are "client side" changes, the ones that
>> can be adopted quickly because they do not require to change the API side of
>> any libraries.
>> ReversibleCollection is an API side change, like generics is, those changes have
>> a far higher cost because you have to wait your library dependencies to be
>> updated.
>> On the Valhalla list, we have discussed several times about how to alleviate
>> those API side change cost using automatic bridging or methods forwarding, even
>> for Valhalla, we are currently moving in a state where those mechanisms are not
>> needed.
> 
> This isn't an argument against RC/RS. Application code can find uses for the new
> APIs, e.g. getFirst and addLast on List, or more ordering flexibility on
> LinkedHashSet, on day one. Applications' internal APIs can also benefit on day
> one.
> Certainly libraries will have to wait for their clients to catch up to later
> JDKs.
> This has *always* been the case, even for library internals (such as use of
> lambdas
> or APIs introduced in newer JDKs) because libraries need to be compiled for the
> lowest version of the JDK their clients support. For example, you can't use
> List.of() in a library -- even internally -- if your clients are still on JDK 8.
> There are no new issues here.

First, i think we have overlooked ReversibleMap, if you have a LinkedHashMap, the keySet should be a ReversibleSet.

It is because with RC/RS/RM, you have to wait far longer, being able to use the JDK version is not enough to be able to introduce a public method that takes a ReversibleCollection, you also need to be sure that all clients of your library are using collections that have been upgraded to implement ReversibleCollection. In practice, enough client might be Ok, but that's a huge difference. Instead, if we follow the path of using default methods on Collection and not new interfaces, you only need to wait until you decide to upgrade the library to the JDK version, because with default methods all existing collections are "automatically" upgraded.

> 
>> The abstraction already exists but it's not defined in term of interface because
>> it's an implementation decision and those are cleanly separated in the current
>> Collection design.
>> 
>> Let take a step back, the collection API defines basic data structure operations
>> in term of interfaces like List, Deque, Set, etc those interfaces are decoupled
>> from implementation capabilities like mutable, nullable, ordered and checked.
>> 
>> Depending on the implementation capabilities, the interfaces method
>> implementation may throw an exception, non-mutable implementations use
>> UnsupportedOperationException, non-nullable implementations use NPE and checked
>> implementations use CCE.
>> 
>> So what is missing is methods on Collection interfaces that require the
>> collection implementation to be ordered like descendingList(), getFirst(), etc.
>> Those methods that may throw a specific exception if the implementation is not
>> ordered, not UnsupportedOperationException but a new one like
>> NotOrderedException.
>> 
>> So to answer to your question about LinkedHashSet, the reverse-ordered
>> LinkedHashSet is a Set with a method descendingSet() that do not throw
>> NotOrderedException like any Set with an order.
>> 
>> To summarize, if we introduce ReversibleCollection, we should also introduce
>> ImmutableCollection, NonNullableCollection and CheckedCollection.
>> I think it's better to consider the fact that being ordered as a capability
>> (hint: this is already what the Spliterator API does) and not as a specific
>> interface.
> 
> This discussion, and your ensuing proposal to add a bunch of throwing default
> methods to Collection, is based on a flawed premise. That premise is that there
> is a fundamental distinction between "data structure operations" which must be embodied
> as types, and "implementation capabilities" which must manifest at runtime either by
> allowing the operation or by throwing an exception.

The collection framework doesn't respect one of the principle of OOP which is that you should not have a method on a type if you are not able to implement it.
This design decision was done for good, it drastically reduces the number of interfaces, thus simplify the mental image people have when using the API.
But it means that Collection.add or Iterator.remove can throw an UnsupportedOperationException, this is how the collection framework was designed.

> 
> But this distinction isn't fundamental. In what way is being ordered not a
> "basic data structure" issue? In what way is indexed access (as for List) not an
> "implementation capability"? Really, these are two different aspects of the same
> thing. Over time, new "data structure operations" and new "implementation
> capabilities" have been added to the collections framework. Some of them were
> embodied as types, and some were not. Which ones were embodied as types was the
> result of design decisions that considered a bunch of tradeoffs.

This is the first time we have actually the choice between adding new interfaces as it was done in the past (for NavigableSet/NavigableMap by example) or adding default methods on existing interfaces.
Before, we did not have that choice because default methods did not exist. We are post Java 8, and we want to add more capabilities to the collection API, so having this discussion about new interfaces vs new default methods is sane in my opinion. 

> 
> What you're attempting to do is to declare absolutes. 

It's something Brian says to me a lot, i believe part is the way i think part is the fact that i'm not a native English speaker, so my dictionary of words is reduced.

> This drives you to one of two extremes, which is either 1) to never add new types and to always add
> possibly-throwing operations to existing types (which seems to be what you're
> describing as an alternative); or 2) to claim that everything needs to be
> manifested as a new type (giving rise to your straw-man argument that we should also have
> ImmutableCollection, NonNullableCollection, CheckedCollection, etc.). The
> argument seems to be that we wouldn't want to add all those other types, so we mustn't
> add ReversibleCollection either. No.
> 
> In summary, I reject the premise that adding ReversibleCollection implies that a
> bunch of other types also need to be added, so I don't accept this line of
> reasoning as an argument against ReversibleCollection.

Where to draw the line is one argument against ReversibleCollection, what's make ReversibleCollection, ReversibleSet and ReversibleMap so special that they deserve to be new interfaces and not new default methods.

Again, we have seen that introducing those interfaces
- is not source backward compatible thus it will be painful for some of our users,
  I believe NavigableSet/NavigableMap did not have that issue because only one existing implementation per interface was retrofitted to implement those interfaces, TreeSet for NavigableSet and TreeMap for NavigableMap.
  ConcurrentSkipListSet/ConcurrentSkipListMap were added at the same time, so there was no existing code doing a lub (lowest upper bound) between TreeSet and ConcurrentSkipListSet.
  Here, they are a lot of implementations that will implement be retrofitted to ReversibleCollection, ReversibleSet and ReversibleMap.
- people will have to wait a theoretically infinite time before being to introduce a public method that takes a ReversibleCollection, ReversibleSet and ReversibleMap to their library, because it requires
  all existing implementations of collection with an order to be retrofitted to implement those interfaces.
- adding any new interfaces has a real cognitive cost, the collection API is supposed to be simple, does being reversible really worth such new weight.

We now have the opportunity to introduce default methods instead of new interfaces which do not have those drawbacks.
Obviously, using default methods instead of new interfaces have drawbacks too, mostly, you can use a static type to say this is a collection with an order.


> 
> s'marks

R?mi

From jvernee at openjdk.java.net  Wed May 12 11:28:12 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 12 May 2021 11:28:12 GMT
Subject: RFR: 8263087: Add a MethodHandle combinator that switches over a
 set of MethodHandles
In-Reply-To: 
References: 
Message-ID: 

On Thu, 8 Apr 2021 18:51:21 GMT, Jorn Vernee  wrote:

> This patch adds a `tableSwitch` combinator that can be used to switch over a set of method handles given an index, with a fallback in case the index is out of bounds, much like the `tableswitch` bytecode. Here is a description of how it works (copied from the javadoc):
> 
>      Creates a table switch method handle, which can be used to switch over a set of target
>      method handles, based on a given target index, called selector.
> 
>      For a selector value of {@code n}, where {@code n} falls in the range {@code [0, N)},
>      and where {@code N} is the number of target method handles, the table switch method
>      handle will invoke the n-th target method handle from the list of target method handles.
> 
>      For a selector value that does not fall in the range {@code [0, N)}, the table switch
>      method handle will invoke the given fallback method handle.
> 
>      All method handles passed to this method must have the same type, with the additional
>      requirement that the leading parameter be of type {@code int}. The leading parameter
>      represents the selector.
> 
>      Any trailing parameters present in the type will appear on the returned table switch
>      method handle as well. Any arguments assigned to these parameters will be forwarded,
>      together with the selector value, to the selected method handle when invoking it.
> 
> The combinator does not support specifying the starting index, so the switch cases always run from 0 to however many target handles are specified. A starting index can be added manually with another combination step that filters the input index by adding or subtracting a constant from it, which does not affect performance. One of the reasons for not supporting a starting index is that it allows for more lambda form sharing, but also simplifies the implementation somewhat. I guess an open question is if a convenience overload should be added for that case?
> 
> Lookup switch can also be simulated by filtering the input through an injection function that translates it into a case index, which has also proven to have the ability to have comparable performance to, or even better performance than, a bytecode-native `lookupswitch` instruction. I plan to add such an injection function to the runtime libraries in the future as well. Maybe at that point it could be evaluated if it's worth it to add a lookup switch combinator as well, but I don't see an immediate need to include it in this patch.
> 
> The current bytecode intrinsification generates a call for each switch case, which guarantees full inlining of the target method handles. Alternatively we could only have 1 callsite at the end of the switch, where each case just loads the target method handle, but currently this does not allow for inlining of the handles, since they are not constant.
> 
> Maybe a future C2 optimization could look at the receiver input for invokeBasic call sites, and if the input is a phi node, clone the call for each constant input of the phi. I believe that would allow simplifying the bytecode without giving up on inlining.
> 
> Some numbers from the added benchmarks:
> 
> Benchmark                                        (numCases)  (offset)  (sorted)  Mode  Cnt   Score   Error  Units
> MethodHandlesTableSwitchConstant.testSwitch               5         0       N/A  avgt   30   4.186 ? 0.054  ms/op
> MethodHandlesTableSwitchConstant.testSwitch               5       150       N/A  avgt   30   4.164 ? 0.057  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              10         0       N/A  avgt   30   4.124 ? 0.023  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              10       150       N/A  avgt   30   4.126 ? 0.025  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              25         0       N/A  avgt   30   4.137 ? 0.042  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              25       150       N/A  avgt   30   4.113 ? 0.016  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              50         0       N/A  avgt   30   4.118 ? 0.028  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              50       150       N/A  avgt   30   4.127 ? 0.019  ms/op
> MethodHandlesTableSwitchConstant.testSwitch             100         0       N/A  avgt   30   4.116 ? 0.013  ms/op
> MethodHandlesTableSwitchConstant.testSwitch             100       150       N/A  avgt   30   4.121 ? 0.020  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5         0       N/A  avgt   30   4.113 ? 0.009  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5       150       N/A  avgt   30   4.149 ? 0.041  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10         0       N/A  avgt   30   4.121 ? 0.026  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10       150       N/A  avgt   30   4.113 ? 0.021  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25         0       N/A  avgt   30   4.129 ? 0.028  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25       150       N/A  avgt   30   4.105 ? 0.019  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50         0       N/A  avgt   30   4.097 ? 0.021  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50       150       N/A  avgt   30   4.131 ? 0.037  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100         0       N/A  avgt   30   4.135 ? 0.025  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100       150       N/A  avgt   30   4.139 ? 0.145  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5         0      true  avgt   30   4.894 ? 0.028  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5         0     false  avgt   30  11.526 ? 0.194  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5       150      true  avgt   30   4.882 ? 0.025  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5       150     false  avgt   30  11.532 ? 0.034  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10         0      true  avgt   30   5.065 ? 0.076  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10         0     false  avgt   30  13.016 ? 0.020  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10       150      true  avgt   30   5.103 ? 0.051  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10       150     false  avgt   30  12.984 ? 0.102  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25         0      true  avgt   30   8.441 ? 0.165  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25         0     false  avgt   30  13.371 ? 0.060  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25       150      true  avgt   30   8.628 ? 0.032  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25       150     false  avgt   30  13.542 ? 0.020  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50         0      true  avgt   30   4.701 ? 0.015  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50         0     false  avgt   30  13.562 ? 0.063  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50       150      true  avgt   30   7.991 ? 3.111  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50       150     false  avgt   30  13.543 ? 0.088  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100         0      true  avgt   30   4.712 ? 0.020  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100         0     false  avgt   30  13.600 ? 0.085  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100       150      true  avgt   30   4.676 ? 0.011  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100       150     false  avgt   30  13.476 ? 0.043  ms/op
> 
> 
> Testing:
> - [x] Running of included benchmarks
> - [x] Inspecting inlining trace and verifying method handle targets are inlined
> - [x] Running TestTableSwitch test (currently the only user of the new code)
> - [x] Running java/lang/invoke tests (just in case)
> - [x] Some manual testing
> 
> Thanks,
> Jorn

I've just gotten back after 3 weeks of being sick, and would like to try moving this PR forward again.

Are there any remaining concerns with adding a tableSwitch combinator?

Reading back some of the discussion, I think the remaining point of contention is about adding a lookupSwitch combinator as well, which I think is a good idea (as a followup) in order to expose the lookupswitch bytecode as a combinator as well, but which doesn't seem like a blocker for this patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3401

From forax at univ-mlv.fr  Wed May 12 11:59:55 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 12 May 2021 13:59:55 +0200 (CEST)
Subject: [External] : Re: ReversibleCollection proposal
In-Reply-To: <034a4c7b-feba-04f7-7d74-2c8afcb84930@gmail.com>
References: <38af-60883900-4c5-3a732100@161619996>
 
 <056b8d18-3ccf-3dac-d64f-07bd2c586752@gmail.com>
 <0f89b6f8-31e4-bb25-56f2-0a8bbcb6f2ac@oracle.com>
 <1360d5bf-cd41-17e2-fb99-0aceb9243795@gmail.com>
 <22074d0d-56a8-172e-fe85-2358a424fe4f@oracle.com>
 <034a4c7b-feba-04f7-7d74-2c8afcb84930@gmail.com>
Message-ID: <1807111196.2080413.1620820795840.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Peter Levart" 
> ?: "Stuart Marks" 
> Cc: "core-libs-dev" 
> Envoy?: Mercredi 12 Mai 2021 08:28:07
> Objet: Re: [External] : Re: ReversibleCollection proposal

> On 5/12/21 2:55 AM, Stuart Marks wrote:
>> As you point out, add() is kind of like addLast(), except without the
>> reordering semantics for LinkedHashSet. And reversed().add() is a
>> roundabout way of saying addFirst() -- also without the reordering
>> semantics for LinkedHashSet. I think most people's reactions would be
>> "Why didn't they just provide addFirst/addLast?" Plus the reordering
>> would be missing for LHS.
>>
>> A second-order issue is performance. I'd expect that implementations
>> would want to provide a fast-path for addFirst() that is amenable to
>> JIT optimization; this seems harder to achieve with reversed().add().
> 
> 
> The allocation of a reversed view instance typically goes away when C2
> compiles the method (if the instance isn't cached like in
> AbstractMap.keySet/values) so this can be as performant as specialized
> addFirst(), but lack of reordering of existent element in LinkedHashSet
> is a different problem I haven thought about.

Don't forget that the default method implementation is just that a default method,
at least the JDK implementations like LinkedHashSet can/should provide a better implementation.

> 
> 
> Regards, Peter

regards,
R?mi

From forax at univ-mlv.fr  Wed May 12 12:27:37 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 12 May 2021 14:27:37 +0200 (CEST)
Subject: [External] : Re: Collection::getAny discussion
In-Reply-To: 
References: <38af-60883900-4c5-3a732100@161619996>
 
 
 <838b3ee1-20ac-2baa-f477-03e92f4697c3@oracle.com>
 
 <493527554.337130.1620642694051.JavaMail.zimbra@u-pem.fr>
 
Message-ID: <761918558.2103510.1620822457723.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Stuart Marks" 
> ?: "Remi Forax" 
> Cc: "core-libs-dev" 
> Envoy?: Mercredi 12 Mai 2021 03:03:33
> Objet: Re: [External] : Re: Collection::getAny discussion

> On 5/10/21 3:31 AM, Remi Forax wrote:
>> Thinking a little more about conflating "first" and "any".
>> I wonder if we have not already cross the Rubicon on that matter,
>> 
>> If we have a HashSet or any collections and using Stream.findFirst()
>>    var collection = new HashSet<>(...);
>>    var result = collection.stream().findFirst().orElseThrow();
>> 
>> We will get the result of collection.iterator().next()
>> 
>> So adding a default method getFirst() on Collection that returns the result of
>> iterator().next() is pretty coherent, no ?
> 
> Not really. Streams have a runtime notion of being ORDERED, and no static type.
> Adding Collection.getFirst() has no similar runtime notion.

The characteristics of a Spliterator/Stream reflects the properties of the collection from which the Spliterator was derived.

Anyway, the spec of Stream.findFirst() is not described in term of being ORDERED or not, it just says returns the first element of a Stream and a Stream can be created on any collections, ordered or not.
So having a method getFirst() on Collection returning the first element of the collection makes sense to me, the same way getting the first element of a Stream makes sense,
even if it implies getting a random element in case of a Set.

> This proposal is to add a static type for ordering/reversibility and corresponding operations for it.

Given that it's a proposal, i think it's fair to discuss other options if most of the intent of your proposal or the one from Tagir is kept.  

> 
> I'd still like to hear about the use cases for getAny or whatever we want to
> call
> the thing. Are callers interested in the collection having zero-or-one, exactly
> one,
> zero or more, or one or more elements? Talking about iterator().next() without
> considering the use cases, and their implications for pattern matching, is
> short-sighted.

Pattern matching (AFAIK) can not be used outside of a switch/instanceof, if as a user i'm required to wrap getFirst() inside a switch in order to get the first element, i will find that API cumbersome.

> 
> s'marks

R?mi

From github.com+828220+forax at openjdk.java.net  Wed May 12 12:33:05 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 12 May 2021 12:33:05 GMT
Subject: RFR: 8263087: Add a MethodHandle combinator that switches over a
 set of MethodHandles
In-Reply-To: 
References: 
Message-ID: 

On Thu, 8 Apr 2021 18:51:21 GMT, Jorn Vernee  wrote:

> This patch adds a `tableSwitch` combinator that can be used to switch over a set of method handles given an index, with a fallback in case the index is out of bounds, much like the `tableswitch` bytecode. Here is a description of how it works (copied from the javadoc):
> 
>      Creates a table switch method handle, which can be used to switch over a set of target
>      method handles, based on a given target index, called selector.
> 
>      For a selector value of {@code n}, where {@code n} falls in the range {@code [0, N)},
>      and where {@code N} is the number of target method handles, the table switch method
>      handle will invoke the n-th target method handle from the list of target method handles.
> 
>      For a selector value that does not fall in the range {@code [0, N)}, the table switch
>      method handle will invoke the given fallback method handle.
> 
>      All method handles passed to this method must have the same type, with the additional
>      requirement that the leading parameter be of type {@code int}. The leading parameter
>      represents the selector.
> 
>      Any trailing parameters present in the type will appear on the returned table switch
>      method handle as well. Any arguments assigned to these parameters will be forwarded,
>      together with the selector value, to the selected method handle when invoking it.
> 
> The combinator does not support specifying the starting index, so the switch cases always run from 0 to however many target handles are specified. A starting index can be added manually with another combination step that filters the input index by adding or subtracting a constant from it, which does not affect performance. One of the reasons for not supporting a starting index is that it allows for more lambda form sharing, but also simplifies the implementation somewhat. I guess an open question is if a convenience overload should be added for that case?
> 
> Lookup switch can also be simulated by filtering the input through an injection function that translates it into a case index, which has also proven to have the ability to have comparable performance to, or even better performance than, a bytecode-native `lookupswitch` instruction. I plan to add such an injection function to the runtime libraries in the future as well. Maybe at that point it could be evaluated if it's worth it to add a lookup switch combinator as well, but I don't see an immediate need to include it in this patch.
> 
> The current bytecode intrinsification generates a call for each switch case, which guarantees full inlining of the target method handles. Alternatively we could only have 1 callsite at the end of the switch, where each case just loads the target method handle, but currently this does not allow for inlining of the handles, since they are not constant.
> 
> Maybe a future C2 optimization could look at the receiver input for invokeBasic call sites, and if the input is a phi node, clone the call for each constant input of the phi. I believe that would allow simplifying the bytecode without giving up on inlining.
> 
> Some numbers from the added benchmarks:
> 
> Benchmark                                        (numCases)  (offset)  (sorted)  Mode  Cnt   Score   Error  Units
> MethodHandlesTableSwitchConstant.testSwitch               5         0       N/A  avgt   30   4.186 ? 0.054  ms/op
> MethodHandlesTableSwitchConstant.testSwitch               5       150       N/A  avgt   30   4.164 ? 0.057  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              10         0       N/A  avgt   30   4.124 ? 0.023  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              10       150       N/A  avgt   30   4.126 ? 0.025  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              25         0       N/A  avgt   30   4.137 ? 0.042  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              25       150       N/A  avgt   30   4.113 ? 0.016  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              50         0       N/A  avgt   30   4.118 ? 0.028  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              50       150       N/A  avgt   30   4.127 ? 0.019  ms/op
> MethodHandlesTableSwitchConstant.testSwitch             100         0       N/A  avgt   30   4.116 ? 0.013  ms/op
> MethodHandlesTableSwitchConstant.testSwitch             100       150       N/A  avgt   30   4.121 ? 0.020  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5         0       N/A  avgt   30   4.113 ? 0.009  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5       150       N/A  avgt   30   4.149 ? 0.041  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10         0       N/A  avgt   30   4.121 ? 0.026  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10       150       N/A  avgt   30   4.113 ? 0.021  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25         0       N/A  avgt   30   4.129 ? 0.028  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25       150       N/A  avgt   30   4.105 ? 0.019  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50         0       N/A  avgt   30   4.097 ? 0.021  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50       150       N/A  avgt   30   4.131 ? 0.037  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100         0       N/A  avgt   30   4.135 ? 0.025  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100       150       N/A  avgt   30   4.139 ? 0.145  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5         0      true  avgt   30   4.894 ? 0.028  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5         0     false  avgt   30  11.526 ? 0.194  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5       150      true  avgt   30   4.882 ? 0.025  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5       150     false  avgt   30  11.532 ? 0.034  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10         0      true  avgt   30   5.065 ? 0.076  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10         0     false  avgt   30  13.016 ? 0.020  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10       150      true  avgt   30   5.103 ? 0.051  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10       150     false  avgt   30  12.984 ? 0.102  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25         0      true  avgt   30   8.441 ? 0.165  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25         0     false  avgt   30  13.371 ? 0.060  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25       150      true  avgt   30   8.628 ? 0.032  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25       150     false  avgt   30  13.542 ? 0.020  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50         0      true  avgt   30   4.701 ? 0.015  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50         0     false  avgt   30  13.562 ? 0.063  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50       150      true  avgt   30   7.991 ? 3.111  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50       150     false  avgt   30  13.543 ? 0.088  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100         0      true  avgt   30   4.712 ? 0.020  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100         0     false  avgt   30  13.600 ? 0.085  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100       150      true  avgt   30   4.676 ? 0.011  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100       150     false  avgt   30  13.476 ? 0.043  ms/op
> 
> 
> Testing:
> - [x] Running of included benchmarks
> - [x] Inspecting inlining trace and verifying method handle targets are inlined
> - [x] Running TestTableSwitch test (currently the only user of the new code)
> - [x] Running java/lang/invoke tests (just in case)
> - [x] Some manual testing
> 
> Thanks,
> Jorn

I hope you are well now.
You are right, adding a lookupswitch can be done later, i'm fine with the current state of this patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3401

From Alan.Bateman at oracle.com  Wed May 12 12:41:10 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 12 May 2021 13:41:10 +0100
Subject: RFC: Add a --validate option to the jar tool
In-Reply-To: <49af48ea-64b2-67fb-2457-838be780d925@oracle.com>
References: <49af48ea-64b2-67fb-2457-838be780d925@oracle.com>
Message-ID: 

On 12/05/2021 11:58, Jorn Vernee wrote:
> Hi,
>
> I see that the jar tool has validation logic for multi-release jars 
> that is triggered when creating or updating a jar that has a versioned 
> file as an input. I wanted to ask what people think about the idea of 
> exposing this validation logic directly under a --validate command 
> line flag as well.
>
> Malformed multi-release jars can cause compilation and runtime 
> problems because the API exposed by the jar is different across 
> different Java versions. Exposing the validation logic directly would 
> allow for easy validation of jar files that are suspected of being 
> malformed multi-release jars.
>
> The validation logic is already cleanly separated into a separate 
> Validator class in the source code, and adding a command line flag 
> that exposes it directly is a relatively minimal change [1]. It seems 
> like maybe the intent in the past was also to expose this validation 
> logic directly?
>
> What's the history here? Any opinions about exposing this validation 
> logic through a command line option?

I think it could be useful, esp. if Maven or Gradle plugins could make 
use of it.

There is other validation that could be done. JDK-8207339 is one example 
where it would be useful to identify a JAR file with a services 
configuration file that disagrees with the module definition. I bring it 
up because a general --validate option could do more than the 
fingerprint check. If the intention is to limit it to MR JAR features 
then I think it will need a different and more specific option name.

-Alan

From jorn.vernee at oracle.com  Wed May 12 12:47:38 2021
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Wed, 12 May 2021 14:47:38 +0200
Subject: RFC: Add a --validate option to the jar tool
In-Reply-To: 
References: <49af48ea-64b2-67fb-2457-838be780d925@oracle.com>
 
Message-ID: <8fddb7b4-6e8f-6cf6-02ee-50aa3f462919@oracle.com>

On 12/05/2021 14:41, Alan Bateman wrote:
> On 12/05/2021 11:58, Jorn Vernee wrote:
>> Hi,
>>
>> I see that the jar tool has validation logic for multi-release jars 
>> that is triggered when creating or updating a jar that has a 
>> versioned file as an input. I wanted to ask what people think about 
>> the idea of exposing this validation logic directly under a 
>> --validate command line flag as well.
>>
>> Malformed multi-release jars can cause compilation and runtime 
>> problems because the API exposed by the jar is different across 
>> different Java versions. Exposing the validation logic directly would 
>> allow for easy validation of jar files that are suspected of being 
>> malformed multi-release jars.
>>
>> The validation logic is already cleanly separated into a separate 
>> Validator class in the source code, and adding a command line flag 
>> that exposes it directly is a relatively minimal change [1]. It seems 
>> like maybe the intent in the past was also to expose this validation 
>> logic directly?
>>
>> What's the history here? Any opinions about exposing this validation 
>> logic through a command line option?
>
> I think it could be useful, esp. if Maven or Gradle plugins could make 
> use of it.
>
> There is other validation that could be done. JDK-8207339 is one 
> example where it would be useful to identify a JAR file with a 
> services configuration file that disagrees with the module definition. 
> I bring it up because a general --validate option could do more than 
> the fingerprint check. If the intention is to limit it to MR JAR 
> features then I think it will need a different and more specific 
> option name.
Potentially doing other validation seems like a good idea to me as well. 
It seems like the validation logic could be expanded further in the 
future. I brought up multi-release jars because AFAICS that's the only 
thing the existing validation logic concerns itself with, but I don't 
see any reason why validation that doesn't relate to multi-release jars 
couldn't be added as well (and I guess I chose the name --validate for 
that reason :) )

Jorn

From alanb at openjdk.java.net  Wed May 12 12:55:52 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 12 May 2021 12:55:52 GMT
Subject: RFR: 8265605: Cannot call BootLoader::loadClassOrNull before
 initPhase2
In-Reply-To: <5Z-hLKzLSdUeUjO5w8WS9PuGfd7se3IAjo18YaUIWEg=.cccb3896-f58f-4f39-838b-f8e4201fc7ea@github.com>
References: <5Z-hLKzLSdUeUjO5w8WS9PuGfd7se3IAjo18YaUIWEg=.cccb3896-f58f-4f39-838b-f8e4201fc7ea@github.com>
Message-ID: 

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 of the archived module graph in the wrong order. Because of unanticipated nesting of `` methods, `BootLoader::SERVICES_CATALOG` becomes empty, causing future `ServiceLoader` operations to fail.
> 
> The fix has 2 parts:
> 
> - `BootLoader::loadClassOrNull` no longer calls `ClassLoaders::bootLoader()`. This avoids triggering the archived module graph initialization. Instead, it makes a direct call to `Classloader::findBootstrapClassOrNull()`. We don't actually need a `ClassLoader` instance for this call, so I changed `Classloader::findBootstrapClassOrNull()` to be a static method.
> - The object returned by `BootLoader::getServicesCatalog()` is now maintained inside `jdk.internal.loader.ClassLoaders`.  Although not strictly required for the fix, this simplifies the initialization of the archived module graph. It also makes the logic consistent for the 3 built-in loaders (boot/platform/app).
> 
> Testing: tiers1-4 in progress. I also verified that the bug reported by Mandy is no longer reproducible after I applied this patch on her branch.

Changes for CDS usually make the code harder to maintain but I think this patch is okay and improves a few areas. Just a few cleanups to keep the code consistent.

src/java.base/share/classes/jdk/internal/loader/BootLoader.java line 75:

> 73:         = NativeLibraries.jniNativeLibraries(null);
> 74: 
> 75:     private static final JavaLangAccess JLA = SharedSecrets.getJavaLangAccess();

It be nicer if you could move this to the top to be consistent with the other files.

src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java line 58:

> 56:     private static final AppClassLoader APP_LOADER;
> 57: 
> 58:     private static void setArchivedServicesCatalog(ArchivedClassLoaders archivedClassLoaders, ClassLoader loader) {

I'd prefer if we could keep the code consistent if possible. In this case, the method declaration can be split over two lines to avoid one really one line in the file. Also can you add a one line // comment to be consistent with the other private methods.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3992

From github.com+10835776+stsypanov at openjdk.java.net  Wed May 12 13:04:21 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 12 May 2021 13:04:21 GMT
Subject: RFR: 8266972: Use String.concat() in j.l.Class where
 invokedynamic-based String concatenation is not available
Message-ID: 

Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like `baseName.replace('.', '/') + '/' + name` are not compiled into `invokedynamic`-based code, but into one using `StringBuilder`. This happens due to some bootstraping issues.

However the code like

private String getSimpleName0() {
    if (isArray()) {
        return getComponentType().getSimpleName() + "[]";
    }
    //...
}

can be improved via replacement of `+` with `String.concat()` call.

I've used this benchmark to measure impact:

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
public class ClassMethodsBenchmark {
  private final Class arrayClass = Object[].class;
  private Method descriptorString;

  @Setup
  public void setUp() throws NoSuchMethodException {
    //fore some reason compiler doesn't allow me to call Class.descriptorString() directly
    descriptorString = Class.class.getDeclaredMethod("descriptorString");
  }

  @Benchmark
  public Object descriptorString() throws Exception {
    return descriptorString.invoke(arrayClass);
  }

  @Benchmark
  public Object typeName() {
    return arrayClass.getTypeName();
  }
}

and got those results

                                                   Mode  Cnt     Score     Error   Units
descriptorString                                   avgt   60    91.480 ?   1.839   ns/op
descriptorString:?gc.alloc.rate.norm               avgt   60   404.008 ?   4.033    B/op
descriptorString:?gc.churn.G1_Eden_Space           avgt   60  2791.866 ? 181.589  MB/sec
descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60   401.702 ?  26.047    B/op
descriptorString:?gc.churn.G1_Survivor_Space       avgt   60     0.003 ?   0.001  MB/sec
descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ? 10??              B/op
descriptorString:?gc.count                         avgt   60   205.000            counts
descriptorString:?gc.time                          avgt   60   216.000                ms

patched
                                                   Mode  Cnt     Score     Error   Units
descriptorString                                   avgt   60    65.016 ?   3.446   ns/op
descriptorString:?gc.alloc.rate                    avgt   60  2844.240 ? 115.719  MB/sec
descriptorString:?gc.alloc.rate.norm               avgt   60   288.006 ?   0.001    B/op
descriptorString:?gc.churn.G1_Eden_Space           avgt   60  2832.996 ? 206.939  MB/sec
descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60   286.955 ?  17.853    B/op
descriptorString:?gc.churn.G1_Survivor_Space       avgt   60     0.003 ?   0.001  MB/sec
descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ? 10??              B/op
descriptorString:?gc.count                         avgt   60   208.000            counts
descriptorString:?gc.time                          avgt   60   228.000                ms
-----------------
typeName                                           avgt   60    34.273 ?   0.480   ns/op
typeName:?gc.alloc.rate                            avgt   60  3265.356 ?  45.113  MB/sec
typeName:?gc.alloc.rate.norm                       avgt   60   176.004 ?   0.001    B/op
typeName:?gc.churn.G1_Eden_Space                   avgt   60  3268.454 ? 134.458  MB/sec
typeName:?gc.churn.G1_Eden_Space.norm              avgt   60   176.109 ?   6.595    B/op
typeName:?gc.churn.G1_Survivor_Space               avgt   60     0.003 ?   0.001  MB/sec
typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ? 10??              B/op
typeName:?gc.count                                 avgt   60   240.000            counts
typeName:?gc.time                                  avgt   60   255.000                ms

patched

typeName                                           avgt   60    15.787 ?   0.214   ns/op
typeName:?gc.alloc.rate                            avgt   60  2577.554 ?  32.339  MB/sec
typeName:?gc.alloc.rate.norm                       avgt   60    64.001 ?   0.001    B/op
typeName:?gc.churn.G1_Eden_Space                   avgt   60  2574.039 ? 147.774  MB/sec
typeName:?gc.churn.G1_Eden_Space.norm              avgt   60    63.895 ?   3.511    B/op
typeName:?gc.churn.G1_Survivor_Space               avgt   60     0.003 ?   0.001  MB/sec
typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ? 10??              B/op
typeName:?gc.count                                 avgt   60   189.000            counts
typeName:?gc.time                                  avgt   60   199.000                ms

I think this patch is likely to improve reflection operations related to arrays.

If one finds this patch useful, then I'll create a ticket to track this. Also it'd be nice to have a list of classes, that are compiled in the same way as `j.l.Class` (i.e. have no access to `invokedynamic`) so I could look into them for other snippets where two String are joined so `concat`-based optimization is possible.

Pre-sizing of `StringBuilder` for `Class.gdescriptorString()` and `Class.getCanonicalName0()` is one more improvement opportunity here.

-------------

Commit messages:
 - Use String.concat() where invokedynamic-based String concatenation is not available

Changes: https://git.openjdk.java.net/jdk/pull/3627/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3627&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266972
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3627.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3627/head:pull/3627

PR: https://git.openjdk.java.net/jdk/pull/3627

From redestad at openjdk.java.net  Wed May 12 13:04:22 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 12 May 2021 13:04:22 GMT
Subject: RFR: 8266972: Use String.concat() in j.l.Class where
 invokedynamic-based String concatenation is not available
In-Reply-To: 
References: 
Message-ID: 

On Thu, 22 Apr 2021 14:07:20 GMT, ?????? ???????  wrote:

> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like `baseName.replace('.', '/') + '/' + name` are not compiled into `invokedynamic`-based code, but into one using `StringBuilder`. This happens due to some bootstraping issues.
> 
> However the code like
> 
> private String getSimpleName0() {
>     if (isArray()) {
>         return getComponentType().getSimpleName() + "[]";
>     }
>     //...
> }
> 
> can be improved via replacement of `+` with `String.concat()` call.
> 
> I've used this benchmark to measure impact:
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ClassMethodsBenchmark {
>   private final Class arrayClass = Object[].class;
>   private Method descriptorString;
> 
>   @Setup
>   public void setUp() throws NoSuchMethodException {
>     //fore some reason compiler doesn't allow me to call Class.descriptorString() directly
>     descriptorString = Class.class.getDeclaredMethod("descriptorString");
>   }
> 
>   @Benchmark
>   public Object descriptorString() throws Exception {
>     return descriptorString.invoke(arrayClass);
>   }
> 
>   @Benchmark
>   public Object typeName() {
>     return arrayClass.getTypeName();
>   }
> }
> 
> and got those results
> 
>                                                    Mode  Cnt     Score     Error   Units
> descriptorString                                   avgt   60    91.480 ?   1.839   ns/op
> descriptorString:?gc.alloc.rate.norm               avgt   60   404.008 ?   4.033    B/op
> descriptorString:?gc.churn.G1_Eden_Space           avgt   60  2791.866 ? 181.589  MB/sec
> descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60   401.702 ?  26.047    B/op
> descriptorString:?gc.churn.G1_Survivor_Space       avgt   60     0.003 ?   0.001  MB/sec
> descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ? 10??              B/op
> descriptorString:?gc.count                         avgt   60   205.000            counts
> descriptorString:?gc.time                          avgt   60   216.000                ms
> 
> patched
>                                                    Mode  Cnt     Score     Error   Units
> descriptorString                                   avgt   60    65.016 ?   3.446   ns/op
> descriptorString:?gc.alloc.rate                    avgt   60  2844.240 ? 115.719  MB/sec
> descriptorString:?gc.alloc.rate.norm               avgt   60   288.006 ?   0.001    B/op
> descriptorString:?gc.churn.G1_Eden_Space           avgt   60  2832.996 ? 206.939  MB/sec
> descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60   286.955 ?  17.853    B/op
> descriptorString:?gc.churn.G1_Survivor_Space       avgt   60     0.003 ?   0.001  MB/sec
> descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ? 10??              B/op
> descriptorString:?gc.count                         avgt   60   208.000            counts
> descriptorString:?gc.time                          avgt   60   228.000                ms
> -----------------
> typeName                                           avgt   60    34.273 ?   0.480   ns/op
> typeName:?gc.alloc.rate                            avgt   60  3265.356 ?  45.113  MB/sec
> typeName:?gc.alloc.rate.norm                       avgt   60   176.004 ?   0.001    B/op
> typeName:?gc.churn.G1_Eden_Space                   avgt   60  3268.454 ? 134.458  MB/sec
> typeName:?gc.churn.G1_Eden_Space.norm              avgt   60   176.109 ?   6.595    B/op
> typeName:?gc.churn.G1_Survivor_Space               avgt   60     0.003 ?   0.001  MB/sec
> typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ? 10??              B/op
> typeName:?gc.count                                 avgt   60   240.000            counts
> typeName:?gc.time                                  avgt   60   255.000                ms
> 
> patched
> 
> typeName                                           avgt   60    15.787 ?   0.214   ns/op
> typeName:?gc.alloc.rate                            avgt   60  2577.554 ?  32.339  MB/sec
> typeName:?gc.alloc.rate.norm                       avgt   60    64.001 ?   0.001    B/op
> typeName:?gc.churn.G1_Eden_Space                   avgt   60  2574.039 ? 147.774  MB/sec
> typeName:?gc.churn.G1_Eden_Space.norm              avgt   60    63.895 ?   3.511    B/op
> typeName:?gc.churn.G1_Survivor_Space               avgt   60     0.003 ?   0.001  MB/sec
> typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ? 10??              B/op
> typeName:?gc.count                                 avgt   60   189.000            counts
> typeName:?gc.time                                  avgt   60   199.000                ms
> 
> I think this patch is likely to improve reflection operations related to arrays.
> 
> If one finds this patch useful, then I'll create a ticket to track this. Also it'd be nice to have a list of classes, that are compiled in the same way as `j.l.Class` (i.e. have no access to `invokedynamic`) so I could look into them for other snippets where two String are joined so `concat`-based optimization is possible.
> 
> Pre-sizing of `StringBuilder` for `Class.gdescriptorString()` and `Class.getCanonicalName0()` is one more improvement opportunity here.

src/java.base/share/classes/java/lang/Class.java line 4351:

> 4349: 
> 4350:         if (isArray()) {
> 4351:             return "[".concat(componentType.descriptorString());

This could be optimized further for multi-dimensional arrays:

if (isArray()) {
  int arrayDepth = 1;
  Class ct = componentType;
  while (ct.isArray()) {
    arrayDepth++;
    ct = ct.componentType;
  }
  return "[".repeat(arrayDepth).concat(ct.descriptorString());

-------------

PR: https://git.openjdk.java.net/jdk/pull/3627

From github.com+10835776+stsypanov at openjdk.java.net  Wed May 12 13:04:22 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 12 May 2021 13:04:22 GMT
Subject: RFR: 8266972: Use String.concat() in j.l.Class where
 invokedynamic-based String concatenation is not available
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 12 May 2021 09:59:32 GMT, Claes Redestad  wrote:

>> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like `baseName.replace('.', '/') + '/' + name` are not compiled into `invokedynamic`-based code, but into one using `StringBuilder`. This happens due to some bootstraping issues.
>> 
>> However the code like
>> 
>> private String getSimpleName0() {
>>     if (isArray()) {
>>         return getComponentType().getSimpleName() + "[]";
>>     }
>>     //...
>> }
>> 
>> can be improved via replacement of `+` with `String.concat()` call.
>> 
>> I've used this benchmark to measure impact:
>> 
>> @State(Scope.Thread)
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
>> public class ClassMethodsBenchmark {
>>   private final Class arrayClass = Object[].class;
>>   private Method descriptorString;
>> 
>>   @Setup
>>   public void setUp() throws NoSuchMethodException {
>>     //fore some reason compiler doesn't allow me to call Class.descriptorString() directly
>>     descriptorString = Class.class.getDeclaredMethod("descriptorString");
>>   }
>> 
>>   @Benchmark
>>   public Object descriptorString() throws Exception {
>>     return descriptorString.invoke(arrayClass);
>>   }
>> 
>>   @Benchmark
>>   public Object typeName() {
>>     return arrayClass.getTypeName();
>>   }
>> }
>> 
>> and got those results
>> 
>>                                                    Mode  Cnt     Score     Error   Units
>> descriptorString                                   avgt   60    91.480 ?   1.839   ns/op
>> descriptorString:?gc.alloc.rate.norm               avgt   60   404.008 ?   4.033    B/op
>> descriptorString:?gc.churn.G1_Eden_Space           avgt   60  2791.866 ? 181.589  MB/sec
>> descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60   401.702 ?  26.047    B/op
>> descriptorString:?gc.churn.G1_Survivor_Space       avgt   60     0.003 ?   0.001  MB/sec
>> descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ? 10??              B/op
>> descriptorString:?gc.count                         avgt   60   205.000            counts
>> descriptorString:?gc.time                          avgt   60   216.000                ms
>> 
>> patched
>>                                                    Mode  Cnt     Score     Error   Units
>> descriptorString                                   avgt   60    65.016 ?   3.446   ns/op
>> descriptorString:?gc.alloc.rate                    avgt   60  2844.240 ? 115.719  MB/sec
>> descriptorString:?gc.alloc.rate.norm               avgt   60   288.006 ?   0.001    B/op
>> descriptorString:?gc.churn.G1_Eden_Space           avgt   60  2832.996 ? 206.939  MB/sec
>> descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60   286.955 ?  17.853    B/op
>> descriptorString:?gc.churn.G1_Survivor_Space       avgt   60     0.003 ?   0.001  MB/sec
>> descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ? 10??              B/op
>> descriptorString:?gc.count                         avgt   60   208.000            counts
>> descriptorString:?gc.time                          avgt   60   228.000                ms
>> -----------------
>> typeName                                           avgt   60    34.273 ?   0.480   ns/op
>> typeName:?gc.alloc.rate                            avgt   60  3265.356 ?  45.113  MB/sec
>> typeName:?gc.alloc.rate.norm                       avgt   60   176.004 ?   0.001    B/op
>> typeName:?gc.churn.G1_Eden_Space                   avgt   60  3268.454 ? 134.458  MB/sec
>> typeName:?gc.churn.G1_Eden_Space.norm              avgt   60   176.109 ?   6.595    B/op
>> typeName:?gc.churn.G1_Survivor_Space               avgt   60     0.003 ?   0.001  MB/sec
>> typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ? 10??              B/op
>> typeName:?gc.count                                 avgt   60   240.000            counts
>> typeName:?gc.time                                  avgt   60   255.000                ms
>> 
>> patched
>> 
>> typeName                                           avgt   60    15.787 ?   0.214   ns/op
>> typeName:?gc.alloc.rate                            avgt   60  2577.554 ?  32.339  MB/sec
>> typeName:?gc.alloc.rate.norm                       avgt   60    64.001 ?   0.001    B/op
>> typeName:?gc.churn.G1_Eden_Space                   avgt   60  2574.039 ? 147.774  MB/sec
>> typeName:?gc.churn.G1_Eden_Space.norm              avgt   60    63.895 ?   3.511    B/op
>> typeName:?gc.churn.G1_Survivor_Space               avgt   60     0.003 ?   0.001  MB/sec
>> typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ? 10??              B/op
>> typeName:?gc.count                                 avgt   60   189.000            counts
>> typeName:?gc.time                                  avgt   60   199.000                ms
>> 
>> I think this patch is likely to improve reflection operations related to arrays.
>> 
>> If one finds this patch useful, then I'll create a ticket to track this. Also it'd be nice to have a list of classes, that are compiled in the same way as `j.l.Class` (i.e. have no access to `invokedynamic`) so I could look into them for other snippets where two String are joined so `concat`-based optimization is possible.
>> 
>> Pre-sizing of `StringBuilder` for `Class.gdescriptorString()` and `Class.getCanonicalName0()` is one more improvement opportunity here.
>
> src/java.base/share/classes/java/lang/Class.java line 4351:
> 
>> 4349: 
>> 4350:         if (isArray()) {
>> 4351:             return "[".concat(componentType.descriptorString());
> 
> This could be optimized further for multi-dimensional arrays:
> 
> if (isArray()) {
>   int arrayDepth = 1;
>   Class ct = componentType;
>   while (ct.isArray()) {
>     arrayDepth++;
>     ct = ct.componentType;
>   }
>   return "[".repeat(arrayDepth).concat(ct.descriptorString());

But isn't `componentType.descriptorString()` does this itself? Also multi-dimensional arrays are quite an infrequent usecase, aren't they?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3627

From redestad at openjdk.java.net  Wed May 12 13:15:23 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 12 May 2021 13:15:23 GMT
Subject: RFR: 8266972: Use String.concat() in j.l.Class where
 invokedynamic-based String concatenation is not available
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 12 May 2021 11:00:25 GMT, ?????? ???????  wrote:

>> src/java.base/share/classes/java/lang/Class.java line 4351:
>> 
>>> 4349: 
>>> 4350:         if (isArray()) {
>>> 4351:             return "[".concat(componentType.descriptorString());
>> 
>> This could be optimized further for multi-dimensional arrays:
>> 
>> if (isArray()) {
>>   int arrayDepth = 1;
>>   Class ct = componentType;
>>   while (ct.isArray()) {
>>     arrayDepth++;
>>     ct = ct.componentType;
>>   }
>>   return "[".repeat(arrayDepth).concat(ct.descriptorString());
>
> But isn't `componentType.descriptorString()` does this itself? Also multi-dimensional arrays are quite an infrequent usecase, aren't they?

Yeah, it's just an optimization. Current code wouldbuild "[[..[[LFoo;" by recursively going down to `Foo`, build and return "LFoo;", then do "[" + "LFoo;", and so on. Infrequent enough that we can ignore it, sure, but since it's effectively reducing the algorithmic complexity from O(n*m) to O(n+m) I should at least mention it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3627

From vlivanov at openjdk.java.net  Wed May 12 14:08:00 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 12 May 2021 14:08:00 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 May 2021 20:43:20 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://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * Remove unused imports
>   * Fix broken javadoc after removal of @throws clauses
>   * Remove other `@CallerSensitive` annotations from `AbstractCLinker`

Overall, hotspot and java.lang.invoke changes look good.

One comment though on naming: there are multiple references to Panama in the code. Moreover, it is used inconsistently (`is_panama_entry_frame()` vs `EntryBlob` vs `OptimizedUpcallStub`). 
I suggest to get rid of any references to Panama and use `optimized`uniformly where appropriate (`is_optimized_entry_frame()`, `OptimizedEntryBlob`, `OptimizedUpcallStub`).

Some minor comments follow.

src/hotspot/share/prims/universalUpcallHandler.cpp line 122:

> 120: JNI_END
> 121: 
> 122: JVM_ENTRY(jlong, PUH_AllocateOptimzedUpcallStub(JNIEnv *env, jclass unused, jobject mh, jobject abi, jobject conv))

Typo: `PUH_AllocateOptimzedUpcallStub` -> `PUH_AllocateOptimizedUpcallStub`.

src/hotspot/share/prims/universalUpcallHandler.cpp line 137:

> 135: JVM_END
> 136: 
> 137: JVM_ENTRY(jboolean, PUH_SupportsOptimzedUpcalls(JNIEnv *env, jclass unused))

Typo: `Optimzed` -> `Optimized`

src/hotspot/share/runtime/sharedRuntime.hpp line 465:

> 463:   static void restore_native_result(MacroAssembler *_masm, BasicType ret_type, int frame_slots);
> 464: 
> 465:   static void   move32_64(MacroAssembler* masm, VMRegPair src, VMRegPair dst);

Please, file an RFE to move these declarations to `MacroAssembler`.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3699

From rriggs at openjdk.java.net  Wed May 12 14:08:35 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 12 May 2021 14:08:35 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
Message-ID: 

JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
configuration mechanisms and filter utilities.

-------------

Commit messages:
 - JEP 415: Context-specific Deserialization Filters

Changes: https://git.openjdk.java.net/jdk/pull/3996/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264859
  Stats: 1583 lines in 5 files changed: 1475 ins; 24 del; 84 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3996.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3996/head:pull/3996

PR: https://git.openjdk.java.net/jdk/pull/3996

From vlivanov at openjdk.java.net  Wed May 12 14:38:18 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 12 May 2021 14:38:18 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 May 2021 20:43:20 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://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * Remove unused imports
>   * Fix broken javadoc after removal of @throws clauses
>   * Remove other `@CallerSensitive` annotations from `AbstractCLinker`

src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp line 472:

> 470:   __ block_comment("} preserve_callee_saved_regs ");
> 471: 
> 472:   // TODO mxcsr

Anything left to do with mxcsr?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From aph at redhat.com  Wed May 12 14:42:21 2021
From: aph at redhat.com (Andrew Haley)
Date: Wed, 12 May 2021 15:42:21 +0100
Subject: JEP draft: Scope Locals
Message-ID: 

There's been considerable discussion about scope locals on the loom-dev list,
and it's now time to open this to a wider audience. This subject is important
because. although scope locals were motivated by the the needs of Loom, they
have many potential applications outside that project.

The draft JEP is at

https://bugs.openjdk.java.net/browse/JDK-8263012

I've already received some very helpful suggestions for enhancements to
the API, and it'll take me a while to work through them all. In particular,
Paul Sandoz has suggested that I unify the classes Snapshot and Carrier,
and it will take me some time to understand the consequences of that.

In the meantime, please have a look at the JEP and comment here.


For reference, earlier discussions are at

https://mail.openjdk.java.net/pipermail/loom-dev/2021-March/002268.html
https://mail.openjdk.java.net/pipermail/loom-dev/2021-April/002287.html
https://mail.openjdk.java.net/pipermail/loom-dev/2021-May/002427.html

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671



From jvernee at openjdk.java.net  Wed May 12 14:58:56 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 12 May 2021 14:58:56 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 12 May 2021 14:06:46 GMT, Vladimir Ivanov  wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * Remove unused imports
>>   * Fix broken javadoc after removal of @throws clauses
>>   * Remove other `@CallerSensitive` annotations from `AbstractCLinker`
>
> src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp line 472:
> 
>> 470:   __ block_comment("} preserve_callee_saved_regs ");
>> 471: 
>> 472:   // TODO mxcsr
> 
> Anything left to do with mxcsr?

I guess this slipped through with the initial PR.

JNI code loads the default value of mxcsr here and saves/restores the incoming native value: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#L265-L298

However, it does nothing on Windows, while the Windows x64 ABI also defines mxcsr to have a non-volatile portion (i.e. that should be saved and restored): https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-160#mxcsr

I think this made me a bit unsure about the need for saving and restoring mxcsr, and wanted to find an actual test case that causes a problem, rather than just copy-pasting the code (or at least understand it a bit better). But, at this time I haven't gotten to that yet.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From avoitylov at openjdk.java.net  Wed May 12 15:03:54 2021
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Wed, 12 May 2021 15:03:54 GMT
Subject: RFR: 8266310: deadlock while loading the JNI code
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 11 May 2021 13:28:16 GMT, Alan Bateman  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 library load operation.
>> 
>> Problem being fixed:
>> 
>> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread.
>> 
>> Proposed fix:
>> 
>> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method.
>> 
>> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared.
>> 
>> Testing:  jtreg and jck testing with no regressions. A new regression test was developed.
>
> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 478:
> 
>> 476: 
>> 477:     // thread local native libraries stack
>> 478:     private static final ThreadLocal> nativeLibraryThreadContext =
> 
> I would prefer not see thread locals introduced here. We've put a lot of effort into recent releases to eliminate the use of TLs from java.base.

I will update the PR to avoid ThreadLocal and have ArrayDeque deallocated once its last element has been popped out.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3976

From mcimadamore at openjdk.java.net  Wed May 12 15:11:51 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 12 May 2021 15:11:51 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 12 May 2021 13:57:21 GMT, Vladimir Ivanov  wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * Remove unused imports
>>   * Fix broken javadoc after removal of @throws clauses
>>   * Remove other `@CallerSensitive` annotations from `AbstractCLinker`
>
> src/hotspot/share/runtime/sharedRuntime.hpp line 465:
> 
>> 463:   static void restore_native_result(MacroAssembler *_masm, BasicType ret_type, int frame_slots);
>> 464: 
>> 465:   static void   move32_64(MacroAssembler* masm, VMRegPair src, VMRegPair dst);
> 
> Please, file an RFE to move these declarations to `MacroAssembler`.

There's already an issue for that:
https://bugs.openjdk.java.net/browse/JDK-8266257

I've upgraded the description to make it reflect the proposed move a bit more precisely.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From tschatzl at openjdk.java.net  Wed May 12 15:22:58 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 12 May 2021 15:22:58 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 May 2021 08:28:43 GMT, Kim Barrett  wrote:

>> Please review this change to the String Deduplication facility.  It is being
>> changed to use OopStorage to hold weak references to relevant objects,
>> rather than bespoke data structures requiring dedicated processing phases by
>> supporting GCs.
>> 
>> (The Shenandoah update was contributed by Zhengyu Gu.)
>> 
>> This change significantly simplifies the interface between a given GC and
>> the String Deduplication facility, which should make it much easier for
>> other GCs to opt in.  However, this change does not alter the set of GCs
>> providing support; currently only G1 and Shenandoah support string
>> deduplication.  Adding support by other GCs will be in followup RFEs.
>> 
>> Reviewing via the diffs might not be all that useful for some parts, as
>> several files have been essentially completely replaced, and a number of
>> files have been added or eliminated.  The full webrev might be a better
>> place to look.
>> 
>> The major changes are in gc/shared/stringdedup/* and in the supporting
>> collectors, but there are also some smaller changes in other places, most
>> notably classfile/{stringTable,javaClasses}.
>> 
>> This change is additionally labeled for review by core-libs, although there
>> are no source changes there.  This change injects a byte field of bits into
>> java.lang.String, using one of the previously unused padding bytes in that
>> class.  (There were two unused bytes, now only one.)
>> 
>> Testing:
>> mach5 tier1-2 with and without -XX:+UseStringDeduplication
>> 
>> Locally (linux-x64) ran all of the existing tests that use string
>> deduplication with both G1 and Shenandoah.  Note that
>> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
>> currently fails, for reasons I haven't figured out but suspect are test
>> related.
>> 
>> - gc/stringdedup/   -- these used to be in gc/g1
>> - runtime/cds/SharedStringsDedup.java
>> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
>> - runtime/cds/appcds/sharedStrings/*
>> 
>> shenandoah-only:
>> - gc/shenandoah/jvmti/TestHeapDump.java
>> - gc/shenandoah/TestStringDedup.java
>> - gc/shenandoah/TestStringDedupStress.java
>> 
>> Performance tested baseline, baseline + stringdedup, new with stringdedup,
>> finding no significant differences.
>
> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - more comment improvements
>  - improve naming and comments around injected String flags
>  - fix some typos in comments

Lgtm.

src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp line 82:

> 80: // Doing so would counteract C2 optimizations on string literals.  But an
> 81: // interned string might later become a deduplication candidate through the
> 82: // normal GC discovery mechanism.  To prevent such modificatoins, the

s/modificatoins/modifications

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3662

From dfuchs at openjdk.java.net  Wed May 12 15:58:16 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 12 May 2021 15:58:16 GMT
Subject: RFR: 8263382: java/util/logging/ParentLoggersTest.java failed with
 "checkLoggers: getLoggerNames() returned unexpected loggers"
Message-ID: <_VqYCFeIaJBXgJGjxkfIeWsw-ghd84Ugd_f8IDgAqnY=.b72352cc-8e08-43aa-8033-c2788d949c02@github.com>

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 causes the LogManager to reparse its configuration and should therefore run in its own VM.

-------------

Commit messages:
 - 8263382: java/util/logging/ParentLoggersTest.java failed with "checkLoggers: getLoggerNames() returned unexpected loggers"

Changes: https://git.openjdk.java.net/jdk/pull/3997/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3997&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263382
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3997.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3997/head:pull/3997

PR: https://git.openjdk.java.net/jdk/pull/3997

From bpb at openjdk.java.net  Wed May 12 16:09:55 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 12 May 2021 16:09:55 GMT
Subject: RFR: 8263382: java/util/logging/ParentLoggersTest.java failed
 with "checkLoggers: getLoggerNames() returned unexpected loggers"
In-Reply-To: <_VqYCFeIaJBXgJGjxkfIeWsw-ghd84Ugd_f8IDgAqnY=.b72352cc-8e08-43aa-8033-c2788d949c02@github.com>
References: <_VqYCFeIaJBXgJGjxkfIeWsw-ghd84Ugd_f8IDgAqnY=.b72352cc-8e08-43aa-8033-c2788d949c02@github.com>
Message-ID: 

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 causes the LogManager to reparse its configuration and should therefore run in its own VM.

Seems reasonable.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3997

From hseigel at openjdk.java.net  Wed May 12 16:10:25 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 12 May 2021 16:10:25 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
Message-ID: 

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 of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix GetModuleTest.java

Thanks Alan, Ioi, and Mandy for looking at this.  The latest changes should address the issues that you found.
Harold

-------------

PR: https://git.openjdk.java.net/jdk/pull/3974

From hseigel at openjdk.java.net  Wed May 12 16:10:24 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 12 May 2021 16:10:24 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]
In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
Message-ID: 

> 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 of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
> 
> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
> 
> Thanks, Harold

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  test changes and small fixes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3974/files
  - new: https://git.openjdk.java.net/jdk/pull/3974/files/874a1603..5246dd76

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=02-03

  Stats: 286 lines in 10 files changed: 22 ins; 256 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3974.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974

PR: https://git.openjdk.java.net/jdk/pull/3974

From hseigel at openjdk.java.net  Wed May 12 16:10:26 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 12 May 2021 16:10:26 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: 
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
 
Message-ID: <6vXfHjNzHSk46muMlntg2ZqE1OSmHx0eg08V-3AqIvc=.2dbd90d5-453a-4447-abfd-9aebfff9143d@github.com>

On Tue, 11 May 2021 17:07:35 GMT, Ioi Lam  wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix GetModuleTest.java
>
> src/hotspot/share/oops/instanceMirrorKlass.inline.hpp line 65:
> 
>> 63:         // so when handling the java mirror for the class we need to make sure its class
>> 64:         // loader data is claimed, this is done by calling do_cld explicitly.
>> 65:         // For non-string hidden classes the call to do_cld is made when the class
> 
> Typo: non-strong

fixed, thanks for finding this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3974

From hseigel at openjdk.java.net  Wed May 12 16:10:27 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 12 May 2021 16:10:27 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <6jFp2B7imcUETfAlhzQUDtp45nwnPauD7rcSfqG4CI8=.39e2a9ab-42ec-4633-9bfc-82a327ed2564@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
 <6jFp2B7imcUETfAlhzQUDtp45nwnPauD7rcSfqG4CI8=.39e2a9ab-42ec-4633-9bfc-82a327ed2564@github.com>
Message-ID: 

On Tue, 11 May 2021 20:49:46 GMT, Mandy Chung  wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix GetModuleTest.java
>
> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MetaUtil.java line 53:
> 
>> 51:             return simpleName;
>> 52:         }
>> 53:         // Must be a local class
> 
> This file should not be changed.  It refers to the Java language anonymous class (not VM anonymous class).

Changes have been restored.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3974

From naoto at openjdk.java.net  Wed May 12 16:38:48 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 12 May 2021 16:38:48 GMT
Subject: RFR: 8258795: Update IANA Language Subtag Registry to Version
 2021-05-11
Message-ID: 

Please review the changes to the subject issue. This is to incorporate the latest language subtag registry definition into the JDK.

-------------

Commit messages:
 - Renaming the test case
 - LSR 2021-05-11
 - LSR 2021-03-05
 - LSR 2021-02-23
 - LSR 2020-12-18

Changes: https://git.openjdk.java.net/jdk/pull/3998/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3998&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258795
  Stats: 340 lines in 2 files changed: 327 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3998.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3998/head:pull/3998

PR: https://git.openjdk.java.net/jdk/pull/3998

From mitsuru.kariya at oss.nttdata.com  Wed May 12 17:00:45 2021
From: mitsuru.kariya at oss.nttdata.com (Mitsuru Kariya)
Date: Thu, 13 May 2021 02:00:45 +0900
Subject: Would anyone please reopen JDK-4991002?
In-Reply-To: 
References: <5a182c946c75707b7deb5c95175818a1@oss.nttdata.com>
 
Message-ID: <3025432253ed277d563295814df32437@oss.nttdata.com>

Thank you for your quick reply and precise advice.

> Once you have signed your OCA and have generated your proposed patch,
> feel free to create your PR.

I already have signed the OCA, so I'll start with a PR for an open 
issue, JDK-8153490.

Thanks,

On 2021-05-12 02:59, Lance Andersen wrote:
> Hi Mitsuru,
> 
> Thank you for your interest in contributing to the OpenJDK project
> 
> If you are not an Author, you can file bugs via
> https://bugreport.java.com/bugreport/
> 
> To contribute fixes,  you will need to sign an Oracle Committer
> Agreement(OCA).  Please see https://openjdk.java.net/contribute/ for
> more info
> 
> Please enter a new issue which you can use to address your
> SerialBlob/Clob fixes.  You will also need to  add the tests to verify
> the fix to the relevant tests in open/test/jdk/javax/sql/testng/test
> 
>  RowSets, in particular the Serialxxx classes, are seldom used (if at
> all) as there are better alternatives for an API.
> 
> Once you have signed your OCA and have generated your proposed patch,
> feel free to create your PR.
> 
> Best
> Lance
> 
>> On May 11, 2021, at 9:11 AM, Mitsuru Kariya
>>  wrote:
>> 
>> Hi,
>> 
>> While reading the source for SerialBlob, I found that
>> SerialBlob.position() does not work correctly.
>> So, I searched JBS and found the description in JDK-4991002 point 1,
>> but it was closed by Cannot Reproduce.
>> 
>> It can be reproduced easily like below.
>> 
>> SerialBlob sb = new SerialBlob(new byte[]{1, 2, 3, 4, 5});
>> System.out.println(sb.position(new byte[]{1, 3, 5}, 1));
>> 
>> It should output "-1"(not found) but the current implementation
>> outputs "3"(found at position 3).
>> 
>> So, would anyone please reopen JDK-4991002 for me?
>> (I cannot reopen it because I don't have an Author role.)
>> 
>> Furthermore, SerialClob has same problem and JDK-4991036 describes
>> it.
>> So, may I fix it together?
>> Or do I need to separate the PR from JDK-4991002?
>> 
>> JDK-4991002:The class javax.sql.rowset.serial.SerialBlob is too
>> buggy
>> https://bugs.openjdk.java.net/browse/JDK-4991002
>> 
>> JDK-4991036:The class javax.sql.rowset.serial.SerialClob is too
>> buggy
>> https://bugs.openjdk.java.net/browse/JDK-4991036
>> 
>> Please let me know if there is a better place to do so.
>> 
>> Thanks
> 
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com

From roger.riggs at oracle.com  Wed May 12 17:41:41 2021
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 12 May 2021 13:41:41 -0400
Subject: Proposal for new interface: TimeSource
In-Reply-To: 
References: 
 
Message-ID: <6622fc7d-3689-47c7-36ea-0bcb027bc1e0@oracle.com>

Hi Stephen,

A useful enhancement.

Will you be posting a PR for the implementation?
It is frequently helpful to evaluate the CSR and the implementation 
concurrently.

Thanks, Roger

On 5/10/21 1:06 AM, Aaron Scott-Boddendijk wrote:
> Yes please.
>
> I often have people ask how they should solve exactly this problem and we
> have several code-bases that have their own implementations of essentially
> this interface.
>
> We've used it not only for the request-contextual time localisation but for
> controlling the stepping for data-processing and simulation.
>
> A standard interface might also mean this makes its way into 1st-class
> testing framework parameterisation.
>
> --
> Aaron Scott-Boddendijk
>
>
> On Fri, May 7, 2021 at 11:28 AM Stephen Colebourne 
> wrote:
>
>> This is a proposal to add a new interface to java.time.*
>>
>>    public interface TimeSource {
>>      public static TimeSource system() { ... }
>>      public abstract Instant instant();
>>      public default long millis() {
>>        return instant().toEpochMilli();
>>      }
>>      public default Clock withZone(ZoneId zoneId) {
>>        return Clock.of(this, zoneId);
>>     }
>>    }
>>
>> The existing `Clock` abstract class would be altered to implement the
>> interface.
>> A new static method `Clock.of(TimeSource, ZoneId)` would be added.
>> No changes are needed to any other part of the API.
>> (Could add `Instant.now(TimeSource)`, but it isn't entirely necessary)
>>
>> Callers would pass around and use `TimeSource` directly, for example
>> by dependency injection.
>>
>>
>> Why add this interface?
>> I've seen various indications that there is a desire for an interface
>> representing a supplier of `Instant`. Specifically this desire is
>> driven by the "unnecessary" time zone that `java.time.Clock` contains.
>> Put simply, if the only thing you want is an `Instant`, then `Clock`
>> isn't the right API because it forces you to think about time zones.
>>
>> A key thing that this interface allows is the separation of the OS
>> Clock from the time-zone (which should generally be linked to user
>> localization). A good architecture would pass `TimeSource` around the
>> system and combine it with a time-zone held in a `UserContext` to get
>> a `Clock`. The current design of java.time.* does not enable that
>> because the `TimeSource` concept does not exist. Developers either
>> have to write their own interface, or use `Clock` and ignore the time
>> zone.
>>
>> A `Supplier` obviously performs similar functionality, but it
>> lacks discoverability and understandability. Plus, injecting
>> generified interfaces tends to be painful.
>>
>> Downsides?
>> None really, other than a new type in the JDK that probably should
>> have been in Java 8.
>>
>>
>> See this ThreeTen-Extra discussion
>> - https://github.com/ThreeTen/threeten-extra/issues/150
>>
>> Joda-Time has a `MillisProvider` that is similar:
>> -
>> https://www.joda.org/joda-time/apidocs/org/joda/time/DateTimeUtils.MillisProvider.html
>>
>> Time4J has a `TimeSource`:
>> -
>> https://github.com/MenoData/Time4J/blob/master/base/src/main/java/net/time4j/base/TimeSource.java
>>
>> Spring has a `DateTimeContext` that separates the user localization as
>> per the `UserContext` described above:
>> -
>> https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/format/datetime/standard/DateTimeContext.html
>>
>> There is a similar concept `TimeSource` in `sun.net.httpserver`
>>
>> There may be a case to name the interface `InstantSource`, however
>> `TimeSource` is a fairly widely understood name for this concept.
>>
>>
>> There is the potential to extend the interface with something similar
>> to Kotlin's `TimeMark` that would allow access to the monotonic clock,
>> suitable for measurement of durations without any leap second effects:
>> - https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.time/-time-mark/
>>
>> Feedback?
>>
>> Stephen
>>


From mchung at openjdk.java.net  Wed May 12 18:04:55 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 12 May 2021 18:04:55 GMT
Subject: RFR: 8265605: Cannot call BootLoader::loadClassOrNull before
 initPhase2
In-Reply-To: <5Z-hLKzLSdUeUjO5w8WS9PuGfd7se3IAjo18YaUIWEg=.cccb3896-f58f-4f39-838b-f8e4201fc7ea@github.com>
References: <5Z-hLKzLSdUeUjO5w8WS9PuGfd7se3IAjo18YaUIWEg=.cccb3896-f58f-4f39-838b-f8e4201fc7ea@github.com>
Message-ID: <2KUzvbgw6D1xPpyDwbdZ2FfmYxh_v9SVS2p6hjsGcvo=.8b9d9bc0-2ccd-4dcd-86e0-bac2673a71c2@github.com>

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 of the archived module graph in the wrong order. Because of unanticipated nesting of `` methods, `BootLoader::SERVICES_CATALOG` becomes empty, causing future `ServiceLoader` operations to fail.
> 
> The fix has 2 parts:
> 
> - `BootLoader::loadClassOrNull` no longer calls `ClassLoaders::bootLoader()`. This avoids triggering the archived module graph initialization. Instead, it makes a direct call to `Classloader::findBootstrapClassOrNull()`. We don't actually need a `ClassLoader` instance for this call, so I changed `Classloader::findBootstrapClassOrNull()` to be a static method.
> - The object returned by `BootLoader::getServicesCatalog()` is now maintained inside `jdk.internal.loader.ClassLoaders`.  Although not strictly required for the fix, this simplifies the initialization of the archived module graph. It also makes the logic consistent for the 3 built-in loaders (boot/platform/app).
> 
> Testing: tiers1-4 in progress. I also verified that the bug reported by Mandy is no longer reproducible after I applied this patch on her branch.

Thanks for fixing this.   This is also an improvement in how service catalogs are loaded from the CDS archive.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3992

From rriggs at openjdk.java.net  Wed May 12 18:05:58 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 12 May 2021 18:05:58 GMT
Subject: RFR: 8265248: Implementation Specific Properties: change prefix,
 plus add existing properties [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 12 May 2021 00:42:57 GMT, Joe Wang  wrote:

>> Update module summary, add a few existing properties and features into the tables.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add legacy property names table

The new table looks fine, ut I think it will be less confusing if the property names are fully qualified (with the jdk.xml prefix) and can be seen as identical to the names in the previous table.

-------------

Changes requested by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3644

From github.com+2217224+kariya-mitsuru at openjdk.java.net  Wed May 12 18:07:03 2021
From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru Kariya)
Date: Wed, 12 May 2021 18:07:03 GMT
Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger
 than number of elements we want to insert.
Message-ID: 

Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases:

1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()`
   The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully.
   (test31)

2. `pos - 1 + length > this.length()`
   The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1
   (test32)

3. `pos == this.length() + 1`
   The original implementation throws `SerialException` but this case should end successfully. *2
   (test33)

Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases:

1. `offset > str.length()`
   The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`.
   (test39)

2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()`
   The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully.
   (test32)

3. `pos - 1 + length > this.length()`
   The original implementaion throws `SerialException` but this case should end successfully. *3
   (test40)

4. `pos == this.length() + 1`
   The original implementaion throws `SerialException` but this case should end successfully. *4
   (test41)

The javadoc has also been modified according to the above.

*1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes."

*2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined."
   So, it should work correctly when pos == length+1 of the BLOB value.

*3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters."

*4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined."
   So, it should work correctly when pos == length+1 of the CLOB value.

-------------

Commit messages:
 - 8153490:Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert.

Changes: https://git.openjdk.java.net/jdk/pull/4001/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4001&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8153490
  Stats: 179 lines in 4 files changed: 122 ins; 17 del; 40 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4001.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4001/head:pull/4001

PR: https://git.openjdk.java.net/jdk/pull/4001

From mchung at openjdk.java.net  Wed May 12 18:20:58 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 12 May 2021 18:20:58 GMT
Subject: RFR: 8263382: java/util/logging/ParentLoggersTest.java failed
 with "checkLoggers: getLoggerNames() returned unexpected loggers"
In-Reply-To: <_VqYCFeIaJBXgJGjxkfIeWsw-ghd84Ugd_f8IDgAqnY=.b72352cc-8e08-43aa-8033-c2788d949c02@github.com>
References: <_VqYCFeIaJBXgJGjxkfIeWsw-ghd84Ugd_f8IDgAqnY=.b72352cc-8e08-43aa-8033-c2788d949c02@github.com>
Message-ID: 

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 causes the LogManager to reparse its configuration and should therefore run in its own VM.

I think you are right that this test should be run in other VM since it alters the system property.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3997

From iklam at openjdk.java.net  Wed May 12 18:23:26 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 12 May 2021 18:23:26 GMT
Subject: RFR: 8265605: Cannot call BootLoader::loadClassOrNull before
 initPhase2 [v2]
In-Reply-To: <5Z-hLKzLSdUeUjO5w8WS9PuGfd7se3IAjo18YaUIWEg=.cccb3896-f58f-4f39-838b-f8e4201fc7ea@github.com>
References: <5Z-hLKzLSdUeUjO5w8WS9PuGfd7se3IAjo18YaUIWEg=.cccb3896-f58f-4f39-838b-f8e4201fc7ea@github.com>
Message-ID: 

> 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 of the archived module graph in the wrong order. Because of unanticipated nesting of `` methods, `BootLoader::SERVICES_CATALOG` becomes empty, causing future `ServiceLoader` operations to fail.
> 
> The fix has 2 parts:
> 
> - `BootLoader::loadClassOrNull` no longer calls `ClassLoaders::bootLoader()`. This avoids triggering the archived module graph initialization. Instead, it makes a direct call to `Classloader::findBootstrapClassOrNull()`. We don't actually need a `ClassLoader` instance for this call, so I changed `Classloader::findBootstrapClassOrNull()` to be a static method.
> - The object returned by `BootLoader::getServicesCatalog()` is now maintained inside `jdk.internal.loader.ClassLoaders`.  Although not strictly required for the fix, this simplifies the initialization of the archived module graph. It also makes the logic consistent for the 3 built-in loaders (boot/platform/app).
> 
> Testing: tiers1-4 in progress. I also verified that the bug reported by Mandy is no longer reproducible after I applied this patch on her branch.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @AlanBateman comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3992/files
  - new: https://git.openjdk.java.net/jdk/pull/3992/files/ebaa6614..8067306a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3992&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3992&range=00-01

  Stats: 8 lines in 2 files changed: 5 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3992.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3992/head:pull/3992

PR: https://git.openjdk.java.net/jdk/pull/3992

From iklam at openjdk.java.net  Wed May 12 18:23:27 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 12 May 2021 18:23:27 GMT
Subject: RFR: 8265605: Cannot call BootLoader::loadClassOrNull before
 initPhase2
In-Reply-To: <5Z-hLKzLSdUeUjO5w8WS9PuGfd7se3IAjo18YaUIWEg=.cccb3896-f58f-4f39-838b-f8e4201fc7ea@github.com>
References: <5Z-hLKzLSdUeUjO5w8WS9PuGfd7se3IAjo18YaUIWEg=.cccb3896-f58f-4f39-838b-f8e4201fc7ea@github.com>
Message-ID: 

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 of the archived module graph in the wrong order. Because of unanticipated nesting of `` methods, `BootLoader::SERVICES_CATALOG` becomes empty, causing future `ServiceLoader` operations to fail.
> 
> The fix has 2 parts:
> 
> - `BootLoader::loadClassOrNull` no longer calls `ClassLoaders::bootLoader()`. This avoids triggering the archived module graph initialization. Instead, it makes a direct call to `Classloader::findBootstrapClassOrNull()`. We don't actually need a `ClassLoader` instance for this call, so I changed `Classloader::findBootstrapClassOrNull()` to be a static method.
> - The object returned by `BootLoader::getServicesCatalog()` is now maintained inside `jdk.internal.loader.ClassLoaders`.  Although not strictly required for the fix, this simplifies the initialization of the archived module graph. It also makes the logic consistent for the 3 built-in loaders (boot/platform/app).
> 
> Testing: tiers1-4 in progress. I also verified that the bug reported by Mandy is no longer reproducible after I applied this patch on her branch.

Thanks alam and mandy for you review. I've made the changes suggested by Alan.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3992

From alanb at openjdk.java.net  Wed May 12 18:49:18 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 12 May 2021 18:49:18 GMT
Subject: RFR: 8265605: Cannot call BootLoader::loadClassOrNull before
 initPhase2 [v2]
In-Reply-To: 
References: <5Z-hLKzLSdUeUjO5w8WS9PuGfd7se3IAjo18YaUIWEg=.cccb3896-f58f-4f39-838b-f8e4201fc7ea@github.com>
 
Message-ID: 

On Wed, 12 May 2021 18:23:26 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 of the archived module graph in the wrong order. Because of unanticipated nesting of `` methods, `BootLoader::SERVICES_CATALOG` becomes empty, causing future `ServiceLoader` operations to fail.
>> 
>> The fix has 2 parts:
>> 
>> - `BootLoader::loadClassOrNull` no longer calls `ClassLoaders::bootLoader()`. This avoids triggering the archived module graph initialization. Instead, it makes a direct call to `Classloader::findBootstrapClassOrNull()`. We don't actually need a `ClassLoader` instance for this call, so I changed `Classloader::findBootstrapClassOrNull()` to be a static method.
>> - The object returned by `BootLoader::getServicesCatalog()` is now maintained inside `jdk.internal.loader.ClassLoaders`.  Although not strictly required for the fix, this simplifies the initialization of the archived module graph. It also makes the logic consistent for the 3 built-in loaders (boot/platform/app).
>> 
>> Testing: tiers1-4 in progress. I also verified that the bug reported by Mandy is no longer reproducible after I applied this patch on her branch.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @AlanBateman comments

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:             ArchivedClassLoaders archivedClassLoaders, ClassLoader loader)

Thanks for the update. The formatting on L60 is messed now, can't the ArchivedClassLoaders go on the previous line? I don't have any other comments, it's worked out well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3992

From brian.goetz at oracle.com  Wed May 12 18:57:33 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 12 May 2021 14:57:33 -0400
Subject: JEP draft: Scope Locals
In-Reply-To: 
References: 
Message-ID: 

Scope locals have come together nicely.

I have some vague thoughts on the presentation of the JEP draft.? There 
are (at least) three intertwined things in the motivation:

 ?- ThreadLocal (and ITL especially) were always compromises, and with 
the advent of Loom, have become untenable -- but the need for implicit 
parameters has not gone away
 ?- Scoped locals, because of their effective finality and dynamic 
scoping, offer a programming model that is a better fit for virtual 
threads, but, even in the absence of virtual threads, are an enabler for 
structured concurrency
 ?- The programming model constraints enable a better-performing 
implementation

In reading the draft, these separate motivations seem somewhat tangled.? 
All the words make sense, but a reader has a hard time coming away with 
a clear picture of "so, why did we do this exactly, besides that its 
cool and faster?"

A possible way to untangle this is:

 ?- the underlying use cases: various forms of implicit context 
(transaction context, implicit parameters, leaving breadcrumbs for your 
future self.)
 ?- the existing solution: thread locals.? ThreadLocals are effectively 
mutable per-thread globals.? The unconstrained mutability makes them 
hard to optimize.? ThreadLocals interact poorly with pooled threads.
 ?- Here comes Loom!? We no longer need to pool threads.? So, why are 
TLs not good enough?
 ?- The more constrained programming model of SLs enables two big new 
benefits:
 ?? - structured concurrency, which is applicable to virtual and 
non-virtual threads alike
 ?? - better optimization of inheritance and get operations







On 5/12/2021 10:42 AM, Andrew Haley wrote:
> There's been considerable discussion about scope locals on the loom-dev list,
> and it's now time to open this to a wider audience. This subject is important
> because. although scope locals were motivated by the the needs of Loom, they
> have many potential applications outside that project.
>
> The draft JEP is at
>
> https://bugs.openjdk.java.net/browse/JDK-8263012
>
> I've already received some very helpful suggestions for enhancements to
> the API, and it'll take me a while to work through them all. In particular,
> Paul Sandoz has suggested that I unify the classes Snapshot and Carrier,
> and it will take me some time to understand the consequences of that.
>
> In the meantime, please have a look at the JEP and comment here.
>
>
> For reference, earlier discussions are at
>
> https://mail.openjdk.java.net/pipermail/loom-dev/2021-March/002268.html
> https://mail.openjdk.java.net/pipermail/loom-dev/2021-April/002287.html
> https://mail.openjdk.java.net/pipermail/loom-dev/2021-May/002427.html
>


From javalists at cbfiddle.com  Wed May 12 19:12:20 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Wed, 12 May 2021 12:12:20 -0700
Subject: JEP draft: Scope Locals
In-Reply-To: 
References: 
Message-ID: <8BF4CB1E-D621-4358-A14D-33FE21171537@cbfiddle.com>

From the motivation section:

> So you want to invoke a method X in a library that later calls back into your code. In your callback you need some context, perhaps a transaction ID or some File instances. However, X provides no way to pass a reference through their code into your callback. What are you to do?

When I read this, my first thought was? pass a callback that is bound to the context.

I suppose the example you have in mind has a fixed callback. Is this a common practice? Doesn?t it point to a deficiency in the library API?

Is this feature just a workaround for poorly designed libraries, or are there other examples?

  Alan


From joehw at openjdk.java.net  Wed May 12 19:13:43 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 12 May 2021 19:13:43 GMT
Subject: RFR: 8265248: Implementation Specific Properties: change prefix,
 plus add existing properties [v5]
In-Reply-To: 
References: 
Message-ID: <8Kuv_S--BlIebX3fmU8hCha9H9FHN0EhnMPoFqxOljg=.6fe912d2-e656-43fe-9ed6-c9726f7808e7@github.com>

> Update module summary, add a few existing properties and features into the tables.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  Thanks Roger. Changed to fully qualified names. Also made them align left instead of center

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3644/files
  - new: https://git.openjdk.java.net/jdk/pull/3644/files/466dc3b7..70f634de

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3644&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3644&range=03-04

  Stats: 29 lines in 1 file changed: 0 ins; 0 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3644.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3644/head:pull/3644

PR: https://git.openjdk.java.net/jdk/pull/3644

From plevart at openjdk.java.net  Wed May 12 19:56:56 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Wed, 12 May 2021 19:56:56 GMT
Subject: RFR: 8266310: deadlock while loading the JNI code
In-Reply-To: 
References: 
Message-ID: 

On Tue, 11 May 2021 13:10:30 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 library load operation.
> 
> Problem being fixed:
> 
> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread.
> 
> Proposed fix:
> 
> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method.
> 
> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared.
> 
> Testing:  jtreg and jck testing with no regressions. A new regression test was developed.

Hi Aleksei,
If I understand David Holmes correctly (on the mailing list), there is a concern that using a per-library-name exclusive lock might not be enough to prevent deadlock with class loading lock. You say: "The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread." ... Could you explain a little bit more about this scenario? As I understand the JNI_OnLoad() is called as part of native library loading and at that time the thread that is loading native library holds a nativeLibraryLock(libraryName). Now if JNI_OnLoad() triggers loading of a class, whose signature is being verified in another thread (do you mean: which is already being loaded in another thread?) then JNI_OnLoad() thread will block on classLoadingLock(className). But that is not a dead-lock yet. The loading of a class in another thread now has to attempt to load the same native library that is being loaded in the JNI_OnLoad() thread.
So before the proposed patch it was enough for the other thread which was loading the class to trigger loading of any native library, while after the proposed patch, the deadlock would occur only if it triggered loading of the same native library. Am I correctly assessing the problem?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3976

From rriggs at openjdk.java.net  Wed May 12 19:56:55 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 12 May 2021 19:56:55 GMT
Subject: RFR: 8265248: Implementation Specific Properties: change prefix,
 plus add existing properties [v5]
In-Reply-To: <8Kuv_S--BlIebX3fmU8hCha9H9FHN0EhnMPoFqxOljg=.6fe912d2-e656-43fe-9ed6-c9726f7808e7@github.com>
References: 
 <8Kuv_S--BlIebX3fmU8hCha9H9FHN0EhnMPoFqxOljg=.6fe912d2-e656-43fe-9ed6-c9726f7808e7@github.com>
Message-ID: 

On Wed, 12 May 2021 19:13:43 GMT, Joe Wang  wrote:

>> Update module summary, add a few existing properties and features into the tables.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thanks Roger. Changed to fully qualified names. Also made them align left instead of center

Look good, Thanks

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3644

From lancea at openjdk.java.net  Wed May 12 20:01:54 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 12 May 2021 20:01:54 GMT
Subject: RFR: 8265248: Implementation Specific Properties: change prefix,
 plus add existing properties [v5]
In-Reply-To: <8Kuv_S--BlIebX3fmU8hCha9H9FHN0EhnMPoFqxOljg=.6fe912d2-e656-43fe-9ed6-c9726f7808e7@github.com>
References: 
 <8Kuv_S--BlIebX3fmU8hCha9H9FHN0EhnMPoFqxOljg=.6fe912d2-e656-43fe-9ed6-c9726f7808e7@github.com>
Message-ID: 

On Wed, 12 May 2021 19:13:43 GMT, Joe Wang  wrote:

>> Update module summary, add a few existing properties and features into the tables.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thanks Roger. Changed to fully qualified names. Also made them align left instead of center

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3644

From lance.andersen at oracle.com  Wed May 12 20:12:46 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 12 May 2021 20:12:46 +0000
Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is
 bigger than number of elements we want to insert.
In-Reply-To: 
References: 
Message-ID: <33628260-8393-4417-BEF0-C20F24B81890@oracle.com>

I won?t have time to look at this today, might not be until over the weekend.

On May 12, 2021, at 2:07 PM, Mitsuru Kariya > wrote:

Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases:

1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()`
  The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully.
  (test31)

2. `pos - 1 + length > this.length()`
  The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1
  (test32)

3. `pos == this.length() + 1`
  The original implementation throws `SerialException` but this case should end successfully. *2
  (test33)

Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases:

1. `offset > str.length()`
  The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`.
  (test39)

2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()`
  The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully.
  (test32)

3. `pos - 1 + length > this.length()`
  The original implementaion throws `SerialException` but this case should end successfully. *3
  (test40)

4. `pos == this.length() + 1`
  The original implementaion throws `SerialException` but this case should end successfully. *4
  (test41)

The javadoc has also been modified according to the above.


The items below should  would change the spec change, require a CSR  and should be looked at separately

*1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes."

*2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined."
  So, it should work correctly when pos == length+1 of the BLOB value.

*3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters."

*4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined."
  So, it should work correctly when pos == length+1 of the CLOB value.

-------------

Commit messages:
- 8153490:Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert.

Changes: https://git.openjdk.java.net/jdk/pull/4001/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4001&range=00
 Issue: https://bugs.openjdk.java.net/browse/JDK-8153490
 Stats: 179 lines in 4 files changed: 122 ins; 17 del; 40 mod
 Patch: https://git.openjdk.java.net/jdk/pull/4001.diff
 Fetch: git fetch https://git.openjdk.java.net/jdk pull/4001/head:pull/4001

PR: https://git.openjdk.java.net/jdk/pull/4001

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com




From asemenyuk at openjdk.java.net  Wed May 12 20:43:12 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 12 May 2021 20:43:12 GMT
Subject: RFR: 8266162: Remove JPackage duplicate tests
Message-ID: 

8266162: Remove JPackage duplicate tests

-------------

Commit messages:
 - 8266162: Remove JPackage duplicate tests

Changes: https://git.openjdk.java.net/jdk/pull/4003/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4003&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266162
  Stats: 39 lines in 2 files changed: 39 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4003.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4003/head:pull/4003

PR: https://git.openjdk.java.net/jdk/pull/4003

From michaelkroll at mail.de  Wed May 12 20:49:14 2021
From: michaelkroll at mail.de (Michael Kroll)
Date: Wed, 12 May 2021 22:49:14 +0200
Subject: RFR: 8266972: Use String.concat() in j.l.Class where
 invokedynamic-based String concatenation is not available
In-Reply-To: 
References: 
Message-ID: 

Hello,

just being curious here:
Before we start to change every usage of String+String into String.concat, shouldn't the compiler be so smart to do that for us?
Currently it compiles to invokedynamic if available and to using StringBuilder otherwise. Now why doesn't it compile to String.concat instead of StringBuilder for the case when invokedynamic is not available as target?

greets,
Michael




Am 12. Mai 2021 15:04:21 MESZ schrieb "?????? ???????" :
>Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've
>found out, that in a few of JDK core classes, e.g. in `j.l.Class`
>expressions like `baseName.replace('.', '/') + '/' + name` are not
>compiled into `invokedynamic`-based code, but into one using
>`StringBuilder`. This happens due to some bootstraping issues.
>
>However the code like
>
>private String getSimpleName0() {
>    if (isArray()) {
>        return getComponentType().getSimpleName() + "[]";
>    }
>    //...
>}
>
>can be improved via replacement of `+` with `String.concat()` call.
>
>I've used this benchmark to measure impact:
>
>@State(Scope.Thread)
>@BenchmarkMode(Mode.AverageTime)
>@OutputTimeUnit(TimeUnit.NANOSECONDS)
>@Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
>public class ClassMethodsBenchmark {
>  private final Class arrayClass = Object[].class;
>  private Method descriptorString;
>
>  @Setup
>  public void setUp() throws NoSuchMethodException {
>//fore some reason compiler doesn't allow me to call
>Class.descriptorString() directly
>  descriptorString = Class.class.getDeclaredMethod("descriptorString");
>  }
>
>  @Benchmark
>  public Object descriptorString() throws Exception {
>    return descriptorString.invoke(arrayClass);
>  }
>
>  @Benchmark
>  public Object typeName() {
>    return arrayClass.getTypeName();
>  }
>}
>
>and got those results
>
>                                  Mode  Cnt     Score     Error   Units
>descriptorString                                   avgt   60    91.480
>?   1.839   ns/op
>descriptorString:?gc.alloc.rate.norm               avgt   60   404.008
>?   4.033    B/op
>descriptorString:?gc.churn.G1_Eden_Space           avgt   60  2791.866
>? 181.589  MB/sec
>descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60   401.702
>?  26.047    B/op
>descriptorString:?gc.churn.G1_Survivor_Space       avgt   60     0.003
>?   0.001  MB/sec
>descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ? 10?? 
>            B/op
>descriptorString:?gc.count                         avgt   60   205.000 
>          counts
>descriptorString:?gc.time                          avgt   60   216.000 
>              ms
>
>patched
>                                  Mode  Cnt     Score     Error   Units
>descriptorString                                   avgt   60    65.016
>?   3.446   ns/op
>descriptorString:?gc.alloc.rate                    avgt   60  2844.240
>? 115.719  MB/sec
>descriptorString:?gc.alloc.rate.norm               avgt   60   288.006
>?   0.001    B/op
>descriptorString:?gc.churn.G1_Eden_Space           avgt   60  2832.996
>? 206.939  MB/sec
>descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60   286.955
>?  17.853    B/op
>descriptorString:?gc.churn.G1_Survivor_Space       avgt   60     0.003
>?   0.001  MB/sec
>descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ? 10?? 
>            B/op
>descriptorString:?gc.count                         avgt   60   208.000 
>          counts
>descriptorString:?gc.time                          avgt   60   228.000 
>              ms
>-----------------
>typeName                                           avgt   60    34.273
>?   0.480   ns/op
>typeName:?gc.alloc.rate                            avgt   60  3265.356
>?  45.113  MB/sec
>typeName:?gc.alloc.rate.norm                       avgt   60   176.004
>?   0.001    B/op
>typeName:?gc.churn.G1_Eden_Space                   avgt   60  3268.454
>? 134.458  MB/sec
>typeName:?gc.churn.G1_Eden_Space.norm              avgt   60   176.109
>?   6.595    B/op
>typeName:?gc.churn.G1_Survivor_Space               avgt   60     0.003
>?   0.001  MB/sec
>typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ? 10?? 
>            B/op
>typeName:?gc.count                                 avgt   60   240.000 
>          counts
>typeName:?gc.time                                  avgt   60   255.000 
>              ms
>
>patched
>
>typeName                                           avgt   60    15.787
>?   0.214   ns/op
>typeName:?gc.alloc.rate                            avgt   60  2577.554
>?  32.339  MB/sec
>typeName:?gc.alloc.rate.norm                       avgt   60    64.001
>?   0.001    B/op
>typeName:?gc.churn.G1_Eden_Space                   avgt   60  2574.039
>? 147.774  MB/sec
>typeName:?gc.churn.G1_Eden_Space.norm              avgt   60    63.895
>?   3.511    B/op
>typeName:?gc.churn.G1_Survivor_Space               avgt   60     0.003
>?   0.001  MB/sec
>typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ? 10?? 
>            B/op
>typeName:?gc.count                                 avgt   60   189.000 
>          counts
>typeName:?gc.time                                  avgt   60   199.000 
>              ms
>
>I think this patch is likely to improve reflection operations related
>to arrays.
>
>If one finds this patch useful, then I'll create a ticket to track
>this. Also it'd be nice to have a list of classes, that are compiled in
>the same way as `j.l.Class` (i.e. have no access to `invokedynamic`) so
>I could look into them for other snippets where two String are joined
>so `concat`-based optimization is possible.
>
>Pre-sizing of `StringBuilder` for `Class.gdescriptorString()` and
>`Class.getCanonicalName0()` is one more improvement opportunity here.
>
>-------------
>
>Commit messages:
>- Use String.concat() where invokedynamic-based String concatenation is
>not available
>
>Changes: https://git.openjdk.java.net/jdk/pull/3627/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3627&range=00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8266972
>  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/3627.diff
>Fetch: git fetch https://git.openjdk.java.net/jdk
>pull/3627/head:pull/3627
>
>PR: https://git.openjdk.java.net/jdk/pull/3627

From iklam at openjdk.java.net  Wed May 12 21:03:27 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 12 May 2021 21:03:27 GMT
Subject: RFR: 8265605: Cannot call BootLoader::loadClassOrNull before
 initPhase2 [v3]
In-Reply-To: <5Z-hLKzLSdUeUjO5w8WS9PuGfd7se3IAjo18YaUIWEg=.cccb3896-f58f-4f39-838b-f8e4201fc7ea@github.com>
References: <5Z-hLKzLSdUeUjO5w8WS9PuGfd7se3IAjo18YaUIWEg=.cccb3896-f58f-4f39-838b-f8e4201fc7ea@github.com>
Message-ID: <4P_OjNotZvZHiygB3Mtil26iP1eGiMAUJMKaPEzIINw=.6730184c-315e-46f6-956e-ef6f737e666d@github.com>

> 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 of the archived module graph in the wrong order. Because of unanticipated nesting of `` methods, `BootLoader::SERVICES_CATALOG` becomes empty, causing future `ServiceLoader` operations to fail.
> 
> The fix has 2 parts:
> 
> - `BootLoader::loadClassOrNull` no longer calls `ClassLoaders::bootLoader()`. This avoids triggering the archived module graph initialization. Instead, it makes a direct call to `Classloader::findBootstrapClassOrNull()`. We don't actually need a `ClassLoader` instance for this call, so I changed `Classloader::findBootstrapClassOrNull()` to be a static method.
> - The object returned by `BootLoader::getServicesCatalog()` is now maintained inside `jdk.internal.loader.ClassLoaders`.  Although not strictly required for the fix, this simplifies the initialization of the archived module graph. It also makes the logic consistent for the 3 built-in loaders (boot/platform/app).
> 
> Testing: tiers1-4 in progress. I also verified that the bug reported by Mandy is no longer reproducible after I applied this patch on her branch.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  cleaned up ClassLoaders.setArchivedServicesCatalog

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3992/files
  - new: https://git.openjdk.java.net/jdk/pull/3992/files/8067306a..4cd981c0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3992&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3992&range=01-02

  Stats: 7 lines in 1 file changed: 0 ins; 2 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3992.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3992/head:pull/3992

PR: https://git.openjdk.java.net/jdk/pull/3992

From iklam at openjdk.java.net  Wed May 12 21:03:28 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 12 May 2021 21:03:28 GMT
Subject: RFR: 8265605: Cannot call BootLoader::loadClassOrNull before
 initPhase2 [v2]
In-Reply-To: 
References: <5Z-hLKzLSdUeUjO5w8WS9PuGfd7se3IAjo18YaUIWEg=.cccb3896-f58f-4f39-838b-f8e4201fc7ea@github.com>
 
 
Message-ID: 

On Wed, 12 May 2021 18:46:20 GMT, Alan Bateman  wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @AlanBateman comments
>
> 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:             ArchivedClassLoaders archivedClassLoaders, ClassLoader loader)
> 
> Thanks for the update. The formatting on L60 is messed now, can't the ArchivedClassLoaders go on the previous line? I don't have any other comments, it's worked out well.

How about the latest version (4cd981c)? I removed the `archivedClassLoaders` argument; this also makes the callers simpler.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3992

From ayang at openjdk.java.net  Wed May 12 21:16:57 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 12 May 2021 21:16:57 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 May 2021 08:28:43 GMT, Kim Barrett  wrote:

>> Please review this change to the String Deduplication facility.  It is being
>> changed to use OopStorage to hold weak references to relevant objects,
>> rather than bespoke data structures requiring dedicated processing phases by
>> supporting GCs.
>> 
>> (The Shenandoah update was contributed by Zhengyu Gu.)
>> 
>> This change significantly simplifies the interface between a given GC and
>> the String Deduplication facility, which should make it much easier for
>> other GCs to opt in.  However, this change does not alter the set of GCs
>> providing support; currently only G1 and Shenandoah support string
>> deduplication.  Adding support by other GCs will be in followup RFEs.
>> 
>> Reviewing via the diffs might not be all that useful for some parts, as
>> several files have been essentially completely replaced, and a number of
>> files have been added or eliminated.  The full webrev might be a better
>> place to look.
>> 
>> The major changes are in gc/shared/stringdedup/* and in the supporting
>> collectors, but there are also some smaller changes in other places, most
>> notably classfile/{stringTable,javaClasses}.
>> 
>> This change is additionally labeled for review by core-libs, although there
>> are no source changes there.  This change injects a byte field of bits into
>> java.lang.String, using one of the previously unused padding bytes in that
>> class.  (There were two unused bytes, now only one.)
>> 
>> Testing:
>> mach5 tier1-2 with and without -XX:+UseStringDeduplication
>> 
>> Locally (linux-x64) ran all of the existing tests that use string
>> deduplication with both G1 and Shenandoah.  Note that
>> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
>> currently fails, for reasons I haven't figured out but suspect are test
>> related.
>> 
>> - gc/stringdedup/   -- these used to be in gc/g1
>> - runtime/cds/SharedStringsDedup.java
>> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
>> - runtime/cds/appcds/sharedStrings/*
>> 
>> shenandoah-only:
>> - gc/shenandoah/jvmti/TestHeapDump.java
>> - gc/shenandoah/TestStringDedup.java
>> - gc/shenandoah/TestStringDedupStress.java
>> 
>> Performance tested baseline, baseline + stringdedup, new with stringdedup,
>> finding no significant differences.
>
> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - more comment improvements
>  - improve naming and comments around injected String flags
>  - fix some typos in comments

Just some minor comments.

src/hotspot/share/gc/shared/stringdedup/stringDedup.cpp line 171:

> 169:   // Store the string in the next pre-allocated storage entry.
> 170:   oop* ref = _buffer[--_index];
> 171:   _buffer[_index] = nullptr;

It's not really needed to clear the slot with null, right?

src/hotspot/share/gc/shared/stringdedup/stringDedupProcessor.cpp line 51:

> 49: }
> 50: 
> 51: StringDedup::Processor::~Processor() {}

Why the empty destructor? Could we just not have it?

src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 92:

> 90:   GrowableArrayCHeap _values;
> 91: 
> 92:   void adjust_capacity(int new_length);

Nit: diff arg name in declaration and implementation, `new_length` vs `new_capacity`.

src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 295:

> 293: 
> 294: protected:
> 295:   CleanupState() {}

Is it possible to use `= default` here? Just like the destructor.

src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 314:

> 312:   size_t _bucket_index;
> 313:   size_t _shrink_index;
> 314:   bool _grow_only;

Seems unused.

src/hotspot/share/memory/universe.cpp line 1153:

> 1151:     ResolvedMethodTable::verify();
> 1152:   }
> 1153:   if (should_verify_subset(Verify_StringDedup) && StringDedup::is_enabled()) {

Maybe drop the `is_enabled()` check in the `if` to keep the consistency with other `if`s?

-------------

Marked as reviewed by ayang (Committer).

PR: https://git.openjdk.java.net/jdk/pull/3662

From vlivanov at openjdk.java.net  Wed May 12 21:23:55 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 12 May 2021 21:23:55 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: 
References: 
 
 
 
Message-ID: <7uT8QeliCJCdi6fuk24JACjroSETna9Y9QxZXep8hMA=.5a392651-605e-48b9-b20f-09b2014d42da@github.com>

On Wed, 12 May 2021 14:53:39 GMT, Jorn Vernee  wrote:

>> src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp line 472:
>> 
>>> 470:   __ block_comment("} preserve_callee_saved_regs ");
>>> 471: 
>>> 472:   // TODO mxcsr
>> 
>> Anything left to do with mxcsr?
>
> I guess this slipped through with the initial PR.
> 
> JNI code loads the default value of mxcsr here and saves/restores the incoming native value: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#L265-L298
> 
> However, it does nothing on Windows, while the Windows x64 ABI also defines mxcsr to have a non-volatile portion (i.e. that should be saved and restored): https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-160#mxcsr
> 
> I think this made me a bit unsure about the need for saving and restoring mxcsr, and wanted to find an actual test case that causes a problem, rather than just copy-pasting the code (or at least understand it a bit better). But, at this time I haven't gotten to that yet.

Thanks for the pointers. It would be safer for now to align the behavior with the call stub.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From mchung at openjdk.java.net  Wed May 12 22:24:12 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 12 May 2021 22:24:12 GMT
Subject: RFR: 8265605: Cannot call BootLoader::loadClassOrNull before
 initPhase2 [v2]
In-Reply-To: 
References: <5Z-hLKzLSdUeUjO5w8WS9PuGfd7se3IAjo18YaUIWEg=.cccb3896-f58f-4f39-838b-f8e4201fc7ea@github.com>
 
 
 
Message-ID: <3zn1qmGNAYIoiXJj73wIjautB_Uef0NWOW3rsUHXXdQ=.aab2a125-09a7-45fb-9e5b-2be949321033@github.com>

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:             ArchivedClassLoaders archivedClassLoaders, ClassLoader loader)
>> 
>> Thanks for the update. The formatting on L60 is messed now, can't the ArchivedClassLoaders go on the previous line? I don't have any other comments, it's worked out well.
>
> How about the latest version (4cd981c)? I removed the `archivedClassLoaders` argument; this also makes the callers simpler.

Looks good to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3992

From mchung at openjdk.java.net  Wed May 12 22:34:55 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 12 May 2021 22:34:55 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]
In-Reply-To: 
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 
Message-ID: 

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 of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test changes and small fixes

Overall looks good to me.

src/hotspot/share/classfile/classLoaderData.cpp line 299:

> 297: }
> 298: 
> 299: // Weak hidden classes have their own ClassLoaderData that is marked to keep alive

`s/Weak/Non-strong/`

test/hotspot/jtreg/runtime/HiddenClasses/StressHiddenClasses.java line 39:

> 37: import jdk.test.lib.compiler.InMemoryJavaCompiler;
> 38: 
> 39: public class StressHiddenClasses {

Since `StressClassLoadingTest` is revised to test hidden class, this test is a subset of it.
I think this can be removed as JDK-8265694 suggests.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3974

From claes.redestad at oracle.com  Wed May 12 22:45:13 2021
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 13 May 2021 00:45:13 +0200
Subject: RFR: 8266972: Use String.concat() in j.l.Class where
 invokedynamic-based String concatenation is not available
In-Reply-To: 
References: 
 
Message-ID: 

Hi,

I gave this some thought the other day when looking at one of Sergey's
patches.

I'm no expert on javac but I think translating to String::concat is
likely to be a bit harder than it seems. It's not a static method, so
the left hand side must be non-null. This is something I believe javac
can't prove in the general case. Corner cases such as when the left
hand side is a String literal, of course, but that would be of limited
utility.

There are more convoluted solutions that might work if one squints (add
public static concat methods and translate calls into those?), but the
question we need to be asking ourselves is really if it is worth our
time - and the added complexity? The answer is likely no.

It might help some if you're targeting java 8 or using javac as a
frontend for non-JVM targets (lol!), but going forward I think it would
mostly help java.base and a few other JDK modules where the
invokedynamic translation can't be used due bootstrapping issues. And in
most of those cases it won't really matter for performance anyhow.

That's why I think using String::concat on a case-by-case basis in those
few OpenJDK modules where indified string concat is not applicable is
enough. When we see that it helps. And then only sparingly.

Hope this clarifies how I reason about this.

/Claes


On 2021-05-12 22:49, Michael Kroll wrote:
> Hello,
> 
> just being curious here:
> Before we start to change every usage of String+String into String.concat, shouldn't the compiler be so smart to do that for us?
> Currently it compiles to invokedynamic if available and to using StringBuilder otherwise. Now why doesn't it compile to String.concat instead of StringBuilder for the case when invokedynamic is not available as target?
> 
> greets,
> Michael
> 
> 
> 
> 
> Am 12. Mai 2021 15:04:21 MESZ schrieb "?????? ???????" :
>> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've
>> found out, that in a few of JDK core classes, e.g. in `j.l.Class`
>> expressions like `baseName.replace('.', '/') + '/' + name` are not
>> compiled into `invokedynamic`-based code, but into one using
>> `StringBuilder`. This happens due to some bootstraping issues.
>>
>> However the code like
>>
>> private String getSimpleName0() {
>>     if (isArray()) {
>>         return getComponentType().getSimpleName() + "[]";
>>     }
>>     //...
>> }
>>
>> can be improved via replacement of `+` with `String.concat()` call.
>>
>> I've used this benchmark to measure impact:
>>
>> @State(Scope.Thread)
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
>> public class ClassMethodsBenchmark {
>>   private final Class arrayClass = Object[].class;
>>   private Method descriptorString;
>>
>>   @Setup
>>   public void setUp() throws NoSuchMethodException {
>> //fore some reason compiler doesn't allow me to call
>> Class.descriptorString() directly
>>   descriptorString = Class.class.getDeclaredMethod("descriptorString");
>>   }
>>
>>   @Benchmark
>>   public Object descriptorString() throws Exception {
>>     return descriptorString.invoke(arrayClass);
>>   }
>>
>>   @Benchmark
>>   public Object typeName() {
>>     return arrayClass.getTypeName();
>>   }
>> }
>>
>> and got those results
>>
>>                                   Mode  Cnt     Score     Error   Units
>> descriptorString                                   avgt   60    91.480
>> ?   1.839   ns/op
>> descriptorString:?gc.alloc.rate.norm               avgt   60   404.008
>> ?   4.033    B/op
>> descriptorString:?gc.churn.G1_Eden_Space           avgt   60  2791.866
>> ? 181.589  MB/sec
>> descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60   401.702
>> ?  26.047    B/op
>> descriptorString:?gc.churn.G1_Survivor_Space       avgt   60     0.003
>> ?   0.001  MB/sec
>> descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ? 10??
>>             B/op
>> descriptorString:?gc.count                         avgt   60   205.000
>>           counts
>> descriptorString:?gc.time                          avgt   60   216.000
>>               ms
>>
>> patched
>>                                   Mode  Cnt     Score     Error   Units
>> descriptorString                                   avgt   60    65.016
>> ?   3.446   ns/op
>> descriptorString:?gc.alloc.rate                    avgt   60  2844.240
>> ? 115.719  MB/sec
>> descriptorString:?gc.alloc.rate.norm               avgt   60   288.006
>> ?   0.001    B/op
>> descriptorString:?gc.churn.G1_Eden_Space           avgt   60  2832.996
>> ? 206.939  MB/sec
>> descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60   286.955
>> ?  17.853    B/op
>> descriptorString:?gc.churn.G1_Survivor_Space       avgt   60     0.003
>> ?   0.001  MB/sec
>> descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ? 10??
>>             B/op
>> descriptorString:?gc.count                         avgt   60   208.000
>>           counts
>> descriptorString:?gc.time                          avgt   60   228.000
>>               ms
>> -----------------
>> typeName                                           avgt   60    34.273
>> ?   0.480   ns/op
>> typeName:?gc.alloc.rate                            avgt   60  3265.356
>> ?  45.113  MB/sec
>> typeName:?gc.alloc.rate.norm                       avgt   60   176.004
>> ?   0.001    B/op
>> typeName:?gc.churn.G1_Eden_Space                   avgt   60  3268.454
>> ? 134.458  MB/sec
>> typeName:?gc.churn.G1_Eden_Space.norm              avgt   60   176.109
>> ?   6.595    B/op
>> typeName:?gc.churn.G1_Survivor_Space               avgt   60     0.003
>> ?   0.001  MB/sec
>> typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ? 10??
>>             B/op
>> typeName:?gc.count                                 avgt   60   240.000
>>           counts
>> typeName:?gc.time                                  avgt   60   255.000
>>               ms
>>
>> patched
>>
>> typeName                                           avgt   60    15.787
>> ?   0.214   ns/op
>> typeName:?gc.alloc.rate                            avgt   60  2577.554
>> ?  32.339  MB/sec
>> typeName:?gc.alloc.rate.norm                       avgt   60    64.001
>> ?   0.001    B/op
>> typeName:?gc.churn.G1_Eden_Space                   avgt   60  2574.039
>> ? 147.774  MB/sec
>> typeName:?gc.churn.G1_Eden_Space.norm              avgt   60    63.895
>> ?   3.511    B/op
>> typeName:?gc.churn.G1_Survivor_Space               avgt   60     0.003
>> ?   0.001  MB/sec
>> typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ? 10??
>>             B/op
>> typeName:?gc.count                                 avgt   60   189.000
>>           counts
>> typeName:?gc.time                                  avgt   60   199.000
>>               ms
>>
>> I think this patch is likely to improve reflection operations related
>> to arrays.
>>
>> If one finds this patch useful, then I'll create a ticket to track
>> this. Also it'd be nice to have a list of classes, that are compiled in
>> the same way as `j.l.Class` (i.e. have no access to `invokedynamic`) so
>> I could look into them for other snippets where two String are joined
>> so `concat`-based optimization is possible.
>>
>> Pre-sizing of `StringBuilder` for `Class.gdescriptorString()` and
>> `Class.getCanonicalName0()` is one more improvement opportunity here.
>>
>> -------------
>>
>> Commit messages:
>> - Use String.concat() where invokedynamic-based String concatenation is
>> not available
>>
>> Changes: https://git.openjdk.java.net/jdk/pull/3627/files
>> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3627&range=00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8266972
>>   Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
>>   Patch: https://git.openjdk.java.net/jdk/pull/3627.diff
>> Fetch: git fetch https://git.openjdk.java.net/jdk
>> pull/3627/head:pull/3627
>>
>> PR: https://git.openjdk.java.net/jdk/pull/3627

From joehw at openjdk.java.net  Thu May 13 01:17:56 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 13 May 2021 01:17:56 GMT
Subject: RFR: 8258795: Update IANA Language Subtag Registry to Version
 2021-05-11
In-Reply-To: 
References: 
Message-ID: 

On Wed, 12 May 2021 16:28:54 GMT, Naoto Sato  wrote:

> Please review the changes to the subject issue. This is to incorporate the latest language subtag registry definition into the JDK.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3998

From almatvee at openjdk.java.net  Thu May 13 02:08:53 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 13 May 2021 02:08:53 GMT
Subject: RFR: 8266162: Remove JPackage duplicate tests
In-Reply-To: 
References: 
Message-ID: 

On Wed, 12 May 2021 20:34:08 GMT, Alexey Semenyuk  wrote:

> 8266162: Remove JPackage duplicate tests

Marked as reviewed by almatvee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4003

From vlivanov at openjdk.java.net  Thu May 13 06:04:00 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 13 May 2021 06:04:00 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 12 May 2021 15:07:37 GMT, Maurizio Cimadamore  wrote:

>> src/hotspot/share/runtime/sharedRuntime.hpp line 465:
>> 
>>> 463:   static void restore_native_result(MacroAssembler *_masm, BasicType ret_type, int frame_slots);
>>> 464: 
>>> 465:   static void   move32_64(MacroAssembler* masm, VMRegPair src, VMRegPair dst);
>> 
>> Please, file an RFE to move these declarations to `MacroAssembler`.
>
> There's already an issue for that:
> https://bugs.openjdk.java.net/browse/JDK-8266257
> 
> I've upgraded the description to make it reflect the proposed move a bit more precisely.

Got it. I was confused by the bug synopsis.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From sergei.tsypanov at yandex.ru  Thu May 13 06:19:55 2021
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Thu, 13 May 2021 08:19:55 +0200
Subject: RFR: 8266972: Use String.concat() in j.l.Class where
 invokedynamic-based String concatenation is not available
In-Reply-To: 
References: 
 
Message-ID: <5009221620886795@vla1-c7cd0219e008.qloud-c.yandex.net>

> Before we start to change every usage of String+String into String.concat, shouldn't the compiler be so smart to do that for us?
> Currently it compiles to invokedynamic if available and to using StringBuilder otherwise. Now why doesn't it compile to String.concat instead of StringBuilder for the case when invokedynamic is not available as target?

I think the main reason is that

String str = "smth is " + null;

returns "smth is null" and with current implementation of String.concat()
the same expression throws NPE. See the code of String.concat():

public String concat(String str) {
    if (str.isEmpty()) {
        return this;
    }
    return StringConcatHelper.simpleConcat(this, str);
}

Regards,
Sergey

From alanb at openjdk.java.net  Thu May 13 06:22:54 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 13 May 2021 06:22:54 GMT
Subject: RFR: 8265605: Cannot call BootLoader::loadClassOrNull before
 initPhase2 [v3]
In-Reply-To: <4P_OjNotZvZHiygB3Mtil26iP1eGiMAUJMKaPEzIINw=.6730184c-315e-46f6-956e-ef6f737e666d@github.com>
References: <5Z-hLKzLSdUeUjO5w8WS9PuGfd7se3IAjo18YaUIWEg=.cccb3896-f58f-4f39-838b-f8e4201fc7ea@github.com>
 <4P_OjNotZvZHiygB3Mtil26iP1eGiMAUJMKaPEzIINw=.6730184c-315e-46f6-956e-ef6f737e666d@github.com>
Message-ID: 

On Wed, 12 May 2021 21:03:27 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 of the archived module graph in the wrong order. Because of unanticipated nesting of `` methods, `BootLoader::SERVICES_CATALOG` becomes empty, causing future `ServiceLoader` operations to fail.
>> 
>> The fix has 2 parts:
>> 
>> - `BootLoader::loadClassOrNull` no longer calls `ClassLoaders::bootLoader()`. This avoids triggering the archived module graph initialization. Instead, it makes a direct call to `Classloader::findBootstrapClassOrNull()`. We don't actually need a `ClassLoader` instance for this call, so I changed `Classloader::findBootstrapClassOrNull()` to be a static method.
>> - The object returned by `BootLoader::getServicesCatalog()` is now maintained inside `jdk.internal.loader.ClassLoaders`.  Although not strictly required for the fix, this simplifies the initialization of the archived module graph. It also makes the logic consistent for the 3 built-in loaders (boot/platform/app).
>> 
>> Testing: tiers1-4 in progress. I also verified that the bug reported by Mandy is no longer reproducible after I applied this patch on her branch.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleaned up ClassLoaders.setArchivedServicesCatalog

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3992

From alanb at openjdk.java.net  Thu May 13 06:22:55 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 13 May 2021 06:22:55 GMT
Subject: RFR: 8265605: Cannot call BootLoader::loadClassOrNull before
 initPhase2 [v2]
In-Reply-To: <3zn1qmGNAYIoiXJj73wIjautB_Uef0NWOW3rsUHXXdQ=.aab2a125-09a7-45fb-9e5b-2be949321033@github.com>
References: <5Z-hLKzLSdUeUjO5w8WS9PuGfd7se3IAjo18YaUIWEg=.cccb3896-f58f-4f39-838b-f8e4201fc7ea@github.com>
 
 
 
 <3zn1qmGNAYIoiXJj73wIjautB_Uef0NWOW3rsUHXXdQ=.aab2a125-09a7-45fb-9e5b-2be949321033@github.com>
Message-ID: 

On Wed, 12 May 2021 22:20:53 GMT, Mandy Chung  wrote:

>> How about the latest version (4cd981c)? I removed the `archivedClassLoaders` argument; this also makes the callers simpler.
>
> Looks good to me.

This makes it simpler and much nicer - thank you!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3992

From alanb at openjdk.java.net  Thu May 13 06:24:54 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 13 May 2021 06:24:54 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]
In-Reply-To: 
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 
Message-ID: 

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 of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test changes and small fixes

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3974

From alanb at openjdk.java.net  Thu May 13 06:24:54 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 13 May 2021 06:24:54 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]
In-Reply-To: 
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 
 
 
Message-ID: <26yxlZkGUBDT2wTKQUS9koA7PZPYojY23wJvl7aTAWE=.6ac4247e-b13f-4ed1-b603-6ff1b09f526b@github.com>

On Tue, 11 May 2021 14:11:22 GMT, Harold Seigel  wrote:

>> Can you check test/jdkjava/lang/Class/attributes/ClassAttributesTest.java? It may minimally need a comment to be updated. That's the only additional test that I could find in test/jdk.
>
> Hi Alan,
> Thanks for find this.  I removed the unneeded imports and @modules from GetModulesTest.java and updated the comment in ClassAttributesTest.java.
> Thanks, Harold

Thanks for fixing up these tests, I didn't spot any more in the test/jdk tree.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3974

From dholmes at openjdk.java.net  Thu May 13 07:27:56 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 13 May 2021 07:27:56 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]
In-Reply-To: 
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 
Message-ID: 

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 of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test changes and small fixes

Hi Harold,

Big change! :) This looks good. All the removals of references to unsafe_anonymous were easy enough  to follow.

I didn't realize that cp patching and psuedo-strings were only related to VM anonymous. It is good to see all that code go as well (but hard to see if you got it all :) ). But as per comment below are we sure psuedo-strings can't be used elsewhere?

Thanks,
David

src/hotspot/share/oops/constantPool.hpp line 493:

> 491:   // object into a CONSTANT_String entry of an unsafe anonymous class.
> 492:   // Methods internally created for method handles may also
> 493:   // use pseudo-strings to link themselves to related metaobjects.

Is this comment wrong? Are psuedo-strings not used by anything now?

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3974

From meumertzheim at code-intelligence.com  Thu May 13 08:14:44 2021
From: meumertzheim at code-intelligence.com (Fabian Meumertzheim)
Date: Thu, 13 May 2021 10:14:44 +0200
Subject: Fuzzing the Java core libs
Message-ID: 

I'm one of the maintainers of Jazzer (
https://github.com/CodeIntelligenceTesting/jazzer), a new open-source
fuzzer for the JVM platform. Jazzer has recently been integrated into
Google's OSS-Fuzz (https://google.github.io/oss-fuzz/) to allow for free
continuous fuzzing of important open-source Java projects. Jazzer has
already found over a hundred bugs and eight security issues in libraries
such as Apache Commons, PDFBox and the OWASP json-sanitizer.

Jazzer finds unexpected exceptions and infinite loops by default, but can
also be used to check domain-specific properties such as
decrypt(encrypt(data)) == data. Since it tracks the coverage it achieves
using instrumentation applied by a Java agent, it can synthesize
interesting test data from scratch.

If there is interest from your side, I could set up the Java core libraries
themselves for fuzzing in OSS-Fuzz. Especially the parts that are
frequently applied to untrusted input, such as java.security.* and
javax.imageio.*, would benefit from fuzz tests. I have prepared basic fuzz
tests for some of the classes in these packages at
https://github.com/CodeIntelligenceTesting/oss-fuzz/tree/openjdk/projects/openjdk,
which has already resulted in the first bug report (JDK-8267086).

All I would need from you is:

* a list of email addresses to which the fuzzer findings should be sent
(ideally associated with Google accounts for authentication to full reports
on oss-fuzz.com),
* ideas for additional fuzz tests, in particular those where there are
interesting properties to verify.

The technical questions about setting up the OpenJDK in OSS-Fuzz have
already been resolved (see also
https://github.com/google/oss-fuzz/issues/5757).

If you need more information on OSS-Fuzz or fuzzing in general, I am happy
to help.

Fabian (@fmeum on GitHub)

From Alan.Bateman at oracle.com  Thu May 13 08:51:41 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 13 May 2021 09:51:41 +0100
Subject: Fuzzing the Java core libs
In-Reply-To: 
References: 
Message-ID: <815a5417-aca0-5b9c-70d4-c9571d84fc35@oracle.com>

On 13/05/2021 09:14, Fabian Meumertzheim wrote:
> I'm one of the maintainers of Jazzer (
> https://github.com/CodeIntelligenceTesting/jazzer), a new open-source
> fuzzer for the JVM platform. Jazzer has recently been integrated into
> Google's OSS-Fuzz (https://google.github.io/oss-fuzz/) to allow for free
> continuous fuzzing of important open-source Java projects. Jazzer has
> already found over a hundred bugs and eight security issues in libraries
> such as Apache Commons, PDFBox and the OWASP json-sanitizer.
>
> Jazzer finds unexpected exceptions and infinite loops by default, but can
> also be used to check domain-specific properties such as
> decrypt(encrypt(data)) == data. Since it tracks the coverage it achieves
> using instrumentation applied by a Java agent, it can synthesize
> interesting test data from scratch.
>
> If there is interest from your side, I could set up the Java core libraries
> themselves for fuzzing in OSS-Fuzz. Especially the parts that are
> frequently applied to untrusted input, such as java.security.* and
> javax.imageio.*, would benefit from fuzz tests. I have prepared basic fuzz
> tests for some of the classes in these packages at
> https://github.com/CodeIntelligenceTesting/oss-fuzz/tree/openjdk/projects/openjdk,
> which has already resulted in the first bug report (JDK-8267086).
>
> All I would need from you is:
>
> * a list of email addresses to which the fuzzer findings should be sent
> (ideally associated with Google accounts for authentication to full reports
> on oss-fuzz.com),
> * ideas for additional fuzz tests, in particular those where there are
> interesting properties to verify.
>
> The technical questions about setting up the OpenJDK in OSS-Fuzz have
> already been resolved (see also
> https://github.com/google/oss-fuzz/issues/5757).
>
> If you need more information on OSS-Fuzz or fuzzing in general, I am happy
> to help.
I have one ask. As you mention, sometimes fuzzing will report issues 
issues that may be security issues. It often requires experts in 
particular areas to look at an issue and decide if it a functional or 
security issue. If there is any question mark over an issue then the 
assumption is that it is a security issue until determined otherwise. In 
that context it may not be possible to engage on the mailing lists here 
about these issues. Oracle engineers are strictly prohibited from 
engaging in any discussions on mailing lists about potential 
vulnerability issues. I suspect many other contributors are somewhat 
restricted too but I think everyone is very responsible and knows not to 
discuss sensitive issues that may need patching. So all I ask is that if 
the fuzzer finds issues that may be security issues that they should be 
reported to the vunl-report list [1] and not discussed on the mailing 
list. I'm not suggesting to sign up the vunl-report list for 
notifications of course, but whoever is triaging these issues should 
know how to report issues.

-Alan

[1] https://openjdk.java.net/groups/vulnerability/report

From avoitylov at openjdk.java.net  Thu May 13 08:52:54 2021
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Thu, 13 May 2021 08:52:54 GMT
Subject: RFR: 8266310: deadlock while loading the JNI code
In-Reply-To: 
References: 
Message-ID: 

On Tue, 11 May 2021 13:10:30 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 library load operation.
> 
> Problem being fixed:
> 
> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread.
> 
> Proposed fix:
> 
> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method.
> 
> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared.
> 
> Testing:  jtreg and jck testing with no regressions. A new regression test was developed.

Peter, that's right. It is still possible to have the same pair of objects being locked with per-library lock, namely when a library being loaded explicitly loads a class that requires the same library to be loaded. I think this type of design flaw cannot be solved by changing locking algorithm. It's clearly not the goal of this patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3976

From dfuchs at openjdk.java.net  Thu May 13 08:58:07 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 13 May 2021 08:58:07 GMT
Subject: Integrated: 8263382: java/util/logging/ParentLoggersTest.java failed
 with "checkLoggers: getLoggerNames() returned unexpected loggers"
In-Reply-To: <_VqYCFeIaJBXgJGjxkfIeWsw-ghd84Ugd_f8IDgAqnY=.b72352cc-8e08-43aa-8033-c2788d949c02@github.com>
References: <_VqYCFeIaJBXgJGjxkfIeWsw-ghd84Ugd_f8IDgAqnY=.b72352cc-8e08-43aa-8033-c2788d949c02@github.com>
Message-ID: 

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 causes the LogManager to reparse its configuration and should therefore run in its own VM.

This pull request has now been integrated.

Changeset: 08a5a5c6
Author:    Daniel Fuchs 
URL:       https://git.openjdk.java.net/jdk/commit/08a5a5c6d64db51700d058954d115aa89dbe73be
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8263382: java/util/logging/ParentLoggersTest.java failed with "checkLoggers: getLoggerNames() returned unexpected loggers"

Reviewed-by: bpb, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/3997

From aph at redhat.com  Thu May 13 09:03:53 2021
From: aph at redhat.com (Andrew Haley)
Date: Thu, 13 May 2021 10:03:53 +0100
Subject: JEP draft: Scope Locals
In-Reply-To: <8BF4CB1E-D621-4358-A14D-33FE21171537@cbfiddle.com>
References: 
 <8BF4CB1E-D621-4358-A14D-33FE21171537@cbfiddle.com>
Message-ID: 

On 5/12/21 8:12 PM, Alan Snyder wrote:
> From the motivation section:
> 
>> So you want to invoke a method?|X|?in a library that later calls back into your code. In your callback you need some context, perhaps a transaction ID or some?|File|?instances. However,?|X|?provides no way to pass a reference through their code into your callback. What are you to do?
> 
> When I read this, my first thought was? pass a callback that is bound to the context.
> 
> I suppose the example you have in mind has a fixed callback.

Fixed? It's a callback, of some form.

> Is this a common practice? Doesn?t it point to a deficiency in the library API?

Not necessarily. For example, say you want to give access to a particular
resource (a log stream, say) to trusted callees. Nobody AFAIK passes a log
stream as an explicit argument through business logic because that's just
too much clutter.

> Is this feature just a workaround for poorly designed libraries, or are there other examples?

It's not really about poor design as much as separation of concerns.
Intermediate libraries have no way to know what might need to be passed
to callees, and in many cases it's better isolation if they don't get to
find out. The latter is especially true of passing security permissions.

Also, there is evolution of libraries: with scope locals you don't need
to change library interfaces to add useful capabilities like logging.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From mcimadamore at openjdk.java.net  Thu May 13 09:28:27 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 13 May 2021 09:28:27 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v17]
In-Reply-To: 
References: 
Message-ID: <2Cgk9O0DjEwy44iJXmyVW_n_Q7mb0XABnlx_G8RYH0E=.f849d10a-2c74-48bc-b092-b43e37ae9574@github.com>

> 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://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address CSR comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/6701654c..03662920

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=16
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=15-16

  Stats: 19 lines in 1 file changed: 19 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From meumertzheim at code-intelligence.com  Thu May 13 09:37:08 2021
From: meumertzheim at code-intelligence.com (Fabian Meumertzheim)
Date: Thu, 13 May 2021 11:37:08 +0200
Subject: Fuzzing the Java core libs
In-Reply-To: <815a5417-aca0-5b9c-70d4-c9571d84fc35@oracle.com>
References: 
 <815a5417-aca0-5b9c-70d4-c9571d84fc35@oracle.com>
Message-ID: 

OSS-Fuzz files bugs in a Monorail instance (of https://bugs.chromium.org
fame), which can be used to discuss the issues, but of course doesn't have
to be. Authentication to that Monorail instance as well as to oss-fuzz.com,
which provides additional information on findings and fuzzer performance,
is tied to Google accounts.

All findings (security or not) remain confidential for 90 days (+ a
possibility for a grace period) or until OSS-Fuzz determines that the
finding no longer reproduces against the source repository (i.e., a fix has
been committed).

Does the OpenJDK security workflow rely on commits with purposefully
innocuous messages to the main branch for embargoed security issues? If
that's the case, we should ensure that the OSS-Fuzz policies don't conflict
with the OoenJDK security policies before performing the integration.

On Thu, May 13, 2021, 10:51 Alan Bateman  wrote:

> On 13/05/2021 09:14, Fabian Meumertzheim wrote:
> > I'm one of the maintainers of Jazzer (
> > https://github.com/CodeIntelligenceTesting/jazzer), a new open-source
> > fuzzer for the JVM platform. Jazzer has recently been integrated into
> > Google's OSS-Fuzz (https://google.github.io/oss-fuzz/) to allow for free
> > continuous fuzzing of important open-source Java projects. Jazzer has
> > already found over a hundred bugs and eight security issues in libraries
> > such as Apache Commons, PDFBox and the OWASP json-sanitizer.
> >
> > Jazzer finds unexpected exceptions and infinite loops by default, but can
> > also be used to check domain-specific properties such as
> > decrypt(encrypt(data)) == data. Since it tracks the coverage it achieves
> > using instrumentation applied by a Java agent, it can synthesize
> > interesting test data from scratch.
> >
> > If there is interest from your side, I could set up the Java core
> libraries
> > themselves for fuzzing in OSS-Fuzz. Especially the parts that are
> > frequently applied to untrusted input, such as java.security.* and
> > javax.imageio.*, would benefit from fuzz tests. I have prepared basic
> fuzz
> > tests for some of the classes in these packages at
> >
> https://github.com/CodeIntelligenceTesting/oss-fuzz/tree/openjdk/projects/openjdk
> ,
> > which has already resulted in the first bug report (JDK-8267086).
> >
> > All I would need from you is:
> >
> > * a list of email addresses to which the fuzzer findings should be sent
> > (ideally associated with Google accounts for authentication to full
> reports
> > on oss-fuzz.com),
> > * ideas for additional fuzz tests, in particular those where there are
> > interesting properties to verify.
> >
> > The technical questions about setting up the OpenJDK in OSS-Fuzz have
> > already been resolved (see also
> > https://github.com/google/oss-fuzz/issues/5757).
> >
> > If you need more information on OSS-Fuzz or fuzzing in general, I am
> happy
> > to help.
> I have one ask. As you mention, sometimes fuzzing will report issues
> issues that may be security issues. It often requires experts in
> particular areas to look at an issue and decide if it a functional or
> security issue. If there is any question mark over an issue then the
> assumption is that it is a security issue until determined otherwise. In
> that context it may not be possible to engage on the mailing lists here
> about these issues. Oracle engineers are strictly prohibited from
> engaging in any discussions on mailing lists about potential
> vulnerability issues. I suspect many other contributors are somewhat
> restricted too but I think everyone is very responsible and knows not to
> discuss sensitive issues that may need patching. So all I ask is that if
> the fuzzer finds issues that may be security issues that they should be
> reported to the vunl-report list [1] and not discussed on the mailing
> list. I'm not suggesting to sign up the vunl-report list for
> notifications of course, but whoever is triaging these issues should
> know how to report issues.
>
> -Alan
>
> [1] https://openjdk.java.net/groups/vulnerability/report
>

From mcimadamore at openjdk.java.net  Thu May 13 10:24:57 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 13 May 2021 10:24:57 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v18]
In-Reply-To: 
References: 
Message-ID: 

> 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://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:

 - Take care of remaining references to "Panama"
 - * Replace is_panama_entry_frame() with is_optimized_entry_frame()
   * Replace EntryBlob with OptimizedEntryBlob

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/03662920..3f99cccf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=16-17

  Stats: 45 lines in 15 files changed: 1 ins; 1 del; 43 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Thu May 13 10:55:41 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 13 May 2021 10:55:41 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v19]
In-Reply-To: 
References: 
Message-ID: 

> 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://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Rename is_entry_blob to is_optimized_entry_blob
  Rename as_entry_blob to as_optimized_entry_blob
  Fix misc typos and indentation issues

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/3f99cccf..352c287f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=17-18

  Stats: 12 lines in 7 files changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From vlivanov at openjdk.java.net  Thu May 13 10:55:42 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 13 May 2021 10:55:42 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v19]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 May 2021 10:52:35 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://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename is_entry_blob to is_optimized_entry_blob
>   Rename as_entry_blob to as_optimized_entry_blob
>   Fix misc typos and indentation issues

Marked as reviewed by vlivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From lancea at openjdk.java.net  Thu May 13 11:01:11 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 May 2021 11:01:11 GMT
Subject: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static @Test
 methods
Message-ID: 

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 upcoming jtreg


Best
Lance

-------------

Commit messages:
 - Remove extrawhitespace
 - Update HashesTest for TestNG 7.4

Changes: https://git.openjdk.java.net/jdk/pull/4009/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4009&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266461
  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4009.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4009/head:pull/4009

PR: https://git.openjdk.java.net/jdk/pull/4009

From chegar at openjdk.java.net  Thu May 13 11:08:15 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 13 May 2021 11:08:15 GMT
Subject: RFR: 8266310: deadlock while loading the JNI code
In-Reply-To: 
References: 
Message-ID: 

On Tue, 11 May 2021 13:10:30 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 library load operation.
> 
> Problem being fixed:
> 
> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread.
> 
> Proposed fix:
> 
> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method.
> 
> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared.
> 
> Testing:  jtreg and jck testing with no regressions. A new regression test was developed.

Hi Aleksei, 

As you may know, I looked into a similar issue recently and put together a reproducer [1] (which is probably similar to what you have). The reproducer, run at the time against Oracle 11u, demonstrates the issue on the mainline too, but the deadlock is slightly different.   The reason I mention it here is that the reproducer encounters the issue whether there is an attempt to load the same class or another class ( from the same jar file ).  In fact, the issue is even more general, the problem is with trying to load a class, not already loaded, from a jar further down on the class path ( the class may not even exist, just that it causes the loader to walk the class path up to the jar being verified ).

I filed an issue for this, which may need to be closed as a duplicate depending on the outcome of this PR [2].

[1] https://github.com/ChrisHegarty/deadlock
[2] https://bugs.openjdk.java.net/browse/JDK-8266350

-------------

PR: https://git.openjdk.java.net/jdk/pull/3976

From alanb at openjdk.java.net  Thu May 13 11:14:54 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 13 May 2021 11:14:54 GMT
Subject: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static
 @Test methods
In-Reply-To: 
References: 
Message-ID: 

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 upcoming jtreg
> 
> 
> Best
> Lance

Changes requested by alanb (Reviewer).

test/jdk/tools/jmod/hashes/HashesTest.java line 94:

> 92:         lib= null;
> 93:         builder=null;
> 94:     }

This looks like a workaround. Can you instead see if the fields can be changed to non-final and place the constructor with a method that has the `@BeforeClass` annotation?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4009

From Alan.Bateman at oracle.com  Thu May 13 11:22:17 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 13 May 2021 12:22:17 +0100
Subject: Fuzzing the Java core libs
In-Reply-To: 
References: 
 <815a5417-aca0-5b9c-70d4-c9571d84fc35@oracle.com>
 
Message-ID: <568d8d7e-2dc6-8177-8d16-40c46027d956@oracle.com>

On 13/05/2021 10:37, Fabian Meumertzheim wrote:
> OSS-Fuzz files bugs in a Monorail instance (of 
> https://bugs.chromium.org 
>  
> fame), which can be used to discuss the issues, but of course doesn't 
> have to be. Authentication to that Monorail instance as well as to 
> oss-fuzz.com 
> , 
> which provides additional information on findings and fuzzer 
> performance, is tied to Google accounts.
>
> All findings (security or not) remain confidential for 90 days (+ a 
> possibility for a grace period) or until OSS-Fuzz determines that the 
> finding no longer reproduces against the source repository (i.e., a 
> fix has been committed).
>
> Does the OpenJDK security workflow rely on commits with purposefully 
> innocuous messages to the main branch for embargoed security issues? 
> If that's the case, we should ensure that the OSS-Fuzz policies don't 
> conflict with the OoenJDK security policies before performing the 
> integration.

The workflow is shown on the Vulnerability Group page [1]. There isn't a 
repo that you can test commits on before the publication date.

-Alan

[1] https://openjdk.java.net/groups/vulnerability/

From chegar at openjdk.java.net  Thu May 13 11:27:00 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 13 May 2021 11:27:00 GMT
Subject: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static
 @Test methods
In-Reply-To: 
References: 
Message-ID: 

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 upcoming jtreg
> 
> 
> Best
> Lance

The non-static state in this test class is initialized for each of the static testXXX scenarios. An alternative could be to move said state (four fields) into a static inner class, and have each of the testXXX scenarios create an instance of that class with the test-specific path. That would also allow the addition of the no-args public constructor to HashesTest, and the testXXX methods to be made non-static.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4009

From michaelkroll at mail.de  Thu May 13 11:52:53 2021
From: michaelkroll at mail.de (Michael Kroll)
Date: Thu, 13 May 2021 13:52:53 +0200
Subject: RFR: 8266972: Use String.concat() in j.l.Class where
 invokedynamic-based String concatenation is not available
In-Reply-To: 
References: 
 
 
Message-ID: 

Okay, that makes sense.
Thanks for clarifying.

Greetings,
Michael


Am 13. Mai 2021 00:45:13 MESZ schrieb Claes Redestad :
>Hi,
>
>I gave this some thought the other day when looking at one of Sergey's
>patches.
>
>I'm no expert on javac but I think translating to String::concat is
>likely to be a bit harder than it seems. It's not a static method, so
>the left hand side must be non-null. This is something I believe javac
>can't prove in the general case. Corner cases such as when the left
>hand side is a String literal, of course, but that would be of limited
>utility.
>
>There are more convoluted solutions that might work if one squints (add
>public static concat methods and translate calls into those?), but the
>question we need to be asking ourselves is really if it is worth our
>time - and the added complexity? The answer is likely no.
>
>It might help some if you're targeting java 8 or using javac as a
>frontend for non-JVM targets (lol!), but going forward I think it would
>mostly help java.base and a few other JDK modules where the
>invokedynamic translation can't be used due bootstrapping issues. And
>in
>most of those cases it won't really matter for performance anyhow.
>
>That's why I think using String::concat on a case-by-case basis in
>those
>few OpenJDK modules where indified string concat is not applicable is
>enough. When we see that it helps. And then only sparingly.
>
>Hope this clarifies how I reason about this.
>
>/Claes
>
>
>On 2021-05-12 22:49, Michael Kroll wrote:
>> Hello,
>> 
>> just being curious here:
>> Before we start to change every usage of String+String into
>String.concat, shouldn't the compiler be so smart to do that for us?
>> Currently it compiles to invokedynamic if available and to using
>StringBuilder otherwise. Now why doesn't it compile to String.concat
>instead of StringBuilder for the case when invokedynamic is not
>available as target?
>> 
>> greets,
>> Michael
>> 
>> 
>> 
>> 
>> Am 12. Mai 2021 15:04:21 MESZ schrieb "?????? ???????"
>:
>>> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464
>I've
>>> found out, that in a few of JDK core classes, e.g. in `j.l.Class`
>>> expressions like `baseName.replace('.', '/') + '/' + name` are not
>>> compiled into `invokedynamic`-based code, but into one using
>>> `StringBuilder`. This happens due to some bootstraping issues.
>>>
>>> However the code like
>>>
>>> private String getSimpleName0() {
>>>     if (isArray()) {
>>>         return getComponentType().getSimpleName() + "[]";
>>>     }
>>>     //...
>>> }
>>>
>>> can be improved via replacement of `+` with `String.concat()` call.
>>>
>>> I've used this benchmark to measure impact:
>>>
>>> @State(Scope.Thread)
>>> @BenchmarkMode(Mode.AverageTime)
>>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>>> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
>>> public class ClassMethodsBenchmark {
>>>   private final Class arrayClass =
>Object[].class;
>>>   private Method descriptorString;
>>>
>>>   @Setup
>>>   public void setUp() throws NoSuchMethodException {
>>> //fore some reason compiler doesn't allow me to call
>>> Class.descriptorString() directly
>>>   descriptorString =
>Class.class.getDeclaredMethod("descriptorString");
>>>   }
>>>
>>>   @Benchmark
>>>   public Object descriptorString() throws Exception {
>>>     return descriptorString.invoke(arrayClass);
>>>   }
>>>
>>>   @Benchmark
>>>   public Object typeName() {
>>>     return arrayClass.getTypeName();
>>>   }
>>> }
>>>
>>> and got those results
>>>
>>>                                   Mode  Cnt     Score     Error  
>Units
>>> descriptorString                                   avgt   60   
>91.480
>>> ?   1.839   ns/op
>>> descriptorString:?gc.alloc.rate.norm               avgt   60  
>404.008
>>> ?   4.033    B/op
>>> descriptorString:?gc.churn.G1_Eden_Space           avgt   60 
>2791.866
>>> ? 181.589  MB/sec
>>> descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60  
>401.702
>>> ?  26.047    B/op
>>> descriptorString:?gc.churn.G1_Survivor_Space       avgt   60    
>0.003
>>> ?   0.001  MB/sec
>>> descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ?
>10??
>>>             B/op
>>> descriptorString:?gc.count                         avgt   60  
>205.000
>>>           counts
>>> descriptorString:?gc.time                          avgt   60  
>216.000
>>>               ms
>>>
>>> patched
>>>                                   Mode  Cnt     Score     Error  
>Units
>>> descriptorString                                   avgt   60   
>65.016
>>> ?   3.446   ns/op
>>> descriptorString:?gc.alloc.rate                    avgt   60 
>2844.240
>>> ? 115.719  MB/sec
>>> descriptorString:?gc.alloc.rate.norm               avgt   60  
>288.006
>>> ?   0.001    B/op
>>> descriptorString:?gc.churn.G1_Eden_Space           avgt   60 
>2832.996
>>> ? 206.939  MB/sec
>>> descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60  
>286.955
>>> ?  17.853    B/op
>>> descriptorString:?gc.churn.G1_Survivor_Space       avgt   60    
>0.003
>>> ?   0.001  MB/sec
>>> descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ?
>10??
>>>             B/op
>>> descriptorString:?gc.count                         avgt   60  
>208.000
>>>           counts
>>> descriptorString:?gc.time                          avgt   60  
>228.000
>>>               ms
>>> -----------------
>>> typeName                                           avgt   60   
>34.273
>>> ?   0.480   ns/op
>>> typeName:?gc.alloc.rate                            avgt   60 
>3265.356
>>> ?  45.113  MB/sec
>>> typeName:?gc.alloc.rate.norm                       avgt   60  
>176.004
>>> ?   0.001    B/op
>>> typeName:?gc.churn.G1_Eden_Space                   avgt   60 
>3268.454
>>> ? 134.458  MB/sec
>>> typeName:?gc.churn.G1_Eden_Space.norm              avgt   60  
>176.109
>>> ?   6.595    B/op
>>> typeName:?gc.churn.G1_Survivor_Space               avgt   60    
>0.003
>>> ?   0.001  MB/sec
>>> typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ?
>10??
>>>             B/op
>>> typeName:?gc.count                                 avgt   60  
>240.000
>>>           counts
>>> typeName:?gc.time                                  avgt   60  
>255.000
>>>               ms
>>>
>>> patched
>>>
>>> typeName                                           avgt   60   
>15.787
>>> ?   0.214   ns/op
>>> typeName:?gc.alloc.rate                            avgt   60 
>2577.554
>>> ?  32.339  MB/sec
>>> typeName:?gc.alloc.rate.norm                       avgt   60   
>64.001
>>> ?   0.001    B/op
>>> typeName:?gc.churn.G1_Eden_Space                   avgt   60 
>2574.039
>>> ? 147.774  MB/sec
>>> typeName:?gc.churn.G1_Eden_Space.norm              avgt   60   
>63.895
>>> ?   3.511    B/op
>>> typeName:?gc.churn.G1_Survivor_Space               avgt   60    
>0.003
>>> ?   0.001  MB/sec
>>> typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ?
>10??
>>>             B/op
>>> typeName:?gc.count                                 avgt   60  
>189.000
>>>           counts
>>> typeName:?gc.time                                  avgt   60  
>199.000
>>>               ms
>>>
>>> I think this patch is likely to improve reflection operations
>related
>>> to arrays.
>>>
>>> If one finds this patch useful, then I'll create a ticket to track
>>> this. Also it'd be nice to have a list of classes, that are compiled
>in
>>> the same way as `j.l.Class` (i.e. have no access to `invokedynamic`)
>so
>>> I could look into them for other snippets where two String are
>joined
>>> so `concat`-based optimization is possible.
>>>
>>> Pre-sizing of `StringBuilder` for `Class.gdescriptorString()` and
>>> `Class.getCanonicalName0()` is one more improvement opportunity
>here.
>>>
>>> -------------
>>>
>>> Commit messages:
>>> - Use String.concat() where invokedynamic-based String concatenation
>is
>>> not available
>>>
>>> Changes: https://git.openjdk.java.net/jdk/pull/3627/files
>>> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3627&range=00
>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8266972
>>>   Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
>>>   Patch: https://git.openjdk.java.net/jdk/pull/3627.diff
>>> Fetch: git fetch https://git.openjdk.java.net/jdk
>>> pull/3627/head:pull/3627
>>>
>>> PR: https://git.openjdk.java.net/jdk/pull/3627

From aleksei.voitylov at bell-sw.com  Thu May 13 11:54:13 2021
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Thu, 13 May 2021 14:54:13 +0300
Subject: RFR: 8266310: deadlock while loading the JNI code
In-Reply-To: <9cca1e8d-d9d9-4bb8-080e-195239023e79@oracle.com>
References: 
 <9cca1e8d-d9d9-4bb8-080e-195239023e79@oracle.com>
Message-ID: <86478a7d-fcf6-df89-0f04-65480bb62fe7@bell-sw.com>

Hi David,

On 12/05/2021 10:56, David Holmes wrote:
> Hi Aleksei,
>
> On 11/05/2021 11:19 pm, 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 library load operation.
>>
>> Problem being fixed:
>>
>> The initial reproducer demonstrated a deadlock between the
>> JarFile/ZipFile and the hash map. That deadlock exists even when the
>> ZipFile/JarFile lock is removed because there's another lock object
>> in the class loader, associated with the name of the class being
>> loaded. Such objects are stored in ClassLoader.parallelLockMap. The
>> deadlock occurs when JNI_OnLoad() loads exactly the same class, whose
>> signature is being verified in another thread.
>>
>> Proposed fix:
>>
>> The proposed patch suggests to get rid of locking loadedLibraryNames
>> hash map and synchronize on each entry name, as it's done with class
>> names in see ClassLoader.getClassLoadingLock(name) method.
>
> The ClassLoader per-name locking map has a number of problems so I'm
> not sure using it as a model is a good idea. In particular your new
> map only grows, with entries never being removed AFAICS.
OK. I'm working on a version of a patch which addresses this concern.
>
> This is a difficult deadlock to solve. Even using a per-entry lock it
> isn't obvious to me that you can't still get a deadlock.

I believe the patch solves the deadlock when different libraries are in
play. Yes, it's still possible to get a deadlock when a library with a
JNI_Onload instantiates a class that requires the same library to be
loaded. Is this a valid use case to begin with for future use and why
such a recursion should be allowed? If not, I'd like to file a CSR for
JNI specification with the intent to forbid such behavior. It's obvious
there are no current users of such behavior because it deadlocks.

>
> My own thoughts on this problem were that we should not be calling
> JNI_OnLoad with any lock held. But that risks use of a library in a
> separate thread before the JNI+OnLoad has completed. As I said this is
> a difficult deadlock to solve - and may not have a complete solution.

Thanks, this is a very appealing idea. While it's true dlopen on Linux
and Mac OS are explicitly marked thread safe (and LoadLibrary on Windows
can probably be assumed so as well, though is not marked so in Microsoft
documentation), all implementations use reference counting techniques,
and the number of calls to open has to be equal to the number of calls
to close. I don't know how to achieve that without locks.

-Aleksei

>
> David
> -----
>
>> The patch introduces nativeLibraryLockMap which holds the lock
>> objects for each library name, and the getNativeLibraryLock() private
>> method is used to lazily initialize the corresponding lock object.
>> nativeLibraryContext was changed to ThreadLocal, so that in any
>> concurrent thread it would have a NativeLibrary object on top of the
>> stack, that's being currently loaded/unloaded in that thread.
>> nativeLibraryLockMap accumulates the names of all native libraries
>> loaded - in line with class loading code, it is not explicitly cleared.
>>
>> Testing:? jtreg and jck testing with no regressions. A new regression
>> test was developed.
>>
>> -------------
>>
>> Commit messages:
>> ? - JDK-8266310: deadlock while loading the JNI code
>> ? - JDK-8266310: deadlock while loading the JNI code
>>
>> Changes: https://git.openjdk.java.net/jdk/pull/3976/files
>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3976&range=00
>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8266310
>> ?? Stats: 475 lines in 6 files changed: 456 ins; 0 del; 19 mod
>> ?? Patch: https://git.openjdk.java.net/jdk/pull/3976.diff
>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk
>> pull/3976/head:pull/3976
>>
>> PR: https://git.openjdk.java.net/jdk/pull/3976
>>


From hseigel at openjdk.java.net  Thu May 13 12:31:48 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 13 May 2021 12:31:48 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]
In-Reply-To: 
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 
 
Message-ID: 

On Wed, 12 May 2021 22:30:30 GMT, Mandy Chung  wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test changes and small fixes
>
> src/hotspot/share/classfile/classLoaderData.cpp line 299:
> 
>> 297: }
>> 298: 
>> 299: // Weak hidden classes have their own ClassLoaderData that is marked to keep alive
> 
> `s/Weak/Non-strong/`

fixed.  thanks for finding it.

> test/hotspot/jtreg/runtime/HiddenClasses/StressHiddenClasses.java line 39:
> 
>> 37: import jdk.test.lib.compiler.InMemoryJavaCompiler;
>> 38: 
>> 39: public class StressHiddenClasses {
> 
> Since `StressClassLoadingTest` is revised to test hidden class, this test is a subset of it.
> I think this can be removed as JDK-8265694 suggests.

Thanks Mandy. I will remove the test as the fix for JDK-8265694 after this change is pushed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3974

From hseigel at openjdk.java.net  Thu May 13 12:31:44 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 13 May 2021 12:31:44 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v5]
In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
Message-ID: <0WaW5NgnyLVdSeN0HAKyHBve4zFSBH_mbLGCa-EqzAM=.c7f0ca4e-106e-4614-83c5-07ee7c1d8c31@github.com>

> 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 of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
> 
> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
> 
> Thanks, Harold

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  fix Weak hidden comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3974/files
  - new: https://git.openjdk.java.net/jdk/pull/3974/files/5246dd76..38675761

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3974.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974

PR: https://git.openjdk.java.net/jdk/pull/3974

From herrick at openjdk.java.net  Thu May 13 12:36:55 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 13 May 2021 12:36:55 GMT
Subject: RFR: 8266162: Remove JPackage duplicate tests
In-Reply-To: 
References: 
Message-ID: 

On Wed, 12 May 2021 20:34:08 GMT, Alexey Semenyuk  wrote:

> 8266162: Remove JPackage duplicate tests

Marked as reviewed by herrick (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4003

From hseigel at openjdk.java.net  Thu May 13 12:38:01 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 13 May 2021 12:38:01 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v5]
In-Reply-To: 
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 
 
Message-ID: 

On Thu, 13 May 2021 07:19:03 GMT, David Holmes  wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix Weak hidden comment
>
> src/hotspot/share/oops/constantPool.hpp line 493:
> 
>> 491:   // object into a CONSTANT_String entry of an unsafe anonymous class.
>> 492:   // Methods internally created for method handles may also
>> 493:   // use pseudo-strings to link themselves to related metaobjects.
> 
> Is this comment wrong? Are psuedo-strings not used by anything now?

Thanks for looking at this.  I discussed pseudo strings with Coleen and we didn't find any use of them besides unsafe.DefineAnonymousClass.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3974

From hseigel at openjdk.java.net  Thu May 13 12:50:40 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 13 May 2021 12:50:40 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v5]
In-Reply-To: <0WaW5NgnyLVdSeN0HAKyHBve4zFSBH_mbLGCa-EqzAM=.c7f0ca4e-106e-4614-83c5-07ee7c1d8c31@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <0WaW5NgnyLVdSeN0HAKyHBve4zFSBH_mbLGCa-EqzAM=.c7f0ca4e-106e-4614-83c5-07ee7c1d8c31@github.com>
Message-ID: 

On Thu, 13 May 2021 12:31:44 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 of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix Weak hidden comment

Thanks Ioi, Alan, Mandy, and David for reviewing this big change!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3974

From hseigel at openjdk.java.net  Thu May 13 12:50:41 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 13 May 2021 12:50:41 GMT
Subject: Integrated: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
Message-ID: 

On Tue, 11 May 2021 12:50:31 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 of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
> 
> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: e14b0268
Author:    Harold Seigel 
URL:       https://git.openjdk.java.net/jdk/commit/e14b0268411bba8eb01bf6c477cc8743a53ffd1c
Stats:     3754 lines in 122 files changed: 75 ins; 3426 del; 253 mod

8243287: Removal of Unsafe::defineAnonymousClass

Reviewed-by: iklam, mchung, alanb, dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/3974

From github.com+10835776+stsypanov at openjdk.java.net  Thu May 13 12:56:23 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 13 May 2021 12:56:23 GMT
Subject: RFR: 8266622: Optimize Class.descriptorString() and
 Class.getCanonicalName0() [v2]
In-Reply-To: 
References: 
Message-ID: 

> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 and https://github.com/openjdk/jdk/pull/2212 it appears, that in `j.l.Class` expressions like
> 
> String str = baseName.replace('.', '/') + '/' + name;
> 
> are not compiled into invokedynamic-based code, but into one using `StringBuilder`.
> 
> This happens due to some bootstraping issues. Currently the bytecode for the last (most often used) branch of `Class.descriptorString()` looks like
> 
> public sb()Ljava/lang/String;
>    L0
>     LINENUMBER 21 L0
>     NEW java/lang/StringBuilder
>     DUP
>     INVOKESPECIAL java/lang/StringBuilder. ()V
>     ASTORE 1
>    L1
>     LINENUMBER 23 L1
>     ALOAD 1
>     LDC "a"
>     INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
>     POP
>    L2
>     LINENUMBER 24 L2
>     ALOAD 1
>     LDC "b"
>     INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
>     POP
>    L3
>     LINENUMBER 26 L3
>     ALOAD 1
>     INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String;
>     ARETURN
> 
> Here the `StringBuilder` is created with default constructor and then expands if necessary while appending. 
> 
> This can be improved by manually allocating `StringBuilder` of exact size. The benchmark demonstrates measurable improvement:
> 
> @State(Scope.Benchmark)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ClassDescriptorStringBenchmark {
> 
>     private final Class clazzWithShortDescriptor = Object.class;
>     private final Class clazzWithLongDescriptor = getClass();
> 
>     @Benchmark
>     public String descriptorString_short() {
>         return clazzWithShortDescriptor.descriptorString();
>     }
> 
>     @Benchmark
>     public String descriptorString_long() {
>         return clazzWithLongDescriptor.descriptorString();
>     }
> }
> 
> 
> 
> original
> -Xint
>                                                Mode     Score     Error   Units
> descriptorString_long                          avgt  6326.478 ? 107.251   ns/op
> descriptorString_short                         avgt  5220.729 ? 103.545   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt   528.089 ?   0.021    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt   232.036 ?   0.015    B/op
> 
> -XX:TieredStopAtLevel=1
>                                                Mode      Score    Error   Units
> descriptorString_long                          avgt    230.223 ?  1.254   ns/op
> descriptorString_short                         avgt    164.255 ?  0.755   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt    528.046 ?  0.002    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt    232.022 ?  0.001    B/op
> 
> full
>                                                Mode      Score     Error   Units
> descriptorString_long                          avgt     74.835 ?   0.262   ns/op
> descriptorString_short                         avgt     43.822 ?   0.788   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt    504.010 ?   0.001    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt    208.004 ?   0.001    B/op
> 
> ------------------------
> patched
> -Xint
>                                                Mode      Score     Error   Units
> descriptorString_long                          avgt   4485.994 ?  60.173   ns/op
> descriptorString_short                         avgt   3949.965 ? 278.143   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt    336.051 ?   0.004    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt    184.027 ?   0.010    B/op
> 
> -XX:TieredStopAtLevel=1
>                                                Mode        Score    Error   Units
> descriptorString_long                          avgt      185.774 ?  1.100   ns/op
> descriptorString_short                         avgt      135.338 ?  1.066   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt      336.030 ?  0.001    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt      184.019 ?  0.001    B/op
> 
> full
>                                                Mode      Score     Error   Units
> descriptorString_long                          avgt     42.864 ?   0.160   ns/op
> descriptorString_short                         avgt     27.255 ?   0.381   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt    224.005 ?   0.001    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt    120.002 ?   0.001    B/op
> 
> Same can be done also for Class.isHidden() branch in Class.descriptorString() and for Class.getCanonicalName0()

?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:

  8266622: Remove pointless String.substring() call

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3903/files
  - new: https://git.openjdk.java.net/jdk/pull/3903/files/7c26095e..641f5273

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3903&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3903&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3903.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3903/head:pull/3903

PR: https://git.openjdk.java.net/jdk/pull/3903

From github.com+10835776+stsypanov at openjdk.java.net  Thu May 13 12:56:24 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 13 May 2021 12:56:24 GMT
Subject: RFR: 8266622: Optimize Class.descriptorString() and
 Class.getCanonicalName0() [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 12 May 2021 10:20:46 GMT, Claes Redestad  wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8266622: Remove pointless String.substring() call
>
> src/java.base/share/classes/java/lang/Class.java line 4377:
> 
>> 4375:                     .append(name.substring(0, index).replace('.', '/'))
>> 4376:                     .append('.')
>> 4377:                     .append(name.substring(index + 1))
> 
> `.append(name, index + 1, name.length())` might be a small win here, but it might be hard to benchmark this branch since it's only for hidden classes.

Indeed, I've measured the case for hidden classes with benchmark

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class HiddenClassBenchmark {
  private Class hiddenClass;

  @Setup
  public void setUp() throws Exception {
    byte[] bytes = getClassWriter().toByteArray();

    hiddenClass = MethodHandles
            .lookup()
            .defineHiddenClass(bytes, true, NESTMATE)
            .lookupClass();

    if (hiddenClass.isHidden()) {
      return;
    }
    throw new RuntimeException();
  }

  @Benchmark
  public String descriptorString() {
    return hiddenClass.descriptorString();
  }

  private static ClassWriter getClassWriter() {
    ClassWriter cw = new ClassWriter(ClassWriter.COMPUTE_MAXS);

    var name = HiddenClassDemo.class.getName().replace('.', '/');
    cw.visit(V1_6, ACC_PUBLIC + ACC_SUPER, name, null, "java/lang/Object", null);
    cw.visitEnd();
    return cw;
  }

  private static class HiddenClassDemo {
  }
}

and got those results:

jdk 16
Benchmark                                                               Mode  Cnt     Score    Error   Units
HiddenClassBenchmark.descriptorString                                   avgt  100   112.591 ?  1.320   ns/op
HiddenClassBenchmark.descriptorString:?gc.alloc.rate.norm               avgt  100   600.045 ?  0.001    B/op

patched

Benchmark                                                               Mode  Cnt     Score    Error   Units
HiddenClassBenchmark.descriptorString                                   avgt  100    85.958 ?  0.561   ns/op
HiddenClassBenchmark.descriptorString:?gc.alloc.rate.norm               avgt  100   448.034 ?  0.001    B/op

patched without substring

Benchmark                                                               Mode  Cnt     Score    Error   Units
HiddenClassBenchmark.descriptorString                                   avgt  100    76.580 ?  0.587   ns/op
HiddenClassBenchmark.descriptorString:?gc.alloc.rate.norm               avgt  100   432.031 ?  0.001    B/op

-------------

PR: https://git.openjdk.java.net/jdk/pull/3903

From david.holmes at oracle.com  Thu May 13 13:05:35 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 13 May 2021 23:05:35 +1000
Subject: RFR: 8266310: deadlock while loading the JNI code
In-Reply-To: <86478a7d-fcf6-df89-0f04-65480bb62fe7@bell-sw.com>
References: 
 <9cca1e8d-d9d9-4bb8-080e-195239023e79@oracle.com>
 <86478a7d-fcf6-df89-0f04-65480bb62fe7@bell-sw.com>
Message-ID: <165946a3-3f16-3250-aa20-814aee31915d@oracle.com>

Hi Aleksei,

On 13/05/2021 9:54 pm, Aleksei Voitylov wrote:
> Hi David,
> 
> On 12/05/2021 10:56, David Holmes wrote:
>> Hi Aleksei,
>>
>> On 11/05/2021 11:19 pm, 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 library load operation.
>>>
>>> Problem being fixed:
>>>
>>> The initial reproducer demonstrated a deadlock between the
>>> JarFile/ZipFile and the hash map. That deadlock exists even when the
>>> ZipFile/JarFile lock is removed because there's another lock object
>>> in the class loader, associated with the name of the class being
>>> loaded. Such objects are stored in ClassLoader.parallelLockMap. The
>>> deadlock occurs when JNI_OnLoad() loads exactly the same class, whose
>>> signature is being verified in another thread.
>>>
>>> Proposed fix:
>>>
>>> The proposed patch suggests to get rid of locking loadedLibraryNames
>>> hash map and synchronize on each entry name, as it's done with class
>>> names in see ClassLoader.getClassLoadingLock(name) method.
>>
>> The ClassLoader per-name locking map has a number of problems so I'm
>> not sure using it as a model is a good idea. In particular your new
>> map only grows, with entries never being removed AFAICS.
> OK. I'm working on a version of a patch which addresses this concern.
>>
>> This is a difficult deadlock to solve. Even using a per-entry lock it
>> isn't obvious to me that you can't still get a deadlock.
> 
> I believe the patch solves the deadlock when different libraries are in
> play. Yes, it's still possible to get a deadlock when a library with a
> JNI_Onload instantiates a class that requires the same library to be
> loaded. Is this a valid use case to begin with for future use and why
> such a recursion should be allowed? If not, I'd like to file a CSR for
> JNI specification with the intent to forbid such behavior. It's obvious
> there are no current users of such behavior because it deadlocks.

So in the current case we have:

Thread 1:
  - loads native lib and acquires load-library lock
  - JNI_Onload tries to initialize class X but can't get the class init lock

Thread 2:
  - initializes class X and has the class init lock
  -  tries to load a native library and can't get the 
load-library lock

If the library lock is finer granularity then we can reduce the risk of 
deadlock but not remove it.

I don't think we can try to forbid anything through the JNI 
specification in such a case. This is really just one of a number of 
class initialization deadlocks that are possible. At most the spec could 
caution against such things, but there is no way to detect it and so 
"forbid" it. And you can construct similar deadlocks without class 
initialization being involved.

>>
>> My own thoughts on this problem were that we should not be calling
>> JNI_OnLoad with any lock held. But that risks use of a library in a
>> separate thread before the JNI+OnLoad has completed. As I said this is
>> a difficult deadlock to solve - and may not have a complete solution.
> 
> Thanks, this is a very appealing idea. While it's true dlopen on Linux
> and Mac OS are explicitly marked thread safe (and LoadLibrary on Windows
> can probably be assumed so as well, though is not marked so in Microsoft
> documentation), all implementations use reference counting techniques,
> and the number of calls to open has to be equal to the number of calls
> to close. I don't know how to achieve that without locks.

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 completely changes the semantics 
of native library loading.

Cheers,
David

> -Aleksei
> 
>>
>> David
>> -----
>>
>>> The patch introduces nativeLibraryLockMap which holds the lock
>>> objects for each library name, and the getNativeLibraryLock() private
>>> method is used to lazily initialize the corresponding lock object.
>>> nativeLibraryContext was changed to ThreadLocal, so that in any
>>> concurrent thread it would have a NativeLibrary object on top of the
>>> stack, that's being currently loaded/unloaded in that thread.
>>> nativeLibraryLockMap accumulates the names of all native libraries
>>> loaded - in line with class loading code, it is not explicitly cleared.
>>>
>>> Testing:? jtreg and jck testing with no regressions. A new regression
>>> test was developed.
>>>
>>> -------------
>>>
>>> Commit messages:
>>>  ? - JDK-8266310: deadlock while loading the JNI code
>>>  ? - JDK-8266310: deadlock while loading the JNI code
>>>
>>> Changes: https://git.openjdk.java.net/jdk/pull/3976/files
>>>  ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3976&range=00
>>>  ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8266310
>>>  ?? Stats: 475 lines in 6 files changed: 456 ins; 0 del; 19 mod
>>>  ?? Patch: https://git.openjdk.java.net/jdk/pull/3976.diff
>>>  ?? Fetch: git fetch https://git.openjdk.java.net/jdk
>>> pull/3976/head:pull/3976
>>>
>>> PR: https://git.openjdk.java.net/jdk/pull/3976
>>>
> 

From jlaskey at openjdk.java.net  Thu May 13 13:46:57 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 13 May 2021 13:46:57 GMT
Subject: Integrated: JDK-8266552 Technical corrections to
 java/util/random/package-info.java
In-Reply-To: 
References: 
Message-ID: 

On Wed, 5 May 2021 12:41:50 GMT, Jim Laskey  wrote:

> The author (Guy Steele) of https://bugs.openjdk.java.net/browse/JDK-8193209 with others have post-integration reviewed commentary (javadoc) and has submitted technical corrections.

This pull request has now been integrated.

Changeset: b4371e9b
Author:    Jim Laskey 
URL:       https://git.openjdk.java.net/jdk/commit/b4371e9bcaa1c8aa394b5eca409c5afc669cc146
Stats:     139 lines in 11 files changed: 10 ins; 20 del; 109 mod

8266552: Technical corrections to java/util/random/package-info.java

Reviewed-by: darcy

-------------

PR: https://git.openjdk.java.net/jdk/pull/3881

From meumertzheim at code-intelligence.com  Thu May 13 13:54:55 2021
From: meumertzheim at code-intelligence.com (Fabian Meumertzheim)
Date: Thu, 13 May 2021 15:54:55 +0200
Subject: Fuzzing the Java core libs
In-Reply-To: <568d8d7e-2dc6-8177-8d16-40c46027d956@oracle.com>
References: 
 <815a5417-aca0-5b9c-70d4-c9571d84fc35@oracle.com>
 
 <568d8d7e-2dc6-8177-8d16-40c46027d956@oracle.com>
Message-ID: 

On Thu, May 13, 2021 at 1:22 PM Alan Bateman 
wrote:

> The workflow is shown on the Vulnerability Group page [1]. There isn't a
> repo that you can test commits on before the publication date.
>
> -Alan
>
> [1] https://openjdk.java.net/groups/vulnerability/
>

Based on the information on that page, there should be no conflict between
the OpenJDK and the OSS-Fuzz policies regarding disclosures (
https://google.github.io/oss-fuzz/getting-started/bug-disclosure-guidelines/
).

Is there anyone who would volunteer to receive the finding reports? Every
report comes with a stack trace and the exact input that reproduces the
finding with the fuzzer, i.e., is immediately actionable.

Examples of such reports for fixed bugs can be found at
https://bugs.chromium.org/p/oss-fuzz/issues/list?q=proj%3A%22json-sanitizer%22%20OR%20proj%3A%22fastjson2%22%20OR%20proj%3A%22jackson-core%22%20OR%20proj%3A%22jackson-dataformats-binary%22%20or%20proj%3A%22apache-commons%22&can=1

From lancea at openjdk.java.net  Thu May 13 14:52:54 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 May 2021 14:52:54 GMT
Subject: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static
 @Test methods
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 May 2021 11:24:34 GMT, Chris Hegarty  wrote:

> The non-static state in this test class is initialized for each of the static testXXX scenarios. An alternative could be to move said state (four fields) into a static inner class, and have each of the testXXX scenarios create an instance of that class with the test-specific path. That would also allow the addition of the no-args public constructor to HashesTest, and the testXXX methods to be made non-static.

I had originally thought about introducing an inner class but decided that given TestNG needs access to  the default constructor, I chose that route vs. doing more of an update.  I can revisit this though

-------------

PR: https://git.openjdk.java.net/jdk/pull/4009

From lancea at openjdk.java.net  Thu May 13 14:52:54 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 May 2021 14:52:54 GMT
Subject: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static
 @Test methods
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 May 2021 11:11:23 GMT, Alan Bateman  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 upcoming jtreg
>> 
>> 
>> Best
>> Lance
>
> test/jdk/tools/jmod/hashes/HashesTest.java line 94:
> 
>> 92:         lib= null;
>> 93:         builder=null;
>> 94:     }
> 
> This looks like a workaround. Can you instead see if the fields can be changed to non-final and place the constructor with a method that has the `@BeforeClass` annotation?

I can look to update the test.  As I mentioned in my reply to Chris, I had thought about introducing an inner class bug decided to go the route of the default/no-arg constructor as it required fewer changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4009

From javalists at cbfiddle.com  Thu May 13 15:59:00 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 13 May 2021 08:59:00 -0700
Subject: JEP draft: Scope Locals
In-Reply-To: 
References: 
 <8BF4CB1E-D621-4358-A14D-33FE21171537@cbfiddle.com>
 
Message-ID: 



> On May 13, 2021, at 2:03 AM, Andrew Haley  wrote:
> 
> On 5/12/21 8:12 PM, Alan Snyder wrote:
>> From the motivation section:
>> 
>>> So you want to invoke a method |X| in a library that later calls back into your code. In your callback you need some context, perhaps a transaction ID or some |File| instances. However, |X| provides no way to pass a reference through their code into your callback. What are you to do?
>> 
>> When I read this, my first thought was? pass a callback that is bound to the context.
>> 
>> I suppose the example you have in mind has a fixed callback.
> 
> Fixed? It's a callback, of some form.
> 

What I meant was that the callback has a larger scope than the method call. Otherwise, you could bind the context to the callback object.


>> Is this a common practice? Doesn?t it point to a deficiency in the library API?
> 
> Not necessarily. For example, say you want to give access to a particular
> resource (a log stream, say) to trusted callees. Nobody AFAIK passes a log
> stream as an explicit argument through business logic because that's just
> too much clutter.
> 

That sounds interesting, but I?m not following how scope locals would be used to solve this problem.


>> Is this feature just a workaround for poorly designed libraries, or are there other examples?
> 
> It's not really about poor design as much as separation of concerns.
> Intermediate libraries have no way to know what might need to be passed
> to callees, and in many cases it's better isolation if they don't get to
> find out. The latter is especially true of passing security permissions.
> 
> Also, there is evolution of libraries: with scope locals you don't need
> to change library interfaces to add useful capabilities like logging.
> 
> -- 
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. 
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> 


From github.com+2217224+kariya-mitsuru at openjdk.java.net  Thu May 13 16:18:47 2021
From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru Kariya)
Date: Thu, 13 May 2021 16:18:47 GMT
Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is
 bigger than number of elements we want to insert. [v2]
In-Reply-To: 
References: 
Message-ID: <-O7P-WxUcM8NR9NxKTkd8HmrTmZhn3bU6hZeMQtrN6c=.55795dd7-c929-4412-aa21-31957b3eadb0@github.com>

> Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases:
> 
> 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()`
>    The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully.
>    (test31)
> 
> 2. `pos - 1 + length > this.length()`
>    The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1
>    (test32)
> 
> 3. `pos == this.length() + 1`
>    The original implementation throws `SerialException` but this case should end successfully. *2
>    (test33)
> 
> 4. `length < 0`
>    The original implementation throws `ArrayIndexOutOfBoundsException` but this case should throw `SerialException`.
>    (test34)
> 
> Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases:
> 
> 1. `offset > str.length()`
>    The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`.
>    (test39)
> 
> 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()`
>    The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully.
>    (test32)
> 
> 3. `pos - 1 + length > this.length()`
>    The original implementaion throws `SerialException` but this case should end successfully. *3
>    (test40)
> 
> 4. `pos == this.length() + 1`
>    The original implementaion throws `SerialException` but this case should end successfully. *4
>    (test41)
> 
> 5. `length < 0`
>    The original implementation throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`.
>    (test42)
> 
> 
> The javadoc has also been modified according to the above.
> 
> *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes."
> 
> *2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined."
>    So, it should work correctly when pos == length+1 of the BLOB value.
> 
> *3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters."
> 
> *4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined."
>    So, it should work correctly when pos == length+1 of the CLOB value.

Mitsuru Kariya has updated the pull request incrementally with one additional commit since the last revision:

  Add check: ensure length >= 0

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4001/files
  - new: https://git.openjdk.java.net/jdk/pull/4001/files/8849de96..6a0cc1ad

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4001&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4001&range=00-01

  Stats: 30 lines in 4 files changed: 30 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4001.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4001/head:pull/4001

PR: https://git.openjdk.java.net/jdk/pull/4001

From naoto at openjdk.java.net  Thu May 13 16:24:06 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 13 May 2021 16:24:06 GMT
Subject: Integrated: 8258795: Update IANA Language Subtag Registry to Version
 2021-05-11
In-Reply-To: 
References: 
Message-ID: <1le7MjJnN23bmuhXodlfBpp4-TrVPToGaH_537MA3JY=.3b9c8503-23e0-4278-9705-4d747a7d7c21@github.com>

On Wed, 12 May 2021 16:28:54 GMT, Naoto Sato  wrote:

> Please review the changes to the subject issue. This is to incorporate the latest language subtag registry definition into the JDK.

This pull request has now been integrated.

Changeset: a259ab4a
Author:    Naoto Sato 
URL:       https://git.openjdk.java.net/jdk/commit/a259ab4a8d163ff924ba56c5da5395cec0d8c350
Stats:     340 lines in 2 files changed: 327 ins; 0 del; 13 mod

8258795: Update IANA Language Subtag Registry to Version 2021-05-11

Reviewed-by: joehw

-------------

PR: https://git.openjdk.java.net/jdk/pull/3998

From asemenyuk at openjdk.java.net  Thu May 13 16:33:58 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 13 May 2021 16:33:58 GMT
Subject: Integrated: 8266162: Remove JPackage duplicate tests
In-Reply-To: 
References: 
Message-ID: <5iccsujicXF2F1kPz98SpofB5kTRGevonKX_vIrxqqA=.f2f0108f-877d-4769-8d89-a581370f3e80@github.com>

On Wed, 12 May 2021 20:34:08 GMT, Alexey Semenyuk  wrote:

> 8266162: Remove JPackage duplicate tests

This pull request has now been integrated.

Changeset: f3c6cda4
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.java.net/jdk/commit/f3c6cda47631cc123dbcddbfb627dc05cf7bc13b
Stats:     39 lines in 2 files changed: 39 ins; 0 del; 0 mod

8266162: Remove JPackage duplicate tests

Reviewed-by: almatvee, herrick

-------------

PR: https://git.openjdk.java.net/jdk/pull/4003

From mchung at openjdk.java.net  Thu May 13 17:01:55 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 13 May 2021 17:01:55 GMT
Subject: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static
 @Test methods
In-Reply-To: 
References: 
Message-ID: <1y9zBD6tJC9kAz7Eq720xmpNqxbniRAaGhQw13jtwJA=.8607942a-afde-40b8-a8ba-023a292abac3@github.com>

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 upcoming jtreg
> 
> 
> Best
> Lance

I also think it's good to fix this properly.    Each test wants to run in an unique directory.    Another solution is to make the fields non-final and add a new `@BeforeMethod` method to generate the unique pathname for each test.   I think this seems a clean way (I sent you a patch to checkout).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4009

From mr at openjdk.java.net  Thu May 13 17:24:10 2021
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 13 May 2021 17:24:10 GMT
Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals
Message-ID: 

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.

-------------

Commit messages:
 - 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals

Changes: https://git.openjdk.java.net/jdk/pull/4015/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4015&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266851
  Stats: 2811 lines in 16 files changed: 0 ins; 2782 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4015.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4015/head:pull/4015

PR: https://git.openjdk.java.net/jdk/pull/4015

From hseigel at openjdk.java.net  Thu May 13 17:41:17 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 13 May 2021 17:41:17 GMT
Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK
 Internals
In-Reply-To: 
References: 
Message-ID: 

On Thu, 13 May 2021 17:14:36 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.

src/hotspot/share/runtime/arguments.cpp line 2434:

> 2432:     // -agentlib and -agentpath
> 2433:     } else if (match_option(option, "-agentlib:", &tail) ||
> 2434:           (is_absolute_path = match_option(option, "-agentpath:", &tail))) {

I think jdk.module.illegalAccess can also be removed from lines 1332 and 2064 of arguments.cpp.
Thanks, Harold

-------------

PR: https://git.openjdk.java.net/jdk/pull/4015

From mr at openjdk.java.net  Thu May 13 18:11:34 2021
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 13 May 2021 18:11:34 GMT
Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK
 Internals [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 May 2021 17:37:42 GMT, Harold Seigel  wrote:

>> Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove stray mentions of the jdk.module.illegalAccess property
>
> src/hotspot/share/runtime/arguments.cpp line 2434:
> 
>> 2432:     // -agentlib and -agentpath
>> 2433:     } else if (match_option(option, "-agentlib:", &tail) ||
>> 2434:           (is_absolute_path = match_option(option, "-agentpath:", &tail))) {
> 
> I think jdk.module.illegalAccess can also be removed from lines 1332 and 2064 of arguments.cpp.
> Thanks, Harold

Good point ? fixed.  Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4015

From mr at openjdk.java.net  Thu May 13 18:11:30 2021
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 13 May 2021 18:11:30 GMT
Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK
 Internals [v2]
In-Reply-To: 
References: 
Message-ID: 

> 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 Reinhold has updated the pull request incrementally with one additional commit since the last revision:

  Remove stray mentions of the jdk.module.illegalAccess property

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4015/files
  - new: https://git.openjdk.java.net/jdk/pull/4015/files/4e2cbf93..719ff4ee

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4015&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4015&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4015.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4015/head:pull/4015

PR: https://git.openjdk.java.net/jdk/pull/4015

From mchung at openjdk.java.net  Thu May 13 18:18:53 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 13 May 2021 18:18:53 GMT
Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK
 Internals [v2]
In-Reply-To: 
References: 
 
Message-ID: 

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 Reinhold has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove stray mentions of the jdk.module.illegalAccess property

There are a few tests with `--illegal-access=deny` for example

test/jdk/java/lang/ModuleTests/BasicModuleTest.java
test/jdk/java/lang/instrument/RedefineModuleTest.java
test/jdk/java/lang/invoke/CallerSensitiveAccess.java
test/jdk/java/lang/reflect/AccessibleObject/ - a few tests
test/jdk/jdk/modules/open/Basic.java
test/jdk/tools/launcher/modules/addexports/manifest/AddExportsAndOpensInManifest.java


It would be good to remove these references to `--illegal-access` option in this patch too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4015

From pedro.lamarao at prodist.com.br  Thu May 13 17:00:37 2021
From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=)
Date: Thu, 13 May 2021 14:00:37 -0300
Subject: JEP draft: Scope Locals
In-Reply-To: 
References: 
 <8BF4CB1E-D621-4358-A14D-33FE21171537@cbfiddle.com>
 
 
Message-ID: 

Em qui., 13 de mai. de 2021 ?s 13:36, Alan Snyder 
escreveu:


> >> Is this a common practice? Doesn?t it point to a deficiency in the
> library API?
> >
> > Not necessarily. For example, say you want to give access to a particular
> > resource (a log stream, say) to trusted callees. Nobody AFAIK passes a
> log
> > stream as an explicit argument through business logic because that's just
> > too much clutter.
> >
>
> That sounds interesting, but I?m not following how scope locals would be
> used to solve this problem.
>

It appears to me that, in this context, scoped locals is inserting itself
inside a hierarchy of "overrides".
We already have mechanisms which provide "context" capable of carrying
"overrides", such as process environment variables and JVM system
properties.
Those are too global for certain uses such as "overriding" a single method
call.
So, in a great hierarchy of "overrides", we would have, from the largest to
the smallest: process environment variables > JVM system properties > *scoped
locals* > method call parameters.
Things like these are recurrent in the design of "I/O cancelability", where
people are always discovering the need for things like "timeout scopes".
It could be argued that "cancelable" APIs must have some "cancellation
token " parameter.
But there are cases where some domain interface, which was never designed
with this in mind, must be implemented over network protocols.
This is the case when you must implement a KeyStore or a Cipher with
remotely managed private keys.
Since you cannot alter KeyStore to pass a "cancellation token" to single
methods, you must insert the token as a sort of "override" thing in some
parallel storage.

-- 
Pedro Lamar?o
https://www.prodist.com.br
Securing Critical Systems
Tel: +55 11 4380-6585

Antes de imprimir esta mensagem e seus anexos, certifique-se que seja
realmente necess?rio.
Proteger o meio ambiente ? nosso dever.
Before printing this e-mail or attachments, be sure it is necessary.
It is in our hands to protect the environment.

From lancea at openjdk.java.net  Thu May 13 18:26:52 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 May 2021 18:26:52 GMT
Subject: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static
 @Test methods [v2]
In-Reply-To: 
References: 
Message-ID: 

> 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 upcoming jtreg
> 
> 
> Best
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Updates based on feedback and additional cleanup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4009/files
  - new: https://git.openjdk.java.net/jdk/pull/4009/files/12c7c4b1..201b9a2b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4009&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4009&range=00-01

  Stats: 182 lines in 1 file changed: 7 ins; 41 del; 134 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4009.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4009/head:pull/4009

PR: https://git.openjdk.java.net/jdk/pull/4009

From lancea at openjdk.java.net  Thu May 13 18:28:55 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 May 2021 18:28:55 GMT
Subject: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static
 @Test methods
In-Reply-To: 
References: 
Message-ID: 

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 upcoming jtreg
> 
> 
> Best
> Lance

The latest commit takes into account the feedback received

> I also think it's good to fix this properly. Each test wants to run in an unique directory. Another solution is to make the fields non-final and add a new `@BeforeMethod` method to generate the unique pathname for each test. I think this seems a clean way (I sent you a patch to checkout).

The latest commit leverages @BeforeMethod vs an inner class and also includes some additional minor cleanup

-------------

PR: https://git.openjdk.java.net/jdk/pull/4009

From lancea at openjdk.java.net  Thu May 13 18:37:21 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 May 2021 18:37:21 GMT
Subject: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static
 @Test methods [v3]
In-Reply-To: 
References: 
Message-ID: 

> 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 upcoming jtreg
> 
> 
> Best
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright typo

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4009/files
  - new: https://git.openjdk.java.net/jdk/pull/4009/files/201b9a2b..a36e9f51

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4009&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4009&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4009.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4009/head:pull/4009

PR: https://git.openjdk.java.net/jdk/pull/4009

From mandy.chung at oracle.com  Thu May 13 18:50:22 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 13 May 2021 11:50:22 -0700
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com>
Message-ID: <79105f52-d0df-b479-1c6c-f0cbf793a624@oracle.com>

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 of the class name containing a slash is 
still valid (I haven't found any of such test though).

Mandy

On 5/11/21 6:20 AM, Brian Goetz wrote:
> There may be some JDK code that checks for anon classes by comparing the name to see if it contains a slash, especially tests, but which don?t say ?anonymous?.  Did you do a search for these idioms too, which are now dead tests?
>
> Sent from my iPad
>
>> On May 11, 2021, at 8:59 AM, 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 of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>>
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>>
>> Thanks, Harold
>>
>> -------------
>>
>> Commit messages:
>> - 8243287: Removal of Unsafe::defineAnonymousClass
>>
>> Changes: https://git.openjdk.java.net/jdk/pull/3974/files
>> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8243287
>>   Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod
>>   Patch: https://git.openjdk.java.net/jdk/pull/3974.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974
>>
>> PR: https://git.openjdk.java.net/jdk/pull/3974


From mchung at openjdk.java.net  Thu May 13 19:00:09 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 13 May 2021 19:00:09 GMT
Subject: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static
 @Test methods [v3]
In-Reply-To: 
References: 
 
Message-ID: 

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 upcoming jtreg
>> 
>> 
>> Best
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright typo

Looks like the imports and whitespace are changed by IDE??   can you please revert these unintentional change.

Otherwise, the change looks good.

test/jdk/tools/jmod/hashes/HashesTest.java line 90:

> 88:         }
> 89:         this.mods = dest.resolve("mods");
> 90:         Path srcDir = dest.resolve("src");

you can just get rid of this local variable and do this in line 92:

     this.builder = new ModuleInfoMaker(dest.resolve("src"));

test/jdk/tools/jmod/hashes/HashesTest.java line 387:

> 385:                 if (hashes != null) {
> 386:                     hashes.names().stream().sorted().forEach(n ->
> 387:                             System.out.format("  %s %s%n", n, toHex(hashes.hashFor(n)))

Nit: the extra whitespaces in line 384 and 387 may be added by IDE.  Can you revert it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4009

From brian.goetz at oracle.com  Thu May 13 19:03:09 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 13 May 2021 15:03:09 -0400
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <79105f52-d0df-b479-1c6c-f0cbf793a624@oracle.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com>
 <79105f52-d0df-b479-1c6c-f0cbf793a624@oracle.com>
Message-ID: <8a888235-84e9-eb72-c709-9060f0862bc1@oracle.com>

Thanks for 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 `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 of the class name containing a slash is 
> still valid (I haven't found any of such test though).
>
> Mandy
>
> On 5/11/21 6:20 AM, Brian Goetz wrote:
>> There may be some JDK code that checks for anon classes by comparing the name to see if it contains a slash, especially tests, but which don?t say ?anonymous?.  Did you do a search for these idioms too, which are now dead tests?
>>
>> Sent from my iPad
>>
>>> On May 11, 2021, at 8:59 AM, 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 of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>>>
>>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>>>
>>> Thanks, Harold
>>>
>>> -------------
>>>
>>> Commit messages:
>>> - 8243287: Removal of Unsafe::defineAnonymousClass
>>>
>>> Changes:https://git.openjdk.java.net/jdk/pull/3974/files
>>> Webrev:https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00
>>>   Issue:https://bugs.openjdk.java.net/browse/JDK-8243287
>>>   Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod
>>>   Patch:https://git.openjdk.java.net/jdk/pull/3974.diff
>>>   Fetch: git fetchhttps://git.openjdk.java.net/jdk  pull/3974/head:pull/3974
>>>
>>> PR:https://git.openjdk.java.net/jdk/pull/3974
>


From dev at anthonyv.be  Thu May 13 19:18:22 2021
From: dev at anthonyv.be (Anthony Vanelverdinghe)
Date: Thu, 13 May 2021 21:18:22 +0200
Subject: =?utf-8?q?Re=3A?= [External] =?utf-8?q?=3A?==?utf-8?q?_Re=3A?= 
 ReversibleCollection proposal
In-Reply-To: <197055291.2061771.1620818563131.JavaMail.zimbra@u-pem.fr>
Message-ID: <2bbe-609d7b80-36b-7314b880@138287482>

Hi R?mi

The discussion "new types? or new default methods?" is indeed a valid one. In fact, I think this choice has already been made once in favor of a default method, when adding `List::sort` was chosen over adding `SortedList` (though I imagine that choice was a no-brainer).

In this case I prefer adding new types though, so I wanted to share my take on this.

In the following diagram (see [1] in case it got mangled), I've tried to arrange all relevant Collection types by their defining characteristics:

|- Collection ---------------------------------------------------------------------------------------------------------------|
|unordered    ordered                                   sorted           distinct    distinct & ordered    distinct & sorted |
|                                                                        Set                                                 |
|             Queue = (get|remove)First + addLast       PriorityQueue                                                        |
|             Stack = (add|get|remove)Last                                                                                   |
|             Deque = Queue + Stack + addFirst                                       LinkedHashSet         SortedSet         |
|             List = Deque + (add|get|remove)Indexed    List::sort                                         NavigableSet      |
|----------------------------------------------------------------------------------------------------------------------------|

As I see it, there are a couple of issues with this:
* conceptually, every List is a Deque, but List doesn't extend Deque. If it would, all uses of List (e.g. as a parameter type in APIs) where the indexed access isn't required could be replaced with Deque instead. Or e.g. when you need to take a stack as argument: currently Deque is the recommended parameter type, but that means you can't just pass a List to the method as-is. With RC, you'd be able to use that as parameter type and pass both Deque and List.
* LinkedHashSet and SortedSet lack a common ancestor which asserts "this is an ordered set". So when defining an API, I'm forced to choose between SortedSet, which is more specific than I want, or List, which is more generic than I want (usually I go with SortedSet, because enforcing something through Javadoc isn't very reliable (cf. Collectors::toList: even though the spec clearly says the result might not be modifiable, people tend to simply assume it is)).

Now with RC/RS these issues would be solved, where RC is ~ Deque + reversed, and RS ~ Deque + distinct + reversed. In terms of the diagram, they group together a bunch of closely-related Collection types (see [1] if needed):

|- Collection ---------------------------------------------------------------------------------------------------------------|
|unordered    ordered                                   sorted           distinct    distinct & ordered    distinct & sorted |
|                                                                        Set                                                 |
|             Queue = (get|remove)First + addLast       PriorityQueue                                                        |
|             Stack = (add|get|remove)Last                                                                                   |
|            |- ReversibleCollection -----------------------------------|           |- ReversibleSet -----------------------||
|            |Deque = Queue + Stack + addFirst                          |           |LinkedHashSet         SortedSet        ||
|            |List = Deque + (add|get|remove)Indexed    List::sort      |           |                      NavigableSet     ||
|            |----------------------------------------------------------|           |---------------------------------------||
|----------------------------------------------------------------------------------------------------------------------------|
 
On Wednesday, May 12, 2021 13:22 CEST, forax at univ-mlv.fr wrote: 
 
> First, i think we have overlooked ReversibleMap, if you have a LinkedHashMap, the keySet should be a ReversibleSet.

I'm not sure what you meant, but the PR already defines `LinkedHashMap::keySet` as `public ReversibleSet keySet()`.

> Again, we have seen that introducing those interfaces
> - is not source backward compatible thus it will be painful for some of our users,
>   I believe NavigableSet/NavigableMap did not have that issue because only one existing implementation per interface was retrofitted to implement those interfaces, TreeSet for NavigableSet and TreeMap for NavigableMap.
>   ConcurrentSkipListSet/ConcurrentSkipListMap were added at the same time, so there was no existing code doing a lub (lowest upper bound) between TreeSet and ConcurrentSkipListSet.
>   Here, they are a lot of implementations that will implement be retrofitted to ReversibleCollection, ReversibleSet and ReversibleMap.

As far as I understand, both options might cause source incompatibilities, but I assume you estimate the actual impact of adding default methods to be (much) smaller?

> - people will have to wait a theoretically infinite time before being to introduce a public method that takes a ReversibleCollection, ReversibleSet and ReversibleMap to their library, because it requires
>   all existing implementations of collection with an order to be retrofitted to implement those interfaces.

I think I'm missing something here. I just did an experiment to convince myself that the set of interfaces a class implements isn't hard-wired in its class file. In other words, that any custom List/Deque/SortedSet/... implementation would be seen as implementing RC/RS without having to recompile it (that, or my experiment was flawed somehow, of course). So am I correct that your concerns are only about custom collections that implement Collection directly? If so, if I'd introduce a public method in my library today, I'd have to declare the parameter as Collection in order for custom collections to be able to use it. So in the future, I could either introduce an overloaded the method (one with a Collection parameter & one with a ReversibleCollection), or I could expect clients to do `List::copyOf`... right? I'd appreciate it if you could elaborate on this point, because I don't understand the concern yet.

> - adding any new interfaces has a real cognitive cost, the collection API is supposed to be simple, does being reversible really worth such new weight.

I believe this is subjective, but to me the new interfaces are like "the missing piece" of the Collections API puzzle. I believe their value is also in the fact that they reconcile List/Deque and LinkedHashSet/SortedSet and are very useful as parameter/return types in APIs.

> > 
> > s'marks
> 
> R?mi

Kind regards, Anthony

[1] https://gist.github.com/anthonyvdotbe/e2e313693f032e4336e5385334a476db


From dev at anthonyv.be  Thu May 13 19:27:08 2021
From: dev at anthonyv.be (Anthony Vanelverdinghe)
Date: Thu, 13 May 2021 21:27:08 +0200
Subject: =?utf-8?q?Re=3A?= ReversibleCollection proposal
In-Reply-To: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
Message-ID: <298b-609d7d80-1a9-66041980@162860758>

Hi Stuart

Will EnumSet also be updated to implement ReversibleSet? Or will it be updated to implement NavigableSet [1] independently of this enhancement?

I'd also like to propose adding `ReversibleSet::of` factory methods. This is something I miss having on SortedSet occasionally, but ReversibleSet would actually be a better fit for such methods.

Kind regards, Anthony

[1] https://bugs.openjdk.java.net/browse/JDK-6278287
 
On Friday, April 16, 2021 19:40 CEST, Stuart Marks  wrote: 
 
> This is a proposal to add a ReversibleCollection interface to the Collections 
> Framework. I'm looking for comments on overall design before I work on detailed 
> specifications and tests. Please send such comments as replies on this email thread.
> 
> Here's a link to a draft PR that contains the code diffs. It's prototype quality, 
> but it should be good enough to build and try out:
> 
>      https://github.com/openjdk/jdk/pull/3533
> 
> And here's a link to a class diagram showing the proposed additions:
> 
>  
> https://cr.openjdk.java.net/~smarks/ReversibleCollection/ReversibleCollectionDiagram.pdf
> 
> Thanks,
> 
> s'marks
> 
> 
> # Ordering and Reversibility
> 
> 
> A long-standing concept that's been missing from collections is that of the 
> positioning, sequencing, or arrangement of elements as a structural property of a 
> collection. (This is sometimes called the "iteration order" of a collection.) For 
> example, a HashSet is not ordered, but a List is. This concept is mostly not 
> manifested in the collections API.
> 
> Iterating a collection produces elements one after another in *some* sequence. The 
> concept of "ordered" determines whether this sequence is defined or whether it's a 
> coincidence of implementation. What does "having an order" mean? It implies that 
> there is a first element and that each element has a successor. Since collections 
> have a finite number of elements, it further implies that there is a last element 
> that has no successor. However, it is difficult to discern whether a collection has 
> a defined order. HashSet generally iterates its elements in the same undefined 
> order, and you can't actually tell that it's not a defined order.
> 
> Streams do have a notion of ordering ("encounter order") and this is preserved, 
> where appropriate, through the stream pipeline. It's possible to detect this by 
> testing whether its spliterator has the ORDERED characteristic. Any collection with 
> a defined order will have a spliterator with this characteristic. However, this is 
> quite a roundabout way to determine whether a collection has a defined order. 
> Furthermore, knowing this doesn't enable any additional operations. It only provides 
> constraints on the stream's implementations (keeping the elements in order) and 
> provides stronger semantics for certain operations. For example, findFirst() on an 
> unordered stream is the same as findAny(), but actually finds the first element if 
> the stream is ordered.
> 
> The concept of ordering is thus present in the system but is surfaced only in a 
> fairly indirect way. We can strengthen abstraction of ordering by making a few 
> observations and considering their implications.
> 
> Given that there is a first element and a last element, the sequence of elements has 
> two ends. It's reasonable to consider operations (add, get, remove) on either end. 
> Indeed, the Deque interface has a full complement of operations at each end. This is 
> an oft-requested feature on various other collections.
> 
> Each element except for the last has a successor, implying that each element except 
> for the first has a predecessor. Thus it's reasonable to consider iterating the 
> elements from first to last or from last to first (that is, in forward or reverse 
> order). Indeed, the concept of iterating in reverse order appears already in bits 
> and pieces in particular places around the collections:
> 
>   - List has indexOf() and lastIndexOf()
>   - Deque has removeFirstOccurrence() and removeLastOccurrence()
>   - List has a ListIterator with hasPrevious/previous methods
>   - Deque and NavigableSet have descendingIterator methods
> 
> Given an ordered collection, though, there's no general way to iterate it in reverse 
> order. Reversed iteration isn't the most common operation, but there are some 
> frequent use cases, such as operating on elements in most-recently-added order. 
> Questions and bug reports about this have come up repeatedly over the years.
> 
> Unfortunately, iterating in reverse order is much harder than iterating in forward 
> order. There are a variety of ways to iterate in forward order. For example, given a 
> List, one can do any of the following:
> 
>      for (var e : list) { ... }
>      list.forEach(...)
>      list.stream()
>      list.toArray()
> 
> However, to iterate a list in reverse order, one must use an explicit loop over 
> ListIterator:
> 
>      for (var it = list.listIterator(list.size()); it.hasPrevious(); ) {
>          var e = it.previous();
>          ...
>      }
> 
> Streaming the elements of a List in reverse order is even worse. One approach would 
> be to implement a reverse-ordered Iterator that wraps a ListIterator and delegates 
> hasNext/next calls to the ListIterator's hasPrevious/previous methods. Then, this 
> Iterator can be turned into a Spliterator, which is then turned into a Stream. (The 
> code to do this is left as an exercise for the reader.) Obtaining the elements in 
> reverse via other means -- forEach() or toArray() -- is similarly difficult.
> 
> Obtaining the elements in reverse order can be accomplished by adopting a concept 
> from NavigableSet's descendingSet() method, which provides a reverse-ordered view 
> collection. This view is also a NavigableSet, which means that any operation that 
> can be performed on the original set can also be applied to the reverse-ordered 
> view. If it were possible to obtain a similar reverse-ordered view on any kind of 
> ordered collection, this would enable the elements to be processed in reverse order 
> in any fashion, not just special-purposes APIs such as ListIterator or 
> descendingIterator().
> 
> 
> # LinkedHashSet
> 
> 
> The main feature of LinkedHashSet is that it does have a defined ordering, as 
> opposed to HashSet, which does not. LinkedHashSet clearly has a first and a last 
> element. However, LinkedHashSet is deficient in a number of ways:
> 
>   - access to and removal of the first element is reasonable (using an iterator) but 
> it is not possible to add at the front
> 
>   - it is possible to add an element at the end, but access to and removal of the 
> last element are expensive
> 
>   - it's not possible to iterate in reverse without copying the entire collection
> 
> Most frustratingly, LinkedHashSet is implemented using a doubly-linked list, so 
> there is no fundamental implementation reason that prevents these operations from 
> being supported. The main reason these operations aren't supported is probably that 
> there hasn't been a good place to push such APIs.
> 
> 
> # Proposal
> 
> 
> Introduce a new ReversibleCollection interface. This provides a new method to 
> obtain a reverse-ordered view. It also contains several methods (copied from Deque) 
> that allow operating on elements at both ends.
> 
> 
>      interface ReversibleCollection extends Collection {
>          ReversibleCollection reversed();
>          default void addFirst(E e)
>          default void addLast(E e)
>          default E getFirst()
>          default E getLast()
>          default E removeFirst()
>          default E removeLast()
>      }
> 
> 
> The List, Deque, and SortedSet interfaces, and the LinkedHashSet class are 
> retrofitted to implement ReversibleCollection. They provide covariant overriding 
> implementations of the reversed() method. For example, List.reversed() returns a 
> List. Default implementations for all of these methods are provided in the 
> appropriate interfaces.
> 
> Covariant overrides are also provided in several other classes. This presents a 
> difficulty for LinkedHashSet, as there's no suitable return type for reversed(). To 
> remedy this, we add another interface
> 
> 
>      interface ReversibleSet extends ReversibleCollection, Set { }
> 
> 
> This adds no new methods but is essentially an intersection of ReversibleCollection 
> and Set. As such, it's suitable as the return type of LinkedHashSet.reversed() and 
> the set views of LinkedHashMap.
> 
> SortedSet::addFirst and addLast throw UnsupportedOperationException. This is because 
> SortedSet's ordering is determined by the comparison method and cannot be controlled 
> explicitly.
> 
> LinkedHashSet::addFirst and addLast add the element at the appropriate position or 
> reposition the element if it is already present in the set.
> 
> New methods are added to LinkedHashMap
> 
>      V putFirst(K, V)
>      V putLast(K, V)
> 
> which put the mapping at the designated position or reposition the mapping if is 
> already present in the map.
> 
> 
> # Design & Implementation Issues
> 
> 
> Covariant overrides for reversed() are provided where possible. However, there is a 
> conflict between List and Deque, as there are examples in the JDK (such as 
> LinkedList) that implement both List and Deque. Since List is much more popular than 
> Deque, I've decided against adding a covariant override to Deque. Instead, a method 
> Deque::reversedDeque is added that returns a Deque, and Deque::reversed returns 
> ReversibleCollection.
> 
> There is no ReversibleMap interface. Most iteration over maps is over the entrySet, 
> keySet, or values views. NavigableMap already has descendingMap(), and LinkedHashMap 
> provides ReversibleX views, which cover most of the cases already.
> 
> Introducing new methods into an interface hierarchy always raises the possibility of 
> name clashes. I've done some searching but I haven't found any major issues, but we 
> should be on the lookout for this. I'll continue to do more searching for such 
> conflicts.
> 
> Introducing covariant overrides on existing methods (notably LinkedHashMap entrySet, 
> keySet, and values) could present incompatibility issues with subclasses that 
> override these methods. I've done some searching and again I haven't found major 
> problems, but this is nonetheless a point of concern. I'll do more searching here, too.
> 
> The default implementations for List::reversed, Deque::reversed, and 
> SortedSet::reversed return reverse-ordered views that are implemented using only 
> public methods of the original interface. This demonstrates the feasibility of 
> retrofitting reverse ordering onto any instance of these interfaces. Similarly, the 
> various add/get/remove methods' default implementations are all implementable in 
> terms of an iterator or reverse-ordered iterator. That said, some concurrent 
> collection implementations will need to override these default implementations in 
> order to preserve their safety invariants. It would probably also be wise to add 
> optimized implementations to the more commonly-used collection implementations.
> 
> Given that a ReversibleCollection has a defined ordering, any spliterator obtained 
> from such a collection should have the Spliterator.ORDERED characteristic.
> 
> This proposal is related to a previous discussion on a similar topic, where Tagir 
> Valeev had proposed OrderedSet and OrderedMap:
> 
>      http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/066028.html
> 
> I think there were some good ideas in there and in the ensuing discussion, but it 
> didn't go anywhere. Several of the concepts in this proposal are an evolution of 
> some ideas discussed in that thread.
> 
> One of the ideas from that thread was to use Deque as a common interface for many 
> collections to support reversibility and operations at the ends. We've abandoned 
> that idea in this proposal. The reasons are that it's cluttered with a bunch of 
> methods that are inherited from Queue. Also, some methods are null-returning instead 
> of throwing, which introduces confusion for collections that can contain nulls.
> 
> # END


From github.com+828220+forax at openjdk.java.net  Thu May 13 19:29:38 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 13 May 2021 19:29:38 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview)
In-Reply-To: 
References: 
Message-ID: 

On Tue, 4 May 2021 16:41:44 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/jep406/jep406-20210430/specs/patterns-switch-jls.html
> 
> A summary of notable parts of the patch:
> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`.
> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods.
> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels.
> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values.
> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later.
> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`.
> 
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 127:

> 125:         Stream.of(labels).forEach(SwitchBootstraps::verifyLabel);
> 126: 
> 127:         return new TypeSwitchCallSite(invocationType, labels);

See why below

  MethodHandle target = MethodHandles.insertArguments(DO_SWITCH, 2, labels);
  return new ConstantCallsite(target);

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 134:

> 132:             throw new IllegalArgumentException("null label found");
> 133:         }
> 134:         if (label.getClass() != Class.class &&

store `label.getClass` in a local variable,
it's too bad that you can no use pattern matching here :)

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 141:

> 139:     }
> 140: 
> 141:     static class TypeSwitchCallSite extends ConstantCallSite {

That's weird, having a callsite extending MutableCallSite is expected but having a callsite extending constant callsite is useless because you can not change it after being constructed.

As an interesting trivia, the VM does not store the CallSite returned by the BSM, but only the target inside it.
So there is no point of keeping a ConstantCallSite around.  

So `doSwitch()` should be static and takes the array of Object[] as parameter, will array will be injected with an insertArguments().

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 157:

> 155:             Class targetClass = target.getClass();
> 156:             for (int i = startIndex; i < labels.length; i++) {
> 157:                 if (labels[i] instanceof Class) {

label[i] should be stored is a local variable and
using `instanceof Class c` (like the other instanceof below) will make the code more readable

-------------

PR: https://git.openjdk.java.net/jdk/pull/3863

From lancea at openjdk.java.net  Thu May 13 19:30:36 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 May 2021 19:30:36 GMT
Subject: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static
 @Test methods [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 May 2021 18:26:52 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 upcoming jtreg
>> 
>> 
>> Best
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates based on feedback and additional cleanup

I can look to revert the imports, that was an optimization via Intellij

-------------

PR: https://git.openjdk.java.net/jdk/pull/4009

From lancea at openjdk.java.net  Thu May 13 19:30:38 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 May 2021 19:30:38 GMT
Subject: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static
 @Test methods [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <3NRPcdvBeHe6IBxzLNBBAgMfgiyMfnuqBR1ZhyJPYCA=.53776007-5a11-4900-8b3f-ca947fabb15a@github.com>

On Thu, 13 May 2021 18:53:25 GMT, Mandy Chung  wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright typo
>
> test/jdk/tools/jmod/hashes/HashesTest.java line 90:
> 
>> 88:         }
>> 89:         this.mods = dest.resolve("mods");
>> 90:         Path srcDir = dest.resolve("src");
> 
> you can just get rid of this local variable and do this in line 92:
> 
>      this.builder = new ModuleInfoMaker(dest.resolve("src"));

Yes I can do that and realized that after I pushed the update

> test/jdk/tools/jmod/hashes/HashesTest.java line 387:
> 
>> 385:                 if (hashes != null) {
>> 386:                     hashes.names().stream().sorted().forEach(n ->
>> 387:                             System.out.format("  %s %s%n", n, toHex(hashes.hashFor(n)))
> 
> Nit: the extra whitespaces in line 384 and 387 may be added by IDE.  Can you revert it.

Intellij did that.  I can tweak

-------------

PR: https://git.openjdk.java.net/jdk/pull/4009

From mandy.chung at oracle.com  Thu May 13 20:37:34 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 13 May 2021 13:37:34 -0700
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <8a888235-84e9-eb72-c709-9060f0862bc1@oracle.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com>
 <79105f52-d0df-b479-1c6c-f0cbf793a624@oracle.com>
 <8a888235-84e9-eb72-c709-9060f0862bc1@oracle.com>
Message-ID: 

Maybe you were thinking 
`jdk.internal.reflect.ReflectUtil::isVMAnonymousClass` that is now 
removed by this patch [1].

[1] 
https://github.com/openjdk/jdk/pull/3974/files#diff-1af3026a3b4942af3ebe6a4df02f8952fb9d51bf93336a2f7f93ce175d047574

On 5/13/21 12:03 PM, Brian Goetz wrote:
> Thanks for 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 `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 of the class name containing a slash is 
>> still valid (I haven't found any of such test though).
>>
>> Mandy
>>
>> On 5/11/21 6:20 AM, Brian Goetz wrote:
>>> There may be some JDK code that checks for anon classes by comparing the name to see if it contains a slash, especially tests, but which don?t say ?anonymous?.  Did you do a search for these idioms too, which are now dead tests?
>>>
>>> Sent from my iPad
>>>
>>>> On May 11, 2021, at 8:59 AM, 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 of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>>>>
>>>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>>>>
>>>> Thanks, Harold
>>>>
>>>> -------------
>>>>
>>>> Commit messages:
>>>> - 8243287: Removal of Unsafe::defineAnonymousClass
>>>>
>>>> Changes:https://git.openjdk.java.net/jdk/pull/3974/files
>>>> Webrev:https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00
>>>>   Issue:https://bugs.openjdk.java.net/browse/JDK-8243287
>>>>   Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod
>>>>   Patch:https://git.openjdk.java.net/jdk/pull/3974.diff
>>>>   Fetch: git fetchhttps://git.openjdk.java.net/jdk  pull/3974/head:pull/3974
>>>>
>>>> PR:https://git.openjdk.java.net/jdk/pull/3974
>>
>


From lancea at openjdk.java.net  Thu May 13 20:38:20 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 May 2021 20:38:20 GMT
Subject: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static
 @Test methods [v4]
In-Reply-To: 
References: 
Message-ID: 

> 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 upcoming jtreg
> 
> 
> Best
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Adjust imports and spacing

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4009/files
  - new: https://git.openjdk.java.net/jdk/pull/4009/files/a36e9f51..2e8f6c97

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4009&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4009&range=02-03

  Stats: 33 lines in 1 file changed: 16 ins; 8 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4009.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4009/head:pull/4009

PR: https://git.openjdk.java.net/jdk/pull/4009

From mchung at openjdk.java.net  Thu May 13 20:53:34 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 13 May 2021 20:53:34 GMT
Subject: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static
 @Test methods [v4]
In-Reply-To: 
References: 
 
Message-ID: 

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 upcoming jtreg
>> 
>> 
>> Best
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust imports and spacing

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4009

From scolebourne at joda.org  Thu May 13 21:05:17 2021
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 13 May 2021 22:05:17 +0100
Subject: Proposal for new interface: TimeSource
In-Reply-To: <6622fc7d-3689-47c7-36ea-0bcb027bc1e0@oracle.com>
References: 
 
 <6622fc7d-3689-47c7-36ea-0bcb027bc1e0@oracle.com>
Message-ID: 

On Wed, 12 May 2021 at 18:41, Roger Riggs  wrote:
> Will you be posting a PR for the implementation?
> It is frequently helpful to evaluate the CSR and the implementation
> concurrently.

PR: https://github.com/openjdk/jdk/pull/4016
Issue: https://bugs.openjdk.java.net/browse/JDK-8266846
CSR: https://bugs.openjdk.java.net/browse/JDK-8266847

The PR takes a middle ground approach to the implementation.

It is not practical to remove the existing package-scoped Clock
implementation classes (SystemClock, TickClock, FixedClock,
OffsetClock) despite the fact that these would be better expressed as
classes that only implement `InstantSource`. However, given that
"system" is the 99%+ use case, I do believe it is worth adding a
dedicated `SystemInstantSource` class, as per the PR.

To achieve this I moved the actual logic using
`VM.getNanoAdjustment()` into a static method which can then be called
directly from three places - Instant.now(), SystemClock and
SystemInstantSource. Previously, every instance of SystemClock
performed the VM/offset calculations separately. The new logic
performs them once based on a single shared static variable. I have no
reason to believe this changes the memory model or performance, but I
must flag it up for reviewers.

When initially discussing the proposal, I planned to add a new static
method `Clock.of(InstantSource, ZoneId)`. When implementing the change
I found that the method was adding no value as the instance method
`InstantSource.withZone(ZoneId)` achieves the same outcome, so I
omitted it.

The Mac test failure appears to be unconnected to the change.

Thanks for any and all reviews!
Stephen

From mandy.chung at oracle.com  Thu May 13 21:20:09 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 13 May 2021 14:20:09 -0700
Subject: RFR: 8266310: deadlock while loading the JNI code
In-Reply-To: <165946a3-3f16-3250-aa20-814aee31915d@oracle.com>
References: 
 <9cca1e8d-d9d9-4bb8-080e-195239023e79@oracle.com>
 <86478a7d-fcf6-df89-0f04-65480bb62fe7@bell-sw.com>
 <165946a3-3f16-3250-aa20-814aee31915d@oracle.com>
Message-ID: <96b76d3f-a1fc-bb2e-195b-7e092b53c59b@oracle.com>



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 completely changes the 
> semantics of native library loading. 

I have been giving some thought on this issue.? I agree with David that 
we should look into a solution not holding a lock while JNI_OnLoad is 
executed.? It might be possible to put all threads that trying to load 
the same native library that is being loaded to wait and only one thread 
is loading it and executing JNI_OnLoad (e.g. add a state in 
NativeLibrary to indicate it is being loaded, already loaded, being 
unloaded).? I haven't had the cycle to think through it in details though.

Mandy

From forax at univ-mlv.fr  Thu May 13 22:15:15 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 14 May 2021 00:15:15 +0200 (CEST)
Subject: [External] : Re:  ReversibleCollection proposal
In-Reply-To: <2bbe-609d7b80-36b-7314b880@138287482>
References: <2bbe-609d7b80-36b-7314b880@138287482>
Message-ID: <477307921.278512.1620944115116.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Anthony Vanelverdinghe" 
> ?: "Remi Forax" 
> Cc: "Stuart Marks" , "core-libs-dev" 
> Envoy?: Jeudi 13 Mai 2021 21:18:22
> Objet: Re: [External] : Re:  ReversibleCollection proposal

> Hi R?mi
> 
> The discussion "new types? or new default methods?" is indeed a valid one. In
> fact, I think this choice has already been made once in favor of a default
> method, when adding `List::sort` was chosen over adding `SortedList` (though I
> imagine that choice was a no-brainer).

yes, very true, there is no SortedList even if it would be useful to know if a list is already sorted, by example, we can add binarySearch() on it with no problem of people using it on an unsorted list.

> 
> In this case I prefer adding new types though, so I wanted to share my take on
> this.
> 
> In the following diagram (see [1] in case it got mangled), I've tried to arrange
> all relevant Collection types by their defining characteristics:
> 
>|- Collection
>|---------------------------------------------------------------------------------------------------------------|
>|unordered    ordered                                   sorted           distinct
>|distinct & ordered    distinct & sorted |
>|                                                                        Set                                                 |
>|             Queue = (get|remove)First + addLast       PriorityQueue
>|             |
>|             Stack = (add|get|remove)Last
>|             |
>|             Deque = Queue + Stack + addFirst
>|             LinkedHashSet         SortedSet         |
>|             List = Deque + (add|get|remove)Indexed    List::sort
>|             NavigableSet      |
>|----------------------------------------------------------------------------------------------------------------------------|
> 
> As I see it, there are a couple of issues with this:
> * conceptually, every List is a Deque, but List doesn't extend Deque. If it
> would, all uses of List (e.g. as a parameter type in APIs) where the indexed
> access isn't required could be replaced with Deque instead. Or e.g. when you
> need to take a stack as argument: currently Deque is the recommended parameter
> type, but that means you can't just pass a List to the method as-is. With RC,
> you'd be able to use that as parameter type and pass both Deque and List.

You can use the same argument to have a common super type between Map and Collection, it would be very useful.

Until you think what methods are available on that type, size() and isEmpty(), meh, this is useless.

RC has the same issue, it's stuck in between Collection and List, so the cases where you don't want a Collection because it has not enough methods you want to use but at the same time you don't want a List because it has too many methods are vanishingly small.

The problem is that adding RC is not source compatible, so you are asking to add something in the JDK which serve a corner case but at the same time forces people to change their code even if they don't use RC.
It's a loose / loose situation, we will have to maintain a collection forever in the JDK that nobody uses but everybody will pay for it.

[...]

> 
> On Wednesday, May 12, 2021 13:22 CEST, forax at univ-mlv.fr wrote:
> 
>> First, i think we have overlooked ReversibleMap, if you have a LinkedHashMap,
>> the keySet should be a ReversibleSet.
> 
> I'm not sure what you meant, but the PR already defines `LinkedHashMap::keySet`
> as `public ReversibleSet keySet()`.

LinkedHashMap is perhaps the only implementation which has a keySet which is reversible, but there are a lot of other collection implementations, Apache collection, Guava, Eclipse, clojure-core, etc that may have such kind of implementation too. The same way you want RC between Queue and List, you want ReversibleMap between those Map implementations.

> 
>> Again, we have seen that introducing those interfaces
>> - is not source backward compatible thus it will be painful for some of our
>> users,
>>   I believe NavigableSet/NavigableMap did not have that issue because only one
>>   existing implementation per interface was retrofitted to implement those
>>   interfaces, TreeSet for NavigableSet and TreeMap for NavigableMap.
>>   ConcurrentSkipListSet/ConcurrentSkipListMap were added at the same time, so
>>   there was no existing code doing a lub (lowest upper bound) between TreeSet and
>>   ConcurrentSkipListSet.
>>   Here, they are a lot of implementations that will implement be retrofitted to
>>   ReversibleCollection, ReversibleSet and ReversibleMap.
> 
> As far as I understand, both options might cause source incompatibilities, but I
> assume you estimate the actual impact of adding default methods to be (much)
> smaller?

Adding a default method may creates source incompatibilities but this can be solved by having a name with no collision, that why Iterator.forEachRemaining is such a long name by example.

Adding a common supertype to at least two already existing types change the inferred type in methods like Array.asList(), List.of() or in Stream so either there is no such problem, which means that nobody wants a supertype between Deque and List, or we have a lot of codes that now fail to compile. In both case, it means we should not add RC.

> 
>> - people will have to wait a theoretically infinite time before being to
>> introduce a public method that takes a ReversibleCollection, ReversibleSet and
>> ReversibleMap to their library, because it requires
>>   all existing implementations of collection with an order to be retrofitted to
>>   implement those interfaces.
> 
> I think I'm missing something here. I just did an experiment to convince myself
> that the set of interfaces a class implements isn't hard-wired in its class
> file. In other words, that any custom List/Deque/SortedSet/... implementation
> would be seen as implementing RC/RS without having to recompile it (that, or my
> experiment was flawed somehow, of course). So am I correct that your concerns
> are only about custom collections that implement Collection directly? If so, if
> I'd introduce a public method in my library today, I'd have to declare the
> parameter as Collection in order for custom collections to be able to use it.
> So in the future, I could either introduce an overloaded the method (one with a
> Collection parameter & one with a ReversibleCollection), or I could expect
> clients to do `List::copyOf`... right? I'd appreciate it if you could elaborate
> on this point, because I don't understand the concern yet.

Let say Java 18 adds RC, so in my new shiny library, i use it by introducing a method
  void foo(ReversibleCollection c) { ...

What it means for people that want to use the method foo ? if they are using the JDK collection, it all clear, now if they are using an ordered Collection from Apache, Guava,  Eclipse, etc, that Collection has not yet being retrofitted to implement ReversibleCollection so it means that as a user he will not use my shiny method foo until the library that provides the implementation is updated.

As you said, as a user i can also use new ArrayList<>() or List.copyOf(), but in that case, why not declaring foo as taking a List in the first place, it will make the adoption of my library faster.
So it's a kind of vicious circle, until enough libraries that provides a collection API has been updated, as a library developer, i will not use ReversibleCollection.
And given that no library are using ReversibleCollection, collection library developers have no incentive to update their library (that forces all their users to update their JDK version).

When you have this kind of relation, it takes a loooong time until you reach the point where people will start to using RC.

> 
>> - adding any new interfaces has a real cognitive cost, the collection API is
>> supposed to be simple, does being reversible really worth such new weight.
> 
> I believe this is subjective, but to me the new interfaces are like "the missing
> piece" of the Collections API puzzle. I believe their value is also in the fact
> that they reconcile List/Deque and LinkedHashSet/SortedSet and are very useful
> as parameter/return types in APIs.

Again, for you ReversibleCollection is the missing piece of the puzzle, for far more people it's ImmutableList, for me it's an interface which is a supertype of Collection that does not allow remove and clear because I very rarely use those methods and if there is no remove you can make the Iterator far faster. Everybody has its fantasy interface he wants to add on the collection API. But i hope that t next time we add one, it will be more useful and with a better compatibility story than ReversibleCollection, ReversibleSet and ReversibleMap. 

> 
> Kind regards, Anthony

regards,
R?mi

> 
> [1] https://gist.github.com/anthonyvdotbe/e2e313693f032e4336e5385334a476db

From kbarrett at openjdk.java.net  Thu May 13 22:52:11 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 13 May 2021 22:52:11 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 12 May 2021 21:13:54 GMT, Albert Mingkun Yang  wrote:

>> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - more comment improvements
>>  - improve naming and comments around injected String flags
>>  - fix some typos in comments
>
> Just some minor comments.

Following up on an off-line discussion with @albertnetymk , I've done a little refactoring of Requests::add.  I also made a few other small cleanups, noticed while dealing with @albertnetymk comments.  I still haven't dealt with the accumulated merge conflicts.  I'll be doing that next.

> src/hotspot/share/gc/shared/stringdedup/stringDedup.cpp line 171:
> 
>> 169:   // Store the string in the next pre-allocated storage entry.
>> 170:   oop* ref = _buffer[--_index];
>> 171:   _buffer[_index] = nullptr;
> 
> It's not really needed to clear the slot with null, right?

You are right; there used to be some asserts, but no longer. Removed.

> src/hotspot/share/gc/shared/stringdedup/stringDedupProcessor.cpp line 51:
> 
>> 49: }
>> 50: 
>> 51: StringDedup::Processor::~Processor() {}
> 
> Why the empty destructor? Could we just not have it?

Changed to use `= default`.

> src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 92:
> 
>> 90:   GrowableArrayCHeap _values;
>> 91: 
>> 92:   void adjust_capacity(int new_length);
> 
> Nit: diff arg name in declaration and implementation, `new_length` vs `new_capacity`.

Changed to consistently use `new_capacity`

> src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 295:
> 
>> 293: 
>> 294: protected:
>> 295:   CleanupState() {}
> 
> Is it possible to use `= default` here? Just like the destructor.

Changed to use `= default`.

> src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 314:
> 
>> 312:   size_t _bucket_index;
>> 313:   size_t _shrink_index;
>> 314:   bool _grow_only;
> 
> Seems unused.

Removed unused `_grow_only`, left over from earlier work.

> src/hotspot/share/memory/universe.cpp line 1153:
> 
>> 1151:     ResolvedMethodTable::verify();
>> 1152:   }
>> 1153:   if (should_verify_subset(Verify_StringDedup) && StringDedup::is_enabled()) {
> 
> Maybe drop the `is_enabled()` check in the `if` to keep the consistency with other `if`s?

Done.  StringDedup::verify already does an is_enabled check.  Also fixed the description comment, which incorrectly said `is_enabled()` was a precondition.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3662

From kbarrett at openjdk.java.net  Thu May 13 22:52:08 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 13 May 2021 22:52:08 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v3]
In-Reply-To: 
References: 
Message-ID: 

> Please review this change to the String Deduplication facility.  It is being
> changed to use OopStorage to hold weak references to relevant objects,
> rather than bespoke data structures requiring dedicated processing phases by
> supporting GCs.
> 
> (The Shenandoah update was contributed by Zhengyu Gu.)
> 
> This change significantly simplifies the interface between a given GC and
> the String Deduplication facility, which should make it much easier for
> other GCs to opt in.  However, this change does not alter the set of GCs
> providing support; currently only G1 and Shenandoah support string
> deduplication.  Adding support by other GCs will be in followup RFEs.
> 
> Reviewing via the diffs might not be all that useful for some parts, as
> several files have been essentially completely replaced, and a number of
> files have been added or eliminated.  The full webrev might be a better
> place to look.
> 
> The major changes are in gc/shared/stringdedup/* and in the supporting
> collectors, but there are also some smaller changes in other places, most
> notably classfile/{stringTable,javaClasses}.
> 
> This change is additionally labeled for review by core-libs, although there
> are no source changes there.  This change injects a byte field of bits into
> java.lang.String, using one of the previously unused padding bytes in that
> class.  (There were two unused bytes, now only one.)
> 
> Testing:
> mach5 tier1-2 with and without -XX:+UseStringDeduplication
> 
> Locally (linux-x64) ran all of the existing tests that use string
> deduplication with both G1 and Shenandoah.  Note that
> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
> currently fails, for reasons I haven't figured out but suspect are test
> related.
> 
> - gc/stringdedup/   -- these used to be in gc/g1
> - runtime/cds/SharedStringsDedup.java
> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
> - runtime/cds/appcds/sharedStrings/*
> 
> shenandoah-only:
> - gc/shenandoah/jvmti/TestHeapDump.java
> - gc/shenandoah/TestStringDedup.java
> - gc/shenandoah/TestStringDedupStress.java
> 
> Performance tested baseline, baseline + stringdedup, new with stringdedup,
> finding no significant differences.

Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:

 - misc cleanups
 - refactor Requests::add
 - fix typo

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3662/files
  - new: https://git.openjdk.java.net/jdk/pull/3662/files/656e2426..30e7b8e9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3662&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3662&range=01-02

  Stats: 69 lines in 6 files changed: 26 ins; 26 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3662.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3662/head:pull/3662

PR: https://git.openjdk.java.net/jdk/pull/3662

From kbarrett at openjdk.java.net  Thu May 13 22:52:12 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 13 May 2021 22:52:12 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 12 May 2021 11:55:08 GMT, Thomas Schatzl  wrote:

>> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - more comment improvements
>>  - improve naming and comments around injected String flags
>>  - fix some typos in comments
>
> src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp line 82:
> 
>> 80: // Doing so would counteract C2 optimizations on string literals.  But an
>> 81: // interned string might later become a deduplication candidate through the
>> 82: // normal GC discovery mechanism.  To prevent such modificatoins, the
> 
> s/modificatoins/modifications

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3662

From mr at openjdk.java.net  Thu May 13 23:07:07 2021
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 13 May 2021 23:07:07 GMT
Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK
 Internals [v3]
In-Reply-To: 
References: 
Message-ID: 

> 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 Reinhold has updated the pull request incrementally with one additional commit since the last revision:

  Remove now-unnecessary uses and mentions of the --illegal-access option

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4015/files
  - new: https://git.openjdk.java.net/jdk/pull/4015/files/719ff4ee..1c14998e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4015&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4015&range=01-02

  Stats: 26 lines in 10 files changed: 0 ins; 8 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4015.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4015/head:pull/4015

PR: https://git.openjdk.java.net/jdk/pull/4015

From mr at openjdk.java.net  Thu May 13 23:07:08 2021
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 13 May 2021 23:07:08 GMT
Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK
 Internals [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <21uRRgGzIydMlvMriHNpwJZ8Of4oIquShc8me0vWLfE=.bf969916-6227-41c1-afb5-9652459f33e2@github.com>

On Thu, 13 May 2021 18:16:23 GMT, Mandy Chung  wrote:

>> Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove stray mentions of the jdk.module.illegalAccess property
>
> There are a few tests with `--illegal-access=deny` for example
> 
> test/jdk/java/lang/ModuleTests/BasicModuleTest.java
> test/jdk/java/lang/instrument/RedefineModuleTest.java
> test/jdk/java/lang/invoke/CallerSensitiveAccess.java
> test/jdk/java/lang/reflect/AccessibleObject/ - a few tests
> test/jdk/jdk/modules/open/Basic.java
> test/jdk/tools/launcher/modules/addexports/manifest/AddExportsAndOpensInManifest.java
> 
> 
> It would be good to remove these references to `--illegal-access` option in this patch too.

@mlchung Thanks for pointing out those stray uses of `--illegal-access`. I?ve removed them, along with the mention of `--illegal-access` in `launcher.properties`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4015

From mchung at openjdk.java.net  Thu May 13 23:16:41 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 13 May 2021 23:16:41 GMT
Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK
 Internals [v3]
In-Reply-To: 
References: 
 
Message-ID: <0MBdE4SVoC_DjdoPcM_npW286VcPBc7kVv31PS7fbQM=.f58f1848-606e-40ee-8a17-06f0d079d181@github.com>

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 Reinhold has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove now-unnecessary uses and mentions of the --illegal-access option

Looks good.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4015

From david.holmes at oracle.com  Fri May 14 00:28:10 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 14 May 2021 10:28:10 +1000
Subject: RFR: 8266310: deadlock while loading the JNI code
In-Reply-To: <96b76d3f-a1fc-bb2e-195b-7e092b53c59b@oracle.com>
References: 
 <9cca1e8d-d9d9-4bb8-080e-195239023e79@oracle.com>
 <86478a7d-fcf6-df89-0f04-65480bb62fe7@bell-sw.com>
 <165946a3-3f16-3250-aa20-814aee31915d@oracle.com>
 <96b76d3f-a1fc-bb2e-195b-7e092b53c59b@oracle.com>
Message-ID: <216c69d9-5c7e-d772-38ee-b9073f8fda98@oracle.com>

On 14/05/2021 7:20 am, Mandy Chung wrote:
> 
> 
> 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 completely changes the 
>> semantics of native library loading. 
> 
> I have been giving some thought on this issue.? I agree with David that 
> we should look into a solution not holding a lock while JNI_OnLoad is 
> executed.? It might be possible to put all threads that trying to load 
> the same native library that is being loaded to wait and only one thread 
> is loading it and executing JNI_OnLoad (e.g. add a state in 
> NativeLibrary to indicate it is being loaded, already loaded, being 
> unloaded).? I haven't had the cycle to think through it in details though.

Any mechanism that blocks threads from accessing the library while 
another thread is performing JNI_OnLoad, suffers from the same deadlock 
problem.

David

> Mandy

From almatvee at openjdk.java.net  Fri May 14 04:31:45 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 14 May 2021 04:31:45 GMT
Subject: RFR: 8249395: (macos) jpackage tests timeout on MacPro5_1 systems
Message-ID: 

Looks like it is similar to JDK-8236282, except for "hdiutil create". Based on call stack from failed test we launched "hdiutil create" and were waiting for it to terminate while reading output from it. However, based on process dump from machine which reproduced this issue, hdiutil no longer runs and existed long time ago. Fixed in same way as JDK-8236282 by writing output to file and then reading it back when process terminates.

-------------

Commit messages:
 - 8249395: (macos) jpackage tests timeout on MacPro5_1 systems

Changes: https://git.openjdk.java.net/jdk/pull/4021/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4021&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8249395
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4021.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4021/head:pull/4021

PR: https://git.openjdk.java.net/jdk/pull/4021

From kbarrett at openjdk.java.net  Fri May 14 04:31:59 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 14 May 2021 04:31:59 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v4]
In-Reply-To: 
References: 
Message-ID: 

> Please review this change to the String Deduplication facility.  It is being
> changed to use OopStorage to hold weak references to relevant objects,
> rather than bespoke data structures requiring dedicated processing phases by
> supporting GCs.
> 
> (The Shenandoah update was contributed by Zhengyu Gu.)
> 
> This change significantly simplifies the interface between a given GC and
> the String Deduplication facility, which should make it much easier for
> other GCs to opt in.  However, this change does not alter the set of GCs
> providing support; currently only G1 and Shenandoah support string
> deduplication.  Adding support by other GCs will be in followup RFEs.
> 
> Reviewing via the diffs might not be all that useful for some parts, as
> several files have been essentially completely replaced, and a number of
> files have been added or eliminated.  The full webrev might be a better
> place to look.
> 
> The major changes are in gc/shared/stringdedup/* and in the supporting
> collectors, but there are also some smaller changes in other places, most
> notably classfile/{stringTable,javaClasses}.
> 
> This change is additionally labeled for review by core-libs, although there
> are no source changes there.  This change injects a byte field of bits into
> java.lang.String, using one of the previously unused padding bytes in that
> class.  (There were two unused bytes, now only one.)
> 
> Testing:
> mach5 tier1-2 with and without -XX:+UseStringDeduplication
> 
> Locally (linux-x64) ran all of the existing tests that use string
> deduplication with both G1 and Shenandoah.  Note that
> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
> currently fails, for reasons I haven't figured out but suspect are test
> related.
> 
> - gc/stringdedup/   -- these used to be in gc/g1
> - runtime/cds/SharedStringsDedup.java
> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
> - runtime/cds/appcds/sharedStrings/*
> 
> shenandoah-only:
> - gc/shenandoah/jvmti/TestHeapDump.java
> - gc/shenandoah/TestStringDedup.java
> - gc/shenandoah/TestStringDedupStress.java
> 
> Performance tested baseline, baseline + stringdedup, new with stringdedup,
> finding no significant differences.

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into new_dedup2
 - misc cleanups
 - refactor Requests::add
 - fix typo
 - more comment improvements
 - improve naming and comments around injected String flags
 - fix some typos in comments
 - New string deduplication

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3662/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3662&range=03
  Stats: 6191 lines in 104 files changed: 2369 ins; 3204 del; 618 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3662.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3662/head:pull/3662

PR: https://git.openjdk.java.net/jdk/pull/3662

From kbarrett at openjdk.java.net  Fri May 14 05:10:38 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 14 May 2021 05:10:38 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 14 May 2021 04:31:59 GMT, Kim Barrett  wrote:

>> Please review this change to the String Deduplication facility.  It is being
>> changed to use OopStorage to hold weak references to relevant objects,
>> rather than bespoke data structures requiring dedicated processing phases by
>> supporting GCs.
>> 
>> (The Shenandoah update was contributed by Zhengyu Gu.)
>> 
>> This change significantly simplifies the interface between a given GC and
>> the String Deduplication facility, which should make it much easier for
>> other GCs to opt in.  However, this change does not alter the set of GCs
>> providing support; currently only G1 and Shenandoah support string
>> deduplication.  Adding support by other GCs will be in followup RFEs.
>> 
>> Reviewing via the diffs might not be all that useful for some parts, as
>> several files have been essentially completely replaced, and a number of
>> files have been added or eliminated.  The full webrev might be a better
>> place to look.
>> 
>> The major changes are in gc/shared/stringdedup/* and in the supporting
>> collectors, but there are also some smaller changes in other places, most
>> notably classfile/{stringTable,javaClasses}.
>> 
>> This change is additionally labeled for review by core-libs, although there
>> are no source changes there.  This change injects a byte field of bits into
>> java.lang.String, using one of the previously unused padding bytes in that
>> class.  (There were two unused bytes, now only one.)
>> 
>> Testing:
>> mach5 tier1-2 with and without -XX:+UseStringDeduplication
>> 
>> Locally (linux-x64) ran all of the existing tests that use string
>> deduplication with both G1 and Shenandoah.  Note that
>> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
>> currently fails, for reasons I haven't figured out but suspect are test
>> related.
>> 
>> - gc/stringdedup/   -- these used to be in gc/g1
>> - runtime/cds/SharedStringsDedup.java
>> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
>> - runtime/cds/appcds/sharedStrings/*
>> 
>> shenandoah-only:
>> - gc/shenandoah/jvmti/TestHeapDump.java
>> - gc/shenandoah/TestStringDedup.java
>> - gc/shenandoah/TestStringDedupStress.java
>> 
>> Performance tested baseline, baseline + stringdedup, new with stringdedup,
>> finding no significant differences.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into new_dedup2
>  - misc cleanups
>  - refactor Requests::add
>  - fix typo
>  - more comment improvements
>  - improve naming and comments around injected String flags
>  - fix some typos in comments
>  - New string deduplication

The "merge from master" commit (ccb9951) doesn't build with Shenandoah.  I've asked Zhengyu to take a look.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3662

From iklam at openjdk.java.net  Fri May 14 05:47:17 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 14 May 2021 05:47:17 GMT
Subject: RFR: 8265605: Cannot call BootLoader::loadClassOrNull before
 initPhase2 [v4]
In-Reply-To: <5Z-hLKzLSdUeUjO5w8WS9PuGfd7se3IAjo18YaUIWEg=.cccb3896-f58f-4f39-838b-f8e4201fc7ea@github.com>
References: <5Z-hLKzLSdUeUjO5w8WS9PuGfd7se3IAjo18YaUIWEg=.cccb3896-f58f-4f39-838b-f8e4201fc7ea@github.com>
Message-ID: <2mZugZX5HEN_ecmplexNkK-SsTpgEjf5_ASkz1Vfd8s=.f89eceb4-1ed6-46ca-8e18-ceedb76961e6@github.com>

> 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 of the archived module graph in the wrong order. Because of unanticipated nesting of `` methods, `BootLoader::SERVICES_CATALOG` becomes empty, causing future `ServiceLoader` operations to fail.
> 
> The fix has 2 parts:
> 
> - `BootLoader::loadClassOrNull` no longer calls `ClassLoaders::bootLoader()`. This avoids triggering the archived module graph initialization. Instead, it makes a direct call to `Classloader::findBootstrapClassOrNull()`. We don't actually need a `ClassLoader` instance for this call, so I changed `Classloader::findBootstrapClassOrNull()` to be a static method.
> - The object returned by `BootLoader::getServicesCatalog()` is now maintained inside `jdk.internal.loader.ClassLoaders`.  Although not strictly required for the fix, this simplifies the initialization of the archived module graph. It also makes the logic consistent for the 3 built-in loaders (boot/platform/app).
> 
> Testing: tiers1-4 in progress. I also verified that the bug reported by Mandy is no longer reproducible after I applied this patch on her branch.

Ioi Lam 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 last revision:

 - Merge branch 'master' into 8265605-bootloader-loadClassOrNull-before-init-phase2
 - cleaned up ClassLoaders.setArchivedServicesCatalog
 - @AlanBateman comments
 - 8265605: Cannot call BootLoader::loadClassOrNull before initPhase2

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3992/files
  - new: https://git.openjdk.java.net/jdk/pull/3992/files/4cd981c0..a3dc9427

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3992&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3992&range=02-03

  Stats: 9450 lines in 343 files changed: 2601 ins; 4164 del; 2685 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3992.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3992/head:pull/3992

PR: https://git.openjdk.java.net/jdk/pull/3992

From sundar at openjdk.java.net  Fri May 14 05:47:45 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Fri, 14 May 2021 05:47:45 GMT
Subject: RFR: 8266291: (jrtfs) Calling Files.exists may break the JRT
 filesystem
Message-ID: 

Problematic paths that start with /modules/modules prefix are handled properly

-------------

Commit messages:
 - fixed typos in comments
 - 8266291: (jrtfs) Calling Files.exists may break the JRT filesystem

Changes: https://git.openjdk.java.net/jdk/pull/4022/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4022&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266291
  Stats: 36 lines in 2 files changed: 32 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4022.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4022/head:pull/4022

PR: https://git.openjdk.java.net/jdk/pull/4022

From iklam at openjdk.java.net  Fri May 14 06:29:40 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 14 May 2021 06:29:40 GMT
Subject: Integrated: 8265605: Cannot call BootLoader::loadClassOrNull before
 initPhase2
In-Reply-To: <5Z-hLKzLSdUeUjO5w8WS9PuGfd7se3IAjo18YaUIWEg=.cccb3896-f58f-4f39-838b-f8e4201fc7ea@github.com>
References: <5Z-hLKzLSdUeUjO5w8WS9PuGfd7se3IAjo18YaUIWEg=.cccb3896-f58f-4f39-838b-f8e4201fc7ea@github.com>
Message-ID: <4QVw_cFRg0IaN0W8gbWHGlSV-h1k5ZkPaa3xLk13MHI=.6411685d-1d23-4001-a97e-63343c994796@github.com>

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 of the archived module graph in the wrong order. Because of unanticipated nesting of `` methods, `BootLoader::SERVICES_CATALOG` becomes empty, causing future `ServiceLoader` operations to fail.
> 
> The fix has 2 parts:
> 
> - `BootLoader::loadClassOrNull` no longer calls `ClassLoaders::bootLoader()`. This avoids triggering the archived module graph initialization. Instead, it makes a direct call to `Classloader::findBootstrapClassOrNull()`. We don't actually need a `ClassLoader` instance for this call, so I changed `Classloader::findBootstrapClassOrNull()` to be a static method.
> - The object returned by `BootLoader::getServicesCatalog()` is now maintained inside `jdk.internal.loader.ClassLoaders`.  Although not strictly required for the fix, this simplifies the initialization of the archived module graph. It also makes the logic consistent for the 3 built-in loaders (boot/platform/app).
> 
> Testing: tiers1-4 in progress. I also verified that the bug reported by Mandy is no longer reproducible after I applied this patch on her branch.

This pull request has now been integrated.

Changeset: 1e0ecd6d
Author:    Ioi Lam 
URL:       https://git.openjdk.java.net/jdk/commit/1e0ecd6d56541c948e0d120295f5008d3248598f
Stats:     43 lines in 8 files changed: 9 ins; 13 del; 21 mod

8265605: Cannot call BootLoader::loadClassOrNull before initPhase2

Reviewed-by: alanb, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/3992

From iklam at openjdk.java.net  Fri May 14 06:29:39 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 14 May 2021 06:29:39 GMT
Subject: RFR: 8265605: Cannot call BootLoader::loadClassOrNull before
 initPhase2 [v3]
In-Reply-To: 
References: <5Z-hLKzLSdUeUjO5w8WS9PuGfd7se3IAjo18YaUIWEg=.cccb3896-f58f-4f39-838b-f8e4201fc7ea@github.com>
 <4P_OjNotZvZHiygB3Mtil26iP1eGiMAUJMKaPEzIINw=.6730184c-315e-46f6-956e-ef6f737e666d@github.com>
 
Message-ID: 

On Thu, 13 May 2021 06:19:47 GMT, Alan Bateman  wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleaned up ClassLoaders.setArchivedServicesCatalog
>
> Marked as reviewed by alanb (Reviewer).

Thanks @AlanBateman and @mlchung for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3992

From redestad at openjdk.java.net  Fri May 14 07:07:40 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 14 May 2021 07:07:40 GMT
Subject: RFR: 8266291: (jrtfs) Calling Files.exists may break the JRT
 filesystem
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 May 2021 05:39:10 GMT, Athijegannathan Sundararajan  wrote:

> Problematic paths that start with /modules/modules prefix are handled properly

LGTM

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4022

From dfranken.jdk at gmail.com  Fri May 14 07:16:07 2021
From: dfranken.jdk at gmail.com (dfranken.jdk at gmail.com)
Date: Fri, 14 May 2021 09:16:07 +0200
Subject: [External] : Re:  ReversibleCollection proposal
In-Reply-To: <477307921.278512.1620944115116.JavaMail.zimbra@u-pem.fr>
References: <2bbe-609d7b80-36b-7314b880@138287482>
 <477307921.278512.1620944115116.JavaMail.zimbra@u-pem.fr>
Message-ID: 

In reading all of the messages in this discussion, it becomes clear to
me that this is not a trivial change, because we are mostly hindered by
the Collection API as it currently exists.

Adding interfaces seems like the correct OOP way to do things, but it
may hinder adoption, because we have to wait for it to cascade through
the ecosystem.

Adding default methods seems like the most compatible way, but then we
create even more confusion in the Collection class. If add() can throw
an exception, but getFirst() never will but may just return a random
element, that does not seem consistent to me.

Has it ever been conceived to create an entire new API like how it was
done for Dates and Times? Obviously this would be a massive
undertaking, but it seems to me we've just about reached the limits of
how far we can stretch the current API.

When given the choice between the current proposals to add interfaces
or default methods, I'm kind of torn. Maybe we should just yield and
add the methods to the different sub-interfaces like List, etc? This
seems to be the least disruptive, but obviously it doesn't greatly
improve the overall design.

Kind regards,

Dave

On Fri, 2021-05-14 at 00:15 +0200, forax at univ-mlv.fr wrote:
> ----- Mail original -----
> > De: "Anthony Vanelverdinghe" 
> > ?: "Remi Forax" 
> > Cc: "Stuart Marks" , "core-libs-dev"
> > 
> > Envoy?: Jeudi 13 Mai 2021 21:18:22
> > Objet: Re: [External] : Re:? ReversibleCollection proposal
> 
> > Hi R?mi
> > 
> > The discussion "new types? or new default methods?" is indeed a
> > valid one. In
> > fact, I think this choice has already been made once in favor of a
> > default
> > method, when adding `List::sort` was chosen over adding
> > `SortedList` (though I
> > imagine that choice was a no-brainer).
> 
> yes, very true, there is no SortedList even if it would be useful to
> know if a list is already sorted, by example, we can add
> binarySearch() on it with no problem of people using it on an
> unsorted list.
> 
> > 
> > In this case I prefer adding new types though, so I wanted to share
> > my take on
> > this.
> > 
> > In the following diagram (see [1] in case it got mangled), I've
> > tried to arrange
> > all relevant Collection types by their defining characteristics:
> > 
> > > - Collection
> > > -----------------------------------------------------------------
> > > ----------------------------------------------|
> > > unordered??? ordered??????????????????????????????????
> > > sorted?????????? distinct
> > > distinct & ordered??? distinct & sorted |
> > > ?????????????????????????????????????????????????????????????????
> > > ????? Set???????????????????????????????????????????????? |
> > > ??????????? Queue = (get|remove)First + addLast??????
> > > PriorityQueue
> > > ??????????? |
> > > ??????????? Stack = (add|get|remove)Last
> > > ??????????? |
> > > ??????????? Deque = Queue + Stack + addFirst
> > > ??????????? LinkedHashSet???????? SortedSet???????? |
> > > ??????????? List = Deque + (add|get|remove)Indexed??? List::sort
> > > ??????????? NavigableSet????? |
> > > -----------------------------------------------------------------
> > > -----------------------------------------------------------|
> > 
> > As I see it, there are a couple of issues with this:
> > * conceptually, every List is a Deque, but List doesn't extend
> > Deque. If it
> > would, all uses of List (e.g. as a parameter type in APIs) where
> > the indexed
> > access isn't required could be replaced with Deque instead. Or e.g.
> > when you
> > need to take a stack as argument: currently Deque is the
> > recommended parameter
> > type, but that means you can't just pass a List to the method as-
> > is. With RC,
> > you'd be able to use that as parameter type and pass both Deque and
> > List.
> 
> You can use the same argument to have a common super type between Map
> and Collection, it would be very useful.
> 
> Until you think what methods are available on that type, size() and
> isEmpty(), meh, this is useless.
> 
> RC has the same issue, it's stuck in between Collection and List, so
> the cases where you don't want a Collection because it has not enough
> methods you want to use but at the same time you don't want a List
> because it has too many methods are vanishingly small.
> 
> The problem is that adding RC is not source compatible, so you are
> asking to add something in the JDK which serve a corner case but at
> the same time forces people to change their code even if they don't
> use RC.
> It's a loose / loose situation, we will have to maintain a collection
> forever in the JDK that nobody uses but everybody will pay for it.
> 
> [...]
> 
> > 
> > On Wednesday, May 12, 2021 13:22 CEST, forax at univ-mlv.fr?wrote:
> > 
> > > First, i think we have overlooked ReversibleMap, if you have a
> > > LinkedHashMap,
> > > the keySet should be a ReversibleSet.
> > 
> > I'm not sure what you meant, but the PR already defines
> > `LinkedHashMap::keySet`
> > as `public ReversibleSet keySet()`.
> 
> LinkedHashMap is perhaps the only implementation which has a keySet
> which is reversible, but there are a lot of other collection
> implementations, Apache collection, Guava, Eclipse, clojure-core, etc
> that may have such kind of implementation too. The same way you want
> RC between Queue and List, you want ReversibleMap between those Map
> implementations.
> 
> > 
> > > Again, we have seen that introducing those interfaces
> > > - is not source backward compatible thus it will be painful for
> > > some of our
> > > users,
> > > ? I believe NavigableSet/NavigableMap did not have that issue
> > > because only one
> > > ? existing implementation per interface was retrofitted to
> > > implement those
> > > ? interfaces, TreeSet for NavigableSet and TreeMap for
> > > NavigableMap.
> > > ? ConcurrentSkipListSet/ConcurrentSkipListMap were added at the
> > > same time, so
> > > ? there was no existing code doing a lub (lowest upper bound)
> > > between TreeSet and
> > > ? ConcurrentSkipListSet.
> > > ? Here, they are a lot of implementations that will implement be
> > > retrofitted to
> > > ? ReversibleCollection, ReversibleSet and ReversibleMap.
> > 
> > As far as I understand, both options might cause source
> > incompatibilities, but I
> > assume you estimate the actual impact of adding default methods to
> > be (much)
> > smaller?
> 
> Adding a default method may creates source incompatibilities but this
> can be solved by having a name with no collision, that why
> Iterator.forEachRemaining is such a long name by example.
> 
> Adding a common supertype to at least two already existing types
> change the inferred type in methods like Array.asList(), List.of() or
> in Stream so either there is no such problem, which means that nobody
> wants a supertype between Deque and List, or we have a lot of codes
> that now fail to compile. In both case, it means we should not add
> RC.
> 
> > 
> > > - people will have to wait a theoretically infinite time before
> > > being to
> > > introduce a public method that takes a ReversibleCollection,
> > > ReversibleSet and
> > > ReversibleMap to their library, because it requires
> > > ? all existing implementations of collection with an order to be
> > > retrofitted to
> > > ? implement those interfaces.
> > 
> > I think I'm missing something here. I just did an experiment to
> > convince myself
> > that the set of interfaces a class implements isn't hard-wired in
> > its class
> > file. In other words, that any custom List/Deque/SortedSet/...
> > implementation
> > would be seen as implementing RC/RS without having to recompile it
> > (that, or my
> > experiment was flawed somehow, of course). So am I correct that
> > your concerns
> > are only about custom collections that implement Collection
> > directly? If so, if
> > I'd introduce a public method in my library today, I'd have to
> > declare the
> > parameter as Collection in order for custom collections to be able
> > to use it.
> > So in the future, I could either introduce an overloaded the method
> > (one with a
> > Collection parameter & one with a ReversibleCollection), or I could
> > expect
> > clients to do `List::copyOf`... right? I'd appreciate it if you
> > could elaborate
> > on this point, because I don't understand the concern yet.
> 
> Let say Java 18 adds RC, so in my new shiny library, i use it by
> introducing a method
> ? void foo(ReversibleCollection c) { ...
> 
> What it means for people that want to use the method foo ? if they
> are using the JDK collection, it all clear, now if they are using an
> ordered Collection from Apache, Guava,? Eclipse, etc, that Collection
> has not yet being retrofitted to implement ReversibleCollection so it
> means that as a user he will not use my shiny method foo until the
> library that provides the implementation is updated.
> 
> As you said, as a user i can also use new ArrayList<>() or
> List.copyOf(), but in that case, why not declaring foo as taking a
> List in the first place, it will make the adoption of my library
> faster.
> So it's a kind of vicious circle, until enough libraries that
> provides a collection API has been updated, as a library developer, i
> will not use ReversibleCollection.
> And given that no library are using ReversibleCollection, collection
> library developers have no incentive to update their library (that
> forces all their users to update their JDK version).
> 
> When you have this kind of relation, it takes a loooong time until
> you reach the point where people will start to using RC.
> 
> > 
> > > - adding any new interfaces has a real cognitive cost, the
> > > collection API is
> > > supposed to be simple, does being reversible really worth such
> > > new weight.
> > 
> > I believe this is subjective, but to me the new interfaces are like
> > "the missing
> > piece" of the Collections API puzzle. I believe their value is also
> > in the fact
> > that they reconcile List/Deque and LinkedHashSet/SortedSet and are
> > very useful
> > as parameter/return types in APIs.
> 
> Again, for you ReversibleCollection is the missing piece of the
> puzzle, for far more people it's ImmutableList, for me it's an
> interface which is a supertype of Collection that does not allow
> remove and clear because I very rarely use those methods and if there
> is no remove you can make the Iterator far faster. Everybody has its
> fantasy interface he wants to add on the collection API. But i hope
> that t next time we add one, it will be more useful and with a better
> compatibility story than ReversibleCollection, ReversibleSet and
> ReversibleMap. 
> 
> > 
> > Kind regards, Anthony
> 
> regards,
> R?mi
> 
> > 
> > [1]
> > https://gist.github.com/anthonyvdotbe/e2e313693f032e4336e5385334a476db



From redestad at openjdk.java.net  Fri May 14 07:29:45 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 14 May 2021 07:29:45 GMT
Subject: RFR: 8263087: Add a MethodHandle combinator that switches over a
 set of MethodHandles
In-Reply-To: 
References: 
Message-ID: 

On Thu, 8 Apr 2021 18:51:21 GMT, Jorn Vernee  wrote:

> This patch adds a `tableSwitch` combinator that can be used to switch over a set of method handles given an index, with a fallback in case the index is out of bounds, much like the `tableswitch` bytecode. Here is a description of how it works (copied from the javadoc):
> 
>      Creates a table switch method handle, which can be used to switch over a set of target
>      method handles, based on a given target index, called selector.
> 
>      For a selector value of {@code n}, where {@code n} falls in the range {@code [0, N)},
>      and where {@code N} is the number of target method handles, the table switch method
>      handle will invoke the n-th target method handle from the list of target method handles.
> 
>      For a selector value that does not fall in the range {@code [0, N)}, the table switch
>      method handle will invoke the given fallback method handle.
> 
>      All method handles passed to this method must have the same type, with the additional
>      requirement that the leading parameter be of type {@code int}. The leading parameter
>      represents the selector.
> 
>      Any trailing parameters present in the type will appear on the returned table switch
>      method handle as well. Any arguments assigned to these parameters will be forwarded,
>      together with the selector value, to the selected method handle when invoking it.
> 
> The combinator does not support specifying the starting index, so the switch cases always run from 0 to however many target handles are specified. A starting index can be added manually with another combination step that filters the input index by adding or subtracting a constant from it, which does not affect performance. One of the reasons for not supporting a starting index is that it allows for more lambda form sharing, but also simplifies the implementation somewhat. I guess an open question is if a convenience overload should be added for that case?
> 
> Lookup switch can also be simulated by filtering the input through an injection function that translates it into a case index, which has also proven to have the ability to have comparable performance to, or even better performance than, a bytecode-native `lookupswitch` instruction. I plan to add such an injection function to the runtime libraries in the future as well. Maybe at that point it could be evaluated if it's worth it to add a lookup switch combinator as well, but I don't see an immediate need to include it in this patch.
> 
> The current bytecode intrinsification generates a call for each switch case, which guarantees full inlining of the target method handles. Alternatively we could only have 1 callsite at the end of the switch, where each case just loads the target method handle, but currently this does not allow for inlining of the handles, since they are not constant.
> 
> Maybe a future C2 optimization could look at the receiver input for invokeBasic call sites, and if the input is a phi node, clone the call for each constant input of the phi. I believe that would allow simplifying the bytecode without giving up on inlining.
> 
> Some numbers from the added benchmarks:
> 
> Benchmark                                        (numCases)  (offset)  (sorted)  Mode  Cnt   Score   Error  Units
> MethodHandlesTableSwitchConstant.testSwitch               5         0       N/A  avgt   30   4.186 ? 0.054  ms/op
> MethodHandlesTableSwitchConstant.testSwitch               5       150       N/A  avgt   30   4.164 ? 0.057  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              10         0       N/A  avgt   30   4.124 ? 0.023  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              10       150       N/A  avgt   30   4.126 ? 0.025  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              25         0       N/A  avgt   30   4.137 ? 0.042  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              25       150       N/A  avgt   30   4.113 ? 0.016  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              50         0       N/A  avgt   30   4.118 ? 0.028  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              50       150       N/A  avgt   30   4.127 ? 0.019  ms/op
> MethodHandlesTableSwitchConstant.testSwitch             100         0       N/A  avgt   30   4.116 ? 0.013  ms/op
> MethodHandlesTableSwitchConstant.testSwitch             100       150       N/A  avgt   30   4.121 ? 0.020  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5         0       N/A  avgt   30   4.113 ? 0.009  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5       150       N/A  avgt   30   4.149 ? 0.041  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10         0       N/A  avgt   30   4.121 ? 0.026  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10       150       N/A  avgt   30   4.113 ? 0.021  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25         0       N/A  avgt   30   4.129 ? 0.028  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25       150       N/A  avgt   30   4.105 ? 0.019  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50         0       N/A  avgt   30   4.097 ? 0.021  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50       150       N/A  avgt   30   4.131 ? 0.037  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100         0       N/A  avgt   30   4.135 ? 0.025  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100       150       N/A  avgt   30   4.139 ? 0.145  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5         0      true  avgt   30   4.894 ? 0.028  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5         0     false  avgt   30  11.526 ? 0.194  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5       150      true  avgt   30   4.882 ? 0.025  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5       150     false  avgt   30  11.532 ? 0.034  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10         0      true  avgt   30   5.065 ? 0.076  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10         0     false  avgt   30  13.016 ? 0.020  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10       150      true  avgt   30   5.103 ? 0.051  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10       150     false  avgt   30  12.984 ? 0.102  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25         0      true  avgt   30   8.441 ? 0.165  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25         0     false  avgt   30  13.371 ? 0.060  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25       150      true  avgt   30   8.628 ? 0.032  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25       150     false  avgt   30  13.542 ? 0.020  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50         0      true  avgt   30   4.701 ? 0.015  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50         0     false  avgt   30  13.562 ? 0.063  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50       150      true  avgt   30   7.991 ? 3.111  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50       150     false  avgt   30  13.543 ? 0.088  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100         0      true  avgt   30   4.712 ? 0.020  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100         0     false  avgt   30  13.600 ? 0.085  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100       150      true  avgt   30   4.676 ? 0.011  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100       150     false  avgt   30  13.476 ? 0.043  ms/op
> 
> 
> Testing:
> - [x] Running of included benchmarks
> - [x] Inspecting inlining trace and verifying method handle targets are inlined
> - [x] Running TestTableSwitch test (currently the only user of the new code)
> - [x] Running java/lang/invoke tests (just in case)
> - [x] Some manual testing
> 
> Thanks,
> Jorn

Overall this looks great! 

I have a number of nits and a request to try and remodel so that `NamedFunction` isn't responsible for holding the arbitrary intrinsic data that you want to add here.

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 1404:

> 1402:     private Name emitTableSwitch(int pos, int numCases) {
> 1403:         Name args    = lambdaForm.names[pos];
> 1404:         Name invoker = lambdaForm.names[pos+1];

Add spaces around `+`

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 1409:

> 1407:         Class returnType = result.function.resolvedHandle().type().returnType();
> 1408:         MethodType caseType = args.function.resolvedHandle().type()
> 1409:             .dropParameterTypes(0,1) // drop collector

Space after comma

src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 731:

> 729:                 collectArgs.isInvokeBasic() &&
> 730:                 unboxResult.isInvokeBasic() &&
> 731:                 tableSwitch.lastUseIndex(collectArgs)  == 3 &&    // t_{n+1}:L=MethodHandleImpl.(*, *, *, t_{n});

Extraneous space

src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1098:

> 1096:         @Stable MethodHandle invoker;
> 1097:         private final MethodHandleImpl.Intrinsic intrinsicName;
> 1098:         private final Object intrinsicData;

This seems like the wrong place to add arbitrary data related only to intrinsics. Could this be moved either into `MethodHandleImpl$IntrinsicMethodHandle` or - perhaps less appealingly - rewrite the `MethodHandleImpl.Intrinsic` to a regular class which can then be instantiated with extra data? That `NamedFunction` holds a field of type `MethodHandleImpl.Intrinsic` instead of delegating to `resolvedHandle.intrinsicName()` seem like a pre-existing kludge that would be good to sort out why/if it's really necessary.

src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 2015:

> 2013:     }
> 2014: 
> 2015:     private static final Map TABLE_SWITCH_LAMBDA_FORM_CACHE = new ConcurrentHashMap<>();

This could be moved to `class TableSwitchCacheKey` to reduce eagerly initialization on bootstrap.

test/micro/org/openjdk/bench/java/lang/invoke/MethodHandlesTableSwitchOpaqueSingle.java line 90:

> 88:         "50",
> 89:         "100"
> 90:     })

To reduce default runtime I think it'd be good to slim down the number of sizes we test here to 2 or 3 different ones.

test/micro/org/openjdk/bench/java/lang/invoke/MethodHandlesTableSwitchRandom.java line 90:

> 88:         "50",
> 89:         "100"
> 90:     })

To reduce default runtime I think it'd be good to slim down the number of sizes we test here to 2 or 3 different ones.

-------------

Changes requested by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3401

From alanb at openjdk.java.net  Fri May 14 08:05:44 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 14 May 2021 08:05:44 GMT
Subject: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static
 @Test methods [v4]
In-Reply-To: 
References: 
 
Message-ID: 

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 upcoming jtreg
>> 
>> 
>> Best
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust imports and spacing

Marked as reviewed by alanb (Reviewer).

test/jdk/tools/jmod/hashes/HashesTest.java line 389:

> 387:         ModuleReference mref = finder.find(name).orElseThrow(RuntimeException::new);
> 388:         try {
> 389:             try (ModuleReader reader = mref.open(); InputStream in = reader.open("module-info.class").get()) {

Thats for doing the right thing and using BeforeMethod. The changes looks good.
There is some random re-formatting in hashes and deleteDirectory, I don't know if this was intended or not. I think we should at least resolve L389 before integrating.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4009

From aph at redhat.com  Fri May 14 08:28:59 2021
From: aph at redhat.com (Andrew Haley)
Date: Fri, 14 May 2021 09:28:59 +0100
Subject: JEP draft: Scope Locals
In-Reply-To: 
References: 
 <8BF4CB1E-D621-4358-A14D-33FE21171537@cbfiddle.com>
 
 
Message-ID: <068819e2-127b-f87c-9e3b-1d8a4e7c1d71@redhat.com>

On 5/13/21 4:59 PM, Alan Snyder wrote:
> 
> 
>> On May 13, 2021, at 2:03 AM, Andrew Haley  wrote:
>>
>> On 5/12/21 8:12 PM, Alan Snyder wrote:
>>> From the motivation section:
>>>
>>>> So you want to invoke a method |X| in a library that later calls back into your code. In your callback you need some context, perhaps a transaction ID or some |File| instances. However, |X| provides no way to pass a reference through their code into your callback. What are you to do?
>>>
>>> When I read this, my first thought was? pass a callback that is bound to the context.
>>>
>>> I suppose the example you have in mind has a fixed callback.
>>
>> Fixed? It's a callback, of some form.
> 
> What I meant was that the callback has a larger scope than the method call. Otherwise, you could bind the context to the callback object.

I don't know quite what you mean by "larger scope," but clearly, if you
can explicitly pass a callback created by a lambda, that's a more explicit
solution.

>>> Is this a common practice? Doesn?t it point to a deficiency in the library API?
>>
>> Not necessarily. For example, say you want to give access to a particular
>> resource (a log stream, say) to trusted callees. Nobody AFAIK passes a log
>> stream as an explicit argument through business logic because that's just
>> too much clutter.
> 
> That sounds interesting, but I?m not following how scope locals would be used to solve this problem.

In the outer scope you bind a logger scope local, and all transitive callees
can use that.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From alanb at openjdk.java.net  Fri May 14 09:02:36 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 14 May 2021 09:02:36 GMT
Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK
 Internals [v3]
In-Reply-To: 
References: 
 
Message-ID: 

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 Reinhold has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove now-unnecessary uses and mentions of the --illegal-access option

The changes look good.

I searched the test and src trees for other remaining usages "--illegal-access" and didn't find any more (except for localized resources).

It's likely that some of the updated tests no longer need "/othervm". It would need a close inspection of each test to see if it still needed.

test/jdk/tools/launcher/modules/illegalaccess/IllegalAccessTest.java line 26:

> 24: /**
> 25:  * @test
> 26:  * @requires vm.compMode != "Xcomp"

I think `@requires vm.compMode != "Xcomp" was added because the test took too long with -Xcomp. I think it can be dropped now.

test/jdk/tools/launcher/modules/illegalaccess/IllegalAccessTest.java line 37:

> 35: 
> 36: /**
> 37:  * Basic test of --illegal-access=value to deny or permit access to JDK internals.

The comment should probably be updated as the test no longer tests denying or permitting access.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4015

From lancea at openjdk.java.net  Fri May 14 10:13:09 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 14 May 2021 10:13:09 GMT
Subject: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static
 @Test methods [v5]
In-Reply-To: 
References: 
Message-ID: 

> 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 upcoming jtreg
> 
> 
> Best
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Additional formatting cleanup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4009/files
  - new: https://git.openjdk.java.net/jdk/pull/4009/files/2e8f6c97..fe8b5a3c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4009&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4009&range=03-04

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4009.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4009/head:pull/4009

PR: https://git.openjdk.java.net/jdk/pull/4009

From lancea at openjdk.java.net  Fri May 14 10:13:10 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 14 May 2021 10:13:10 GMT
Subject: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static
 @Test methods [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 14 May 2021 08:02:29 GMT, Alan Bateman  wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust imports and spacing
>
> test/jdk/tools/jmod/hashes/HashesTest.java line 389:
> 
>> 387:         ModuleReference mref = finder.find(name).orElseThrow(RuntimeException::new);
>> 388:         try {
>> 389:             try (ModuleReader reader = mref.open(); InputStream in = reader.open("module-info.class").get()) {
> 
> Thats for doing the right thing and using BeforeMethod. The changes looks good.
> There is some random re-formatting in hashes and deleteDirectory, I don't know if this was intended or not. I think we should at least resolve L389 before integrating.

Thank you Alan.  The re-formatting was done automagically by Intellij.  I just pushed an update to address your suggestions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4009

From alanb at openjdk.java.net  Fri May 14 11:23:43 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 14 May 2021 11:23:43 GMT
Subject: RFR: 8266291: (jrtfs) Calling Files.exists may break the JRT
 filesystem
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 May 2021 05:39:10 GMT, Athijegannathan Sundararajan  wrote:

> Problematic paths that start with /modules/modules prefix are handled properly

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 475:

> 473:             }
> 474:             // Make sure that the thing that follows "/modules/" is a module name.
> 475:             // This will rule out paths that start as "/modules/modules/".

The code change looks fine. I guess I would probably change the comment to say that it make sure that there is something ending with "/" after "/modules/" (as the code that it comments doesn't actually change for a module name).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4022

From github.com+10835776+stsypanov at openjdk.java.net  Fri May 14 12:32:36 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 14 May 2021 12:32:36 GMT
Subject: Integrated: 8266622: Optimize Class.descriptorString() and
 Class.getCanonicalName0()
In-Reply-To: 
References: 
Message-ID: 

On Thu, 6 May 2021 15:20:23 GMT, ?????? ???????  wrote:

> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 and https://github.com/openjdk/jdk/pull/2212 it appears, that in `j.l.Class` expressions like
> 
> String str = baseName.replace('.', '/') + '/' + name;
> 
> are not compiled into invokedynamic-based code, but into one using `StringBuilder`.
> 
> This happens due to some bootstraping issues. Currently the bytecode for the last (most often used) branch of `Class.descriptorString()` looks like
> 
> public sb()Ljava/lang/String;
>    L0
>     LINENUMBER 21 L0
>     NEW java/lang/StringBuilder
>     DUP
>     INVOKESPECIAL java/lang/StringBuilder. ()V
>     ASTORE 1
>    L1
>     LINENUMBER 23 L1
>     ALOAD 1
>     LDC "a"
>     INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
>     POP
>    L2
>     LINENUMBER 24 L2
>     ALOAD 1
>     LDC "b"
>     INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
>     POP
>    L3
>     LINENUMBER 26 L3
>     ALOAD 1
>     INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String;
>     ARETURN
> 
> Here the `StringBuilder` is created with default constructor and then expands if necessary while appending. 
> 
> This can be improved by manually allocating `StringBuilder` of exact size. The benchmark demonstrates measurable improvement:
> 
> @State(Scope.Benchmark)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ClassDescriptorStringBenchmark {
> 
>     private final Class clazzWithShortDescriptor = Object.class;
>     private final Class clazzWithLongDescriptor = getClass();
> 
>     @Benchmark
>     public String descriptorString_short() {
>         return clazzWithShortDescriptor.descriptorString();
>     }
> 
>     @Benchmark
>     public String descriptorString_long() {
>         return clazzWithLongDescriptor.descriptorString();
>     }
> }
> 
> 
> 
> original
> -Xint
>                                                Mode     Score     Error   Units
> descriptorString_long                          avgt  6326.478 ? 107.251   ns/op
> descriptorString_short                         avgt  5220.729 ? 103.545   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt   528.089 ?   0.021    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt   232.036 ?   0.015    B/op
> 
> -XX:TieredStopAtLevel=1
>                                                Mode      Score    Error   Units
> descriptorString_long                          avgt    230.223 ?  1.254   ns/op
> descriptorString_short                         avgt    164.255 ?  0.755   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt    528.046 ?  0.002    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt    232.022 ?  0.001    B/op
> 
> full
>                                                Mode      Score     Error   Units
> descriptorString_long                          avgt     74.835 ?   0.262   ns/op
> descriptorString_short                         avgt     43.822 ?   0.788   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt    504.010 ?   0.001    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt    208.004 ?   0.001    B/op
> 
> ------------------------
> patched
> -Xint
>                                                Mode      Score     Error   Units
> descriptorString_long                          avgt   4485.994 ?  60.173   ns/op
> descriptorString_short                         avgt   3949.965 ? 278.143   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt    336.051 ?   0.004    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt    184.027 ?   0.010    B/op
> 
> -XX:TieredStopAtLevel=1
>                                                Mode        Score    Error   Units
> descriptorString_long                          avgt      185.774 ?  1.100   ns/op
> descriptorString_short                         avgt      135.338 ?  1.066   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt      336.030 ?  0.001    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt      184.019 ?  0.001    B/op
> 
> full
>                                                Mode      Score     Error   Units
> descriptorString_long                          avgt     42.864 ?   0.160   ns/op
> descriptorString_short                         avgt     27.255 ?   0.381   ns/op
> descriptorString_long:?gc.alloc.rate.norm      avgt    224.005 ?   0.001    B/op
> descriptorString_short:?gc.alloc.rate.norm     avgt    120.002 ?   0.001    B/op
> 
> Same can be done also for Class.isHidden() branch in Class.descriptorString() and for Class.getCanonicalName0()

This pull request has now been integrated.

Changeset: ebcf3991
Author:    ?????? ??????? 
Committer: Claes Redestad 
URL:       https://git.openjdk.java.net/jdk/commit/ebcf3991b79024ef35512e5aa2be5bd731acf9e0
Stats:     19 lines in 1 file changed: 15 ins; 0 del; 4 mod

8266622: Optimize Class.descriptorString() and Class.getCanonicalName0()

Reviewed-by: redestad

-------------

PR: https://git.openjdk.java.net/jdk/pull/3903

From zgu at openjdk.java.net  Fri May 14 12:43:53 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 14 May 2021 12:43:53 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 14 May 2021 04:31:59 GMT, Kim Barrett  wrote:

>> Please review this change to the String Deduplication facility.  It is being
>> changed to use OopStorage to hold weak references to relevant objects,
>> rather than bespoke data structures requiring dedicated processing phases by
>> supporting GCs.
>> 
>> (The Shenandoah update was contributed by Zhengyu Gu.)
>> 
>> This change significantly simplifies the interface between a given GC and
>> the String Deduplication facility, which should make it much easier for
>> other GCs to opt in.  However, this change does not alter the set of GCs
>> providing support; currently only G1 and Shenandoah support string
>> deduplication.  Adding support by other GCs will be in followup RFEs.
>> 
>> Reviewing via the diffs might not be all that useful for some parts, as
>> several files have been essentially completely replaced, and a number of
>> files have been added or eliminated.  The full webrev might be a better
>> place to look.
>> 
>> The major changes are in gc/shared/stringdedup/* and in the supporting
>> collectors, but there are also some smaller changes in other places, most
>> notably classfile/{stringTable,javaClasses}.
>> 
>> This change is additionally labeled for review by core-libs, although there
>> are no source changes there.  This change injects a byte field of bits into
>> java.lang.String, using one of the previously unused padding bytes in that
>> class.  (There were two unused bytes, now only one.)
>> 
>> Testing:
>> mach5 tier1-2 with and without -XX:+UseStringDeduplication
>> 
>> Locally (linux-x64) ran all of the existing tests that use string
>> deduplication with both G1 and Shenandoah.  Note that
>> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
>> currently fails, for reasons I haven't figured out but suspect are test
>> related.
>> 
>> - gc/stringdedup/   -- these used to be in gc/g1
>> - runtime/cds/SharedStringsDedup.java
>> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
>> - runtime/cds/appcds/sharedStrings/*
>> 
>> shenandoah-only:
>> - gc/shenandoah/jvmti/TestHeapDump.java
>> - gc/shenandoah/TestStringDedup.java
>> - gc/shenandoah/TestStringDedupStress.java
>> 
>> Performance tested baseline, baseline + stringdedup, new with stringdedup,
>> finding no significant differences.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into new_dedup2
>  - misc cleanups
>  - refactor Requests::add
>  - fix typo
>  - more comment improvements
>  - improve naming and comments around injected String flags
>  - fix some typos in comments
>  - New string deduplication

> The "merge from master" commit ([ccb9951](https://github.com/openjdk/jdk/commit/ccb99515d020785d7fe1cf9a1c247aeed775dc19)) doesn't build with Shenandoah. I've asked Zhengyu to take a look.

Just missing a parameter:

```diff --git a/src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp b/src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp
index ddaa66ccc14..93a067fa22d 100644
--- a/src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp
+++ b/src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp
@@ -57,7 +57,7 @@ ShenandoahInitMarkRootsClosure::ShenandoahInitMarkRootsClosure(ShenandoahObjToSc
 
 template 
 void ShenandoahInitMarkRootsClosure::do_oop_work(T* p) {
-  ShenandoahMark::mark_through_ref(p, _queue, _mark_context, false);
+  ShenandoahMark::mark_through_ref(p, _queue, _mark_context, NULL, false);
 }```

src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 314:

> 312:   size_t _bucket_index;
> 313:   size_t _shrink_index;
> 314:   bool _grow_only;

Indentation

-------------

PR: https://git.openjdk.java.net/jdk/pull/3662

From javalists at cbfiddle.com  Fri May 14 12:51:30 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 14 May 2021 05:51:30 -0700
Subject: JEP draft: Scope Locals
In-Reply-To: <068819e2-127b-f87c-9e3b-1d8a4e7c1d71@redhat.com>
References: 
 <8BF4CB1E-D621-4358-A14D-33FE21171537@cbfiddle.com>
 
 
 <068819e2-127b-f87c-9e3b-1d8a4e7c1d71@redhat.com>
Message-ID: <1A1CDA7B-8409-4F93-9747-B2D76E3176A1@cbfiddle.com>

The essence of the example seems to be that the callback is supporting multiple client contexts and when called needs to act relative to the specific client context.

The callback does not get a parameter identifying the client context because the library that calls it does not know anything about these client contexts.

Effectively, the callback uses the calling thread as a way to identify the client context.

That is not new. The ability to shadow/snapshot appears to be new, but it is still based on the thread as the ultimate context identifier.

Did I get it right?

If so, perhaps it would be less confusing if ?Scope Locals? instead were called ?Scoped Thread Locals?.





> On May 14, 2021, at 1:28 AM, Andrew Haley  wrote:
> 
> On 5/13/21 4:59 PM, Alan Snyder wrote:
>> 
>> 
>>> On May 13, 2021, at 2:03 AM, Andrew Haley  wrote:
>>> 
>>> On 5/12/21 8:12 PM, Alan Snyder wrote:
>>>> From the motivation section:
>>>> 
>>>>> So you want to invoke a method |X| in a library that later calls back into your code. In your callback you need some context, perhaps a transaction ID or some |File| instances. However, |X| provides no way to pass a reference through their code into your callback. What are you to do?
>>>> 
>>>> When I read this, my first thought was? pass a callback that is bound to the context.
>>>> 
>>>> I suppose the example you have in mind has a fixed callback.
>>> 
>>> Fixed? It's a callback, of some form.
>> 
>> What I meant was that the callback has a larger scope than the method call. Otherwise, you could bind the context to the callback object.
> 
> I don't know quite what you mean by "larger scope," but clearly, if you
> can explicitly pass a callback created by a lambda, that's a more explicit
> solution.
> 
>>>> Is this a common practice? Doesn?t it point to a deficiency in the library API?
>>> 
>>> Not necessarily. For example, say you want to give access to a particular
>>> resource (a log stream, say) to trusted callees. Nobody AFAIK passes a log
>>> stream as an explicit argument through business logic because that's just
>>> too much clutter.
>> 
>> That sounds interesting, but I?m not following how scope locals would be used to solve this problem.
> 
> In the outer scope you bind a logger scope local, and all transitive callees
> can use that.
> 
> -- 
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. 
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> 


From sundar at openjdk.java.net  Fri May 14 13:03:16 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Fri, 14 May 2021 13:03:16 GMT
Subject: RFR: 8266291: (jrtfs) Calling Files.exists may break the JRT
 filesystem [v2]
In-Reply-To: 
References: 
Message-ID: 

> Problematic paths that start with /modules/modules prefix are handled properly

Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:

  edited comment as per code review.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4022/files
  - new: https://git.openjdk.java.net/jdk/pull/4022/files/ba288d93..92611cbb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4022&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4022&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4022.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4022/head:pull/4022

PR: https://git.openjdk.java.net/jdk/pull/4022

From sundar at openjdk.java.net  Fri May 14 13:03:17 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Fri, 14 May 2021 13:03:17 GMT
Subject: Integrated: 8266291: (jrtfs) Calling Files.exists may break the JRT
 filesystem
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 May 2021 05:39:10 GMT, Athijegannathan Sundararajan  wrote:

> Problematic paths that start with /modules/modules prefix are handled properly

This pull request has now been integrated.

Changeset: af4cd04c
Author:    Athijegannathan Sundararajan 
URL:       https://git.openjdk.java.net/jdk/commit/af4cd04c2e393f8d1ffef60f49e3269adee649b8
Stats:     35 lines in 2 files changed: 31 ins; 0 del; 4 mod

8266291: (jrtfs) Calling Files.exists may break the JRT filesystem

Reviewed-by: redestad, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/4022

From brian.goetz at oracle.com  Fri May 14 14:45:15 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 14 May 2021 10:45:15 -0400
Subject: JEP draft: Scope Locals
In-Reply-To: <1A1CDA7B-8409-4F93-9747-B2D76E3176A1@cbfiddle.com>
References: 
 <8BF4CB1E-D621-4358-A14D-33FE21171537@cbfiddle.com>
 
 
 <068819e2-127b-f87c-9e3b-1d8a4e7c1d71@redhat.com>
 <1A1CDA7B-8409-4F93-9747-B2D76E3176A1@cbfiddle.com>
Message-ID: <88c68160-7c01-828a-71b7-614f2907307e@oracle.com>

Its simpler than you're making it.? Think of the motivating use cases 
for ThreadLocal, such as when a container calls into user code, and the 
user code calls back into the container, and we need to keep track of 
{transaction, security, etc} context, and it is impractical to pass them 
all through as parameters, or enumerate the possible callbacks.? The 
motivation here is the same; while the model is constrained, which 
eliminates some of the ways TLs are used today, these are "better TLs 
for better threads".? (If you believe that the motivation here is 
"poorly written libraries", then you believe that all libraries and 
frameworks that use TL are also poorly written.)

Where I think the JEP draft (the exposition, not the feature design) 
could be improved is to make the relationship to TL more clear.? IMO, 
this is a "more modern" TL design; it addresses the same primary use 
cases, without the unconstrained mutability of TLs.? The safety that 
comes from the immutability enables some new concurrent patterns (e.g., 
structured concurrency) and some nice optimizations.

On 5/14/2021 8:51 AM, Alan Snyder wrote:
> The essence of the example seems to be that the callback is supporting multiple client contexts and when called needs to act relative to the specific client context.
>
> The callback does not get a parameter identifying the client context because the library that calls it does not know anything about these client contexts.
>
> Effectively, the callback uses the calling thread as a way to identify the client context.
>
> That is not new. The ability to shadow/snapshot appears to be new, but it is still based on the thread as the ultimate context identifier.
>
> Did I get it right?
>
> If so, perhaps it would be less confusing if ?Scope Locals? instead were called ?Scoped Thread Locals?.
>
>
>
>
>
>> On May 14, 2021, at 1:28 AM, Andrew Haley  wrote:
>>
>> On 5/13/21 4:59 PM, Alan Snyder wrote:
>>>
>>>> On May 13, 2021, at 2:03 AM, Andrew Haley  wrote:
>>>>
>>>> On 5/12/21 8:12 PM, Alan Snyder wrote:
>>>>>  From the motivation section:
>>>>>
>>>>>> So you want to invoke a method |X| in a library that later calls back into your code. In your callback you need some context, perhaps a transaction ID or some |File| instances. However, |X| provides no way to pass a reference through their code into your callback. What are you to do?
>>>>> When I read this, my first thought was? pass a callback that is bound to the context.
>>>>>
>>>>> I suppose the example you have in mind has a fixed callback.
>>>> Fixed? It's a callback, of some form.
>>> What I meant was that the callback has a larger scope than the method call. Otherwise, you could bind the context to the callback object.
>> I don't know quite what you mean by "larger scope," but clearly, if you
>> can explicitly pass a callback created by a lambda, that's a more explicit
>> solution.
>>
>>>>> Is this a common practice? Doesn?t it point to a deficiency in the library API?
>>>> Not necessarily. For example, say you want to give access to a particular
>>>> resource (a log stream, say) to trusted callees. Nobody AFAIK passes a log
>>>> stream as an explicit argument through business logic because that's just
>>>> too much clutter.
>>> That sounds interesting, but I?m not following how scope locals would be used to solve this problem.
>> In the outer scope you bind a logger scope local, and all transitive callees
>> can use that.
>>
>> -- 
>> Andrew Haley  (he/him)
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. 
>> https://keybase.io/andrewhaley
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>>


From aph at redhat.com  Fri May 14 15:07:16 2021
From: aph at redhat.com (Andrew Haley)
Date: Fri, 14 May 2021 16:07:16 +0100
Subject: JEP draft: Scope Locals
In-Reply-To: <88c68160-7c01-828a-71b7-614f2907307e@oracle.com>
References: 
 <8BF4CB1E-D621-4358-A14D-33FE21171537@cbfiddle.com>
 
 
 <068819e2-127b-f87c-9e3b-1d8a4e7c1d71@redhat.com>
 <1A1CDA7B-8409-4F93-9747-B2D76E3176A1@cbfiddle.com>
 <88c68160-7c01-828a-71b7-614f2907307e@oracle.com>
Message-ID: 

On 5/14/21 3:45 PM, Brian Goetz wrote:
> Where I think the JEP draft (the exposition, not the feature design) 
> could be improved is to make the relationship to TL more clear.? IMO, 
> this is a "more modern" TL design; it addresses the same primary use 
> cases, without the unconstrained mutability of TLs.? The safety that 
> comes from the immutability enables some new concurrent patterns (e.g., 
> structured concurrency) and some nice optimizations.

Thank you, that's a nice summary. I was trying to describe scope locals
in a stand-alone way, but everything that a scope local can do can also
be done by a TL, albeit with some clumsiness. I should be more explicit
about that.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From herrick at openjdk.java.net  Fri May 14 15:23:38 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 14 May 2021 15:23:38 GMT
Subject: RFR: 8249395: (macos) jpackage tests timeout on MacPro5_1 systems
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 May 2021 04:24:42 GMT, Alexander Matveev  wrote:

> Looks like it is similar to JDK-8236282, except for "hdiutil create". Based on call stack from failed test we launched "hdiutil create" and were waiting for it to terminate while reading output from it. However, based on process dump from machine which reproduced this issue, hdiutil no longer runs and existed long time ago. Fixed in same way as JDK-8236282 by writing output to file and then reading it back when process terminates.

Marked as reviewed by herrick (Reviewer).

is JDK-8265294 also related to this ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4021

From bpb at openjdk.java.net  Fri May 14 16:00:58 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 14 May 2021 16:00:58 GMT
Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes
 [v7]
In-Reply-To: <7DNAsNlR9qOFQ60l-pSzc1SfH9GdecjrZ9re51Jo9vQ=.54273097-3573-4d4d-98b4-d29a964a41ad@github.com>
References: 
 <7DNAsNlR9qOFQ60l-pSzc1SfH9GdecjrZ9re51Jo9vQ=.54273097-3573-4d4d-98b4-d29a964a41ad@github.com>
Message-ID: 

On Mon, 10 May 2021 17:54:52 GMT, Brian Burkhalter  wrote:

>> Please consider this request to override the `java.io.InputStream` methods `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more performant implementations. The method overrides attempt to read all requested bytes into a single array of the required size rather than composing the result from a sequence of smaller arrays. An example of the performance improvements is as follows.
>> 
>> **readAllBytes**
>> Before
>> 
>> Benchmark                                    (length)   Mode  Cnt      Score     Error  Units
>> ReadAllBytes.readAllBytesFileInputStream      1000000  thrpt   20   2412.031 ?   7.309  ops/s
>> ReadAllBytes.readAllBytesFileInputStream     10000000  thrpt   20    212.181 ?   0.369  ops/s
>> ReadAllBytes.readAllBytesFileInputStream    100000000  thrpt   20     19.860 ?   0.048  ops/s
>> ReadAllBytes.readAllBytesFileInputStream   1000000000  thrpt   20      1.298 ?   0.183  ops/s
>> 
>> After
>> 
>> Benchmark                                    (length)   Mode  Cnt      Score     Error  Units
>> ReadAllBytes.readAllBytesFileInputStream      1000000  thrpt   20   8218.473 ?  43.425  ops/s
>> ReadAllBytes.readAllBytesFileInputStream     10000000  thrpt   20    302.781 ?   1.273  ops/s
>> ReadAllBytes.readAllBytesFileInputStream    100000000  thrpt   20     22.461 ?   0.084  ops/s
>> ReadAllBytes.readAllBytesFileInputStream   1000000000  thrpt   20      1.502 ?   0.003  ops/s
>> 
>> 
>> **readNBytes**
>> 
>> `N = file_size / 2`
>> 
>> Before
>> 
>> Benchmark                                    (length)   Mode  Cnt      Score     Error  Units
>> ReadAllBytes.readHalfBytesFileInputStream     1000000  thrpt   20   5585.500 ? 153.353  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream    10000000  thrpt   20    436.164 ?   1.104  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream   100000000  thrpt   20     40.167 ?   0.141  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream  1000000000  thrpt   20      3.291 ?   0.211  ops/s
>> 
>> 
>> After
>> 
>> Benchmark                                    (length)   Mode  Cnt      Score     Error  Units
>> ReadAllBytes.readHalfBytesFileInputStream     1000000  thrpt   20  15463.210 ?  66.045  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream    10000000  thrpt   20    561.752 ?   0.951  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream   100000000  thrpt   20     45.043 ?   0.102  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream  1000000000  thrpt   20      4.629 ?   0.035  ops/s
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8264777: Handle readNBytes(0): src/test

Any more comments on this? Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3845

From dfuchs at openjdk.java.net  Fri May 14 16:14:56 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 14 May 2021 16:14:56 GMT
Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes
 [v7]
In-Reply-To: <7DNAsNlR9qOFQ60l-pSzc1SfH9GdecjrZ9re51Jo9vQ=.54273097-3573-4d4d-98b4-d29a964a41ad@github.com>
References: 
 <7DNAsNlR9qOFQ60l-pSzc1SfH9GdecjrZ9re51Jo9vQ=.54273097-3573-4d4d-98b4-d29a964a41ad@github.com>
Message-ID: <2qYzGg-WHIMs2H-5kJCLQ3qalnP4_VF-C_uCN5U0mnA=.9ffd7da0-1da7-43c5-8f08-38f0c2047ef0@github.com>

On Mon, 10 May 2021 17:54:52 GMT, Brian Burkhalter  wrote:

>> Please consider this request to override the `java.io.InputStream` methods `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more performant implementations. The method overrides attempt to read all requested bytes into a single array of the required size rather than composing the result from a sequence of smaller arrays. An example of the performance improvements is as follows.
>> 
>> **readAllBytes**
>> Before
>> 
>> Benchmark                                    (length)   Mode  Cnt      Score     Error  Units
>> ReadAllBytes.readAllBytesFileInputStream      1000000  thrpt   20   2412.031 ?   7.309  ops/s
>> ReadAllBytes.readAllBytesFileInputStream     10000000  thrpt   20    212.181 ?   0.369  ops/s
>> ReadAllBytes.readAllBytesFileInputStream    100000000  thrpt   20     19.860 ?   0.048  ops/s
>> ReadAllBytes.readAllBytesFileInputStream   1000000000  thrpt   20      1.298 ?   0.183  ops/s
>> 
>> After
>> 
>> Benchmark                                    (length)   Mode  Cnt      Score     Error  Units
>> ReadAllBytes.readAllBytesFileInputStream      1000000  thrpt   20   8218.473 ?  43.425  ops/s
>> ReadAllBytes.readAllBytesFileInputStream     10000000  thrpt   20    302.781 ?   1.273  ops/s
>> ReadAllBytes.readAllBytesFileInputStream    100000000  thrpt   20     22.461 ?   0.084  ops/s
>> ReadAllBytes.readAllBytesFileInputStream   1000000000  thrpt   20      1.502 ?   0.003  ops/s
>> 
>> 
>> **readNBytes**
>> 
>> `N = file_size / 2`
>> 
>> Before
>> 
>> Benchmark                                    (length)   Mode  Cnt      Score     Error  Units
>> ReadAllBytes.readHalfBytesFileInputStream     1000000  thrpt   20   5585.500 ? 153.353  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream    10000000  thrpt   20    436.164 ?   1.104  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream   100000000  thrpt   20     40.167 ?   0.141  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream  1000000000  thrpt   20      3.291 ?   0.211  ops/s
>> 
>> 
>> After
>> 
>> Benchmark                                    (length)   Mode  Cnt      Score     Error  Units
>> ReadAllBytes.readHalfBytesFileInputStream     1000000  thrpt   20  15463.210 ?  66.045  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream    10000000  thrpt   20    561.752 ?   0.951  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream   100000000  thrpt   20     45.043 ?   0.102  ops/s
>> ReadAllBytes.readHalfBytesFileInputStream  1000000000  thrpt   20      4.629 ?   0.035  ops/s
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8264777: Handle readNBytes(0): src/test

New changes look good to me.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3845

From lancea at openjdk.java.net  Fri May 14 17:22:41 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 14 May 2021 17:22:41 GMT
Subject: Integrated: 8266461: tools/jmod/hashes/HashesTest.java fails: static
 @Test methods
In-Reply-To: 
References: 
Message-ID: 

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 upcoming jtreg
> 
> 
> Best
> Lance

This pull request has now been integrated.

Changeset: e90388bc
Author:    Lance Andersen 
URL:       https://git.openjdk.java.net/jdk/commit/e90388bc1e7bba92675fa799d9da77aa4d6e1a05
Stats:     151 lines in 1 file changed: 8 ins; 25 del; 118 mod

8266461: tools/jmod/hashes/HashesTest.java fails: static @Test methods

Reviewed-by: alanb, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/4009

From lancea at openjdk.java.net  Fri May 14 17:58:56 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 14 May 2021 17:58:56 GMT
Subject: Integrated: 8267180: Typo in copyright header  for HashesTest
Message-ID: 

Please review this fix for a typo in the copyright header in HashTest which the jdk-tier1 does not catch

Best
Lance

-------------

Commit messages:
 - Typo in copyright header  for HashesTest

Changes: https://git.openjdk.java.net/jdk/pull/4034/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4034&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267180
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4034.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4034/head:pull/4034

PR: https://git.openjdk.java.net/jdk/pull/4034

From dcubed at openjdk.java.net  Fri May 14 17:58:56 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 14 May 2021 17:58:56 GMT
Subject: Integrated: 8267180: Typo in copyright header  for HashesTest
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 May 2021 17:44:20 GMT, Lance Andersen  wrote:

> Please review this fix for a typo in the copyright header in HashTest which the jdk-tier1 does not catch
> 
> Best
> Lance

Thumbs up. This is a trivial change.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4034

From naoto at openjdk.java.net  Fri May 14 17:58:56 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 14 May 2021 17:58:56 GMT
Subject: Integrated: 8267180: Typo in copyright header  for HashesTest
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 May 2021 17:44:20 GMT, Lance Andersen  wrote:

> Please review this fix for a typo in the copyright header in HashTest which the jdk-tier1 does not catch
> 
> Best
> Lance

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4034

From joehw at openjdk.java.net  Fri May 14 17:58:57 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 14 May 2021 17:58:57 GMT
Subject: Integrated: 8267180: Typo in copyright header  for HashesTest
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 May 2021 17:44:20 GMT, Lance Andersen  wrote:

> Please review this fix for a typo in the copyright header in HashTest which the jdk-tier1 does not catch
> 
> Best
> Lance

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4034

From lancea at openjdk.java.net  Fri May 14 17:58:57 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 14 May 2021 17:58:57 GMT
Subject: Integrated: 8267180: Typo in copyright header  for HashesTest
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 May 2021 17:44:20 GMT, Lance Andersen  wrote:

> Please review this fix for a typo in the copyright header in HashTest which the jdk-tier1 does not catch
> 
> Best
> Lance

This pull request has now been integrated.

Changeset: 5eda812f
Author:    Lance Andersen 
URL:       https://git.openjdk.java.net/jdk/commit/5eda812f53bfe65d11f6241b0831c588c1400b08
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8267180: Typo in copyright header  for HashesTest

Reviewed-by: dcubed, naoto, joehw

-------------

PR: https://git.openjdk.java.net/jdk/pull/4034

From asemenyuk at openjdk.java.net  Fri May 14 18:34:00 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 14 May 2021 18:34:00 GMT
Subject: RFR: 8249395: (macos) jpackage tests timeout on MacPro5_1 systems
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 May 2021 04:24:42 GMT, Alexander Matveev  wrote:

> Looks like it is similar to JDK-8236282, except for "hdiutil create". Based on call stack from failed test we launched "hdiutil create" and were waiting for it to terminate while reading output from it. However, based on process dump from machine which reproduced this issue, hdiutil no longer runs and existed long time ago. Fixed in same way as JDK-8236282 by writing output to file and then reading it back when process terminates.

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4021

From kbarrett at openjdk.java.net  Fri May 14 18:42:06 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 14 May 2021 18:42:06 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v5]
In-Reply-To: 
References: 
Message-ID: <0Zvd_LtOrgN-vGEPtCbd-q3RG97ZTgGRr1mRlowBpxw=.7744f9eb-0ec7-4192-b21d-8af96ee8e79f@github.com>

> Please review this change to the String Deduplication facility.  It is being
> changed to use OopStorage to hold weak references to relevant objects,
> rather than bespoke data structures requiring dedicated processing phases by
> supporting GCs.
> 
> (The Shenandoah update was contributed by Zhengyu Gu.)
> 
> This change significantly simplifies the interface between a given GC and
> the String Deduplication facility, which should make it much easier for
> other GCs to opt in.  However, this change does not alter the set of GCs
> providing support; currently only G1 and Shenandoah support string
> deduplication.  Adding support by other GCs will be in followup RFEs.
> 
> Reviewing via the diffs might not be all that useful for some parts, as
> several files have been essentially completely replaced, and a number of
> files have been added or eliminated.  The full webrev might be a better
> place to look.
> 
> The major changes are in gc/shared/stringdedup/* and in the supporting
> collectors, but there are also some smaller changes in other places, most
> notably classfile/{stringTable,javaClasses}.
> 
> This change is additionally labeled for review by core-libs, although there
> are no source changes there.  This change injects a byte field of bits into
> java.lang.String, using one of the previously unused padding bytes in that
> class.  (There were two unused bytes, now only one.)
> 
> Testing:
> mach5 tier1-2 with and without -XX:+UseStringDeduplication
> 
> Locally (linux-x64) ran all of the existing tests that use string
> deduplication with both G1 and Shenandoah.  Note that
> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
> currently fails, for reasons I haven't figured out but suspect are test
> related.
> 
> - gc/stringdedup/   -- these used to be in gc/g1
> - runtime/cds/SharedStringsDedup.java
> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
> - runtime/cds/appcds/sharedStrings/*
> 
> shenandoah-only:
> - gc/shenandoah/jvmti/TestHeapDump.java
> - gc/shenandoah/TestStringDedup.java
> - gc/shenandoah/TestStringDedupStress.java
> 
> Performance tested baseline, baseline + stringdedup, new with stringdedup,
> finding no significant differences.

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into new_dedup2
 - fix shenandoah merge
 - Merge branch 'master' into new_dedup2
 - misc cleanups
 - refactor Requests::add
 - fix typo
 - more comment improvements
 - improve naming and comments around injected String flags
 - fix some typos in comments
 - New string deduplication

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3662/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3662&range=04
  Stats: 6192 lines in 105 files changed: 2369 ins; 3204 del; 619 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3662.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3662/head:pull/3662

PR: https://git.openjdk.java.net/jdk/pull/3662

From kbarrett at openjdk.java.net  Fri May 14 18:42:08 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 14 May 2021 18:42:08 GMT
Subject: Integrated: 8254598: StringDedupTable should use OopStorage
In-Reply-To: 
References: 
Message-ID: 

On Fri, 23 Apr 2021 19:48:47 GMT, Kim Barrett  wrote:

> Please review this change to the String Deduplication facility.  It is being
> changed to use OopStorage to hold weak references to relevant objects,
> rather than bespoke data structures requiring dedicated processing phases by
> supporting GCs.
> 
> (The Shenandoah update was contributed by Zhengyu Gu.)
> 
> This change significantly simplifies the interface between a given GC and
> the String Deduplication facility, which should make it much easier for
> other GCs to opt in.  However, this change does not alter the set of GCs
> providing support; currently only G1 and Shenandoah support string
> deduplication.  Adding support by other GCs will be in followup RFEs.
> 
> Reviewing via the diffs might not be all that useful for some parts, as
> several files have been essentially completely replaced, and a number of
> files have been added or eliminated.  The full webrev might be a better
> place to look.
> 
> The major changes are in gc/shared/stringdedup/* and in the supporting
> collectors, but there are also some smaller changes in other places, most
> notably classfile/{stringTable,javaClasses}.
> 
> This change is additionally labeled for review by core-libs, although there
> are no source changes there.  This change injects a byte field of bits into
> java.lang.String, using one of the previously unused padding bytes in that
> class.  (There were two unused bytes, now only one.)
> 
> Testing:
> mach5 tier1-2 with and without -XX:+UseStringDeduplication
> 
> Locally (linux-x64) ran all of the existing tests that use string
> deduplication with both G1 and Shenandoah.  Note that
> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
> currently fails, for reasons I haven't figured out but suspect are test
> related.
> 
> - gc/stringdedup/   -- these used to be in gc/g1
> - runtime/cds/SharedStringsDedup.java
> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
> - runtime/cds/appcds/sharedStrings/*
> 
> shenandoah-only:
> - gc/shenandoah/jvmti/TestHeapDump.java
> - gc/shenandoah/TestStringDedup.java
> - gc/shenandoah/TestStringDedupStress.java
> 
> Performance tested baseline, baseline + stringdedup, new with stringdedup,
> finding no significant differences.

This pull request has now been integrated.

Changeset: be0a6552
Author:    Kim Barrett 
URL:       https://git.openjdk.java.net/jdk/commit/be0a655208f64e076e9e0141fe5dadc862cba981
Stats:     6192 lines in 105 files changed: 2369 ins; 3204 del; 619 mod

8254598: StringDedupTable should use OopStorage

Co-authored-by: Kim Barrett 
Co-authored-by: Zhengyu Gu 
Reviewed-by: coleenp, iklam, tschatzl, ayang

-------------

PR: https://git.openjdk.java.net/jdk/pull/3662

From kbarrett at openjdk.java.net  Fri May 14 18:42:07 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 14 May 2021 18:42:07 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 14 May 2021 12:40:46 GMT, Zhengyu Gu  wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - Merge branch 'master' into new_dedup2
>>  - fix shenandoah merge
>>  - Merge branch 'master' into new_dedup2
>>  - misc cleanups
>>  - refactor Requests::add
>>  - fix typo
>>  - more comment improvements
>>  - improve naming and comments around injected String flags
>>  - fix some typos in comments
>>  - New string deduplication
>
>> The "merge from master" commit ([ccb9951](https://github.com/openjdk/jdk/commit/ccb99515d020785d7fe1cf9a1c247aeed775dc19)) doesn't build with Shenandoah. I've asked Zhengyu to take a look.
> 
> Just missing a parameter:
> 
> ```diff --git a/src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp b/src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp
> index ddaa66ccc14..93a067fa22d 100644
> --- a/src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp
> @@ -57,7 +57,7 @@ ShenandoahInitMarkRootsClosure::ShenandoahInitMarkRootsClosure(ShenandoahObjToSc
>  
>  template 
>  void ShenandoahInitMarkRootsClosure::do_oop_work(T* p) {
> -  ShenandoahMark::mark_through_ref(p, _queue, _mark_context, false);
> +  ShenandoahMark::mark_through_ref(p, _queue, _mark_context, NULL, false);
>  }```

Thanks @zhengyu123 for the shenandoah merge fix.

Thanks @iklam , @coleenp , @tschatzl , @albertnetymk for reviews.

> src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 314:
> 
>> 312:   size_t _bucket_index;
>> 313:   size_t _shrink_index;
>> 314:   bool _grow_only;
> 
> Indentation

Not sure what this indentation comment is referring to.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3662

From brian.goetz at oracle.com  Fri May 14 21:39:37 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 14 May 2021 17:39:37 -0400
Subject: JEP draft: Scope Locals
In-Reply-To: 
References: 
 
Message-ID: <7220447e-b2c5-7199-655c-aee364c78b35@oracle.com>

The lifecycle is bounded by the duration of the Runnable passed to the 
`run()` method.

In the simple case, with no inheritance and no snapshotting:

 ??? ScopedLocal.where(x, xExpr).run(r)

the lifecycle of the binding starts when we enter r, and ends when we 
return from r.

With snapshotting, the answer is the same, just less obviously so.? If I 
take a snapshot of a set of variables, we're not in a scope yet; we'll 
enter a new scope when we use that snapshot to run a task, possibly 
multiple times.

With inheritance, it is possible that the child thread can live longer 
than the lifetime of the task that spawned it; this is something we hope 
we can avoid through _structured concurrency_ -- that the inheritance is 
restricted to cases where we can prove the lifetime of the parent is 
longer than the lifetime of the child.? There's more work to be done here.

To be explicit, the two assumptions we need in order to avoid people 
shooting their feet are:

 ?- ScopeLocal values are effectively final "all the way down". We can't 
enforce this, but if users had to synchronize when accessing the state 
of scoped locals, then someone made a big mistake.? (This joins a very 
long list of mutability bugs we can't prevent but for which we have to 
communicate to users what they shouldn't be doing, not unlike "don't 
modify the source of the stream while traversing it.")

 ?- When inheriting, the parent must outlive the child.

When these assumptions hold, understanding the lifecycle is trivial.



On 5/14/2021 3:19 PM, Mike Rettig wrote:
> I don't see a way to capture the lifecycle of the scoped variable. I think
> for framework designers it's going to be important to know the life cycle
> of the scoped variable especially with snapshotting and inheritance.  The
> lack of a defined life cycle for thread locals is one of the many reasons
> why it should be avoided. If scoped locals have a well defined and
> comprehensive life cycle then it will make working with them much easier
> (especially when many threads are involved).
>
> interface ScopedVariableLifecycle {
>     ScopedVariable begin();
> }
>
> interface ScopedVariable {
>     T get();
>     void end();
>
>     Optional> createForChildScope();
>     Optional> createSnapshot();
> }
>
> static final ScopeLocal x = ScopeLocal.forType(MyType.class);
>
> //most scoped variables will probably use the standard singleton
> implementations.
>
> ScopedLocal.where(x, new Singleton(new MyType()));
>
> ScopedLocal.where(x, new InheritableSingleton(new MyType()));
>
>
> //a custom lifecycle (e.g. database connection that is opened on first
> access and closed at the end of the scope).
>
> ScopedLocal.where(x, new MyScopedVariableLifecycle());
>
>
> On Wed, May 12, 2021 at 10:15 AM Andrew Haley  wrote:
>
>> There's been considerable discussion about scope locals on the loom-dev
>> list,
>> and it's now time to open this to a wider audience. This subject is
>> important
>> because. although scope locals were motivated by the the needs of Loom,
>> they
>> have many potential applications outside that project.
>>
>> The draft JEP is at
>>
>> https://bugs.openjdk.java.net/browse/JDK-8263012
>>
>> I've already received some very helpful suggestions for enhancements to
>> the API, and it'll take me a while to work through them all. In particular,
>> Paul Sandoz has suggested that I unify the classes Snapshot and Carrier,
>> and it will take me some time to understand the consequences of that.
>>
>> In the meantime, please have a look at the JEP and comment here.
>>
>>
>> For reference, earlier discussions are at
>>
>> https://mail.openjdk.java.net/pipermail/loom-dev/2021-March/002268.html
>> https://mail.openjdk.java.net/pipermail/loom-dev/2021-April/002287.html
>> https://mail.openjdk.java.net/pipermail/loom-dev/2021-May/002427.html
>>
>> --
>> Andrew Haley  (he/him)
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. 
>> https://keybase.io/andrewhaley
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>>
>>
>>


From almatvee at openjdk.java.net  Fri May 14 23:04:43 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 14 May 2021 23:04:43 GMT
Subject: Integrated: 8249395: (macos) jpackage tests timeout on MacPro5_1
 systems
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 May 2021 04:24:42 GMT, Alexander Matveev  wrote:

> Looks like it is similar to JDK-8236282, except for "hdiutil create". Based on call stack from failed test we launched "hdiutil create" and were waiting for it to terminate while reading output from it. However, based on process dump from machine which reproduced this issue, hdiutil no longer runs and existed long time ago. Fixed in same way as JDK-8236282 by writing output to file and then reading it back when process terminates.

This pull request has now been integrated.

Changeset: 28f1c7ac
Author:    Alexander Matveev 
URL:       https://git.openjdk.java.net/jdk/commit/28f1c7ac4dfcf1df7df4eb94d270292b76baee12
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8249395: (macos) jpackage tests timeout on MacPro5_1 systems

Reviewed-by: herrick, asemenyuk

-------------

PR: https://git.openjdk.java.net/jdk/pull/4021

From sviswanathan at openjdk.java.net  Sat May 15 00:18:17 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Sat, 15 May 2021 00:18:17 GMT
Subject: RFR: 8267190: Optimize Vector API test operations
Message-ID: 

Vector API test operations (IS_DEFAULT, IS_FINITE, IS_INFINITE, IS_NAN and IS_NEGATIVE) are computed in three steps:
1) reinterpreting the floating point vectors as integral vectors (int/long)
2) perform the test in integer domain to get a int/long mask
3) reinterpret the int/long mask as float/double mask
Step 3) currently is very slow. It can be optimized by modifying the Java code to utilize the existing reinterpret intrinsic.

For the VectorTestPerf attached to the JBS for JDK-8267190, the performance improves as follows:

Base:
Benchmark (size) Mode Cnt Score Error Units
VectorTestPerf.IS_DEFAULT 1024 thrpt 5 223.156 ? 90.452 ops/ms
VectorTestPerf.IS_FINITE 1024 thrpt 5 223.841 ? 91.685 ops/ms
VectorTestPerf.IS_INFINITE 1024 thrpt 5 224.561 ? 83.890 ops/ms
VectorTestPerf.IS_NAN 1024 thrpt 5 223.777 ? 70.629 ops/ms
VectorTestPerf.IS_NEGATIVE 1024 thrpt 5 218.392 ? 79.806 ops/ms

With patch:
Benchmark (size) Mode Cnt Score Error Units
VectorTestPerf.IS_DEFAULT 1024 thrpt 5 8812.357 ? 40.477 ops/ms
VectorTestPerf.IS_FINITE 1024 thrpt 5 7425.739 ? 296.622 ops/ms
VectorTestPerf.IS_INFINITE 1024 thrpt 5 8932.730 ? 269.988 ops/ms
VectorTestPerf.IS_NAN 1024 thrpt 5 8574.872 ? 498.649 ops/ms
VectorTestPerf.IS_NEGATIVE 1024 thrpt 5 8838.400 ? 11.849 ops/ms

Best Regards,
Sandhya

-------------

Commit messages:
 - 8267190: Optimize Vector API test operations

Changes: https://git.openjdk.java.net/jdk/pull/4039/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4039&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267190
  Stats: 809 lines in 32 files changed: 714 ins; 0 del; 95 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4039.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4039/head:pull/4039

PR: https://git.openjdk.java.net/jdk/pull/4039

From sviswanathan at openjdk.java.net  Sat May 15 01:48:35 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Sat, 15 May 2021 01:48:35 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v3]
In-Reply-To: 
References: 
Message-ID: <2gAn7RV3gzdAOuAZNRcINNLi4NKBwYJW-4NdjcRgpCE=.5e3c0cc3-c89b-486d-8749-cfa630e59f04@github.com>

> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
> 
> The following changes are made:
>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>    Changes are made to build system to support dependency tracking for assembly files with includes.
>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
> 
> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
> 
> Looking forward to your review and feedback.
> 
> Performance:
> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
> Double128Vector.COS 49.94 245.89 ops/ms 4.92
> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
> Double256Vector.COS 58.26 389.77 ops/ms 6.69
> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
> Double512Vector.COS 59.88 837.04 ops/ms 13.98
> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
> Double512Vector.POW 37.42 384.13 ops/ms 10.26
> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
> Double64Vector.COS 23.42 152.01 ops/ms 6.49
> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
> Float128Vector.COS 42.82 803.02 ops/ms 18.75
> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
> Float256Vector.COS 43.75 926.69 ops/ms 21.18
> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
> Float64Vector.COS 44.28 394.33 ops/ms 8.91
> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
> Float64Vector.TANH 47.65 214.04 ops/ms 4.49

Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge master
 - Merge master
 - remove whitespace
 - Merge master
 - Small fix
 - cleanup
 - x86 short vector math optimization for Vector API

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3638/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=02
  Stats: 417101 lines in 120 files changed: 416935 ins; 123 del; 43 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638

PR: https://git.openjdk.java.net/jdk/pull/3638

From sviswanathan at openjdk.java.net  Sat May 15 02:06:29 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Sat, 15 May 2021 02:06:29 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v4]
In-Reply-To: 
References: 
Message-ID: 

> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted.
> 
> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
> 
> The following changes are made:
>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>    Changes are made to build system to support dependency tracking for assembly files with includes.
>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
> 
> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
> 
> Looking forward to your review and feedback.
> 
> Performance:
> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
> Double128Vector.COS 49.94 245.89 ops/ms 4.92
> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
> Double256Vector.COS 58.26 389.77 ops/ms 6.69
> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
> Double512Vector.COS 59.88 837.04 ops/ms 13.98
> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
> Double512Vector.POW 37.42 384.13 ops/ms 10.26
> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
> Double64Vector.COS 23.42 152.01 ops/ms 6.49
> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
> Float128Vector.COS 42.82 803.02 ops/ms 18.75
> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
> Float256Vector.COS 43.75 926.69 ops/ms 21.18
> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
> Float64Vector.COS 44.28 394.33 ops/ms 8.91
> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
> Float64Vector.TANH 47.65 214.04 ops/ms 4.49

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  Add missing Lib.gmk

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3638/files
  - new: https://git.openjdk.java.net/jdk/pull/3638/files/6e105f51..01a549e4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=02-03

  Stats: 42 lines in 1 file changed: 42 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638

PR: https://git.openjdk.java.net/jdk/pull/3638

From aph at redhat.com  Sat May 15 08:16:30 2021
From: aph at redhat.com (Andrew Haley)
Date: Sat, 15 May 2021 09:16:30 +0100
Subject: JEP draft: Scope Locals
In-Reply-To: 
References: 
 
 <7220447e-b2c5-7199-655c-aee364c78b35@oracle.com>
 
 
Message-ID: 

On 5/15/21 12:28 AM, Nathan Reynolds wrote:
> What about cleanup of the scoped objects?  For example, how do I ensure
> close() or some cleanup method is called at the right time on the scoped
> object?  Do I need to use a Weak/Soft/PhantomReference and a ReferenceQueue
> to track the object?  Do I use Cleaner?  Does the object need to implement
> finalize()... hopefully not?

All a scope local does is bind a value to a name, in a scope. This isn't
about C++-style destructors, which have their merits but are a different
subject.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From scolebourne at openjdk.java.net  Sat May 15 08:27:06 2021
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Sat, 15 May 2021 08:27:06 GMT
Subject: RFR: 8266846: Add java.time.InstantSource
Message-ID: 

8266846: Add java.time.InstantSource

-------------

Commit messages:
 - 8266846: Add java.time.InstantSource
 - 8266846: Add java.time.InstantSource

Changes: https://git.openjdk.java.net/jdk/pull/4016/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4016&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266846
  Stats: 615 lines in 4 files changed: 519 ins; 83 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4016.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4016/head:pull/4016

PR: https://git.openjdk.java.net/jdk/pull/4016

From github.com+15714253+anthonyvdotbe at openjdk.java.net  Sat May 15 08:27:07 2021
From: github.com+15714253+anthonyvdotbe at openjdk.java.net (Anthony Vanelverdinghe)
Date: Sat, 15 May 2021 08:27:07 GMT
Subject: RFR: 8266846: Add java.time.InstantSource
In-Reply-To: 
References: 
Message-ID: 

On Thu, 13 May 2021 20:52:33 GMT, Stephen Colebourne  wrote:

> 8266846: Add java.time.InstantSource

A nice addition to the JDK, thanks for taking this on.

src/java.base/share/classes/java/time/Clock.java line 114:

> 112:  * provides access to the current instant, and does not provide access to the time-zone.
> 113:  * Where an application only requires the current instant {@code InstantSource} should
> 114:  * be preferred to this class. For example, his might be the case where the time-zone

his -> this

src/java.base/share/classes/java/time/Clock.java line 513:

> 511:      * {@link System#currentTimeMillis()} or equivalent.
> 512:      */
> 513:     static final class SystemInstantSource implements InstantSource, Serializable {

Is it possible to declare this as an enum? As doing so would simplify its implementation.

src/java.base/share/classes/java/time/InstantSource.java line 59:

> 57:  *  }
> 58:  *
> 59: * This approach allows an alternate source, such as {@link #fixed(Instant) fixed} alternate -> alternative? To me (being a non-native speaker) the latter reads more naturally src/java.base/share/classes/java/time/InstantSource.java line 62: > 60: * or {@link #offset(InstantSource, Duration) offset} to be used during testing. > 61: *

> 62: * The {@code system} factory method provide a source based on the best available provide -> provides src/java.base/share/classes/java/time/InstantSource.java line 63: > 61: *

> 62: * The {@code system} factory method provide a source based on the best available > 63: * system clock This may use {@link System#currentTimeMillis()}, or a higher missing dot after "clock" src/java.base/share/classes/java/time/InstantSource.java line 175: > 173: /** > 174: * Obtains a source that returns instants from the specified source with the > 175: * specified duration added missing dot to end the sentence ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From naoto at openjdk.java.net Sat May 15 08:27:08 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sat, 15 May 2021 08:27:08 GMT Subject: RFR: 8266846: Add java.time.InstantSource In-Reply-To: References: Message-ID: <3RgsdS1BjtqSoQ807YfEYpjIX-6wBq3sujK-HowGDXI=.49067a6b-7638-4ac6-92d6-c4f89bcc2b00@github.com> On Thu, 13 May 2021 20:52:33 GMT, Stephen Colebourne wrote: > 8266846: Add java.time.InstantSource src/java.base/share/classes/java/time/Clock.java line 2: > 1: /* > 2: * Copyright (c) 2012, 2019, 2021, Oracle and/or its affiliates. All rights reserved. `2019, ` should be removed. src/java.base/share/classes/java/time/Clock.java line 115: > 113: * Where an application only requires the current instant {@code InstantSource} should > 114: * be preferred to this class. For example, his might be the case where the time-zone > 115: * is provided by a separate user localization subsystem. `@see InstantSource` would be preferred here. src/java.base/share/classes/java/time/InstantSource.java line 32: > 30: import java.time.Clock.SystemClock; > 31: import java.time.Clock.SystemInstantSource; > 32: import java.time.Clock.TickClock; Some of them are not used. src/java.base/share/classes/java/time/InstantSource.java line 112: > 110: * @return a source that uses the best available system clock, not null > 111: */ > 112: public static InstantSource system() { `public` is redundant here, same for other methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From scolebourne at openjdk.java.net Sat May 15 08:27:09 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Sat, 15 May 2021 08:27:09 GMT Subject: RFR: 8266846: Add java.time.InstantSource In-Reply-To: References: Message-ID: On Fri, 14 May 2021 07:19:03 GMT, Anthony Vanelverdinghe wrote: >> 8266846: Add java.time.InstantSource > > src/java.base/share/classes/java/time/Clock.java line 513: > >> 511: * {@link System#currentTimeMillis()} or equivalent. >> 512: */ >> 513: static final class SystemInstantSource implements InstantSource, Serializable { > > Is it possible to declare this as an enum? As doing so would simplify its implementation. My feeling is that in this case it is better to keep control of the kind of class being used. ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From github.com+297150+michaelhixson at openjdk.java.net Sat May 15 08:27:10 2021 From: github.com+297150+michaelhixson at openjdk.java.net (Michael Hixson) Date: Sat, 15 May 2021 08:27:10 GMT Subject: RFR: 8266846: Add java.time.InstantSource In-Reply-To: References: Message-ID: <7sYlP_DfsD6FK-xQWdvaO3HeT6cHita3FekibbG9q34=.aaaf3728-26cb-4029-ae3a-e699256f430c@github.com> On Thu, 13 May 2021 20:52:33 GMT, Stephen Colebourne wrote: > 8266846: Add java.time.InstantSource src/java.base/share/classes/java/time/InstantSource.java line 68: > 66: * @implSpec > 67: * This interface must be implemented with care to ensure other classes operate correctly. > 68: * All implementations that can be instantiated must be final, immutable and thread-safe. (I'm not an openjdk reviewer) I'm wondering if we can revisit this "immutable" requirement as it is being shuffled from `Clock` to `InstantSource`. This precludes an implementation that might be useful for testing, where the time provided by a single `InstantSource` instance can be adjusted manually in the test code. To me that is a notable downside (worth breaking the contract for), and it's not so clear what the upside is. "Immutable" seems like an odd way to describe the system clock anyway. Do you know if the people who already use their own `InstantSource` / `TimeSource` / `Supplier` have a mutable version that they use in tests? I would be surprised if they're all satisfied with `InstantSource.fixed`, but perhaps my intuition is wrong here. ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From aph at redhat.com Sat May 15 08:29:22 2021 From: aph at redhat.com (Andrew Haley) Date: Sat, 15 May 2021 09:29:22 +0100 Subject: JEP draft: Scope Locals In-Reply-To: References: Message-ID: <134e8452-d279-a6b3-0fa7-c8eb1bc8471c@redhat.com> On 5/14/21 8:19 PM, Mike Rettig wrote: > I don't see a way to capture the lifecycle of the scoped variable. I think > for framework designers it's going to be important to know the life cycle > of the scoped variable especially with snapshotting and inheritance. The > lack of a defined life cycle for thread locals is one of the many reasons > why it should be avoided. This requirement sounds similar, but I think it's really a different idea. Scope locals are only binding data to names and don't attempt to handle lifetime issues. Apart from anything else, that would require a more heavyweight mechanism than scope locals, which need to be very lightweight for some applications. Over at Loom we've been talking about lifetimes and Ron has some ideas, but scope locals are not likely to be that thing. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Sat May 15 10:35:16 2021 From: aph at redhat.com (Andrew Haley) Date: Sat, 15 May 2021 11:35:16 +0100 Subject: JEP draft: Scope Locals In-Reply-To: References: <7220447e-b2c5-7199-655c-aee364c78b35@oracle.com> Message-ID: On 5/15/21 10:10 AM, Alex Otenko wrote: > ScopeLocal.where(...).run(...).finally(...) would be nice. Is that different from try ... run ... finally ? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From forax at univ-mlv.fr Sat May 15 17:15:02 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 15 May 2021 19:15:02 +0200 (CEST) Subject: JEP draft: Scope Locals In-Reply-To: References: Message-ID: <1564558114.876437.1621098902738.JavaMail.zimbra@u-pem.fr> Apart the performance, threadLocal has currently two issues that are addressed by scope locals. ThreadLocal let the programmer defines the lifecycle, while it seems great on paper, it's a huge mess in reality. Because not everybody wraps the calls to set()/remove() in a try/finally, so the values inside thread locals are not reclaimed by the GC. It was less an issue before pooling because all the values are reclaimed when the thread die, but with pooling, threads do not die. (I think this is the point made by Brian about ThreadLocal not interacting smoothly with ThreadLocal) InheritableThreadLocal copies everything each time a new thread is created, again this lead to memory leaks because if an unexpected threads is created, sadly some libraries do that, all values are now referenced by this new thread that may never die. If you want more https://www.google.com/search?hl=en&q=ThreadLocal%20memory%20leak I think the JEP should be more explicit about the shortcoming of ThreadLocal and how the design of scope local fix both issues. R?mi ----- Mail original ----- > De: "Brian Goetz" > ?: "Andrew Haley" , "core-libs-dev" , "loom-dev" > > Envoy?: Mercredi 12 Mai 2021 20:57:33 > Objet: Re: JEP draft: Scope Locals > Scope locals have come together nicely. > > I have some vague thoughts on the presentation of the JEP draft.? There > are (at least) three intertwined things in the motivation: > > ?- ThreadLocal (and ITL especially) were always compromises, and with > the advent of Loom, have become untenable -- but the need for implicit > parameters has not gone away > ?- Scoped locals, because of their effective finality and dynamic > scoping, offer a programming model that is a better fit for virtual > threads, but, even in the absence of virtual threads, are an enabler for > structured concurrency > ?- The programming model constraints enable a better-performing > implementation > > In reading the draft, these separate motivations seem somewhat tangled. > All the words make sense, but a reader has a hard time coming away with > a clear picture of "so, why did we do this exactly, besides that its > cool and faster?" > > A possible way to untangle this is: > > ?- the underlying use cases: various forms of implicit context > (transaction context, implicit parameters, leaving breadcrumbs for your > future self.) > ?- the existing solution: thread locals.? ThreadLocals are effectively > mutable per-thread globals.? The unconstrained mutability makes them > hard to optimize.? ThreadLocals interact poorly with pooled threads. > ?- Here comes Loom!? We no longer need to pool threads.? So, why are > TLs not good enough? > ?- The more constrained programming model of SLs enables two big new > benefits: > ?? - structured concurrency, which is applicable to virtual and > non-virtual threads alike > ?? - better optimization of inheritance and get operations > > > > > > > > On 5/12/2021 10:42 AM, Andrew Haley wrote: >> There's been considerable discussion about scope locals on the loom-dev list, >> and it's now time to open this to a wider audience. This subject is important >> because. although scope locals were motivated by the the needs of Loom, they >> have many potential applications outside that project. >> >> The draft JEP is at >> >> https://bugs.openjdk.java.net/browse/JDK-8263012 >> >> I've already received some very helpful suggestions for enhancements to >> the API, and it'll take me a while to work through them all. In particular, >> Paul Sandoz has suggested that I unify the classes Snapshot and Carrier, >> and it will take me some time to understand the consequences of that. >> >> In the meantime, please have a look at the JEP and comment here. >> >> >> For reference, earlier discussions are at >> >> https://mail.openjdk.java.net/pipermail/loom-dev/2021-March/002268.html >> https://mail.openjdk.java.net/pipermail/loom-dev/2021-April/002287.html >> https://mail.openjdk.java.net/pipermail/loom-dev/2021-May/002427.html From peter.levart at gmail.com Sat May 15 17:50:37 2021 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 15 May 2021 19:50:37 +0200 Subject: JEP draft: Scope Locals In-Reply-To: References: Message-ID: Hi, So if scopeLocal.get() is called in a thread outside any .run() scope in that thread, it will throw exception and scopeLocal.isBound() will return false. Unless it was called on an inheritableScopeLocal which inherited binding from parent thread. What if I wanted to create and start a thread that would be "pristine" - not have any ScopeLocal value bound? Is this intentionally not allowed in order to make sure that inheritable ScopeLocal(s) can't be cleared by code that has no access to ScopeLocal instance(s)? Another question: Suppose there are two inheritable ScopeLocal variables with bound values in scope (A and B) when I take a snapshot: var snapshot = ScopeLocal.snapshot(); now I pass that snapshot to a thread which does the following: ScopeLocal ??? .where(C, "value for C") ??? .run(() -> { ??? ??? System.out.printf("A:%s B:%s C:%s\n", A.isBound(), B.isBound(), C.isBound()); ??? ??? ScopeLocal.runWithSnapshot?(() -> { ??? ??? ??? System.out.printf("A:%s B:%s C:%s\n", A.isBound(), B.isBound(), C.isBound()); ??? ??? }, snapshot); ??? ??? System.out.printf("A:%s B:%s C:%s\n", A.isBound(), B.isBound(), C.isBound()); ??? }); What would this code print? ...in other words, does runWithSnapshot replace the whole set of bound values or does it merge it with existing set? Peter On 5/12/21 4:42 PM, Andrew Haley wrote: > There's been considerable discussion about scope locals on the loom-dev list, > and it's now time to open this to a wider audience. This subject is important > because. although scope locals were motivated by the the needs of Loom, they > have many potential applications outside that project. > > The draft JEP is at > > https://bugs.openjdk.java.net/browse/JDK-8263012 > > I've already received some very helpful suggestions for enhancements to > the API, and it'll take me a while to work through them all. In particular, > Paul Sandoz has suggested that I unify the classes Snapshot and Carrier, > and it will take me some time to understand the consequences of that. > > In the meantime, please have a look at the JEP and comment here. > > > For reference, earlier discussions are at > > https://mail.openjdk.java.net/pipermail/loom-dev/2021-March/002268.html > https://mail.openjdk.java.net/pipermail/loom-dev/2021-April/002287.html > https://mail.openjdk.java.net/pipermail/loom-dev/2021-May/002427.html > From github.com+6502015+ineuwirth at openjdk.java.net Sat May 15 21:01:40 2021 From: github.com+6502015+ineuwirth at openjdk.java.net (Istvan Neuwirth) Date: Sat, 15 May 2021 21:01:40 GMT Subject: RFR: 8266846: Add java.time.InstantSource In-Reply-To: References: Message-ID: <320w2F0BxUEMhMEavzjP_I76VtziOiJ63VgJT_OcwFY=.197a39dd-247f-4577-a6d6-4f6a7eaef931@github.com> On Thu, 13 May 2021 20:52:33 GMT, Stephen Colebourne wrote: > 8266846: Add java.time.InstantSource src/java.base/share/classes/java/time/InstantSource.java line 93: > 91: * @since 17 > 92: */ > 93: public interface InstantSource { Should not we add `@FunctionalInterface`? I can easily imagine this interface being used in tests where we can define the `InstantSource` with lambdas. ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From github.com+120415+rgoers at openjdk.java.net Sat May 15 21:42:41 2021 From: github.com+120415+rgoers at openjdk.java.net (Ralph Goers) Date: Sat, 15 May 2021 21:42:41 GMT Subject: RFR: 8266846: Add java.time.InstantSource In-Reply-To: References: Message-ID: On Thu, 13 May 2021 20:52:33 GMT, Stephen Colebourne wrote: > 8266846: Add java.time.InstantSource Can you possibly find a way that this can be used in a garbage free manner? Providing a MutableInstant interface that allows the Instant object to be provided and have its values set by a currentInstant(MutableInstant instant) method would solve the problem nicely for Log4j - or any other app that is trying to avoid allocating new objects. ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From alanb at openjdk.java.net Sun May 16 15:56:47 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 16 May 2021 15:56:47 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes [v7] In-Reply-To: References: <7DNAsNlR9qOFQ60l-pSzc1SfH9GdecjrZ9re51Jo9vQ=.54273097-3573-4d4d-98b4-d29a964a41ad@github.com> Message-ID: <0F98GniFLyNTyBeajSIUafPIb8oPKRZbssoFe3gMSlk=.5846ddbe-29df-4782-97a1-55cc6b9a25b4@github.com> On Fri, 14 May 2021 15:57:48 GMT, Brian Burkhalter wrote: > Any more comments on this? Thanks. I think you've addressed the obvious bugs now but I'm still nervous that the lseek will fail for some special devices (time will tell). It would be good to do some cleanup on the test before you integrate this. If you change it to use try-with-resources will it will avoid leaving the file open when the test fails. Also would be good to add a test for readNBytes(0) for the empty-file case. There's a typo in one of the exception messages ("expecte"). ------------- PR: https://git.openjdk.java.net/jdk/pull/3845 From scolebourne at openjdk.java.net Mon May 17 07:34:40 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Mon, 17 May 2021 07:34:40 GMT Subject: RFR: 8266846: Add java.time.InstantSource In-Reply-To: <320w2F0BxUEMhMEavzjP_I76VtziOiJ63VgJT_OcwFY=.197a39dd-247f-4577-a6d6-4f6a7eaef931@github.com> References: <320w2F0BxUEMhMEavzjP_I76VtziOiJ63VgJT_OcwFY=.197a39dd-247f-4577-a6d6-4f6a7eaef931@github.com> Message-ID: On Sat, 15 May 2021 20:53:28 GMT, Istvan Neuwirth wrote: >> 8266846: Add java.time.InstantSource > > src/java.base/share/classes/java/time/InstantSource.java line 93: > >> 91: * @since 17 >> 92: */ >> 93: public interface InstantSource { > > Should not we add `@FunctionalInterface`? I can easily imagine this interface being used in tests where we can define the `InstantSource` with lambdas. `@FunctionalInterface` isn't required for use by lambdas. I wasn't initially convinced using it here was the right choice. ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From scolebourne at openjdk.java.net Mon May 17 07:41:22 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Mon, 17 May 2021 07:41:22 GMT Subject: RFR: 8266846: Add java.time.InstantSource In-Reply-To: References: Message-ID: On Sat, 15 May 2021 21:32:54 GMT, Ralph Goers wrote: >> 8266846: Add java.time.InstantSource > > Can you possibly find a way that this can be used in a garbage free manner? Providing a MutableInstant interface that allows the Instant object to be provided and have its values set by a currentInstant(MutableInstant instant) method would solve the problem nicely for Log4j - or any other app that is trying to avoid allocating new objects. I believe this also aligns with what [Michael Hixson](https://github.com/michaelhixson) is asking for. > > An alternative would be for java.time to maintain a pool of Instants that apps like Log4j can somehow control, but that would seem far more complicated. @rgoers Michael's request has been handled, which was a simple change to the wording. What you need cannot be accomplished because `Instant` has a restricted design due to the Valhalla project. A `MutableInstant` class can have its own `now()` method that does whatever is necessary to initialize it, so there is no need to refer to it here. ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From github.com+828220+forax at openjdk.java.net Mon May 17 07:46:43 2021 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Mon, 17 May 2021 07:46:43 GMT Subject: RFR: 8266846: Add java.time.InstantSource In-Reply-To: References: <320w2F0BxUEMhMEavzjP_I76VtziOiJ63VgJT_OcwFY=.197a39dd-247f-4577-a6d6-4f6a7eaef931@github.com> Message-ID: On Mon, 17 May 2021 07:31:45 GMT, Stephen Colebourne wrote: >> src/java.base/share/classes/java/time/InstantSource.java line 93: >> >>> 91: * @since 17 >>> 92: */ >>> 93: public interface InstantSource { >> >> Should not we add `@FunctionalInterface`? I can easily imagine this interface being used in tests where we can define the `InstantSource` with lambdas. > > `@FunctionalInterface` isn't required for use by lambdas. I wasn't initially convinced using it here was the right choice. Right, it's about signaling that it's safe to be used with a lambda/method-reference, so it's not required but a nice to have, very like @Override. ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From scolebourne at openjdk.java.net Mon May 17 07:53:40 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Mon, 17 May 2021 07:53:40 GMT Subject: RFR: 8266846: Add java.time.InstantSource In-Reply-To: References: Message-ID: On Thu, 13 May 2021 20:52:33 GMT, Stephen Colebourne wrote: > 8266846: Add java.time.InstantSource It would good to get confirmation in the review from @dholmes-ora or Mark Kralj-Taylor that my changes to the precise system clock are correct. Specifically, I moved the code from instance to static. I don't believe this changes the thread-safety, but it does need double checking (there was no discussion in the original thread concerning instance vs static). Original thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066670.html ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From jbhateja at openjdk.java.net Mon May 17 12:06:33 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 17 May 2021 12:06:33 GMT Subject: RFR: 8266054: VectorAPI rotate operation optimization [v6] In-Reply-To: References: Message-ID: > Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:- > > vec1 = lanewise(VectorOperators.LSHL, n) > vec2 = lanewise(VectorOperators.LSHR, n) > res = lanewise(VectorOperations.OR, vec1 , vec2) > > This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction. > > AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations ) instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted. > > Please find below the performance data for included JMH benchmark. > Machine: Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz) > > > Benchmark | (TESTSIZE) | Shift | Baseline AVX3 (ops/ms) | Withopt? AVX3 (ops/ms) | Gain % | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain % > -- | -- | -- | -- | -- | -- | -- | -- | -- > ? | ? | ? | ? | ? | ? | ? | ? | ? > RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 17223.35 | 17094.69 | -0.75 | 17008.32 | 17488.06 | 2.82 > RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 8944.98 | 8811.34 | -1.49 | 8878.17 | 9218.68 | 3.84 > RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 17195.75 | 17137.32 | -0.34 | 16789.01 | 17780.34 | 5.90 > RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 9052.67 | 8838.60 | -2.36 | 8814.62 | 9206.01 | 4.44 > RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 17100.19 | 16950.64 | -0.87 | 16827.73 | 17720.37 | 5.30 > RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 9079.95 | 8471.26 | -6.70 | 8888.44 | 9167.68 | 3.14 > RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 21231.33 | 21513.08 | 1.33 | 21824.51 | 21479.48 | -1.58 > RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 11103.62 | 11180.16 | 0.69 | 11173.67 | 11529.22 | 3.18 > RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 21119.14 | 21552.04 | 2.05 | 21693.05 | 21915.37 | 1.02 > RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 11048.68 | 11094.20 | 0.41 | 11049.90 | 11439.07 | 3.52 > RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 21506.31 | 21391.41 | -0.53 | 21263.18 | 21986.29 | 3.40 > RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 11056.12 | 11232.78 | 1.60 | 10941.59 | 11397.09 | 4.16 > RotateBenchmark.testRotateLeftB | 512.00 | 7.00 | 17976.56 | 18180.85 | 1.14 | 1212.26 | 2533.34 | 108.98 > RotateBenchmark.testRotateLeftB | 512.00 | 15.00 | 17553.70 | 18219.07 | 3.79 | 1256.73 | 2537.41 | 101.91 > RotateBenchmark.testRotateLeftB | 512.00 | 31.00 | 17618.03 | 17738.15 | 0.68 | 1214.69 | 2533.83 | 108.60 > RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 7258.87 | 7468.88 | 2.89 | 7115.12 | 7117.26 | 0.03 > RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 3586.65 | 3950.85 | 10.15 | 3532.17 | 3595.80 | 1.80 > RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 1835.07 | 1999.68 | 8.97 | 1789.90 | 1819.93 | 1.68 > RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 7273.36 | 7410.91 | 1.89 | 7198.60 | 6994.79 | -2.83 > RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 3674.98 | 3926.27 | 6.84 | 3549.90 | 3755.09 | 5.78 > RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 1840.94 | 1882.25 | 2.24 | 1801.56 | 1872.89 | 3.96 > RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 7457.11 | 7361.48 | -1.28 | 6975.33 | 7385.94 | 5.89 > RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 3570.74 | 3929.30 | 10.04 | 3635.37 | 3736.67 | 2.79 > RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 1902.32 | 1960.46 | 3.06 | 1812.32 | 1813.88 | 0.09 > RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 11174.24 | 12044.52 | 7.79 | 11509.87 | 11273.44 | -2.05 > RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 5981.47 | 6073.70 | 1.54 | 5593.66 | 5661.93 | 1.22 > RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 2932.49 | 3069.54 | 4.67 | 2950.86 | 2892.42 | -1.98 > RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 11764.11 | 12098.63 | 2.84 | 11069.52 | 11476.93 | 3.68 > RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 5855.20 | 6080.40 | 3.85 | 5919.11 | 5607.04 | -5.27 > RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 2989.05 | 3048.56 | 1.99 | 2902.63 | 2821.83 | -2.78 > RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 11652.84 | 11965.40 | 2.68 | 11525.62 | 11459.83 | -0.57 > RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 5851.82 | 6164.94 | 5.35 | 5882.60 | 5842.30 | -0.69 > RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 3015.99 | 3043.79 | 0.92 | 2963.71 | 2947.97 | -0.53 > RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 16029.15 | 16189.79 | 1.00 | 860.43 | 2339.32 | 171.88 > RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 8078.25 | 8081.84 | 0.04 | 427.39 | 1147.92 | 168.59 > RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 4021.49 | 4294.03 | 6.78 | 209.25 | 582.28 | 178.27 > RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 15912.98 | 16329.03 | 2.61 | 848.23 | 2296.78 | 170.77 > RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 8054.10 | 8306.37 | 3.13 | 429.93 | 1146.90 | 166.77 > RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 4102.58 | 4071.08 | -0.77 | 217.86 | 582.20 | 167.24 > RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 16177.79 | 16287.85 | 0.68 | 857.84 | 2243.15 | 161.49 > RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 8187.47 | 8410.48 | 2.72 | 434.60 | 1128.20 | 159.60 > RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 4109.15 | 4233.80 | 3.03 | 208.71 | 572.43 | 174.27 > RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 3755.09 | 3930.29 | 4.67 | 3604.19 | 3598.47 | -0.16 > RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 1829.03 | 1957.39 | 7.02 | 1833.95 | 1808.38 | -1.39 > RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 915.35 | 970.55 | 6.03 | 916.25 | 899.08 | -1.87 > RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 3664.85 | 3812.26 | 4.02 | 3629.37 | 3579.23 | -1.38 > RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 1829.51 | 1877.76 | 2.64 | 1781.05 | 1807.57 | 1.49 > RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 913.37 | 953.42 | 4.38 | 912.26 | 908.73 | -0.39 > RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 3648.45 | 3899.20 | 6.87 | 3552.67 | 3581.04 | 0.80 > RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 1816.50 | 1959.68 | 7.88 | 1820.88 | 1819.71 | -0.06 > RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 901.05 | 955.13 | 6.00 | 913.74 | 907.90 | -0.64 > RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 5850.99 | 6108.64 | 4.40 | 5882.65 | 5755.21 | -2.17 > RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 2962.21 | 3060.47 | 3.32 | 2955.20 | 2909.18 | -1.56 > RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 1480.46 | 1534.72 | 3.66 | 1467.78 | 1430.60 | -2.53 > RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 5858.23 | 6047.51 | 3.23 | 5770.02 | 5773.19 | 0.05 > RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 2951.49 | 3096.53 | 4.91 | 2885.21 | 2899.31 | 0.49 > RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 1486.26 | 1527.94 | 2.80 | 1441.93 | 1454.25 | 0.85 > RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 5873.21 | 6089.75 | 3.69 | 5767.58 | 5664.11 | -1.79 > RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 2969.67 | 3081.39 | 3.76 | 2878.50 | 2905.86 | 0.95 > RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 1452.21 | 1520.03 | 4.67 | 1430.30 | 1485.63 | 3.87 > RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 8088.65 | 8443.63 | 4.39 | 455.67 | 1226.33 | 169.13 > RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 4011.95 | 4120.25 | 2.70 | 229.77 | 619.87 | 169.77 > RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 2090.57 | 2109.53 | 0.91 | 115.21 | 310.36 | 169.37 > RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 8166.84 | 8557.28 | 4.78 | 457.67 | 1242.86 | 171.56 > RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 4137.02 | 4287.95 | 3.65 | 227.26 | 624.80 | 174.93 > RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 2095.01 | 2102.86 | 0.37 | 114.26 | 310.83 | 172.03 > RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 8082.68 | 8400.56 | 3.93 | 459.59 | 1230.07 | 167.64 > RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 4047.67 | 4147.58 | 2.47 | 229.01 | 606.38 | 164.78 > RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 2086.83 | 2126.72 | 1.91 | 111.93 | 305.66 | 173.08 > RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 13597.19 | 13255.09 | -2.52 | 13818.39 | 13242.40 | -4.17 > RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 7028.26 | 6826.59 | -2.87 | 6765.15 | 6907.87 | 2.11 > RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 3570.40 | 3468.01 | -2.87 | 3449.66 | 3533.50 | 2.43 > RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 13615.99 | 13464.40 | -1.11 | 13330.02 | 13870.57 | 4.06 > RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 7043.31 | 6763.34 | -3.97 | 6928.88 | 7063.57 | 1.94 > RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 3495.12 | 3537.62 | 1.22 | 3503.41 | 3457.67 | -1.31 > RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 13591.66 | 13665.84 | 0.55 | 13773.27 | 13126.08 | -4.70 > RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 7027.08 | 7011.24 | -0.23 | 6974.98 | 6815.50 | -2.29 > RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 3568.28 | 3569.62 | 0.04 | 3580.67 | 3463.58 | -3.27 > RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 21154.03 | 21416.32 | 1.24 | 21187.01 | 21401.61 | 1.01 > RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 11194.24 | 10865.47 | -2.94 | 11063.19 | 10977.60 | -0.77 > RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 5797.80 | 5523.94 | -4.72 | 5654.63 | 5468.78 | -3.29 > RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 21333.89 | 21412.74 | 0.37 | 21610.94 | 20908.96 | -3.25 > RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 11327.07 | 11113.48 | -1.89 | 11148.25 | 10678.14 | -4.22 > RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 5810.69 | 5569.72 | -4.15 | 5663.26 | 5618.87 | -0.78 > RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 21753.20 | 21198.43 | -2.55 | 21567.90 | 21929.81 | 1.68 > RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 11517.08 | 11039.64 | -4.15 | 11103.08 | 10871.59 | -2.08 > RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 5897.16 | 5606.75 | -4.92 | 5459.87 | 5604.12 | 2.64 > RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 29748.53 | 28883.73 | -2.91 | 1549.02 | 3928.53 | 153.61 > RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 15197.09 | 15878.19 | 4.48 | 772.59 | 1924.35 | 149.08 > RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 8046.30 | 8081.19 | 0.43 | 388.11 | 990.28 | 155.16 > RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 30618.04 | 29419.19 | -3.92 | 1524.22 | 3915.97 | 156.92 > RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 15854.43 | 15846.37 | -0.05 | 766.09 | 1953.60 | 155.01 > RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 7814.77 | 7899.30 | 1.08 | 390.82 | 970.37 | 148.29 > RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 29596.82 | 28538.69 | -3.58 | 1530.45 | 3906.91 | 155.28 > RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 15662.48 | 15849.25 | 1.19 | 778.08 | 1934.31 | 148.60 > RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 8121.14 | 7758.59 | -4.46 | 392.78 | 959.73 | 144.34 > RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 17465.84 | 17069.34 | -2.27 | 16849.73 | 17842.08 | 5.89 > RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 9049.19 | 8864.15 | -2.04 | 8786.67 | 9105.34 | 3.63 > RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 17703.38 | 17070.98 | -3.57 | 16595.85 | 17784.68 | 7.16 > RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 9007.68 | 8817.41 | -2.11 | 8704.49 | 9185.87 | 5.53 > RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 17531.05 | 16983.40 | -3.12 | 16947.69 | 17655.40 | 4.18 > RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 8986.30 | 8794.15 | -2.14 | 8816.62 | 9225.95 | 4.64 > RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 21293.95 | 21506.74 | 1.00 | 21163.29 | 21854.03 | 3.26 > RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 11258.47 | 11072.92 | -1.65 | 11118.12 | 11338.96 | 1.99 > RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 21253.36 | 21292.37 | 0.18 | 21224.39 | 21763.88 | 2.54 > RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 11064.80 | 11198.35 | 1.21 | 10960.98 | 11294.14 | 3.04 > RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 21358.14 | 21346.21 | -0.06 | 21487.25 | 21854.42 | 1.71 > RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 11045.61 | 11208.26 | 1.47 | 10907.03 | 11415.18 | 4.66 > RotateBenchmark.testRotateRightB | 512.00 | 7.00 | 17898.61 | 18307.54 | 2.28 | 1214.65 | 2546.64 | 109.66 > RotateBenchmark.testRotateRightB | 512.00 | 15.00 | 17909.25 | 18242.51 | 1.86 | 1215.05 | 2563.98 | 111.02 > RotateBenchmark.testRotateRightB | 512.00 | 31.00 | 17883.35 | 17928.44 | 0.25 | 1220.77 | 2543.30 | 108.34 > RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 7139.97 | 7626.72 | 6.82 | 6994.86 | 7075.65 | 1.15 > RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 3657.37 | 3898.34 | 6.59 | 3617.06 | 3576.12 | -1.13 > RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 1804.26 | 1969.19 | 9.14 | 1796.62 | 1858.84 | 3.46 > RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 7404.31 | 7760.09 | 4.80 | 7036.77 | 7401.52 | 5.18 > RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 3600.52 | 3956.35 | 9.88 | 3595.28 | 3560.36 | -0.97 > RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 1813.32 | 1966.41 | 8.44 | 1839.95 | 1852.53 | 0.68 > RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 7118.48 | 7724.81 | 8.52 | 7151.56 | 7021.09 | -1.82 > RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 3529.70 | 3881.63 | 9.97 | 3623.08 | 3601.01 | -0.61 > RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 1823.61 | 1961.34 | 7.55 | 1786.86 | 1748.85 | -2.13 > RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 11697.98 | 11835.25 | 1.17 | 11513.16 | 11184.87 | -2.85 > RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 5890.11 | 6102.57 | 3.61 | 5658.79 | 5696.08 | 0.66 > RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 2964.94 | 3070.26 | 3.55 | 2945.00 | 2962.08 | 0.58 > RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 11562.51 | 12151.29 | 5.09 | 11404.17 | 11120.28 | -2.49 > RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 5702.93 | 6130.57 | 7.50 | 5799.54 | 5779.08 | -0.35 > RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 2861.96 | 3051.44 | 6.62 | 2943.99 | 2860.65 | -2.83 > RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 11203.13 | 11710.59 | 4.53 | 11363.18 | 11112.16 | -2.21 > RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 5893.97 | 6070.71 | 3.00 | 5776.67 | 5648.84 | -2.21 > RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 2971.83 | 3046.76 | 2.52 | 2903.35 | 2833.88 | -2.39 > RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 16064.71 | 15851.35 | -1.33 | 861.93 | 2256.88 | 161.84 > RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 7916.80 | 8462.65 | 6.89 | 430.23 | 1147.30 | 166.67 > RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 4104.64 | 4068.28 | -0.89 | 216.30 | 572.86 | 164.84 > RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 16133.09 | 16281.59 | 0.92 | 856.36 | 2229.58 | 160.35 > RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 8127.26 | 8117.59 | -0.12 | 419.16 | 1176.42 | 180.66 > RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 4080.11 | 4063.26 | -0.41 | 218.32 | 571.93 | 161.97 > RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 15834.26 | 16314.64 | 3.03 | 865.96 | 2297.74 | 165.34 > RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 7965.62 | 8270.48 | 3.83 | 428.55 | 1148.87 | 168.08 > RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 4161.69 | 4034.76 | -3.05 | 215.63 | 570.19 | 164.43 > RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 3556.70 | 3877.08 | 9.01 | 3596.46 | 3558.32 | -1.06 > RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 1772.93 | 1993.86 | 12.46 | 1856.79 | 1783.22 | -3.96 > RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 908.66 | 1000.37 | 10.09 | 944.79 | 922.91 | -2.32 > RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 3742.44 | 3748.41 | 0.16 | 3788.07 | 3570.67 | -5.74 > RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 1817.53 | 1985.69 | 9.25 | 1892.38 | 1833.16 | -3.13 > RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 941.03 | 952.68 | 1.24 | 915.79 | 910.21 | -0.61 > RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 3649.48 | 3896.56 | 6.77 | 3637.59 | 3557.53 | -2.20 > RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 1840.12 | 1997.19 | 8.54 | 1821.47 | 1799.82 | -1.19 > RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 901.33 | 995.67 | 10.47 | 909.20 | 902.73 | -0.71 > RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 5789.93 | 5960.54 | 2.95 | 5758.14 | 5736.30 | -0.38 > RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 2963.20 | 3063.30 | 3.38 | 2943.48 | 2833.84 | -3.72 > RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 1501.81 | 1510.23 | 0.56 | 1463.85 | 1462.26 | -0.11 > RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 5870.05 | 5951.43 | 1.39 | 5794.74 | 5604.58 | -3.28 > RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 2971.36 | 3047.00 | 2.55 | 2931.19 | 2907.30 | -0.82 > RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 1473.97 | 1530.54 | 3.84 | 1473.45 | 1442.40 | -2.11 > RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 5858.08 | 6080.49 | 3.80 | 5863.69 | 5549.85 | -5.35 > RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 2916.24 | 3045.77 | 4.44 | 2981.59 | 2815.07 | -5.58 > RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 1441.20 | 1531.56 | 6.27 | 1492.47 | 1473.25 | -1.29 > RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 8147.24 | 8310.05 | 2.00 | 469.45 | 1235.21 | 163.12 > RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 4142.95 | 4258.86 | 2.80 | 234.14 | 615.52 | 162.88 > RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 2095.48 | 2087.20 | -0.40 | 113.55 | 311.19 | 174.05 > RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 8222.94 | 8246.58 | 0.29 | 458.91 | 1244.32 | 171.15 > RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 4160.04 | 4226.46 | 1.60 | 227.78 | 625.38 | 174.56 > RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 2064.63 | 2162.44 | 4.74 | 113.27 | 314.15 | 177.36 > RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 8157.94 | 8466.90 | 3.79 | 450.26 | 1221.90 | 171.37 > RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 4039.74 | 4283.33 | 6.03 | 224.82 | 612.68 | 172.53 > RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 2066.88 | 2147.51 | 3.90 | 110.97 | 303.43 | 173.42 > RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 13548.39 | 13245.87 | -2.23 | 13490.93 | 13084.76 | -3.01 > RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 7020.16 | 6768.85 | -3.58 | 6991.39 | 7044.32 | 0.76 > RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 3550.50 | 3505.19 | -1.28 | 3507.12 | 3612.86 | 3.01 > RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 13743.43 | 13325.44 | -3.04 | 13696.15 | 13255.80 | -3.22 > RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 6856.02 | 6969.18 | 1.65 | 6886.29 | 6834.12 | -0.76 > RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 3569.53 | 3492.76 | -2.15 | 3539.02 | 3470.02 | -1.95 > RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 13704.18 | 13495.07 | -1.53 | 13649.14 | 13583.87 | -0.48 > RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 7011.77 | 6953.93 | -0.82 | 6978.28 | 6740.30 | -3.41 > RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 3591.62 | 3620.12 | 0.79 | 3502.04 | 3510.05 | 0.23 > RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 21950.71 | 22113.60 | 0.74 | 21484.27 | 21596.64 | 0.52 > RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 11616.88 | 11099.73 | -4.45 | 11188.29 | 10737.68 | -4.03 > RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 5872.72 | 5579.12 | -5.00 | 5784.05 | 5454.57 | -5.70 > RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 22017.83 | 20817.97 | -5.45 | 21934.65 | 21356.90 | -2.63 > RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 11414.27 | 11044.86 | -3.24 | 11454.35 | 11140.34 | -2.74 > RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 5786.64 | 5634.05 | -2.64 | 5724.93 | 5639.99 | -1.48 > RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 21754.77 | 21466.01 | -1.33 | 21140.67 | 21970.03 | 3.92 > RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 11676.46 | 11358.64 | -2.72 | 11204.90 | 11213.48 | 0.08 > RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 5728.20 | 5772.49 | 0.77 | 5594.33 | 5544.25 | -0.90 > RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 30247.03 | 30179.41 | -0.22 | 1538.75 | 3975.82 | 158.38 > RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 15988.73 | 15621.42 | -2.30 | 776.04 | 1910.91 | 146.24 > RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 8115.84 | 8025.28 | -1.12 | 389.12 | 984.46 | 152.99 > RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 30110.91 | 30200.69 | 0.30 | 1532.49 | 3983.77 | 159.95 > RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 15957.90 | 15690.73 | -1.67 | 774.90 | 1931.00 | 149.19 > RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 8113.26 | 8037.93 | -0.93 | 391.90 | 965.53 | 146.37 > RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 29816.97 | 29891.54 | 0.25 | 1538.12 | 3881.93 | 152.38 > RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 15405.95 | 15619.17 | 1.38 | 762.49 | 1871.00 | 145.38 > RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 7919.80 | 7957.35 | 0.47 | 393.63 | 972.49 | 147.06 Jatin Bhateja has updated the pull request incrementally with three additional commits since the last revision: - Merge branch 'JDK-8266054' of http://github.com/jatin-bhateja/jdk into JDK-8266054 - 8266054: Code reorganization for efficient sharing of logic to check rotate operation support on a target platform. - 8266054: Removing redundant test templates. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3720/files - new: https://git.openjdk.java.net/jdk/pull/3720/files/ef46c0a8..7969f19f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3720&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3720&range=04-05 Stats: 76 lines in 3 files changed: 28 ins; 43 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3720.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3720/head:pull/3720 PR: https://git.openjdk.java.net/jdk/pull/3720 From albest512 at hotmail.com Mon May 17 12:58:24 2021 From: albest512 at hotmail.com (=?iso-8859-1?Q?Alberto_Otero_Rodr=EDguez?=) Date: Mon, 17 May 2021 12:58:24 +0000 Subject: New java.util.Strings class Message-ID: Hi, members of the core-libs developers of OpenJDK. I think Java needs a Strings class similar to the java.util.Objects class of Java 16 to be used in method arguments, return types and Stream filters. I have coded it myself here based on the Objects implementation of Java 16 (please have a look): https://github.com/Aliuken/Java-Strings/blob/main/Strings.java In fact, I think it would be useful also adding annotations for method arguments and return types such as: - @NonNull - @NonNullElse(defaultValue) - @NonNullElseGet(class::supplierMethod) - @NonNullNorEmpty - @NonNullNorEmptyElse(defaultValue) - @NonNullNorEmptyElseGet(class::supplierMethod) With that kind of annotations, you could assume thinks like: - an argument or return type cannot have value null, but an Exception - an argument or return type cannot have value null, but a default value What do you think? Waiting for your response. PS: I am sending this email repeated. I have sended it yesterday with my other email account (alber84ou at gmail.com), but I wasn't a member of this mailing list. Now I have become a member with this other email account. Regards, Alberto Otero Rodr?guez. From erikj at openjdk.java.net Mon May 17 13:03:42 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 17 May 2021 13:03:42 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v4] In-Reply-To: References: Message-ID: On Sat, 15 May 2021 02:06:29 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. >> >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> Looking forward to your review and feedback. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > Add missing Lib.gmk Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3638 From asotona at openjdk.java.net Mon May 17 13:18:58 2021 From: asotona at openjdk.java.net (Adam Sotona) Date: Mon, 17 May 2021 13:18:58 GMT Subject: RFR: 8264561: javap get NegativeArraySizeException on bad instruction Message-ID: Actual javap implementation reacts on corrupted TABLESWITCH or LOOKUPSWITCH bytecode instructions resulting to negative array allocation with NegativeArraySizeException, which is reported to user with stack trace and as serious internal error. The fix in c.s.t.classfile.Instruction is checking for negative array size of corrupted TABLESWITCH or LOOKUPSWITCH bytecode and throwing j.l.IllegalStateException instead of the NegativeArraySizeException. Another part of the fix in c.s.t.javap.CodeWriter is catching j.l.IllegalStateException and reporting it as error in the analyzed bytecode, instead of passing it up and causing serious internal javap error. ------------- Commit messages: - 8264561: javap get NegativeArraySizeException on bad instruction Changes: https://git.openjdk.java.net/jdk/pull/4061/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4061&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264561 Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4061.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4061/head:pull/4061 PR: https://git.openjdk.java.net/jdk/pull/4061 From jbhateja at openjdk.java.net Mon May 17 13:23:36 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 17 May 2021 13:23:36 GMT Subject: RFR: 8266054: VectorAPI rotate operation optimization [v6] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 12:06:33 GMT, Jatin Bhateja wrote: >> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:- >> >> vec1 = lanewise(VectorOperators.LSHL, n) >> vec2 = lanewise(VectorOperators.LSHR, n) >> res = lanewise(VectorOperations.OR, vec1 , vec2) >> >> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction. >> >> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations ) instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted. >> >> Please find below the performance data for included JMH benchmark. >> Machine: Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz) >> >> >> Benchmark | (TESTSIZE) | Shift | Baseline AVX3 (ops/ms) | Withopt? AVX3 (ops/ms) | Gain % | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain % >> -- | -- | -- | -- | -- | -- | -- | -- | -- >> ? | ? | ? | ? | ? | ? | ? | ? | ? >> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 17223.35 | 17094.69 | -0.75 | 17008.32 | 17488.06 | 2.82 >> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 8944.98 | 8811.34 | -1.49 | 8878.17 | 9218.68 | 3.84 >> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 17195.75 | 17137.32 | -0.34 | 16789.01 | 17780.34 | 5.90 >> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 9052.67 | 8838.60 | -2.36 | 8814.62 | 9206.01 | 4.44 >> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 17100.19 | 16950.64 | -0.87 | 16827.73 | 17720.37 | 5.30 >> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 9079.95 | 8471.26 | -6.70 | 8888.44 | 9167.68 | 3.14 >> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 21231.33 | 21513.08 | 1.33 | 21824.51 | 21479.48 | -1.58 >> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 11103.62 | 11180.16 | 0.69 | 11173.67 | 11529.22 | 3.18 >> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 21119.14 | 21552.04 | 2.05 | 21693.05 | 21915.37 | 1.02 >> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 11048.68 | 11094.20 | 0.41 | 11049.90 | 11439.07 | 3.52 >> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 21506.31 | 21391.41 | -0.53 | 21263.18 | 21986.29 | 3.40 >> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 11056.12 | 11232.78 | 1.60 | 10941.59 | 11397.09 | 4.16 >> RotateBenchmark.testRotateLeftB | 512.00 | 7.00 | 17976.56 | 18180.85 | 1.14 | 1212.26 | 2533.34 | 108.98 >> RotateBenchmark.testRotateLeftB | 512.00 | 15.00 | 17553.70 | 18219.07 | 3.79 | 1256.73 | 2537.41 | 101.91 >> RotateBenchmark.testRotateLeftB | 512.00 | 31.00 | 17618.03 | 17738.15 | 0.68 | 1214.69 | 2533.83 | 108.60 >> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 7258.87 | 7468.88 | 2.89 | 7115.12 | 7117.26 | 0.03 >> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 3586.65 | 3950.85 | 10.15 | 3532.17 | 3595.80 | 1.80 >> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 1835.07 | 1999.68 | 8.97 | 1789.90 | 1819.93 | 1.68 >> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 7273.36 | 7410.91 | 1.89 | 7198.60 | 6994.79 | -2.83 >> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 3674.98 | 3926.27 | 6.84 | 3549.90 | 3755.09 | 5.78 >> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 1840.94 | 1882.25 | 2.24 | 1801.56 | 1872.89 | 3.96 >> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 7457.11 | 7361.48 | -1.28 | 6975.33 | 7385.94 | 5.89 >> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 3570.74 | 3929.30 | 10.04 | 3635.37 | 3736.67 | 2.79 >> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 1902.32 | 1960.46 | 3.06 | 1812.32 | 1813.88 | 0.09 >> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 11174.24 | 12044.52 | 7.79 | 11509.87 | 11273.44 | -2.05 >> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 5981.47 | 6073.70 | 1.54 | 5593.66 | 5661.93 | 1.22 >> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 2932.49 | 3069.54 | 4.67 | 2950.86 | 2892.42 | -1.98 >> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 11764.11 | 12098.63 | 2.84 | 11069.52 | 11476.93 | 3.68 >> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 5855.20 | 6080.40 | 3.85 | 5919.11 | 5607.04 | -5.27 >> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 2989.05 | 3048.56 | 1.99 | 2902.63 | 2821.83 | -2.78 >> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 11652.84 | 11965.40 | 2.68 | 11525.62 | 11459.83 | -0.57 >> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 5851.82 | 6164.94 | 5.35 | 5882.60 | 5842.30 | -0.69 >> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 3015.99 | 3043.79 | 0.92 | 2963.71 | 2947.97 | -0.53 >> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 16029.15 | 16189.79 | 1.00 | 860.43 | 2339.32 | 171.88 >> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 8078.25 | 8081.84 | 0.04 | 427.39 | 1147.92 | 168.59 >> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 4021.49 | 4294.03 | 6.78 | 209.25 | 582.28 | 178.27 >> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 15912.98 | 16329.03 | 2.61 | 848.23 | 2296.78 | 170.77 >> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 8054.10 | 8306.37 | 3.13 | 429.93 | 1146.90 | 166.77 >> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 4102.58 | 4071.08 | -0.77 | 217.86 | 582.20 | 167.24 >> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 16177.79 | 16287.85 | 0.68 | 857.84 | 2243.15 | 161.49 >> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 8187.47 | 8410.48 | 2.72 | 434.60 | 1128.20 | 159.60 >> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 4109.15 | 4233.80 | 3.03 | 208.71 | 572.43 | 174.27 >> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 3755.09 | 3930.29 | 4.67 | 3604.19 | 3598.47 | -0.16 >> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 1829.03 | 1957.39 | 7.02 | 1833.95 | 1808.38 | -1.39 >> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 915.35 | 970.55 | 6.03 | 916.25 | 899.08 | -1.87 >> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 3664.85 | 3812.26 | 4.02 | 3629.37 | 3579.23 | -1.38 >> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 1829.51 | 1877.76 | 2.64 | 1781.05 | 1807.57 | 1.49 >> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 913.37 | 953.42 | 4.38 | 912.26 | 908.73 | -0.39 >> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 3648.45 | 3899.20 | 6.87 | 3552.67 | 3581.04 | 0.80 >> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 1816.50 | 1959.68 | 7.88 | 1820.88 | 1819.71 | -0.06 >> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 901.05 | 955.13 | 6.00 | 913.74 | 907.90 | -0.64 >> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 5850.99 | 6108.64 | 4.40 | 5882.65 | 5755.21 | -2.17 >> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 2962.21 | 3060.47 | 3.32 | 2955.20 | 2909.18 | -1.56 >> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 1480.46 | 1534.72 | 3.66 | 1467.78 | 1430.60 | -2.53 >> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 5858.23 | 6047.51 | 3.23 | 5770.02 | 5773.19 | 0.05 >> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 2951.49 | 3096.53 | 4.91 | 2885.21 | 2899.31 | 0.49 >> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 1486.26 | 1527.94 | 2.80 | 1441.93 | 1454.25 | 0.85 >> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 5873.21 | 6089.75 | 3.69 | 5767.58 | 5664.11 | -1.79 >> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 2969.67 | 3081.39 | 3.76 | 2878.50 | 2905.86 | 0.95 >> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 1452.21 | 1520.03 | 4.67 | 1430.30 | 1485.63 | 3.87 >> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 8088.65 | 8443.63 | 4.39 | 455.67 | 1226.33 | 169.13 >> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 4011.95 | 4120.25 | 2.70 | 229.77 | 619.87 | 169.77 >> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 2090.57 | 2109.53 | 0.91 | 115.21 | 310.36 | 169.37 >> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 8166.84 | 8557.28 | 4.78 | 457.67 | 1242.86 | 171.56 >> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 4137.02 | 4287.95 | 3.65 | 227.26 | 624.80 | 174.93 >> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 2095.01 | 2102.86 | 0.37 | 114.26 | 310.83 | 172.03 >> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 8082.68 | 8400.56 | 3.93 | 459.59 | 1230.07 | 167.64 >> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 4047.67 | 4147.58 | 2.47 | 229.01 | 606.38 | 164.78 >> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 2086.83 | 2126.72 | 1.91 | 111.93 | 305.66 | 173.08 >> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 13597.19 | 13255.09 | -2.52 | 13818.39 | 13242.40 | -4.17 >> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 7028.26 | 6826.59 | -2.87 | 6765.15 | 6907.87 | 2.11 >> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 3570.40 | 3468.01 | -2.87 | 3449.66 | 3533.50 | 2.43 >> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 13615.99 | 13464.40 | -1.11 | 13330.02 | 13870.57 | 4.06 >> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 7043.31 | 6763.34 | -3.97 | 6928.88 | 7063.57 | 1.94 >> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 3495.12 | 3537.62 | 1.22 | 3503.41 | 3457.67 | -1.31 >> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 13591.66 | 13665.84 | 0.55 | 13773.27 | 13126.08 | -4.70 >> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 7027.08 | 7011.24 | -0.23 | 6974.98 | 6815.50 | -2.29 >> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 3568.28 | 3569.62 | 0.04 | 3580.67 | 3463.58 | -3.27 >> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 21154.03 | 21416.32 | 1.24 | 21187.01 | 21401.61 | 1.01 >> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 11194.24 | 10865.47 | -2.94 | 11063.19 | 10977.60 | -0.77 >> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 5797.80 | 5523.94 | -4.72 | 5654.63 | 5468.78 | -3.29 >> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 21333.89 | 21412.74 | 0.37 | 21610.94 | 20908.96 | -3.25 >> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 11327.07 | 11113.48 | -1.89 | 11148.25 | 10678.14 | -4.22 >> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 5810.69 | 5569.72 | -4.15 | 5663.26 | 5618.87 | -0.78 >> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 21753.20 | 21198.43 | -2.55 | 21567.90 | 21929.81 | 1.68 >> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 11517.08 | 11039.64 | -4.15 | 11103.08 | 10871.59 | -2.08 >> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 5897.16 | 5606.75 | -4.92 | 5459.87 | 5604.12 | 2.64 >> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 29748.53 | 28883.73 | -2.91 | 1549.02 | 3928.53 | 153.61 >> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 15197.09 | 15878.19 | 4.48 | 772.59 | 1924.35 | 149.08 >> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 8046.30 | 8081.19 | 0.43 | 388.11 | 990.28 | 155.16 >> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 30618.04 | 29419.19 | -3.92 | 1524.22 | 3915.97 | 156.92 >> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 15854.43 | 15846.37 | -0.05 | 766.09 | 1953.60 | 155.01 >> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 7814.77 | 7899.30 | 1.08 | 390.82 | 970.37 | 148.29 >> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 29596.82 | 28538.69 | -3.58 | 1530.45 | 3906.91 | 155.28 >> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 15662.48 | 15849.25 | 1.19 | 778.08 | 1934.31 | 148.60 >> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 8121.14 | 7758.59 | -4.46 | 392.78 | 959.73 | 144.34 >> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 17465.84 | 17069.34 | -2.27 | 16849.73 | 17842.08 | 5.89 >> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 9049.19 | 8864.15 | -2.04 | 8786.67 | 9105.34 | 3.63 >> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 17703.38 | 17070.98 | -3.57 | 16595.85 | 17784.68 | 7.16 >> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 9007.68 | 8817.41 | -2.11 | 8704.49 | 9185.87 | 5.53 >> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 17531.05 | 16983.40 | -3.12 | 16947.69 | 17655.40 | 4.18 >> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 8986.30 | 8794.15 | -2.14 | 8816.62 | 9225.95 | 4.64 >> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 21293.95 | 21506.74 | 1.00 | 21163.29 | 21854.03 | 3.26 >> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 11258.47 | 11072.92 | -1.65 | 11118.12 | 11338.96 | 1.99 >> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 21253.36 | 21292.37 | 0.18 | 21224.39 | 21763.88 | 2.54 >> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 11064.80 | 11198.35 | 1.21 | 10960.98 | 11294.14 | 3.04 >> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 21358.14 | 21346.21 | -0.06 | 21487.25 | 21854.42 | 1.71 >> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 11045.61 | 11208.26 | 1.47 | 10907.03 | 11415.18 | 4.66 >> RotateBenchmark.testRotateRightB | 512.00 | 7.00 | 17898.61 | 18307.54 | 2.28 | 1214.65 | 2546.64 | 109.66 >> RotateBenchmark.testRotateRightB | 512.00 | 15.00 | 17909.25 | 18242.51 | 1.86 | 1215.05 | 2563.98 | 111.02 >> RotateBenchmark.testRotateRightB | 512.00 | 31.00 | 17883.35 | 17928.44 | 0.25 | 1220.77 | 2543.30 | 108.34 >> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 7139.97 | 7626.72 | 6.82 | 6994.86 | 7075.65 | 1.15 >> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 3657.37 | 3898.34 | 6.59 | 3617.06 | 3576.12 | -1.13 >> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 1804.26 | 1969.19 | 9.14 | 1796.62 | 1858.84 | 3.46 >> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 7404.31 | 7760.09 | 4.80 | 7036.77 | 7401.52 | 5.18 >> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 3600.52 | 3956.35 | 9.88 | 3595.28 | 3560.36 | -0.97 >> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 1813.32 | 1966.41 | 8.44 | 1839.95 | 1852.53 | 0.68 >> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 7118.48 | 7724.81 | 8.52 | 7151.56 | 7021.09 | -1.82 >> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 3529.70 | 3881.63 | 9.97 | 3623.08 | 3601.01 | -0.61 >> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 1823.61 | 1961.34 | 7.55 | 1786.86 | 1748.85 | -2.13 >> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 11697.98 | 11835.25 | 1.17 | 11513.16 | 11184.87 | -2.85 >> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 5890.11 | 6102.57 | 3.61 | 5658.79 | 5696.08 | 0.66 >> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 2964.94 | 3070.26 | 3.55 | 2945.00 | 2962.08 | 0.58 >> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 11562.51 | 12151.29 | 5.09 | 11404.17 | 11120.28 | -2.49 >> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 5702.93 | 6130.57 | 7.50 | 5799.54 | 5779.08 | -0.35 >> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 2861.96 | 3051.44 | 6.62 | 2943.99 | 2860.65 | -2.83 >> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 11203.13 | 11710.59 | 4.53 | 11363.18 | 11112.16 | -2.21 >> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 5893.97 | 6070.71 | 3.00 | 5776.67 | 5648.84 | -2.21 >> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 2971.83 | 3046.76 | 2.52 | 2903.35 | 2833.88 | -2.39 >> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 16064.71 | 15851.35 | -1.33 | 861.93 | 2256.88 | 161.84 >> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 7916.80 | 8462.65 | 6.89 | 430.23 | 1147.30 | 166.67 >> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 4104.64 | 4068.28 | -0.89 | 216.30 | 572.86 | 164.84 >> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 16133.09 | 16281.59 | 0.92 | 856.36 | 2229.58 | 160.35 >> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 8127.26 | 8117.59 | -0.12 | 419.16 | 1176.42 | 180.66 >> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 4080.11 | 4063.26 | -0.41 | 218.32 | 571.93 | 161.97 >> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 15834.26 | 16314.64 | 3.03 | 865.96 | 2297.74 | 165.34 >> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 7965.62 | 8270.48 | 3.83 | 428.55 | 1148.87 | 168.08 >> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 4161.69 | 4034.76 | -3.05 | 215.63 | 570.19 | 164.43 >> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 3556.70 | 3877.08 | 9.01 | 3596.46 | 3558.32 | -1.06 >> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 1772.93 | 1993.86 | 12.46 | 1856.79 | 1783.22 | -3.96 >> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 908.66 | 1000.37 | 10.09 | 944.79 | 922.91 | -2.32 >> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 3742.44 | 3748.41 | 0.16 | 3788.07 | 3570.67 | -5.74 >> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 1817.53 | 1985.69 | 9.25 | 1892.38 | 1833.16 | -3.13 >> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 941.03 | 952.68 | 1.24 | 915.79 | 910.21 | -0.61 >> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 3649.48 | 3896.56 | 6.77 | 3637.59 | 3557.53 | -2.20 >> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 1840.12 | 1997.19 | 8.54 | 1821.47 | 1799.82 | -1.19 >> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 901.33 | 995.67 | 10.47 | 909.20 | 902.73 | -0.71 >> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 5789.93 | 5960.54 | 2.95 | 5758.14 | 5736.30 | -0.38 >> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 2963.20 | 3063.30 | 3.38 | 2943.48 | 2833.84 | -3.72 >> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 1501.81 | 1510.23 | 0.56 | 1463.85 | 1462.26 | -0.11 >> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 5870.05 | 5951.43 | 1.39 | 5794.74 | 5604.58 | -3.28 >> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 2971.36 | 3047.00 | 2.55 | 2931.19 | 2907.30 | -0.82 >> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 1473.97 | 1530.54 | 3.84 | 1473.45 | 1442.40 | -2.11 >> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 5858.08 | 6080.49 | 3.80 | 5863.69 | 5549.85 | -5.35 >> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 2916.24 | 3045.77 | 4.44 | 2981.59 | 2815.07 | -5.58 >> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 1441.20 | 1531.56 | 6.27 | 1492.47 | 1473.25 | -1.29 >> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 8147.24 | 8310.05 | 2.00 | 469.45 | 1235.21 | 163.12 >> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 4142.95 | 4258.86 | 2.80 | 234.14 | 615.52 | 162.88 >> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 2095.48 | 2087.20 | -0.40 | 113.55 | 311.19 | 174.05 >> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 8222.94 | 8246.58 | 0.29 | 458.91 | 1244.32 | 171.15 >> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 4160.04 | 4226.46 | 1.60 | 227.78 | 625.38 | 174.56 >> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 2064.63 | 2162.44 | 4.74 | 113.27 | 314.15 | 177.36 >> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 8157.94 | 8466.90 | 3.79 | 450.26 | 1221.90 | 171.37 >> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 4039.74 | 4283.33 | 6.03 | 224.82 | 612.68 | 172.53 >> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 2066.88 | 2147.51 | 3.90 | 110.97 | 303.43 | 173.42 >> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 13548.39 | 13245.87 | -2.23 | 13490.93 | 13084.76 | -3.01 >> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 7020.16 | 6768.85 | -3.58 | 6991.39 | 7044.32 | 0.76 >> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 3550.50 | 3505.19 | -1.28 | 3507.12 | 3612.86 | 3.01 >> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 13743.43 | 13325.44 | -3.04 | 13696.15 | 13255.80 | -3.22 >> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 6856.02 | 6969.18 | 1.65 | 6886.29 | 6834.12 | -0.76 >> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 3569.53 | 3492.76 | -2.15 | 3539.02 | 3470.02 | -1.95 >> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 13704.18 | 13495.07 | -1.53 | 13649.14 | 13583.87 | -0.48 >> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 7011.77 | 6953.93 | -0.82 | 6978.28 | 6740.30 | -3.41 >> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 3591.62 | 3620.12 | 0.79 | 3502.04 | 3510.05 | 0.23 >> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 21950.71 | 22113.60 | 0.74 | 21484.27 | 21596.64 | 0.52 >> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 11616.88 | 11099.73 | -4.45 | 11188.29 | 10737.68 | -4.03 >> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 5872.72 | 5579.12 | -5.00 | 5784.05 | 5454.57 | -5.70 >> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 22017.83 | 20817.97 | -5.45 | 21934.65 | 21356.90 | -2.63 >> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 11414.27 | 11044.86 | -3.24 | 11454.35 | 11140.34 | -2.74 >> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 5786.64 | 5634.05 | -2.64 | 5724.93 | 5639.99 | -1.48 >> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 21754.77 | 21466.01 | -1.33 | 21140.67 | 21970.03 | 3.92 >> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 11676.46 | 11358.64 | -2.72 | 11204.90 | 11213.48 | 0.08 >> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 5728.20 | 5772.49 | 0.77 | 5594.33 | 5544.25 | -0.90 >> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 30247.03 | 30179.41 | -0.22 | 1538.75 | 3975.82 | 158.38 >> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 15988.73 | 15621.42 | -2.30 | 776.04 | 1910.91 | 146.24 >> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 8115.84 | 8025.28 | -1.12 | 389.12 | 984.46 | 152.99 >> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 30110.91 | 30200.69 | 0.30 | 1532.49 | 3983.77 | 159.95 >> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 15957.90 | 15690.73 | -1.67 | 774.90 | 1931.00 | 149.19 >> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 8113.26 | 8037.93 | -0.93 | 391.90 | 965.53 | 146.37 >> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 29816.97 | 29891.54 | 0.25 | 1538.12 | 3881.93 | 152.38 >> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 15405.95 | 15619.17 | 1.38 | 762.49 | 1871.00 | 145.38 >> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 7919.80 | 7957.35 | 0.47 | 393.63 | 972.49 | 147.06 > > Jatin Bhateja has updated the pull request incrementally with three additional commits since the last revision: > > - Merge branch 'JDK-8266054' of http://github.com/jatin-bhateja/jdk into JDK-8266054 > - 8266054: Code reorganization for efficient sharing of logic to check rotate operation support on a target platform. > - 8266054: Removing redundant test templates. Hi @iwanowww, @neliasso, can you kindly review compiler side changes and share your feedback. ------------- PR: https://git.openjdk.java.net/jdk/pull/3720 From brian.goetz at oracle.com Mon May 17 13:43:34 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 17 May 2021 09:43:34 -0400 Subject: [External] : Re: JEP draft: Scope Locals In-Reply-To: References: <7220447e-b2c5-7199-655c-aee364c78b35@oracle.com> Message-ID: <131cc69b-1a5d-1837-298c-5f4f19a1474f@oracle.com> > How so? How do I know if a snapshot of my variable has occurred? Let's back up a lot of steps; you're deep in proposing a solution when you've not even explained what problem you think you're solving.? So control question, which I hope will start to expose the assumptions: ?? Why do you think its important to know that a snapshot of a variable has occurred? From github.com+2217224+kariya-mitsuru at openjdk.java.net Mon May 17 14:39:05 2021 From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru Kariya) Date: Mon, 17 May 2021 14:39:05 GMT Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. [v3] In-Reply-To: References: Message-ID: > Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases: > > 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()` > The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. > (test31) > > 2. `pos - 1 + length > this.length()` > The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1 > (test32) > > 3. `pos == this.length() + 1` > The original implementation throws `SerialException` but this case should end successfully. *2 > (test33) > > 4. `length < 0` > The original implementation throws `ArrayIndexOutOfBoundsException` but this case should throw `SerialException`. > (test34) > > Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases: > > 1. `offset > str.length()` > The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. > (test39) > > 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()` > The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. > (test32) > > 3. `pos - 1 + length > this.length()` > The original implementaion throws `SerialException` but this case should end successfully. *3 > (test40) > > 4. `pos == this.length() + 1` > The original implementaion throws `SerialException` but this case should end successfully. *4 > (test41) > > 5. `length < 0` > The original implementation throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. > (test42) > > > The javadoc has also been modified according to the above. > > *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes." > > *2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined." > So, it should work correctly when pos == length+1 of the BLOB value. > > *3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters." > > *4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined." > So, it should work correctly when pos == length+1 of the CLOB value. Mitsuru Kariya has updated the pull request incrementally with one additional commit since the last revision: Fix for length + offset > Integer.MAX_VALUE case ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4001/files - new: https://git.openjdk.java.net/jdk/pull/4001/files/6a0cc1ad..e4346738 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4001&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4001&range=01-02 Stats: 26 lines in 4 files changed: 24 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4001/head:pull/4001 PR: https://git.openjdk.java.net/jdk/pull/4001 From rriggs at openjdk.java.net Mon May 17 14:42:50 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 17 May 2021 14:42:50 GMT Subject: RFR: 8266846: Add java.time.InstantSource In-Reply-To: References: Message-ID: On Thu, 13 May 2021 20:52:33 GMT, Stephen Colebourne wrote: > 8266846: Add java.time.InstantSource Changes requested by rriggs (Reviewer). src/java.base/share/classes/java/time/Clock.java line 128: > 126: * Implementations should implement {@code Serializable} wherever possible and must > 127: * document whether or not they do support serialization. > 128: * The ImplSpec needs to say how it is implemented. The 'implements InstantSource' can not mandate any particular implementation. Its just an interface the real behavior comes from its implementations. In this case Clock. Referring to the static methods of InstantSource behavior may be sufficient because that behavior is concrete. src/java.base/share/classes/java/time/InstantSource.java line 36: > 34: * Instances of this interface are used to find the current instant. > 35: * As such, an {@code InstantSource} can be used instead of {@link System#currentTimeMillis()}. > 36: *

The word 'current' is likely to misleading here. The specification of an interface does not have any context in which to describe what the instant represents or what it is relative to. Given the intended use cases, it is definitely not always related to System.currentTimeMillis() which is bound to the running system. i think the best you could say is that it returns an instant provided by the source as does the 'instance()' method. src/java.base/share/classes/java/time/InstantSource.java line 64: > 62: * @implSpec > 63: * This interface must be implemented with care to ensure other classes operate correctly. > 64: * All implementations must be thread-safe. It would be useful to expand on the invariants that must be maintained, or examples of incorrect implementations. src/java.base/share/classes/java/time/InstantSource.java line 165: > 163: */ > 164: static InstantSource fixed(Instant fixedInstant) { > 165: return Clock.fixed(fixedInstant, ZoneOffset.UTC); Instant might also implement InstantSource, returning itself. This fixed method would be unnecessary because an Instant is itself a InstantSource. ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From vromero at openjdk.java.net Mon May 17 14:50:40 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 17 May 2021 14:50:40 GMT Subject: RFR: 8264561: javap get NegativeArraySizeException on bad instruction In-Reply-To: References: Message-ID: On Mon, 17 May 2021 13:11:56 GMT, Adam Sotona wrote: > Actual javap implementation reacts on corrupted TABLESWITCH or LOOKUPSWITCH bytecode instructions resulting to negative array allocation with NegativeArraySizeException, which is reported to user with stack trace and as serious internal error. > > The fix in c.s.t.classfile.Instruction is checking for negative array size of corrupted TABLESWITCH or LOOKUPSWITCH bytecode and throwing j.l.IllegalStateException instead of the NegativeArraySizeException. > > Another part of the fix in c.s.t.javap.CodeWriter is catching j.l.IllegalStateException and reporting it as error in the analyzed bytecode, instead of passing it up and causing serious internal javap error. lgtm ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4061 From github.com+120415+rgoers at openjdk.java.net Mon May 17 15:08:41 2021 From: github.com+120415+rgoers at openjdk.java.net (Ralph Goers) Date: Mon, 17 May 2021 15:08:41 GMT Subject: RFR: 8266846: Add java.time.InstantSource In-Reply-To: References: Message-ID: On Mon, 17 May 2021 07:50:22 GMT, Stephen Colebourne wrote: >> 8266846: Add java.time.InstantSource > > It would good to get confirmation in the review from @dholmes-ora or Mark Kralj-Taylor that my changes to the precise system clock are correct. Specifically, I moved the code from instance to static. I don't believe this changes the thread-safety, but it does need double checking (there was no discussion in the original thread concerning instance vs static). > > Original thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066670.html @jodastephen While an implementation can certainly implement the now() method there is nothing useful it can do in the JVM to get anything more than millisecond precision. It needs to perform the logic in currentInstant() which requires a call to VM.getNanoTimeAdjustment(localOffset) which it doesn't have access to. This is precisely why it needs to call Clock to pass in a structure that can be populated with the millis and nanos. ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From asotona at openjdk.java.net Mon May 17 15:27:39 2021 From: asotona at openjdk.java.net (Adam Sotona) Date: Mon, 17 May 2021 15:27:39 GMT Subject: Integrated: 8264561: javap get NegativeArraySizeException on bad instruction In-Reply-To: References: Message-ID: On Mon, 17 May 2021 13:11:56 GMT, Adam Sotona wrote: > Actual javap implementation reacts on corrupted TABLESWITCH or LOOKUPSWITCH bytecode instructions resulting to negative array allocation with NegativeArraySizeException, which is reported to user with stack trace and as serious internal error. > > The fix in c.s.t.classfile.Instruction is checking for negative array size of corrupted TABLESWITCH or LOOKUPSWITCH bytecode and throwing j.l.IllegalStateException instead of the NegativeArraySizeException. > > Another part of the fix in c.s.t.javap.CodeWriter is catching j.l.IllegalStateException and reporting it as error in the analyzed bytecode, instead of passing it up and causing serious internal javap error. This pull request has now been integrated. Changeset: cf97252f Author: Adam Sotona URL: https://git.openjdk.java.net/jdk/commit/cf97252f3fd4e7bdb57271b92dd2866101d4a94b Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod 8264561: javap get NegativeArraySizeException on bad instruction Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/4061 From mcimadamore at openjdk.java.net Mon May 17 16:03:32 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 17 May 2021 16:03:32 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v20] In-Reply-To: References: Message-ID: > 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://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix issue with bounded arena allocator ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/352c287f..0c464221 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=18-19 Stats: 112 lines in 3 files changed: 61 ins; 37 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Mon May 17 16:08:17 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 17 May 2021 16:08:17 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v21] In-Reply-To: References: Message-ID: > 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://openjdk.java.net/jeps/412 Maurizio Cimadamore 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 30 additional commits since the last revision: - Merge branch 'master' into JEP-412 - Fix issue with bounded arena allocator - Rename is_entry_blob to is_optimized_entry_blob Rename as_entry_blob to as_optimized_entry_blob Fix misc typos and indentation issues - Take care of remaining references to "Panama" - * Replace is_panama_entry_frame() with is_optimized_entry_frame() * Replace EntryBlob with OptimizedEntryBlob - Address CSR comments - * Remove unused imports * Fix broken javadoc after removal of @throws clauses * Remove other `@CallerSensitive` annotations from `AbstractCLinker` - Merge branch 'master' into JEP-412 - Remove redundant checks for --enable-native-access - Fix issue in snippet in package-info - ... and 20 more: https://git.openjdk.java.net/jdk/compare/893e2ec1...9eb61a46 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/0c464221..9eb61a46 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=20 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=19-20 Stats: 23427 lines in 753 files changed: 8549 ins; 9558 del; 5320 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From scolebourne at openjdk.java.net Mon May 17 16:51:56 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Mon, 17 May 2021 16:51:56 GMT Subject: RFR: 8266846: Add java.time.InstantSource In-Reply-To: References: Message-ID: On Mon, 17 May 2021 14:04:24 GMT, Roger Riggs wrote: >> 8266846: Add java.time.InstantSource > > src/java.base/share/classes/java/time/InstantSource.java line 36: > >> 34: * Instances of this interface are used to find the current instant. >> 35: * As such, an {@code InstantSource} can be used instead of {@link System#currentTimeMillis()}. >> 36: *

> > The word 'current' is likely to misleading here. The specification of an interface does not have any context in which to describe what the instant represents or what it is relative to. > Given the intended use cases, it is definitely not always related to System.currentTimeMillis() > which is bound to the running system. > i think the best you could say is that it returns an instant provided by the source as does the 'instance()' method. This is the definition used by `Clock` since Java 8. It is also the purpose of the interface. ie. this isn't an interface for providing instants in general, but for providing the _current instant_. I can clarify wrt the meaning of "current", but I don't see how that word can be avoided. ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From scolebourne at openjdk.java.net Mon May 17 16:54:45 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Mon, 17 May 2021 16:54:45 GMT Subject: RFR: 8266846: Add java.time.InstantSource In-Reply-To: References: Message-ID: On Mon, 17 May 2021 14:13:06 GMT, Roger Riggs wrote: >> 8266846: Add java.time.InstantSource > > src/java.base/share/classes/java/time/InstantSource.java line 165: > >> 163: */ >> 164: static InstantSource fixed(Instant fixedInstant) { >> 165: return Clock.fixed(fixedInstant, ZoneOffset.UTC); > > Instant might also implement InstantSource, returning itself. > This fixed method would be unnecessary because an Instant is itself a InstantSource. While I can see the appeal, I don't think this would be a good choice. Doing so would add three methods to `Instant` that are of no value. `millis()` would duplicate `toEpochMilli()`, `withZone(zone)` would duplicate `atZone(zone)` and `instant()` would return `this`. Moreover it doesn't respect the rationale of the interface, which is explictly to return the current instant, not any random instant. Effectively, this proposal is a variation of Scala's implicit conversions which were rejected during the development of JSR-310 as being more likely to cause bugs than help developers, ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From bpb at openjdk.java.net Mon May 17 17:00:15 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 17 May 2021 17:00:15 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes [v8] In-Reply-To: References: Message-ID: > Please consider this request to override the `java.io.InputStream` methods `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more performant implementations. The method overrides attempt to read all requested bytes into a single array of the required size rather than composing the result from a sequence of smaller arrays. An example of the performance improvements is as follows. > > **readAllBytes** > Before > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 2412.031 ? 7.309 ops/s > ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 212.181 ? 0.369 ops/s > ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 19.860 ? 0.048 ops/s > ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.298 ? 0.183 ops/s > > After > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 8218.473 ? 43.425 ops/s > ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 302.781 ? 1.273 ops/s > ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 22.461 ? 0.084 ops/s > ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.502 ? 0.003 ops/s > > > **readNBytes** > > `N = file_size / 2` > > Before > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 5585.500 ? 153.353 ops/s > ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 436.164 ? 1.104 ops/s > ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 40.167 ? 0.141 ops/s > ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 3.291 ? 0.211 ops/s > > > After > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 15463.210 ? 66.045 ops/s > ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 561.752 ? 0.951 ops/s > ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 45.043 ? 0.102 ops/s > ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 4.629 ? 0.035 ops/s Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8264777: Clean up test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3845/files - new: https://git.openjdk.java.net/jdk/pull/3845/files/4fae0209..17e21c9a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3845&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3845&range=06-07 Stats: 49 lines in 1 file changed: 6 ins; 3 del; 40 mod Patch: https://git.openjdk.java.net/jdk/pull/3845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3845/head:pull/3845 PR: https://git.openjdk.java.net/jdk/pull/3845 From vromero at openjdk.java.net Mon May 17 17:01:51 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 17 May 2021 17:01:51 GMT Subject: RFR: 8224158: assertion related to NPE at DynamicCallSiteDesc::withArgs should be reworded Message-ID: This is a very small patch that is just rewording the spec for DynamicCallSiteDesc::withArgs. Basically adding that NPE can also be thrown if the content of the argument is `null` TIA for the review ------------- Commit messages: - 8224158: assertion related to NPE at DynamicCallSiteDesc::withArgs should be reworded Changes: https://git.openjdk.java.net/jdk/pull/4067/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4067&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8224158 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4067.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4067/head:pull/4067 PR: https://git.openjdk.java.net/jdk/pull/4067 From naoto at openjdk.java.net Mon May 17 17:08:30 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 17 May 2021 17:08:30 GMT Subject: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current Message-ID: Please review the changes to the subject issue. java.util.Locale class has a long-standing issue for those obsolete ISO 639 languages where its normalization ends up in the obsolete codes. This change intends to flip the normalization towards the current codes, providing a system property for compatibility behavior. ResourceBundle class is also modified to load either obsolete/current bundles. For more detail, take a look at the CSR. ------------- Commit messages: - Added more ResourceBundleProvider tests - ResourceBundleProvider and test cases modifications - Eliminated some duplicated code - Changed ResourceBundle javadoc - Locale class description - renamed old resource files - inital commit Changes: https://git.openjdk.java.net/jdk/pull/4069/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4069&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263202 Stats: 382 lines in 35 files changed: 239 ins; 41 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/4069.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4069/head:pull/4069 PR: https://git.openjdk.java.net/jdk/pull/4069 From erikj at openjdk.java.net Mon May 17 17:17:42 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 17 May 2021 17:17:42 GMT Subject: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current In-Reply-To: References: Message-ID: <7AIkJPfmGbs8ZppuRu6kDGP4fZXu_RG9t7KEvPLFaJ8=.43150153-f88a-44bd-a903-fe019e2ab9f9@github.com> On Mon, 17 May 2021 16:55:35 GMT, Naoto Sato wrote: > Please review the changes to the subject issue. java.util.Locale class has a long-standing issue for those obsolete ISO 639 languages where its normalization ends up in the obsolete codes. This change intends to flip the normalization towards the current codes, providing a system property for compatibility behavior. ResourceBundle class is also modified to load either obsolete/current bundles. For more detail, take a look at the CSR. I see no relevant build changes to comment on as the build label was only added because the buildtool java source was touched, so this looks ok from a build perspective. ------------- PR: https://git.openjdk.java.net/jdk/pull/4069 From jvernee at openjdk.java.net Mon May 17 17:19:16 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 17 May 2021 17:19:16 GMT Subject: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles [v2] In-Reply-To: References: Message-ID: > This patch adds a `tableSwitch` combinator that can be used to switch over a set of method handles given an index, with a fallback in case the index is out of bounds, much like the `tableswitch` bytecode. Here is a description of how it works (copied from the javadoc): > > Creates a table switch method handle, which can be used to switch over a set of target > method handles, based on a given target index, called selector. > > For a selector value of {@code n}, where {@code n} falls in the range {@code [0, N)}, > and where {@code N} is the number of target method handles, the table switch method > handle will invoke the n-th target method handle from the list of target method handles. > > For a selector value that does not fall in the range {@code [0, N)}, the table switch > method handle will invoke the given fallback method handle. > > All method handles passed to this method must have the same type, with the additional > requirement that the leading parameter be of type {@code int}. The leading parameter > represents the selector. > > Any trailing parameters present in the type will appear on the returned table switch > method handle as well. Any arguments assigned to these parameters will be forwarded, > together with the selector value, to the selected method handle when invoking it. > > The combinator does not support specifying the starting index, so the switch cases always run from 0 to however many target handles are specified. A starting index can be added manually with another combination step that filters the input index by adding or subtracting a constant from it, which does not affect performance. One of the reasons for not supporting a starting index is that it allows for more lambda form sharing, but also simplifies the implementation somewhat. I guess an open question is if a convenience overload should be added for that case? > > Lookup switch can also be simulated by filtering the input through an injection function that translates it into a case index, which has also proven to have the ability to have comparable performance to, or even better performance than, a bytecode-native `lookupswitch` instruction. I plan to add such an injection function to the runtime libraries in the future as well. Maybe at that point it could be evaluated if it's worth it to add a lookup switch combinator as well, but I don't see an immediate need to include it in this patch. > > The current bytecode intrinsification generates a call for each switch case, which guarantees full inlining of the target method handles. Alternatively we could only have 1 callsite at the end of the switch, where each case just loads the target method handle, but currently this does not allow for inlining of the handles, since they are not constant. > > Maybe a future C2 optimization could look at the receiver input for invokeBasic call sites, and if the input is a phi node, clone the call for each constant input of the phi. I believe that would allow simplifying the bytecode without giving up on inlining. > > Some numbers from the added benchmarks: > > Benchmark (numCases) (offset) (sorted) Mode Cnt Score Error Units > MethodHandlesTableSwitchConstant.testSwitch 5 0 N/A avgt 30 4.186 ? 0.054 ms/op > MethodHandlesTableSwitchConstant.testSwitch 5 150 N/A avgt 30 4.164 ? 0.057 ms/op > MethodHandlesTableSwitchConstant.testSwitch 10 0 N/A avgt 30 4.124 ? 0.023 ms/op > MethodHandlesTableSwitchConstant.testSwitch 10 150 N/A avgt 30 4.126 ? 0.025 ms/op > MethodHandlesTableSwitchConstant.testSwitch 25 0 N/A avgt 30 4.137 ? 0.042 ms/op > MethodHandlesTableSwitchConstant.testSwitch 25 150 N/A avgt 30 4.113 ? 0.016 ms/op > MethodHandlesTableSwitchConstant.testSwitch 50 0 N/A avgt 30 4.118 ? 0.028 ms/op > MethodHandlesTableSwitchConstant.testSwitch 50 150 N/A avgt 30 4.127 ? 0.019 ms/op > MethodHandlesTableSwitchConstant.testSwitch 100 0 N/A avgt 30 4.116 ? 0.013 ms/op > MethodHandlesTableSwitchConstant.testSwitch 100 150 N/A avgt 30 4.121 ? 0.020 ms/op > MethodHandlesTableSwitchOpaqueSingle.testSwitch 5 0 N/A avgt 30 4.113 ? 0.009 ms/op > MethodHandlesTableSwitchOpaqueSingle.testSwitch 5 150 N/A avgt 30 4.149 ? 0.041 ms/op > MethodHandlesTableSwitchOpaqueSingle.testSwitch 10 0 N/A avgt 30 4.121 ? 0.026 ms/op > MethodHandlesTableSwitchOpaqueSingle.testSwitch 10 150 N/A avgt 30 4.113 ? 0.021 ms/op > MethodHandlesTableSwitchOpaqueSingle.testSwitch 25 0 N/A avgt 30 4.129 ? 0.028 ms/op > MethodHandlesTableSwitchOpaqueSingle.testSwitch 25 150 N/A avgt 30 4.105 ? 0.019 ms/op > MethodHandlesTableSwitchOpaqueSingle.testSwitch 50 0 N/A avgt 30 4.097 ? 0.021 ms/op > MethodHandlesTableSwitchOpaqueSingle.testSwitch 50 150 N/A avgt 30 4.131 ? 0.037 ms/op > MethodHandlesTableSwitchOpaqueSingle.testSwitch 100 0 N/A avgt 30 4.135 ? 0.025 ms/op > MethodHandlesTableSwitchOpaqueSingle.testSwitch 100 150 N/A avgt 30 4.139 ? 0.145 ms/op > MethodHandlesTableSwitchRandom.testSwitch 5 0 true avgt 30 4.894 ? 0.028 ms/op > MethodHandlesTableSwitchRandom.testSwitch 5 0 false avgt 30 11.526 ? 0.194 ms/op > MethodHandlesTableSwitchRandom.testSwitch 5 150 true avgt 30 4.882 ? 0.025 ms/op > MethodHandlesTableSwitchRandom.testSwitch 5 150 false avgt 30 11.532 ? 0.034 ms/op > MethodHandlesTableSwitchRandom.testSwitch 10 0 true avgt 30 5.065 ? 0.076 ms/op > MethodHandlesTableSwitchRandom.testSwitch 10 0 false avgt 30 13.016 ? 0.020 ms/op > MethodHandlesTableSwitchRandom.testSwitch 10 150 true avgt 30 5.103 ? 0.051 ms/op > MethodHandlesTableSwitchRandom.testSwitch 10 150 false avgt 30 12.984 ? 0.102 ms/op > MethodHandlesTableSwitchRandom.testSwitch 25 0 true avgt 30 8.441 ? 0.165 ms/op > MethodHandlesTableSwitchRandom.testSwitch 25 0 false avgt 30 13.371 ? 0.060 ms/op > MethodHandlesTableSwitchRandom.testSwitch 25 150 true avgt 30 8.628 ? 0.032 ms/op > MethodHandlesTableSwitchRandom.testSwitch 25 150 false avgt 30 13.542 ? 0.020 ms/op > MethodHandlesTableSwitchRandom.testSwitch 50 0 true avgt 30 4.701 ? 0.015 ms/op > MethodHandlesTableSwitchRandom.testSwitch 50 0 false avgt 30 13.562 ? 0.063 ms/op > MethodHandlesTableSwitchRandom.testSwitch 50 150 true avgt 30 7.991 ? 3.111 ms/op > MethodHandlesTableSwitchRandom.testSwitch 50 150 false avgt 30 13.543 ? 0.088 ms/op > MethodHandlesTableSwitchRandom.testSwitch 100 0 true avgt 30 4.712 ? 0.020 ms/op > MethodHandlesTableSwitchRandom.testSwitch 100 0 false avgt 30 13.600 ? 0.085 ms/op > MethodHandlesTableSwitchRandom.testSwitch 100 150 true avgt 30 4.676 ? 0.011 ms/op > MethodHandlesTableSwitchRandom.testSwitch 100 150 false avgt 30 13.476 ? 0.043 ms/op > > > Testing: > - [x] Running of included benchmarks > - [x] Inspecting inlining trace and verifying method handle targets are inlined > - [x] Running TestTableSwitch test (currently the only user of the new code) > - [x] Running java/lang/invoke tests (just in case) > - [x] Some manual testing > > Thanks, > Jorn Jorn Vernee 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 two additional commits since the last revision: - - Formatting - Reduce benchmark cases - Remove NamedFunction::intrinsicName - All changes prior to review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3401/files - new: https://git.openjdk.java.net/jdk/pull/3401/files/f26a908c..80a706f1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3401&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3401&range=00-01 Stats: 647619 lines in 7045 files changed: 88629 ins; 538861 del; 20129 mod Patch: https://git.openjdk.java.net/jdk/pull/3401.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3401/head:pull/3401 PR: https://git.openjdk.java.net/jdk/pull/3401 From scolebourne at openjdk.java.net Mon May 17 17:19:19 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Mon, 17 May 2021 17:19:19 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v2] In-Reply-To: References: Message-ID: <-4wVyKFO8p5jFap50H7tmoQ5VRzSnwZ1A4dCsqy9rOk=.7b351a5f-f127-4941-9467-ac864de71509@github.com> > 8266846: Add java.time.InstantSource Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: 8266846: Add java.time.InstantSource ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4016/files - new: https://git.openjdk.java.net/jdk/pull/4016/files/befc7621..7fa9d0ec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4016&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4016&range=00-01 Stats: 38 lines in 2 files changed: 31 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4016.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4016/head:pull/4016 PR: https://git.openjdk.java.net/jdk/pull/4016 From scolebourne at openjdk.java.net Mon May 17 17:19:20 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Mon, 17 May 2021 17:19:20 GMT Subject: RFR: 8266846: Add java.time.InstantSource In-Reply-To: References: Message-ID: On Thu, 13 May 2021 20:52:33 GMT, Stephen Colebourne wrote: > 8266846: Add java.time.InstantSource FWIW, if there is a need to access `VM.getNanoTimeAdjustment(localOffset)` then that should be a separate issue. I don't personally think it would be approved given Valhalla is coming. ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From scolebourne at openjdk.java.net Mon May 17 17:19:23 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Mon, 17 May 2021 17:19:23 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v2] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 14:30:20 GMT, Roger Riggs wrote: >> Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: >> >> 8266846: Add java.time.InstantSource > > src/java.base/share/classes/java/time/Clock.java line 128: > >> 126: * Implementations should implement {@code Serializable} wherever possible and must >> 127: * document whether or not they do support serialization. >> 128: * > > The ImplSpec needs to say how it is implemented. > The 'implements InstantSource' can not mandate any particular implementation. Its just an interface the real behavior comes from its implementations. In this case Clock. Referring to the static methods of InstantSource behavior may be sufficient because that behavior is concrete. There are plenty of examples of interfaces in `java.time` and elsewhere that apply restrictions to implementations. Nevertheless, for simplicity and expediency I have reinstated the `implSpec` on `Clock` ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From naoto at openjdk.java.net Mon May 17 17:22:37 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 17 May 2021 17:22:37 GMT Subject: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current In-Reply-To: <7AIkJPfmGbs8ZppuRu6kDGP4fZXu_RG9t7KEvPLFaJ8=.43150153-f88a-44bd-a903-fe019e2ab9f9@github.com> References: <7AIkJPfmGbs8ZppuRu6kDGP4fZXu_RG9t7KEvPLFaJ8=.43150153-f88a-44bd-a903-fe019e2ab9f9@github.com> Message-ID: <2BUKuYhdtpkEUbUG6a-ME_61A1ss_5FN18stfHwI-ic=.9c0b5001-9e65-44c7-ae01-850e751a8180@github.com> On Mon, 17 May 2021 17:14:53 GMT, Erik Joelsson wrote: > I see no relevant build changes to comment on as the build label was only added because the buildtool java source was touched, so this looks ok from a build perspective. Removed `build` label. ------------- PR: https://git.openjdk.java.net/jdk/pull/4069 From jvernee at openjdk.java.net Mon May 17 17:22:48 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 17 May 2021 17:22:48 GMT Subject: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles [v2] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 07:27:08 GMT, Claes Redestad wrote: >> Jorn Vernee 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 two additional commits since the last revision: >> >> - - Formatting >> - Reduce benchmark cases >> - Remove NamedFunction::intrinsicName >> - All changes prior to review > > Overall this looks great! > > I have a number of nits and a request to try and remodel so that `NamedFunction` isn't responsible for holding the arbitrary intrinsic data that you want to add here. Thanks for the review @cl4es I've addressed your review comments. I've reduced the number of cases in the benchmark to 5, 10, and 25, which is the most interesting area to look at, and also removed the offset cases for the non-constant input benchmarks (proving the offset is constant folded only needs to be done once I think). WRT `NamedFunction::intrinsicName`, I think you're right that we can also just delegate to `IntrinsicMethodHandle::intrinsicName`, and have it indicate the intrinsic. I've implemented that change. As a result, some `NamedFunction` constructor call sites no longer attach the intrinsic name to the `NamedFunction` itself, but re-wrap the `resolvedHandle` they use in an `IntrinsicMethodHandle` with the right intrinsic name. This leads to a nice code simplification from being able to remove all the `NamedFunction` constructor overloads. java/lang/invoke tests are still green, but I'll re-run Tier 1-3 as well to make sure that the difference in `resolvedHandle` being used for some `NamedFunctions` doesn't cause any other problems. ------------- PR: https://git.openjdk.java.net/jdk/pull/3401 From redestad at openjdk.java.net Mon May 17 17:37:59 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 17 May 2021 17:37:59 GMT Subject: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles [v2] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 17:19:16 GMT, Jorn Vernee wrote: >> This patch adds a `tableSwitch` combinator that can be used to switch over a set of method handles given an index, with a fallback in case the index is out of bounds, much like the `tableswitch` bytecode. Here is a description of how it works (copied from the javadoc): >> >> Creates a table switch method handle, which can be used to switch over a set of target >> method handles, based on a given target index, called selector. >> >> For a selector value of {@code n}, where {@code n} falls in the range {@code [0, N)}, >> and where {@code N} is the number of target method handles, the table switch method >> handle will invoke the n-th target method handle from the list of target method handles. >> >> For a selector value that does not fall in the range {@code [0, N)}, the table switch >> method handle will invoke the given fallback method handle. >> >> All method handles passed to this method must have the same type, with the additional >> requirement that the leading parameter be of type {@code int}. The leading parameter >> represents the selector. >> >> Any trailing parameters present in the type will appear on the returned table switch >> method handle as well. Any arguments assigned to these parameters will be forwarded, >> together with the selector value, to the selected method handle when invoking it. >> >> The combinator does not support specifying the starting index, so the switch cases always run from 0 to however many target handles are specified. A starting index can be added manually with another combination step that filters the input index by adding or subtracting a constant from it, which does not affect performance. One of the reasons for not supporting a starting index is that it allows for more lambda form sharing, but also simplifies the implementation somewhat. I guess an open question is if a convenience overload should be added for that case? >> >> Lookup switch can also be simulated by filtering the input through an injection function that translates it into a case index, which has also proven to have the ability to have comparable performance to, or even better performance than, a bytecode-native `lookupswitch` instruction. I plan to add such an injection function to the runtime libraries in the future as well. Maybe at that point it could be evaluated if it's worth it to add a lookup switch combinator as well, but I don't see an immediate need to include it in this patch. >> >> The current bytecode intrinsification generates a call for each switch case, which guarantees full inlining of the target method handles. Alternatively we could only have 1 callsite at the end of the switch, where each case just loads the target method handle, but currently this does not allow for inlining of the handles, since they are not constant. >> >> Maybe a future C2 optimization could look at the receiver input for invokeBasic call sites, and if the input is a phi node, clone the call for each constant input of the phi. I believe that would allow simplifying the bytecode without giving up on inlining. >> >> Some numbers from the added benchmarks: >> >> Benchmark (numCases) (offset) (sorted) Mode Cnt Score Error Units >> MethodHandlesTableSwitchConstant.testSwitch 5 0 N/A avgt 30 4.186 ? 0.054 ms/op >> MethodHandlesTableSwitchConstant.testSwitch 5 150 N/A avgt 30 4.164 ? 0.057 ms/op >> MethodHandlesTableSwitchConstant.testSwitch 10 0 N/A avgt 30 4.124 ? 0.023 ms/op >> MethodHandlesTableSwitchConstant.testSwitch 10 150 N/A avgt 30 4.126 ? 0.025 ms/op >> MethodHandlesTableSwitchConstant.testSwitch 25 0 N/A avgt 30 4.137 ? 0.042 ms/op >> MethodHandlesTableSwitchConstant.testSwitch 25 150 N/A avgt 30 4.113 ? 0.016 ms/op >> MethodHandlesTableSwitchConstant.testSwitch 50 0 N/A avgt 30 4.118 ? 0.028 ms/op >> MethodHandlesTableSwitchConstant.testSwitch 50 150 N/A avgt 30 4.127 ? 0.019 ms/op >> MethodHandlesTableSwitchConstant.testSwitch 100 0 N/A avgt 30 4.116 ? 0.013 ms/op >> MethodHandlesTableSwitchConstant.testSwitch 100 150 N/A avgt 30 4.121 ? 0.020 ms/op >> MethodHandlesTableSwitchOpaqueSingle.testSwitch 5 0 N/A avgt 30 4.113 ? 0.009 ms/op >> MethodHandlesTableSwitchOpaqueSingle.testSwitch 5 150 N/A avgt 30 4.149 ? 0.041 ms/op >> MethodHandlesTableSwitchOpaqueSingle.testSwitch 10 0 N/A avgt 30 4.121 ? 0.026 ms/op >> MethodHandlesTableSwitchOpaqueSingle.testSwitch 10 150 N/A avgt 30 4.113 ? 0.021 ms/op >> MethodHandlesTableSwitchOpaqueSingle.testSwitch 25 0 N/A avgt 30 4.129 ? 0.028 ms/op >> MethodHandlesTableSwitchOpaqueSingle.testSwitch 25 150 N/A avgt 30 4.105 ? 0.019 ms/op >> MethodHandlesTableSwitchOpaqueSingle.testSwitch 50 0 N/A avgt 30 4.097 ? 0.021 ms/op >> MethodHandlesTableSwitchOpaqueSingle.testSwitch 50 150 N/A avgt 30 4.131 ? 0.037 ms/op >> MethodHandlesTableSwitchOpaqueSingle.testSwitch 100 0 N/A avgt 30 4.135 ? 0.025 ms/op >> MethodHandlesTableSwitchOpaqueSingle.testSwitch 100 150 N/A avgt 30 4.139 ? 0.145 ms/op >> MethodHandlesTableSwitchRandom.testSwitch 5 0 true avgt 30 4.894 ? 0.028 ms/op >> MethodHandlesTableSwitchRandom.testSwitch 5 0 false avgt 30 11.526 ? 0.194 ms/op >> MethodHandlesTableSwitchRandom.testSwitch 5 150 true avgt 30 4.882 ? 0.025 ms/op >> MethodHandlesTableSwitchRandom.testSwitch 5 150 false avgt 30 11.532 ? 0.034 ms/op >> MethodHandlesTableSwitchRandom.testSwitch 10 0 true avgt 30 5.065 ? 0.076 ms/op >> MethodHandlesTableSwitchRandom.testSwitch 10 0 false avgt 30 13.016 ? 0.020 ms/op >> MethodHandlesTableSwitchRandom.testSwitch 10 150 true avgt 30 5.103 ? 0.051 ms/op >> MethodHandlesTableSwitchRandom.testSwitch 10 150 false avgt 30 12.984 ? 0.102 ms/op >> MethodHandlesTableSwitchRandom.testSwitch 25 0 true avgt 30 8.441 ? 0.165 ms/op >> MethodHandlesTableSwitchRandom.testSwitch 25 0 false avgt 30 13.371 ? 0.060 ms/op >> MethodHandlesTableSwitchRandom.testSwitch 25 150 true avgt 30 8.628 ? 0.032 ms/op >> MethodHandlesTableSwitchRandom.testSwitch 25 150 false avgt 30 13.542 ? 0.020 ms/op >> MethodHandlesTableSwitchRandom.testSwitch 50 0 true avgt 30 4.701 ? 0.015 ms/op >> MethodHandlesTableSwitchRandom.testSwitch 50 0 false avgt 30 13.562 ? 0.063 ms/op >> MethodHandlesTableSwitchRandom.testSwitch 50 150 true avgt 30 7.991 ? 3.111 ms/op >> MethodHandlesTableSwitchRandom.testSwitch 50 150 false avgt 30 13.543 ? 0.088 ms/op >> MethodHandlesTableSwitchRandom.testSwitch 100 0 true avgt 30 4.712 ? 0.020 ms/op >> MethodHandlesTableSwitchRandom.testSwitch 100 0 false avgt 30 13.600 ? 0.085 ms/op >> MethodHandlesTableSwitchRandom.testSwitch 100 150 true avgt 30 4.676 ? 0.011 ms/op >> MethodHandlesTableSwitchRandom.testSwitch 100 150 false avgt 30 13.476 ? 0.043 ms/op >> >> >> Testing: >> - [x] Running of included benchmarks >> - [x] Inspecting inlining trace and verifying method handle targets are inlined >> - [x] Running TestTableSwitch test (currently the only user of the new code) >> - [x] Running java/lang/invoke tests (just in case) >> - [x] Some manual testing >> >> Thanks, >> Jorn > > Jorn Vernee 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 two additional commits since the last revision: > > - - Formatting > - Reduce benchmark cases > - Remove NamedFunction::intrinsicName > - All changes prior to review Thanks for working through my comments, especially cleaning up how intrinsic data is handled which now looks much more like a natural fit! ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3401 From rriggs at openjdk.java.net Mon May 17 17:45:42 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 17 May 2021 17:45:42 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v2] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 17:13:58 GMT, Stephen Colebourne wrote: >> src/java.base/share/classes/java/time/Clock.java line 128: >> >>> 126: * Implementations should implement {@code Serializable} wherever possible and must >>> 127: * document whether or not they do support serialization. >>> 128: * >> >> The ImplSpec needs to say how it is implemented. >> The 'implements InstantSource' can not mandate any particular implementation. Its just an interface the real behavior comes from its implementations. In this case Clock. Referring to the static methods of InstantSource behavior may be sufficient because that behavior is concrete. > > There are plenty of examples of interfaces in `java.time` and elsewhere that apply restrictions to implementations. Nevertheless, for simplicity and expediency I have reinstated the `implSpec` on `Clock` ok, thanks. Assertions in interfaces are toothless. Tests can only be written for implementations. ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From alanb at openjdk.java.net Mon May 17 17:47:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 17 May 2021 17:47:40 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes [v8] In-Reply-To: References: Message-ID: <8YjWEszECAbsRTDjC2MuewboUxif9_nEhFDFc6CtIos=.c176fd69-3320-4402-91bc-cf6927ab35d6@github.com> On Mon, 17 May 2021 17:00:15 GMT, Brian Burkhalter wrote: >> Please consider this request to override the `java.io.InputStream` methods `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more performant implementations. The method overrides attempt to read all requested bytes into a single array of the required size rather than composing the result from a sequence of smaller arrays. An example of the performance improvements is as follows. >> >> **readAllBytes** >> Before >> >> Benchmark (length) Mode Cnt Score Error Units >> ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 2412.031 ? 7.309 ops/s >> ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 212.181 ? 0.369 ops/s >> ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 19.860 ? 0.048 ops/s >> ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.298 ? 0.183 ops/s >> >> After >> >> Benchmark (length) Mode Cnt Score Error Units >> ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 8218.473 ? 43.425 ops/s >> ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 302.781 ? 1.273 ops/s >> ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 22.461 ? 0.084 ops/s >> ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.502 ? 0.003 ops/s >> >> >> **readNBytes** >> >> `N = file_size / 2` >> >> Before >> >> Benchmark (length) Mode Cnt Score Error Units >> ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 5585.500 ? 153.353 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 436.164 ? 1.104 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 40.167 ? 0.141 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 3.291 ? 0.211 ops/s >> >> >> After >> >> Benchmark (length) Mode Cnt Score Error Units >> ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 15463.210 ? 66.045 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 561.752 ? 0.951 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 45.043 ? 0.102 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 4.629 ? 0.035 ops/s > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8264777: Clean up test Marked as reviewed by alanb (Reviewer). test/jdk/java/io/FileInputStream/ReadXBytes.java line 69: > 67: > 68: try (FileInputStream fis = new FileInputStream(empty)) { > 69: byte[] b = fis.readAllBytes(); You could move this readAllBytes test up to the previous block if you want. ------------- PR: https://git.openjdk.java.net/jdk/pull/3845 From bpb at openjdk.java.net Mon May 17 17:53:05 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 17 May 2021 17:53:05 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes [v9] In-Reply-To: References: Message-ID: > Please consider this request to override the `java.io.InputStream` methods `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more performant implementations. The method overrides attempt to read all requested bytes into a single array of the required size rather than composing the result from a sequence of smaller arrays. An example of the performance improvements is as follows. > > **readAllBytes** > Before > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 2412.031 ? 7.309 ops/s > ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 212.181 ? 0.369 ops/s > ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 19.860 ? 0.048 ops/s > ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.298 ? 0.183 ops/s > > After > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 8218.473 ? 43.425 ops/s > ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 302.781 ? 1.273 ops/s > ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 22.461 ? 0.084 ops/s > ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.502 ? 0.003 ops/s > > > **readNBytes** > > `N = file_size / 2` > > Before > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 5585.500 ? 153.353 ops/s > ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 436.164 ? 1.104 ops/s > ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 40.167 ? 0.141 ops/s > ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 3.291 ? 0.211 ops/s > > > After > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 15463.210 ? 66.045 ops/s > ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 561.752 ? 0.951 ops/s > ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 45.043 ? 0.102 ops/s > ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 4.629 ? 0.035 ops/s Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8264777: Merge two try-with-resources blocks in test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3845/files - new: https://git.openjdk.java.net/jdk/pull/3845/files/17e21c9a..76895a0c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3845&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3845&range=07-08 Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3845/head:pull/3845 PR: https://git.openjdk.java.net/jdk/pull/3845 From brian.goetz at oracle.com Mon May 17 18:14:26 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 17 May 2021 14:14:26 -0400 Subject: [External] : Re: JEP draft: Scope Locals In-Reply-To: References: <7220447e-b2c5-7199-655c-aee364c78b35@oracle.com> <131cc69b-1a5d-1837-298c-5f4f19a1474f@oracle.com> Message-ID: <24e9d8c3-b219-f94c-721d-55a38590f902@oracle.com> > Let's back up a lot of steps; you're deep in proposing a solution > when you've not even explained what problem you think you're > solving.? So control question, which I hope will start to expose > the assumptions: > > ?? Why do you think its important to know that a snapshot of a > variable has occurred? > > > From the JEP: > "In addition, a |Snapshot()| operation that captures the current set > of inheritable scope locals is provided. This allows context > information to be shared with asynchronous computations." > > As the provider of the scoped variable, I'd certainly like to know > that my scoped variable is being passed into a new scope. Let's try again: why is that important??? What decisions would you make differently if you had this information?? What benefit would come from those decisions? From alanb at openjdk.java.net Mon May 17 18:36:46 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 17 May 2021 18:36:46 GMT Subject: RFR: 8264777: Overload optimized FileInputStream::readAllBytes [v9] In-Reply-To: References: Message-ID: <813PqjCFVs9u8cmurOU1OJ5Fwoaf3hKacF3KcJU6MEk=.d13bcf96-7649-44f5-a68a-81d9953e78a7@github.com> On Mon, 17 May 2021 17:53:05 GMT, Brian Burkhalter wrote: >> Please consider this request to override the `java.io.InputStream` methods `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more performant implementations. The method overrides attempt to read all requested bytes into a single array of the required size rather than composing the result from a sequence of smaller arrays. An example of the performance improvements is as follows. >> >> **readAllBytes** >> Before >> >> Benchmark (length) Mode Cnt Score Error Units >> ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 2412.031 ? 7.309 ops/s >> ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 212.181 ? 0.369 ops/s >> ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 19.860 ? 0.048 ops/s >> ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.298 ? 0.183 ops/s >> >> After >> >> Benchmark (length) Mode Cnt Score Error Units >> ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 8218.473 ? 43.425 ops/s >> ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 302.781 ? 1.273 ops/s >> ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 22.461 ? 0.084 ops/s >> ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.502 ? 0.003 ops/s >> >> >> **readNBytes** >> >> `N = file_size / 2` >> >> Before >> >> Benchmark (length) Mode Cnt Score Error Units >> ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 5585.500 ? 153.353 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 436.164 ? 1.104 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 40.167 ? 0.141 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 3.291 ? 0.211 ops/s >> >> >> After >> >> Benchmark (length) Mode Cnt Score Error Units >> ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 15463.210 ? 66.045 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 561.752 ? 0.951 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 45.043 ? 0.102 ops/s >> ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 4.629 ? 0.035 ops/s > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8264777: Merge two try-with-resources blocks in test Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3845 From jlahoda at openjdk.java.net Mon May 17 19:04:11 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 17 May 2021 19:04:11 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v2] In-Reply-To: References: Message-ID: On Tue, 4 May 2021 20:48:34 GMT, Maurizio Cimadamore wrote: >> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision: >> >> - Reflecting recent spec changes. >> - Reflecting review comments. >> - Reflecting review comments on SwitchBootstraps. > > Good work. There's a lot to take in here. I think overall, it holds up well - I like how case labels have been extended to accommodate for patterns. In the front-end, I think there are some questions over the split between Attr and Flow - maybe it is unavoidable, but I'm not sure why some control-flow analysis happens in Attr instead of Flow and I left some questions to make sure I understand what's happening. > > In the backend it's mostly good work - but overall the structure of the code, both in Lower and in TransPattern is getting very difficult to follow, given there are many different kind of switches each with its own little twist attached to it. It would be nice, I think (maybe in a separate cleanup?) if the code paths serving the different switch kinds could be made more separate, so that, when reading the code we can worry only about one possible code shape. That would make the code easier to document as well. @mcimadamore, @forax, thanks a lot for comments! I tried to apply the requested changes in recent commits (https://github.com/openjdk/jdk/pull/3863/commits/3fc2502a33cec20f39fe571eb25538ee3b459a9b https://github.com/openjdk/jdk/pull/3863/commits/aeddb85e65bf77ed62dc7fa1ad00c29646d02c99 ). I've also tried to update the implementation for the latest spec changes here: https://github.com/openjdk/jdk/pull/3863/commits/54ba974e1aac00bbde1c3bd2627f01caaaeda09b The spec changes are: total patterns are nullable; pattern matching ("new") statement switches must be complete (as switch expressions). Any further feedback is welcome! ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Mon May 17 19:04:11 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 17 May 2021 19:04:11 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v2] In-Reply-To: References: Message-ID: > 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/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision: - Reflecting recent spec changes. - Reflecting review comments. - Reflecting review comments on SwitchBootstraps. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/5e663d70..54ba974e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=00-01 Stats: 544 lines in 18 files changed: 431 ins; 68 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From github.com+828220+forax at openjdk.java.net Mon May 17 19:21:41 2021 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Mon, 17 May 2021 19:21:41 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v2] In-Reply-To: References: Message-ID: <4O-2pD_4PUl_DRDCLvPO6nNwOvqN-j0GvQzogPTJ0hE=.d5009f6b-72a8-4a96-80b9-4a3a73178e1e@github.com> On Mon, 17 May 2021 19:04:11 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/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision: > > - Reflecting recent spec changes. > - Reflecting review comments. > - Reflecting review comments on SwitchBootstraps. It's not clear to me if it's the first change and several will follow or not. The code looks good but the metaprotocol is not the right one IMO, i would prefer the one we discuss in April https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-April/002992.html But this can be tackle in another PR ------------- Marked as reviewed by forax at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/3863 From brian.goetz at oracle.com Mon May 17 19:55:37 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 17 May 2021 15:55:37 -0400 Subject: [External] : Re: JEP draft: Scope Locals In-Reply-To: References: <7220447e-b2c5-7199-655c-aee364c78b35@oracle.com> <131cc69b-1a5d-1837-298c-5f4f19a1474f@oracle.com> <24e9d8c3-b219-f94c-721d-55a38590f902@oracle.com> Message-ID: <1c980620-febc-e299-8268-bdd5f088e5c2@oracle.com> > Let's try again: why is that important??? What decisions would you > make differently if you had this information?? What benefit would > come from those decisions? > > Threading is hard. Gee, thanks MIke for pointing that out to me, obviously I'm new to the topic :) > Scoped variables are also hard to get right. Combining the two without > an explicit api ignores the complexity that will arise as scoped > variables are passed to other threads. OK, now we're getting to the actual question; you obviously have some assumptions about the degree of sharing expected, that might be skipping a few steps (and then skipping some more steps by jumping to a solution).? So to ask again: what patterns of access / sharing are you assuming, what risks are you anticipating, etc? From bpb at openjdk.java.net Mon May 17 20:02:43 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 17 May 2021 20:02:43 GMT Subject: Integrated: 8264777: Overload optimized FileInputStream::readAllBytes In-Reply-To: References: Message-ID: On Mon, 3 May 2021 20:33:23 GMT, Brian Burkhalter wrote: > Please consider this request to override the `java.io.InputStream` methods `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more performant implementations. The method overrides attempt to read all requested bytes into a single array of the required size rather than composing the result from a sequence of smaller arrays. An example of the performance improvements is as follows. > > **readAllBytes** > Before > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 2412.031 ? 7.309 ops/s > ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 212.181 ? 0.369 ops/s > ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 19.860 ? 0.048 ops/s > ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.298 ? 0.183 ops/s > > After > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 8218.473 ? 43.425 ops/s > ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 302.781 ? 1.273 ops/s > ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 22.461 ? 0.084 ops/s > ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.502 ? 0.003 ops/s > > > **readNBytes** > > `N = file_size / 2` > > Before > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 5585.500 ? 153.353 ops/s > ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 436.164 ? 1.104 ops/s > ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 40.167 ? 0.141 ops/s > ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 3.291 ? 0.211 ops/s > > > After > > Benchmark (length) Mode Cnt Score Error Units > ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 15463.210 ? 66.045 ops/s > ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 561.752 ? 0.951 ops/s > ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 45.043 ? 0.102 ops/s > ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 4.629 ? 0.035 ops/s This pull request has now been integrated. Changeset: da4dfde7 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/da4dfde71a176d2b8401782178e854d4c924eba1 Stats: 244 lines in 4 files changed: 238 ins; 1 del; 5 mod 8264777: Overload optimized FileInputStream::readAllBytes Reviewed-by: dfuchs, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/3845 From weijun at openjdk.java.net Mon May 17 22:01:49 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 17 May 2021 22:01:49 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager Message-ID: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> 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.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) ``` The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. ------------- Commit messages: - test for awt - test for hotspot-gc - test for compiler - test for net - test for core-libs - test for beans - test for xml - test for nio - test for hotspot-runtime - test for security - ... and 7 more: https://git.openjdk.java.net/jdk/compare/79b39445...900c28c0 Changes: https://git.openjdk.java.net/jdk/pull/4071/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267184 Stats: 1024 lines in 852 files changed: 249 ins; 8 del; 767 mod Patch: https://git.openjdk.java.net/jdk/pull/4071.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071 PR: https://git.openjdk.java.net/jdk/pull/4071 From weijun at openjdk.java.net Mon May 17 22:01:52 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 17 May 2021 22:01:52 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal Message-ID: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. ------------- Commit messages: - add supresswarnings annotations automatically - manual change before automatic annotating - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal Changes: https://git.openjdk.java.net/jdk/pull/4073/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266459 Stats: 2018 lines in 826 files changed: 1884 ins; 9 del; 125 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Mon May 17 22:01:53 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 17 May 2021 22:01:53 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. The 3rd commit is the biggest one but it's all generated programmatically. All changes are simply adding `@SupressWarnings("removal")` to a declaration. Precisely, of all the diff hunks (leading whitespaces ignored), there are 1607 + @SuppressWarnings("removal") There are also 7 cases where an existing annotation is updated ================= 2 ==================== - @SuppressWarnings("deprecation") + @SuppressWarnings({"removal","deprecation"}) ================= 1 ==================== - @SuppressWarnings("Convert2Lambda") + @SuppressWarnings({"removal","Convert2Lambda"}) ================= 1 ==================== - @SuppressWarnings({"unchecked", "CloneDeclaresCloneNotSupported"}) + @SuppressWarnings({"removal","unchecked", "CloneDeclaresCloneNotSupported"}) ================= 1 ==================== - @SuppressWarnings("deprecation") // Use of RMISecurityManager + @SuppressWarnings({"removal","deprecation"}) // Use of RMISecurityManager ================= 1 ==================== - @SuppressWarnings("unchecked") /*To suppress warning from line 1374*/ + @SuppressWarnings({"removal","unchecked"}) /*To suppress warning from line 1374*/ ================= 1 ==================== - @SuppressWarnings("fallthrough") + @SuppressWarnings({"removal","fallthrough"}) All other cases are new annotation embedded inline: ================= 7 ==================== - AccessControlContext acc) { + @SuppressWarnings("removal") AccessControlContext acc) { ================= 4 ==================== - AccessControlContext acc, + @SuppressWarnings("removal") AccessControlContext acc, ================= 3 ==================== - AccessControlContext context, + @SuppressWarnings("removal") AccessControlContext context, ================= 3 ==================== - AccessControlContext acc) + @SuppressWarnings("removal") AccessControlContext acc) ================= 2 ==================== - try (InputStream stream = AccessController.doPrivileged(pa)) { + try (@SuppressWarnings("removal") InputStream stream = AccessController.doPrivileged(pa)) { ================= 2 ==================== - AccessControlContext context, Permission... perms) { + @SuppressWarnings("removal") AccessControlContext context, Permission... perms) { ================= 2 ==================== - } catch (java.security.AccessControlException e) { + } catch (@SuppressWarnings("removal") java.security.AccessControlException e) { ================= 2 ==================== - } catch (AccessControlException ace) { + } catch (@SuppressWarnings("removal") AccessControlException ace) { ================= 2 ==================== - AccessControlContext context) + @SuppressWarnings("removal") AccessControlContext context) ================= 2 ==================== - AccessControlContext acc) throws LoginException { + @SuppressWarnings("removal") AccessControlContext acc) throws LoginException { ================= 2 ==================== - } catch (AccessControlException e) { + } catch (@SuppressWarnings("removal") AccessControlException e) { ================= 1 ==================== - public static void addHook(AccessControlContext acc, PlatformEventType type, Runnable hook) { + public static void addHook(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType type, Runnable hook) { ================= 1 ==================== - DomainCombiner combiner, + @SuppressWarnings("removal") DomainCombiner combiner, ================= 1 ==================== - } catch (java.security.AccessControlException ace) { + } catch (@SuppressWarnings("removal") java.security.AccessControlException ace) { ================= 1 ==================== - private static File checkFile(File f, SecurityManager sm) { + private static File checkFile(File f, @SuppressWarnings("removal") SecurityManager sm) { ================= 1 ==================== - private static File checkFile(File file, SecurityManager sm) { + private static File checkFile(File file, @SuppressWarnings("removal") SecurityManager sm) { ================= 1 ==================== - private static void checkPackageAccessForPermittedSubclasses(SecurityManager sm, + private static void checkPackageAccessForPermittedSubclasses(@SuppressWarnings("removal") SecurityManager sm, ================= 1 ==================== - ProtectionDomain[] getProtectDomains(AccessControlContext context); + ProtectionDomain[] getProtectDomains(@SuppressWarnings("removal") AccessControlContext context); ================= 1 ==================== - SecureCallbackHandler(java.security.AccessControlContext acc, + SecureCallbackHandler(@SuppressWarnings("removal") java.security.AccessControlContext acc, ================= 1 ==================== - private static void addHookInternal(AccessControlContext acc, PlatformEventType type, Runnable hook) { + private static void addHookInternal(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType type, Runnable hook) { ================= 1 ==================== - private void checkMemberAccess(SecurityManager sm, int which, + private void checkMemberAccess(@SuppressWarnings("removal") SecurityManager sm, int which, ================= 1 ==================== - private static File[] checkFiles(Stream filesStream, SecurityManager sm) { + private static File[] checkFiles(Stream filesStream, @SuppressWarnings("removal") SecurityManager sm) { ================= 1 ==================== - Thread(Runnable target, AccessControlContext acc) { + Thread(Runnable target, @SuppressWarnings("removal") AccessControlContext acc) { ================= 1 ==================== - public ProtectionDomain[] getProtectDomains(AccessControlContext context) { + public ProtectionDomain[] getProtectDomains(@SuppressWarnings("removal") AccessControlContext context) { ================= 1 ==================== - AccessControlContext context); + @SuppressWarnings("removal") AccessControlContext context); ================= 1 ==================== - AccessControlContext stack, - AccessControlContext context); + @SuppressWarnings("removal") AccessControlContext stack, + @SuppressWarnings("removal") AccessControlContext context); ================= 1 ==================== - AccessControlContext(ProtectionDomain caller, DomainCombiner combiner, + AccessControlContext(ProtectionDomain caller, @SuppressWarnings("removal") DomainCombiner combiner, ================= 1 ==================== - public URLClassPath(URL[] urls, AccessControlContext acc) { + public URLClassPath(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) { ================= 1 ==================== - URLClassLoader(URL[] urls, AccessControlContext acc) { + URLClassLoader(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) { ================= 1 ==================== - public static void setSecurityManager(SecurityManager sm) { + public static void setSecurityManager(@SuppressWarnings("removal") SecurityManager sm) { ================= 1 ==================== - try (DataInputStream dis = new DataInputStream(new InflaterInputStream( + try (@SuppressWarnings("removal") DataInputStream dis = new DataInputStream(new InflaterInputStream( ================= 1 ==================== - try (FileInputStream fis = AccessController.doPrivileged( + try (@SuppressWarnings("removal") FileInputStream fis = AccessController.doPrivileged( ================= 1 ==================== - FactoryURLClassLoader(URL[] urls, AccessControlContext acc) { + FactoryURLClassLoader(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) { ================= 1 ==================== - Thread newThreadWithAcc(Runnable target, AccessControlContext acc); + Thread newThreadWithAcc(Runnable target, @SuppressWarnings("removal") AccessControlContext acc); ================= 1 ==================== - SecureRecorderListener(AccessControlContext context, FlightRecorderListener changeListener) { + SecureRecorderListener(@SuppressWarnings("removal") AccessControlContext context, FlightRecorderListener changeListener) { ================= 1 ==================== - private PolicyDelegate(PolicySpi spi, Provider p, + private PolicyDelegate(@SuppressWarnings("removal") PolicySpi spi, Provider p, ================= 1 ==================== - DomainCombiner combiner) { + @SuppressWarnings("removal") DomainCombiner combiner) { ================= 1 ==================== - PrivilegedRunnable(Runnable r, AccessControlContext acc) { + PrivilegedRunnable(Runnable r, @SuppressWarnings("removal") AccessControlContext acc) { ================= 1 ==================== - private static File[] checkFiles(Stream fs, SecurityManager sm) { + private static File[] checkFiles(Stream fs, @SuppressWarnings("removal") SecurityManager sm) { ================= 1 ==================== - private void checkSpecifyHandler(SecurityManager sm) { + private void checkSpecifyHandler(@SuppressWarnings("removal") SecurityManager sm) { ================= 1 ==================== - String serverPrincipal, AccessControlContext acc) + String serverPrincipal, @SuppressWarnings("removal") AccessControlContext acc) ================= 1 ==================== - public Thread newThreadWithAcc(Runnable target, AccessControlContext acc) { + public Thread newThreadWithAcc(Runnable target, @SuppressWarnings("removal") AccessControlContext acc) { ================= 1 ==================== - try (InputStream is = AccessController.doPrivileged(new PrivilegedAction() { + try (@SuppressWarnings("removal") InputStream is = AccessController.doPrivileged(new PrivilegedAction() { ================= 1 ==================== - public EventFileStream(AccessControlContext acc, Path path) throws IOException { + public EventFileStream(@SuppressWarnings("removal") AccessControlContext acc, Path path) throws IOException { ================= 1 ==================== - AccessControlContext context, Permission... perms) + @SuppressWarnings("removal") AccessControlContext context, Permission... perms) ================= 1 ==================== - private static void privateCheckPackageAccess(SecurityManager s, Class clazz) { + private static void privateCheckPackageAccess(@SuppressWarnings("removal") SecurityManager s, Class clazz) { ================= 1 ==================== - AbstractEventStream(AccessControlContext acc, PlatformRecording recording, List configurations) throws IOException { + AbstractEventStream(@SuppressWarnings("removal") AccessControlContext acc, PlatformRecording recording, List configurations) throws IOException { ================= 1 ==================== - private void checkPackageAccess(SecurityManager sm, final ClassLoader ccl, + private void checkPackageAccess(@SuppressWarnings("removal") SecurityManager sm, final ClassLoader ccl, ================= 1 ==================== - AccessControlContext context) { + @SuppressWarnings("removal") AccessControlContext context) { ================= 1 ==================== - public PrivilegedExecutor(Executor executor, AccessControlContext acc) { + public PrivilegedExecutor(Executor executor, @SuppressWarnings("removal") AccessControlContext acc) { ================= 1 ==================== - private RequestHook(AccessControlContext acc, PlatformEventType eventType, Runnable hook) { + private RequestHook(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType eventType, Runnable hook) { ================= 1 ==================== - try (BufferedReader bufferedReader = + try (@SuppressWarnings("removal") BufferedReader bufferedReader = ================= 1 ==================== - private static void privateCheckProxyPackageAccess(SecurityManager s, Class clazz) { + private static void privateCheckProxyPackageAccess(@SuppressWarnings("removal") SecurityManager s, Class clazz) { **That's all**. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From psandoz at openjdk.java.net Mon May 17 22:11:10 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 17 May 2021 22:11:10 GMT Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit) [v3] In-Reply-To: References: Message-ID: <3TMBo-E41tbmPdNPsTD_fJuaxFz9fuTzXGQ4s-IrKe4=.fc9af658-90d0-4af3-b569-c11fdea64632@github.com> On Sat, 17 Apr 2021 02:16:44 GMT, Tagir F. Valeev wrote: >> Tagir F. Valeev has updated the pull request incrementally with four additional commits since the last revision: >> >> - More benchmarks >> - adjustSize -> exactOutputSize >> >> Co-authored-by: Paul Sandoz >> - adjustedLimit -> normalizedLimit >> >> Co-authored-by: Paul Sandoz >> - adjustSize -> exactOutputSize >> >> Co-authored-by: Paul Sandoz > > I see your concern. I made some additional benchmarks and added them here. First, CountSized, which just gets the stream size without actual traversal. We can see how the performance changes depending on number of stream operations. I also added an optional type profile pollution that makes `exactOutputSize` virtual method polymorphic. Here's the results: > > Baseline (The `count10Skip` test added just to ensure that patch works) > > Benchmark (pollute) (size) Mode Cnt Score Error Units > count0 false 10000 avgt 100 15,648 ? 0,182 ns/op > count2 false 10000 avgt 100 31,252 ? 0,113 ns/op > count4 false 10000 avgt 100 47,683 ? 0,165 ns/op > count6 false 10000 avgt 100 64,417 ? 0,203 ns/op > count8 false 10000 avgt 100 80,813 ? 0,265 ns/op > count10 false 10000 avgt 100 101,057 ? 0,295 ns/op > count10Skip false 10000 avgt 100 497967,375 ? 5946,108 ns/op > count0 true 10000 avgt 100 18,843 ? 0,103 ns/op > count2 true 10000 avgt 100 33,716 ? 0,152 ns/op > count4 true 10000 avgt 100 49,062 ? 0,208 ns/op > count6 true 10000 avgt 100 66,773 ? 0,237 ns/op > count8 true 10000 avgt 100 82,727 ? 0,354 ns/op > count10 true 10000 avgt 100 104,499 ? 0,299 ns/op > count10Skip true 10000 avgt 100 501723,220 ? 6361,932 ns/op > > Type pollution adds some near-constant ~2ns overhead to the non-patched version as well. > > Patched: > > Benchmark (pollute) (size) Mode Cnt Score Error Units > count0 false 10000 avgt 100 15,363 ? 0,086 ns/op > count2 false 10000 avgt 100 33,736 ? 0,138 ns/op > count4 false 10000 avgt 100 51,470 ? 0,205 ns/op > count6 false 10000 avgt 100 70,407 ? 0,262 ns/op > count8 false 10000 avgt 100 89,865 ? 0,262 ns/op > count10 false 10000 avgt 100 114,423 ? 0,363 ns/op > count10Skip false 10000 avgt 100 139,963 ? 0,550 ns/op > count0 true 10000 avgt 100 26,538 ? 0,084 ns/op > count2 true 10000 avgt 100 46,089 ? 0,191 ns/op > count4 true 10000 avgt 100 66,560 ? 0,315 ns/op > count6 true 10000 avgt 100 87,852 ? 0,288 ns/op > count8 true 10000 avgt 100 109,037 ? 0,391 ns/op > count10 true 10000 avgt 100 139,759 ? 0,382 ns/op > count10Skip true 10000 avgt 100 156,963 ? 1,862 ns/op > > So indeed we have some performance drawback in patched version. Here's a chart: > > ![image](https://user-images.githubusercontent.com/5114450/115098724-c754dd00-9f5b-11eb-86a0-b614a7d36fad.png) > I've calculated linear regression on (patched-baseline) times, depending on the number of ops. It's `y = 1.288x - 0.7078` for clean type profile and `y = 2.6174x + 6.9489` for polluted type profile. So, in the worst case, we have circa 2.6ns per operation plus 7ns constant overhead. > > However, using Stream API without actually iterating the stream is very rare case. And if we iterate, the performance will be dominated by the number of iterations. I tried to model this case with SumSized benchmark (replacing count with sum, for 5 and 10 stream elements), but got very confusing results. > > Baseline: > > Benchmark (pollute) (size) Mode Cnt Score Error Units > sum0 true 5 avgt 100 126,425 ? 0,793 ns/op > sum2 true 5 avgt 100 195,113 ? 1,359 ns/op > sum4 true 5 avgt 100 304,111 ? 8,302 ns/op > sum6 true 5 avgt 100 414,841 ? 3,215 ns/op > sum8 true 5 avgt 100 507,421 ? 4,781 ns/op > sum10 true 5 avgt 100 633,635 ? 7,105 ns/op > sum0 false 5 avgt 100 45,781 ? 0,258 ns/op > sum2 false 5 avgt 100 86,720 ? 0,573 ns/op > sum4 false 5 avgt 100 195,777 ? 1,145 ns/op > sum6 false 5 avgt 100 291,261 ? 2,091 ns/op > sum8 false 5 avgt 100 376,094 ? 3,283 ns/op > sum10 false 5 avgt 100 492,082 ? 7,914 ns/op > sum0 true 10 avgt 100 127,989 ? 0,758 ns/op > sum2 true 10 avgt 100 219,991 ? 3,081 ns/op > sum4 true 10 avgt 100 374,148 ? 7,426 ns/op > sum6 true 10 avgt 100 557,829 ? 3,959 ns/op > sum8 true 10 avgt 100 698,135 ? 4,915 ns/op > sum10 true 10 avgt 100 904,851 ? 14,458 ns/op > sum0 false 10 avgt 100 43,861 ? 0,107 ns/op > sum2 false 10 avgt 100 105,049 ? 0,276 ns/op > sum4 false 10 avgt 100 294,639 ? 1,499 ns/op > sum6 false 10 avgt 100 439,340 ? 4,223 ns/op > sum8 false 10 avgt 100 577,025 ? 5,760 ns/op > sum10 false 10 avgt 100 729,391 ? 6,045 ns/op > > > Patched: > > Benchmark (pollute) (size) Mode Cnt Score Error Units > sum0 true 5 avgt 100 68,466 ? 0,167 ns/op > sum2 true 5 avgt 100 107,240 ? 0,261 ns/op > sum4 true 5 avgt 100 209,469 ? 1,098 ns/op > sum6 true 5 avgt 100 300,873 ? 2,020 ns/op > sum8 true 5 avgt 100 378,654 ? 2,620 ns/op > sum10 true 5 avgt 100 473,769 ? 3,665 ns/op > sum0 false 5 avgt 100 49,435 ? 2,702 ns/op > sum2 false 5 avgt 100 96,237 ? 2,906 ns/op > sum4 false 5 avgt 100 195,196 ? 0,961 ns/op > sum6 false 5 avgt 100 286,542 ? 1,874 ns/op > sum8 false 5 avgt 100 371,664 ? 3,416 ns/op > sum10 false 5 avgt 100 457,178 ? 3,776 ns/op > sum0 true 10 avgt 100 69,223 ? 0,195 ns/op > sum2 true 10 avgt 100 120,507 ? 0,752 ns/op > sum4 true 10 avgt 100 291,328 ? 5,581 ns/op > sum6 true 10 avgt 100 439,136 ? 3,787 ns/op > sum8 true 10 avgt 100 569,188 ? 6,440 ns/op > sum10 true 10 avgt 100 709,916 ? 5,022 ns/op > sum0 false 10 avgt 100 46,347 ? 0,174 ns/op > sum2 false 10 avgt 100 109,131 ? 2,381 ns/op > sum4 false 10 avgt 100 296,566 ? 2,079 ns/op > sum6 false 10 avgt 100 430,852 ? 2,629 ns/op > sum8 false 10 avgt 100 562,795 ? 4,442 ns/op > sum10 false 10 avgt 100 716,229 ? 5,659 ns/op > > > Or, in graphical form: > ![image](https://user-images.githubusercontent.com/5114450/115098879-c2dcf400-9f5c-11eb-9fd3-f72ac7c1d59a.png) > ![image](https://user-images.githubusercontent.com/5114450/115098884-cc665c00-9f5c-11eb-9e9d-d7c9a7aa10ee.png) > > For some reason, non-patched polluted version is the slowest, and I cannot see any stable overhead in patched version. For 4+ intermediate ops, patched version numbers are always better than the corresponding non-patched ones. I would be glad if somebody explains these numbers or point to a flaw in this benchmark. > > What do you think, @PaulSandoz? Is it acceptable overhead or should I experiment with the new Stream flag? @amaembo this dropped of my radar, but the Skara reminder made it visible again! Thank you for the detailed analysis. I cannot explain the results of when triggering profile pollution over the kinds of stream. I think we have good sense that the performance is not unduly perturbed for small streams (there is more work done elsewhere than determining the actual size of the sized stream). Implementation-wise I still find it a little awkward that the operation is responsible for calling the prior op in the pipeline, and we see the consequences of that in the Slice op implementation that predicates on `isParallel`. It might be cleaner if the op is presented with some exact size and adjusts it, something more pure e.g. for SliceOp: long exactOutputSize(long sourceSize) { return calcSize(sourceSize, skip, normalizedLimit); } The default impl would be: long exactOutputSize(long sourceSize) { return sourceSize; } Then the pipeline helper is responsible for traversing the pipeline (be it sequentially or in parallel, in the latter case the above method would not get called since the slice op becomes the source spliterator for the next stages). To do that efficiently does I think require a new flag, set by an op and only meaningful when SIZED is set (and cleared when SIZED is cleared, although perhaps we only need to do that splitting stages for parallel execution, see `AbstractPipeline.sourceSpliterator`). ------------- PR: https://git.openjdk.java.net/jdk/pull/3427 From kvn at openjdk.java.net Mon May 17 22:20:44 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 17 May 2021 22:20:44 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v4] In-Reply-To: References: Message-ID: On Sat, 15 May 2021 02:06:29 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. >> >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> Looking forward to your review and feedback. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > Add missing Lib.gmk I reviewed only HotSpot part. Main complain is long list of library entry points (vector functions) repeated in several files. May be use macros/lambdas? with loops to reduce number of lines and consolidate in one place. Add comments explaining numbers and letters in names. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7290: > 7288: StubRoutines::_vector_cbrt_float128 = (address)os::dll_lookup(libsvml, "__svml_cbrtf4_ha_ex"); > 7289: StubRoutines::_vector_cbrt_double64 = (address)os::dll_lookup(libsvml, "__svml_cbrt1_ha_ex"); > 7290: StubRoutines::_vector_cbrt_double128 = (address)os::dll_lookup(libsvml, "__svml_cbrt2_ha_ex"); May be use macros with **comments**? In this code is very easy make `copy-paste` errors. And It is very not clear for me what all these numbers and letters mean in names. I can guess but it should be comments. src/hotspot/cpu/x86/x86_64.ad line 1713: > 1711: return OptoRegPair(hi, lo); > 1712: } > 1713: Should these methods check `EnableVectorSupport` flag too? Or `UseVectorStubs`? src/hotspot/share/opto/callnode.cpp line 747: > 745: > 746: // If the return is in vector, compute appropriate regmask taking into account the whole range > 747: if(ideal_reg >= Op_VecS && ideal_reg <= Op_VecZ) { Should this be done only for CallLeafVector? Can `Valhalla` return big object in one of vector registers? src/hotspot/share/opto/vectorIntrinsics.cpp line 353: > 351: if (operation == NULL) { > 352: if (C->print_intrinsics()) { > 353: tty->print_cr(" ** svml call failed"); Also print information about the call which fail. src/hotspot/share/opto/vectorIntrinsics.cpp line 1682: > 1680: default: Unimplemented(); break; > 1681: } > 1682: } Macros? src/hotspot/share/runtime/stubRoutines.cpp line 330: > 328: address StubRoutines::_vector_atan2_double256 = NULL; > 329: address StubRoutines::_vector_atan2_double512 = NULL; > 330: #endif // __VECTOR_API_MATH_INTRINSICS_COMMON Macros? ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3638 From erikj at openjdk.java.net Mon May 17 22:30:56 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 17 May 2021 22:30:56 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. Makefile change looks ok. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4073 From dholmes at openjdk.java.net Tue May 18 05:01:46 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 18 May 2021 05:01:46 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: 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.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). > > To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: > > 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. > 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. > 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. > 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. > > Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. > > Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. > > Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. > > There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). > > 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). > > 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: > > rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. Changes to hotspot-* and serviceability look good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4071 From alanb at openjdk.java.net Tue May 18 05:51:41 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 18 May 2021 05:51:41 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: 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.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). > > To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: > > 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. > 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. > 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. > 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. > > Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. > > Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. > > Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. > > There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). > > 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). > > 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: > > rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. Marked as reviewed by alanb (Reviewer). The changes look okay but a bit inconsistent on where -Djava...=allow is inserted for tests that already set other system properties or other parameters. Not a correctness issue, just looks odd in several places, e.g. test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java - the tests sets the system properties after -Xbootclasspath/a: but the change means it sets properties before and after. test/jdk/java/lang/Class/getResource/ResourcesTest.java - you've added it in the middle of the module and class path parameters. For uses using ProcessTools then it seems to be very random. ------------- PR: https://git.openjdk.java.net/jdk/pull/4071 From alanb at openjdk.java.net Tue May 18 06:33:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 18 May 2021 06:33:40 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. src/java.base/share/classes/java/lang/SecurityManager.java line 315: > 313: * > 314: * @since 1.0 > 315: * @deprecated The Security Manager is deprecated and subject to removal in a Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check? ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From jlahoda at openjdk.java.net Tue May 18 10:00:10 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 18 May 2021 10:00:10 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v3] In-Reply-To: References: Message-ID: > 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/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Avoiding fall-through from the total case to a synthetic default but changing total patterns to default. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/54ba974e..5fa8005a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=01-02 Stats: 22 lines in 2 files changed: 21 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From mcimadamore at openjdk.java.net Tue May 18 10:20:41 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 18 May 2021 10:20:41 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v22] In-Reply-To: References: Message-ID: > 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://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - Merge pull request #11 from JornVernee/JEP-412-MXCSR Add MXCSR save and restore to upcall stubs for non-windows platforms - Add MXCSR save and restore to upcall stubs for non-windows platforms ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/9eb61a46..f6051daf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=21 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=20-21 Stats: 32 lines in 1 file changed: 26 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From pconcannon at openjdk.java.net Tue May 18 10:43:52 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Tue, 18 May 2021 10:43:52 GMT Subject: RFR: 8267110: Update java.util to use instanceof pattern variable Message-ID: Hi, Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable? Kind regards, Patrick ------------- Commit messages: - 8267110: Update java.util to use instanceof pattern variable Changes: https://git.openjdk.java.net/jdk/pull/4088/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267110 Stats: 304 lines in 35 files changed: 1 ins; 144 del; 159 mod Patch: https://git.openjdk.java.net/jdk/pull/4088.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4088/head:pull/4088 PR: https://git.openjdk.java.net/jdk/pull/4088 From lancea at openjdk.java.net Tue May 18 11:13:40 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 18 May 2021 11:13:40 GMT Subject: RFR: 8267110: Update java.util to use instanceof pattern variable In-Reply-To: References: Message-ID: On Tue, 18 May 2021 10:37:21 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick Changes look good. ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4088 From dfuchs at openjdk.java.net Tue May 18 11:33:44 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 18 May 2021 11:33:44 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: 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.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). > > To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: > > 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. > 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. > 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. > 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. > > Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. > > Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. > > Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. > > There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). > > 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). > > 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: > > rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. I looked at serviceability, net, and corelibs. The changes look good to me - though I have one question about the NotificationEmissionTest. I believe that regardless of whether the new property is needed, test case 1 should be run in /othervm too. test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 34: > 32: * @run clean NotificationEmissionTest > 33: * @run build NotificationEmissionTest > 34: * @run main NotificationEmissionTest 1 This test case (NotificationEmissionTest 1) calls `System.setProperty("java.security.policy", policyFile);` - even though it doesn't call System.setSecurityManager(); Should the @run command line for test case 1 be modified as well? ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4071 From alanb at openjdk.java.net Tue May 18 12:05:38 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 18 May 2021 12:05:38 GMT Subject: RFR: 8267110: Update java.util to use instanceof pattern variable In-Reply-To: References: Message-ID: On Tue, 18 May 2021 10:37:21 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick You may need to coordinate with @DougLea on the changes to j.u.concurrent. ------------- PR: https://git.openjdk.java.net/jdk/pull/4088 From dl at openjdk.java.net Tue May 18 12:23:43 2021 From: dl at openjdk.java.net (Doug Lea) Date: Tue, 18 May 2021 12:23:43 GMT Subject: RFR: 8267110: Update java.util to use instanceof pattern variable In-Reply-To: References: Message-ID: On Tue, 18 May 2021 10:37:21 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick Because we still make jdk11-compatible test-release java.util.concurrent jars, we are not big fans of adding non-essential differences to openjdk version. But if there is some advantage to doing this, we'll cope. ------------- PR: https://git.openjdk.java.net/jdk/pull/4088 From mullan at openjdk.java.net Tue May 18 12:44:48 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 18 May 2021 12:44:48 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Tue, 18 May 2021 06:31:06 GMT, Alan Bateman 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > src/java.base/share/classes/java/lang/SecurityManager.java line 315: > >> 313: * >> 314: * @since 1.0 >> 315: * @deprecated The Security Manager is deprecated and subject to removal in a > > Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check? It includes both: ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg) ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From jorn.vernee at oracle.com Tue May 18 13:18:56 2021 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Tue, 18 May 2021 15:18:56 +0200 Subject: RFC: Add a --validate option to the jar tool In-Reply-To: <8fddb7b4-6e8f-6cf6-02ee-50aa3f462919@oracle.com> References: <49af48ea-64b2-67fb-2457-838be780d925@oracle.com> <8fddb7b4-6e8f-6cf6-02ee-50aa3f462919@oracle.com> Message-ID: <9f4bfe4f-44ce-1059-010a-f995890472c4@oracle.com> I'll go ahead with this enhancement, and make sure the wording is open to adding validation logic not related to multi-release jars in the future. Jorn On 12/05/2021 14:47, Jorn Vernee wrote: > On 12/05/2021 14:41, Alan Bateman wrote: >> On 12/05/2021 11:58, Jorn Vernee wrote: >>> Hi, >>> >>> I see that the jar tool has validation logic for multi-release jars >>> that is triggered when creating or updating a jar that has a >>> versioned file as an input. I wanted to ask what people think about >>> the idea of exposing this validation logic directly under a >>> --validate command line flag as well. >>> >>> Malformed multi-release jars can cause compilation and runtime >>> problems because the API exposed by the jar is different across >>> different Java versions. Exposing the validation logic directly >>> would allow for easy validation of jar files that are suspected of >>> being malformed multi-release jars. >>> >>> The validation logic is already cleanly separated into a separate >>> Validator class in the source code, and adding a command line flag >>> that exposes it directly is a relatively minimal change [1]. It >>> seems like maybe the intent in the past was also to expose this >>> validation logic directly? >>> >>> What's the history here? Any opinions about exposing this validation >>> logic through a command line option? >> >> I think it could be useful, esp. if Maven or Gradle plugins could >> make use of it. >> >> There is other validation that could be done. JDK-8207339 is one >> example where it would be useful to identify a JAR file with a >> services configuration file that disagrees with the module >> definition. I bring it up because a general --validate option could >> do more than the fingerprint check. If the intention is to limit it >> to MR JAR features then I think it will need a different and more >> specific option name. > Potentially doing other validation seems like a good idea to me as > well. It seems like the validation logic could be expanded further in > the future. I brought up multi-release jars because AFAICS that's the > only thing the existing validation logic concerns itself with, but I > don't see any reason why validation that doesn't relate to > multi-release jars couldn't be added as well (and I guess I chose the > name --validate for that reason :) ) > > Jorn From weijun at openjdk.java.net Tue May 18 14:01:41 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 18 May 2021 14:01:41 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager In-Reply-To: References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: On Tue, 18 May 2021 11:12:00 GMT, Daniel Fuchs 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.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). >> >> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, i18n, rmi, javadoc, swing, 2d, security, hotspot-runtime, nio, xml, beans, ~~core-libs~~, ~~net~~, compiler, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: >> >> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. >> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. >> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. >> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. >> >> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. >> >> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. >> >> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. >> >> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). >> >> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). >> >> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: >> >> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) >> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) >> ``` >> >> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. > > test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 34: > >> 32: * @run clean NotificationEmissionTest >> 33: * @run build NotificationEmissionTest >> 34: * @run main NotificationEmissionTest 1 > > This test case (NotificationEmissionTest 1) calls `System.setProperty("java.security.policy", policyFile);` - even though it doesn't call System.setSecurityManager(); Should the @run command line for test case 1 be modified as well? Or maybe the policy setting line should only be called when a security manager is set? IIRC jtreg is able to restore system properties even in agentvm mode. So maybe this really doesn't matter. We just want to modify as little as possible in this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4071 From weijun at openjdk.java.net Tue May 18 14:07:38 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 18 May 2021 14:07:38 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager In-Reply-To: References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: On Tue, 18 May 2021 05:48:56 GMT, Alan Bateman wrote: > The changes look okay but a bit inconsistent on where -Djava...=allow is inserted for tests that already set other system properties or other parameters. Not a correctness issue, just looks odd in several places, e.g. > > test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java - the tests sets the system properties after -Xbootclasspath/a: but the change means it sets properties before and after. > > test/jdk/java/lang/Class/getResource/ResourcesTest.java - you've added it in the middle of the module and class path parameters. > > For uses using ProcessTools then it seems to be very random. I've updated the 3 cases you mentioned and will go through more. Yes it looks good to group system property settings together. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4071 From alanb at openjdk.java.net Tue May 18 15:22:42 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 18 May 2021 15:22:42 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Tue, 18 May 2021 12:42:08 GMT, Sean Mullan wrote: >> src/java.base/share/classes/java/lang/SecurityManager.java line 315: >> >>> 313: * >>> 314: * @since 1.0 >>> 315: * @deprecated The Security Manager is deprecated and subject to removal in a >> >> Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check? > > It includes both: > ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg) Thanks for checking, I assumed that was the case so wondering if it should be dropped from the deprecation text to avoid the repeated sentence. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From mullan at openjdk.java.net Tue May 18 15:49:38 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 18 May 2021 15:49:38 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: <0_9OMaDXfGSSqm5VdlusV4KRWnHxD2KFD5ifyV1hVFI=.1ba2b000-954e-4b23-a869-7d3aa1a909d6@github.com> On Tue, 18 May 2021 15:19:21 GMT, Alan Bateman wrote: >> It includes both: >> ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg) > > Thanks for checking, I assumed that was the case so wondering if it should be dropped from the deprecation text to avoid the repeated sentence. My feeling is that it is better to be more specific than the generic removal text as this is the most significant class that is being deprecated for removal. Also, this says "the Security Manager" (note the space between) which really encompasses more than the `java.lang.SecurityManager` API and which is explained more completely in the JEP. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From darcy at openjdk.java.net Tue May 18 16:29:47 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 18 May 2021 16:29:47 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From chegar at openjdk.java.net Tue May 18 16:38:42 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 18 May 2021 16:38:42 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. The changes in the net area look fine. ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4073 From naoto at openjdk.java.net Tue May 18 16:45:40 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 18 May 2021 16:45:40 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. Reviewed i18n/java.time/charset. They all look good. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4073 From naoto at openjdk.java.net Tue May 18 16:52:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 18 May 2021 16:52:41 GMT Subject: RFR: 8267110: Update java.util to use instanceof pattern variable In-Reply-To: References: Message-ID: On Tue, 18 May 2021 10:37:21 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick Classes in the i18n area look good. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4088 From joehw at openjdk.java.net Tue May 18 17:30:39 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 18 May 2021 17:30:39 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. java.xml changes look good. Thanks. ------------- Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4073 From alanb at openjdk.java.net Tue May 18 17:39:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 18 May 2021 17:39:40 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. Marked as reviewed by alanb (Reviewer). src/java.base/share/classes/java/security/AccessController.java line 877: > 875: @CallerSensitive > 876: public static T doPrivileged(PrivilegedExceptionAction action, > 877: @SuppressWarnings("removal") AccessControlContext context, Permission... perms) you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From mchung at openjdk.java.net Tue May 18 17:43:39 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 18 May 2021 17:43:39 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: 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.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). > > To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, i18n, rmi, javadoc, swing, 2d, security, hotspot-runtime, nio, xml, beans, ~~core-libs~~, ~~net~~, compiler, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: > > 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. > 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. > 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. > 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. > > Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. > > Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. > > Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. > > There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). > > 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). > > 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: > > rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. I reviewed non-client areas. Looks okay. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4071 From mchung at openjdk.java.net Tue May 18 17:53:51 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 18 May 2021 17:53:51 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From plevart at openjdk.java.net Tue May 18 18:03:48 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 18 May 2021 18:03:48 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v2] In-Reply-To: <-4wVyKFO8p5jFap50H7tmoQ5VRzSnwZ1A4dCsqy9rOk=.7b351a5f-f127-4941-9467-ac864de71509@github.com> References: <-4wVyKFO8p5jFap50H7tmoQ5VRzSnwZ1A4dCsqy9rOk=.7b351a5f-f127-4941-9467-ac864de71509@github.com> Message-ID: <5PDgT2ctbgsXq8ZHBYQa_4M_AFNKadmKqwUBFWAhCgs=.88433340-cece-4c4a-a1a5-87fbaf27f80d@github.com> On Mon, 17 May 2021 17:19:19 GMT, Stephen Colebourne wrote: >> 8266846: Add java.time.InstantSource > > Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: > > 8266846: Add java.time.InstantSource Changes requested by plevart (Reviewer). src/java.base/share/classes/java/time/Clock.java line 487: > 485: // it more unlikely to hit the 1ns in the future condition. > 486: localOffset = System.currentTimeMillis()/1000 - 1024; > 487: Is it possible that after a fresh localOffset is retrieved, the thread is preempted and when it is scheduled again after a pause, the getNanoTimeAdjustment below returns -1 ? Would it help if instead of throwing exception, there was an infinite retry loop? ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From weijun at openjdk.java.net Tue May 18 18:42:26 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 18 May 2021 18:42:26 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Tue, 18 May 2021 17:36:55 GMT, Alan Bateman 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > src/java.base/share/classes/java/security/AccessController.java line 877: > >> 875: @CallerSensitive >> 876: public static T doPrivileged(PrivilegedExceptionAction action, >> 877: @SuppressWarnings("removal") AccessControlContext context, Permission... perms) > > you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens. My rule is that a new line is added if there's only whitespaces before the insert position and the previous line does not end with a comma. In this case, unless I move `Permission... perms` onto a new line that an annotation on a new line looks like covering both `context` and `perms`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From lancea at openjdk.java.net Tue May 18 19:07:23 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 18 May 2021 19:07:23 GMT Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. [v3] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 14:39:05 GMT, Mitsuru Kariya wrote: >> Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases: >> >> 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. >> (test31) >> >> 2. `pos - 1 + length > this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1 >> (test32) >> >> 3. `pos == this.length() + 1` >> The original implementation throws `SerialException` but this case should end successfully. *2 >> (test33) >> >> 4. `length < 0` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test34) >> >> 5. `offset + length > Integer.MAX_VALUE` >> The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. >> (test35) >> >> Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases: >> >> 1. `offset > str.length()` >> The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test39) >> >> 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. >> (test32) >> >> 3. `pos - 1 + length > this.length()` >> The original implementaion throws `SerialException` but this case should end successfully. *3 >> (test40) >> >> 4. `pos == this.length() + 1` >> The original implementaion throws `SerialException` but this case should end successfully. *4 >> (test41) >> >> 5. `length < 0` >> The original implementation throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test42) >> >> 6. `offset + length > Integer.MAX_VALUE` >> The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. >> (test43) >> >> >> The javadoc has also been modified according to the above. >> >> *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes." >> >> *2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined." >> So, it should work correctly when pos == length+1 of the BLOB value. >> >> *3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters." >> >> *4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined." >> So, it should work correctly when pos == length+1 of the CLOB value. > > Mitsuru Kariya has updated the pull request incrementally with one additional commit since the last revision: > > Fix for length + offset > Integer.MAX_VALUE case Overall the changes look reasonable. As mentioned in the comments, a CSR will be required due to some of the wordsmithing cleanup src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialBlob.java line 306: > 304: * > 305: * @param pos the position in the SQL BLOB value at which > 306: * to start writing. The first position is 1; When updating the javadoc to use @code, please update all instances for consistency src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialBlob.java line 308: > 306: * to start writing. The first position is 1; > 307: * must not be less than 1 nor greater than > 308: * the length+1 of this {@code SerialBlob} object. Changes such as this require a CSR. I think I have convinced myself that it is OK to move forward with the CSR. src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialBlob.java line 313: > 311: * @return the number of bytes written > 312: * @throws SerialException if there is an error accessing the > 313: * {@code BLOB} value; or if an invalid position is set; Even though this addresses a typo, this will require a CSR ------------- Changes requested by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4001 From lancea at openjdk.java.net Tue May 18 19:09:28 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 18 May 2021 19:09:28 GMT Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. [v3] In-Reply-To: References: Message-ID: <67cyn8TRFVcijg4ewkd45WQgjoAzKWwsj44chc36zME=.27b68fe2-7f42-4e1f-890c-1589611b9d2d@github.com> On Mon, 17 May 2021 14:39:05 GMT, Mitsuru Kariya wrote: >> Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases: >> >> 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. >> (test31) >> >> 2. `pos - 1 + length > this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1 >> (test32) >> >> 3. `pos == this.length() + 1` >> The original implementation throws `SerialException` but this case should end successfully. *2 >> (test33) >> >> 4. `length < 0` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test34) >> >> 5. `offset + length > Integer.MAX_VALUE` >> The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. >> (test35) >> >> Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases: >> >> 1. `offset > str.length()` >> The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test39) >> >> 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. >> (test32) >> >> 3. `pos - 1 + length > this.length()` >> The original implementaion throws `SerialException` but this case should end successfully. *3 >> (test40) >> >> 4. `pos == this.length() + 1` >> The original implementaion throws `SerialException` but this case should end successfully. *4 >> (test41) >> >> 5. `length < 0` >> The original implementation throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test42) >> >> 6. `offset + length > Integer.MAX_VALUE` >> The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. >> (test43) >> >> >> The javadoc has also been modified according to the above. >> >> *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes." >> >> *2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined." >> So, it should work correctly when pos == length+1 of the BLOB value. >> >> *3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters." >> >> *4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined." >> So, it should work correctly when pos == length+1 of the CLOB value. > > Mitsuru Kariya has updated the pull request incrementally with one additional commit since the last revision: > > Fix for length + offset > Integer.MAX_VALUE case I have run the JCK tests in addition to to the JTREG Tess to validate there are no additional failures due to these changes ------------- PR: https://git.openjdk.java.net/jdk/pull/4001 From psandoz at openjdk.java.net Tue May 18 20:36:43 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 18 May 2021 20:36:43 GMT Subject: RFR: 8267190: Optimize Vector API test operations In-Reply-To: References: Message-ID: On Fri, 14 May 2021 23:58:38 GMT, Sandhya Viswanathan wrote: > Vector API test operations (IS_DEFAULT, IS_FINITE, IS_INFINITE, IS_NAN and IS_NEGATIVE) are computed in three steps: > 1) reinterpreting the floating point vectors as integral vectors (int/long) > 2) perform the test in integer domain to get a int/long mask > 3) reinterpret the int/long mask as float/double mask > Step 3) currently is very slow. It can be optimized by modifying the Java code to utilize the existing reinterpret intrinsic. > > For the VectorTestPerf attached to the JBS for JDK-8267190, the performance improves as follows: > > Base: > Benchmark (size) Mode Cnt Score Error Units > VectorTestPerf.IS_DEFAULT 1024 thrpt 5 223.156 ? 90.452 ops/ms > VectorTestPerf.IS_FINITE 1024 thrpt 5 223.841 ? 91.685 ops/ms > VectorTestPerf.IS_INFINITE 1024 thrpt 5 224.561 ? 83.890 ops/ms > VectorTestPerf.IS_NAN 1024 thrpt 5 223.777 ? 70.629 ops/ms > VectorTestPerf.IS_NEGATIVE 1024 thrpt 5 218.392 ? 79.806 ops/ms > > With patch: > Benchmark (size) Mode Cnt Score Error Units > VectorTestPerf.IS_DEFAULT 1024 thrpt 5 8812.357 ? 40.477 ops/ms > VectorTestPerf.IS_FINITE 1024 thrpt 5 7425.739 ? 296.622 ops/ms > VectorTestPerf.IS_INFINITE 1024 thrpt 5 8932.730 ? 269.988 ops/ms > VectorTestPerf.IS_NAN 1024 thrpt 5 8574.872 ? 498.649 ops/ms > VectorTestPerf.IS_NEGATIVE 1024 thrpt 5 8838.400 ? 11.849 ops/ms > > Best Regards, > Sandhya Changes look good, some minor comments. I shall run it through tier 1 to 3 tests and report back. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 609: > 607: @ForceInline > 608: final > 609: VectorMask defaultMaskReinterpret(VectorSpecies dsp) { Since this method is only called by `cast` we can make this method private and accept an argument of `AbstractSpecies`. Further, the length check is duplicated by `cast` so we could turn it into an assert. Extra bonus points for converting the statement switch into an expression switch. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4039 From rriggs at openjdk.java.net Tue May 18 20:55:09 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 18 May 2021 20:55:09 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v2] In-Reply-To: References: Message-ID: <77qgKLTHn2YAQqPi5S1WCTXMpwnfqid165juQPVhOCw=.f389ffb4-5684-4ad9-aa4a-452576dbdbf0@github.com> > JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. > The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional > configuration mechanisms and filter utilities. > > javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: > http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Add utilities to reject undecided results, allow unlimited limits, and improve robustness of examples ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3996/files - new: https://git.openjdk.java.net/jdk/pull/3996/files/5414d505..3ec309f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=00-01 Stats: 562 lines in 4 files changed: 351 ins; 59 del; 152 mod Patch: https://git.openjdk.java.net/jdk/pull/3996.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3996/head:pull/3996 PR: https://git.openjdk.java.net/jdk/pull/3996 From naoto at openjdk.java.net Tue May 18 21:07:42 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 18 May 2021 21:07:42 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v2] In-Reply-To: <-4wVyKFO8p5jFap50H7tmoQ5VRzSnwZ1A4dCsqy9rOk=.7b351a5f-f127-4941-9467-ac864de71509@github.com> References: <-4wVyKFO8p5jFap50H7tmoQ5VRzSnwZ1A4dCsqy9rOk=.7b351a5f-f127-4941-9467-ac864de71509@github.com> Message-ID: <-hgApr-MNMiCiU90l9cMiqx3lMBNRU9ik0lAmMamvSU=.62f2029b-b52f-4d03-be8d-e4758a2d5c46@github.com> On Mon, 17 May 2021 17:19:19 GMT, Stephen Colebourne wrote: >> 8266846: Add java.time.InstantSource > > Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: > > 8266846: Add java.time.InstantSource src/java.base/share/classes/java/time/Instant.java line 275: > 273: */ > 274: public static Instant now() { > 275: return Clock.currentInstant(); Copyright year should change to 2021 for this change. test/jdk/java/time/test/java/time/TestInstantSource.java line 59: > 57: assertTrue(Math.abs(testMillis - millis) < 1000); > 58: assertTrue(Math.abs(testInstantMillis - millis) < 1000); > 59: assertSame(test.equals(InstantSource.system()); ')' is missing. Couple other locations. test/jdk/java/time/test/java/time/TestInstantSource.java line 86: > 84: assertEquals(test.instant(), instant); > 85: assertSame(test.equals(InstantSource..fixed(instant)); > 86: assertEquals(test.hashCode(), InstantSource..fixed(instant).hashCode()); Not sure this would compile. ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From redestad at openjdk.java.net Tue May 18 21:08:00 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 18 May 2021 21:08:00 GMT Subject: RFR: 8267321: Use switch expression for VarHandle$AccessMode lookup Message-ID: Using a switch expression instead of a (read-only) static `HashMap` reduces initialization overhead of `VarHandle$AccessMode`. This gets loaded earlier after JDK-8265079, so it started showing up in a few lambda startup tests. This also obsoletes a jtreg test that only verified that this map was optimally sized. ------------- Commit messages: - Remove obsolete test - Transform AccessMode name map into switch expression Changes: https://git.openjdk.java.net/jdk/pull/4102/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4102&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267321 Stats: 90 lines in 2 files changed: 31 ins; 56 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4102.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4102/head:pull/4102 PR: https://git.openjdk.java.net/jdk/pull/4102 From weijun at openjdk.java.net Tue May 18 21:13:40 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 18 May 2021 21:13:40 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Tue, 18 May 2021 18:38:52 GMT, Weijun Wang wrote: >> src/java.base/share/classes/java/security/AccessController.java line 877: >> >>> 875: @CallerSensitive >>> 876: public static T doPrivileged(PrivilegedExceptionAction action, >>> 877: @SuppressWarnings("removal") AccessControlContext context, Permission... perms) >> >> you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens. > > I'll try to update my auto-annotating program. Turns out this only happens in this class: $ rg '^\s*@SuppressWarnings("removal").*?,.' src/java.base/share/classes/java/security/AccessController.java:449: @SuppressWarnings("removal") AccessControlContext context, Permission... perms) { src/java.base/share/classes/java/security/AccessController.java:514: @SuppressWarnings("removal") AccessControlContext context, Permission... perms) { src/java.base/share/classes/java/security/AccessController.java:877: @SuppressWarnings("removal") AccessControlContext context, Permission... perms) I'll fix them manually. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Tue May 18 21:21:45 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 18 May 2021 21:21:45 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v2] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: > 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: feedback from Sean, Phil and Alan ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4073/files - new: https://git.openjdk.java.net/jdk/pull/4073/files/eb6c566f..bb73093a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=00-01 Stats: 9 lines in 3 files changed: 4 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From bchristi at openjdk.java.net Tue May 18 21:23:08 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 18 May 2021 21:23:08 GMT Subject: RFR: 8266936: Add a finalization JFR event Message-ID: Please review this enhancement to add a new JFR event, generated whenever a finalizer is run. (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).) The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized. The Category for the event: `"Java Virtual Machine" / "GC" / "Finalization"` is what made sense to me, even though the event is generated from library code. Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr. Automated testing looks good so far. Thanks, -Brent ------------- Commit messages: - Fix jcheck some more - Fix jcheck - Merge branch 'master' into 8266936 - Add jfr mode to test/jdk/java/lang/ref/FinalizeOverride.java - Fix spacing in new regtest - Remove extraneous comments from new regtest - Removed unintentional changes from FinalizeOverride.java - Actually check in new regtest - Update TestActiveSettingEvent.java - Update TestDefaultConfigurations.java and .jfc files - ... and 2 more: https://git.openjdk.java.net/jdk/compare/e6705c0e...200268ab Changes: https://git.openjdk.java.net/jdk/pull/4101/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4101&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266936 Stats: 191 lines in 11 files changed: 190 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4101.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4101/head:pull/4101 PR: https://git.openjdk.java.net/jdk/pull/4101 From github.com+6502015+ineuwirth at openjdk.java.net Tue May 18 21:43:48 2021 From: github.com+6502015+ineuwirth at openjdk.java.net (Istvan Neuwirth) Date: Tue, 18 May 2021 21:43:48 GMT Subject: RFR: 8266936: Add a finalization JFR event In-Reply-To: References: Message-ID: On Tue, 18 May 2021 20:55:10 GMT, Brent Christian wrote: > Please review this enhancement to add a new JFR event, generated whenever a finalizer is run. > (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).) > > The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized. > > The Category for the event: > `"Java Virtual Machine" / "GC" / "Finalization"` > is what made sense to me, even though the event is generated from library code. > > Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr. > Automated testing looks good so far. > > Thanks, > -Brent test/jdk/jdk/jfr/event/gc/finalization/TestFinalizerEvent.java line 48: > 46: > 47: public class TestFinalizerEvent { > 48: static boolean finalizerRun = false; Should not this be a `volatile` field? (Or alternatively, using `AtomicBoolean`). As the `finalize` is invoked on the finalizer thread, the other thread executing the test might not see the change. ------------- PR: https://git.openjdk.java.net/jdk/pull/4101 From weijun at openjdk.java.net Tue May 18 21:44:43 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 18 May 2021 21:44:43 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager [v2] In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: > 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.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). > > To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: > > 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. > 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. > 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. > 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. > > Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. > > Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. > > Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. > > There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). > > 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). > > 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: > > rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: adjust order of VM options ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4071/files - new: https://git.openjdk.java.net/jdk/pull/4071/files/900c28c0..bfa955ad Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=00-01 Stats: 59 lines in 18 files changed: 8 ins; 6 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/4071.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071 PR: https://git.openjdk.java.net/jdk/pull/4071 From bchristi at openjdk.java.net Tue May 18 22:27:37 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 18 May 2021 22:27:37 GMT Subject: RFR: 8266936: Add a finalization JFR event In-Reply-To: References: Message-ID: On Tue, 18 May 2021 21:40:57 GMT, Istvan Neuwirth wrote: >> Please review this enhancement to add a new JFR event, generated whenever a finalizer is run. >> (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).) >> >> The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized. >> >> The Category for the event: >> `"Java Virtual Machine" / "GC" / "Finalization"` >> is what made sense to me, even though the event is generated from library code. >> >> Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr. >> Automated testing looks good so far. >> >> Thanks, >> -Brent > > test/jdk/jdk/jfr/event/gc/finalization/TestFinalizerEvent.java line 48: > >> 46: >> 47: public class TestFinalizerEvent { >> 48: static boolean finalizerRun = false; > > Should not this be a `volatile` field? (Or alternatively, using `AtomicBoolean`). As the `finalize` is invoked on the finalizer thread, the other thread executing the test might not see the change. Good idea, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4101 From bchristi at openjdk.java.net Tue May 18 22:41:06 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 18 May 2021 22:41:06 GMT Subject: RFR: 8266936: Add a finalization JFR event [v2] In-Reply-To: References: Message-ID: > Please review this enhancement to add a new JFR event, generated whenever a finalizer is run. > (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).) > > The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized. > > The Category for the event: > `"Java Virtual Machine" / "GC" / "Finalization"` > is what made sense to me, even though the event is generated from library code. > > Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr. > Automated testing looks good so far. > > Thanks, > -Brent Brent Christian has updated the pull request incrementally with one additional commit since the last revision: Test flag should be volatile ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4101/files - new: https://git.openjdk.java.net/jdk/pull/4101/files/200268ab..e0ef383b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4101&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4101&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4101.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4101/head:pull/4101 PR: https://git.openjdk.java.net/jdk/pull/4101 From joehw at openjdk.java.net Tue May 18 22:53:39 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 18 May 2021 22:53:39 GMT Subject: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current In-Reply-To: References: Message-ID: On Mon, 17 May 2021 16:55:35 GMT, Naoto Sato wrote: > Please review the changes to the subject issue. java.util.Locale class has a long-standing issue for those obsolete ISO 639 languages where its normalization ends up in the obsolete codes. This change intends to flip the normalization towards the current codes, providing a system property for compatibility behavior. ResourceBundle class is also modified to load either obsolete/current bundles. For more detail, take a look at the CSR. src/java.base/share/classes/java/util/Locale.java line 462: > 460: * backward compatible forms. > 461: * > 462: *

The APIs added in 1.7 map between the old and new language codes, This paragraph needs a rewrite as well it seems, esp. the part that states "getLanguage and toString reflect the old code" is no longer true. test/jdk/java/util/Locale/LocaleTest.java line 683: > 681: * @bug 4052404 4778440 8263202 > 682: */ > 683: public void TestChangedISO639Codes() { Could probably be simplified with a DataProvider. ------------- PR: https://git.openjdk.java.net/jdk/pull/4069 From mr at openjdk.java.net Tue May 18 23:01:05 2021 From: mr at openjdk.java.net (Mark Reinhold) Date: Tue, 18 May 2021 23:01:05 GMT Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v4] In-Reply-To: References: Message-ID: > 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 Reinhold has updated the pull request incrementally with one additional commit since the last revision: Fix up IllegalAccessTest ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4015/files - new: https://git.openjdk.java.net/jdk/pull/4015/files/1c14998e..cde0adbb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4015&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4015&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4015.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4015/head:pull/4015 PR: https://git.openjdk.java.net/jdk/pull/4015 From mr at openjdk.java.net Tue May 18 23:01:07 2021 From: mr at openjdk.java.net (Mark Reinhold) Date: Tue, 18 May 2021 23:01:07 GMT Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v3] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 08:54:23 GMT, Alan Bateman wrote: >> Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove now-unnecessary uses and mentions of the --illegal-access option > > test/jdk/tools/launcher/modules/illegalaccess/IllegalAccessTest.java line 26: > >> 24: /** >> 25: * @test >> 26: * @requires vm.compMode != "Xcomp" > > I think `@requires vm.compMode != "Xcomp" was added because the test took too long with -Xcomp. I think it can be dropped now. Dropped. > test/jdk/tools/launcher/modules/illegalaccess/IllegalAccessTest.java line 37: > >> 35: >> 36: /** >> 37: * Basic test of --illegal-access=value to deny or permit access to JDK internals. > > The comment should probably be updated as the test no longer tests denying or permitting access. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4015 From scolebourne at openjdk.java.net Tue May 18 23:18:42 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Tue, 18 May 2021 23:18:42 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v3] In-Reply-To: References: Message-ID: > 8266846: Add java.time.InstantSource Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: 8266846: Add java.time.InstantSource ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4016/files - new: https://git.openjdk.java.net/jdk/pull/4016/files/7fa9d0ec..425e01a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4016&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4016&range=01-02 Stats: 12 lines in 3 files changed: 1 ins; 3 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4016.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4016/head:pull/4016 PR: https://git.openjdk.java.net/jdk/pull/4016 From scolebourne at openjdk.java.net Tue May 18 23:18:43 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Tue, 18 May 2021 23:18:43 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v3] In-Reply-To: <5PDgT2ctbgsXq8ZHBYQa_4M_AFNKadmKqwUBFWAhCgs=.88433340-cece-4c4a-a1a5-87fbaf27f80d@github.com> References: <-4wVyKFO8p5jFap50H7tmoQ5VRzSnwZ1A4dCsqy9rOk=.7b351a5f-f127-4941-9467-ac864de71509@github.com> <5PDgT2ctbgsXq8ZHBYQa_4M_AFNKadmKqwUBFWAhCgs=.88433340-cece-4c4a-a1a5-87fbaf27f80d@github.com> Message-ID: On Sun, 16 May 2021 07:39:21 GMT, Peter Levart wrote: >> Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: >> >> 8266846: Add java.time.InstantSource > > src/java.base/share/classes/java/time/Clock.java line 487: > >> 485: // it more unlikely to hit the 1ns in the future condition. >> 486: localOffset = System.currentTimeMillis()/1000 - 1024; >> 487: > > Is it possible that after a fresh localOffset is retrieved, the thread is preempted and when it is scheduled again after a pause, the getNanoTimeAdjustment below returns -1 ? Would it help if instead of throwing exception, there was an infinite retry loop? This isn't my logic - it is existing code that has been moved. I'm not a fan of infinite retry loops as the can hang the system. But I'm happy to change it to work that way if there is a consensus to do so. ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From scolebourne at openjdk.java.net Tue May 18 23:25:41 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Tue, 18 May 2021 23:25:41 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v2] In-Reply-To: <-hgApr-MNMiCiU90l9cMiqx3lMBNRU9ik0lAmMamvSU=.62f2029b-b52f-4d03-be8d-e4758a2d5c46@github.com> References: <-4wVyKFO8p5jFap50H7tmoQ5VRzSnwZ1A4dCsqy9rOk=.7b351a5f-f127-4941-9467-ac864de71509@github.com> <-hgApr-MNMiCiU90l9cMiqx3lMBNRU9ik0lAmMamvSU=.62f2029b-b52f-4d03-be8d-e4758a2d5c46@github.com> Message-ID: On Tue, 18 May 2021 21:04:18 GMT, Naoto Sato wrote: >> Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: >> >> 8266846: Add java.time.InstantSource > > test/jdk/java/time/test/java/time/TestInstantSource.java line 86: > >> 84: assertEquals(test.instant(), instant); >> 85: assertSame(test.equals(InstantSource..fixed(instant)); >> 86: assertEquals(test.hashCode(), InstantSource..fixed(instant).hashCode()); > > Not sure this would compile. I was expecting the GitHub Action to pickup coding and test issues (since my dev setup can't compile or run tests). But it seems it doesn't. do that. The latest commit should at least compile as I copied the test class to another IDE location, but I have no way of knowing if the tests pass. ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From sviswanathan at openjdk.java.net Tue May 18 23:27:13 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 18 May 2021 23:27:13 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v5] In-Reply-To: References: Message-ID: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: Implement review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/01a549e4..9021a15c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=03-04 Stats: 1220 lines in 8 files changed: 48 ins; 1104 del; 68 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From naoto at openjdk.java.net Tue May 18 23:39:42 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 18 May 2021 23:39:42 GMT Subject: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current [v2] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 22:22:06 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Locale's class description modification > > src/java.base/share/classes/java/util/Locale.java line 462: > >> 460: * backward compatible forms. >> 461: * >> 462: *

The APIs added in 1.7 map between the old and new language codes, > > This paragraph needs a rewrite as well it seems, esp. the part that states "getLanguage and toString reflect the old code" is no longer true. Good catch! In fact, I had modified this paragraph in my preliminary fix, but it slipped away somehow along the fix. Corrected the PR and CSR as well. > test/jdk/java/util/Locale/LocaleTest.java line 683: > >> 681: * @bug 4052404 4778440 8263202 >> 682: */ >> 683: public void TestChangedISO639Codes() { > > Could probably be simplified with a DataProvider. That would be nice, but the test is not testng based, and it would be an entire test rewrite which I would not do it at this time. ------------- PR: https://git.openjdk.java.net/jdk/pull/4069 From naoto at openjdk.java.net Tue May 18 23:39:37 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 18 May 2021 23:39:37 GMT Subject: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current [v2] In-Reply-To: References: Message-ID: > Please review the changes to the subject issue. java.util.Locale class has a long-standing issue for those obsolete ISO 639 languages where its normalization ends up in the obsolete codes. This change intends to flip the normalization towards the current codes, providing a system property for compatibility behavior. ResourceBundle class is also modified to load either obsolete/current bundles. For more detail, take a look at the CSR. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Locale's class description modification ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4069/files - new: https://git.openjdk.java.net/jdk/pull/4069/files/dee95bf1..0f76ac45 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4069&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4069&range=00-01 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4069.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4069/head:pull/4069 PR: https://git.openjdk.java.net/jdk/pull/4069 From sviswanathan at openjdk.java.net Tue May 18 23:43:13 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 18 May 2021 23:43:13 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v6] In-Reply-To: References: Message-ID: <6cWkz6rWmKC0L2U3sYiELeoOphNGlEHvCoSXcJHE-hE=.04e407ec-be8f-4d01-b527-ec7e1d30bb34@github.com> > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: Print intrinsic fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/9021a15c..11528426 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=04-05 Stats: 9 lines in 1 file changed: 2 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From sviswanathan at openjdk.java.net Tue May 18 23:59:30 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 18 May 2021 23:59:30 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v6] In-Reply-To: <6cWkz6rWmKC0L2U3sYiELeoOphNGlEHvCoSXcJHE-hE=.04e407ec-be8f-4d01-b527-ec7e1d30bb34@github.com> References: <6cWkz6rWmKC0L2U3sYiELeoOphNGlEHvCoSXcJHE-hE=.04e407ec-be8f-4d01-b527-ec7e1d30bb34@github.com> Message-ID: On Tue, 18 May 2021 23:43:13 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. >> >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> Looking forward to your review and feedback. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > Print intrinsic fix @vnlozlov I have implemented all the review comments. Please let me know if the changes look ok to you. ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From sviswanathan at openjdk.java.net Tue May 18 23:59:28 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 18 May 2021 23:59:28 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v7] In-Reply-To: References: Message-ID: <8FlPfGWCt4m3-JqK3IimdEyhG767zaov3nfteXioR0c=.8e49bf89-d74a-474b-9bd0-cce80f744af3@github.com> > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: jcheck fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/11528426..0d1d0382 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=05-06 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From kvn at openjdk.java.net Wed May 19 00:30:42 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 19 May 2021 00:30:42 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v7] In-Reply-To: <8FlPfGWCt4m3-JqK3IimdEyhG767zaov3nfteXioR0c=.8e49bf89-d74a-474b-9bd0-cce80f744af3@github.com> References: <8FlPfGWCt4m3-JqK3IimdEyhG767zaov3nfteXioR0c=.8e49bf89-d74a-474b-9bd0-cce80f744af3@github.com> Message-ID: <-BR26RrPjxCrCj3TmA4xRVCvZxEk8njxsQh7kqjmmts=.df6b4208-d5a1-4d28-802b-1fa28848abce@github.com> On Tue, 18 May 2021 23:59:28 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. >> >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> Looking forward to your review and feedback. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > jcheck fixes This is much much better! Thank you for changing it. I am only asking now to add comment explaining names. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6975: > 6973: if (libsvml != NULL) { > 6974: log_info(library)("Loaded library %s, handle " INTPTR_FORMAT, JNI_LIB_PREFIX "svml" JNI_LIB_SUFFIX, p2i(libsvml)); > 6975: if (UseAVX > 2) { Please add comment here explaining naming convention you are using here. What `f16_ha_z0` mean? Why `8_ha_z0` and not `d8_ha_z0`? What is `l9`, `e9`, `ex`? ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3638 From kvn at openjdk.java.net Wed May 19 00:34:39 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 19 May 2021 00:34:39 GMT Subject: RFR: 8267190: Optimize Vector API test operations In-Reply-To: References: Message-ID: <8ZVcXmmppPrp_92nHp3r_pCDsP2PcQGWW5wSChKyDHY=.3bbb6d31-b210-4417-a211-c4bc5b083f1e@github.com> On Fri, 14 May 2021 23:58:38 GMT, Sandhya Viswanathan wrote: > Vector API test operations (IS_DEFAULT, IS_FINITE, IS_INFINITE, IS_NAN and IS_NEGATIVE) are computed in three steps: > 1) reinterpreting the floating point vectors as integral vectors (int/long) > 2) perform the test in integer domain to get a int/long mask > 3) reinterpret the int/long mask as float/double mask > Step 3) currently is very slow. It can be optimized by modifying the Java code to utilize the existing reinterpret intrinsic. > > For the VectorTestPerf attached to the JBS for JDK-8267190, the performance improves as follows: > > Base: > Benchmark (size) Mode Cnt Score Error Units > VectorTestPerf.IS_DEFAULT 1024 thrpt 5 223.156 ? 90.452 ops/ms > VectorTestPerf.IS_FINITE 1024 thrpt 5 223.841 ? 91.685 ops/ms > VectorTestPerf.IS_INFINITE 1024 thrpt 5 224.561 ? 83.890 ops/ms > VectorTestPerf.IS_NAN 1024 thrpt 5 223.777 ? 70.629 ops/ms > VectorTestPerf.IS_NEGATIVE 1024 thrpt 5 218.392 ? 79.806 ops/ms > > With patch: > Benchmark (size) Mode Cnt Score Error Units > VectorTestPerf.IS_DEFAULT 1024 thrpt 5 8812.357 ? 40.477 ops/ms > VectorTestPerf.IS_FINITE 1024 thrpt 5 7425.739 ? 296.622 ops/ms > VectorTestPerf.IS_INFINITE 1024 thrpt 5 8932.730 ? 269.988 ops/ms > VectorTestPerf.IS_NAN 1024 thrpt 5 8574.872 ? 498.649 ops/ms > VectorTestPerf.IS_NEGATIVE 1024 thrpt 5 8838.400 ? 11.849 ops/ms > > Best Regards, > Sandhya Change in vectorIntrinsics.cpp seems fine. I did not look on Java code. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4039 From sviswanathan at openjdk.java.net Wed May 19 00:58:15 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 19 May 2021 00:58:15 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v8] In-Reply-To: References: Message-ID: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: Add comments explaining naming convention ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/0d1d0382..45f20a34 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=06-07 Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From sviswanathan at openjdk.java.net Wed May 19 00:58:18 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 19 May 2021 00:58:18 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v7] In-Reply-To: <-BR26RrPjxCrCj3TmA4xRVCvZxEk8njxsQh7kqjmmts=.df6b4208-d5a1-4d28-802b-1fa28848abce@github.com> References: <8FlPfGWCt4m3-JqK3IimdEyhG767zaov3nfteXioR0c=.8e49bf89-d74a-474b-9bd0-cce80f744af3@github.com> <-BR26RrPjxCrCj3TmA4xRVCvZxEk8njxsQh7kqjmmts=.df6b4208-d5a1-4d28-802b-1fa28848abce@github.com> Message-ID: On Wed, 19 May 2021 00:26:48 GMT, Vladimir Kozlov wrote: >> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: >> >> jcheck fixes > > This is much much better! Thank you for changing it. I am only asking now to add comment explaining names. @vnkozlov I have added comments explaining naming convention. Please let me know if this looks ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From kvn at openjdk.java.net Wed May 19 01:07:42 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 19 May 2021 01:07:42 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v8] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 00:58:15 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. >> >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> Looking forward to your review and feedback. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > Add comments explaining naming convention Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3638 From sviswanathan at openjdk.java.net Wed May 19 01:31:40 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 19 May 2021 01:31:40 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v8] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 00:58:15 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. >> >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> Looking forward to your review and feedback. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > Add comments explaining naming convention Thanks a lot Vladimir! ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From vromero at openjdk.java.net Wed May 19 01:50:37 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 19 May 2021 01:50:37 GMT Subject: RFR: 8224158: assertion related to NPE at DynamicCallSiteDesc::withArgs should be reworded In-Reply-To: References: Message-ID: On Mon, 17 May 2021 16:53:24 GMT, Vicente Romero wrote: > This is a very small patch that is just rewording the spec for DynamicCallSiteDesc::withArgs. Basically adding that NPE can also be thrown if the content of the argument is `null` > > TIA for the review ping ------------- PR: https://git.openjdk.java.net/jdk/pull/4067 From sviswanathan at openjdk.java.net Wed May 19 03:37:11 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 19 May 2021 03:37:11 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v9] In-Reply-To: References: Message-ID: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: fix 32-bit build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/45f20a34..f7e39913 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From egahlin at openjdk.java.net Wed May 19 04:19:40 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Wed, 19 May 2021 04:19:40 GMT Subject: RFR: 8203359: Container level resources events [v11] In-Reply-To: References: Message-ID: <1lfvmG52YKC-DGE11E5TynzpIjC8WjlhlIK51wJF5bE=.7b07556c-b253-47d4-8300-1bb7e8bfa98f@github.com> On Mon, 3 May 2021 13:16:06 GMT, Jaroslav Bachorik wrote: >> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events. >> >> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with. >> * CPU related metrics >> * Memory related metrics >> * I/O related metrics >> >> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. >> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently). > > Jaroslav Bachorik has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Small fixes > - Remove trailing spaces > - Doh > - Report container type and register events conditionally > - Remove unused test files > - Initial test support for JFR container events > - Update the JFR control files > - Split off the CPU throttling metrics > - Formatting spaces > - 8203359: Container level resources events Looks good, but if there are test issues they should be fixed. ------------- Marked as reviewed by egahlin (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3126 From joehw at openjdk.java.net Wed May 19 06:12:39 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 19 May 2021 06:12:39 GMT Subject: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current [v2] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 23:39:37 GMT, Naoto Sato wrote: >> Please review the changes to the subject issue. java.util.Locale class has a long-standing issue for those obsolete ISO 639 languages where its normalization ends up in the obsolete codes. This change intends to flip the normalization towards the current codes, providing a system property for compatibility behavior. ResourceBundle class is also modified to load either obsolete/current bundles. For more detail, take a look at the CSR. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Locale's class description modification Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4069 From joehw at openjdk.java.net Wed May 19 06:12:40 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 19 May 2021 06:12:40 GMT Subject: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current [v2] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 23:35:12 GMT, Naoto Sato wrote: >> test/jdk/java/util/Locale/LocaleTest.java line 683: >> >>> 681: * @bug 4052404 4778440 8263202 >>> 682: */ >>> 683: public void TestChangedISO639Codes() { >> >> Could probably be simplified with a DataProvider. > > That would be nice, but the test is not testng based, and it would be an entire test rewrite which I would not do it at this time. I see. Good old test is still good. ------------- PR: https://git.openjdk.java.net/jdk/pull/4069 From egahlin at openjdk.java.net Wed May 19 06:23:39 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Wed, 19 May 2021 06:23:39 GMT Subject: RFR: 8266936: Add a finalization JFR event [v2] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 22:41:06 GMT, Brent Christian wrote: >> Please review this enhancement to add a new JFR event, generated whenever a finalizer is run. >> (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).) >> >> The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized. >> >> The Category for the event: >> `"Java Virtual Machine" / "GC" / "Finalization"` >> is what made sense to me, even though the event is generated from library code. >> >> Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr. >> Automated testing looks good so far. >> >> Thanks, >> -Brent > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > Test flag should be volatile This looks useful, but I am worried about the performance impact: - The added allocation for every object that is finalized. - The event being enabled in the default configuration. The default configuration must be safe to use even in pathological cases, i.e. an application with lots of objects being finalized. It's probably too much overhead (or number of events) for the profile configuration as well. There is also the added startup cost of JFR. One event may not matter that much, but they all add up. We need to put in place a mechanism that doesn't rely on bytecode instrumentation at runtime. There is an enhancement for that, but it requires some engineering first. ------------- PR: https://git.openjdk.java.net/jdk/pull/4101 From alanb at openjdk.java.net Wed May 19 06:24:44 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 19 May 2021 06:24:44 GMT Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v4] In-Reply-To: References: Message-ID: 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 Reinhold has updated the pull request incrementally with one additional commit since the last revision: > > Fix up IllegalAccessTest Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4015 From alanb at openjdk.java.net Wed May 19 06:55:39 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 19 May 2021 06:55:39 GMT Subject: RFR: 8266936: Add a finalization JFR event [v2] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 06:20:59 GMT, Erik Gahlin wrote: > This looks useful, but I am worried about the performance impact: > > * The added allocation for every object that is finalized. > * The event being enabled in the default configuration. > > The default configuration must be safe to use even in pathological cases, i.e. an application with lots of objects being finalized. It's probably too much overhead (or number of events) for the profile configuration as well. > > There is also the added startup cost of JFR. One event may not matter that much, but they all add up. We need to put in place a mechanism that doesn't rely on bytecode instrumentation at runtime. There is an enhancement for that, but it requires some engineering first. I'm a bit worried by this too. Does it need to be enabled by default? Can we put a static final instance of FinalizerEvent in that class that can be used to test if the event is enabled so that it doesn't create a FinalizerEvent when disabled? Is it worth exploring doing have an event in the VM, in register_finalizer, instead? ------------- PR: https://git.openjdk.java.net/jdk/pull/4101 From egahlin at openjdk.java.net Wed May 19 07:54:09 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Wed, 19 May 2021 07:54:09 GMT Subject: RFR: 8266936: Add a finalization JFR event [v2] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 22:41:06 GMT, Brent Christian wrote: >> Please review this enhancement to add a new JFR event, generated whenever a finalizer is run. >> (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).) >> >> The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized. >> >> The Category for the event: >> `"Java Virtual Machine" / "GC" / "Finalization"` >> is what made sense to me, even though the event is generated from library code. >> >> Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr. >> Automated testing looks good so far. >> >> Thanks, >> -Brent > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > Test flag should be volatile I wonder if there needs to be one event per finalized object? Perhaps a counter per class would be as useful, i.e. jdk.FinalizationStatistics, and if it could be implemented in the VM, without other implications, that would be great. Such an event could be enabled by default and provide much greater value than an event that users would need to know about and configure themselves, which 99,99% of all user will not do. ------------- PR: https://git.openjdk.java.net/jdk/pull/4101 From jlahoda at openjdk.java.net Wed May 19 08:00:12 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 19 May 2021 08:00:12 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: > 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/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Fixing various error-related bugs. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/5fa8005a..0875377b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=02-03 Stats: 117 lines in 6 files changed: 94 ins; 13 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From vlivanov at openjdk.java.net Wed May 19 08:10:43 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 19 May 2021 08:10:43 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v9] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 03:37:11 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. >> >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> Looking forward to your review and feedback. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > fix 32-bit build Overall, looks fine. src/hotspot/cpu/x86/x86_64.ad line 1704: > 1702: } > 1703: > 1704: void Matcher::vector_calling_convention(VMRegPair *regs, uint num_bits, uint total_args_passed) { You can just remove `Matcher::vector_calling_convention()` and call `SharedRuntime::vector_calling_convention()` directly. src/hotspot/share/opto/matcher.cpp line 1370: > 1368: VMReg first = parm_regs[i].first(); > 1369: VMReg second = parm_regs[i].second(); > 1370: if( !first->is_valid() && Please, fix formatting. src/hotspot/share/opto/vectorIntrinsics.cpp line 1355: > 1353: > 1354: // Get address for svml method. > 1355: get_svml_address(vector_api_op_id, vt->length_in_bytes() * BitsPerByte, bt, name, 100, &addr); Any particular reason to return the address as an out argument and not directly (`address addr = get_svml_address(...)`)? src/hotspot/share/utilities/globalDefinitions_vecApi.hpp line 34: > 32: // VS2017 required to build .s files for math intrinsics > 33: #if defined(_WIN64) && (defined(_MSC_VER) && (_MSC_VER >= 1910)) > 34: #define __VECTOR_API_MATH_INTRINSICS_COMMON Considering the stubs are not part of JVM anymore, the macros can go away. The stubs are dynamically linked now and if there's no library built/present the linking will fail. And then `globalDefinitions_vecApi.hpp` becomes empty and can be removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From jbhateja at openjdk.java.net Wed May 19 08:33:55 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 19 May 2021 08:33:55 GMT Subject: RFR: 8267357: build breaks with -Werror option on micro benchmark added for JDK-8256973 Message-ID: Relevant declarations modified and tested with -Werror, no longer see unchecked conversion warnings. Kindly review and approve. ------------- Commit messages: - 8267357: build breaks with -Werror option on micro benchmark added for JDK-8256973 Changes: https://git.openjdk.java.net/jdk/pull/4108/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4108&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267357 Stats: 10 lines in 1 file changed: 0 ins; 1 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4108.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4108/head:pull/4108 PR: https://git.openjdk.java.net/jdk/pull/4108 From plevart at openjdk.java.net Wed May 19 08:44:50 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 19 May 2021 08:44:50 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v3] In-Reply-To: References: <-4wVyKFO8p5jFap50H7tmoQ5VRzSnwZ1A4dCsqy9rOk=.7b351a5f-f127-4941-9467-ac864de71509@github.com> <5PDgT2ctbgsXq8ZHBYQa_4M_AFNKadmKqwUBFWAhCgs=.88433340-cece-4c4a-a1a5-87fbaf27f80d@github.com> Message-ID: <5Mlj059l4xCeEPL8MFWrsojw0PwbhOd8W5yR2PWV9qo=.21784c99-3074-4392-a5b6-48b160b6f310@github.com> On Tue, 18 May 2021 23:14:53 GMT, Stephen Colebourne wrote: >> src/java.base/share/classes/java/time/Clock.java line 487: >> >>> 485: // it more unlikely to hit the 1ns in the future condition. >>> 486: localOffset = System.currentTimeMillis()/1000 - 1024; >>> 487: >> >> Is it possible that after a fresh localOffset is retrieved, the thread is preempted and when it is scheduled again after a pause, the getNanoTimeAdjustment below returns -1 ? Would it help if instead of throwing exception, there was an infinite retry loop? > > This isn't my logic - it is existing code that has been moved. I'm not a fan of infinite retry loops as the can hang the system. But I'm happy to change it to work that way if there is a consensus to do so. I see the localOffset passed to VM.getNanoTimeAdjustment() has to be in the range of current time +/- 2^32 seconds. This means the thread would have to sleep for ~136 years before the exception is triggered. I think this is more than enough. :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From jiefu at openjdk.java.net Wed May 19 08:46:40 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 19 May 2021 08:46:40 GMT Subject: RFR: 8267357: build breaks with -Werror option on micro benchmark added for JDK-8256973 In-Reply-To: References: Message-ID: <_jD3PtGlJL7eljQuJk5V_Q-sZk3GMjXJiFIF30_T0N0=.d048b12f-b22c-4c04-9900-95fe7679fcc5@github.com> On Wed, 19 May 2021 08:20:13 GMT, Jatin Bhateja wrote: > Relevant declarations modified and tested with -Werror, no longer see unchecked conversion warnings. > > Kindly review and approve. LGTM ------------- Marked as reviewed by jiefu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4108 From aph at redhat.com Wed May 19 09:01:03 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 May 2021 10:01:03 +0100 Subject: JEP draft: Scope Locals In-Reply-To: References: Message-ID: On 5/15/21 6:50 PM, Peter Levart wrote: > What if I wanted to create and start a thread that would be "pristine" - > not have any ScopeLocal value bound? Is this intentionally not allowed > in order to make sure that inheritable ScopeLocal(s) can't be cleared by > code that has no access to ScopeLocal instance(s)? That one is about to be changed by a revision to the JEP. There clearly is a need to control whether a newly-created thread inherits scope locals or not. For instance, an Executor might lazily create worker threads, and we don't want them to inherit scope locals from the thread that was running. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From neliasso at openjdk.java.net Wed May 19 09:02:41 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Wed, 19 May 2021 09:02:41 GMT Subject: RFR: 8267357: build breaks with -Werror option on micro benchmark added for JDK-8256973 In-Reply-To: References: Message-ID: On Wed, 19 May 2021 08:20:13 GMT, Jatin Bhateja wrote: > Relevant declarations modified and tested with -Werror, no longer see unchecked conversion warnings. > > Kindly review and approve. Looks good. ------------- Marked as reviewed by neliasso (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4108 From alanb at openjdk.java.net Wed May 19 09:03:43 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 19 May 2021 09:03:43 GMT Subject: RFR: 8266936: Add a finalization JFR event [v2] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 07:50:55 GMT, Erik Gahlin wrote: > I wonder if there needs to be one event per finalized object? > > Perhaps a counter per class would be as useful, i.e. jdk.FinalizationStatistics, and if it could be implemented in the VM, without other implications, that would be great. > > Such an event could be enabled by default and provide much greater value than an event that users would need to know about and configure themselves, which 99,99% of all user will not do. So some statistics or periodic event that N instances of class C were registered or queued? I think you are right that this would be a lot more valuable. ------------- PR: https://git.openjdk.java.net/jdk/pull/4101 From aph at redhat.com Wed May 19 09:15:18 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 May 2021 10:15:18 +0100 Subject: [External] : Re: JEP draft: Scope Locals In-Reply-To: References: <7220447e-b2c5-7199-655c-aee364c78b35@oracle.com> <131cc69b-1a5d-1837-298c-5f4f19a1474f@oracle.com> <24e9d8c3-b219-f94c-721d-55a38590f902@oracle.com> <1c980620-febc-e299-8268-bdd5f088e5c2@oracle.com> Message-ID: <3effeaf8-e36d-555a-d6f6-0fe9463a651e@redhat.com> On 5/18/21 3:19 AM, Mike Rettig wrote: > With the current proposal I can't simply flush and close at the > end of the scope because there might be a child scope that is still active. Yes, that's true. I think that what you have in mind is a more elaborate mechanism than what is proposed here, which does no more than bind values to names over a scope. There needs to be more discussion in the JEP of what this proposal isn't intended to do, and how we might cope with mutability of a scope local's values. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From chegar at openjdk.java.net Wed May 19 09:14:39 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 19 May 2021 09:14:39 GMT Subject: RFR: 8266936: Add a finalization JFR event [v2] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 22:41:06 GMT, Brent Christian wrote: >> Please review this enhancement to add a new JFR event, generated whenever a finalizer is run. >> (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).) >> >> The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized. >> >> The Category for the event: >> `"Java Virtual Machine" / "GC" / "Finalization"` >> is what made sense to me, even though the event is generated from library code. >> >> Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr. >> Automated testing looks good so far. >> >> Thanks, >> -Brent > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > Test flag should be volatile My 0.02$ ;-) I really like the idea of a jdk.FinalizationStatistics event. The devil is (as always) in the details. Multiple concerns have been raised above, which benefit from being separated out: 1) Raising an event per invocation of each individual finalizer may be costly when JFR is enabled (since there could be an extremely large number of these), as well as a little unwieldy for a human observer. Aggregating invocations of finalizers and reporting periodically seems like a nice solution to this. 2) A jdk.FinalizationStatistics event that provides an aggregate count of *all* finalizer invocations seems most straightforward, but less useful. A jdk.FinalizationStatistics event that provides per-class invocation metrics seems more useful, but at the expense of a more complex event structure. Maybe model jdk.FinalizationStatistics as a tuple of Class and long (count) - periodically committing multiple jdk.FinalizationStatistics events, one event per class? ( or was the thought to somehow aggregate all these per-class metrics into a single jdk.FinalizationStatistics event? ) 3) If we keep the currently proposed semantic - capturing actual invocation/queueing counts (rather than registrations), then I see no reason why the implementation of a jdk.FinalizationStatistics needs to be in the JVM. The metrics can be captured in Java code and reported in a similar way to the container metrics (being proposed in [PR 3126][PR3126]). Surely, this would be more straightforward to implement and maintain, no? 4) The startup cost of JFR. I dunno enough about this, but what I do know is that a handler needs to be spun per Java-event, so maybe this has some bearing on the decision of no.3 above? [PR3126]: https://github.com/openjdk/jdk/pull/3126 ------------- PR: https://git.openjdk.java.net/jdk/pull/4101 From albest512 at hotmail.com Wed May 19 09:36:57 2021 From: albest512 at hotmail.com (=?iso-8859-1?Q?Alberto_Otero_Rodr=EDguez?=) Date: Wed, 19 May 2021 09:36:57 +0000 Subject: New java.util.Strings class In-Reply-To: References: Message-ID: Hi, I have made some changes to the Strings class I proposed in my previous message. The changes are: * Use str.isEmpty() instead of EMPTY_STRING.equals(str) * Create methods using str.strip() to check a String is not Whitespace You can see the new code here: https://github.com/Aliuken/Java-Strings/blob/main/Strings.java With those changes, the following annotations could also be created for method arguments and return types: - @NonNullNorWhiteSpace - @NonNullNorWhiteSpaceElse(defaultValue) - @NonNullNorWhiteSpaceElseGet(class::supplierMethod) I didn't have any response to the previous message. Please, take this one in consideration. Regards, Alberto Otero Rodr?guez. ________________________________ De: Alberto Otero Rodr?guez Enviado: lunes, 17 de mayo de 2021 14:58 Para: core-libs-dev at openjdk.java.net Asunto: New java.util.Strings class Hi, members of the core-libs developers of OpenJDK. I think Java needs a Strings class similar to the java.util.Objects class of Java 16 to be used in method arguments, return types and Stream filters. I have coded it myself here based on the Objects implementation of Java 16 (please have a look): https://github.com/Aliuken/Java-Strings/blob/main/Strings.java In fact, I think it would be useful also adding annotations for method arguments and return types such as: - @NonNull - @NonNullElse(defaultValue) - @NonNullElseGet(class::supplierMethod) - @NonNullNorEmpty - @NonNullNorEmptyElse(defaultValue) - @NonNullNorEmptyElseGet(class::supplierMethod) With that kind of annotations, you could assume thinks like: - an argument or return type cannot have value null, but an Exception - an argument or return type cannot have value null, but a default value What do you think? Waiting for your response. PS: I am sending this email repeated. I have sended it yesterday with my other email account (alber84ou at gmail.com), but I wasn't a member of this mailing list. Now I have become a member with this other email account. Regards, Alberto Otero Rodr?guez. From Alan.Bateman at oracle.com Wed May 19 09:44:56 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 19 May 2021 10:44:56 +0100 Subject: [External] : Re: JEP draft: Scope Locals In-Reply-To: <3effeaf8-e36d-555a-d6f6-0fe9463a651e@redhat.com> References: <7220447e-b2c5-7199-655c-aee364c78b35@oracle.com> <131cc69b-1a5d-1837-298c-5f4f19a1474f@oracle.com> <24e9d8c3-b219-f94c-721d-55a38590f902@oracle.com> <1c980620-febc-e299-8268-bdd5f088e5c2@oracle.com> <3effeaf8-e36d-555a-d6f6-0fe9463a651e@redhat.com> Message-ID: On 19/05/2021 10:15, Andrew Haley wrote: > : > Yes, that's true. I think that what you have in mind is a more elaborate > mechanism than what is proposed here, which does no more than bind values > to names over a scope. There needs to be more discussion in the JEP of > what this proposal isn't intended to do, and how we might cope with > mutability of a scope local's values. > Also just to add that the closable-resource in the example is being used on concurrent threads so it already has to cope with attempted usage after close or async close (close while in use). Also once we combine this with SC then we can be sure that the child task has completed before closing the resource. -Alan From thartmann at openjdk.java.net Wed May 19 09:58:49 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 19 May 2021 09:58:49 GMT Subject: RFR: 8267357: build breaks with -Werror option on micro benchmark added for JDK-8256973 In-Reply-To: References: Message-ID: On Wed, 19 May 2021 08:20:13 GMT, Jatin Bhateja wrote: > Relevant declarations modified and tested with -Werror, no longer see unchecked conversion warnings. > > Kindly review and approve. Marked as reviewed by thartmann (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4108 From jbhateja at openjdk.java.net Wed May 19 10:01:45 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 19 May 2021 10:01:45 GMT Subject: Integrated: 8267357: build breaks with -Werror option on micro benchmark added for JDK-8256973 In-Reply-To: References: Message-ID: On Wed, 19 May 2021 08:20:13 GMT, Jatin Bhateja wrote: > Relevant declarations modified and tested with -Werror, no longer see unchecked conversion warnings. > > Kindly review and approve. This pull request has now been integrated. Changeset: 88b11423 Author: Jatin Bhateja URL: https://git.openjdk.java.net/jdk/commit/88b114235c5716ea43c55a9c4bc886bf5bcf4b42 Stats: 10 lines in 1 file changed: 0 ins; 1 del; 9 mod 8267357: build breaks with -Werror option on micro benchmark added for JDK-8256973 Reviewed-by: jiefu, neliasso, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/4108 From sgehwolf at openjdk.java.net Wed May 19 10:03:43 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 19 May 2021 10:03:43 GMT Subject: RFR: 8203359: Container level resources events [v11] In-Reply-To: References: Message-ID: On Mon, 3 May 2021 13:16:06 GMT, Jaroslav Bachorik wrote: >> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events. >> >> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with. >> * CPU related metrics >> * Memory related metrics >> * I/O related metrics >> >> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. >> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently). > > Jaroslav Bachorik has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Small fixes > - Remove trailing spaces > - Doh > - Report container type and register events conditionally > - Remove unused test files > - Initial test support for JFR container events > - Update the JFR control files > - Split off the CPU throttling metrics > - Formatting spaces > - 8203359: Container level resources events Changes requested by sgehwolf (Reviewer). src/jdk.jfr/share/classes/jdk/jfr/events/ContainerMemoryUsageEvent.java line 48: > 46: @Description("(attempts per second * 1000), if enabled, that the operating system tries to satisfy a memory request for any " + > 47: "process in the current container when no free memory is readily available.") > 48: public double memoryPressure; Should this `memoryPressure` field go from `ContainerMemoryUsageEvent` class? It's not set anywhere is it? would be cgroup v1 only api so I'm not sure it should be there for a generic event like this. ------------- PR: https://git.openjdk.java.net/jdk/pull/3126 From jbachorik at openjdk.java.net Wed May 19 10:27:42 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Wed, 19 May 2021 10:27:42 GMT Subject: RFR: 8203359: Container level resources events [v11] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 10:00:04 GMT, Severin Gehwolf wrote: >> Jaroslav Bachorik has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: >> >> - Small fixes >> - Remove trailing spaces >> - Doh >> - Report container type and register events conditionally >> - Remove unused test files >> - Initial test support for JFR container events >> - Update the JFR control files >> - Split off the CPU throttling metrics >> - Formatting spaces >> - 8203359: Container level resources events > > src/jdk.jfr/share/classes/jdk/jfr/events/ContainerMemoryUsageEvent.java line 48: > >> 46: @Description("(attempts per second * 1000), if enabled, that the operating system tries to satisfy a memory request for any " + >> 47: "process in the current container when no free memory is readily available.") >> 48: public double memoryPressure; > > Should this `memoryPressure` field go from `ContainerMemoryUsageEvent` class? It's not set anywhere is it? would be cgroup v1 only api so I'm not sure it should be there for a generic event like this. Yes. Removing. ------------- PR: https://git.openjdk.java.net/jdk/pull/3126 From mcimadamore at openjdk.java.net Wed May 19 12:15:28 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 19 May 2021 12:15:28 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v23] In-Reply-To: References: Message-ID: > 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://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix VaList test Remove unused code in Utils ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/f6051daf..f5668ffc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=22 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=21-22 Stats: 6 lines in 2 files changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From hseigel at openjdk.java.net Wed May 19 12:45:41 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 19 May 2021 12:45:41 GMT Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v4] In-Reply-To: References: Message-ID: 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 Reinhold has updated the pull request incrementally with one additional commit since the last revision: > > Fix up IllegalAccessTest Hotspot changes look good. Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4015 From weijun at openjdk.java.net Wed May 19 13:47:54 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 May 2021 13:47:54 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v2] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: <8mVaKSBeyfyVBHsp67PuOC1G7--flmHQzygrQTyrgGE=.ed4f6dd9-e0af-4058-97f5-cf5ab3651aa4@github.com> On Tue, 18 May 2021 21:21:45 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > feedback from Sean, Phil and Alan A new commit fixing `awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java` test in tier4. The test compares stderr output with a known value but we have a new warning written to stderr now. It's now using stdout instead. @prrace, Please confirm this is acceptable. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Wed May 19 13:47:53 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 May 2021 13:47:53 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: > 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4073/files - new: https://git.openjdk.java.net/jdk/pull/4073/files/bb73093a..c4221b5f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From mik3hall at gmail.com Wed May 19 14:00:08 2021 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 19 May 2021 09:00:08 -0500 Subject: jpackage java commands Message-ID: <3230F945-8EF0-4DCC-AC72-5878965505D7@gmail.com> I added --jlink-options '--strip-debug --no-man-pages --no-header-files? to my invocation, avoiding --strip-native-commands, so that the native java commands are not stripped. I believe currently recommended jpackage way to do this. I get the following commands in my embedded JDK java jdb jshell rmid serialver javac jrunscript keytool rmiregistry The installed jdk bin directory has 29 different commands including ones like jpackage, jlink, javap, jcmd? What if I want to run one of those from the application? I can exec them but the version might not match the embedded? Not a current problem that I know of, I will use the installed for now. From pconcannon at openjdk.java.net Wed May 19 14:08:15 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 19 May 2021 14:08:15 GMT Subject: RFR: 8267110: Update java.util to use instanceof pattern variable [v2] In-Reply-To: References: Message-ID: <8AXQCx52GlKankpXKO_Ouh0ASaCl9fkiRj8ZCz3TOJo=.85f154c1-0214-4db7-8834-ced49cf4c868@github.com> > Hi, > > Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick Patrick Concannon 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 three additional commits since the last revision: - 8267110: Reverted changes in java/util/Formatter as primitive to boxed types may have semantic/performance implications - Merge remote-tracking branch 'origin/master' into JDK-8267110 - 8267110: Update java.util to use instanceof pattern variable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4088/files - new: https://git.openjdk.java.net/jdk/pull/4088/files/0ed0bd99..cd99dc49 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=00-01 Stats: 4003 lines in 175 files changed: 2590 ins; 890 del; 523 mod Patch: https://git.openjdk.java.net/jdk/pull/4088.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4088/head:pull/4088 PR: https://git.openjdk.java.net/jdk/pull/4088 From jbachorik at openjdk.java.net Wed May 19 14:11:40 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Wed, 19 May 2021 14:11:40 GMT Subject: RFR: 8203359: Container level resources events [v12] In-Reply-To: References: Message-ID: <4brXaeEbxSKZu-OyzpHr48NKsm9aMnUMcBSD9AB9934=.a28b5183-6aee-490a-9df5-a66f0a0e19e7@github.com> > With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events. > > Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with. > * CPU related metrics > * Memory related metrics > * I/O related metrics > > For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. > By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently). Jaroslav Bachorik 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 11 additional commits since the last revision: - Fix event metadata - Small fixes - Remove trailing spaces - Doh - Report container type and register events conditionally - Remove unused test files - Initial test support for JFR container events - Update the JFR control files - Split off the CPU throttling metrics - Formatting spaces - ... and 1 more: https://git.openjdk.java.net/jdk/compare/2f8f5ce3...c3fa274c ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3126/files - new: https://git.openjdk.java.net/jdk/pull/3126/files/fddd1727..c3fa274c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3126&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3126&range=10-11 Stats: 638229 lines in 6576 files changed: 92464 ins; 530978 del; 14787 mod Patch: https://git.openjdk.java.net/jdk/pull/3126.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3126/head:pull/3126 PR: https://git.openjdk.java.net/jdk/pull/3126 From jvernee at openjdk.java.net Wed May 19 14:24:19 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 19 May 2021 14:24:19 GMT Subject: RFR: 8266835: Add a --validate option to the jar tool Message-ID: This patch adds a `--validate` option to the jar tool which can be used to validate a jar file that might be malformed. For instance, if a jar is a multi-release jar, it is malformed if different versions expose different APIs. The implementation is straight forward since there already exists validation logic that is run when creating or updating a jar. This patch just exposes that logic directly under a new command line flag. I've enhanced the existing ApiValidatorTest to also create malformed jars using the zip file APIs (the jar tool does not output malformed jars) and run them through `jar --validate`. Note that while the jdk's jar tool does not output malformed jars, third-party archiving tools might, or the jar could have been manually edited. Some prior discussion here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077420.html Testing: running jdk/tools/jar test suite locally, tier 1-3 (in progress), manual testing. ------------- Commit messages: - - Remove spurious test imports - Add tests - Change validate option wording to not mention multi-release jars - Add jar --validate Changes: https://git.openjdk.java.net/jdk/pull/3971/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3971&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266835 Stats: 146 lines in 4 files changed: 114 ins; 4 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/3971.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3971/head:pull/3971 PR: https://git.openjdk.java.net/jdk/pull/3971 From jvernee at openjdk.java.net Wed May 19 14:30:44 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 19 May 2021 14:30:44 GMT Subject: RFR: 8266835: Add a --validate option to the jar tool In-Reply-To: References: Message-ID: On Tue, 11 May 2021 10:51:18 GMT, Jorn Vernee wrote: > This patch adds a `--validate` option to the jar tool which can be used to validate a jar file that might be malformed. For instance, if a jar is a multi-release jar, it is malformed if different versions expose different APIs. > > The implementation is straight forward since there already exists validation logic that is run when creating or updating a jar. This patch just exposes that logic directly under a new command line flag. > > I've enhanced the existing ApiValidatorTest to also create malformed jars using the zip file APIs (the jar tool does not output malformed jars) and run them through `jar --validate`. > > Note that while the jdk's jar tool does not output malformed jars, third-party archiving tools might, or the jar could have been manually edited. > > Some prior discussion here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077420.html > > Testing: running jdk/tools/jar test suite locally, tier 1-3 (in progress), manual testing. CSR here: https://bugs.openjdk.java.net/browse/JDK-8267402 ------------- PR: https://git.openjdk.java.net/jdk/pull/3971 From jvernee at openjdk.java.net Wed May 19 14:35:04 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 19 May 2021 14:35:04 GMT Subject: RFR: 8267321: Use switch expression for VarHandle$AccessMode lookup In-Reply-To: References: Message-ID: On Tue, 18 May 2021 20:59:49 GMT, Claes Redestad wrote: > Using a switch expression instead of a (read-only) static `HashMap` reduces initialization overhead of `VarHandle$AccessMode`. This gets loaded earlier after JDK-8265079, so it started showing up in a few lambda startup tests. > > This also obsoletes a jtreg test that only verified that this map was optimally sized. LGTM. I assume existing tests verify that all values of the enum are covered by the switch? ------------- Marked as reviewed by jvernee (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4102 From andy.herrick at oracle.com Wed May 19 14:40:41 2021 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 19 May 2021 10:40:41 -0400 Subject: jpackage java commands In-Reply-To: <3230F945-8EF0-4DCC-AC72-5878965505D7@gmail.com> References: <3230F945-8EF0-4DCC-AC72-5878965505D7@gmail.com> Message-ID: <8aebabd3-f309-67a9-97b9-58c3610e15f6@oracle.com> I don't think jlink will ever include the jdk development tools in a custom runtime (using jlink on windows or mac without --strip-native-commands only gives me java and keytool), but you can include the whole jdk (less src.zip and the jmods directory) by using --runtime-image and pointing to the JDK you are running jpackage from (or you can take copy of that JDK, modify it in any way you want, and point to that)). /Andy On 5/19/2021 10:00 AM, Michael Hall wrote: > I added > --jlink-options '--strip-debug --no-man-pages --no-header-files? > to my invocation, avoiding --strip-native-commands, so that the native java commands are not stripped. I believe currently recommended jpackage way to do this. > I get the following commands in my embedded JDK > > java jdb jshell rmid serialver > javac jrunscript keytool rmiregistry > > The installed jdk bin directory has 29 different commands including ones like jpackage, jlink, javap, jcmd? > > What if I want to run one of those from the application? I can exec them but the version might not match the embedded? > > Not a current problem that I know of, I will use the installed for now. > > > > > > From redestad at openjdk.java.net Wed May 19 14:52:37 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 19 May 2021 14:52:37 GMT Subject: RFR: 8267321: Use switch expression for VarHandle$AccessMode lookup In-Reply-To: References: Message-ID: On Wed, 19 May 2021 14:31:48 GMT, Jorn Vernee wrote: > LGTM. I assume existing tests verify that all values of the enum are covered by the switch? Thanks! Yes, the method with the switch is called when linking a VH, and the tests should be exhaustive in that regard. ------------- PR: https://git.openjdk.java.net/jdk/pull/4102 From redestad at openjdk.java.net Wed May 19 15:26:44 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 19 May 2021 15:26:44 GMT Subject: Integrated: 8267321: Use switch expression for VarHandle$AccessMode lookup In-Reply-To: References: Message-ID: On Tue, 18 May 2021 20:59:49 GMT, Claes Redestad wrote: > Using a switch expression instead of a (read-only) static `HashMap` reduces initialization overhead of `VarHandle$AccessMode`. This gets loaded earlier after JDK-8265079, so it started showing up in a few lambda startup tests. > > This also obsoletes a jtreg test that only verified that this map was optimally sized. This pull request has now been integrated. Changeset: 9760dba7 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/9760dba71c07cf7b0df16590b3e84e23ad587621 Stats: 90 lines in 2 files changed: 31 ins; 56 del; 3 mod 8267321: Use switch expression for VarHandle$AccessMode lookup Reviewed-by: jvernee ------------- PR: https://git.openjdk.java.net/jdk/pull/4102 From jbachorik at openjdk.java.net Wed May 19 15:30:35 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Wed, 19 May 2021 15:30:35 GMT Subject: RFR: 8203359: Container level resources events [v13] In-Reply-To: References: Message-ID: > With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events. > > Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with. > * CPU related metrics > * Memory related metrics > * I/O related metrics > > For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. > By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently). Jaroslav Bachorik has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Fix event metadata ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3126/files - new: https://git.openjdk.java.net/jdk/pull/3126/files/c3fa274c..e0f5855b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3126&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3126&range=11-12 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3126.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3126/head:pull/3126 PR: https://git.openjdk.java.net/jdk/pull/3126 From sgehwolf at openjdk.java.net Wed May 19 15:30:37 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 19 May 2021 15:30:37 GMT Subject: RFR: 8203359: Container level resources events [v13] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 15:23:55 GMT, Jaroslav Bachorik wrote: >> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events. >> >> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with. >> * CPU related metrics >> * Memory related metrics >> * I/O related metrics >> >> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. >> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently). > > Jaroslav Bachorik has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Fix event metadata LGTM ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3126 From jbachorik at openjdk.java.net Wed May 19 15:31:10 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Wed, 19 May 2021 15:31:10 GMT Subject: RFR: 8203359: Container level resources events [v12] In-Reply-To: <4brXaeEbxSKZu-OyzpHr48NKsm9aMnUMcBSD9AB9934=.a28b5183-6aee-490a-9df5-a66f0a0e19e7@github.com> References: <4brXaeEbxSKZu-OyzpHr48NKsm9aMnUMcBSD9AB9934=.a28b5183-6aee-490a-9df5-a66f0a0e19e7@github.com> Message-ID: On Wed, 19 May 2021 14:11:40 GMT, Jaroslav Bachorik wrote: >> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events. >> >> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with. >> * CPU related metrics >> * Memory related metrics >> * I/O related metrics >> >> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. >> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently). > > Jaroslav Bachorik 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 11 additional commits since the last revision: > > - Fix event metadata > - Small fixes > - Remove trailing spaces > - Doh > - Report container type and register events conditionally > - Remove unused test files > - Initial test support for JFR container events > - Update the JFR control files > - Split off the CPU throttling metrics > - Formatting spaces > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/a32c4b70...c3fa274c Thanks for the review! I've fixed the outstanding test failures and the patch is in its final form. ------------- PR: https://git.openjdk.java.net/jdk/pull/3126 From jvernee at openjdk.java.net Wed May 19 15:36:57 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 19 May 2021 15:36:57 GMT Subject: RFR: 8266835: Add a --validate option to the jar tool [v2] In-Reply-To: References: Message-ID: > This patch adds a `--validate` option to the jar tool which can be used to validate a jar file that might be malformed. For instance, if a jar is a multi-release jar, it is malformed if different versions expose different APIs. > > The implementation is straight forward since there already exists validation logic that is run when creating or updating a jar. This patch just exposes that logic directly under a new command line flag. > > I've enhanced the existing ApiValidatorTest to also create malformed jars using the zip file APIs (the jar tool does not output malformed jars) and run them through `jar --validate`. > > Note that while the jdk's jar tool does not output malformed jars, third-party archiving tools might, or the jar could have been manually edited. > > Some prior discussion here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077420.html > > Testing: running jdk/tools/jar test suite locally, tier 1-3 (in progress), manual testing. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Update error message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3971/files - new: https://git.openjdk.java.net/jdk/pull/3971/files/3f68ad6c..cbd6e81b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3971&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3971&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3971.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3971/head:pull/3971 PR: https://git.openjdk.java.net/jdk/pull/3971 From duke at openjdk.java.net Wed May 19 15:49:40 2021 From: duke at openjdk.java.net (duke) Date: Wed, 19 May 2021 15:49:40 GMT Subject: Withdrawn: 8260710: Inline and simplify String*::{coder, value, isLatin1} methods In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 13:11:52 GMT, Aleksey Shipilev wrote: > Since Compact Strings implementation, there are simple methods in String and StringBuilders: `coder()`, `value()`, `isLatin1()`. They are mostly there to capture `COMPACT_STRINGS` flag that would fold to "false" when compact strings are disabled with `-XX:-CompactStrings`. > > This was to guarantee the same performance when Compact String are unimplemented and/or have surprising performance behaviors. Quite some time had passed since JDK 9 release, and we can consider simplifying these. For example, ignoring `COMPACT_STRINGS` and inlining the methods simplifies the code. Some new code added to `String` after JDK 9 already has these methods inlined, checking `coder` directly. > > The major drawback is that supplying `-XX:-CompactStrings` would have to go through the same `coder == UTF16` paths the "normal" Compact Strings are going. It would not be folded to the most optimal form by the optimizer, because `coder` field value is generally opaque to optimizers. > > On the flip side, there is an advantage on paths that do not have optimizer ready (yet), for example at startup. Hello World startup improves for about 0.3 msec (or ~1.3%). The improvement is quite probably more visible on larger workloads, i.e. large application servers. (In fact, this is where I spotted this opportunity: OpenLiberty startup profiles). > > Interpreter-only "Hello World": > > > Performance counter stats for 'taskset -c 13 build/baseline/bin/java -Xms128m -Xmx128m -Xint Hello' (5000 runs): > > 23.40 msec task-clock # 0.933 CPUs utilized ( +- 0.01% ) > 86,133,190 cycles # 3.680 GHz ( +- 0.01% ) > 79,854,588 instructions # 0.93 insn per cycle ( +- 0.00% ) > > 0.02507105 +- 0.00000343 seconds time elapsed ( +- 0.01% ) > > Performance counter stats for 'taskset -c 13 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m -Xint Hello' (5000 runs): > > 23.07 msec task-clock # 0.935 CPUs utilized ( +- 0.01% ) > 84,877,118 cycles # 3.679 GHz ( +- 0.01% ) > 79,231,598 instructions # 0.93 insn per cycle ( +- 0.00% ) > > 0.02466467 +- 0.00000382 seconds time elapsed ( +- 0.02% ) > > > > OpenLiberty startup: > > > Before: 2.296, 2.281, 2.291 (seconds) > After: 2.254, 2.267, 2.272 (seconds) > > > Additional tests: > - [x] Linux `tier1` default (passes) > - [x] Linux `tier1` `-XX:-CompactStrings` This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2334 From mik3hall at gmail.com Wed May 19 16:11:24 2021 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 19 May 2021 11:11:24 -0500 Subject: jpackage java commands In-Reply-To: <8aebabd3-f309-67a9-97b9-58c3610e15f6@oracle.com> References: <3230F945-8EF0-4DCC-AC72-5878965505D7@gmail.com> <8aebabd3-f309-67a9-97b9-58c3610e15f6@oracle.com> Message-ID: <4DA00408-2872-421E-A4BF-4E6E7BC805DC@gmail.com> > On May 19, 2021, at 9:40 AM, Andy Herrick wrote: > > I don't think jlink will ever include the jdk development tools in a custom runtime (using jlink on windows or mac without --strip-native-commands only gives me java and keytool), Mac gave me the 9 commands shown earlier. Something inconsistent involved? > but you can include the whole jdk (less src.zip and the jmods directory) by using --runtime-image and pointing to the JDK you are running jpackage from (or you can take copy of that JDK, modify it in any way you want, and point to that)). I was trying a couple of these options for something unrelated last night. Just a quick look not extensive. But it seemed like if you copy ?runtime-image you are limited in making some modular changes to that runtime. I also tried directly using jlink to make the runtime myself but that also errored. I didn?t make any effort to figure out the problem at that time. A linkage error of some sort in class initialization for my launcher class. Manually changing a copied runtime I didn?t try. You could then just copy the commands you need to the jpackage runtime if the application is unsigned? I used to do something similar for app?s that needed an embedded ?java? command available. But got scolded for doing so when I mentioned it on this list. If the functionality is critical to the app I will probably have to make one of those options work. Currently it isn?t critical. So I guess I could just add an availability check. Thanks. From avoitylov at openjdk.java.net Wed May 19 16:21:41 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Wed, 19 May 2021 16:21:41 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v2] In-Reply-To: References: Message-ID: <7uREVWzjGhgjYBdEpYZ5OBurn9FzSuu-TG9_xIu-syc=.c737c435-734e-4e79-9969-cf0d2147ac07@github.com> > 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 library load operation. > > Problem being fixed: > > The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. > > Proposed fix: > > The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. > > The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. > > Testing: jtreg and jck testing with no regressions. A new regression test was developed. Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: address review comments, add tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3976/files - new: https://git.openjdk.java.net/jdk/pull/3976/files/113ee0f3..a0b2163a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3976&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3976&range=00-01 Stats: 560 lines in 9 files changed: 441 ins; 41 del; 78 mod Patch: https://git.openjdk.java.net/jdk/pull/3976.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3976/head:pull/3976 PR: https://git.openjdk.java.net/jdk/pull/3976 From duke at openjdk.java.net Wed May 19 16:26:50 2021 From: duke at openjdk.java.net (duke) Date: Wed, 19 May 2021 16:26:50 GMT Subject: Withdrawn: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> Message-ID: On Thu, 17 Dec 2020 13:36:17 GMT, PROgrm_JARvis wrote: > Please review this change moving lookup of MD5 digest in `java.lang.UUID` to an internal holder class. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From aleksei.voitylov at bell-sw.com Wed May 19 16:30:19 2021 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Wed, 19 May 2021 19:30:19 +0300 Subject: RFR: 8266310: deadlock while loading the JNI code In-Reply-To: <216c69d9-5c7e-d772-38ee-b9073f8fda98@oracle.com> References: <9cca1e8d-d9d9-4bb8-080e-195239023e79@oracle.com> <86478a7d-fcf6-df89-0f04-65480bb62fe7@bell-sw.com> <165946a3-3f16-3250-aa20-814aee31915d@oracle.com> <96b76d3f-a1fc-bb2e-195b-7e092b53c59b@oracle.com> <216c69d9-5c7e-d772-38ee-b9073f8fda98@oracle.com> Message-ID: <92262b66-327f-d925-e766-aeab2c2dfba3@bell-sw.com> Hi David, Mandy, In the updated PR I removed the lock held during the load/unload calls. Our testing confirmed that without that removal the deadlock can easily be reproduced, even without signed jars. Now the lock is only held to prevent races during access to "libraries" and "loadedLibraryNames". Thank you, -Aleksei On 14/05/2021 03:28, David Holmes wrote: > On 14/05/2021 7:20 am, Mandy Chung wrote: >> >> >> 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 completely changes the >>> semantics of native library loading. >> >> I have been giving some thought on this issue.? I agree with David >> that we should look into a solution not holding a lock while >> JNI_OnLoad is executed.? It might be possible to put all threads that >> trying to load the same native library that is being loaded to wait >> and only one thread is loading it and executing JNI_OnLoad (e.g. add >> a state in NativeLibrary to indicate it is being loaded, already >> loaded, being unloaded).? I haven't had the cycle to think through it >> in details though. > > Any mechanism that blocks threads from accessing the library while > another thread is performing JNI_OnLoad, suffers from the same > deadlock problem. > > David > >> Mandy From avoitylov at openjdk.java.net Wed May 19 16:29:33 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Wed, 19 May 2021 16:29:33 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v3] In-Reply-To: References: Message-ID: > 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 library load operation. > > Problem being fixed: > > The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. > > Proposed fix: > > The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. > > The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. > > Testing: jtreg and jck testing with no regressions. A new regression test was developed. Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: fix trailing whitespace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3976/files - new: https://git.openjdk.java.net/jdk/pull/3976/files/a0b2163a..8f47d890 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3976&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3976&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3976.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3976/head:pull/3976 PR: https://git.openjdk.java.net/jdk/pull/3976 From avoitylov at openjdk.java.net Wed May 19 16:29:36 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Wed, 19 May 2021 16:29:36 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v2] In-Reply-To: <7uREVWzjGhgjYBdEpYZ5OBurn9FzSuu-TG9_xIu-syc=.c737c435-734e-4e79-9969-cf0d2147ac07@github.com> References: <7uREVWzjGhgjYBdEpYZ5OBurn9FzSuu-TG9_xIu-syc=.c737c435-734e-4e79-9969-cf0d2147ac07@github.com> Message-ID: On Wed, 19 May 2021 16:21:41 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 library load operation. >> >> Problem being fixed: >> >> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. >> >> Proposed fix: >> >> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. >> >> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. >> >> Testing: jtreg and jck testing with no regressions. A new regression test was developed. > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > address review comments, add tests Dear colleagues, The updated PR addresses review comment regarding ThreadLocal as well as David' concern around the lock being held during JNI_OnLoad/JNI_OnUnload calls, and ensures all lock objects are deallocated. Multiple threads are allowed to enter NativeLibrary.load() to prevent any thread from locking while another thread loads a library. Before the update, there could be a class loading lock held by a parallel capable class loader, which can deadlock with the library loading lock. As proposed by David Holmes, the library loading lock was removed because dlopen/LoadLibrary are thread safe and they maintain internal reference counters on libraries. There's still a lock being held while a pair of containers are read/updated. It's not going to deadlock as there's no lock/wait operation performed while that lock is held. Multiple threads may create their own copies of NativeLibrary object and register it for auto unloading. Tests for auto unloading were added along with the PR update. There are now 3 jtreg tests: - one checks for deadlock, similar to the one proposed by Chris Hegarty - two other tests are for library unload. The major side effect of that multiple threads are allowed to enter is that JNI_OnLoad/JNI_OnUnload may be called multiple (but same) number of times from concurrent threads. In particular, the number of calls to JNI_OnLoad must be equal to the number of calls to JNI_OnUnload after the relevant class loader is garbage collected. This may affect the behaviour that relies on specific order or the number of JNI_OnLoad/JNI_OnUnload calls. The current JNI specification does not mandate how many times JNI_OnLoad/JNI_OnUnload are called. Also, we could not locate tests in jck/jtreg/vmTestbase that would rely on the specific order or number of calls to JNI_OnLoad/JNI_OnUnload. Thank you Alan Bateman, David Holmes and Chris Hegarty for your valuable input. ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From naoto at openjdk.java.net Wed May 19 16:32:46 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 19 May 2021 16:32:46 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v3] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 23:18:42 GMT, Stephen Colebourne wrote: >> 8266846: Add java.time.InstantSource > > Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: > > 8266846: Add java.time.InstantSource test/jdk/java/time/test/java/time/TestInstantSource.java line 33: > 31: import java.time.Duration; > 32: import java.time.Instant; > 33: import java.time.ZoneId; Needs `import java.time.InstantSource;` ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From naoto at openjdk.java.net Wed May 19 16:36:44 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 19 May 2021 16:36:44 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v2] In-Reply-To: References: <-4wVyKFO8p5jFap50H7tmoQ5VRzSnwZ1A4dCsqy9rOk=.7b351a5f-f127-4941-9467-ac864de71509@github.com> <-hgApr-MNMiCiU90l9cMiqx3lMBNRU9ik0lAmMamvSU=.62f2029b-b52f-4d03-be8d-e4758a2d5c46@github.com> Message-ID: On Tue, 18 May 2021 23:22:49 GMT, Stephen Colebourne wrote: >> test/jdk/java/time/test/java/time/TestInstantSource.java line 86: >> >>> 84: assertEquals(test.instant(), instant); >>> 85: assertSame(test.equals(InstantSource..fixed(instant)); >>> 86: assertEquals(test.hashCode(), InstantSource..fixed(instant).hashCode()); >> >> Not sure this would compile. > > I was expecting the GitHub Action to pickup coding and test issues (since my dev setup can't compile or run tests). But it seems it doesn't. do that. The latest commit should at least compile as I copied the test class to another IDE location, but I have no way of knowing if the tests pass. GitHub Actions just verifies build and tier1 testing, while java.time tests are in tier2, so it won't catch the failure. The test case still does not compile without the `import java.time.InstantSource` statement. I've verified the test passed with that fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From mchung at openjdk.java.net Wed May 19 16:37:41 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 19 May 2021 16:37:41 GMT Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v4] In-Reply-To: References: Message-ID: 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 Reinhold has updated the pull request incrementally with one additional commit since the last revision: > > Fix up IllegalAccessTest Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4015 From peter.levart at gmail.com Wed May 19 16:55:28 2021 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 19 May 2021 18:55:28 +0200 Subject: JEP draft: Scope Locals In-Reply-To: References: Message-ID: <30302ef8-4f44-4421-f34f-3c7e9302878b@gmail.com> On 15/05/2021 19:50, Peter Levart wrote: > Another question: Suppose there are two inheritable ScopeLocal > variables with bound values in scope (A and B) when I take a snapshot: > > var snapshot = ScopeLocal.snapshot(); > > now I pass that snapshot to a thread which does the following: > > ScopeLocal > ??? .where(C, "value for C") > ??? .run(() -> { > ??? ??? System.out.printf("A:%s B:%s C:%s\n", A.isBound(), > B.isBound(), C.isBound()); > ??? ??? ScopeLocal.runWithSnapshot?(() -> { > ??? ??? ??? System.out.printf("A:%s B:%s C:%s\n", A.isBound(), > B.isBound(), C.isBound()); > ??? ??? }, snapshot); > ??? ??? System.out.printf("A:%s B:%s C:%s\n", A.isBound(), > B.isBound(), C.isBound()); > ??? }); > > What would this code print? > > ...in other words, does runWithSnapshot replace the whole set of bound > values or does it merge it with existing set? ...let me answer this myself, after checking current implementation. The answer is: "It depends on whether C is an inheritable ScopeLocal or non-inheritable". If I understand the code correctly there are two independent sets of bindings: inheritable and non-inheritable. snapshot() retrieves the current inheritable set and runWithSnapshot?() replaces current inheriatable set with the snapshot for the execution of given Runnable and afterwards swaps previous inheritable set back. So if C is inheritable, the output would be: A:false B:false C:true A:true B:true C:false A:false B:false C:true ...but if C is non-inheritable, the output would be: A:false B:false C:true A:true B:true C:true A:false B:false C:true This seems consistent. In other words, non-inheritable bindings are never transferred from thread to thread automatically or by snapshot/runWithSnapshot. I can see that snapshot/runWithSnapshot was meant as a mechanism to "simulate" inheritance of bindings when execution is transferred from one thread to another which is not a newly started child thread. Regards, Peter Peter From psandoz at openjdk.java.net Wed May 19 16:54:39 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 19 May 2021 16:54:39 GMT Subject: RFR: 8267190: Optimize Vector API test operations In-Reply-To: References: Message-ID: On Fri, 14 May 2021 23:58:38 GMT, Sandhya Viswanathan wrote: > Vector API test operations (IS_DEFAULT, IS_FINITE, IS_INFINITE, IS_NAN and IS_NEGATIVE) are computed in three steps: > 1) reinterpreting the floating point vectors as integral vectors (int/long) > 2) perform the test in integer domain to get a int/long mask > 3) reinterpret the int/long mask as float/double mask > Step 3) currently is very slow. It can be optimized by modifying the Java code to utilize the existing reinterpret intrinsic. > > For the VectorTestPerf attached to the JBS for JDK-8267190, the performance improves as follows: > > Base: > Benchmark (size) Mode Cnt Score Error Units > VectorTestPerf.IS_DEFAULT 1024 thrpt 5 223.156 ? 90.452 ops/ms > VectorTestPerf.IS_FINITE 1024 thrpt 5 223.841 ? 91.685 ops/ms > VectorTestPerf.IS_INFINITE 1024 thrpt 5 224.561 ? 83.890 ops/ms > VectorTestPerf.IS_NAN 1024 thrpt 5 223.777 ? 70.629 ops/ms > VectorTestPerf.IS_NEGATIVE 1024 thrpt 5 218.392 ? 79.806 ops/ms > > With patch: > Benchmark (size) Mode Cnt Score Error Units > VectorTestPerf.IS_DEFAULT 1024 thrpt 5 8812.357 ? 40.477 ops/ms > VectorTestPerf.IS_FINITE 1024 thrpt 5 7425.739 ? 296.622 ops/ms > VectorTestPerf.IS_INFINITE 1024 thrpt 5 8932.730 ? 269.988 ops/ms > VectorTestPerf.IS_NAN 1024 thrpt 5 8574.872 ? 498.649 ops/ms > VectorTestPerf.IS_NEGATIVE 1024 thrpt 5 8838.400 ? 11.849 ops/ms > > Best Regards, > Sandhya Tier 1 to 3 tests pass on supported platforms ------------- PR: https://git.openjdk.java.net/jdk/pull/4039 From dfuchs at openjdk.java.net Wed May 19 17:01:51 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 19 May 2021 17:01:51 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v3] In-Reply-To: <5Mlj059l4xCeEPL8MFWrsojw0PwbhOd8W5yR2PWV9qo=.21784c99-3074-4392-a5b6-48b160b6f310@github.com> References: <-4wVyKFO8p5jFap50H7tmoQ5VRzSnwZ1A4dCsqy9rOk=.7b351a5f-f127-4941-9467-ac864de71509@github.com> <5PDgT2ctbgsXq8ZHBYQa_4M_AFNKadmKqwUBFWAhCgs=.88433340-cece-4c4a-a1a5-87fbaf27f80d@github.com> <5Mlj059l4xCeEPL8MFWrsojw0PwbhOd8W5yR2PWV9qo=.21784c99-3074-4392-a5b6-48b160b6f310@github.com> Message-ID: On Wed, 19 May 2021 08:41:08 GMT, Peter Levart wrote: >> This isn't my logic - it is existing code that has been moved. I'm not a fan of infinite retry loops as the can hang the system. But I'm happy to change it to work that way if there is a consensus to do so. > > I see the localOffset passed to VM.getNanoTimeAdjustment() has to be in the range of current time +/- 2^32 seconds. This means the thread would have to sleep for ~136 years before the exception is triggered. I think this is more than enough. :-) Exactly. You could hit the 1ns if the operating system clock was concurrently moved backward by a NTP adjustment of ~ 1024 seconds at the same time that the offset is taken but this would be extremely unlikely - I don't believe it deserves any infinite retry loop. That was discussed at the time the enhancement that provides sub-millisecond precision was proposed, and it was rejected in favor of a one time retry. ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From jbachorik at openjdk.java.net Wed May 19 17:01:51 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Wed, 19 May 2021 17:01:51 GMT Subject: RFR: 8203359: Container level resources events [v9] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 22:38:32 GMT, Erik Gahlin wrote: >> Jaroslav Bachorik has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > I wonder if something similar to below could be added to jdk.jfr.internal.Utils: > > private static Metrics[] metrics; > public static Metrics getMetrics() { > if (metrics == null) { > metrics = new Metrics[] { Metrics.systemMetrics() }; > } > return metrics[0]; > } > > public static boolean shouldSkipBytecode(String eventName, Class superClass) { > if (superClass != AbstractJDKEvent.class) { > return false; > } > if (!eventName.startsWith("jdk.Container")) { > return false; > } > return getMetrics() == null; > } > > Then we could add checks to jdk.jfr.internal.JVMUpcalls::bytesForEagerInstrumentation(...) > > eventName = ei.getEventName(); > if (Utils.shouldSkipBytecode(eventName, superClass))) { > return oldBytes; > } > > and jdk.jfr.internal.JVMUpcalls:onRetransform(...) > > if (jdk.internal.event.Event.class.isAssignableFrom(clazz) && !Modifier.isAbstract(clazz.getModifiers())) { > if (Utils.shouldSkipBytecode(clazz.getName(), clazz.getSuperclass())) { > return oldBytes; > } > > This way we would not pay for generating bytecode for events in a non-container environment. > > Not sure if it works, but could perhaps make startup faster? We would still pay for generating the event handlers during registration, but it's much trickier to avoid since we need to store the event type somewhere. @egahlin Unfortunately, I had to make one late change in the periodic event hook registration. If the events are registered conditionally only when running in a container the event metadata are not correct and `TestDefaultConfigurations.java` test will fail. When I register the hooks unconditionally, the metadata is correctly generated and the test passes. I will hold off integration until I hear back from you whether this is acceptable or I should try to find an alternative solution. ------------- PR: https://git.openjdk.java.net/jdk/pull/3126 From mchung at openjdk.java.net Wed May 19 17:09:38 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 19 May 2021 17:09:38 GMT Subject: RFR: 8266936: Add a finalization JFR event [v2] In-Reply-To: References: Message-ID: 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 libraries/applications and prepare them to migrate away from using finalization. As well-known, the finalization mechanism is inherently problematic. > Perhaps a counter per class would be as useful, i.e. jdk.FinalizationStatistics, and if it could be implemented in the VM, without other implications, that would be great. Therefore, a counter per class would be useful as it identifies the usage of finalizers while providing the number of objects per class pending for finalization (see `ReferenceQueue::enqueue` and `ReferenceQueue::reallyPoll` where it keeps track of the pending for finalization counter). Another option is to go with a simple approach - just report the aggregated number of `Finalizer` objects per class which still meets the primary goal to identify what existing code uses finalizers and the counter gives the users an additional information how many finalizers are created. BTW the number of finalizer invocation is not more useful than the number of `Finalizer` instances unless we provide both counters so that the users can determine the number of objects pending for finalization. > Such an event could be enabled by default and provide much greater value than an event that users would need to know about and configure themselves, which 99,99% of all user will not do. I agree an event enabled by default is more useful provided that the performance overhead is insignificant. I was also thinking if this event should be implemented in the VM in order to avoid some performance overhead such as object allocation. Erin, what is the benefit of implementing in in the VM? ------------- PR: https://git.openjdk.java.net/jdk/pull/4101 From egahlin at openjdk.java.net Wed May 19 17:24:43 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Wed, 19 May 2021 17:24:43 GMT Subject: RFR: 8203359: Container level resources events [v9] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 22:38:32 GMT, Erik Gahlin wrote: >> Jaroslav Bachorik has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > I wonder if something similar to below could be added to jdk.jfr.internal.Utils: > > private static Metrics[] metrics; > public static Metrics getMetrics() { > if (metrics == null) { > metrics = new Metrics[] { Metrics.systemMetrics() }; > } > return metrics[0]; > } > > public static boolean shouldSkipBytecode(String eventName, Class superClass) { > if (superClass != AbstractJDKEvent.class) { > return false; > } > if (!eventName.startsWith("jdk.Container")) { > return false; > } > return getMetrics() == null; > } > > Then we could add checks to jdk.jfr.internal.JVMUpcalls::bytesForEagerInstrumentation(...) > > eventName = ei.getEventName(); > if (Utils.shouldSkipBytecode(eventName, superClass))) { > return oldBytes; > } > > and jdk.jfr.internal.JVMUpcalls:onRetransform(...) > > if (jdk.internal.event.Event.class.isAssignableFrom(clazz) && !Modifier.isAbstract(clazz.getModifiers())) { > if (Utils.shouldSkipBytecode(clazz.getName(), clazz.getSuperclass())) { > return oldBytes; > } > > This way we would not pay for generating bytecode for events in a non-container environment. > > Not sure if it works, but could perhaps make startup faster? We would still pay for generating the event handlers during registration, but it's much trickier to avoid since we need to store the event type somewhere. > @egahlin Unfortunately, I had to make one late change in the periodic event hook registration. > If the events are registered conditionally only when running in a container the event metadata are not correct and `TestDefaultConfigurations.java` test will fail. When I register the hooks unconditionally, the metadata is correctly generated and the test passes. > I will hold off integration until I hear back from you whether this is acceptable or I should try to find an alternative solution. I think we should always register the metadata, even if you can't get the event. That's how we handle different GCs. Users must be able to explore events even if they can't use them. For example, you must be able to configure container events in JMC (with correct labels/descriptions) without actually connecting to a JVM running in a Docker container. ------------- PR: https://git.openjdk.java.net/jdk/pull/3126 From naoto at openjdk.java.net Wed May 19 17:49:43 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 19 May 2021 17:49:43 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v3] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 23:18:42 GMT, Stephen Colebourne wrote: >> 8266846: Add java.time.InstantSource > > Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: > > 8266846: Add java.time.InstantSource Another test started failing with your fix. Apparently, the following piece in java/time/test/java/time/TestClock_System.java throws ExceptionInInitializerError. static { try { offsetField = Class.forName("java.time.Clock$SystemClock").getDeclaredField("offset"); offsetField.setAccessible(true); } catch (ClassNotFoundException | NoSuchFieldException ex) { throw new ExceptionInInitializerError(ex); } } ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From egahlin at openjdk.java.net Wed May 19 17:59:40 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Wed, 19 May 2021 17:59:40 GMT Subject: RFR: 8266936: Add a finalization JFR event [v2] In-Reply-To: References: Message-ID: <4_QSMcxN46M-A1ZxjNPkHECuutCfsQMpZ3MiCca6JtA=.64fdccff-f40b-40c6-af5a-65cc5fc8883e@github.com> On Tue, 18 May 2021 22:41:06 GMT, Brent Christian wrote: >> Please review this enhancement to add a new JFR event, generated whenever a finalizer is run. >> (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).) >> >> The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized. >> >> The Category for the event: >> `"Java Virtual Machine" / "GC" / "Finalization"` >> is what made sense to me, even though the event is generated from library code. >> >> Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr. >> Automated testing looks good so far. >> >> Thanks, >> -Brent > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > Test flag should be volatile > 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 and there are callbacks when a class gets unloaded, so it's probably easier to clear any table where the statistics is held. ------------- PR: https://git.openjdk.java.net/jdk/pull/4101 From forax at openjdk.java.net Wed May 19 18:14:51 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 19 May 2021 18:14:51 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v3] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 23:18:42 GMT, Stephen Colebourne wrote: >> 8266846: Add java.time.InstantSource > > Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: > > 8266846: Add java.time.InstantSource It's a side effect of JEP 403, i believe ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From prr at openjdk.java.net Wed May 19 18:16:57 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 19 May 2021 18:16:57 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 13:47:53 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59: > 57: ProcessCommunicator > 58: .executeChildProcess(Consumer.class, new String[0]); > 59: if (!"Hello".equals(processResults.getStdOut())) { Who or what prompted this change ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From prr at openjdk.java.net Wed May 19 18:19:49 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 19 May 2021 18:19:49 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 13:47:53 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java This change is so large that github won't even display the list of files so I can't jump to where I want to go ! And when I try to scroll I get just a blank page. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From github.com+1059453+fleshgrinder at openjdk.java.net Wed May 19 18:27:51 2021 From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger) Date: Wed, 19 May 2021 18:27:51 GMT Subject: RFR: 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant In-Reply-To: References: Message-ID: On Thu, 26 Nov 2020 18:51:10 GMT, Richard Fussenegger wrote: > 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant @bridgekeeper I guess it will stay open for a little longer. ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/1467 From github.com+1059453+fleshgrinder at openjdk.java.net Wed May 19 18:27:53 2021 From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger) Date: Wed, 19 May 2021 18:27:53 GMT Subject: RFR: 5023614: UUID needs methods to get most/leastSigBits and write to DataOutput [v3] In-Reply-To: References: <2jx_KKaEEiEbvuAH398iD_noYamG-_50NkL4nCIQwXE=.5da5bc1d-4cf2-4a10-90be-5dfdaaba9e0e@github.com> Message-ID: On Sat, 28 Nov 2020 10:12:10 GMT, Richard Fussenegger wrote: >> Made byte constructor public and changed the length assertion to an `IllegalArgumentException`, added a `getBytes` method that allows users to retrieve the raw bytes of the UUID, and created a new private constructor with an optimized construction for byte arrays that can set the version as desired and the variant to RFC 4122. Also changed the existing static factory methods to use the new constructor and removed the duplicate code from them where the variant and version is being set. >> >> Report [5023614](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=5023614) asks for more than what I provided and with different names. However, I believe that there is no value in providing methods to deal with `DataInput` and `DataOutput` because they would only encapsulate single method calls that the caller can directly write as well (e.g. `output.write(uuid.getBytes())` vs `uuid.write(output)`). Hence, I consider this change to satisfy the feature request. > > Richard Fussenegger has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. @bridgekeeper I guess it will stay open for a little longer. ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/1465 From prr at openjdk.java.net Wed May 19 18:29:41 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 19 May 2021 18:29:41 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 13:47:53 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java src/java.desktop/share/classes/java/awt/Component.java line 217: > 215: * @author Sami Shaio > 216: */ > 217: @SuppressWarnings("removal") Why is this placed on the *entire class* ?? This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext. src/java.desktop/share/classes/java/awt/Container.java line 97: > 95: * @since 1.0 > 96: */ > 97: @SuppressWarnings("removal") Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places. Where else are you adding this to entire classes instead of the specific site ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From naoto at openjdk.java.net Wed May 19 18:40:03 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 19 May 2021 18:40:03 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v3] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 23:18:42 GMT, Stephen Colebourne wrote: >> 8266846: Add java.time.InstantSource > > Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: > > 8266846: Add java.time.InstantSource The Error was caused by the movement of the field `offset`, from inner `SystemClock` class to `Clock`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From weijun at openjdk.java.net Wed May 19 18:41:44 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 May 2021 18:41:44 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 18:26:25 GMT, Phil Race wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java > > src/java.desktop/share/classes/java/awt/Component.java line 217: > >> 215: * @author Sami Shaio >> 216: */ >> 217: @SuppressWarnings("removal") > > Why is this placed on the *entire class* ?? > This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext. This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is s = java.security.AccessController.doPrivileged( new GetPropertyAction("awt.image.redrawrate")); > src/java.desktop/share/classes/java/awt/Container.java line 97: > >> 95: * @since 1.0 >> 96: */ >> 97: @SuppressWarnings("removal") > > Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places. > > Where else are you adding this to entire classes instead of the specific site ? Similar as the one above, it's because of static { // Don't lazy-read because every app uses invalidate() isJavaAwtSmartInvalidate = AccessController.doPrivileged( new GetBooleanAction("java.awt.smartInvalidate")); } > test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59: > >> 57: ProcessCommunicator >> 58: .executeChildProcess(Consumer.class, new String[0]); >> 59: if (!"Hello".equals(processResults.getStdOut())) { > > Who or what prompted this change ? The child process is started with `-Djava.security.manager=allow` (after the other PR) and a warning will be printed to stderr. Therefore I move the message to stdout. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From mchung at openjdk.java.net Wed May 19 18:43:40 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 19 May 2021 18:43:40 GMT Subject: RFR: 8266936: Add a finalization JFR event [v2] In-Reply-To: <4_QSMcxN46M-A1ZxjNPkHECuutCfsQMpZ3MiCca6JtA=.64fdccff-f40b-40c6-af5a-65cc5fc8883e@github.com> References: <4_QSMcxN46M-A1ZxjNPkHECuutCfsQMpZ3MiCca6JtA=.64fdccff-f40b-40c6-af5a-65cc5fc8883e@github.com> Message-ID: 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 and there are callbacks when a class gets unloaded, so it's probably easier to clear any table where the statistics is held. Thanks for the confirmation. This is performance sensitive area and so it's worth considering doing it in the VM. In either case, performance measurement of the overhead will tell. ------------- PR: https://git.openjdk.java.net/jdk/pull/4101 From weijun at openjdk.java.net Wed May 19 18:46:46 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 May 2021 18:46:46 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 18:39:10 GMT, Weijun Wang wrote: >> src/java.desktop/share/classes/java/awt/Container.java line 97: >> >>> 95: * @since 1.0 >>> 96: */ >>> 97: @SuppressWarnings("removal") >> >> Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places. >> >> Where else are you adding this to entire classes instead of the specific site ? > > Similar as the one above, it's because of > > static { > // Don't lazy-read because every app uses invalidate() > isJavaAwtSmartInvalidate = AccessController.doPrivileged( > new GetBooleanAction("java.awt.smartInvalidate")); > } We are thinking of more tweaks after this overall change to make the annotation more precise. For example, in this case we can assign the `doPrivileged` result to a local variable right at its declaration, and then assign it to `isJavaAwtSmartInvalidate`. Some people might think this is ugly. Such manual code changes need to done little by little to ease code reviewing. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From jvernee at openjdk.java.net Wed May 19 18:50:40 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 19 May 2021 18:50:40 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v3] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 16:29:33 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 library load operation. >> >> Problem being fixed: >> >> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. >> >> Proposed fix: >> >> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. >> >> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. >> >> Testing: jtreg and jck testing with no regressions. A new regression test was developed. > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > fix trailing whitespace src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 262: > 260: } finally { > 261: releaseNativeLibraryLock(name); > 262: } The new locking scheme looks incorrect to me. It now seems possible for 2 different class loaders in 2 different threads to load the same library (which should not be possible). Thread 1: - acquires name lock - checks library name is already in `loadedLibraryNames` (it's not) - release name lock - start loading library Then thread 2 comes in and does the same Then again thread 1 finishes loading and: - acquires name lock - puts library name in `loadedLibraryNames` - puts library name in it's own `libraries` - release lock Then thread 2 comes in and does the same again (although adding the name to `loadedLibraryNames` will silently return `false`). It seems that this scenario is possible, and the library will be loaded by 2 different class loaders, each with their own `lib` object. (If there's a race, there has to be a loser as well, which would need to discard their work when finding out they lost) You might be able to stress this by checking if `loadedLibraryNames.add(name);` returns `true`, and throwing an exception if not. I think a possible solution would be to claim the library name up front for a particular loader. Then 2 threads can still race to load the same library for the same class loader, but 2 threads with 2 different class loaders racing to load the library should not be possible. Actually, you might be able to prevent a race on JNI_OnLoad altogether by claiming the library name for a particular thread upfront as well (e.g. using a `ConcurrentHashMap`). ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From weijun at openjdk.java.net Wed May 19 18:51:43 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 May 2021 18:51:43 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 18:44:06 GMT, Weijun Wang wrote: >> Similar as the one above, it's because of >> >> static { >> // Don't lazy-read because every app uses invalidate() >> isJavaAwtSmartInvalidate = AccessController.doPrivileged( >> new GetBooleanAction("java.awt.smartInvalidate")); >> } > > We are thinking of more tweaks after this overall change to make the annotation more precise. For example, in this case we can assign the `doPrivileged` result to a local variable right at its declaration, and then assign it to `isJavaAwtSmartInvalidate`. Some people might think this is ugly. Such manual code changes need to done little by little to ease code reviewing. I know it's not easy to read the commit and that's why I make the 3rd commit totally automatic. Hopefully you have more confidence on the program than my hand. All annotations are added to the nearest declarations. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From forax at openjdk.java.net Wed May 19 18:59:44 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 19 May 2021 18:59:44 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v3] In-Reply-To: References: Message-ID: <4NHDVx_FgUMFhAOYzi_JVbMgFul5z_jwiMoHeF9t0Sc=.5a41f72d-ec32-4e91-9ebc-4056c70c0c68@github.com> On Tue, 18 May 2021 23:18:42 GMT, Stephen Colebourne wrote: >> 8266846: Add java.time.InstantSource > > Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: > > 8266846: Add java.time.InstantSource my bad ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From psandoz at openjdk.java.net Wed May 19 19:26:44 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 19 May 2021 19:26:44 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v9] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 03:37:11 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. >> >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> Looking forward to your review and feedback. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > fix 32-bit build src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 723: > 721: #end[BITWISE] > 722: #if[FP] > 723: case VECTOR_OP_OR: return (v0, v1) -> `VECTOR_OP_OR` looks incorrect, since `VectorOperators.OR` is not applicable to FP types. ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From prr at openjdk.java.net Wed May 19 19:34:48 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 19 May 2021 19:34:48 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> On Wed, 19 May 2021 18:38:39 GMT, Weijun Wang wrote: >> src/java.desktop/share/classes/java/awt/Component.java line 217: >> >>> 215: * @author Sami Shaio >>> 216: */ >>> 217: @SuppressWarnings("removal") >> >> Why is this placed on the *entire class* ?? >> This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext. > > This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is > > s = java.security.AccessController.doPrivileged( > new GetPropertyAction("awt.image.redrawrate")); That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable. You can define a static private method to contain this and call it from the static initializer block. Much better than applying the annotation to an entire class. --- a/src/java.desktop/share/classes/java/awt/Component.java +++ b/src/java.desktop/share/classes/java/awt/Component.java @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer, */ static boolean isInc; static int incRate; + + private static void initIncRate() { + String s = java.security.AccessController.doPrivileged( + new GetPropertyAction("awt.image.incrementaldraw")); + isInc = (s == null || s.equals("true")); + + s = java.security.AccessController.doPrivileged( + new GetPropertyAction("awt.image.redrawrate")); + incRate = (s != null) ? Integer.parseInt(s) : 100; + } + static { /* ensure that the necessary native libraries are loaded */ Toolkit.loadLibraries(); @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer, if (!GraphicsEnvironment.isHeadless()) { initIDs(); } - - String s = java.security.AccessController.doPrivileged( - new GetPropertyAction("awt.image.incrementaldraw")); - isInc = (s == null || s.equals("true")); - - s = java.security.AccessController.doPrivileged( - new GetPropertyAction("awt.image.redrawrate")); - incRate = (s != null) ? Integer.parseInt(s) : 100; + initIncRate(); } ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From mullan at openjdk.java.net Wed May 19 20:33:43 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 19 May 2021 20:33:43 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager [v2] In-Reply-To: References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: On Tue, 18 May 2021 21:44:43 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.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). >> >> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: >> >> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. >> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. >> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. >> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. >> >> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. >> >> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. >> >> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. >> >> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). >> >> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). >> >> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: >> >> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) >> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) >> ``` >> >> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > adjust order of VM options The changes to the security tests look good. ------------- Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4071 From vromero at openjdk.java.net Wed May 19 20:46:23 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 19 May 2021 20:46:23 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v8] In-Reply-To: References: Message-ID: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. Vicente Romero 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 12 additional commits since the last revision: - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - updating comment after review feedback - removing javax.lang.model changes - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - fixing failing regression tests - ... and 2 more: https://git.openjdk.java.net/jdk/compare/cc4f43fb...d220bc20 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3526/files - new: https://git.openjdk.java.net/jdk/pull/3526/files/0208dcf0..d220bc20 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=06-07 Stats: 40144 lines in 1123 files changed: 19391 ins; 13080 del; 7673 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From david.lloyd at redhat.com Wed May 19 20:55:43 2021 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 19 May 2021 15:55:43 -0500 Subject: JEP draft: Scope Locals In-Reply-To: References: Message-ID: On Wed, May 19, 2021 at 4:01 AM Andrew Haley wrote: > On 5/15/21 6:50 PM, Peter Levart wrote: > > What if I wanted to create and start a thread that would be "pristine" - > > not have any ScopeLocal value bound? Is this intentionally not allowed > > in order to make sure that inheritable ScopeLocal(s) can't be cleared by > > code that has no access to ScopeLocal instance(s)? > > That one is about to be changed by a revision to the JEP. There clearly > is a need to control whether a newly-created thread inherits scope locals > or not. For instance, an Executor might lazily create worker threads, and > we don't want them to inherit scope locals from the thread that was > running. > Turning this around, I would argue that there are few (or perhaps *no*) cases where it would ever be desirable to inherit scope locals across thread creation; in cases where this is explicitly desired, one can always resume the snapshot from within the thread's Runnable. Was there a particular use case this was meant to address? -- - DML ? he/him From almatvee at openjdk.java.net Wed May 19 21:07:47 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 19 May 2021 21:07:47 GMT Subject: RFR: 8267056: tools/jpackage/share/RuntimePackageTest.java fails with NoSuchFileException Message-ID: <3FZIYFgMcdRP9EWWHTLNbg-IM8B4Zt0LW4YtvhCIpqA=.e76ed78b-1591-446b-b4bc-29b4d6b00e11@github.com> For debug build on macOS, runtime which used for test fill be located in /path/jdk-17/fastdebug and /path/jdk-17 will not contain any other files except fastdebug and in this case our check to decide if we need to copy app or runtime will return /path/jdk-17 which is not correct. Fixed by skipping this check for runtime and only using it for app. Also, added ignoring .DS_Store to test which is needed if user used Finder to look inside runtime folder which will cause .DS_Store to be created and will cause test to fail, since this file is not being packaged. ------------- Commit messages: - 8267056: tools/jpackage/share/RuntimePackageTest.java fails with NoSuchFileException Changes: https://git.openjdk.java.net/jdk/pull/4120/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4120&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267056 Stats: 15 lines in 2 files changed: 5 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4120.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4120/head:pull/4120 PR: https://git.openjdk.java.net/jdk/pull/4120 From brian.goetz at oracle.com Wed May 19 21:23:34 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 19 May 2021 17:23:34 -0400 Subject: [External] : Re: ReversibleCollection proposal In-Reply-To: References: <2bbe-609d7b80-36b-7314b880@138287482> <477307921.278512.1620944115116.JavaMail.zimbra@u-pem.fr> Message-ID: > Has it ever been conceived to create an entire new API like how it was > done for Dates and Times? Obviously this would be a massive > undertaking, but it seems to me we've just about reached the limits of > how far we can stretch the current API. "This code is a mess, we should throw it away and rewrite it" ?? -- every developer Don't confuse the volume of "I would rather do it this way" replies with the complexity of this issue; I think that's just the nature of the game ("Being the biggest crime of the last 50 years, and everybody wanted to get in the newspaper story about it.")? Stuart's proposal is a measured, responsible, carefully-thought-through way to extend the framework we have. In addition to "massive undertaking", and in addition to "if you think you can't get people to agree on something the size of a golf ball, try to get them to agree on something the size of Montana", there's another massive problem here: migration.? It's not just a matter of having a "better" Collections library; the collection interfaces we have (Collection, List, Map, Set) have found their way into the API of nearly every Java library.? Moving to Collections II would then force a migration on every one of those libraries (or consumer of those libraries.) From david.lloyd at redhat.com Wed May 19 21:51:27 2021 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 19 May 2021 16:51:27 -0500 Subject: JEP draft: Scope Locals In-Reply-To: References: Message-ID: On Wed, May 12, 2021 at 9:43 AM Andrew Haley wrote: > There's been considerable discussion about scope locals on the loom-dev > list, > and it's now time to open this to a wider audience. This subject is > important > because. although scope locals were motivated by the the needs of Loom, > they > have many potential applications outside that project. > I didn't get a chance to mention earlier, but I think scope locals are shaping up really great so far: simple yet powerful. I know this will be a really useful addition to the JDK. There are several projects both within and without Red Hat that I have authored or have contributed to which use a very compatible pattern (that is, using a lexically constrained binding strategy for context association) and are perfect candidates to switch over to use this feature. That said, I have one minor comment about the API. :-) I think it would be really nice if the snapshot class could hold its run/call method rather than making it a static method of `ScopeLocal`. This reads more naturally to me (and is nicer to write): var snap = ScopeLocal.snapshot(); return executor.submit(() -> snap.call(aCallable)); Than this: var snap = ScopeLocal.snapshot(); return executor.submit(() -> ScopeLocal.callWithSnapshot(aCallable, snap )); This kind of lexically bound contextual pattern can be found in several of our existing projects (including those listed below [1] [2]). In writing these projects, we took it a step further than just Runnable and Callable and added variants which accept `Consumer` plus a `T` to pass in, a `Function` plus a `T` to pass in, and `BiConsumer` and `BiFunction` variants as well which accept two arguments to pass in. The practical reason here is that we could then pass in a method handle with explicit arguments rather than relying on lambda capture, which can be expensive in certain circumstances. The overall benefit vs cost of doing this is probably debatable, but I thought the idea might be interesting at any rate. Anyway that's it. I love this feature and am excited to see it get into the JDK! [1] WildFly Elytron "Scoped" API, used by client and server authentication contexts (WildFly's version of JAAS Subject): https://github.com/wildfly-security/wildfly-elytron/blob/1.x/auth/server/base/src/main/java/org/wildfly/security/auth/server/Scoped.java [2] WildFly Common "Contextual" API used for transaction, configuration, and other context propagation: https://github.com/wildfly/wildfly-common/blob/master/src/main/java/org/wildfly/common/context/Contextual.java -- - DML ? he/him From sviswanathan at openjdk.java.net Wed May 19 21:55:07 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 19 May 2021 21:55:07 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v10] In-Reply-To: References: Message-ID: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: Implement Vladimir Ivanov and Paul Sandoz review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/f7e39913..0b4a1c9c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=08-09 Stats: 45 lines in 1 file changed: 0 ins; 45 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From weijun at openjdk.java.net Wed May 19 21:56:30 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 May 2021 21:56:30 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> Message-ID: On Wed, 19 May 2021 19:31:24 GMT, Phil Race wrote: >> This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is >> >> s = java.security.AccessController.doPrivileged( >> new GetPropertyAction("awt.image.redrawrate")); > > That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable. > You can define a static private method to contain this and call it from the static initializer block. > Much better than applying the annotation to an entire class. > > --- a/src/java.desktop/share/classes/java/awt/Component.java > +++ b/src/java.desktop/share/classes/java/awt/Component.java > @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer, > */ > static boolean isInc; > static int incRate; > + > + private static void initIncRate() { > + String s = java.security.AccessController.doPrivileged( > + new GetPropertyAction("awt.image.incrementaldraw")); > + isInc = (s == null || s.equals("true")); > + > + s = java.security.AccessController.doPrivileged( > + new GetPropertyAction("awt.image.redrawrate")); > + incRate = (s != null) ? Integer.parseInt(s) : 100; > + } > + > static { > /* ensure that the necessary native libraries are loaded */ > Toolkit.loadLibraries(); > @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer, > if (!GraphicsEnvironment.isHeadless()) { > initIDs(); > } > - > - String s = java.security.AccessController.doPrivileged( > - new GetPropertyAction("awt.image.incrementaldraw")); > - isInc = (s == null || s.equals("true")); > - > - s = java.security.AccessController.doPrivileged( > - new GetPropertyAction("awt.image.redrawrate")); > - incRate = (s != null) ? Integer.parseInt(s) : 100; > + initIncRate(); > } Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From scolebourne at openjdk.java.net Wed May 19 21:58:08 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Wed, 19 May 2021 21:58:08 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v4] In-Reply-To: References: Message-ID: > 8266846: Add java.time.InstantSource Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: 8266846: Add java.time.InstantSource ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4016/files - new: https://git.openjdk.java.net/jdk/pull/4016/files/425e01a8..c7d9076b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4016&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4016&range=02-03 Stats: 6 lines in 2 files changed: 2 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4016.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4016/head:pull/4016 PR: https://git.openjdk.java.net/jdk/pull/4016 From scolebourne at openjdk.java.net Wed May 19 21:58:11 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Wed, 19 May 2021 21:58:11 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v3] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 23:18:42 GMT, Stephen Colebourne wrote: >> 8266846: Add java.time.InstantSource > > Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: > > 8266846: Add java.time.InstantSource I've made the obvious changes to fix the offset reflection. However it does now mean that the offset is being altered for a singleton where previously it would have only affected Clock.systemUtc(). Is the test class spun up in its own JVM process? Just want to make sure that manipulating the singleton clock won't impact other tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From sviswanathan at openjdk.java.net Wed May 19 21:58:37 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 19 May 2021 21:58:37 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v2] In-Reply-To: References: Message-ID: On Mon, 3 May 2021 21:41:26 GMT, Paul Sandoz wrote: >> Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Merge master >> - remove whitespace >> - Merge master >> - Small fix >> - cleanup >> - x86 short vector math optimization for Vector API > > Tier 1 to 3 tests pass for the default set of build profiles. Thanks a lot for the review @PaulSandoz @iwanowww @erikj79. Paul and Vladimir, I have implemented your review comments. Please take a look. ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From psandoz at openjdk.java.net Wed May 19 22:05:59 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 19 May 2021 22:05:59 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v2] In-Reply-To: References: Message-ID: On Mon, 3 May 2021 21:41:26 GMT, Paul Sandoz wrote: >> Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Merge master >> - remove whitespace >> - Merge master >> - Small fix >> - cleanup >> - x86 short vector math optimization for Vector API > > Tier 1 to 3 tests pass for the default set of build profiles. > Thanks a lot for the review @PaulSandoz @iwanowww @erikj79. > Paul and Vladimir, I have implemented your review comments. Please take a look. `case VECTOR_OP_OR` is still present. ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From prr at openjdk.java.net Wed May 19 22:07:36 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 19 May 2021 22:07:36 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> Message-ID: On Wed, 19 May 2021 21:53:35 GMT, Weijun Wang wrote: >> That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable. >> You can define a static private method to contain this and call it from the static initializer block. >> Much better than applying the annotation to an entire class. >> >> --- a/src/java.desktop/share/classes/java/awt/Component.java >> +++ b/src/java.desktop/share/classes/java/awt/Component.java >> @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer, >> */ >> static boolean isInc; >> static int incRate; >> + >> + private static void initIncRate() { >> + String s = java.security.AccessController.doPrivileged( >> + new GetPropertyAction("awt.image.incrementaldraw")); >> + isInc = (s == null || s.equals("true")); >> + >> + s = java.security.AccessController.doPrivileged( >> + new GetPropertyAction("awt.image.redrawrate")); >> + incRate = (s != null) ? Integer.parseInt(s) : 100; >> + } >> + >> static { >> /* ensure that the necessary native libraries are loaded */ >> Toolkit.loadLibraries(); >> @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer, >> if (!GraphicsEnvironment.isHeadless()) { >> initIDs(); >> } >> - >> - String s = java.security.AccessController.doPrivileged( >> - new GetPropertyAction("awt.image.incrementaldraw")); >> - isInc = (s == null || s.equals("true")); >> - >> - s = java.security.AccessController.doPrivileged( >> - new GetPropertyAction("awt.image.redrawrate")); >> - incRate = (s != null) ? Integer.parseInt(s) : 100; >> + initIncRate(); >> } > > Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed. I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release. I think it should all be taken care of as part of this proposed change. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From sviswanathan at openjdk.java.net Wed May 19 22:16:18 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 19 May 2021 22:16:18 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v11] In-Reply-To: References: Message-ID: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: Commit missing changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/0b4a1c9c..1b0367ac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=09-10 Stats: 55 lines in 16 files changed: 2 ins; 42 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From sviswanathan at openjdk.java.net Wed May 19 22:16:19 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 19 May 2021 22:16:19 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v2] In-Reply-To: References: Message-ID: <5ncMaHLhmfOv3FBOrYSkKmzVXHwQqFks-RPcjuC02Mo=.31de0845-e60a-413a-8984-0ce6e4eac2ed@github.com> On Wed, 19 May 2021 22:02:14 GMT, Paul Sandoz wrote: >> Tier 1 to 3 tests pass for the default set of build profiles. > >> Thanks a lot for the review @PaulSandoz @iwanowww @erikj79. >> Paul and Vladimir, I have implemented your review comments. Please take a look. > > `case VECTOR_OP_OR` is still present. @PaulSandoz Thanks for pointing that out. I had missed git add for some of the files. ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From weijun at openjdk.java.net Wed May 19 22:17:34 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 May 2021 22:17:34 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> Message-ID: <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> On Wed, 19 May 2021 22:04:57 GMT, Phil Race wrote: >> Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed. > > I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release. > I think it should all be taken care of as part of this proposed change. I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From psandoz at openjdk.java.net Wed May 19 22:29:32 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 19 May 2021 22:29:32 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v11] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 22:16:18 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. >> >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> Looking forward to your review and feedback. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > Commit missing changes > @PaulSandoz Thanks for pointing that out. I had missed git add for some of the files. Java changes look good. Please don't integrate when checks pass. I need to work through some JEP details first before we can integrate relevant PRs. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3638 From david.holmes at oracle.com Wed May 19 22:31:14 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 May 2021 08:31:14 +1000 Subject: RFR: 8266310: deadlock while loading the JNI code [v2] In-Reply-To: References: <7uREVWzjGhgjYBdEpYZ5OBurn9FzSuu-TG9_xIu-syc=.c737c435-734e-4e79-9969-cf0d2147ac07@github.com> Message-ID: On 20/05/2021 2:29 am, Aleksei Voitylov wrote: > On Wed, 19 May 2021 16:21:41 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 library load operation. >>> >>> Problem being fixed: >>> >>> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. >>> >>> Proposed fix: >>> >>> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. >>> >>> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. >>> >>> Testing: jtreg and jck testing with no regressions. A new regression test was developed. >> >> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: >> >> address review comments, add tests > > Dear colleagues, > > The updated PR addresses review comment regarding ThreadLocal as well as David' concern around the lock being held during JNI_OnLoad/JNI_OnUnload calls, and ensures all lock objects are deallocated. Multiple threads are allowed to enter NativeLibrary.load() to prevent any thread from locking while another thread loads a library. Before the update, there could be a class loading lock held by a parallel capable class loader, which can deadlock with the library loading lock. As proposed by David Holmes, the library loading lock was removed because dlopen/LoadLibrary are thread safe and they maintain internal reference counters on libraries. There's still a lock being held while a pair of containers are read/updated. It's not going to deadlock as there's no lock/wait operation performed while that lock is held. Multiple threads may create their own copies of NativeLibrary object and register it for auto unloading. > > Tests for auto unloading were added along with the PR update. There are now 3 jtreg tests: > - one checks for deadlock, similar to the one proposed by Chris Hegarty > - two other tests are for library unload. > > The major side effect of that multiple threads are allowed to enter is that JNI_OnLoad/JNI_OnUnload may be called multiple (but same) number of times from concurrent threads. In particular, the number of calls to JNI_OnLoad must be equal to the number of calls to JNI_OnUnload after the relevant class loader is garbage collected. This may affect the behaviour that relies on specific order or the number of JNI_OnLoad/JNI_OnUnload calls. The current JNI specification does not mandate how many times JNI_OnLoad/JNI_OnUnload are called. Also, we could not locate tests in jck/jtreg/vmTestbase that would rely on the specific order or number of calls to JNI_OnLoad/JNI_OnUnload. But you can't make such a change! That was my point. To fix the deadlock we must not hold a lock. But we must ensure only a single call to JNI_OnLoad is possible. It is an unsolvable problem with those constraints. You can't just change the behaviour of JNI_OnLoad like that. David ----- > Thank you Alan Bateman, David Holmes and Chris Hegarty for your valuable input. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3976 > From sviswanathan at openjdk.java.net Wed May 19 22:52:09 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 19 May 2021 22:52:09 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v12] In-Reply-To: References: Message-ID: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Merge master - Commit missing changes - Implement Vladimir Ivanov and Paul Sandoz review comments - fix 32-bit build - Add comments explaining naming convention - jcheck fixes - Print intrinsic fix - Implement review comments - Add missing Lib.gmk - Merge master - ... and 6 more: https://git.openjdk.java.net/jdk/compare/b961f253...7b959b67 ------------- Changes: https://git.openjdk.java.net/jdk/pull/3638/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=11 Stats: 416021 lines in 119 files changed: 415854 ins; 124 del; 43 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From naoto at openjdk.java.net Wed May 19 22:58:34 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 19 May 2021 22:58:34 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v4] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 21:58:08 GMT, Stephen Colebourne wrote: >> 8266846: Add java.time.InstantSource > > Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: > > 8266846: Add java.time.InstantSource I believe that the default execution mode is `agentvm` so it will leave unnecessary side effects. To make it run in `othervm` mode, possibly you will need to tweak TEST.properties (not tried though). ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From sviswanathan at openjdk.java.net Wed May 19 23:01:09 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 19 May 2021 23:01:09 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v13] In-Reply-To: References: Message-ID: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: correct ppc.ad ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/7b959b67..4d59af0a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=11-12 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From prr at openjdk.java.net Wed May 19 23:53:35 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 19 May 2021 23:53:35 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> Message-ID: On Wed, 19 May 2021 22:14:20 GMT, Weijun Wang wrote: >> I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release. >> I think it should all be taken care of as part of this proposed change. > > I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release. Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork, and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready. I already pasted the patch for Component.java and it took about 60 seconds to do that. Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored. I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From sviswanathan at openjdk.java.net Thu May 20 01:27:48 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 20 May 2021 01:27:48 GMT Subject: RFR: 8267190: Optimize Vector API test operations [v2] In-Reply-To: References: Message-ID: > Vector API test operations (IS_DEFAULT, IS_FINITE, IS_INFINITE, IS_NAN and IS_NEGATIVE) are computed in three steps: > 1) reinterpreting the floating point vectors as integral vectors (int/long) > 2) perform the test in integer domain to get a int/long mask > 3) reinterpret the int/long mask as float/double mask > Step 3) currently is very slow. It can be optimized by modifying the Java code to utilize the existing reinterpret intrinsic. > > For the VectorTestPerf attached to the JBS for JDK-8267190, the performance improves as follows: > > Base: > Benchmark (size) Mode Cnt Score Error Units > VectorTestPerf.IS_DEFAULT 1024 thrpt 5 223.156 ? 90.452 ops/ms > VectorTestPerf.IS_FINITE 1024 thrpt 5 223.841 ? 91.685 ops/ms > VectorTestPerf.IS_INFINITE 1024 thrpt 5 224.561 ? 83.890 ops/ms > VectorTestPerf.IS_NAN 1024 thrpt 5 223.777 ? 70.629 ops/ms > VectorTestPerf.IS_NEGATIVE 1024 thrpt 5 218.392 ? 79.806 ops/ms > > With patch: > Benchmark (size) Mode Cnt Score Error Units > VectorTestPerf.IS_DEFAULT 1024 thrpt 5 8812.357 ? 40.477 ops/ms > VectorTestPerf.IS_FINITE 1024 thrpt 5 7425.739 ? 296.622 ops/ms > VectorTestPerf.IS_INFINITE 1024 thrpt 5 8932.730 ? 269.988 ops/ms > VectorTestPerf.IS_NAN 1024 thrpt 5 8574.872 ? 498.649 ops/ms > VectorTestPerf.IS_NEGATIVE 1024 thrpt 5 8838.400 ? 11.849 ops/ms > > Best Regards, > Sandhya Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: Implement Paul's review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4039/files - new: https://git.openjdk.java.net/jdk/pull/4039/files/bb0d4000..b506fc45 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4039&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4039&range=00-01 Stats: 806 lines in 31 files changed: 0 ins; 310 del; 496 mod Patch: https://git.openjdk.java.net/jdk/pull/4039.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4039/head:pull/4039 PR: https://git.openjdk.java.net/jdk/pull/4039 From sviswanathan at openjdk.java.net Thu May 20 01:27:49 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 20 May 2021 01:27:49 GMT Subject: RFR: 8267190: Optimize Vector API test operations In-Reply-To: References: Message-ID: On Wed, 19 May 2021 16:51:33 GMT, Paul Sandoz wrote: >> Vector API test operations (IS_DEFAULT, IS_FINITE, IS_INFINITE, IS_NAN and IS_NEGATIVE) are computed in three steps: >> 1) reinterpreting the floating point vectors as integral vectors (int/long) >> 2) perform the test in integer domain to get a int/long mask >> 3) reinterpret the int/long mask as float/double mask >> Step 3) currently is very slow. It can be optimized by modifying the Java code to utilize the existing reinterpret intrinsic. >> >> For the VectorTestPerf attached to the JBS for JDK-8267190, the performance improves as follows: >> >> Base: >> Benchmark (size) Mode Cnt Score Error Units >> VectorTestPerf.IS_DEFAULT 1024 thrpt 5 223.156 ? 90.452 ops/ms >> VectorTestPerf.IS_FINITE 1024 thrpt 5 223.841 ? 91.685 ops/ms >> VectorTestPerf.IS_INFINITE 1024 thrpt 5 224.561 ? 83.890 ops/ms >> VectorTestPerf.IS_NAN 1024 thrpt 5 223.777 ? 70.629 ops/ms >> VectorTestPerf.IS_NEGATIVE 1024 thrpt 5 218.392 ? 79.806 ops/ms >> >> With patch: >> Benchmark (size) Mode Cnt Score Error Units >> VectorTestPerf.IS_DEFAULT 1024 thrpt 5 8812.357 ? 40.477 ops/ms >> VectorTestPerf.IS_FINITE 1024 thrpt 5 7425.739 ? 296.622 ops/ms >> VectorTestPerf.IS_INFINITE 1024 thrpt 5 8932.730 ? 269.988 ops/ms >> VectorTestPerf.IS_NAN 1024 thrpt 5 8574.872 ? 498.649 ops/ms >> VectorTestPerf.IS_NEGATIVE 1024 thrpt 5 8838.400 ? 11.849 ops/ms >> >> Best Regards, >> Sandhya > > Tier 1 to 3 tests pass on supported platforms @PaulSandoz @vnkozlov Thanks a lot for the review. Paul, I have implemented your review comments. I also changed the switch to switch expression. Please take a look. ------------- PR: https://git.openjdk.java.net/jdk/pull/4039 From weijun at openjdk.java.net Thu May 20 02:09:42 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 20 May 2021 02:09:42 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> Message-ID: On Wed, 19 May 2021 23:50:04 GMT, Phil Race wrote: >> I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release. > > Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork, > and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready. > I already pasted the patch for Component.java and it took about 60 seconds to do that. > Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored. > > I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ? I can make it a bug. I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here. And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers. Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Thu May 20 02:12:33 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 20 May 2021 02:12:33 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> Message-ID: On Thu, 20 May 2021 02:06:46 GMT, Weijun Wang wrote: >> Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork, >> and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready. >> I already pasted the patch for Component.java and it took about 60 seconds to do that. >> Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored. >> >> I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ? > > I can make it a bug. > > I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here. > > And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers. > > Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB. By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From prr at openjdk.java.net Thu May 20 04:08:38 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 20 May 2021 04:08:38 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> Message-ID: <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com> On Thu, 20 May 2021 02:09:57 GMT, Weijun Wang wrote: >> I can make it a bug. >> >> I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here. >> >> And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers. >> >> Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB. > > By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now. That is unfortunate, but nonetheless I think required to be done. We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP. >From my point of view it is a blocker. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From prr at openjdk.java.net Thu May 20 04:25:29 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 20 May 2021 04:25:29 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com> Message-ID: On Thu, 20 May 2021 04:05:23 GMT, Phil Race wrote: >> By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now. > > That is unfortunate, but nonetheless I think required to be done. > We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP. > From my point of view it is a blocker. The JEP isn't PTT for 17 so there's plenty of time isn't there ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From joehw at openjdk.java.net Thu May 20 05:10:18 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 20 May 2021 05:10:18 GMT Subject: RFR: 8265248: Implementation Specific Properties: change prefix, plus add existing properties [v6] In-Reply-To: References: Message-ID: <_FiWL5oqiMnm4gpYCazf9fUEM6xCgZjXAO_qYIuVEK0=.877cccc6-0a6b-4d33-b195-ecc46d134de9@github.com> > Update module summary, add a few existing properties and features into the tables. Joe Wang 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 six additional commits since the last revision: - Merge branch 'master' into JDK-8265248 before a major commit that will involve many (57) classes. - Thanks Roger. Changed to fully qualified names. Also made them align left instead of center - Add legacy property names table - replace isAssignableFrom with instanceof - Update the CSR. See Update 03 in the CSR - 8265248: Implementation Specific Properties: change prefix, plus add existing properties ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3644/files - new: https://git.openjdk.java.net/jdk/pull/3644/files/70f634de..d4356925 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3644&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3644&range=04-05 Stats: 566351 lines in 5111 files changed: 50537 ins; 501716 del; 14098 mod Patch: https://git.openjdk.java.net/jdk/pull/3644.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3644/head:pull/3644 PR: https://git.openjdk.java.net/jdk/pull/3644 From dfranken.jdk at gmail.com Thu May 20 06:35:30 2021 From: dfranken.jdk at gmail.com (dfranken.jdk at gmail.com) Date: Thu, 20 May 2021 08:35:30 +0200 Subject: [External] : Re: ReversibleCollection proposal In-Reply-To: References: <2bbe-609d7b80-36b-7314b880@138287482> <477307921.278512.1620944115116.JavaMail.zimbra@u-pem.fr> Message-ID: <0f2dedf1dc5a372586eccd96b765c42670f70493.camel@gmail.com> Dear Brian, I understand this would be a massive undertaking. Still, the date-time library was a mess before Java 8 and it has been rewritten and found its way to most other libraries. So while I understand this isn't going to be done any time soon, my only question was whether it had been thought about at any time in the past. And if the consensus at that time was 'well, it would be great if we could do it, but it's totally impractical, so let's not do it' I would be okay with that. I also think the proposal of Stuart is reasonable though, but it seemed to me that we had reached some sort of impasse in this discussion. As Remi points out, we have (default) methods which sometimes throw exceptions when they are implemented to signify they don't actually implement the given feature, but we also have interfaces which add new methods. So any choice we make here seems to be inconsistent with some choice we made in the past, but such is the nature of software development I guess. Given the choices of what is actually possible, I would go the interface route. Kind regards, Dave On Wed, 2021-05-19 at 17:23 -0400, Brian Goetz wrote: > > > Has it ever been conceived to create an entire new API like how it > > was > > done for Dates and Times? Obviously this would be a massive > > undertaking, but it seems to me we've just about reached the limits > > of > > how far we can stretch the current API. > > "This code is a mess, we should throw it away and rewrite it" > > ??? -- every developer > > Don't confuse the volume of "I would rather do it this way" replies > with > the complexity of this issue; I think that's just the nature of the > game > ("Being the biggest crime of the last 50 years, and everybody wanted > to > get in the newspaper story about it.")? Stuart's proposal is a > measured, > responsible, carefully-thought-through way to extend the framework we > have. > > In addition to "massive undertaking", and in addition to "if you > think > you can't get people to agree on something the size of a golf ball, > try > to get them to agree on something the size of Montana", there's > another > massive problem here: migration.? It's not just a matter of having a > "better" Collections library; the collection interfaces we have > (Collection, List, Map, Set) have found their way into the API of > nearly > every Java library.? Moving to Collections II would then force a > migration on every one of those libraries (or consumer of those > libraries.) > > From github.com+10835776+stsypanov at openjdk.java.net Thu May 20 06:45:43 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 20 May 2021 06:45:43 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 16:38:03 GMT, ?????? ??????? wrote: >> Non-static classes hold a link to their parent classes, which in many cases can be avoided. > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8261880: Remove static from declarations of Holder nested classes Any more comments? ------------- PR: https://git.openjdk.java.net/jdk/pull/2589 From jbachorik at openjdk.java.net Thu May 20 06:46:26 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 20 May 2021 06:46:26 GMT Subject: RFR: 8203359: Container level resources events [v14] In-Reply-To: References: Message-ID: > With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events. > > Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with. > * CPU related metrics > * Memory related metrics > * I/O related metrics > > For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. > By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently). Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: Remove conditinal registration of event hooks ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3126/files - new: https://git.openjdk.java.net/jdk/pull/3126/files/e0f5855b..37931f4a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3126&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3126&range=12-13 Stats: 16 lines in 1 file changed: 1 ins; 4 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/3126.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3126/head:pull/3126 PR: https://git.openjdk.java.net/jdk/pull/3126 From jbachorik at openjdk.java.net Thu May 20 06:46:26 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 20 May 2021 06:46:26 GMT Subject: RFR: 8203359: Container level resources events [v9] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 17:21:26 GMT, Erik Gahlin wrote: > I think you need to add the hook, for the event metadata to be correct. Otherwise, the "period" setting will not show up. Yes. The failed test log would indicate also the rest of the metadata not being in a good shape. But with the hook registered everything works fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/3126 From alanb at openjdk.java.net Thu May 20 07:08:35 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 20 May 2021 07:08:35 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com> Message-ID: On Thu, 20 May 2021 04:22:32 GMT, Phil Race wrote: >> That is unfortunate, but nonetheless I think required to be done. >> We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP. >> From my point of view it is a blocker. > > The JEP isn't PTT for 17 so there's plenty of time isn't there ? There are 827 files in this patch. Phil is right that adding SW at the class level is introducing technical debt but if addressing that requires refactoring and re-testing of AWT or font code then it would be better to have someone from that area working on. Is there any reason why this can't be going on now on awt-dev/2d-dev and integrated immediately after JEP 411? I don't think we should put Max through the wringer here as there are too many areas to cover. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From peter.levart at gmail.com Thu May 20 07:27:31 2021 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 20 May 2021 09:27:31 +0200 Subject: [External] : Re: ReversibleCollection proposal In-Reply-To: <0f2dedf1dc5a372586eccd96b765c42670f70493.camel@gmail.com> References: <2bbe-609d7b80-36b-7314b880@138287482> <477307921.278512.1620944115116.JavaMail.zimbra@u-pem.fr> <0f2dedf1dc5a372586eccd96b765c42670f70493.camel@gmail.com> Message-ID: <2aa8636c-57d1-5fb9-b3ac-39a874f7b9db@gmail.com> On 20/05/2021 08:35, dfranken.jdk at gmail.com wrote: > I also think the proposal of Stuart is reasonable though, but it seemed > to me that we had reached some sort of impasse in this discussion. As > Remi points out, we have (default) methods which sometimes throw > exceptions when they are implemented to signify they don't actually > implement the given feature, but we also have interfaces which add new > methods. So any choice we make here seems to be inconsistent with some > choice we made in the past, but such is the nature of software > development I guess. I think progress is still possible. The discussion has shown some alternatives which are not better than new ReversibleCollection/ReversibleSet types. The discussion has raised some concerns about compatibility but they are not to hard to overcome (mostly just source-level). There is clearly a benefit from new types although migration to use them will not be fast. But it might be faster than we are used to. The most difficult was (and for some still is) a JDK 8 -> JDK 9 jump, but once you are on JDK 9+ it is relatively easy to follow latest JDK release. With LTS JDK 17 around the corner, I expect most production code which now runs on JDK 11 will relatively quickly migrate to JDK 17 just for improvements in JVM/GC if not for Language/APIs. I think adding these types will surely trigger some disturbance but nothing major. Peter From aph at redhat.com Thu May 20 08:02:44 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 May 2021 09:02:44 +0100 Subject: JEP draft: Scope Locals In-Reply-To: <1564558114.876437.1621098902738.JavaMail.zimbra@u-pem.fr> References: <1564558114.876437.1621098902738.JavaMail.zimbra@u-pem.fr> Message-ID: On 5/15/21 6:15 PM, Remi Forax wrote: > I think the JEP should be more explicit about the shortcoming of ThreadLocal and how the design of scope local fix both issues. Yes. It's in progress. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu May 20 08:05:34 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 May 2021 09:05:34 +0100 Subject: JEP draft: Scope Locals In-Reply-To: <30302ef8-4f44-4421-f34f-3c7e9302878b@gmail.com> References: <30302ef8-4f44-4421-f34f-3c7e9302878b@gmail.com> Message-ID: On 5/19/21 5:55 PM, Peter Levart wrote: > In other words, non-inheritable bindings are > never transferred from thread to thread automatically or by > snapshot/runWithSnapshot. I can see that snapshot/runWithSnapshot was > meant as a mechanism to "simulate" inheritance of bindings when > execution is transferred from one thread to another which is not a newly > started child thread. Yes. However, this part of the draft proposal is undergoing some revision, and it looks like it will make more sense to control inheritance in a different way, one that will permit more flexible control over what gets inherited and when. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu May 20 08:06:43 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 May 2021 09:06:43 +0100 Subject: JEP draft: Scope Locals In-Reply-To: References: Message-ID: <2225b12a-16db-3477-f6a1-7b074717c001@redhat.com> On 5/19/21 9:55 PM, David Lloyd wrote: > Turning this around, I would argue that there are few (or perhaps *no*) > cases where it would ever be desirable to inherit scope locals across > thread creation; in cases where this is explicitly desired, one can always > resume the snapshot from within the thread's Runnable. Was there a > particular use case this was meant to address? Structured Concurrency, but also possibly anywhere that inheritable thread locals are used now. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu May 20 08:10:18 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 May 2021 09:10:18 +0100 Subject: JEP draft: Scope Locals In-Reply-To: References: Message-ID: On 5/19/21 10:51 PM, David Lloyd wrote: > I think it would be really nice if the snapshot class could hold its > run/call method rather than making it a static method of `ScopeLocal`. This > reads more naturally to me (and is nicer to write): True, but inheritance is *extremely* time-critical when creating a ForkJoin task. In many cases there won't be any scope locals to inherit, and by allowing null snapshots you save a significant fraction of a nanosecond when creating one. And I know, this is hard to believe, but such an overhead has a significant macroscopic effect on benchmarks. However, I do intend to fix this in a different way, if I can. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vromero at openjdk.java.net Thu May 20 09:14:33 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 20 May 2021 09:14:33 GMT Subject: Integrated: 8260517: implement Sealed Classes as a standard feature in Java In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 01:08:57 GMT, Vicente Romero wrote: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. This pull request has now been integrated. Changeset: 0fa9223f Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/0fa9223f34bc33635079763362f42f0a5c53759b Stats: 444 lines in 54 files changed: 51 ins; 275 del; 118 mod 8260517: implement Sealed Classes as a standard feature in Java Co-authored-by: Harold Seigel Co-authored-by: Vicente Romero Reviewed-by: dholmes, mcimadamore, jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/3526 From tvaleev at openjdk.java.net Thu May 20 10:28:45 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Thu, 20 May 2021 10:28:45 GMT Subject: RFR: 8267452: Delegate forEachRemaining in Spliterators.iterator() Message-ID: Sometimes, `Spliterator::forEachRemaining` has much more optimized implementation, compared to `Spliterator::tryAdvance`. For example, if a `Stream::spliterator` called for a stream that has intermediate operations, `tryAdvance()` may buffer intermediate elements while `forEachRemaining()` just delegates to the `wrapAndCopyInto` (see `StreamSpliterators.AbstractWrappingSpliterator` and its inheritors). `Spliterators::iterator` methods (used in particular by `Stream::iterator`) provide adapter iterators that delegate to the supplied spliterator. Unfortunately, they don't have a specialized implementation for `Iterator::forEachRemaining`. As a result, a default implementation is used that delegates to `hasNext`/`next`, which in turn causes the delegation to `tryAdvance`. It's quite simple to implement `Iterator::forEachRemaining` here, taking advantage of possible spliterator optimizations if the iterator client decides to use `forEachRemaining`. This patch implements Iterator::forEachRemaining in Spliterators::iterator methods. Also, I nullize the `nextElement` in `Iterator::next` to avoid accidental prolongation of the user's object lifetime when iteration is finished. Finally, a small cleanup: I added the `final` modifier where possible to private fields in `Spliterators`. Test-wise, some scenarios are already covered by SpliteratorTraversingAndSplittingTest. However, the resulting iterator is always wrapped into `Spliterators::spliterator`, so usage scenarios are somewhat limited. In particular, calling `hasNext` (without `next`) before `forEachRemaining` was not covered there. I added more tests in `IteratorFromSpliteratorTest` to cover these scenarios. I checked that removing `valueReady = false;` or `action.accept(t);` lines from newly implemented `forEachRemaining` method causes new tests to fail (but old tests don't fail due to this). ------------- Commit messages: - 8267452: Linebreaks fixed - 8267452: @bug tag - 8267452: Delegate forEachRemaining in Spliterators.iterator() Changes: https://git.openjdk.java.net/jdk/pull/4124/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4124&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267452 Stats: 178 lines in 2 files changed: 173 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4124.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4124/head:pull/4124 PR: https://git.openjdk.java.net/jdk/pull/4124 From redestad at openjdk.java.net Thu May 20 10:45:37 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 20 May 2021 10:45:37 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 16:38:03 GMT, ?????? ??????? wrote: >> Non-static classes hold a link to their parent classes, which in many cases can be avoided. > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8261880: Remove static from declarations of Holder nested classes Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2589 From avoitylov at openjdk.java.net Thu May 20 12:43:32 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Thu, 20 May 2021 12:43:32 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v3] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 16:29:33 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 library load operation. >> >> Problem being fixed: >> >> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. >> >> Proposed fix: >> >> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. >> >> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. >> >> Testing: jtreg and jck testing with no regressions. A new regression test was developed. > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > fix trailing whitespace Sorry, let me get back to this after I talk with the chalkboard. ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From mcimadamore at openjdk.java.net Thu May 20 13:05:55 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 20 May 2021 13:05:55 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v24] In-Reply-To: References: Message-ID: <0XX1uEuGfH11GkV08duVqk1u1vbP8IKAuZbf56JMKeY=.565f6565-3968-4f4f-ad10-de5dd6058e18@github.com> On Thu, 20 May 2021 13:00:15 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://openjdk.java.net/jeps/412 > > Maurizio Cimadamore 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 35 additional commits since the last revision: > > - Add sealed modifiers in morally sealed API interfaces > - Merge branch 'master' into JEP-412 > - Fix VaList test > Remove unused code in Utils > - Merge pull request #11 from JornVernee/JEP-412-MXCSR > > Add MXCSR save and restore to upcall stubs for non-windows platforms > - Add MXCSR save and restore to upcall stubs for non-windows platforms > - Merge branch 'master' into JEP-412 > - Fix issue with bounded arena allocator > - Rename is_entry_blob to is_optimized_entry_blob > Rename as_entry_blob to as_optimized_entry_blob > Fix misc typos and indentation issues > - Take care of remaining references to "Panama" > - * Replace is_panama_entry_frame() with is_optimized_entry_frame() > * Replace EntryBlob with OptimizedEntryBlob > - ... and 25 more: https://git.openjdk.java.net/jdk/compare/629f67e6...e927c235 src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java line 200: > 198: * Implementations of this interface are immutable, thread-safe and value-based. > 199: */ > 200: public sealed interface MemoryLayout extends Constable permits AbstractLayout, SequenceLayout, GroupLayout, PaddingLayout, ValueLayout { In principle we could just permit AbstractLayout and be done. In practice, the javadoc comes out better if we list all the concrete API interfaces which extend MemoryLayout, as the `permit` list will be displayed in the javadoc. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Thu May 20 13:05:22 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 20 May 2021 13:05:22 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v24] In-Reply-To: References: Message-ID: > 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://openjdk.java.net/jeps/412 Maurizio Cimadamore 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 35 additional commits since the last revision: - Add sealed modifiers in morally sealed API interfaces - Merge branch 'master' into JEP-412 - Fix VaList test Remove unused code in Utils - Merge pull request #11 from JornVernee/JEP-412-MXCSR Add MXCSR save and restore to upcall stubs for non-windows platforms - Add MXCSR save and restore to upcall stubs for non-windows platforms - Merge branch 'master' into JEP-412 - Fix issue with bounded arena allocator - Rename is_entry_blob to is_optimized_entry_blob Rename as_entry_blob to as_optimized_entry_blob Fix misc typos and indentation issues - Take care of remaining references to "Panama" - * Replace is_panama_entry_frame() with is_optimized_entry_frame() * Replace EntryBlob with OptimizedEntryBlob - ... and 25 more: https://git.openjdk.java.net/jdk/compare/788875f9...e927c235 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/f5668ffc..e927c235 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=23 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=22-23 Stats: 7087 lines in 360 files changed: 4302 ins; 1796 del; 989 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From github.com+10835776+stsypanov at openjdk.java.net Thu May 20 13:07:34 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 20 May 2021 13:07:34 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2] In-Reply-To: References: Message-ID: <-6K32RgKOwmXJztestBAA8OWC406eWVuqTRIjvfzcoQ=.59f5b0be-a1d9-48a8-89bd-5b7c51222bd7@github.com> On Thu, 20 May 2021 10:42:49 GMT, Claes Redestad wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8261880: Remove static from declarations of Holder nested classes > > Marked as reviewed by redestad (Reviewer). @cl4es now you can sponsor :) ------------- PR: https://git.openjdk.java.net/jdk/pull/2589 From mcimadamore at openjdk.java.net Thu May 20 13:12:09 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 20 May 2021 13:12:09 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v24] In-Reply-To: References: Message-ID: <9PaAroygCBAEwYmF4lNFzy46QKSPJsET65dXf6XQs18=.9059eafa-0dae-4a6c-ab12-461bb6456b92@github.com> On Thu, 20 May 2021 13:05:22 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://openjdk.java.net/jeps/412 > > Maurizio Cimadamore 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 35 additional commits since the last revision: > > - Add sealed modifiers in morally sealed API interfaces > - Merge branch 'master' into JEP-412 > - Fix VaList test > Remove unused code in Utils > - Merge pull request #11 from JornVernee/JEP-412-MXCSR > > Add MXCSR save and restore to upcall stubs for non-windows platforms > - Add MXCSR save and restore to upcall stubs for non-windows platforms > - Merge branch 'master' into JEP-412 > - Fix issue with bounded arena allocator > - Rename is_entry_blob to is_optimized_entry_blob > Rename as_entry_blob to as_optimized_entry_blob > Fix misc typos and indentation issues > - Take care of remaining references to "Panama" > - * Replace is_panama_entry_frame() with is_optimized_entry_frame() > * Replace EntryBlob with OptimizedEntryBlob > - ... and 25 more: https://git.openjdk.java.net/jdk/compare/354e6edf...e927c235 Latest javadoc: http://cr.openjdk.java.net/~mcimadamore/JEP-412/v3/javadoc/jdk/incubator/foreign/package-summary.html Latest specdiff: http://cr.openjdk.java.net/~mcimadamore/JEP-412/v3/specdiff/overview-summary.html ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From jvernee at openjdk.java.net Thu May 20 13:12:26 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 20 May 2021 13:12:26 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v24] In-Reply-To: <0XX1uEuGfH11GkV08duVqk1u1vbP8IKAuZbf56JMKeY=.565f6565-3968-4f4f-ad10-de5dd6058e18@github.com> References: <0XX1uEuGfH11GkV08duVqk1u1vbP8IKAuZbf56JMKeY=.565f6565-3968-4f4f-ad10-de5dd6058e18@github.com> Message-ID: On Thu, 20 May 2021 13:00:14 GMT, Maurizio Cimadamore wrote: >> Maurizio Cimadamore 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 35 additional commits since the last revision: >> >> - Add sealed modifiers in morally sealed API interfaces >> - Merge branch 'master' into JEP-412 >> - Fix VaList test >> Remove unused code in Utils >> - Merge pull request #11 from JornVernee/JEP-412-MXCSR >> >> Add MXCSR save and restore to upcall stubs for non-windows platforms >> - Add MXCSR save and restore to upcall stubs for non-windows platforms >> - Merge branch 'master' into JEP-412 >> - Fix issue with bounded arena allocator >> - Rename is_entry_blob to is_optimized_entry_blob >> Rename as_entry_blob to as_optimized_entry_blob >> Fix misc typos and indentation issues >> - Take care of remaining references to "Panama" >> - * Replace is_panama_entry_frame() with is_optimized_entry_frame() >> * Replace EntryBlob with OptimizedEntryBlob >> - ... and 25 more: https://git.openjdk.java.net/jdk/compare/26a8cf83...e927c235 > > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java line 200: > >> 198: * Implementations of this interface are immutable, thread-safe and value-based. >> 199: */ >> 200: public sealed interface MemoryLayout extends Constable permits AbstractLayout, SequenceLayout, GroupLayout, PaddingLayout, ValueLayout { > > In principle we could just permit AbstractLayout and be done. In practice, the javadoc comes out better if we list all the concrete API interfaces which extend MemoryLayout, as the `permit` list will be displayed in the javadoc. At least the internal class name is hidden in the javadoc: ![image](https://user-images.githubusercontent.com/5962029/118983890-37042080-b97d-11eb-9ee0-ae5d5db5cd7e.png) ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From github.com+1324414+desruisseaux at openjdk.java.net Thu May 20 13:18:36 2021 From: github.com+1324414+desruisseaux at openjdk.java.net (Martin Desruisseaux) Date: Thu, 20 May 2021 13:18:36 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 16:38:03 GMT, ?????? ??????? wrote: >> Non-static classes hold a link to their parent classes, which in many cases can be avoided. > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8261880: Remove static from declarations of Holder nested classes Just for information there is similar issues in `javax.imageio.metadata.IIOMetadataFormatImpl` class in the `java.desktop` module. ------------- PR: https://git.openjdk.java.net/jdk/pull/2589 From github.com+10835776+stsypanov at openjdk.java.net Thu May 20 13:59:41 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 20 May 2021 13:59:41 GMT Subject: Integrated: 8261880: Change nested classes in java.base to static nested classes where possible In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 14:30:58 GMT, ?????? ??????? wrote: > Non-static classes hold a link to their parent classes, which in many cases can be avoided. This pull request has now been integrated. Changeset: 9425d3de Author: Sergey Tsypanov Committer: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/9425d3de83fe8f4caddef03ffa3f4dd4de58f236 Stats: 15 lines in 11 files changed: 0 ins; 0 del; 15 mod 8261880: Change nested classes in java.base to static nested classes where possible Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/2589 From peter.levart at gmail.com Thu May 20 14:42:30 2021 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 20 May 2021 16:42:30 +0200 Subject: RFR: 8266310: deadlock while loading the JNI code [v2] In-Reply-To: References: <7uREVWzjGhgjYBdEpYZ5OBurn9FzSuu-TG9_xIu-syc=.c737c435-734e-4e79-9969-cf0d2147ac07@github.com> Message-ID: <1b1189d6-f340-9220-73f0-185411262a21@gmail.com> Hi Aleksei, Are you trying to solve this in principle or do you have a concrete problem at hand which triggers this deadlock? If it is the later, then some rearrangement of code might do the trick... For example, native libraries are typically loaded by a class initializer of some class that is guaranteed to be initialized before the 1st invocation of a native method from such library. But if such class can also be loaded and initialized by some other trigger, deadlock can occur. Best remedy for such situation is to move all native methods to a special class that serves just for interfacing with native code and also contains an initializer that loads the native library and nothing else. Such arrangement would ensure that the order of taking locks is always the same: classLoadingLock -> nativeLibraryLock ... Regards, Peter On 5/20/21 12:31 AM, David Holmes wrote: > On 20/05/2021 2:29 am, Aleksei Voitylov wrote: >> On Wed, 19 May 2021 16:21:41 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 library load operation. >>>> >>>> Problem being fixed: >>>> >>>> The initial reproducer demonstrated a deadlock between the >>>> JarFile/ZipFile and the hash map. That deadlock exists even when >>>> the ZipFile/JarFile lock is removed because there's another lock >>>> object in the class loader, associated with the name of the class >>>> being loaded. Such objects are stored in >>>> ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() >>>> loads exactly the same class, whose signature is being verified in >>>> another thread. >>>> >>>> Proposed fix: >>>> >>>> The proposed patch suggests to get rid of locking >>>> loadedLibraryNames hash map and synchronize on each entry name, as >>>> it's done with class names in see >>>> ClassLoader.getClassLoadingLock(name) method. >>>> >>>> The patch introduces nativeLibraryLockMap which holds the lock >>>> objects for each library name, and the getNativeLibraryLock() >>>> private method is used to lazily initialize the corresponding lock >>>> object. nativeLibraryContext was changed to ThreadLocal, so that in >>>> any concurrent thread it would have a NativeLibrary object on top >>>> of the stack, that's being currently loaded/unloaded in that >>>> thread. nativeLibraryLockMap accumulates the names of all native >>>> libraries loaded - in line with class loading code, it is not >>>> explicitly cleared. >>>> >>>> Testing:? jtreg and jck testing with no regressions. A new >>>> regression test was developed. >>> >>> Aleksei Voitylov has updated the pull request incrementally with one >>> additional commit since the last revision: >>> >>> ?? address review comments, add tests >> >> Dear colleagues, >> >> The updated PR addresses review comment regarding ThreadLocal as well >> as David' concern around the lock being held during >> JNI_OnLoad/JNI_OnUnload calls, and ensures all lock objects are >> deallocated. Multiple threads are allowed to enter >> NativeLibrary.load() to prevent any thread from locking while another >> thread loads a library. Before the update, there could be a class >> loading lock held by a parallel capable class loader, which can >> deadlock with the library loading lock. As proposed by David Holmes, >> the library loading lock was removed because dlopen/LoadLibrary are >> thread safe and they maintain internal reference counters on >> libraries. There's still a lock being held while a pair of containers >> are read/updated. It's not going to deadlock as there's no lock/wait >> operation performed while that lock is held. Multiple threads may >> create their own copies of NativeLibrary object and register it for >> auto unloading. >> >> Tests for auto unloading were added along with the PR update. There >> are now 3 jtreg tests: >> - one checks for deadlock, similar to the one proposed by Chris Hegarty >> - two other tests are for library unload. >> >> The major side effect of that multiple threads are allowed to enter >> is that JNI_OnLoad/JNI_OnUnload may be called multiple (but same) >> number of times from concurrent threads. In particular, the number of >> calls to JNI_OnLoad must be equal to the number of calls to >> JNI_OnUnload after the relevant class loader is garbage collected. >> This may affect the behaviour that relies on specific order or the >> number of JNI_OnLoad/JNI_OnUnload calls. The current JNI >> specification does not mandate how many times JNI_OnLoad/JNI_OnUnload >> are called. Also, we could not locate tests in jck/jtreg/vmTestbase >> that would rely on the specific order or number of calls to >> JNI_OnLoad/JNI_OnUnload. > > But you can't make such a change! That was my point. To fix the > deadlock we must not hold a lock. But we must ensure only a single > call to JNI_OnLoad is possible. It is an unsolvable problem with those > constraints. You can't just change the behaviour of JNI_OnLoad like that. > > David > ----- > If this is really a problem that several people are facing, then perhaps a change in the API could solve it. I'm thinking >> Thank you Alan Bateman, David Holmes and Chris Hegarty for your >> valuable input. >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/3976 >> From rriggs at openjdk.java.net Thu May 20 16:10:11 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 20 May 2021 16:10:11 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v3] In-Reply-To: References: Message-ID: <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com> > JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. > The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional > configuration mechanisms and filter utilities. > > javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: > http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Simplify factory interface to BinaryOperator and cleanup the example ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3996/files - new: https://git.openjdk.java.net/jdk/pull/3996/files/3ec309f3..f1c5cd85 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=01-02 Stats: 193 lines in 4 files changed: 135 ins; 9 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/3996.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3996/head:pull/3996 PR: https://git.openjdk.java.net/jdk/pull/3996 From asemenyuk at openjdk.java.net Thu May 20 16:19:28 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 20 May 2021 16:19:28 GMT Subject: RFR: 8267056: tools/jpackage/share/RuntimePackageTest.java fails with NoSuchFileException In-Reply-To: <3FZIYFgMcdRP9EWWHTLNbg-IM8B4Zt0LW4YtvhCIpqA=.e76ed78b-1591-446b-b4bc-29b4d6b00e11@github.com> References: <3FZIYFgMcdRP9EWWHTLNbg-IM8B4Zt0LW4YtvhCIpqA=.e76ed78b-1591-446b-b4bc-29b4d6b00e11@github.com> Message-ID: On Wed, 19 May 2021 21:00:07 GMT, Alexander Matveev wrote: > For debug build on macOS, runtime which used for test fill be located in /path/jdk-17/fastdebug and /path/jdk-17 will not contain any other files except fastdebug and in this case our check to decide if we need to copy app or runtime will return /path/jdk-17 which is not correct. Fixed by skipping this check for runtime and only using it for app. Also, added ignoring .DS_Store to test which is needed if user used Finder to look inside runtime folder which will cause .DS_Store to be created and will cause test to fail, since this file is not being packaged. Changes requested by asemenyuk (Reviewer). src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgBundler.java line 396: > 394: // if parent does not have any other files > 395: if (!StandardBundlerParam.isRuntimeInstaller(params)) { > 396: Path[] list = Files.list(rootDir).toArray(Path[]::new); `Files.list()` requires try-with-resources construct. ------------- PR: https://git.openjdk.java.net/jdk/pull/4120 From github.com+42899633+eastig at openjdk.java.net Thu May 20 16:22:26 2021 From: github.com+42899633+eastig at openjdk.java.net (Evgeny Astigeevich) Date: Thu, 20 May 2021 16:22:26 GMT Subject: RFR: 8246677: LinkedTransferQueue and SynchronousQueue synchronization updates [v2] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 05:54:24 GMT, Martin Buchholz wrote: >> 8246677: LinkedTransferQueue and SynchronousQueue synchronization updates > > Martin Buchholz has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. This PR causes 16x performance regression in SynchronousQueue. Details are in https://bugs.openjdk.java.net/browse/JDK-8267502 ------------- PR: https://git.openjdk.java.net/jdk/pull/1645 From darcy at openjdk.java.net Thu May 20 17:26:15 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 20 May 2021 17:26:15 GMT Subject: RFR: 8224243: Make AccessibleObject a sealed class Message-ID: <4DFE3N_LB1D0jraDzmAmhGpzPGZAZrluVqCM5LFo5B4=.bbe76387-44f8-44de-ae2a-ce89d823041b@github.com> Conceptually, AccessbileObject is a sealed class with a protected constructor stating Constructor: only used by the Java Virtual Machine. With the language now supporting sealed classes, the AccessbileObject should be marked as sealed. Executable and Field are the subclasses of AccessbileObject in the JDK; as Executable has subclasses, it is marked as non-sealed. Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8224243 ------------- Commit messages: - 8224243: Make AccessibleObject a sealed class Changes: https://git.openjdk.java.net/jdk/pull/4133/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4133&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8224243 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4133.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4133/head:pull/4133 PR: https://git.openjdk.java.net/jdk/pull/4133 From alanb at openjdk.java.net Thu May 20 17:34:35 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 20 May 2021 17:34:35 GMT Subject: RFR: 8224243: Make AccessibleObject a sealed class In-Reply-To: <4DFE3N_LB1D0jraDzmAmhGpzPGZAZrluVqCM5LFo5B4=.bbe76387-44f8-44de-ae2a-ce89d823041b@github.com> References: <4DFE3N_LB1D0jraDzmAmhGpzPGZAZrluVqCM5LFo5B4=.bbe76387-44f8-44de-ae2a-ce89d823041b@github.com> Message-ID: On Thu, 20 May 2021 17:14:57 GMT, Joe Darcy wrote: > Conceptually, AccessbileObject is a sealed class with a protected constructor stating > > Constructor: only used by the Java Virtual Machine. > > With the language now supporting sealed classes, the AccessbileObject should be marked as sealed. > > Executable and Field are the subclasses of AccessbileObject in the JDK; as Executable has subclasses, it is marked as non-sealed. > > Please also review the corresponding CSR: > > https://bugs.openjdk.java.net/browse/JDK-8224243 I think this will require reaching out to Google Guava, I think its their Invocable API that extends AccessibleObject outside of the JDK. We ran this when doing the module system where we didn't initially take into account sub-classes that were outside of java.base. ------------- PR: https://git.openjdk.java.net/jdk/pull/4133 From alanb at openjdk.java.net Thu May 20 17:45:45 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 20 May 2021 17:45:45 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v24] In-Reply-To: References: <6SevcbQtVmLuygupdqgGyTXI943L_DitH0AK5r-Ou40=.d2ea73a1-0f30-46f2-b2d6-8f59db9b8a83@github.com> Message-ID: <8LA0NkO48Sxqf8ITGs8HWtyQhcr5oK5sbMBcYYOZCe0=.5c378205-caed-467e-9dc3-999b5dd54b05@github.com> On Wed, 28 Apr 2021 08:20:05 GMT, Chris Hegarty wrote: >> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 466: >> >>> 464: } >>> 465: >>> 466: private static final JavaNioAccess NIO_ACCESS = SharedSecrets.getJavaNioAccess(); >> >> It might be cleaner to move to acquire/release methods to their own supporting class as it's not really IOUtil. > > I went back and forth on this a number of times already. I think where we landed is a reasonable place, given the current shape of the code. > > Scope is a private property of Buffer, and as such should be consulted anywhere where a buffer's address is being accessed. In fact, a prior prototype would not allow access to the underlying address value without the caller passing a valid handle for the buffer view's scope. It's hard to find the sweet-spot here between code reuse and safety, but the high-order bit is that the code accessing the address is auditable and testable to avoid accessing memory unsafely. Maybe there is a better alternative implementation code structure (at the cost of some duplication), but it is not obvious to me what that is (and I have given it some thought). Suggestions welcome. > > Note, there is a little more follow-on work to be done in this area, if we are to expand support to other non-TCP channel implementations. Maybe investigation into possible code refactorings could be done as part of that? Can you create a follow-on issue to re-visit the changes to IOUtil? The changes in this area that are in this PR will need to re-worked so that it more cleanly separate the synchronous and asynchronous usages. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From dfuchs at openjdk.java.net Thu May 20 17:59:29 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 20 May 2021 17:59:29 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v3] In-Reply-To: <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com> References: <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com> Message-ID: <8XsgRyElekStT0QurGdkx3t7CMmgA4WbYVqd-dHg35w=.d47a3d8b-b20f-45d0-87f2-abc1ffd7bc68@github.com> On Thu, 20 May 2021 16:10:11 GMT, Roger Riggs wrote: >> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. >> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional >> configuration mechanisms and filter utilities. >> >> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: >> http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Simplify factory interface to BinaryOperator and cleanup the example src/java.base/share/classes/java/io/ObjectInputFilter.java line 197: > 195: * } > 196: * } > 197: *

Using the Filter Factory

Should this be rather a subsection of the example above? Otherwise it gives the impression that the `doWithSerialFilter` method is provided or invoked by the JDK. src/java.base/share/classes/java/io/ObjectInputFilter.java line 263: > 261: /** > 262: * Returns a filter, that when applied to this filter that is checking a class, maps > 263: * {@code Status.UNDECIDED} to {@code Status.REJECTED}, otherwise returns the status of the other filter. Which `other filter` is that? Shouldn't that be `..., otherwise returns the status of this filter.` src/java.base/share/classes/java/io/ObjectInputFilter.java line 265: > 263: * {@code Status.UNDECIDED} to {@code Status.REJECTED}, otherwise returns the status of the other filter. > 264: * Object serialization accepts a class if the filter returns {@code UNDECIDED}. > 265: * Appending a filter to reject undecided results for classes that have not been Could this be rephrased? I am not sure what "Appending" means in this context: more specifically appending to what? Maybe there's a way to describe that in terms of "Mapping" rather than "Appending"? src/java.base/share/classes/java/io/ObjectInputFilter.java line 364: > 362: /** > 363: * A utility class to set and get the JVM-wide deserialization filter factory, > 364: * the static JVM-wide filter, or to create a filter from a pattern string. FWIW: In other APIs we talk of `system-wide` rather than `JVM-wide`. src/java.base/share/classes/java/io/ObjectInputFilter.java line 371: > 369: * When each {@link ObjectInputStream#ObjectInputStream() ObjectInputStream} > 370: * is created the {@linkplain Config#getSerialFilterFactory() filter factory} > 371: * is invoked to determine the initial filter for the stream. A stream-specific filter can be set with Maybe the concept of system-wide filter should be introduced first, then you could say that the factory is invoked with `null` as first parameter and the system-wide filter as second parameter when the `ObjectInputStream` is created. Then the next paragraph could expand on what happens when `setObjectInputFilter` is called. ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From thihup at gmail.com Thu May 20 18:32:49 2021 From: thihup at gmail.com (Thiago Henrique Hupner) Date: Thu, 20 May 2021 15:32:49 -0300 Subject: Make java.lang.constant.ConstantDesc selead Message-ID: Now that Sealed classes are integrated, should be the moment to seal the ConstantDesc class and its subclasses, or would be better to wait a little bit more? Best regards Thiago From kcr at openjdk.java.net Thu May 20 18:31:33 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 20 May 2021 18:31:33 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: <58-JOVfSiUl3xFtcjGhwaviPqV-amDLlusvj_yCwmj8=.6d3bbada-4a59-443a-9940-121606b64a71@github.com> On Wed, 19 May 2021 13:47:53 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java This isn't a review of the code changes, although I did take a quick look at the manual changes, and they look fine. I did a local build of the PR branch on Windows, Mac, and Linux, and then did a build / test of JavaFX using that locally built JDK to find all the places where I need to add `-Djava.security.manager=allow` to the JavaFX tests to fix [JDK-8264140](https://bugs.openjdk.java.net/browse/JDK-8264140). It's working as expected. ------------- Marked as reviewed by kcr (Author). PR: https://git.openjdk.java.net/jdk/pull/4073 From mandy.chung at oracle.com Thu May 20 18:43:26 2021 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 20 May 2021 11:43:26 -0700 Subject: Suppressed IllegalAccessException in MethodHandle.setVarargs In-Reply-To: References: Message-ID: <4e89c1b0-2b43-9f27-4939-7af89974501d@oracle.com> 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 locate a MethodHandle for a varargs method who's final parameter is not an array an IllegalArgumentException will be thrown: > >> java.lang.IllegalArgumentException: not an array type: int >> ???? at java.base/java.lang.invoke.MethodHandleStatics.newIllegalArgumentException(MethodHandleStatics.java:138) >> ???? at java.base/java.lang.invoke.MethodHandle.spreadArrayChecks(MethodHandle.java:1066) >> ???? at java.base/java.lang.invoke.MethodHandle.asCollectorChecks(MethodHandle.java:1259) >> ???? at java.base/java.lang.invoke.MethodHandle.asVarargsCollector(MethodHandle.java:1427) >> ???? at java.base/java.lang.invoke.MethodHandle.withVarargs(MethodHandle.java:1111) >> ???? at java.base/java.lang.invoke.MethodHandle.setVarargs(MethodHandle.java:1634) >> ?? ? at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:3755) >> ???? at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethod(MethodHandles.java:3691) >> ???? at java.base/java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:2399) > This makes sense, however it seems that the exception is swallowed and instead a generic IllegalAccessException is thrown: > >> Caused by: java.lang.IllegalAccessException: cannot make variable arity: package.Class.method(Object[],int)Object/invokeStatic >> at java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:957) >> at java.base/java.lang.invoke.MethodHandle.setVarargs(MethodHandle.java:1636) >> at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:3755) >> at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethod(MethodHandles.java:3691) >> at java.base/java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:2399) > It would probably be helpful to make the IllegalAccessException caused by the IllegalArgumentException, or at the very least add it as a suppressed exception. > Otherwise the only way to find the helpful exception here is through runtime debugging. > > Relevant code: https://github.com/openjdk/jdk/blob/7b98400c81900a8c779394d549b5fb61f1dd8638/src/java.base/share/classes/java/lang/invoke/MethodHandle.java#L1635 > > Thanks, > x4e From dfuchs at openjdk.java.net Thu May 20 19:14:31 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 20 May 2021 19:14:31 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v3] In-Reply-To: <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com> References: <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com> Message-ID: On Thu, 20 May 2021 16:10:11 GMT, Roger Riggs wrote: >> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. >> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional >> configuration mechanisms and filter utilities. >> >> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: >> http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Simplify factory interface to BinaryOperator and cleanup the example src/java.base/share/classes/java/io/ObjectInputFilter.java line 410: > 408: * The class must have a public zero-argument constructor, implement the > 409: * {@link BinaryOperator} interface, > 410: * and provide its implementation. I wonder if some more explanation is needed to explain how the filter factory class is located. I mean - I expect it will be looked up using the System ClassLoader - doesn't this need to be specified? Or if it's already specified elsewhere then maybe a link should be provided? Maybe the spec should also say that the class should be public. And I guess that if it is in another module then it should be in an exported package - or possibly in a package opened to reflection? Or does this only work if the class is in the unnamed module (deployed on the classpath)? src/java.base/share/classes/java/io/ObjectInputFilter.java line 431: > 429: * Used as a system property and a java.security.Security property. > 430: */ > 431: private final static String SERIAL_FILTER_PROPNAME = "jdk.serialFilter"; should be `private static final` (in canonical order). src/java.base/share/classes/java/io/ObjectInputFilter.java line 589: > 587: /** > 588: * Returns the JVM-wide deserialization filter factory. > 589: * If the filter factory has been {@link #setSerialFilterFactory(BinaryOperator) set} it is returned, Should be `{@linkplain ...}` src/java.base/share/classes/java/io/ObjectInputFilter.java line 592: > 590: * otherwise, a builtin deserialization filter factory is returned. > 591: * The filter factory provides a filter for every ObjectInputStream when invoked from > 592: * {@link ObjectInputStream#ObjectInputStream(InputStream) ObjectInputStream constructors} Should be {@linkplain ...} src/java.base/share/classes/java/io/ObjectInputFilter.java line 601: > 599: * {@link ObjectInputStream#ObjectInputStream(InputStream) ObjectInputStream constructors}. > 600: * When invoked {@link ObjectInputStream#setObjectInputFilter(ObjectInputFilter) > 601: * to set the stream-specific filter} the requested filter replaces the static JVM-wide filter, These three should be {@linkplain ...} too. src/java.base/share/classes/java/io/ObjectInputFilter.java line 603: > 601: * to set the stream-specific filter} the requested filter replaces the static JVM-wide filter, > 602: * unless it has already been set. The stream-specific filter can only be set once, > 603: * if it has already been set, an {@link IllegalStateException} is thrown. I am assuming the `IllegalStateException` exception is thrown by `ObjecInputStream::setObjectInputFilter` - maybe that should be clarified here. src/java.base/share/classes/java/io/ObjectInputFilter.java line 609: > 607: * > 608: * @return the JVM-wide deserialization filter factory; non-null > 609: * @since TBD Need to replace TBD before pushing ;-) src/java.base/share/classes/java/io/ObjectInputFilter.java line 632: > 630: * The factory determines the filter to be used for {@code ObjectInputStream} streams based > 631: * on its inputs, and any other filters, context, or state that is available. > 632: * The factory may throw runtime exceptions to signal incorrect use or invalid parameters. What happens if the factory throws an exception? src/java.base/share/classes/java/io/ObjectInputFilter.java line 639: > 637: * @throws SecurityException if there is security manager and the > 638: * {@code SerializablePermission("serialFilter")} is not granted > 639: * @since TBD ... TBD ... src/java.base/share/classes/java/io/ObjectInputFilter.java line 756: > 754: * 

> 755:          *     ObjectInputFilter f = allowFilter(cl -> cl.getClassLoader() == ClassLoader.getPlatformClassLoader()
> 756:          *                                          || cl.getClassLoader() == null);

The example here seems to be missing the `otherStatus` parameter.

src/java.base/share/classes/java/io/ObjectInputFilter.java line 785:

> 783:          * 

> 784:          *     ObjectInputFilter f = rejectFilter(cl -> cl.getClassLoader() == ClassLoader.ClassLoader.getSystemClassLoader());
> 785:          * 


Same here, the example is missing the `otherStatus` parameter.

src/java.base/share/classes/java/io/ObjectInputFilter.java line 830:

> 828:          *
> 829:          */
> 830:         final static class Global implements ObjectInputFilter {

IIRC the canonical order is `static final` not `final static`.

src/java.base/share/classes/java/io/ObjectInputFilter.java line 1079:

> 1077:                 }
> 1078:                 // There are no classes to check and none of the limits have been exceeded.
> 1079:                 return Status.ALLOWED;

Should this be addressed outside of this JEP and pushed separately?

src/java.base/share/classes/java/io/ObjectInputFilter.java line 1127:

> 1125:             public ObjectInputFilter.Status checkInput(FilterInfo info) {
> 1126:                 return (info.serialClass() != null &&
> 1127:                         predicate.test(info.serialClass())) ? ifTrueStatus : ifFalseStatus;

Maybe the result of info.serialClass() should be stored in a local var to avoid calling the method twice.

src/java.base/share/classes/java/io/ObjectInputFilter.java line 1139:

> 1137:          * and not classes.
> 1138:          */
> 1139:         private static class AllowMaxLimitsFilter implements ObjectInputFilter {

This class is maybe misnamed. If limitCheck == REJECTED it will not allow max limits. Or am I missing something?

src/java.base/share/classes/java/io/ObjectInputFilter.java line 1238:

> 1236:          * {@link #getSerialFilter static serial filter} when invoked from
> 1237:          * {@link ObjectInputStream#ObjectInputStream(InputStream) ObjectInputStream constructors}.
> 1238:          * When invoked from {@link ObjectInputStream#setObjectInputFilter(ObjectInputFilter)

These three links should be {@linkplain ...}

src/java.base/share/classes/java/io/ObjectInputFilter.java line 1270:

> 1268:              *       is not {@code null} and is not the JVM-wide filter
> 1269:              * @throws SecurityException if there is security manager and the
> 1270:              *       {@code SerializablePermission("serialFilter")} is not granted

Where is this thrown? I don't see it in the implementation of `apply` below.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From dfuchs at openjdk.java.net  Thu May 20 19:52:32 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 20 May 2021 19:52:32 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
Message-ID: 

On Thu, 20 May 2021 16:10:11 GMT, Roger Riggs  wrote:

>> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
>> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
>> configuration mechanisms and filter utilities.
>> 
>> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`:
>>     http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify factory interface to BinaryOperator and cleanup the example

src/java.base/share/classes/java/io/ObjectInputStream.java line 201:

> 199:  *     when a filter is set for a stream.
> 200:  *     The filter factory determines the filter to be used for each stream based
> 201:  *     on its inputs, thread context, other filters, or state that is available.

Maybe a link to the ObjectInputFilter API documentation where it is explained what the two filters passed to the factory are in each of these cases should be provided here.

Namely: 

- in the constructor, `factory.apply(null, Config.getSerialFilter())` is invoked.
- in `setObjectInputFilter(newfilter)`, `factory.apply(filter, newFilter)` is invoked - where `filter` is the filter that the stream is currently using.

Or maybe link to the constructor and setObjectInputFilter method where this is explained.

src/java.base/share/classes/java/io/ObjectInputStream.java line 204:

> 202:  * 
  • If a JVM-wide filter factory is not set, a builtin deserialization filter factory
> 203:  *     provides the {@link Config#getSerialFilter static JVM-wide filter} when invoked from the
> 204:  *     {@link ObjectInputStream#ObjectInputStream(InputStream) ObjectInputStream constructors}

These two links should be `{@linkplain ...}`

src/java.base/share/classes/java/io/ObjectInputStream.java line 1255:

> 1253:      * Returns the serialization filter for this stream.
> 1254:      * The filter is the result of invoking the
> 1255:      * {@link Config#getSerialFilterFactory() JVM-wide filter factory}

`{@linkplain }`

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From rriggs at openjdk.java.net  Thu May 20 20:05:56 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 20 May 2021 20:05:56 GMT
Subject: RFR: 8191441: (Process) add Readers and Writer access to
 java.lang.Process streams
Message-ID: 

Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process.
The Charset used to encode and decode characters to bytes can be specified or use the
operating system native encoding as is available from the "native.encoding" system property.

-------------

Commit messages:
 - 8191441: (Process) add Readers and Writer access to java.lang.Process streams

Changes: https://git.openjdk.java.net/jdk/pull/4134/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4134&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8191441
  Stats: 416 lines in 2 files changed: 412 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4134.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4134/head:pull/4134

PR: https://git.openjdk.java.net/jdk/pull/4134

From forax at openjdk.java.net  Thu May 20 20:15:26 2021
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 20 May 2021 20:15:26 GMT
Subject: RFR: 8191441: (Process) add Readers and Writer access to
 java.lang.Process streams
In-Reply-To: 
References: 
Message-ID: 

On Thu, 20 May 2021 19:57:22 GMT, Roger Riggs  wrote:

> Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process.
> The Charset used to encode and decode characters to bytes can be specified or use the
> operating system native encoding as is available from the "native.encoding" system property.

I've added the same comment on the bug itself.
I don't think that using PrintWriter is a good idea here given that a PrintWriter shallow the IOException

-------------

PR: https://git.openjdk.java.net/jdk/pull/4134

From rriggs at openjdk.java.net  Thu May 20 20:40:30 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 20 May 2021 20:40:30 GMT
Subject: RFR: 8191441: (Process) add Readers and Writer access to
 java.lang.Process streams
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 20 May 2021 20:12:07 GMT, R?mi Forax  wrote:

> I don't think that using PrintWriter is a good idea here given that a PrintWriter shallow the IOException

Good point, but...

PrintStream does also and it is used frequently for Stdout and Stderr. 

OutputStreamWriter would be a better choice with that in mind. It does not have the convenience methods for converting various types to strings but would not hide the exceptions. Developers could wrap it in a PrintWriter to get the convenience and take on the responsibility of dealing with exceptions by polling.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4134

From naoto at openjdk.java.net  Thu May 20 20:50:30 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 20 May 2021 20:50:30 GMT
Subject: RFR: 8191441: (Process) add Readers and Writer access to
 java.lang.Process streams
In-Reply-To: 
References: 
Message-ID: 

On Thu, 20 May 2021 19:57:22 GMT, Roger Riggs  wrote:

> Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process.
> The Charset used to encode and decode characters to bytes can be specified or use the
> operating system native encoding as is available from the "native.encoding" system property.

Good to see `native.encoding` is utilized. Some comments follow.

src/java.base/share/classes/java/lang/Process.java line 25:

> 23:  * questions.
> 24:  */
> 25: 

Copyright year -> 2021

src/java.base/share/classes/java/lang/Process.java line 181:

> 179:      * @return a {@link BufferedReader BufferedReader} using the {@code native.encoding} if supported,
> 180:      *          otherwise, the {@link Charset#defaultCharset()}
> 181:      */

`@since 17` is needed (and for other public methods)

src/java.base/share/classes/java/lang/Process.java line 771:

> 769: 
> 770:         /**
> 771:          * {@return Charset for the native encoding or {@link Charset#defaultCharset()}

Need some edit here?

test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java line 64:

> 62:         return new Object[][] {
> 63:                 {"UTF-8"},
> 64:                 {"ISO8859-1"},

`ISO8859-1` may not be available on all underlying OSes.

test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java line 111:

> 109:     @Test(dataProvider = "CharsetCases", enabled = true)
> 110:     void testCase(String nativeEncoding) throws IOException {
> 111:         String osName = System.getProperty("os.name").toLowerCase(Locale.ROOT);

Not used anywhere else.

test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java line 122:

> 120:                 "ReaderWriterTest$ChildWithCharset");
> 121:         var env = pb.environment();
> 122:         env.put("LANG", "en_US." + cleanCSName);

Does this work on Windows?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4134

From rriggs at openjdk.java.net  Thu May 20 20:50:32 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 20 May 2021 20:50:32 GMT
Subject: RFR: 8191441: (Process) add Readers and Writer access to
 java.lang.Process streams
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 20 May 2021 20:42:35 GMT, Naoto Sato  wrote:

>> Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process.
>> The Charset used to encode and decode characters to bytes can be specified or use the
>> operating system native encoding as is available from the "native.encoding" system property.
>
> test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java line 64:
> 
>> 62:         return new Object[][] {
>> 63:                 {"UTF-8"},
>> 64:                 {"ISO8859-1"},
> 
> `ISO8859-1` may not be available on all underlying OSes.

Is there a safe subset?
I haven't seen a failure yet, if/when it occurs, we make an exception or narrow the test to known systems.

> test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java line 111:
> 
>> 109:     @Test(dataProvider = "CharsetCases", enabled = true)
>> 110:     void testCase(String nativeEncoding) throws IOException {
>> 111:         String osName = System.getProperty("os.name").toLowerCase(Locale.ROOT);
> 
> Not used anywhere else.

Right, dead code now without host dependencies.

> test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java line 122:
> 
>> 120:                 "ReaderWriterTest$ChildWithCharset");
>> 121:         var env = pb.environment();
>> 122:         env.put("LANG", "en_US." + cleanCSName);
> 
> Does this work on Windows?

Should be removed, the tests work because they set sun.stdout/stderr.encoding.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4134

From naoto at openjdk.java.net  Thu May 20 21:05:28 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 20 May 2021 21:05:28 GMT
Subject: RFR: 8191441: (Process) add Readers and Writer access to
 java.lang.Process streams
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 20 May 2021 20:46:36 GMT, Roger Riggs  wrote:

>> test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java line 64:
>> 
>>> 62:         return new Object[][] {
>>> 63:                 {"UTF-8"},
>>> 64:                 {"ISO8859-1"},
>> 
>> `ISO8859-1` may not be available on all underlying OSes.
>
> Is there a safe subset?
> I haven't seen a failure yet, if/when it occurs, we make an exception or narrow the test to known systems.

Lucky you :-)
I wasn't so lucky that I got an intermittent issue (https://bugs.openjdk.java.net/browse/JDK-8265918), where it only fails if the test is run on an Ubuntu CI test machine. It's not only depending on Linux distros, but on the user's configuration (minimal install or full, etc.), so I don't think there is any safe subset.
That said, the test code uses those encoding names as `sun.stdout/err.encoding` properties values, not setting the real native encoding, so the test should be fine. Only the argument name in the test (`nativeEncoding`) is a bit confusing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4134

From gbierman at openjdk.java.net  Thu May 20 21:17:49 2021
From: gbierman at openjdk.java.net (Gavin Bierman)
Date: Thu, 20 May 2021 21:17:49 GMT
Subject: RFR: 8265130: Make ConstantDesc class hierarchy sealed
Message-ID: 

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

-------------

Commit messages:
 - 8265130: Make ConstantDesc class hierarchy sealed

Changes: https://git.openjdk.java.net/jdk/pull/4135/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4135&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265130
  Stats: 25 lines in 6 files changed: 16 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4135/head:pull/4135

PR: https://git.openjdk.java.net/jdk/pull/4135

From psandoz at openjdk.java.net  Thu May 20 21:19:31 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 20 May 2021 21:19:31 GMT
Subject: RFR: 8267190: Optimize Vector API test operations [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 20 May 2021 01:27:48 GMT, Sandhya Viswanathan  wrote:

>> Vector API test operations (IS_DEFAULT, IS_FINITE, IS_INFINITE, IS_NAN and IS_NEGATIVE) are computed in three steps:
>> 1) reinterpreting the floating point vectors as integral vectors (int/long)
>> 2) perform the test in integer domain to get a int/long mask
>> 3) reinterpret the int/long mask as float/double mask
>> Step 3) currently is very slow. It can be optimized by modifying the Java code to utilize the existing reinterpret intrinsic.
>> 
>> For the VectorTestPerf attached to the JBS for JDK-8267190, the performance improves as follows:
>> 
>> Base:
>> Benchmark (size) Mode Cnt Score Error Units
>> VectorTestPerf.IS_DEFAULT 1024 thrpt 5 223.156 ? 90.452 ops/ms
>> VectorTestPerf.IS_FINITE 1024 thrpt 5 223.841 ? 91.685 ops/ms
>> VectorTestPerf.IS_INFINITE 1024 thrpt 5 224.561 ? 83.890 ops/ms
>> VectorTestPerf.IS_NAN 1024 thrpt 5 223.777 ? 70.629 ops/ms
>> VectorTestPerf.IS_NEGATIVE 1024 thrpt 5 218.392 ? 79.806 ops/ms
>> 
>> With patch:
>> Benchmark (size) Mode Cnt Score Error Units
>> VectorTestPerf.IS_DEFAULT 1024 thrpt 5 8812.357 ? 40.477 ops/ms
>> VectorTestPerf.IS_FINITE 1024 thrpt 5 7425.739 ? 296.622 ops/ms
>> VectorTestPerf.IS_INFINITE 1024 thrpt 5 8932.730 ? 269.988 ops/ms
>> VectorTestPerf.IS_NAN 1024 thrpt 5 8574.872 ? 498.649 ops/ms
>> VectorTestPerf.IS_NEGATIVE 1024 thrpt 5 8838.400 ? 11.849 ops/ms
>> 
>> Best Regards,
>> Sandhya
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement Paul's review comments

Java changes are good, some minor comments if you choose to accept them, no need for me to review further.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template line 852:

> 850:         private final 
> 851:         VectorMask defaultMaskCast(AbstractSpecies dsp) {
> 852:             boolean[] maskArray = toArray();

Can you add an `assert length() != species.laneCount()`?

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template line 854:

> 852:             boolean[] maskArray = toArray();
> 853:             // enum-switches don't optimize properly JDK-8161245
> 854:             return (

Minor syntactic quibble: you don't need the '(` and `)` surrounding the switch expressions e.g.:

   return switch (dsp.laneType.switchKey) {
       case ...
   }

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4039

From ecki at zusammenkunft.net  Thu May 20 21:30:39 2021
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 20 May 2021 21:30:39 +0000
Subject: RFR: 8191441: (Process) add Readers and Writer access to
 java.lang.Process streams
In-Reply-To: 
References: 
 ,
 
Message-ID: 

Hello,

Hm, how is that list used? - StandardCharaet.ISO_8859_1 is a guaranteed Charset for JVM, and since the encoding is done in Java it should be fine. Added benefit is, it?s 8bit transparent.

As for OS there is not a single standard charset (ebcdic vs latin families) but ASCII is probably the widest available (with latin1 variants to follow)


--
https://Bernd.eckenfels.net
________________________________
From: core-libs-dev  on behalf of Roger Riggs 
Sent: Thursday, May 20, 2021 10:52 PM
To: core-libs-dev at openjdk.java.net
Subject: Re: RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams

On Thu, 20 May 2021 20:42:35 GMT, Naoto Sato  wrote:

>> Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process.
>> The Charset used to encode and decode characters to bytes can be specified or use the
>> operating system native encoding as is available from the "native.encoding" system property.
>
> test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java line 64:
>
>> 62:         return new Object[][] {
>> 63:                 {"UTF-8"},
>> 64:                 {"ISO8859-1"},
>
> `ISO8859-1` may not be available on all underlying OSes.

Is there a safe subset?
I haven't seen a failure yet, if/when it occurs, we make an exception or narrow the test to known systems.

> test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java line 111:
>
>> 109:     @Test(dataProvider = "CharsetCases", enabled = true)
>> 110:     void testCase(String nativeEncoding) throws IOException {
>> 111:         String osName = System.getProperty("os.name").toLowerCase(Locale.ROOT);
>
> Not used anywhere else.

Right, dead code now without host dependencies.

> test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java line 122:
>
>> 120:                 "ReaderWriterTest$ChildWithCharset");
>> 121:         var env = pb.environment();
>> 122:         env.put("LANG", "en_US." + cleanCSName);
>
> Does this work on Windows?

Should be removed, the tests work because they set sun.stdout/stderr.encoding.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4134

From gbierman at openjdk.java.net  Thu May 20 21:32:05 2021
From: gbierman at openjdk.java.net (Gavin Bierman)
Date: Thu, 20 May 2021 21:32:05 GMT
Subject: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v2]
In-Reply-To: 
References: 
Message-ID: 

> 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 request incrementally with one additional commit since the last revision:

  Removing javadoc comments about future use of sealed

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4135/files
  - new: https://git.openjdk.java.net/jdk/pull/4135/files/8084e90b..1cd54624

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4135&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4135&range=00-01

  Stats: 131 lines in 6 files changed: 102 ins; 29 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4135/head:pull/4135

PR: https://git.openjdk.java.net/jdk/pull/4135

From mchung at openjdk.java.net  Thu May 20 21:35:35 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 20 May 2021 21:35:35 GMT
Subject: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v2]
In-Reply-To: 
References: 
 
Message-ID: 

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 request incrementally with one additional commit since the last revision:
> 
>   Removing javadoc comments about future use of sealed

Looks like `constants.patch` is accidentally added in this commit.  That should be removed.

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-sealed?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4135

From emcmanus at google.com  Thu May 20 21:59:26 2021
From: emcmanus at google.com (=?UTF-8?Q?=C3=89amonn_McManus?=)
Date: Thu, 20 May 2021 14:59:26 -0700
Subject: RFR: 8224243: Make AccessibleObject a sealed class
In-Reply-To: 
References: <4DFE3N_LB1D0jraDzmAmhGpzPGZAZrluVqCM5LFo5B4=.bbe76387-44f8-44de-ae2a-ce89d823041b@github.com>
 
Message-ID: 

Thanks for the tip, Alan. Guava's public Invokable

class does inherit from AccessibleObject. It would probably not be too hard
to make it stop doing so. That's technically a breaking API change, but the
class is marked @Beta so that's fair game.

I looked in Google's code base and I found one other project that extends
AccessibleObject, picocli, here
.
That's not to say that nobody else does it, but apparently cases are rare.

I do wonder what the purpose of the change would be. The constructor
javadoc text doesn't say you *can't* extend this class. Is there some
benefit from making it not work anymore?

On Thu, 20 May 2021 at 10:36, Alan Bateman  wrote:

> On Thu, 20 May 2021 17:14:57 GMT, Joe Darcy  wrote:
>
> > Conceptually, AccessbileObject is a sealed class with a protected
> constructor stating
> >
> >     Constructor: only used by the Java Virtual Machine.
> >
> > With the language now supporting sealed classes, the AccessbileObject
> should be marked as sealed.
> >
> > Executable and Field are the subclasses of AccessbileObject in the JDK;
> as Executable has subclasses, it is marked as non-sealed.
> >
> > Please also review the corresponding CSR:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8224243
>
> I think this will require reaching out to Google Guava, I think its their
> Invocable API that extends AccessibleObject outside of the JDK. We ran this
> when doing the module system where we didn't initially take into account
> sub-classes that were outside of java.base.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/4133
>

From gbierman at openjdk.java.net  Thu May 20 22:13:51 2021
From: gbierman at openjdk.java.net (Gavin Bierman)
Date: Thu, 20 May 2021 22:13:51 GMT
Subject: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v3]
In-Reply-To: 
References: 
Message-ID: <-Wla9ZYDbnQ8UfTAq4x-rvK6kj3elKri-6LbvR9udOI=.68ae6dab-7758-401d-8a44-9d4ed26bf51a@github.com>

> 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 request incrementally with one additional commit since the last revision:

  Removing file constants.patch added by mistake

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4135/files
  - new: https://git.openjdk.java.net/jdk/pull/4135/files/1cd54624..c8f632f6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4135&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4135&range=01-02

  Stats: 102 lines in 1 file changed: 0 ins; 102 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4135/head:pull/4135

PR: https://git.openjdk.java.net/jdk/pull/4135

From gbierman at openjdk.java.net  Thu May 20 22:19:42 2021
From: gbierman at openjdk.java.net (Gavin Bierman)
Date: Thu, 20 May 2021 22:19:42 GMT
Subject: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 20 May 2021 21:32:08 GMT, Mandy Chung  wrote:

>> Gavin Bierman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing javadoc comments about future use of sealed
>
> 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-sealed?

It's a permitted subclass of ConstantDesc, so it must be either `final`, `sealed`, or `non-sealed`. Making it `non-sealed` means it can still be extended.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4135

From almatvee at openjdk.java.net  Thu May 20 22:25:10 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 20 May 2021 22:25:10 GMT
Subject: RFR: 8267056: tools/jpackage/share/RuntimePackageTest.java fails
 with NoSuchFileException [v2]
In-Reply-To: <3FZIYFgMcdRP9EWWHTLNbg-IM8B4Zt0LW4YtvhCIpqA=.e76ed78b-1591-446b-b4bc-29b4d6b00e11@github.com>
References: <3FZIYFgMcdRP9EWWHTLNbg-IM8B4Zt0LW4YtvhCIpqA=.e76ed78b-1591-446b-b4bc-29b4d6b00e11@github.com>
Message-ID: 

> For debug build on macOS, runtime which used for test fill be located in /path/jdk-17/fastdebug and /path/jdk-17 will not contain any other files except fastdebug and in this case our check to decide if we need to copy app or runtime will return /path/jdk-17 which is not correct. Fixed by skipping this check for runtime and only using it for app. Also, added ignoring .DS_Store to test which is needed if user used Finder to look inside runtime folder which will cause .DS_Store to be created and will cause test to fail, since this file is not being packaged.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8267056: tools/jpackage/share/RuntimePackageTest.java fails with NoSuchFileException [v2]

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4120/files
  - new: https://git.openjdk.java.net/jdk/pull/4120/files/de575160..bce1c7e4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4120&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4120&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4120.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4120/head:pull/4120

PR: https://git.openjdk.java.net/jdk/pull/4120

From almatvee at openjdk.java.net  Thu May 20 22:25:14 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 20 May 2021 22:25:14 GMT
Subject: RFR: 8267056: tools/jpackage/share/RuntimePackageTest.java fails
 with NoSuchFileException [v2]
In-Reply-To: 
References: <3FZIYFgMcdRP9EWWHTLNbg-IM8B4Zt0LW4YtvhCIpqA=.e76ed78b-1591-446b-b4bc-29b4d6b00e11@github.com>
 
Message-ID: <_FzXboZY5rg0IfMXi0NhzYN7dkXdVurUldbVwipiJQo=.2234adbd-7ea2-4bef-b0a4-31ebbee24f9c@github.com>

On Thu, 20 May 2021 16:15:21 GMT, Alexey Semenyuk  wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8267056: tools/jpackage/share/RuntimePackageTest.java fails with NoSuchFileException [v2]
>
> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgBundler.java line 396:
> 
>> 394:         // if parent does not have any other files
>> 395:         if (!StandardBundlerParam.isRuntimeInstaller(params)) {
>> 396:             Path[] list = Files.list(rootDir).toArray(Path[]::new);
> 
> `Files.list()` requires try-with-resources construct.

Fixed. I also removed check for null, since I do not think that Files.list can return null. I think it was leftover when we used File APIs instead of Files.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4120

From mchung at openjdk.java.net  Thu May 20 22:31:29 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 20 May 2021 22:31:29 GMT
Subject: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

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-sealed?
>
> It's a permitted subclass of `ConstantDesc`, so it must be either `final`, `sealed`, or `non-sealed`. Making it `non-sealed` means it can still be extended.

I should have made it clear.  I was expecting `DynamicConstantDesc` should be `sealed`.  Do you expect non-JDK implementation class extending `DynamicConstantDesc`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4135

From asemenyuk at openjdk.java.net  Thu May 20 22:33:32 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 20 May 2021 22:33:32 GMT
Subject: RFR: 8267056: tools/jpackage/share/RuntimePackageTest.java fails
 with NoSuchFileException [v2]
In-Reply-To: 
References: <3FZIYFgMcdRP9EWWHTLNbg-IM8B4Zt0LW4YtvhCIpqA=.e76ed78b-1591-446b-b4bc-29b4d6b00e11@github.com>
 
Message-ID: 

On Thu, 20 May 2021 22:25:10 GMT, Alexander Matveev  wrote:

>> For debug build on macOS, runtime which used for test fill be located in /path/jdk-17/fastdebug and /path/jdk-17 will not contain any other files except fastdebug and in this case our check to decide if we need to copy app or runtime will return /path/jdk-17 which is not correct. Fixed by skipping this check for runtime and only using it for app. Also, added ignoring .DS_Store to test which is needed if user used Finder to look inside runtime folder which will cause .DS_Store to be created and will cause test to fail, since this file is not being packaged.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8267056: tools/jpackage/share/RuntimePackageTest.java fails with NoSuchFileException [v2]

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4120

From github.com+13357965+thihup at openjdk.java.net  Thu May 20 22:41:29 2021
From: github.com+13357965+thihup at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Thu, 20 May 2021 22:41:29 GMT
Subject: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v2]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Thu, 20 May 2021 22:28:56 GMT, Mandy Chung  wrote:

>> It's a permitted subclass of `ConstantDesc`, so it must be either `final`, `sealed`, or `non-sealed`. Making it `non-sealed` means it can still be extended.
>
> 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 classes should not implement {@linkplain ConstantDesc} directly.
 * Instead, they should extend {@link DynamicConstantDesc} (as {@link EnumDesc}
 * and {@link VarHandleDesc} do.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4135

From joe.darcy at oracle.com  Thu May 20 22:47:39 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 20 May 2021 15:47:39 -0700
Subject: RFR: 8224243: Make AccessibleObject a sealed class
In-Reply-To: 
References: <4DFE3N_LB1D0jraDzmAmhGpzPGZAZrluVqCM5LFo5B4=.bbe76387-44f8-44de-ae2a-ce89d823041b@github.com>
 
 
Message-ID: <10e02c56-f42e-bbc9-9927-cb819fb2a30f@oracle.com>

Hi ?amonn,

On 5/20/2021 2:59 PM, ?amonn McManus wrote:
> Thanks for the tip, Alan. Guava's public Invokable
> 
> class does inherit from AccessibleObject. It would probably not be too hard
> to make it stop doing so. That's technically a breaking API change, but the
> class is marked @Beta so that's fair game.
>
> I looked in Google's code base and I found one other project that extends
> AccessibleObject, picocli, here
> .
> That's not to say that nobody else does it, but apparently cases are rare.
>
> I do wonder what the purpose of the change would be. The constructor
> javadoc text doesn't say you *can't* extend this class. Is there some
> benefit from making it not work anymore?
>

The intent of the constructor's text to me implies the class is not 
intended to be subclassed outside of the JDK. (I'm not sure why the 
constructor isn't package private as all its subclasses are in the same 
package which would have accomplished that, but the SCM history from 
circa JDK 1.2 would need to be consulted for guidance.)

The original impetus for 8224243 was the implementation of certain 
overridable methods in AccessibleObject (getAnnotation, 
getAnnotationsByType, and getDeclaredAnnotations) not @implSpec'ing 
their behavior. The behavior is to thrown an error as the method should 
be overridden in the subclasses. If all the subclasses are within the 
JDK and the class is sealed, that @implSpec'ing need not occur.

If all the subclasses were in the JDK (which we know is not that case), 
it is preferable to avoid the @implSpec'ing throwing the exception as 
that is just an implementation-internal comment.

HTH,

-Joe


From david.holmes at oracle.com  Thu May 20 23:11:02 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 21 May 2021 09:11:02 +1000
Subject: RFR: 8266310: deadlock while loading the JNI code [v2]
In-Reply-To: <1b1189d6-f340-9220-73f0-185411262a21@gmail.com>
References: 
 <7uREVWzjGhgjYBdEpYZ5OBurn9FzSuu-TG9_xIu-syc=.c737c435-734e-4e79-9969-cf0d2147ac07@github.com>
 
 
 <1b1189d6-f340-9220-73f0-185411262a21@gmail.com>
Message-ID: <253df918-7106-1930-5963-877e58e7b26a@oracle.com>

Hi Peter,

On 21/05/2021 12:42 am, Peter Levart wrote:
> Hi Aleksei,
> 
> Are you trying to solve this in principle or do you have a concrete 
> problem at hand which triggers this deadlock? If it is the later, then 
> some rearrangement of code might do the trick... For example, native 
> libraries are typically loaded by a class initializer of some class that 
> is guaranteed to be initialized before the 1st invocation of a native 
> method from such library. But if such class can also be loaded and 
> initialized by some other trigger, deadlock can occur. Best remedy for 
> such situation is to move all native methods to a special class that 
> serves just for interfacing with native code and also contains an 
> initializer that loads the native library and nothing else. Such 
> arrangement would ensure that the order of taking locks is always the 
> same: classLoadingLock -> nativeLibraryLock ...

There were specific examples for this problem, but Aleksei is trying to 
define a general solution - which unfortunately doesn't exist.

The basic deadlock scenario is a special variant of the general class 
initialization deadlock:

Thread 1:
- loadLibrary
  - acquire loadLibrary global lock
    - call JNI_OnLoad
      - use class Foo (which needs to be loaded and initialized)
        - block acquiring  lock for Foo

Thread 2:
  - Initialize class Foo
   - Acquire  lock for Foo
     - 
       - call loadLibrary(x) // for any X
        - block acquiring loadLibrary global lock

We can reduce the chance of deadlock by using a per-native-library lock 
instead of the global loadLibrary lock - which is what Aleksei's initial 
version did. But we cannot remove all deadlock possibility because we 
must ensure only one thread can be executing JNI_OnLoad for any given 
native library.

Cheers,
David
-----


> Regards, Peter
> 
> On 5/20/21 12:31 AM, David Holmes wrote:
>> On 20/05/2021 2:29 am, Aleksei Voitylov wrote:
>>> On Wed, 19 May 2021 16:21:41 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 library load operation.
>>>>>
>>>>> Problem being fixed:
>>>>>
>>>>> The initial reproducer demonstrated a deadlock between the 
>>>>> JarFile/ZipFile and the hash map. That deadlock exists even when 
>>>>> the ZipFile/JarFile lock is removed because there's another lock 
>>>>> object in the class loader, associated with the name of the class 
>>>>> being loaded. Such objects are stored in 
>>>>> ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() 
>>>>> loads exactly the same class, whose signature is being verified in 
>>>>> another thread.
>>>>>
>>>>> Proposed fix:
>>>>>
>>>>> The proposed patch suggests to get rid of locking 
>>>>> loadedLibraryNames hash map and synchronize on each entry name, as 
>>>>> it's done with class names in see 
>>>>> ClassLoader.getClassLoadingLock(name) method.
>>>>>
>>>>> The patch introduces nativeLibraryLockMap which holds the lock 
>>>>> objects for each library name, and the getNativeLibraryLock() 
>>>>> private method is used to lazily initialize the corresponding lock 
>>>>> object. nativeLibraryContext was changed to ThreadLocal, so that in 
>>>>> any concurrent thread it would have a NativeLibrary object on top 
>>>>> of the stack, that's being currently loaded/unloaded in that 
>>>>> thread. nativeLibraryLockMap accumulates the names of all native 
>>>>> libraries loaded - in line with class loading code, it is not 
>>>>> explicitly cleared.
>>>>>
>>>>> Testing:? jtreg and jck testing with no regressions. A new 
>>>>> regression test was developed.
>>>>
>>>> Aleksei Voitylov has updated the pull request incrementally with one 
>>>> additional commit since the last revision:
>>>>
>>>> ?? address review comments, add tests
>>>
>>> Dear colleagues,
>>>
>>> The updated PR addresses review comment regarding ThreadLocal as well 
>>> as David' concern around the lock being held during 
>>> JNI_OnLoad/JNI_OnUnload calls, and ensures all lock objects are 
>>> deallocated. Multiple threads are allowed to enter 
>>> NativeLibrary.load() to prevent any thread from locking while another 
>>> thread loads a library. Before the update, there could be a class 
>>> loading lock held by a parallel capable class loader, which can 
>>> deadlock with the library loading lock. As proposed by David Holmes, 
>>> the library loading lock was removed because dlopen/LoadLibrary are 
>>> thread safe and they maintain internal reference counters on 
>>> libraries. There's still a lock being held while a pair of containers 
>>> are read/updated. It's not going to deadlock as there's no lock/wait 
>>> operation performed while that lock is held. Multiple threads may 
>>> create their own copies of NativeLibrary object and register it for 
>>> auto unloading.
>>>
>>> Tests for auto unloading were added along with the PR update. There 
>>> are now 3 jtreg tests:
>>> - one checks for deadlock, similar to the one proposed by Chris Hegarty
>>> - two other tests are for library unload.
>>>
>>> The major side effect of that multiple threads are allowed to enter 
>>> is that JNI_OnLoad/JNI_OnUnload may be called multiple (but same) 
>>> number of times from concurrent threads. In particular, the number of 
>>> calls to JNI_OnLoad must be equal to the number of calls to 
>>> JNI_OnUnload after the relevant class loader is garbage collected. 
>>> This may affect the behaviour that relies on specific order or the 
>>> number of JNI_OnLoad/JNI_OnUnload calls. The current JNI 
>>> specification does not mandate how many times JNI_OnLoad/JNI_OnUnload 
>>> are called. Also, we could not locate tests in jck/jtreg/vmTestbase 
>>> that would rely on the specific order or number of calls to 
>>> JNI_OnLoad/JNI_OnUnload.
>>
>> But you can't make such a change! That was my point. To fix the 
>> deadlock we must not hold a lock. But we must ensure only a single 
>> call to JNI_OnLoad is possible. It is an unsolvable problem with those 
>> constraints. You can't just change the behaviour of JNI_OnLoad like that.
>>
>> David
>> -----
>>
> 
> If this is really a problem that several people are facing, then perhaps 
> a change in the API could solve it. I'm thinking
> 
>>> Thank you Alan Bateman, David Holmes and Chris Hegarty for your 
>>> valuable input.
>>>
>>> -------------
>>>
>>> PR: https://git.openjdk.java.net/jdk/pull/3976
>>>
> 

From sviswanathan at openjdk.java.net  Thu May 20 23:19:01 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 20 May 2021 23:19:01 GMT
Subject: RFR: 8267190: Optimize Vector API test operations [v3]
In-Reply-To: 
References: 
Message-ID: 

> Vector API test operations (IS_DEFAULT, IS_FINITE, IS_INFINITE, IS_NAN and IS_NEGATIVE) are computed in three steps:
> 1) reinterpreting the floating point vectors as integral vectors (int/long)
> 2) perform the test in integer domain to get a int/long mask
> 3) reinterpret the int/long mask as float/double mask
> Step 3) currently is very slow. It can be optimized by modifying the Java code to utilize the existing reinterpret intrinsic.
> 
> For the VectorTestPerf attached to the JBS for JDK-8267190, the performance improves as follows:
> 
> Base:
> Benchmark (size) Mode Cnt Score Error Units
> VectorTestPerf.IS_DEFAULT 1024 thrpt 5 223.156 ? 90.452 ops/ms
> VectorTestPerf.IS_FINITE 1024 thrpt 5 223.841 ? 91.685 ops/ms
> VectorTestPerf.IS_INFINITE 1024 thrpt 5 224.561 ? 83.890 ops/ms
> VectorTestPerf.IS_NAN 1024 thrpt 5 223.777 ? 70.629 ops/ms
> VectorTestPerf.IS_NEGATIVE 1024 thrpt 5 218.392 ? 79.806 ops/ms
> 
> With patch:
> Benchmark (size) Mode Cnt Score Error Units
> VectorTestPerf.IS_DEFAULT 1024 thrpt 5 8812.357 ? 40.477 ops/ms
> VectorTestPerf.IS_FINITE 1024 thrpt 5 7425.739 ? 296.622 ops/ms
> VectorTestPerf.IS_INFINITE 1024 thrpt 5 8932.730 ? 269.988 ops/ms
> VectorTestPerf.IS_NAN 1024 thrpt 5 8574.872 ? 498.649 ops/ms
> VectorTestPerf.IS_NEGATIVE 1024 thrpt 5 8838.400 ? 11.849 ops/ms
> 
> Best Regards,
> Sandhya

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  Implement review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4039/files
  - new: https://git.openjdk.java.net/jdk/pull/4039/files/b506fc45..f318c0ee

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4039&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4039&range=01-02

  Stats: 372 lines in 31 files changed: 31 ins; 62 del; 279 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4039.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4039/head:pull/4039

PR: https://git.openjdk.java.net/jdk/pull/4039

From herrick at openjdk.java.net  Thu May 20 23:34:30 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 20 May 2021 23:34:30 GMT
Subject: RFR: 8267056: tools/jpackage/share/RuntimePackageTest.java fails
 with NoSuchFileException [v2]
In-Reply-To: 
References: <3FZIYFgMcdRP9EWWHTLNbg-IM8B4Zt0LW4YtvhCIpqA=.e76ed78b-1591-446b-b4bc-29b4d6b00e11@github.com>
 
Message-ID: <3nWS9-h08BtfOaRt9QsuLruA8S0HTRy5phxx8sf07Yk=.4a171420-e9de-4ad7-9803-44febd847b5e@github.com>

On Thu, 20 May 2021 22:25:10 GMT, Alexander Matveev  wrote:

>> For debug build on macOS, runtime which used for test fill be located in /path/jdk-17/fastdebug and /path/jdk-17 will not contain any other files except fastdebug and in this case our check to decide if we need to copy app or runtime will return /path/jdk-17 which is not correct. Fixed by skipping this check for runtime and only using it for app. Also, added ignoring .DS_Store to test which is needed if user used Finder to look inside runtime folder which will cause .DS_Store to be created and will cause test to fail, since this file is not being packaged.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8267056: tools/jpackage/share/RuntimePackageTest.java fails with NoSuchFileException [v2]

Marked as reviewed by herrick (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4120

From sviswanathan at openjdk.java.net  Thu May 20 23:36:37 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 20 May 2021 23:36:37 GMT
Subject: RFR: 8267190: Optimize Vector API test operations [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 20 May 2021 23:19:01 GMT, Sandhya Viswanathan  wrote:

>> Vector API test operations (IS_DEFAULT, IS_FINITE, IS_INFINITE, IS_NAN and IS_NEGATIVE) are computed in three steps:
>> 1) reinterpreting the floating point vectors as integral vectors (int/long)
>> 2) perform the test in integer domain to get a int/long mask
>> 3) reinterpret the int/long mask as float/double mask
>> Step 3) currently is very slow. It can be optimized by modifying the Java code to utilize the existing reinterpret intrinsic.
>> 
>> For the VectorTestPerf attached to the JBS for JDK-8267190, the performance improves as follows:
>> 
>> Base:
>> Benchmark (size) Mode Cnt Score Error Units
>> VectorTestPerf.IS_DEFAULT 1024 thrpt 5 223.156 ? 90.452 ops/ms
>> VectorTestPerf.IS_FINITE 1024 thrpt 5 223.841 ? 91.685 ops/ms
>> VectorTestPerf.IS_INFINITE 1024 thrpt 5 224.561 ? 83.890 ops/ms
>> VectorTestPerf.IS_NAN 1024 thrpt 5 223.777 ? 70.629 ops/ms
>> VectorTestPerf.IS_NEGATIVE 1024 thrpt 5 218.392 ? 79.806 ops/ms
>> 
>> With patch:
>> Benchmark (size) Mode Cnt Score Error Units
>> VectorTestPerf.IS_DEFAULT 1024 thrpt 5 8812.357 ? 40.477 ops/ms
>> VectorTestPerf.IS_FINITE 1024 thrpt 5 7425.739 ? 296.622 ops/ms
>> VectorTestPerf.IS_INFINITE 1024 thrpt 5 8932.730 ? 269.988 ops/ms
>> VectorTestPerf.IS_NAN 1024 thrpt 5 8574.872 ? 498.649 ops/ms
>> VectorTestPerf.IS_NEGATIVE 1024 thrpt 5 8838.400 ? 11.849 ops/ms
>> 
>> Best Regards,
>> Sandhya
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement review comments

Thanks Paul. I have implemented these two suggestions as well.

If no objections from any one else, I plan to integrate this tomorrow, Friday May 21.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4039

From mchung at openjdk.java.net  Thu May 20 23:43:31 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 20 May 2021 23:43:31 GMT
Subject: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v2]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: <5XPJ9shB0AbhV4Jh7PkxS8JTyChaOckwSFV48ajvITc=.941c7963-7e82-4881-a2f2-c91645bbcbe4@github.com>

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 classes should not implement {@linkplain ConstantDesc} directly.
>  * Instead, they should extend {@link DynamicConstantDesc} (as {@link EnumDesc}
>  * and {@link VarHandleDesc} do.)

Thanks.  I missed this javadoc.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4135

From mik3hall at gmail.com  Thu May 20 23:45:43 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 20 May 2021 18:45:43 -0500
Subject: jpackage GraalVM on Windows 10
Message-ID: <684AC497-2CCE-46D1-B8BC-5A1926EB8300@gmail.com>

Has anyone done this who can indicate how it should be done?

I recently set this up for my app on OS/X and thought I?d have cross platform versions.
I have tried it both with ?runtime-image and making Graal the installed JVM.

Both ways I seem to get an application with directory structure

runtime
?? graalvm-ce-java11-21.1.0
?????bin
?????conf
?

It appears it should not have the Graal dir in there. I removed it and the application runs. Otherwise no.
Again it seems to do this even if I let it default to the installed Graal jdk - not ?runtime-image.

If no one else has run into this and figured something out or just knows how to do it correctly I can just do a bug report.


From emcmanus at google.com  Fri May 21 00:48:09 2021
From: emcmanus at google.com (=?UTF-8?Q?=C3=89amonn_McManus?=)
Date: Thu, 20 May 2021 17:48:09 -0700
Subject: RFR: 8224243: Make AccessibleObject a sealed class
In-Reply-To: <10e02c56-f42e-bbc9-9927-cb819fb2a30f@oracle.com>
References: <4DFE3N_LB1D0jraDzmAmhGpzPGZAZrluVqCM5LFo5B4=.bbe76387-44f8-44de-ae2a-ce89d823041b@github.com>
 
 
 <10e02c56-f42e-bbc9-9927-cb819fb2a30f@oracle.com>
Message-ID: 

Hi Joe,

I see that I blogged
 about
AccessibleObject in 2006 and already complained about its protected
constructor back then. :-)

Still, if the main motivation of sealing it is to avoid adding @implSpec to
a few methods, perhaps it would be better just to bite the bullet and do
that? We can fix Guava's Invokable class so it no longer inherits from
AccessibleObject, and I think we probably should, but it would still be the
case that an app using a version of Guava from before the fix would fail
when deployed to a JDK with this change.

Thanks,
?amonn

On Thu, 20 May 2021 at 15:47, Joe Darcy  wrote:

> Hi ?amonn,
>
> On 5/20/2021 2:59 PM, ?amonn McManus wrote:
> > Thanks for the tip, Alan. Guava's public Invokable
> > <
> https://javadoc.io/doc/com.google.guava/guava/latest/com/google/common/reflect/Invokable.html
> >
> > class does inherit from AccessibleObject. It would probably not be too
> hard
> > to make it stop doing so. That's technically a breaking API change, but
> the
> > class is marked @Beta so that's fair game.
> >
> > I looked in Google's code base and I found one other project that extends
> > AccessibleObject, picocli, here
> >  >.
> > That's not to say that nobody else does it, but apparently cases are
> rare.
> >
> > I do wonder what the purpose of the change would be. The constructor
> > javadoc text doesn't say you *can't* extend this class. Is there some
> > benefit from making it not work anymore?
> >
>
> The intent of the constructor's text to me implies the class is not
> intended to be subclassed outside of the JDK. (I'm not sure why the
> constructor isn't package private as all its subclasses are in the same
> package which would have accomplished that, but the SCM history from
> circa JDK 1.2 would need to be consulted for guidance.)
>
> The original impetus for 8224243 was the implementation of certain
> overridable methods in AccessibleObject (getAnnotation,
> getAnnotationsByType, and getDeclaredAnnotations) not @implSpec'ing
> their behavior. The behavior is to thrown an error as the method should
> be overridden in the subclasses. If all the subclasses are within the
> JDK and the class is sealed, that @implSpec'ing need not occur.
>
> If all the subclasses were in the JDK (which we know is not that case),
> it is preferable to avoid the @implSpec'ing throwing the exception as
> that is just an implementation-internal comment.
>
> HTH,
>
> -Joe
>
>

From almatvee at openjdk.java.net  Fri May 21 00:47:35 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 21 May 2021 00:47:35 GMT
Subject: Integrated: 8267056: tools/jpackage/share/RuntimePackageTest.java
 fails with NoSuchFileException
In-Reply-To: <3FZIYFgMcdRP9EWWHTLNbg-IM8B4Zt0LW4YtvhCIpqA=.e76ed78b-1591-446b-b4bc-29b4d6b00e11@github.com>
References: <3FZIYFgMcdRP9EWWHTLNbg-IM8B4Zt0LW4YtvhCIpqA=.e76ed78b-1591-446b-b4bc-29b4d6b00e11@github.com>
Message-ID: <247EPfIrEStj8D7oaX3z8XIJtpDLsD0BuqwClcBWp_g=.7fe3ea95-19da-4b9c-9da9-48cff14e7b16@github.com>

On Wed, 19 May 2021 21:00:07 GMT, Alexander Matveev  wrote:

> For debug build on macOS, runtime which used for test fill be located in /path/jdk-17/fastdebug and /path/jdk-17 will not contain any other files except fastdebug and in this case our check to decide if we need to copy app or runtime will return /path/jdk-17 which is not correct. Fixed by skipping this check for runtime and only using it for app. Also, added ignoring .DS_Store to test which is needed if user used Finder to look inside runtime folder which will cause .DS_Store to be created and will cause test to fail, since this file is not being packaged.

This pull request has now been integrated.

Changeset: 9eaa4afc
Author:    Alexander Matveev 
URL:       https://git.openjdk.java.net/jdk/commit/9eaa4afc99b09f4704e4d641f95104be40b9ea66
Stats:     15 lines in 2 files changed: 5 ins; 0 del; 10 mod

8267056: tools/jpackage/share/RuntimePackageTest.java fails with NoSuchFileException

Reviewed-by: asemenyuk, herrick

-------------

PR: https://git.openjdk.java.net/jdk/pull/4120

From mik3hall at gmail.com  Fri May 21 01:24:51 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 20 May 2021 20:24:51 -0500
Subject: jpackage GraalVM on Windows 10
In-Reply-To: <684AC497-2CCE-46D1-B8BC-5A1926EB8300@gmail.com>
References: <684AC497-2CCE-46D1-B8BC-5A1926EB8300@gmail.com>
Message-ID: <53D7048E-14C0-44AD-BD18-E687FC0DE280@gmail.com>



> On May 20, 2021, at 6:45 PM, Michael Hall  wrote:
> 
> Has anyone done this who can indicate how it should be done?
> 

It seems to be the non-standard JDK name. I renamed it to jdk-11 and it worked. 
Letting it default still set it to the current jdk-16 even though that was later in PATH.
But using ?runtime-image worked.
I?ll bug report if non-standard JDK names can be expected to be supported.


From weijun at openjdk.java.net  Fri May 21 01:58:47 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 01:58:47 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
Message-ID: 

The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.

-------------

Depends on: https://git.openjdk.java.net/jdk/pull/4073

Commit messages:
 - 8267521: Post JEP 411 refactoring: maximum covering > 50K

Changes: https://git.openjdk.java.net/jdk/pull/4138/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267521
  Stats: 226 lines in 18 files changed: 142 ins; 29 del; 55 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138

PR: https://git.openjdk.java.net/jdk/pull/4138

From darcy at openjdk.java.net  Fri May 21 02:42:50 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 21 May 2021 02:42:50 GMT
Subject: RFR: 8224243: Make AccessibleObject a sealed class [v2]
In-Reply-To: <4DFE3N_LB1D0jraDzmAmhGpzPGZAZrluVqCM5LFo5B4=.bbe76387-44f8-44de-ae2a-ce89d823041b@github.com>
References: <4DFE3N_LB1D0jraDzmAmhGpzPGZAZrluVqCM5LFo5B4=.bbe76387-44f8-44de-ae2a-ce89d823041b@github.com>
Message-ID: <1p8BXJHpzVJ_nPh9j0sRoOJwdiYNkO_6DK9sg5T92_A=.9a001d1a-f0d9-428e-8c45-fb5f04cf79b4@github.com>

> Conceptually, AccessbileObject is a sealed class with a protected constructor stating
> 
>     Constructor: only used by the Java Virtual Machine.
> 
> With the language now supporting sealed classes, the AccessbileObject should be marked as sealed.
> 
> Executable and Field are the subclasses of AccessbileObject in the JDK; as Executable has subclasses, it is marked as non-sealed.
> 
> Please also review the corresponding CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8224243

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Update in response to review feedback.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4133/files
  - new: https://git.openjdk.java.net/jdk/pull/4133/files/f605cfa8..be517cda

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4133&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4133&range=00-01

  Stats: 21 lines in 3 files changed: 15 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4133.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4133/head:pull/4133

PR: https://git.openjdk.java.net/jdk/pull/4133

From darcy at openjdk.java.net  Fri May 21 02:45:33 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 21 May 2021 02:45:33 GMT
Subject: RFR: 8224243: Make AccessibleObject a sealed class [v2]
In-Reply-To: <1p8BXJHpzVJ_nPh9j0sRoOJwdiYNkO_6DK9sg5T92_A=.9a001d1a-f0d9-428e-8c45-fb5f04cf79b4@github.com>
References: <4DFE3N_LB1D0jraDzmAmhGpzPGZAZrluVqCM5LFo5B4=.bbe76387-44f8-44de-ae2a-ce89d823041b@github.com>
 <1p8BXJHpzVJ_nPh9j0sRoOJwdiYNkO_6DK9sg5T92_A=.9a001d1a-f0d9-428e-8c45-fb5f04cf79b4@github.com>
Message-ID: <06vjOUleO7E2K5WSzP_aQRMDkcReQlo2yhylAi_pQiU=.deecdc8c-6223-4c4d-b015-2cd3e583431b@github.com>

On Fri, 21 May 2021 02:42:50 GMT, Joe Darcy  wrote:

>> Conceptually, AccessbileObject is a sealed class with a protected constructor stating
>> 
>>     Constructor: only used by the Java Virtual Machine.
>> 
>> With the language now supporting sealed classes, the AccessbileObject should be marked as sealed.
>> 
>> Executable and Field are the subclasses of AccessbileObject in the JDK; as Executable has subclasses, it is marked as non-sealed.
>> 
>> Please also review the corresponding CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8224243
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update in response to review feedback.

Pushed an updated version of the fix that deprecates the AccessibleObject constructor, adds the @implSpec tags, and makes Executable a sealed class.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4133

From bchristi at openjdk.java.net  Fri May 21 03:06:34 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 21 May 2021 03:06:34 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
Message-ID: 

On Thu, 20 May 2021 16:10:11 GMT, Roger Riggs  wrote:

>> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
>> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
>> configuration mechanisms and filter utilities.
>> 
>> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`:
>>     http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify factory interface to BinaryOperator and cleanup the example

src/java.base/share/classes/java/io/ObjectInputStream.java line 193:

> 191:  * the state.
> 192:  *
> 193:  * The deserialization filter for a stream is determined in one of the following ways:

Should this line start with a `
    ` ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From github.com+7806504+liach at openjdk.java.net  Fri May 21 03:29:31 2021
From: github.com+7806504+liach at openjdk.java.net (liach)
Date: Fri, 21 May 2021 03:29:31 GMT
Subject: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v3]
In-Reply-To: <-Wla9ZYDbnQ8UfTAq4x-rvK6kj3elKri-6LbvR9udOI=.68ae6dab-7758-401d-8a44-9d4ed26bf51a@github.com>
References: 
 <-Wla9ZYDbnQ8UfTAq4x-rvK6kj3elKri-6LbvR9udOI=.68ae6dab-7758-401d-8a44-9d4ed26bf51a@github.com>
Message-ID: 

On Thu, 20 May 2021 22:13: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 request incrementally with one additional commit since the last revision:
> 
>   Removing file constants.patch added by mistake

src/java.base/share/classes/java/lang/constant/ClassDesc.java line 56:

> 54:  * @since 12
> 55:  */
> 56: sealed public interface ClassDesc

Should move `sealed` behind `public` per the blessed modifier order from JLS. https://docs.oracle.com/javase/specs/jls/se16/preview/specs/sealed-classes-jls.html#jls-8.1.1

Per http://openjdk.java.net/jeps/409 the finalized sealed classes have no difference from that in 16, so the order suggested there should be valid.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4135

From almatvee at openjdk.java.net  Fri May 21 04:41:44 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 21 May 2021 04:41:44 GMT
Subject: RFR: 8267403: tools/jpackage/share/FileAssociationsTest.java#id0
 failed with "Error: Bundler "Mac PKG Package" (pkg) failed to produce a
 package"
Message-ID: 

Looks like another issue similar to hdiutil (JDK-8249395) when process is gone, but we still waiting for it. I was not able to reproduce this issue by running test or pkgbuild separately and conclusion was made based on logs. Fixed in same way as hdiutil issue. Also, I added logging PID for external commands to simplify log analysis. Log will have multiple hdiutil and/or pkgbuild processes, since we running multiple tests in parallel and matching external process to test failure requires looking at command line for particular process, so PID should simplify this.

-------------

Commit messages:
 - 8267403: tools/jpackage/share/FileAssociationsTest.java#id0 failed with "Error: Bundler \"Mac PKG Package\" (pkg) failed to produce a package"

Changes: https://git.openjdk.java.net/jdk/pull/4139/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4139&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267403
  Stats: 31 lines in 5 files changed: 16 ins; 1 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4139.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4139/head:pull/4139

PR: https://git.openjdk.java.net/jdk/pull/4139

From bchristi at openjdk.java.net  Fri May 21 05:52:45 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 21 May 2021 05:52:45 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
Message-ID: <0Nt9icC6yOGDWvXL6E7pZQYijtUhFRXJym2a38CuyOA=.aa03566b-0762-4ab0-b5a4-3aa0f2d9d203@github.com>

On Thu, 20 May 2021 16:10:11 GMT, Roger Riggs  wrote:

>> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
>> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
>> configuration mechanisms and filter utilities.
>> 
>> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`:
>>     http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify factory interface to BinaryOperator and cleanup the example

src/java.base/share/classes/java/io/ObjectInputFilter.java line 273:

> 271:      *     
  • {@link ObjectInputFilter.Status#REJECTED}, if the filter is checking a class
> 272:      *     and the filter returns {@link ObjectInputFilter.Status#UNDECIDED}, 
    • 
> 273:      *     
  • Otherwise, return the status
    • 

"Otherwise, return the status of this filter" ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From peter.levart at gmail.com  Fri May 21 08:29:42 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 21 May 2021 10:29:42 +0200
Subject: RFR: 8266310: deadlock while loading the JNI code [v2]
In-Reply-To: <253df918-7106-1930-5963-877e58e7b26a@oracle.com>
References: 
 <7uREVWzjGhgjYBdEpYZ5OBurn9FzSuu-TG9_xIu-syc=.c737c435-734e-4e79-9969-cf0d2147ac07@github.com>
 
 
 <1b1189d6-f340-9220-73f0-185411262a21@gmail.com>
 <253df918-7106-1930-5963-877e58e7b26a@oracle.com>
Message-ID: <7b625acd-9c83-e4cf-02cd-ff534ecdffa3@gmail.com>


On 21/05/2021 01:11, David Holmes wrote:
> Hi Peter,
>
> On 21/05/2021 12:42 am, Peter Levart wrote:
>> Hi Aleksei,
>>
>> Are you trying to solve this in principle or do you have a concrete 
>> problem at hand which triggers this deadlock? If it is the later, 
>> then some rearrangement of code might do the trick... For example, 
>> native libraries are typically loaded by a class initializer of some 
>> class that is guaranteed to be initialized before the 1st invocation 
>> of a native method from such library. But if such class can also be 
>> loaded and initialized by some other trigger, deadlock can occur. 
>> Best remedy for such situation is to move all native methods to a 
>> special class that serves just for interfacing with native code and 
>> also contains an initializer that loads the native library and 
>> nothing else. Such arrangement would ensure that the order of taking 
>> locks is always the same: classLoadingLock -> nativeLibraryLock ...
>
> There were specific examples for this problem, but Aleksei is trying 
> to define a general solution - which unfortunately doesn't exist.
>
> The basic deadlock scenario is a special variant of the general class 
> initialization deadlock:
>
> Thread 1:
> - loadLibrary
> ?- acquire loadLibrary global lock
> ?? - call JNI_OnLoad
> ???? - use class Foo (which needs to be loaded and initialized)
> ?????? - block acquiring  lock for Foo
>
> Thread 2:
> ?- Initialize class Foo
> ? - Acquire  lock for Foo
> ??? - 
> ????? - call loadLibrary(x) // for any X
> ?????? - block acquiring loadLibrary global lock
>
> We can reduce the chance of deadlock by using a per-native-library 
> lock instead of the global loadLibrary lock - which is what Aleksei's 
> initial version did. But we cannot remove all deadlock possibility 
> because we must ensure only one thread can be executing JNI_OnLoad for 
> any given native library.


Right, I was just trying to suggest that by exercising some discipline 
about how to arrange code that loads native libraries, deadlocks can be 
avoided if also Aleksei's initial version of the patch is used (using a 
per-native-library lock instead of the global loadLibrary lock). The 
discipline would be to load a particular native library only from 
 of a unique class associated with that native library. If 
everybody followed this discipline (which fortunately is typical use of 
loadLibrary), then without Aleksei's patch, deadlock is still possible. 
Imagine two native libraries A and B, each loaded from  of 
corresponding classes ClassA and ClassB. Library A also has JNI_OnLoad 
which uses ClassB. So we have:

Thread 1:
 ??? - initialize ClassA
 ??? - acquire  lock for ClassA
 ??? ??? - ClassA.
 ??? ??? - call loadLibrary(A)
 ??? ??? - acquire loadLibrary global lock
 ??? ??? ??? - call JNI_OnLoad for A
 ??????? ??? - use class ClassB (which needs to be loaded and initialized)
 ??? ??? ??? - block acquiring  lock for ClassB

Thread 2:
 ??? - initialize ClassB
 ??? - acquire  lock for ClassB
 ??? ??? - ClassB.
 ??? ??? - call loadLibrary(B)
 ??? ??? - block acquiring loadLibrary global lock

With Aleksei's initial patch, such scenario would not result in a 
deadlock. And since such scenario can arise from typical use of 
loadLibrary, I think this patch is a good thing. It reduces number of 
scenarios where deadlock is a possible outcome. Here's another scenario 
where deadlock would still occur even with Sergei's initial patch. It is 
a modified variant of above scenario where JNI_OnLoad of library A uses 
ClassB and JNI_OnLoad of library B uses ClassA:

Thread 1:
 ??? - initialize ClassA
 ??? - acquire  lock for ClassA
 ??? ??? - ClassA.
 ??? ??? - call loadLibrary(A)
 ??? ??? - acquire loadLibrary(A) lock
 ??? ??? ??? - call JNI_OnLoad for A
 ??????? ??? - use class ClassB (which needs to be loaded and initialized)
 ??? ??? ??? - block acquiring  lock for ClassB

Thread 2:
 ??? - initialize ClassB
 ??? - acquire  lock for ClassB
 ??? ??? - ClassB.
 ??? ??? - call loadLibrary(B)
 ??? ??? - acquire loadLibrary(B) lock
 ??? ??? ??? - call JNI_OnLoad for B
 ??????? ??? - use class ClassA (which needs to be loaded and initialized)
 ??? ??? ??? - block acquiring  lock for ClassA

But in this scenario, deadlock is provoked without blocking on any 
loadLibrary lock. This deadlock arises from circular dependencies among 
classes in their  methods. It just happens that these 
dependencies are evaluated via a chain of: X. -> loadLibrary -> 
JNI_OnLoad -> use class Y calls. Such deadlock is possible without 
involvement of native libraries loading too, so I would not classify it 
as the problem that Sergei's patch is trying to solve.

I still haven't found a scenario of a possible deadlock when Sergei's 
initial patch is combined with the above mentioned discipline in which a 
loadLibrary lock would be involved.

Regards, Peter

>
> Cheers,
> David
> -----
>
>
>> Regards, Peter
>>
>> On 5/20/21 12:31 AM, David Holmes wrote:
>>> On 20/05/2021 2:29 am, Aleksei Voitylov wrote:
>>>> On Wed, 19 May 2021 16:21:41 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 library load operation.
>>>>>>
>>>>>> Problem being fixed:
>>>>>>
>>>>>> The initial reproducer demonstrated a deadlock between the 
>>>>>> JarFile/ZipFile and the hash map. That deadlock exists even when 
>>>>>> the ZipFile/JarFile lock is removed because there's another lock 
>>>>>> object in the class loader, associated with the name of the class 
>>>>>> being loaded. Such objects are stored in 
>>>>>> ClassLoader.parallelLockMap. The deadlock occurs when 
>>>>>> JNI_OnLoad() loads exactly the same class, whose signature is 
>>>>>> being verified in another thread.
>>>>>>
>>>>>> Proposed fix:
>>>>>>
>>>>>> The proposed patch suggests to get rid of locking 
>>>>>> loadedLibraryNames hash map and synchronize on each entry name, 
>>>>>> as it's done with class names in see 
>>>>>> ClassLoader.getClassLoadingLock(name) method.
>>>>>>
>>>>>> The patch introduces nativeLibraryLockMap which holds the lock 
>>>>>> objects for each library name, and the getNativeLibraryLock() 
>>>>>> private method is used to lazily initialize the corresponding 
>>>>>> lock object. nativeLibraryContext was changed to ThreadLocal, so 
>>>>>> that in any concurrent thread it would have a NativeLibrary 
>>>>>> object on top of the stack, that's being currently 
>>>>>> loaded/unloaded in that thread. nativeLibraryLockMap accumulates 
>>>>>> the names of all native libraries loaded - in line with class 
>>>>>> loading code, it is not explicitly cleared.
>>>>>>
>>>>>> Testing:? jtreg and jck testing with no regressions. A new 
>>>>>> regression test was developed.
>>>>>
>>>>> Aleksei Voitylov has updated the pull request incrementally with 
>>>>> one additional commit since the last revision:
>>>>>
>>>>> ?? address review comments, add tests
>>>>
>>>> Dear colleagues,
>>>>
>>>> The updated PR addresses review comment regarding ThreadLocal as 
>>>> well as David' concern around the lock being held during 
>>>> JNI_OnLoad/JNI_OnUnload calls, and ensures all lock objects are 
>>>> deallocated. Multiple threads are allowed to enter 
>>>> NativeLibrary.load() to prevent any thread from locking while 
>>>> another thread loads a library. Before the update, there could be a 
>>>> class loading lock held by a parallel capable class loader, which 
>>>> can deadlock with the library loading lock. As proposed by David 
>>>> Holmes, the library loading lock was removed because 
>>>> dlopen/LoadLibrary are thread safe and they maintain internal 
>>>> reference counters on libraries. There's still a lock being held 
>>>> while a pair of containers are read/updated. It's not going to 
>>>> deadlock as there's no lock/wait operation performed while that 
>>>> lock is held. Multiple threads may create their own copies of 
>>>> NativeLibrary object and register it for auto unloading.
>>>>
>>>> Tests for auto unloading were added along with the PR update. There 
>>>> are now 3 jtreg tests:
>>>> - one checks for deadlock, similar to the one proposed by Chris 
>>>> Hegarty
>>>> - two other tests are for library unload.
>>>>
>>>> The major side effect of that multiple threads are allowed to enter 
>>>> is that JNI_OnLoad/JNI_OnUnload may be called multiple (but same) 
>>>> number of times from concurrent threads. In particular, the number 
>>>> of calls to JNI_OnLoad must be equal to the number of calls to 
>>>> JNI_OnUnload after the relevant class loader is garbage collected. 
>>>> This may affect the behaviour that relies on specific order or the 
>>>> number of JNI_OnLoad/JNI_OnUnload calls. The current JNI 
>>>> specification does not mandate how many times 
>>>> JNI_OnLoad/JNI_OnUnload are called. Also, we could not locate tests 
>>>> in jck/jtreg/vmTestbase that would rely on the specific order or 
>>>> number of calls to JNI_OnLoad/JNI_OnUnload.
>>>
>>> But you can't make such a change! That was my point. To fix the 
>>> deadlock we must not hold a lock. But we must ensure only a single 
>>> call to JNI_OnLoad is possible. It is an unsolvable problem with 
>>> those constraints. You can't just change the behaviour of JNI_OnLoad 
>>> like that.
>>>
>>> David
>>> -----
>>>
>>
>> If this is really a problem that several people are facing, then 
>> perhaps a change in the API could solve it. I'm thinking
>>
>>>> Thank you Alan Bateman, David Holmes and Chris Hegarty for your 
>>>> valuable input.
>>>>
>>>> -------------
>>>>
>>>> PR: https://git.openjdk.java.net/jdk/pull/3976
>>>>
>>

From gbierman at openjdk.java.net  Fri May 21 08:53:51 2021
From: gbierman at openjdk.java.net (Gavin Bierman)
Date: Fri, 21 May 2021 08:53:51 GMT
Subject: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v4]
In-Reply-To: 
References: 
Message-ID: 

> 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 request incrementally with one additional commit since the last revision:

  Reordering class modifiers

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4135/files
  - new: https://git.openjdk.java.net/jdk/pull/4135/files/c8f632f6..c36075d2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4135&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4135&range=02-03

  Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4135/head:pull/4135

PR: https://git.openjdk.java.net/jdk/pull/4135

From gbierman at openjdk.java.net  Fri May 21 08:53:52 2021
From: gbierman at openjdk.java.net (Gavin Bierman)
Date: Fri, 21 May 2021 08:53:52 GMT
Subject: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v3]
In-Reply-To: 
References: 
 <-Wla9ZYDbnQ8UfTAq4x-rvK6kj3elKri-6LbvR9udOI=.68ae6dab-7758-401d-8a44-9d4ed26bf51a@github.com>
 
Message-ID: 

On Fri, 21 May 2021 03:26:49 GMT, liach  wrote:

>> Gavin Bierman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing file constants.patch added by mistake
>
> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 56:
> 
>> 54:  * @since 12
>> 55:  */
>> 56: sealed public interface ClassDesc
> 
> Should move `sealed` behind `public` per the blessed modifier order from JLS. https://docs.oracle.com/javase/specs/jls/se16/preview/specs/sealed-classes-jls.html#jls-8.1.1
> 
> Per http://openjdk.java.net/jeps/409 the finalized sealed classes have no difference from that in 16, so the order suggested there should be valid.

Thanks. Now changed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4135

From albest512 at hotmail.com  Fri May 21 09:11:59 2021
From: albest512 at hotmail.com (=?iso-8859-1?Q?Alberto_Otero_Rodr=EDguez?=)
Date: Fri, 21 May 2021 09:11:59 +0000
Subject: New java.util.Strings class
In-Reply-To: 
References: ,
 
Message-ID: 

Hi,

I have made other changes to the Strings class I proposed in my previous messages.

The changes are:

  *   Added the new methods compareTo and compareToIgnoreCase
  *   Changed WhiteSpace for Whitespace

You can see the new code here:
https://github.com/Aliuken/Java-Strings/blob/main/Strings.java

With those changes, the annotations suggested in the previous message should change to:
- @NonNullNorWhitespace
- @NonNullNorWhitespaceElse(defaultValue)
- @NonNullNorWhitespaceElseGet(class::supplierMethod)

Regards,

Alberto Otero Rodr?guez.
________________________________
De: Alberto Otero Rodr?guez 
Enviado: mi?rcoles, 19 de mayo de 2021 11:36
Para: core-libs-dev at openjdk.java.net 
Asunto: RE: New java.util.Strings class

Hi,

I have made some changes to the Strings class I proposed in my previous message.

The changes are:

  *   Use str.isEmpty() instead of EMPTY_STRING.equals(str)
  *   Create methods using str.strip() to check a String is not Whitespace

You can see the new code here:
https://github.com/Aliuken/Java-Strings/blob/main/Strings.java

With those changes, the following annotations could also be created for method arguments and return types:
- @NonNullNorWhiteSpace
- @NonNullNorWhiteSpaceElse(defaultValue)
- @NonNullNorWhiteSpaceElseGet(class::supplierMethod)

I didn't have any response to the previous message.

Please, take this one in consideration.

Regards,

Alberto Otero Rodr?guez.

________________________________
De: Alberto Otero Rodr?guez
Enviado: lunes, 17 de mayo de 2021 14:58
Para: core-libs-dev at openjdk.java.net 
Asunto: New java.util.Strings class

Hi, members of the core-libs developers of OpenJDK.

I think Java needs a Strings class similar to the java.util.Objects class of Java 16 to be used in method arguments, return types and Stream filters.

I have coded it myself here based on the Objects implementation of Java 16 (please have a look):
https://github.com/Aliuken/Java-Strings/blob/main/Strings.java

In fact, I think it would be useful also adding annotations for method arguments and return types such as:
- @NonNull
- @NonNullElse(defaultValue)
- @NonNullElseGet(class::supplierMethod)
- @NonNullNorEmpty
- @NonNullNorEmptyElse(defaultValue)
- @NonNullNorEmptyElseGet(class::supplierMethod)

With that kind of annotations, you could assume thinks like:
- an argument or return type cannot have value null, but an Exception
- an argument or return type cannot have value null, but a default value

What do you think?

Waiting for your response.

PS: I am sending this email repeated. I have sended it yesterday with my other email account (alber84ou at gmail.com), but I wasn't a member of this mailing list. Now I have become a member with this other email account.

Regards,

Alberto Otero Rodr?guez.


From jbachorik at openjdk.java.net  Fri May 21 09:47:38 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Fri, 21 May 2021 09:47:38 GMT
Subject: Integrated: 8203359: Container level resources events
In-Reply-To: 
References: 
Message-ID: <-1woABIwQgawuw-DfZsq52kuwUJHF0UQwIb5bOqvMIo=.cd977456-1150-4670-bbea-81a214731a74@github.com>

On Mon, 22 Mar 2021 15:57:12 GMT, Jaroslav Bachorik  wrote:

> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events.
> 
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with.
> * CPU related metrics
> * Memory related metrics
> * I/O related metrics
> 
> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. 
> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently).

This pull request has now been integrated.

Changeset: ee2651b9
Author:    Jaroslav Bachorik 
URL:       https://git.openjdk.java.net/jdk/commit/ee2651b9e5a9ab468b4be73d43b8f643e9e92042
Stats:     598 lines in 14 files changed: 582 ins; 4 del; 12 mod

8203359: Container level resources events

Reviewed-by: sgehwolf, egahlin

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From eastig at amazon.co.uk  Fri May 21 10:38:52 2021
From: eastig at amazon.co.uk (Astigeevich, Evgeny)
Date: Fri, 21 May 2021 10:38:52 +0000
Subject: JDK-8246677 caused 16x performance regression in OpenJDK Tip
 SynchronousQueue
Message-ID: <665F83CF-DBD3-4A18-BEB6-BA5CFF07953E@amazon.com>

Hi Alan,

I was benchmarking SynchronousQueue from the OpenJDK Tip on Linux. I found its performance is 16 times lower than the performance of SynchronousQueue from OpenJDK 11. The regression exists on Linux x86_64 and Linux aarch64. Comparing SynchronousQueue implementations I found the OpenJDK Tip SynchronousQueue is changed by PR https://github.com/openjdk/jdk/pull/1645 (JDK-8246677). Reverting SynchronousQueue to the version before the PR fixes the regression. I cannot find any performance data backing the PR.

I raised a JBS issue: https://bugs.openjdk.java.net/browse/JDK-8267502
It has details how to reproduce the issue.

As we are approaching JDK 17 Rampdown Phase One (2021/06/10), could the issue be triaged?

Thanks,
Evgeny Astigeevich



Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.



From pconcannon at openjdk.java.net  Fri May 21 11:26:56 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 21 May 2021 11:26:56 GMT
Subject: RFR: 8267110: Update java.util to use instanceof pattern variable
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Patrick Concannon 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 last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8267110
 - 8267110: Reverted changes in java/util/Formatter as primitive to boxed types may have semantic/performance implications
 - Merge remote-tracking branch 'origin/master' into JDK-8267110
 - 8267110: Update java.util to use instanceof pattern variable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4088/files
  - new: https://git.openjdk.java.net/jdk/pull/4088/files/cd99dc49..da615e7d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=01-02

  Stats: 4905 lines in 201 files changed: 2421 ins; 2058 del; 426 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4088.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4088/head:pull/4088

PR: https://git.openjdk.java.net/jdk/pull/4088

From albest512 at hotmail.com  Fri May 21 13:51:08 2021
From: albest512 at hotmail.com (=?iso-8859-1?Q?Alberto_Otero_Rodr=EDguez?=)
Date: Fri, 21 May 2021 13:51:08 +0000
Subject: Java records used in enums
Message-ID: 

Hi,

I think enums in Java should be immutable. When you let the programmer change values in an enum instance, an unexpected behaviour can happen when using multiple threads as enum instances are static (singleton).

So, I was wondering why not make enums instances be defined as records instead of normal classes.

What do you think?

Regards,

Alberto.

From jvernee at openjdk.java.net  Fri May 21 14:00:06 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 21 May 2021 14:00:06 GMT
Subject: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v4]
In-Reply-To: 
References: 
 
Message-ID: 

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 request incrementally with one additional commit since the last revision:
> 
>   Reordering class modifiers

This looks good to me.

Does this require a CSR as well?

I see a CSR here for another change that seals a hierarchy: https://bugs.openjdk.java.net/browse/JDK-8267506

Ah, nvm, it's already indicated on the PR :)

-------------

Marked as reviewed by jvernee (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4135

From weijun at openjdk.java.net  Fri May 21 14:00:39 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 14:00:39 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
> 
> The code change shows some common solutions to avoid such too wide annotations:
> 
> 1. Extract calls into a method and add annotation on that method
> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value.
> 3. Put declaration and assignment into a single statement if possible.
> 4. Rewrite code to achieve #3 above.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  typo on windows

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4138/files
  - new: https://git.openjdk.java.net/jdk/pull/4138/files/e3f0405a..d460efb8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138

PR: https://git.openjdk.java.net/jdk/pull/4138

From pconcannon at openjdk.java.net  Fri May 21 14:00:43 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 21 May 2021 14:00:43 GMT
Subject: RFR: 8267110: Update java.util to use instanceof pattern variable
 [v4]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:

  8267110: Reverted changes made to files in java.util.concurrent

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4088/files
  - new: https://git.openjdk.java.net/jdk/pull/4088/files/da615e7d..2c076a55

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=02-03

  Stats: 31 lines in 5 files changed: 16 ins; 0 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4088.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4088/head:pull/4088

PR: https://git.openjdk.java.net/jdk/pull/4088

From github.com+10835776+stsypanov at openjdk.java.net  Fri May 21 14:04:23 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 21 May 2021 14:04:23 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
Message-ID: <49DKqYCEGnU3_LyaAoKbyyCrNWeOhpyi06nqfNwqtu0=.3de3c091-0eb1-4d37-881c-f532a6a2e120@github.com>

On Fri, 26 Feb 2021 10:48:33 GMT, ?????? ???????  wrote:

> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
> 
> jdk:tier1 and jdk:tier2 are both ok

Hi guys, any more comments here? Please ping me if I've missed something

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From alanb at openjdk.java.net  Fri May 21 14:26:50 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 21 May 2021 14:26:50 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <49DKqYCEGnU3_LyaAoKbyyCrNWeOhpyi06nqfNwqtu0=.3de3c091-0eb1-4d37-881c-f532a6a2e120@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <49DKqYCEGnU3_LyaAoKbyyCrNWeOhpyi06nqfNwqtu0=.3de3c091-0eb1-4d37-881c-f532a6a2e120@github.com>
Message-ID: <7M39TjBM4Y3jcrY8TSkasy25HcSB8WqKOVu_JK5c4mU=.122ac5e0-50e5-4bf6-80ae-e32337c6938d@github.com>

On Fri, 21 May 2021 13:13:04 GMT, ?????? ???????  wrote:

> Hi guys, any more comments here? Please ping me if I've missed something

I suspect this will require renaming some fields and changing comments, e.g. requestList is no longer a good name for the field in AbstractPoller, its comments need changes too. The field in ResolverConfigurationImpl is searchList, it will require a few changes. There may be more, I just picked out a few.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From dfuchs at openjdk.java.net  Fri May 21 14:26:48 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 21 May 2021 14:26:48 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
Message-ID: 

On Fri, 26 Feb 2021 10:48:33 GMT, ?????? ???????  wrote:

> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
> 
> jdk:tier1 and jdk:tier2 are both ok

I don't remember all the comments you have received in this thread but have you verified that arbitrarily changing `LinkedList` into `ArrayList` in these classes is not going to significantly increase the footprint in the case where lists are empty or contain only one or two elements?

I am not convinced that a global replacement of  `LinkedList` by `ArrayList` is necessarily good - even though I agree that `ArrayList` is generally more efficient.

src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 155:

> 153:      */
> 154:     public List get(String fileName) {
> 155:         ArrayList jarFiles;

This could probably be declared as:


List jarFiles;

src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 264:

> 262:                 String jar = jarFiles[i];
> 263:                 bw.write(jar + "\n");
> 264:                 ArrayList jarlist = jarMap.get(jar);

Here again, jarList could probably be declared as `List`

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From kasperni at gmail.com  Fri May 21 14:28:27 2021
From: kasperni at gmail.com (Kasper Nielsen)
Date: Fri, 21 May 2021 15:28:27 +0100
Subject: Java records used in enums
In-Reply-To: 
References: 
Message-ID: 

On Fri, 21 May 2021 at 14:51, Alberto Otero Rodr?guez 
wrote:

> Hi,
>
> I think enums in Java should be immutable. When you let the programmer
> change values in an enum instance, an unexpected behaviour can happen when
> using multiple threads as enum instances are static (singleton).
>
> So, I was wondering why not make enums instances be defined as records
> instead of normal classes.
>

Lots of reasons, for example:
* It would be a breaking change for an almost non-existent problem.
* All internal state of enums would now be public.
* Enum's extend java.lang.Enum, records extend java.lang.Record.
  java.lang.Enum cannot extend java.lang.Record because it has instance
fields.

/Kasper

From robert at marcanoonline.com  Fri May 21 14:54:18 2021
From: robert at marcanoonline.com (Robert Marcano)
Date: Fri, 21 May 2021 10:54:18 -0400
Subject: Java records used in enums
In-Reply-To: 
References: 
 
Message-ID: <7bf091d6-4241-3999-fe8e-e816f1a65378@marcanoonline.com>

On 5/21/21 10:28 AM, Kasper Nielsen wrote:
> On Fri, 21 May 2021 at 14:51, Alberto Otero Rodr?guez 
> wrote:
> 
>> Hi,
>>
>> I think enums in Java should be immutable. When you let the programmer
>> change values in an enum instance, an unexpected behaviour can happen when
>> using multiple threads as enum instances are static (singleton).
>>
>> So, I was wondering why not make enums instances be defined as records
>> instead of normal classes.
>>
> 
> Lots of reasons, for example:
> * It would be a breaking change for an almost non-existent problem.
> * All internal state of enums would now be public.
> * Enum's extend java.lang.Enum, records extend java.lang.Record.
>    java.lang.Enum cannot extend java.lang.Record because it has instance
> fields.
> 
> /Kasper
> 

I could add that making enum records would not solve the proposed 
"problem" because records are shallowly immutable.

I am sure that theoretically, simple enum implementations could be 
treated by the JIT internally as simple indexes as an optimization, I 
don't know if it does something like that already. So I don't think 
records will bring any improvement to enums

From github.com+13357965+thihup at openjdk.java.net  Fri May 21 14:55:16 2021
From: github.com+13357965+thihup at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Fri, 21 May 2021 14:55:16 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
Message-ID: 

On Fri, 26 Feb 2021 10:48:33 GMT, ?????? ???????  wrote:

> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
> 
> jdk:tier1 and jdk:tier2 are both ok

src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 154:

> 152:      * @param fileName the key of the mapping
> 153:      */
> 154:     public List get(String fileName) {

IcedTea-Web seems to be using this method reflectively:
https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From albest512 at hotmail.com  Fri May 21 15:00:10 2021
From: albest512 at hotmail.com (=?iso-8859-1?Q?Alberto_Otero_Rodr=EDguez?=)
Date: Fri, 21 May 2021 15:00:10 +0000
Subject: Java records used in enums
In-Reply-To: 
References: ,
 
Message-ID: 

It seems a non-existent problem until you face it, which is what happened me today.

I think at least (supposing enums can't be records) all the fields in enums should be made final by default.

Regards,

Alberto.
________________________________
De: Kasper Nielsen 
Enviado: viernes, 21 de mayo de 2021 16:28
Para: Alberto Otero Rodr?guez 
Cc: core-libs-dev at openjdk.java.net 
Asunto: Re: Java records used in enums

On Fri, 21 May 2021 at 14:51, Alberto Otero Rodr?guez > wrote:
Hi,

I think enums in Java should be immutable. When you let the programmer change values in an enum instance, an unexpected behaviour can happen when using multiple threads as enum instances are static (singleton).

So, I was wondering why not make enums instances be defined as records instead of normal classes.

Lots of reasons, for example:
* It would be a breaking change for an almost non-existent problem.
* All internal state of enums would now be public.
* Enum's extend java.lang.Enum, records extend java.lang.Record.
  java.lang.Enum cannot extend java.lang.Record because it has instance fields.

/Kasper

From alanb at openjdk.java.net  Fri May 21 15:02:57 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 21 May 2021 15:02:57 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: 
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 
Message-ID: 

On Fri, 21 May 2021 14:52:21 GMT, Thiago Henrique H?pner  wrote:

> IcedTea-Web seems to be using this method reflectively:
> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80

I assume this doesn't work with JDK 16, at least not without using --add-options to export jdk.internal.util.jar.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From liangchenblue at gmail.com  Fri May 21 15:15:50 2021
From: liangchenblue at gmail.com (-)
Date: Fri, 21 May 2021 10:15:50 -0500
Subject: Fwd: Java records used in enums
In-Reply-To: 
References: 
 
 
 
Message-ID: 

---------- Forwarded message ---------
From: - 
Date: Fri, May 21, 2021 at 10:14 AM
Subject: Re: Java records used in enums
To: Alberto Otero Rodr?guez 


I fail to understand what you want. How does making enums records fix the
multithreading issue?

If you wish to have enums declared like records code-wise, I see it as a
possibility, but I don't see how it affects any enum behavior in any way.

If you want a combination of record and enum, or a record with enumerated
possible instances, it may be possible to add an alternative syntax for
such enum declaration; but restricting all enums to be such enum records
offers no benefit that I can see, especially given records themselves have
severe restrictions (must have an accessible canonical ctor available; that
ctor cannot throw checked exceptions; field/getter method name limits, so a
"enum record" cannot declare fields like "values" "name"); also records are
value-based while enums are identity based, which is another problem.

In short, I believe regular enum suffices and a "record enum" offers little
benefit while it cannot fix your issue at all.

On Fri, May 21, 2021 at 10:00 AM Alberto Otero Rodr?guez <
albest512 at hotmail.com> wrote:

> It seems a non-existent problem until you face it, which is what happened
> me today.
>
> I think at least (supposing enums can't be records) all the fields in
> enums should be made final by default.
>
> Regards,
>
> Alberto.
> ________________________________
> De: Kasper Nielsen 
> Enviado: viernes, 21 de mayo de 2021 16:28
> Para: Alberto Otero Rodr?guez 
> Cc: core-libs-dev at openjdk.java.net 
> Asunto: Re: Java records used in enums
>
> On Fri, 21 May 2021 at 14:51, Alberto Otero Rodr?guez <
> albest512 at hotmail.com> wrote:
> Hi,
>
> I think enums in Java should be immutable. When you let the programmer
> change values in an enum instance, an unexpected behaviour can happen when
> using multiple threads as enum instances are static (singleton).
>
> So, I was wondering why not make enums instances be defined as records
> instead of normal classes.
>
> Lots of reasons, for example:
> * It would be a breaking change for an almost non-existent problem.
> * All internal state of enums would now be public.
> * Enum's extend java.lang.Enum, records extend java.lang.Record.
>   java.lang.Enum cannot extend java.lang.Record because it has instance
> fields.
>
> /Kasper
>

From github.com+13357965+thihup at openjdk.java.net  Fri May 21 15:15:15 2021
From: github.com+13357965+thihup at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Fri, 21 May 2021 15:15:15 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: 
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 
 
Message-ID: 

On Fri, 21 May 2021 15:00:15 GMT, Alan Bateman  wrote:

>> src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 154:
>> 
>>> 152:      * @param fileName the key of the mapping
>>> 153:      */
>>> 154:     public List get(String fileName) {
>> 
>> IcedTea-Web seems to be using this method reflectively:
>> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80
>
>> IcedTea-Web seems to be using this method reflectively:
>> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80
> 
> I assume this doesn't work with JDK 16, at least not without using --add-options to export jdk.internal.util.jar.

Just for completeness, they're using the add-exports:
https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/launchers/itw-modularjdk.args#L19

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From albest512 at hotmail.com  Fri May 21 15:28:43 2021
From: albest512 at hotmail.com (=?iso-8859-1?Q?Alberto_Otero_Rodr=EDguez?=)
Date: Fri, 21 May 2021 15:28:43 +0000
Subject: Java records used in enums
In-Reply-To: 
References: 
 
 
 ,
 
Message-ID: 

The problem in my case was that we have an enum ErrorEnum with several fields.

One of the fields was "description" which have a getter and a setter.

The problem appeared when testing with JUnit. Basically the logic of the application was working correctly but the descriptions of the errors of different tests were overriden with the description of the errors of another tests.

The problem was solved by making the fields of the enums final and removing all the setter methods (after trying a lot of things and refactoring the application almost entirely to remove all the static methods and static members we had in the application).

Regards,

Alberto.
________________________________
De: core-libs-dev  en nombre de liangchenblue at gmail.com 
Enviado: viernes, 21 de mayo de 2021 17:15
Para: core-libs-dev at openjdk.java.net 
Asunto: Fwd: Java records used in enums

---------- Forwarded message ---------
From: - 
Date: Fri, May 21, 2021 at 10:14 AM
Subject: Re: Java records used in enums
To: Alberto Otero Rodr?guez 


I fail to understand what you want. How does making enums records fix the
multithreading issue?

If you wish to have enums declared like records code-wise, I see it as a
possibility, but I don't see how it affects any enum behavior in any way.

If you want a combination of record and enum, or a record with enumerated
possible instances, it may be possible to add an alternative syntax for
such enum declaration; but restricting all enums to be such enum records
offers no benefit that I can see, especially given records themselves have
severe restrictions (must have an accessible canonical ctor available; that
ctor cannot throw checked exceptions; field/getter method name limits, so a
"enum record" cannot declare fields like "values" "name"); also records are
value-based while enums are identity based, which is another problem.

In short, I believe regular enum suffices and a "record enum" offers little
benefit while it cannot fix your issue at all.

On Fri, May 21, 2021 at 10:00 AM Alberto Otero Rodr?guez <
albest512 at hotmail.com> wrote:

> It seems a non-existent problem until you face it, which is what happened
> me today.
>
> I think at least (supposing enums can't be records) all the fields in
> enums should be made final by default.
>
> Regards,
>
> Alberto.
> ________________________________
> De: Kasper Nielsen 
> Enviado: viernes, 21 de mayo de 2021 16:28
> Para: Alberto Otero Rodr?guez 
> Cc: core-libs-dev at openjdk.java.net 
> Asunto: Re: Java records used in enums
>
> On Fri, 21 May 2021 at 14:51, Alberto Otero Rodr?guez <
> albest512 at hotmail.com> wrote:
> Hi,
>
> I think enums in Java should be immutable. When you let the programmer
> change values in an enum instance, an unexpected behaviour can happen when
> using multiple threads as enum instances are static (singleton).
>
> So, I was wondering why not make enums instances be defined as records
> instead of normal classes.
>
> Lots of reasons, for example:
> * It would be a breaking change for an almost non-existent problem.
> * All internal state of enums would now be public.
> * Enum's extend java.lang.Enum, records extend java.lang.Record.
>   java.lang.Enum cannot extend java.lang.Record because it has instance
> fields.
>
> /Kasper
>

From kasperni at gmail.com  Fri May 21 15:31:38 2021
From: kasperni at gmail.com (Kasper Nielsen)
Date: Fri, 21 May 2021 16:31:38 +0100
Subject: Java records used in enums
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 21 May 2021 at 16:00, Alberto Otero Rodr?guez 
wrote:

> It seems a non-existent problem until you face it, which is what happened
> me today.
>
> I think at least (supposing enums can't be records) all the fields in
> enums should be made final by default.
>

A suppressible compiler warning on non-final enum fields would probably be
the best bet.

You can actually find some build-in types where the intended behavior is
final
but it was not declared. For example, java.sql.JDBCType [1]. And a couple
of
other internal classes.

/Kasper

[1]
https://github.com/openjdk/jdk/blob/master/src/java.sql/share/classes/java/sql/JDBCType.java

From vromero at openjdk.java.net  Fri May 21 15:31:06 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 21 May 2021 15:31:06 GMT
Subject: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v4]
In-Reply-To: 
References: 
 
Message-ID: 

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 request incrementally with one additional commit since the last revision:
> 
>   Reordering class modifiers

looks good to me

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4135

From jvernee at openjdk.java.net  Fri May 21 15:33:51 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 21 May 2021 15:33:51 GMT
Subject: RFR: 8263087: Add a MethodHandle combinator that switches over a
 set of MethodHandles [v3]
In-Reply-To: 
References: 
Message-ID: 

> This patch adds a `tableSwitch` combinator that can be used to switch over a set of method handles given an index, with a fallback in case the index is out of bounds, much like the `tableswitch` bytecode. Here is a description of how it works (copied from the javadoc):
> 
>      Creates a table switch method handle, which can be used to switch over a set of target
>      method handles, based on a given target index, called selector.
> 
>      For a selector value of {@code n}, where {@code n} falls in the range {@code [0, N)},
>      and where {@code N} is the number of target method handles, the table switch method
>      handle will invoke the n-th target method handle from the list of target method handles.
> 
>      For a selector value that does not fall in the range {@code [0, N)}, the table switch
>      method handle will invoke the given fallback method handle.
> 
>      All method handles passed to this method must have the same type, with the additional
>      requirement that the leading parameter be of type {@code int}. The leading parameter
>      represents the selector.
> 
>      Any trailing parameters present in the type will appear on the returned table switch
>      method handle as well. Any arguments assigned to these parameters will be forwarded,
>      together with the selector value, to the selected method handle when invoking it.
> 
> The combinator does not support specifying the starting index, so the switch cases always run from 0 to however many target handles are specified. A starting index can be added manually with another combination step that filters the input index by adding or subtracting a constant from it, which does not affect performance. One of the reasons for not supporting a starting index is that it allows for more lambda form sharing, but also simplifies the implementation somewhat. I guess an open question is if a convenience overload should be added for that case?
> 
> Lookup switch can also be simulated by filtering the input through an injection function that translates it into a case index, which has also proven to have the ability to have comparable performance to, or even better performance than, a bytecode-native `lookupswitch` instruction. I plan to add such an injection function to the runtime libraries in the future as well. Maybe at that point it could be evaluated if it's worth it to add a lookup switch combinator as well, but I don't see an immediate need to include it in this patch.
> 
> The current bytecode intrinsification generates a call for each switch case, which guarantees full inlining of the target method handles. Alternatively we could only have 1 callsite at the end of the switch, where each case just loads the target method handle, but currently this does not allow for inlining of the handles, since they are not constant.
> 
> Maybe a future C2 optimization could look at the receiver input for invokeBasic call sites, and if the input is a phi node, clone the call for each constant input of the phi. I believe that would allow simplifying the bytecode without giving up on inlining.
> 
> Some numbers from the added benchmarks:
> 
> Benchmark                                        (numCases)  (offset)  (sorted)  Mode  Cnt   Score   Error  Units
> MethodHandlesTableSwitchConstant.testSwitch               5         0       N/A  avgt   30   4.186 ? 0.054  ms/op
> MethodHandlesTableSwitchConstant.testSwitch               5       150       N/A  avgt   30   4.164 ? 0.057  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              10         0       N/A  avgt   30   4.124 ? 0.023  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              10       150       N/A  avgt   30   4.126 ? 0.025  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              25         0       N/A  avgt   30   4.137 ? 0.042  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              25       150       N/A  avgt   30   4.113 ? 0.016  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              50         0       N/A  avgt   30   4.118 ? 0.028  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              50       150       N/A  avgt   30   4.127 ? 0.019  ms/op
> MethodHandlesTableSwitchConstant.testSwitch             100         0       N/A  avgt   30   4.116 ? 0.013  ms/op
> MethodHandlesTableSwitchConstant.testSwitch             100       150       N/A  avgt   30   4.121 ? 0.020  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5         0       N/A  avgt   30   4.113 ? 0.009  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5       150       N/A  avgt   30   4.149 ? 0.041  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10         0       N/A  avgt   30   4.121 ? 0.026  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10       150       N/A  avgt   30   4.113 ? 0.021  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25         0       N/A  avgt   30   4.129 ? 0.028  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25       150       N/A  avgt   30   4.105 ? 0.019  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50         0       N/A  avgt   30   4.097 ? 0.021  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50       150       N/A  avgt   30   4.131 ? 0.037  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100         0       N/A  avgt   30   4.135 ? 0.025  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100       150       N/A  avgt   30   4.139 ? 0.145  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5         0      true  avgt   30   4.894 ? 0.028  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5         0     false  avgt   30  11.526 ? 0.194  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5       150      true  avgt   30   4.882 ? 0.025  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5       150     false  avgt   30  11.532 ? 0.034  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10         0      true  avgt   30   5.065 ? 0.076  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10         0     false  avgt   30  13.016 ? 0.020  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10       150      true  avgt   30   5.103 ? 0.051  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10       150     false  avgt   30  12.984 ? 0.102  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25         0      true  avgt   30   8.441 ? 0.165  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25         0     false  avgt   30  13.371 ? 0.060  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25       150      true  avgt   30   8.628 ? 0.032  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25       150     false  avgt   30  13.542 ? 0.020  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50         0      true  avgt   30   4.701 ? 0.015  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50         0     false  avgt   30  13.562 ? 0.063  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50       150      true  avgt   30   7.991 ? 3.111  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50       150     false  avgt   30  13.543 ? 0.088  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100         0      true  avgt   30   4.712 ? 0.020  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100         0     false  avgt   30  13.600 ? 0.085  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100       150      true  avgt   30   4.676 ? 0.011  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100       150     false  avgt   30  13.476 ? 0.043  ms/op
> 
> 
> Testing:
> - [x] Running of included benchmarks
> - [x] Inspecting inlining trace and verifying method handle targets are inlined
> - [x] Running TestTableSwitch test (currently the only user of the new code)
> - [x] Running java/lang/invoke tests (just in case)
> - [x] Some manual testing
> 
> Thanks,
> Jorn

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Added usage example to javadoc

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3401/files
  - new: https://git.openjdk.java.net/jdk/pull/3401/files/80a706f1..0e3f96a3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3401&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3401&range=01-02

  Stats: 26 lines in 1 file changed: 26 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3401.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3401/head:pull/3401

PR: https://git.openjdk.java.net/jdk/pull/3401

From jvernee at openjdk.java.net  Fri May 21 15:34:11 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 21 May 2021 15:34:11 GMT
Subject: RFR: 8263087: Add a MethodHandle combinator that switches over a
 set of MethodHandles [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 17 May 2021 17:19:16 GMT, Jorn Vernee  wrote:

>> This patch adds a `tableSwitch` combinator that can be used to switch over a set of method handles given an index, with a fallback in case the index is out of bounds, much like the `tableswitch` bytecode. Here is a description of how it works (copied from the javadoc):
>> 
>>      Creates a table switch method handle, which can be used to switch over a set of target
>>      method handles, based on a given target index, called selector.
>> 
>>      For a selector value of {@code n}, where {@code n} falls in the range {@code [0, N)},
>>      and where {@code N} is the number of target method handles, the table switch method
>>      handle will invoke the n-th target method handle from the list of target method handles.
>> 
>>      For a selector value that does not fall in the range {@code [0, N)}, the table switch
>>      method handle will invoke the given fallback method handle.
>> 
>>      All method handles passed to this method must have the same type, with the additional
>>      requirement that the leading parameter be of type {@code int}. The leading parameter
>>      represents the selector.
>> 
>>      Any trailing parameters present in the type will appear on the returned table switch
>>      method handle as well. Any arguments assigned to these parameters will be forwarded,
>>      together with the selector value, to the selected method handle when invoking it.
>> 
>> The combinator does not support specifying the starting index, so the switch cases always run from 0 to however many target handles are specified. A starting index can be added manually with another combination step that filters the input index by adding or subtracting a constant from it, which does not affect performance. One of the reasons for not supporting a starting index is that it allows for more lambda form sharing, but also simplifies the implementation somewhat. I guess an open question is if a convenience overload should be added for that case?
>> 
>> Lookup switch can also be simulated by filtering the input through an injection function that translates it into a case index, which has also proven to have the ability to have comparable performance to, or even better performance than, a bytecode-native `lookupswitch` instruction. I plan to add such an injection function to the runtime libraries in the future as well. Maybe at that point it could be evaluated if it's worth it to add a lookup switch combinator as well, but I don't see an immediate need to include it in this patch.
>> 
>> The current bytecode intrinsification generates a call for each switch case, which guarantees full inlining of the target method handles. Alternatively we could only have 1 callsite at the end of the switch, where each case just loads the target method handle, but currently this does not allow for inlining of the handles, since they are not constant.
>> 
>> Maybe a future C2 optimization could look at the receiver input for invokeBasic call sites, and if the input is a phi node, clone the call for each constant input of the phi. I believe that would allow simplifying the bytecode without giving up on inlining.
>> 
>> Some numbers from the added benchmarks:
>> 
>> Benchmark                                        (numCases)  (offset)  (sorted)  Mode  Cnt   Score   Error  Units
>> MethodHandlesTableSwitchConstant.testSwitch               5         0       N/A  avgt   30   4.186 ? 0.054  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch               5       150       N/A  avgt   30   4.164 ? 0.057  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              10         0       N/A  avgt   30   4.124 ? 0.023  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              10       150       N/A  avgt   30   4.126 ? 0.025  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              25         0       N/A  avgt   30   4.137 ? 0.042  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              25       150       N/A  avgt   30   4.113 ? 0.016  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              50         0       N/A  avgt   30   4.118 ? 0.028  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              50       150       N/A  avgt   30   4.127 ? 0.019  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch             100         0       N/A  avgt   30   4.116 ? 0.013  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch             100       150       N/A  avgt   30   4.121 ? 0.020  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5         0       N/A  avgt   30   4.113 ? 0.009  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5       150       N/A  avgt   30   4.149 ? 0.041  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10         0       N/A  avgt   30   4.121 ? 0.026  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10       150       N/A  avgt   30   4.113 ? 0.021  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25         0       N/A  avgt   30   4.129 ? 0.028  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25       150       N/A  avgt   30   4.105 ? 0.019  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50         0       N/A  avgt   30   4.097 ? 0.021  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50       150       N/A  avgt   30   4.131 ? 0.037  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100         0       N/A  avgt   30   4.135 ? 0.025  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100       150       N/A  avgt   30   4.139 ? 0.145  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                 5         0      true  avgt   30   4.894 ? 0.028  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                 5         0     false  avgt   30  11.526 ? 0.194  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                 5       150      true  avgt   30   4.882 ? 0.025  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                 5       150     false  avgt   30  11.532 ? 0.034  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                10         0      true  avgt   30   5.065 ? 0.076  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                10         0     false  avgt   30  13.016 ? 0.020  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                10       150      true  avgt   30   5.103 ? 0.051  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                10       150     false  avgt   30  12.984 ? 0.102  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                25         0      true  avgt   30   8.441 ? 0.165  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                25         0     false  avgt   30  13.371 ? 0.060  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                25       150      true  avgt   30   8.628 ? 0.032  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                25       150     false  avgt   30  13.542 ? 0.020  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                50         0      true  avgt   30   4.701 ? 0.015  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                50         0     false  avgt   30  13.562 ? 0.063  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                50       150      true  avgt   30   7.991 ? 3.111  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                50       150     false  avgt   30  13.543 ? 0.088  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch               100         0      true  avgt   30   4.712 ? 0.020  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch               100         0     false  avgt   30  13.600 ? 0.085  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch               100       150      true  avgt   30   4.676 ? 0.011  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch               100       150     false  avgt   30  13.476 ? 0.043  ms/op
>> 
>> 
>> Testing:
>> - [x] Running of included benchmarks
>> - [x] Inspecting inlining trace and verifying method handle targets are inlined
>> - [x] Running TestTableSwitch test (currently the only user of the new code)
>> - [x] Running java/lang/invoke tests (just in case)
>> - [x] Some manual testing
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee 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 two additional commits since the last revision:
> 
>  - - Formatting
>    - Reduce benchmark cases
>    - Remove NamedFunction::intrinsicName
>  - All changes prior to review

I've added a usage example to the javadoc in response to a review comment on the CSR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3401

From albest512 at hotmail.com  Fri May 21 15:37:04 2021
From: albest512 at hotmail.com (=?iso-8859-1?Q?Alberto_Otero_Rodr=EDguez?=)
Date: Fri, 21 May 2021 15:37:04 +0000
Subject: Builder pattern for Java records
Message-ID: 

Hi, I have found this project on GitHub which creates a Builder for Java records:
https://github.com/Randgalt/record-builder
[https://opengraph.githubassets.com/a4e3a7b3c7b16b51e0854011fe4b031577bcc09919058baef412b03613295d20/Randgalt/record-builder]
GitHub - Randgalt/record-builder: Record builder generator for Java records
The target package for generation is the same as the package that contains the "Include" annotation. Use packagePattern to change this (see Javadoc for details).. Usage Maven. Add the dependency that contains the @RecordBuilder annotation. < dependency > < groupId >io.soabase.record-builder < artifactId >record-builder-core < version >set-version-here
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Wed, 19 May 2021 13:47:53 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

src/java.base/share/classes/java/lang/SecurityManager.java line 104:

> 102:  * method will throw an {@code UnsupportedOperationException}). If the
> 103:  * {@systemProperty java.security.manager} system property is set to the
> 104:  * special token "{@code allow}", then a security manager will not be set at

Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From avoitylov at openjdk.java.net  Fri May 21 15:42:51 2021
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Fri, 21 May 2021 15:42:51 GMT
Subject: RFR: 8266310: deadlock while loading the JNI code [v4]
In-Reply-To: 
References: 
Message-ID: 

> 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 library load operation.
> 
> Problem being fixed:
> 
> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread.
> 
> Proposed fix:
> 
> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method.
> 
> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared.
> 
> Testing:  jtreg and jck testing with no regressions. A new regression test was developed.

Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:

  revert to a version with lock on library name while fixing all other comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3976/files
  - new: https://git.openjdk.java.net/jdk/pull/3976/files/8f47d890..5e62b308

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3976&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3976&range=02-03

  Stats: 119 lines in 3 files changed: 43 ins; 22 del; 54 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3976.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3976/head:pull/3976

PR: https://git.openjdk.java.net/jdk/pull/3976

From avoitylov at openjdk.java.net  Fri May 21 15:42:54 2021
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Fri, 21 May 2021 15:42:54 GMT
Subject: RFR: 8266310: deadlock while loading the JNI code [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 19 May 2021 18:47:52 GMT, Jorn Vernee  wrote:

>> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix trailing whitespace
>
> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 262:
> 
>> 260:         } finally {
>> 261:             releaseNativeLibraryLock(name);
>> 262:         }
> 
> The new locking scheme looks incorrect to me. It now seems possible for 2 different class loaders in 2 different threads to load the same library (which should not be possible).
> 
> Thread 1:
>   - acquires name lock
>   - checks library name is already in `loadedLibraryNames` (it's not)
>   - release name lock
>   - start loading library
>   
> Then thread 2 comes in and does the same
>   
> Then again thread 1 finishes loading and:
>  - acquires name lock
>  - puts library name in `loadedLibraryNames`
>  - puts library name in it's own `libraries`
>  - release lock
>  
> Then thread 2 comes in and does the same again (although adding the name to `loadedLibraryNames` will silently return `false`).
> 
> It seems that this scenario is possible, and the library will be loaded by 2 different class loaders, each with their own `lib` object. (If there's a race, there has to be a loser as well, which would need to discard their work when finding out they lost)
> 
> You might be able to stress this by checking if `loadedLibraryNames.add(name);` returns `true`, and throwing an exception if not.
> 
> I think a possible solution would be to claim the library name up front for a particular loader. Then 2 threads can still race to load the same library for the same class loader, but 2 threads with 2 different class loaders racing to load the library should not be possible.
> 
> Actually, you might be able to prevent a race on JNI_OnLoad altogether by claiming the library name for a particular thread upfront as well (e.g. using a `ConcurrentHashMap`).

Thank you, the previous version of the PR suffered from other problems as well. 

The PR is now reverted to a scheme with a lock held on library name, thus such a situation is no longer possible.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3976

From avoitylov at openjdk.java.net  Fri May 21 15:49:09 2021
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Fri, 21 May 2021 15:49:09 GMT
Subject: RFR: 8266310: deadlock while loading the JNI code [v5]
In-Reply-To: 
References: 
Message-ID: 

> 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 library load operation.
> 
> Problem being fixed:
> 
> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread.
> 
> Proposed fix:
> 
> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method.
> 
> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared.
> 
> Testing:  jtreg and jck testing with no regressions. A new regression test was developed.

Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:

  fix whitespace

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3976/files
  - new: https://git.openjdk.java.net/jdk/pull/3976/files/5e62b308..8e735117

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3976&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3976&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3976.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3976/head:pull/3976

PR: https://git.openjdk.java.net/jdk/pull/3976

From dfuchs at openjdk.java.net  Fri May 21 15:55:07 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 21 May 2021 15:55:07 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 21 May 2021 14:00:39 GMT, Weijun Wang  wrote:

>> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
>> 
>> The code change shows some common solutions to avoid such too wide annotations:
>> 
>> 1. Extract calls into a method and add annotation on that method
>> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value.
>> 3. Put declaration and assignment into a single statement if possible.
>> 4. Rewrite code to achieve #3 above.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo on windows

src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 120:

> 118:                         vals[1] = Integer.getInteger("sun.net.client.defaultConnectTimeout", 300_000).intValue();
> 119:                         return System.getProperty("file.encoding", "ISO8859_1");
> 120:                     }

It is a bit strange that "file.encoding" seem to get a special treatment - but I guess that's OK.

src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 550:

> 548:      * @throws IOException if the connection was unsuccessful.
> 549:      */
> 550:     @SuppressWarnings("removal")

Could the scope of the annotation be further reduced by applying it to the two places where `doPrivileged` is called in this method?

src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 921:

> 919:     }
> 920: 
> 921:     @SuppressWarnings("removal")

Could the scope be further reduced by applying it at line 926 in this method - at the cost of creating a temporary variable? The code could probably be further simplified by using a lambda...


            PrivilegedAction pa = () -> new Socket(proxy);
            @SuppressWarnings("removal")
            var ps = AccessController.doPrivileged(pa);
            s = ps;

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From avoitylov at openjdk.java.net  Fri May 21 15:56:08 2021
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Fri, 21 May 2021 15:56:08 GMT
Subject: RFR: 8266310: deadlock while loading the JNI code [v5]
In-Reply-To: 
References: 
 
Message-ID: 

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 library load operation.
>> 
>> Problem being fixed:
>> 
>> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread.
>> 
>> Proposed fix:
>> 
>> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method.
>> 
>> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared.
>> 
>> Testing:  jtreg and jck testing with no regressions. A new regression test was developed.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix whitespace

The PR was updated as follows:

- the fix resolves the deadlock problem when different libraries are loaded. 
- the lock on the library name is held just like in the first version of PR to avoid simultaneous JNI_OnLoad calls. 
- the test now checks that JNI_Onload and JNI_OnUnload are executed only once.

Within the current limitations it is not possible to resolve the deadlock when a library being loaded attempts, in JNI_OnLoad,  to load a class that depends on the same library. It is not the intent of this PR to do so.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3976

From chegar at openjdk.java.net  Fri May 21 15:58:00 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 21 May 2021 15:58:00 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
Message-ID: 

On Thu, 20 May 2021 16:10:11 GMT, Roger Riggs  wrote:

>> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
>> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
>> configuration mechanisms and filter utilities.
>> 
>> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`:
>>     http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify factory interface to BinaryOperator and cleanup the example

src/java.base/share/classes/java/io/ObjectInputFilter.java line 365:

> 363:      * A utility class to set and get the JVM-wide deserialization filter factory,
> 364:      * the static JVM-wide filter, or to create a filter from a pattern string.
> 365:      * If a JVM-wide filter factory or static JVM-wide filter is set, it will determine the filter

This concerns me, "A JVM-wide filter factory". I was going to suggest that it should be "The ..", but then realised that there can only ever be one present at a time, but in the lifetime of a JVM there can be two (since getSerialFilterFactory if invoked before setSerialFilterFactory will subsequently return a different JVM-wide factory).   Is this intentional? It would great if this could be "The ..", so that setXXX can only be invoked successfully if getXXX has not been.   This may seen somewhat insignificant, but the fact that the JVM-wide factory can change make the model harder understand.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From chegar at openjdk.java.net  Fri May 21 15:58:01 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 21 May 2021 15:58:01 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: 
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
 
Message-ID: 

On Fri, 21 May 2021 03:02:43 GMT, Brent Christian  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify factory interface to BinaryOperator and cleanup the example
>
> src/java.base/share/classes/java/io/ObjectInputStream.java line 193:
> 
>> 191:  * the state.
>> 192:  *
>> 193:  * The deserialization filter for a stream is determined in one of the following ways:
> 
> Should this line start with a `
    ` ?

At this point in the OIS spec it would be good to introduce the idea of a stream-specific filter. Maybe open this paragraph with some additional context, like say:


 * 
     An {@code ObjectInputStream} has an optional stream-specific
 * deserialization filter. The stream-specific deserialization filter
 * is determined in one of the following ways:


then enumerate the ways in which the stream-specific deserialization filter is determine, and drop how the filter factory can be set, etc. That is best left to the Config.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From chegar at openjdk.java.net  Fri May 21 16:13:08 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 21 May 2021 16:13:08 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
Message-ID: 

On Thu, 20 May 2021 16:10:11 GMT, Roger Riggs  wrote:

>> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
>> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
>> configuration mechanisms and filter utilities.
>> 
>> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`:
>>     http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify factory interface to BinaryOperator and cleanup the example

src/java.base/share/classes/java/io/ObjectInputFilter.java line 56:

> 54:  * 
    
> 55:  *
> 56:  * 
    To protect the JVM against deserialization vulnerabilities, application developers

I would personally drop "the JVM", leaving "To protect against deserialization ..", since the protection is applicable to more than the JVM ( applications, libraries, etc).

src/java.base/share/classes/java/io/ObjectInputFilter.java line 58:

> 56:  * 
    To protect the JVM against deserialization vulnerabilities, application developers
> 57:  * need a clear description of the objects that can be serialized or deserialized
> 58:  * by each component or library. For each context and use case, developers should

drop "serialized or" - filtering is not relevant to serializing.

src/java.base/share/classes/java/io/ObjectInputFilter.java line 75:

> 73:  * protect individual contexts by providing a custom filter for each. When the stream
> 74:  * is constructed, the filter factory can identify the execution context based upon
> 75:  * the current thread-local state, hierarchy of callers, library, module, and class loader.

This list looks like it is enumerating what the filter factory does, but it is just an example of what could be done. Maybe that needs to be made more explicit. ".. the filter factory can identify execution context based upon, say, ... whatever it likes .. system nanoTime, ... " Or just add "e.g."

src/java.base/share/classes/java/io/ObjectInputFilter.java line 107:

> 105:  *     Note that the filter may be used directly or combined with other filters by the
> 106:  *     {@linkplain Config#setSerialFilterFactory(BinaryOperator) JVM-wide filter factory}.
> 107:  * 

This list is a little confusing to me, but could be that I don't fully grok it yet. getSerialFilterFactory returns THE JVM-wide factory, whether that be the built-in factory implementation or not is somewhat irrelevant. No need to treat them differently - one either sets a factory (in which case that is the JVM-wide factory), or one does not set the factory (in which case the built-in factory is the JVM-wide factory).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From chegar at openjdk.java.net  Fri May 21 16:30:01 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 21 May 2021 16:30:01 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
Message-ID: 

On Thu, 20 May 2021 16:10:11 GMT, Roger Riggs  wrote:

>> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
>> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
>> configuration mechanisms and filter utilities.
>> 
>> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`:
>>     http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify factory interface to BinaryOperator and cleanup the example

src/java.base/share/classes/java/io/ObjectInputFilter.java line 559:

> 557:          * Returns the static JVM-wide deserialization filter or {@code null} if not configured.
> 558:          *
> 559:          * @return the static JVM-wide deserialization filter or {@code null} if not configured

Is "static" significant here? Can it be dropped?   I fine myself questioning if the "static JVM-wide" and "JVM-wide" are two different filters. If we do this then we have just two terms: 1) the "JVM-wide deserialization filter" and 2) the "JVM-wide deserialization filter factory".

Additionally, can you please check all occurrence of these, to ensure that they are used consistently in all parts of the spec. I think I see serial/serialization (without the "de" ) used in a few places.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From rriggs at openjdk.java.net  Fri May 21 16:30:02 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 21 May 2021 16:30:02 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: 
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
 
Message-ID: <-Rpcq-g6N5dUfBhonX_RiBq7d1smTLBC5FhV1a-fIJU=.b0d003eb-082c-41e1-b981-857b4b70390b@github.com>

On Thu, 20 May 2021 19:04:25 GMT, Daniel Fuchs  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify factory interface to BinaryOperator and cleanup the example
>
> src/java.base/share/classes/java/io/ObjectInputFilter.java line 1139:
> 
>> 1137:          * and not classes.
>> 1138:          */
>> 1139:         private static class AllowMaxLimitsFilter implements ObjectInputFilter {
> 
> This class is maybe misnamed. If limitCheck == REJECTED it will not allow max limits. Or am I missing something?

Rejection always wins in the larger scheme of things; another filter may reject based on other limits.
In the composition of filters, any UNDECIDED results must eventually be decided.
This filter maps, for a limit check, the UNDECIDED to allowed; it does nothing for checks for classes.
Other names considered,  allowUnlimited().  Also, not guaranteed.
Perhaps, something in the xxxElseYyy family.  Will reconsider the name.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From rriggs at openjdk.java.net  Fri May 21 16:33:02 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 21 May 2021 16:33:02 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: 
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
 
Message-ID: 

On Thu, 20 May 2021 19:11:34 GMT, Daniel Fuchs  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify factory interface to BinaryOperator and cleanup the example
>
> src/java.base/share/classes/java/io/ObjectInputFilter.java line 1270:
> 
>> 1268:              *       is not {@code null} and is not the JVM-wide filter
>> 1269:              * @throws SecurityException if there is security manager and the
>> 1270:              *       {@code SerializablePermission("serialFilter")} is not granted
> 
> Where is this thrown? I don't see it in the implementation of `apply` below.

The throws clause is not needed, it is thrown in OIS.setObjectInputFilter.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From mchung at openjdk.java.net  Fri May 21 16:43:58 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 21 May 2021 16:43:58 GMT
Subject: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v4]
In-Reply-To: 
References: 
 
Message-ID: 

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 request incrementally with one additional commit since the last revision:
> 
>   Reordering class modifiers

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4135

From rriggs at openjdk.java.net  Fri May 21 17:11:59 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 21 May 2021 17:11:59 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: 
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
 
Message-ID: 

On Fri, 21 May 2021 15:54:50 GMT, Chris Hegarty  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify factory interface to BinaryOperator and cleanup the example
>
> src/java.base/share/classes/java/io/ObjectInputFilter.java line 365:
> 
>> 363:      * A utility class to set and get the JVM-wide deserialization filter factory,
>> 364:      * the static JVM-wide filter, or to create a filter from a pattern string.
>> 365:      * If a JVM-wide filter factory or static JVM-wide filter is set, it will determine the filter
> 
> This concerns me, "A JVM-wide filter factory". I was going to suggest that it should be "The ..", but then realised that there can only ever be one present at a time, but in the lifetime of a JVM there can be two (since getSerialFilterFactory if invoked before setSerialFilterFactory will subsequently return a different JVM-wide factory).   Is this intentional? It would great if this could be "The ..", so that setXXX can only be invoked successfully if getXXX has not been.   This may seen somewhat insignificant, but the fact that the JVM-wide factory can change make the model harder understand.

It is reasonable to require that the factory be set before any OIS is constructed.
Similar to the restriction that the filter on a stream cannot be changed after the first call to readObject.
So an IllegalStateException added to Config.setSerialFilterFactory.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From rriggs at openjdk.java.net  Fri May 21 17:16:59 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 21 May 2021 17:16:59 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: 
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
 
Message-ID: 

On Fri, 21 May 2021 15:58:15 GMT, Chris Hegarty  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify factory interface to BinaryOperator and cleanup the example
>
> src/java.base/share/classes/java/io/ObjectInputFilter.java line 56:
> 
>> 54:  * 
    
>> 55:  *
>> 56:  * 
    To protect the JVM against deserialization vulnerabilities, application developers
> 
> I would personally drop "the JVM", leaving "To protect against deserialization ..", since the protection is applicable to more than the JVM ( applications, libraries, etc).

There's a terminology push and pull about what to call everything in the java runtime.
Some use the term system, a few use JVM, etc.  The terminology here came from the JEP.
In this context is it unnecessary.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From rriggs at openjdk.java.net  Fri May 21 17:20:00 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 21 May 2021 17:20:00 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: 
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
 
Message-ID: 

On Fri, 21 May 2021 16:05:59 GMT, Chris Hegarty  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify factory interface to BinaryOperator and cleanup the example
>
> src/java.base/share/classes/java/io/ObjectInputFilter.java line 75:
> 
>> 73:  * protect individual contexts by providing a custom filter for each. When the stream
>> 74:  * is constructed, the filter factory can identify the execution context based upon
>> 75:  * the current thread-local state, hierarchy of callers, library, module, and class loader.
> 
> This list looks like it is enumerating what the filter factory does, but it is just an example of what could be done. Maybe that needs to be made more explicit. ".. the filter factory can identify execution context based upon, say, ... whatever it likes .. system nanoTime, ... " Or just add "e.g."

More verbiage  from the JEP.  Adding 'for example' or 'including' reinforces the 'can'.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From rriggs at openjdk.java.net  Fri May 21 17:24:15 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 21 May 2021 17:24:15 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: 
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
 
Message-ID: 

On Fri, 21 May 2021 16:09:45 GMT, Chris Hegarty  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify factory interface to BinaryOperator and cleanup the example
>
> src/java.base/share/classes/java/io/ObjectInputFilter.java line 107:
> 
>> 105:  *     Note that the filter may be used directly or combined with other filters by the
>> 106:  *     {@linkplain Config#setSerialFilterFactory(BinaryOperator) JVM-wide filter factory}.
>> 107:  * 
> 
> This list is a little confusing to me, but could be that I don't fully grok it yet. getSerialFilterFactory returns THE JVM-wide factory, whether that be the built-in factory implementation or not is somewhat irrelevant. No need to treat them differently - one either sets a factory (in which case that is the JVM-wide factory), or one does not set the factory (in which case the built-in factory is the JVM-wide factory).

In previous versions, calling OIS.setObjectInputFilter determined exactly the filter used for the stream.
With the filter factory enhancement, the current filter factory determines how the argument to OIS.setObjectInputFilter is used. There are plenty of cases where the filter factory will combine it with other filters and the composite will becomes the filter for the stream.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From rriggs at openjdk.java.net  Fri May 21 17:27:58 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 21 May 2021 17:27:58 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: 
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
 
Message-ID: 

On Fri, 21 May 2021 16:25:58 GMT, Chris Hegarty  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify factory interface to BinaryOperator and cleanup the example
>
> src/java.base/share/classes/java/io/ObjectInputFilter.java line 559:
> 
>> 557:          * Returns the static JVM-wide deserialization filter or {@code null} if not configured.
>> 558:          *
>> 559:          * @return the static JVM-wide deserialization filter or {@code null} if not configured
> 
> Is "static" significant here? Can it be dropped?   I fine myself questioning if the "static JVM-wide" and "JVM-wide" are two different filters. If we do this then we have just two terms: 1) the "JVM-wide deserialization filter" and 2) the "JVM-wide deserialization filter factory".
> 
> Additionally, can you please check all occurrence of these, to ensure that they are used consistently in all parts of the spec. I think I see serial/serialization (without the "de" ) used in a few places.

The static is intended to distinguish that single filter from the others.  The static vs current distinction is part of JEP 290 from which this evolved.  The migration to "de-serialization" from the previous "serialization" is as yet incomplete.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From rriggs at openjdk.java.net  Fri May 21 17:47:53 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 21 May 2021 17:47:53 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v4]
In-Reply-To: 
References: 
Message-ID: 

> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
> configuration mechanisms and filter utilities.
> 
> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`:
>     http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Editorial updates to review comments
  Add filter tracing support

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3996/files
  - new: https://git.openjdk.java.net/jdk/pull/3996/files/f1c5cd85..a0785e88

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=02-03

  Stats: 160 lines in 3 files changed: 69 ins; 21 del; 70 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3996.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3996/head:pull/3996

PR: https://git.openjdk.java.net/jdk/pull/3996

From rriggs at openjdk.java.net  Fri May 21 17:47:56 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 21 May 2021 17:47:56 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: 
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
 
Message-ID: 

On Thu, 20 May 2021 18:59:58 GMT, Daniel Fuchs  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify factory interface to BinaryOperator and cleanup the example
>
> src/java.base/share/classes/java/io/ObjectInputFilter.java line 1079:
> 
>> 1077:                 }
>> 1078:                 // There are no classes to check and none of the limits have been exceeded.
>> 1079:                 return Status.ALLOWED;
> 
> Should this be addressed outside of this JEP and pushed separately?

Reverted, it might be a useful change but has compatibility concerns.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From rriggs at openjdk.java.net  Fri May 21 17:51:01 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 21 May 2021 17:51:01 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 21 May 2021 17:47:53 GMT, Roger Riggs  wrote:

>> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
>> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
>> configuration mechanisms and filter utilities.
>> 
>> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`:
>>     http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Editorial updates to review comments
>   Add filter tracing support

To avoid spamming folks with individual emails, I marked as 'resolved' comments that didn't need a response other than 'ok, will fix'.  Feel free to re-open them or re-comment if you don't see the fix. 
Thanks for the comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From prr at openjdk.java.net  Fri May 21 18:03:01 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 18:03:01 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
 
 
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 
 
Message-ID: 

On Thu, 20 May 2021 07:06:00 GMT, Alan Bateman  wrote:

>> The JEP isn't PTT for 17 so there's plenty of time isn't there ?
>
> There are 827 files in this patch. Phil is right that adding SW at the class level is introducing technical debt but if addressing that requires refactoring and re-testing of AWT or font code then it would be better to have someone from that area working on. Is there any reason why this can't be going on now on awt-dev/2d-dev and integrated immediately after JEP 411? I don't think we should put Max through the wringer here as there are too many areas to cover.

Are you suggesting that the patch doesn't need testing as it is ? It should be the same either way.
It is very straight forward to run the automated tests across all platforms these days.
I get the impression that no one is guaranteeing to do this straight after integration.
It sounds like it is up for deferral if time runs out.

The amount of follow-on work that I am hearing about here, and may be for tests, does not  make it sound
like this JEP is nearly as done as first presented.

If there was some expectation that groups responsible for an area would get involved with this
issue which I am assured was already known about, then why was it not raised before and made
part of the plan ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From peter.levart at gmail.com  Fri May 21 18:10:02 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 21 May 2021 20:10:02 +0200
Subject: RFR: 8266310: deadlock while loading the JNI code [v2]
In-Reply-To: <7b625acd-9c83-e4cf-02cd-ff534ecdffa3@gmail.com>
References: 
 <7uREVWzjGhgjYBdEpYZ5OBurn9FzSuu-TG9_xIu-syc=.c737c435-734e-4e79-9969-cf0d2147ac07@github.com>
 
 
 <1b1189d6-f340-9220-73f0-185411262a21@gmail.com>
 <253df918-7106-1930-5963-877e58e7b26a@oracle.com>
 <7b625acd-9c83-e4cf-02cd-ff534ecdffa3@gmail.com>
Message-ID: <84442ae7-9924-ff8d-2c6c-ec45dd09153e@gmail.com>


On 21/05/2021 10:29, Peter Levart wrote:
> I still haven't found a scenario of a possible deadlock when Sergei's 
> initial patch is combined with...


Sorry Aleksei, I renamed you to Sergei without intention. Please excuse me.


Peter



From sviswanathan at openjdk.java.net  Fri May 21 18:18:30 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 21 May 2021 18:18:30 GMT
Subject: Integrated: 8267190: Optimize Vector API test operations
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 May 2021 23:58:38 GMT, Sandhya Viswanathan  wrote:

> Vector API test operations (IS_DEFAULT, IS_FINITE, IS_INFINITE, IS_NAN and IS_NEGATIVE) are computed in three steps:
> 1) reinterpreting the floating point vectors as integral vectors (int/long)
> 2) perform the test in integer domain to get a int/long mask
> 3) reinterpret the int/long mask as float/double mask
> Step 3) currently is very slow. It can be optimized by modifying the Java code to utilize the existing reinterpret intrinsic.
> 
> For the VectorTestPerf attached to the JBS for JDK-8267190, the performance improves as follows:
> 
> Base:
> Benchmark (size) Mode Cnt Score Error Units
> VectorTestPerf.IS_DEFAULT 1024 thrpt 5 223.156 ? 90.452 ops/ms
> VectorTestPerf.IS_FINITE 1024 thrpt 5 223.841 ? 91.685 ops/ms
> VectorTestPerf.IS_INFINITE 1024 thrpt 5 224.561 ? 83.890 ops/ms
> VectorTestPerf.IS_NAN 1024 thrpt 5 223.777 ? 70.629 ops/ms
> VectorTestPerf.IS_NEGATIVE 1024 thrpt 5 218.392 ? 79.806 ops/ms
> 
> With patch:
> Benchmark (size) Mode Cnt Score Error Units
> VectorTestPerf.IS_DEFAULT 1024 thrpt 5 8812.357 ? 40.477 ops/ms
> VectorTestPerf.IS_FINITE 1024 thrpt 5 7425.739 ? 296.622 ops/ms
> VectorTestPerf.IS_INFINITE 1024 thrpt 5 8932.730 ? 269.988 ops/ms
> VectorTestPerf.IS_NAN 1024 thrpt 5 8574.872 ? 498.649 ops/ms
> VectorTestPerf.IS_NEGATIVE 1024 thrpt 5 8838.400 ? 11.849 ops/ms
> 
> Best Regards,
> Sandhya

This pull request has now been integrated.

Changeset: 8f10c5a8
Author:    Sandhya Viswanathan 
URL:       https://git.openjdk.java.net/jdk/commit/8f10c5a8900517cfa04256eab909e18535086b98
Stats:     1274 lines in 32 files changed: 652 ins; 279 del; 343 mod

8267190: Optimize Vector API test operations

Reviewed-by: psandoz, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/4039

From prr at openjdk.java.net  Fri May 21 18:31:01 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 18:31:01 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: 
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 
Message-ID: <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>

On Tue, 18 May 2021 21:44:43 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.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust order of VM options

The client changes are fine except for the one misplaced (c)

test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3:

> 1: /*
> 2:  * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights reserved.
> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

Probably the (c) update was meant to be on the .sh file that is actually modified.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4071

From vromero at openjdk.java.net  Fri May 21 19:09:59 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 21 May 2021 19:09:59 GMT
Subject: RFR: 8224158: assertion related to NPE at
 DynamicCallSiteDesc::withArgs should be reworded
In-Reply-To: 
References: 
Message-ID: 

On Mon, 17 May 2021 16:53:24 GMT, Vicente Romero  wrote:

> This is a very small patch that is just rewording the spec for DynamicCallSiteDesc::withArgs. Basically adding that NPE can also be thrown if the content of the argument is `null`
> 
> TIA for the review

any reviewers for this simple PR?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4067

From liangchenblue at gmail.com  Fri May 21 19:11:07 2021
From: liangchenblue at gmail.com (-)
Date: Fri, 21 May 2021 14:11:07 -0500
Subject: Java records used in enums
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

Thanks for the info Alberto!

In my opinion, your best bet would be using an enum map to track these
information. Unfortunately, java enums and records are both static and you
should indeed avoid modifying them.

As a result, making enums deeply unmodifiable (immutable) is a good
practice, like your suggestion. Yet there are other uses of enums, such as
singletons, in which people may still want mutable instance fields. Lazy
field initialization are possible usages, too.

Best!

On Friday, May 21, 2021, Alberto Otero Rodr?guez 
wrote:
> The problem in my case was that we have an enum ErrorEnum with several
fields.
> One of the fields was "description" which have a getter and a setter.
> The problem appeared when testing with JUnit. Basically the logic of the
application was working correctly but the descriptions of the errors of
different tests were overriden with the description of the errors of
another tests.
> The problem was solved by making the fields of the enums final and
removing all the setter methods (after trying a lot of things and
refactoring the application almost entirely to remove all the static
methods and static members we had in the application).
> Regards,
> Alberto.
> ________________________________
> De: core-libs-dev  en nombre de
liangchenblue at gmail.com 
> Enviado: viernes, 21 de mayo de 2021 17:15
> Para: core-libs-dev at openjdk.java.net 
> Asunto: Fwd: Java records used in enums
>
> ---------- Forwarded message ---------
> From: - 
> Date: Fri, May 21, 2021 at 10:14 AM
> Subject: Re: Java records used in enums
> To: Alberto Otero Rodr?guez 
>
>
> I fail to understand what you want. How does making enums records fix the
> multithreading issue?
>
> If you wish to have enums declared like records code-wise, I see it as a
> possibility, but I don't see how it affects any enum behavior in any way.
>
> If you want a combination of record and enum, or a record with enumerated
> possible instances, it may be possible to add an alternative syntax for
> such enum declaration; but restricting all enums to be such enum records
> offers no benefit that I can see, especially given records themselves have
> severe restrictions (must have an accessible canonical ctor available;
that
> ctor cannot throw checked exceptions; field/getter method name limits, so
a
> "enum record" cannot declare fields like "values" "name"); also records
are
> value-based while enums are identity based, which is another problem.
>
> In short, I believe regular enum suffices and a "record enum" offers
little
> benefit while it cannot fix your issue at all.
>
> On Fri, May 21, 2021 at 10:00 AM Alberto Otero Rodr?guez <
> albest512 at hotmail.com> wrote:
>
>> It seems a non-existent problem until you face it, which is what happened
>> me today.
>>
>> I think at least (supposing enums can't be records) all the fields in
>> enums should be made final by default.
>>
>> Regards,
>>
>> Alberto.
>> ________________________________
>> De: Kasper Nielsen 
>> Enviado: viernes, 21 de mayo de 2021 16:28
>> Para: Alberto Otero Rodr?guez 
>> Cc: core-libs-dev at openjdk.java.net 
>> Asunto: Re: Java records used in enums
>>
>> On Fri, 21 May 2021 at 14:51, Alberto Otero Rodr?guez <
>> albest512 at hotmail.com> wrote:
>> Hi,
>>
>> I think enums in Java should be immutable. When you let the programmer
>> change values in an enum instance, an unexpected behaviour can happen
when
>> using multiple threads as enum instances are static (singleton).
>>
>> So, I was wondering why not make enums instances be defined as records
>> instead of normal classes.
>>
>> Lots of reasons, for example:
>> * It would be a breaking change for an almost non-existent problem.
>> * All internal state of enums would now be public.
>> * Enum's extend java.lang.Enum, records extend java.lang.Record.
>>   java.lang.Enum cannot extend java.lang.Record because it has instance
>> fields.
>>
>> /Kasper
>>
>

From liangchenblue at gmail.com  Fri May 21 19:16:56 2021
From: liangchenblue at gmail.com (-)
Date: Fri, 21 May 2021 14:16:56 -0500
Subject: Builder pattern for Java records
In-Reply-To: 
References: 
Message-ID: 

As far as I see, builders are more useful when there are too many arguments
or a lot of them have default values. These needs aren't as significant as
on records where few components are inferred.

In addition, using builders may lead to extra object allocation and
increase distribution size for the extra bytecode. So I guess people can
use an annotation processor to generate record builders optionally than
mandating a builder type for every record.

On Friday, May 21, 2021, Alberto Otero Rodr?guez 
wrote:
> Hi, I have found this project on GitHub which creates a Builder for Java
records:
> https://github.com/Randgalt/record-builder
> [
https://opengraph.githubassets.com/a4e3a7b3c7b16b51e0854011fe4b031577bcc09919058baef412b03613295d20/Randgalt/record-builder
]
> GitHub - Randgalt/record-builder: Record builder generator for Java
records
> The target package for generation is the same as the package that
contains the "Include" annotation. Use packagePattern to change this (see
Javadoc for details).. Usage Maven. Add the dependency that contains the
@RecordBuilder annotation. < dependency > < groupId
>io.soabase.record-builder < artifactId >record-builder-core < version >set-version-here github.com
>
> And I was wondering if this could be made by default in all Java Records.
>
> Technically a Builder is only used when creating the Object so I think is
possible and, if Java creates it by default, would be less error prone than
creating it manually.
>
> Regards,
>
> Alberto.
>

From weijun at openjdk.java.net  Fri May 21 19:50:15 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 19:50:15 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 
 <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>
Message-ID: 

On Fri, 21 May 2021 18:26:48 GMT, Phil Race  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust order of VM options
>
> test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights reserved.
>> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> 
> Probably the (c) update was meant to be on the .sh file that is actually modified.

Oops, I'll back it out. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071

From weijun at openjdk.java.net  Fri May 21 20:01:15 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:01:15 GMT
Subject: RFR: 8267184: Add -Djava.security.manager=allow to tests calling
 System.setSecurityManager [v3]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

> 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.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  feedback from Phil
  
  reverted:

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/bfa955ad..9a3ec578

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071

From aleksei.voitylov at bell-sw.com  Fri May 21 20:19:29 2021
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Fri, 21 May 2021 23:19:29 +0300
Subject: RFR: 8266310: deadlock while loading the JNI code [v2]
In-Reply-To: <84442ae7-9924-ff8d-2c6c-ec45dd09153e@gmail.com>
References: 
 <7uREVWzjGhgjYBdEpYZ5OBurn9FzSuu-TG9_xIu-syc=.c737c435-734e-4e79-9969-cf0d2147ac07@github.com>
 
 
 <1b1189d6-f340-9220-73f0-185411262a21@gmail.com>
 <253df918-7106-1930-5963-877e58e7b26a@oracle.com>
 <7b625acd-9c83-e4cf-02cd-ff534ecdffa3@gmail.com>
 <84442ae7-9924-ff8d-2c6c-ec45dd09153e@gmail.com>
Message-ID: <50bf4deb-6727-7b39-aeca-47da64ce01a6@bell-sw.com>

Peter, David,

I updated the PR to focus on solving the problem I originally intended
to solve that is observed in the wild - a deadlock when two different
libraries are being loaded. The case when the same library JNI_OnLoad
has FindClass with a circular dependency on loading the same library is
artificial. I thought of two ways to resolve it with the following
conclusions:

- not holding a lock when JNI_OnLoad is executed can only be done in a
such a way that would lead to a possibility to get JNI_OnLoad executed
multiple times, and the JNI code can rely on the fact that it's called
only once (though the JNI spec does not say so). Decoupling
dlopen/LoadLibrary from JNI_OnLoad does not solve this problem as well.
- throwing something like LibraryBeingLoadedError similar to
ClassCircularityError for JNI calls trying to use a class which
initializes the same library is also not a good option, as it is
behavior change. I as a user would not know what to do with that
(remember it can appear for a different thread that just happened to be
initializing the same library as well). Such a thread should just sit
and wait on the lock.

Both such solutions would make innocent code suffer, so are a no-go. I'm
open to ideas how to resolve it, if at all, but IMO it has a different
priority compared to the original bug report. I thus focused on solving
the original problem.

Thanks,

-Aleksei

On 21/05/2021 21:10, Peter Levart wrote:
>
> On 21/05/2021 10:29, Peter Levart wrote:
>> I still haven't found a scenario of a possible deadlock when Sergei's
>> initial patch is combined with...
>
>
> Sorry Aleksei, I renamed you to Sergei without intention. Please
> excuse me.
>
>
> Peter
>
>


From weijun at openjdk.java.net  Fri May 21 20:18:58 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:18:58 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <-G6LsP9NmgT4W265oaeXphH-xSg2U-9ofbhBlay7_-w=.0241068a-301f-4f94-802e-69a8adb545a4@github.com>

On Fri, 21 May 2021 15:35:05 GMT, Daniel Fuchs  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo on windows
>
> src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 120:
> 
>> 118:                         vals[1] = Integer.getInteger("sun.net.client.defaultConnectTimeout", 300_000).intValue();
>> 119:                         return System.getProperty("file.encoding", "ISO8859_1");
>> 120:                     }
> 
> It is a bit strange that "file.encoding" seem to get a special treatment - but I guess that's OK.

You might say we thus avoid wasting the return value, as much as possible.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From weijun at openjdk.java.net  Fri May 21 20:23:14 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:23:14 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 21 May 2021 15:37:48 GMT, Daniel Fuchs  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo on windows
>
> src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 550:
> 
>> 548:      * @throws IOException if the connection was unsuccessful.
>> 549:      */
>> 550:     @SuppressWarnings("removal")
> 
> Could the scope of the annotation be further reduced by applying it to the two places where `doPrivileged` is called in this method?

I'll probably need to assign the doPriv result on L631 to a tmp variable and then assign it to `s`. Are you OK with this ugliness? Update: Ah, I see you already have similar suggestion in the next comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From weijun at openjdk.java.net  Fri May 21 20:37:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:37:30 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
> 
> The code change shows some common solutions to avoid such too wide annotations:
> 
> 1. Extract calls into a method and add annotation on that method
> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value.
> 3. Put declaration and assignment into a single statement if possible.
> 4. Rewrite code to achieve #3 above.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  update FtpClient.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4138/files
  - new: https://git.openjdk.java.net/jdk/pull/4138/files/d460efb8..60d97a4c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=01-02

  Stats: 23 lines in 1 file changed: 0 ins; 12 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138

PR: https://git.openjdk.java.net/jdk/pull/4138

From prr at openjdk.java.net  Fri May 21 20:46:03 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 20:46:03 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Wed, 19 May 2021 13:47:53 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

I haven't seen any response to this comment I made a couple of days ago and I suspect it got missed
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:

> 57:                 ProcessCommunicator
> 58:                         .executeChildProcess(Consumer.class, new String[0]);
> 59:         if (!"Hello".equals(processResults.getStdOut())) {

Who or what prompted this change ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From roger.riggs at oracle.com  Fri May 21 20:52:45 2021
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 21 May 2021 16:52:45 -0400
Subject: RFR: 8191441: (Process) add Readers and Writer access to
 java.lang.Process streams
In-Reply-To: 
References: 
 
 
 
Message-ID: <44944b0f-0875-41e4-527d-90781fe48063@oracle.com>

Hi,

The list is used to test the inputReader and errorReader methods that 
accept a Charset.

The child process is launched with -Dsun.stdout.encoding and 
-Dsun.stderr.encoding
to make the child encode its output in the requested charset (overriding 
the native encoding).
Then the parent reads the output with the same charset.
The test will be skipped if the encoding is not supported.

The test for the native charset uses only the native encoding in the 
default configuration.

Thanks, Roger

On 5/20/21 5:30 PM, Bernd Eckenfels wrote:
> Hello,
>
> Hm, how is that list used? - StandardCharaet.ISO_8859_1 is a guaranteed Charset for JVM, and since the encoding is done in Java it should be fine. Added benefit is, it?s 8bit transparent.
>
> As for OS there is not a single standard charset (ebcdic vs latin families) but ASCII is probably the widest available (with latin1 variants to follow)
>
>
> --
> https://Bernd.eckenfels.net
> ________________________________
> From: core-libs-dev  on behalf of Roger Riggs 
> Sent: Thursday, May 20, 2021 10:52 PM
> To: core-libs-dev at openjdk.java.net
> Subject: Re: RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams
>
> On Thu, 20 May 2021 20:42:35 GMT, Naoto Sato  wrote:
>
>>> Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process.
>>> The Charset used to encode and decode characters to bytes can be specified or use the
>>> operating system native encoding as is available from the "native.encoding" system property.
>> test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java line 64:
>>
>>> 62:         return new Object[][] {
>>> 63:                 {"UTF-8"},
>>> 64:                 {"ISO8859-1"},
>> `ISO8859-1` may not be available on all underlying OSes.
> Is there a safe subset?
> I haven't seen a failure yet, if/when it occurs, we make an exception or narrow the test to known systems.
>
>> test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java line 111:
>>
>>> 109:     @Test(dataProvider = "CharsetCases", enabled = true)
>>> 110:     void testCase(String nativeEncoding) throws IOException {
>>> 111:         String osName = System.getProperty("os.name").toLowerCase(Locale.ROOT);
>> Not used anywhere else.
> Right, dead code now without host dependencies.
>
>> test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java line 122:
>>
>>> 120:                 "ReaderWriterTest$ChildWithCharset");
>>> 121:         var env = pb.environment();
>>> 122:         env.put("LANG", "en_US." + cleanCSName);
>> Does this work on Windows?
> Should be removed, the tests work because they set sun.stdout/stderr.encoding.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/4134


From weijun at openjdk.java.net  Fri May 21 20:55:02 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:55:02 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
Message-ID: 

On Fri, 21 May 2021 20:43:05 GMT, Phil Race  wrote:

> I haven't seen any response to this comment I made a couple of days ago and I suspect it got missed
> 
> > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
> 
> test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:
> 
> > 57:                 ProcessCommunicator
> > 58:                         .executeChildProcess(Consumer.class, new String[0]);
> > 59:         if (!"Hello".equals(processResults.getStdOut())) {
> 
> Who or what prompted this change ?

I replied right in the thread but unfortunately GitHub does not display it at the end of page.

This is because the process is now launched with `-Djava.security.manager=allow` (because of another change in https://github.com/openjdk/jdk/pull/4071), and a new warning is displayed in stderr. Therefore I switched to stdout.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From forax at openjdk.java.net  Fri May 21 21:23:58 2021
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 21 May 2021 21:23:58 GMT
Subject: RFR: 8191441: (Process) add Readers and Writer access to
 java.lang.Process streams
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 20 May 2021 20:37:57 GMT, Roger Riggs  wrote:

> OutputStreamWriter would be a better choice with that in mind. It does not have the convenience methods for converting various types to strings but would not hide the exceptions. Developers could wrap it in a PrintWriter to get the convenience and take on the responsibility of dealing with exceptions by polling.

yes, instead of OutputStreamWriter, i wonder if BufferedWriter is not better given that reader part uses BufferedReader and that is mirror java.nio.file.Files which also uses BufferedReader/BufferedWriter as types for the pair reader/writer.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4134

From roger.riggs at oracle.com  Fri May 21 21:44:16 2021
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 21 May 2021 17:44:16 -0400
Subject: RFR: 8191441: (Process) add Readers and Writer access to
 java.lang.Process streams
In-Reply-To: 
References: 
 
 
 
Message-ID: <2e414962-c7f4-6566-ab1a-5444e95f644f@oracle.com>

Hi,

Yes, I'm testing BufferedWriter-> OutputStreamWriter now.
And it can be wrapped in PrintWriter if someone is eager to get the 
missing text formatting
or auto-flush behaviors.

Roger


On 5/21/21 5:23 PM, R?mi Forax wrote:
> On Thu, 20 May 2021 20:37:57 GMT, Roger Riggs  wrote:
>
>> OutputStreamWriter would be a better choice with that in mind. It does not have the convenience methods for converting various types to strings but would not hide the exceptions. Developers could wrap it in a PrintWriter to get the convenience and take on the responsibility of dealing with exceptions by polling.
> yes, instead of OutputStreamWriter, i wonder if BufferedWriter is not better given that reader part uses BufferedReader and that is mirror java.nio.file.Files which also uses BufferedReader/BufferedWriter as types for the pair reader/writer.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/4134


From jvernee at openjdk.java.net  Fri May 21 23:15:15 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 21 May 2021 23:15:15 GMT
Subject: RFR: 8266310: deadlock while loading the JNI code [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 21 May 2021 15:39:33 GMT, Aleksei Voitylov  wrote:

>> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 262:
>> 
>>> 260:         } finally {
>>> 261:             releaseNativeLibraryLock(name);
>>> 262:         }
>> 
>> The new locking scheme looks incorrect to me. It now seems possible for 2 different class loaders in 2 different threads to load the same library (which should not be possible).
>> 
>> Thread 1:
>>   - acquires name lock
>>   - checks library name is already in `loadedLibraryNames` (it's not)
>>   - release name lock
>>   - start loading library
>>   
>> Then thread 2 comes in and does the same
>>   
>> Then again thread 1 finishes loading and:
>>  - acquires name lock
>>  - puts library name in `loadedLibraryNames`
>>  - puts library name in it's own `libraries`
>>  - release lock
>>  
>> Then thread 2 comes in and does the same again (although adding the name to `loadedLibraryNames` will silently return `false`).
>> 
>> It seems that this scenario is possible, and the library will be loaded by 2 different class loaders, each with their own `lib` object. (If there's a race, there has to be a loser as well, which would need to discard their work when finding out they lost)
>> 
>> You might be able to stress this by checking if `loadedLibraryNames.add(name);` returns `true`, and throwing an exception if not.
>> 
>> I think a possible solution would be to claim the library name up front for a particular loader. Then 2 threads can still race to load the same library for the same class loader, but 2 threads with 2 different class loaders racing to load the library should not be possible.
>> 
>> Actually, you might be able to prevent a race on JNI_OnLoad altogether by claiming the library name for a particular thread upfront as well (e.g. using a `ConcurrentHashMap`).
>
> Thank you, the previous version of the PR suffered from other problems as well. 
> 
> The PR is now reverted to a scheme with a lock held on library name, thus such a situation is no longer possible.

Ok, thanks.

FWIW, I think trying to lock on a per-name basis instead of globally is a good idea, and should improve the current situation. It is also safe to do as far as I can see.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3976

From mcimadamore at openjdk.java.net  Fri May 21 23:20:04 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 21 May 2021 23:20:04 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: 
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 
Message-ID: 

On Fri, 21 May 2021 14:22:47 GMT, Daniel Fuchs  wrote:

>> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
>> 
>> jdk:tier1 and jdk:tier2 are both ok
>
> I don't remember all the comments you have received in this thread but have you verified that arbitrarily changing `LinkedList` into `ArrayList` in these classes is not going to significantly increase the footprint in the case where lists are empty or contain only one or two elements?
> 
> I am not convinced that a global replacement of  `LinkedList` by `ArrayList` is necessarily good - even though I agree that `ArrayList` is generally more efficient.

I second the footprint concerns from @dfuch. I've seen with first hand cases where widespread uses of array lists for holding 1-2-3 elements (e.g. think of a graph where each node might only have a very small number of outgoing edges) lead to massive memory over-utilization. If the average size is known, at the very least I'd argue to replace with an array list which is sized correctly.

And, all this said, the general assumption implied in this PR which linked lists are just to be avoided doesn't match my experience. If you want a "pay only as much memory as you use" data structure, you don't care about random access (e.g. all accesses are linear walks), a linked list is a perfectly fine choice. If there are use cases in the JDK where a LinkedList is used in places where it shouldn't be, then obviously _those cases_ should be replaced.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From bchristi at openjdk.java.net  Sat May 22 00:43:13 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Sat, 22 May 2021 00:43:13 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 21 May 2021 17:47:53 GMT, Roger Riggs  wrote:

>> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
>> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
>> configuration mechanisms and filter utilities.
>> 
>> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`:
>>     http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Editorial updates to review comments
>   Add filter tracing support

Changes requested by bchristi (Reviewer).

src/java.base/share/classes/java/io/ObjectInputFilter.java line 84:

> 82:  *
> 83:  * 
     When a filter is set on an {@link ObjectInputStream}, the {@link #checkInput checkInput(FilterInfo)}
> 84:  * method is called to validate classes, the length of each array,

This sounds a bit like checkInput() is called at the time that the filter is set.  I'd recommend something like, "If a filter is set on an ObjectInputStream, the checkInput() method is called during deserialization to validate..."

src/java.base/share/classes/java/io/ObjectInputFilter.java line 123:

> 121:  * the depth, number of references, and stream size and return a status
> 122:  * that reflects only one or only some of the values.
> 123:  * This allows a filter to specific about the choice it is reporting and

...to _**be**_ specific ?

src/java.base/share/classes/java/io/ObjectInputFilter.java line 386:

> 384:      * {@link ObjectInputStream#setObjectInputFilter(ObjectInputFilter) ObjectInputStream.setObjectInputFilter}.
> 385:      * If {@code ObjectInputStream.setObjectInputFilter} is called, the filter factory is called a second time
> 386:      * with the initial filter returned from the first call and the requested new filter.

Maybe shorten to, "with the stream's initial filter, and the requested new filter."

src/java.base/share/classes/java/io/ObjectInputFilter.java line 404:

> 402:      * The JVM-wide filter is configured during the initialization of the
> 403:      * {@code ObjectInputFilter.Config} class.
> 404:      * For example, by calling {@link #getSerialFilter() Config.getSerialFilter}.

Can the "For example..." sentence be removed?

src/java.base/share/classes/java/io/ObjectInputFilter.java line 423:

> 421:      * The class must be public, must have a public zero-argument constructor, implement the
> 422:      * {@link BinaryOperator {@literal BinaryOperator}} interface, provide its implementation and
> 423:      * be accessible via the {@linkplain ClassLoader#getSystemClassLoader() the application class loader}.

two "the"s

src/java.base/share/classes/java/io/ObjectInputFilter.java line 1258:

> 1256:             /**
> 1257:              * Apply the filter and return the status if not UNDECIDED and checking a class.
> 1258:              * Make an exception for Primitive classes that are implicitly allowed by the pattern based filte.

filte -> filter

src/java.base/share/classes/java/io/ObjectInputStream.java line 200:

> 198:  * and every object read from the stream can be checked.
> 199:  * The {@linkplain #ObjectInputStream() ObjectInputStream constructors} invoke the filter factory
> 200:  * to select the initial filter and it is updated by {@link #setObjectInputFilter}.

In ObjectInputFilter, the `"The deserialization filter for a stream is determined in one of the following ways"` section has a good description of the various pieces and how they work together to determine a stream's filter.  I would consider leaning on that to provide the details, and have a shorter, high-level description here.  For instance:

"Each stream has an optional deserialization filter to check the classes and resource limits during deserialization.  The filter can be set for all streams JVM-wide, or customized on a per-stream basis.  See `` for details on how the filter for a stream is determined.
ObjectInputFilter describes how to use filters and..."

src/java.base/share/classes/java/io/ObjectInputStream.java line 370:

> 368:      *
> 369:      * 
    The serialization filter is initialized to the filter returned
> 370:      * by invoking the {@link Config#getSerialFilterFactory()} with {@code null} for the current filter

`linkplain` to "JVM-wide filter factory" ?

src/java.base/share/classes/java/io/ObjectInputStream.java line 371:

> 369:      * 
    The serialization filter is initialized to the filter returned
> 370:      * by invoking the {@link Config#getSerialFilterFactory()} with {@code null} for the current filter
> 371:      * and {@linkplain  Config#getSerialFilter() static JVM-wide filter} for the requested filter.

"and _**the**_ static JVM-wide filter for the..."

src/java.base/share/classes/java/io/ObjectInputStream.java line 408:

> 406:      * 
    The serialization filter is initialized to the filter returned
> 407:      * by invoking the {@link Config#getSerialFilterFactory()} with {@code null} for the current filter
> 408:      * and {@linkplain  Config#getSerialFilter() static JVM-wide filter} for the requested filter.

Same comments as the other constructor.

src/java.base/share/classes/java/io/ObjectInputStream.java line 1256:

> 1254:     /**
> 1255:      * Set the deserialization filter for the stream.
> 1256:      * The filter must be set and only set once before reading any objects from the stream;

"The filter can only be set once, and must be set before..." ?

src/java.base/share/classes/java/io/ObjectInputStream.java line 1260:

> 1258:      *
> 1259:      * 
    The serialization filter is set to the filter returned
> 1260:      * by invoking the {@link Config#getSerialFilterFactory()}

linkplain to "JVM-wide filter factory" ?

src/java.base/share/classes/java/io/ObjectInputStream.java line 1263:

> 1261:      * with the current filter and the {@code filter} parameter.
> 1262:      * If there is a non-null filter for the stream, one was set in the constructor, and the filter factory
> 1263:      * must return a non-null filter, it is not permitted to remove filtering once established.

New sentence for, "it is not permitted..." ?

src/java.base/share/classes/java/io/ObjectInputStream.java line 1327:

> 1325:      *       if the filter factory returns {@code null} when the
> 1326:      *       {@linkplain #getObjectInputFilter() current filter} is non-null, or
> 1327:      *       if the filter has already been.

if the filter has already been **_set_**

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From liangchenblue at gmail.com  Sat May 22 00:59:15 2021
From: liangchenblue at gmail.com (-)
Date: Fri, 21 May 2021 19:59:15 -0500
Subject: Please, help me with Java Strings class
In-Reply-To: 
References: 
Message-ID: 

I personally think the annotation ones are overkill; jdk doesn't use
annotations for automatic code generation for most of its core libs, and
these annotations will decrease the readability of code.

As far as I see, most of your utility methods are bypassing nulls. Imo the
right approach in the future would be avoiding null references like the
direction of modern jdk than adding a lot of null handlers. Otherwise, new
utility methods should go to java.lang.String I think.

On Fri, May 21, 2021 at 3:27 PM Alberto Otero Rodr?guez <
albest512 at hotmail.com> wrote:

> Hi, I'm Alberto Otero Rodr?guez,
>
> You have answered several questions I made in:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/thread.html
>
> Could you have a look at my other question?:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077882.html
>
> I have proposed there creating a new java.util.Strings class and maybe
> some new annotations.
>
> I know the annotations would require too much effort, but the Strings
> class is pretty simple and I think it would be really useful.
>
> Thank you so much for your answers!
>
> Regards,
>
> Alberto.
>

From rriggs at openjdk.java.net  Sat May 22 01:24:24 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Sat, 22 May 2021 01:24:24 GMT
Subject: RFR: 8191441: (Process) add Readers and Writer access to
 java.lang.Process streams [v2]
In-Reply-To: 
References: 
Message-ID: 

> Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process.
> The Charset used to encode and decode characters to bytes can be specified or use the
> operating system native encoding as is available from the "native.encoding" system property.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Use BufferedWriter and OutputStreamWriter and address review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4134/files
  - new: https://git.openjdk.java.net/jdk/pull/4134/files/a49b0b72..5a4a85d2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4134&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4134&range=00-01

  Stats: 66 lines in 3 files changed: 19 ins; 14 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4134.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4134/head:pull/4134

PR: https://git.openjdk.java.net/jdk/pull/4134

From rriggs at openjdk.java.net  Sat May 22 02:50:17 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Sat, 22 May 2021 02:50:17 GMT
Subject: RFR: 8267544: (test) rmi test NonLocalSkeleton fails if network has
 multiple adapters with the same address
Message-ID: 

Correct test code that creates a set of unique hostnames from an array of non-unique hostname.
Was using Set.of that throws if the elements are not unique.

-------------

Commit messages:
 - Correct API to get list of unique hostnames

Changes: https://git.openjdk.java.net/jdk/pull/4151/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4151&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267544
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4151.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4151/head:pull/4151

PR: https://git.openjdk.java.net/jdk/pull/4151

From alanb at openjdk.java.net  Sat May 22 07:00:03 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 22 May 2021 07:00:03 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
 
 
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 
 
 
Message-ID: 

On Fri, 21 May 2021 18:00:13 GMT, Phil Race  wrote:

> Are you suggesting that the patch doesn't need testing as it is ? It should be the same either way.
> It is very straight forward to run the automated tests across all platforms these days.
> I get the impression that no one is guaranteeing to do this straight after integration.
> It sounds like it is up for deferral if time runs out.
> 
> The amount of follow-on work that I am hearing about here, and may be for tests, does not make it sound
> like this JEP is nearly as done as first presented.
> 
> If there was some expectation that groups responsible for an area would get involved with this
> issue which I am assured was already known about, then why was it not raised before and made
> part of the plan ?

Sprinkling SuppressWarnings should be very low risk. Refactoring code to have the scope of the SW be as small as possible may be a bit more risky, esp. in areas where one doesn't know the code or the tests that exercise it. The tests may be good but it's not clear to me that we want to force Max to do significant refactoring in this PR.  PR 4138 has been created as the follow-on PR so I think we should help get that reviewed so that it can be integrated soon after this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From raffaello.giulietti at gmail.com  Sat May 22 11:22:04 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Sat, 22 May 2021 13:22:04 +0200
Subject: New java.util.Strings class
In-Reply-To: 
References: 
 
 
Message-ID: 

Hi Alberto,

there's an understandable tendency to wish to add convenience/utility 
methods like the ones you are proposing. Often, however, the perceived 
benefits are not assessed accurately. In other words, convenience 
methods in core libraries must be of real general interest.

Coming to your class, it exposes the constant EMPTY_STRING for "". Now, 
this is 12 characters (or even more if you don't use static imports) 
against 2 for nothing in exchange: "" is very readable, is not a magic 
constant that would deserve a global name, is interned and comes exactly 
to the point. Finding/replacing all occurrences of "" in a code base, if 
so needed, is easy even with the most elementary tools.

Some methods are there just to come around null strings. Now, a properly 
written application rarely uses null strings and if that happens it is 
mostly because of logical errors. The proposed methods hide them instead 
of pointing at their cause by throwing, so would even be harmful if used 
there. Thus, the general usefulness of such methods is probably more 
limited than intended by the proposal.

Other methods are focused on empty strings or strings of whitespaces. 
Agreed, some business logic would have to treat them specially and could 
benefit, but what's so outstanding with them to deserve API points in a 
core lib? In addition, some methods invoke String::strip() just to test 
whether a string is whitespaces.

This is not to say that your methods are not useful, only that they are 
probably not *that* useful to be included as a core lib.

A great post about the tension between the desire to add convenience 
methods to the core libs and try to refrain from doing so:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077103.html


Greetings
Raffaello


On 2021-05-21 11:11, Alberto Otero Rodr?guez wrote:
> Hi,
> 
> I have made other changes to the Strings class I proposed in my previous messages.
> 
> The changes are:
> 
>    *   Added the new methods compareTo and compareToIgnoreCase
>    *   Changed WhiteSpace for Whitespace
> 
> You can see the new code here:
> https://github.com/Aliuken/Java-Strings/blob/main/Strings.java
> 
> With those changes, the annotations suggested in the previous message should change to:
> - @NonNullNorWhitespace
> - @NonNullNorWhitespaceElse(defaultValue)
> - @NonNullNorWhitespaceElseGet(class::supplierMethod)
> 
> Regards,
> 
> Alberto Otero Rodr?guez.
> ________________________________
> De: Alberto Otero Rodr?guez 
> Enviado: mi?rcoles, 19 de mayo de 2021 11:36
> Para: core-libs-dev at openjdk.java.net 
> Asunto: RE: New java.util.Strings class
> 
> Hi,
> 
> I have made some changes to the Strings class I proposed in my previous message.
> 
> The changes are:
> 
>    *   Use str.isEmpty() instead of EMPTY_STRING.equals(str)
>    *   Create methods using str.strip() to check a String is not Whitespace
> 
> You can see the new code here:
> https://github.com/Aliuken/Java-Strings/blob/main/Strings.java
> 
> With those changes, the following annotations could also be created for method arguments and return types:
> - @NonNullNorWhiteSpace
> - @NonNullNorWhiteSpaceElse(defaultValue)
> - @NonNullNorWhiteSpaceElseGet(class::supplierMethod)
> 
> I didn't have any response to the previous message.
> 
> Please, take this one in consideration.
> 
> Regards,
> 
> Alberto Otero Rodr?guez.
> 
> ________________________________
> De: Alberto Otero Rodr?guez
> Enviado: lunes, 17 de mayo de 2021 14:58
> Para: core-libs-dev at openjdk.java.net 
> Asunto: New java.util.Strings class
> 
> Hi, members of the core-libs developers of OpenJDK.
> 
> I think Java needs a Strings class similar to the java.util.Objects class of Java 16 to be used in method arguments, return types and Stream filters.
> 
> I have coded it myself here based on the Objects implementation of Java 16 (please have a look):
> https://github.com/Aliuken/Java-Strings/blob/main/Strings.java
> 
> In fact, I think it would be useful also adding annotations for method arguments and return types such as:
> - @NonNull
> - @NonNullElse(defaultValue)
> - @NonNullElseGet(class::supplierMethod)
> - @NonNullNorEmpty
> - @NonNullNorEmptyElse(defaultValue)
> - @NonNullNorEmptyElseGet(class::supplierMethod)
> 
> With that kind of annotations, you could assume thinks like:
> - an argument or return type cannot have value null, but an Exception
> - an argument or return type cannot have value null, but a default value
> 
> What do you think?
> 
> Waiting for your response.
> 
> PS: I am sending this email repeated. I have sended it yesterday with my other email account (alber84ou at gmail.com), but I wasn't a member of this mailing list. Now I have become a member with this other email account.
> 
> Regards,
> 
> Alberto Otero Rodr?guez.
> 

From alanb at openjdk.java.net  Sat May 22 13:15:57 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 22 May 2021 13:15:57 GMT
Subject: RFR: 8224243: Make AccessibleObject a sealed class [v2]
In-Reply-To: <1p8BXJHpzVJ_nPh9j0sRoOJwdiYNkO_6DK9sg5T92_A=.9a001d1a-f0d9-428e-8c45-fb5f04cf79b4@github.com>
References: <4DFE3N_LB1D0jraDzmAmhGpzPGZAZrluVqCM5LFo5B4=.bbe76387-44f8-44de-ae2a-ce89d823041b@github.com>
 <1p8BXJHpzVJ_nPh9j0sRoOJwdiYNkO_6DK9sg5T92_A=.9a001d1a-f0d9-428e-8c45-fb5f04cf79b4@github.com>
Message-ID: <2-RKE9hlmiuS3_-GAjsHXHvzMCaj6_DbR9AS9ufF7SE=.9b7bb5bb-8854-47bc-8171-9bb343ccf75a@github.com>

On Fri, 21 May 2021 02:42:50 GMT, Joe Darcy  wrote:

>> Conceptually, AccessbileObject is a sealed class with a protected constructor stating
>> 
>>     Constructor: only used by the Java Virtual Machine.
>> 
>> With the language now supporting sealed classes, the AccessbileObject should be marked as sealed.
>> 
>> Executable and Field are the subclasses of AccessbileObject in the JDK; as Executable has subclasses, it is marked as non-sealed.
>> 
>> Please also review the corresponding CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8224243
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update in response to review feedback.

src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 533:

> 531:     @Override
> 532:     public  T getAnnotation(Class annotationClass) {
> 533:         throw new IllegalStateException("All subclasses should override this method");

I'm now sure that ISE is the more appropriate exception here because there isn't an alternative state that would accept the input. UOE might be better.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4133

From alanb at openjdk.java.net  Sat May 22 16:41:00 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 22 May 2021 16:41:00 GMT
Subject: RFR: 8224243: Make AccessibleObject a sealed class [v2]
In-Reply-To: <1p8BXJHpzVJ_nPh9j0sRoOJwdiYNkO_6DK9sg5T92_A=.9a001d1a-f0d9-428e-8c45-fb5f04cf79b4@github.com>
References: <4DFE3N_LB1D0jraDzmAmhGpzPGZAZrluVqCM5LFo5B4=.bbe76387-44f8-44de-ae2a-ce89d823041b@github.com>
 <1p8BXJHpzVJ_nPh9j0sRoOJwdiYNkO_6DK9sg5T92_A=.9a001d1a-f0d9-428e-8c45-fb5f04cf79b4@github.com>
Message-ID: 

On Fri, 21 May 2021 02:42:50 GMT, Joe Darcy  wrote:

>> Conceptually, AccessbileObject is a sealed class with a protected constructor stating
>> 
>>     Constructor: only used by the Java Virtual Machine.
>> 
>> With the language now supporting sealed classes, the AccessbileObject should be marked as sealed.
>> 
>> Executable and Field are the subclasses of AccessbileObject in the JDK; as Executable has subclasses, it is marked as non-sealed.
>> 
>> Please also review the corresponding CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8224243
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update in response to review feedback.

src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 533:

> 531:     @Override
> 532:     public  T getAnnotation(Class annotationClass) {
> 533:         throw new IllegalStateException("All subclasses should override this method");

I'm not sure that ISE is the most appropriate exception here because there isn't an alternative state that would accept the input. UOE might be better.

The new proposal to just seal Executable looks reasonable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4133

From albest512 at hotmail.com  Sat May 22 18:09:43 2021
From: albest512 at hotmail.com (=?iso-8859-1?Q?Alberto_Otero_Rodr=EDguez?=)
Date: Sat, 22 May 2021 18:09:43 +0000
Subject: New java.util.Strings class
In-Reply-To: 
References: 
 
 ,
 
Message-ID: 

Hi Raffaello,

I undestand what you said. However:

1) I based my code in the current java.util.Objects class of Java 16. I don't know why the Objects class was a good idea, but the Strings class is not.

2) It's not just treating with nulls, but also with empty strings and whitespaces. If Java doesn't have this utilities, people will have to use external libraries like Guava or Apache Commons.

3) I don't think (when developing a programming language) it is a good idea to just think in what nowadays you think is a "properly written application". Java should be prepared for applications programmed in completely different ways.

Regards,

Alberto.

________________________________
De: Raffaello Giulietti 
Enviado: s?bado, 22 de mayo de 2021 13:22
Para: core-libs-dev at openjdk.java.net ; Alberto Otero Rodr?guez 
Asunto: Re: New java.util.Strings class

Hi Alberto,

there's an understandable tendency to wish to add convenience/utility
methods like the ones you are proposing. Often, however, the perceived
benefits are not assessed accurately. In other words, convenience
methods in core libraries must be of real general interest.

Coming to your class, it exposes the constant EMPTY_STRING for "". Now,
this is 12 characters (or even more if you don't use static imports)
against 2 for nothing in exchange: "" is very readable, is not a magic
constant that would deserve a global name, is interned and comes exactly
to the point. Finding/replacing all occurrences of "" in a code base, if
so needed, is easy even with the most elementary tools.

Some methods are there just to come around null strings. Now, a properly
written application rarely uses null strings and if that happens it is
mostly because of logical errors. The proposed methods hide them instead
of pointing at their cause by throwing, so would even be harmful if used
there. Thus, the general usefulness of such methods is probably more
limited than intended by the proposal.

Other methods are focused on empty strings or strings of whitespaces.
Agreed, some business logic would have to treat them specially and could
benefit, but what's so outstanding with them to deserve API points in a
core lib? In addition, some methods invoke String::strip() just to test
whether a string is whitespaces.

This is not to say that your methods are not useful, only that they are
probably not *that* useful to be included as a core lib.

A great post about the tension between the desire to add convenience
methods to the core libs and try to refrain from doing so:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077103.html


Greetings
Raffaello


On 2021-05-21 11:11, Alberto Otero Rodr?guez wrote:
> Hi,
>
> I have made other changes to the Strings class I proposed in my previous messages.
>
> The changes are:
>
>    *   Added the new methods compareTo and compareToIgnoreCase
>    *   Changed WhiteSpace for Whitespace
>
> You can see the new code here:
> https://github.com/Aliuken/Java-Strings/blob/main/Strings.java
>
> With those changes, the annotations suggested in the previous message should change to:
> - @NonNullNorWhitespace
> - @NonNullNorWhitespaceElse(defaultValue)
> - @NonNullNorWhitespaceElseGet(class::supplierMethod)
>
> Regards,
>
> Alberto Otero Rodr?guez.
> ________________________________
> De: Alberto Otero Rodr?guez 
> Enviado: mi?rcoles, 19 de mayo de 2021 11:36
> Para: core-libs-dev at openjdk.java.net 
> Asunto: RE: New java.util.Strings class
>
> Hi,
>
> I have made some changes to the Strings class I proposed in my previous message.
>
> The changes are:
>
>    *   Use str.isEmpty() instead of EMPTY_STRING.equals(str)
>    *   Create methods using str.strip() to check a String is not Whitespace
>
> You can see the new code here:
> https://github.com/Aliuken/Java-Strings/blob/main/Strings.java
>
> With those changes, the following annotations could also be created for method arguments and return types:
> - @NonNullNorWhiteSpace
> - @NonNullNorWhiteSpaceElse(defaultValue)
> - @NonNullNorWhiteSpaceElseGet(class::supplierMethod)
>
> I didn't have any response to the previous message.
>
> Please, take this one in consideration.
>
> Regards,
>
> Alberto Otero Rodr?guez.
>
> ________________________________
> De: Alberto Otero Rodr?guez
> Enviado: lunes, 17 de mayo de 2021 14:58
> Para: core-libs-dev at openjdk.java.net 
> Asunto: New java.util.Strings class
>
> Hi, members of the core-libs developers of OpenJDK.
>
> I think Java needs a Strings class similar to the java.util.Objects class of Java 16 to be used in method arguments, return types and Stream filters.
>
> I have coded it myself here based on the Objects implementation of Java 16 (please have a look):
> https://github.com/Aliuken/Java-Strings/blob/main/Strings.java
>
> In fact, I think it would be useful also adding annotations for method arguments and return types such as:
> - @NonNull
> - @NonNullElse(defaultValue)
> - @NonNullElseGet(class::supplierMethod)
> - @NonNullNorEmpty
> - @NonNullNorEmptyElse(defaultValue)
> - @NonNullNorEmptyElseGet(class::supplierMethod)
>
> With that kind of annotations, you could assume thinks like:
> - an argument or return type cannot have value null, but an Exception
> - an argument or return type cannot have value null, but a default value
>
> What do you think?
>
> Waiting for your response.
>
> PS: I am sending this email repeated. I have sended it yesterday with my other email account (alber84ou at gmail.com), but I wasn't a member of this mailing list. Now I have become a member with this other email account.
>
> Regards,
>
> Alberto Otero Rodr?guez.
>

From rriggs at openjdk.java.net  Sat May 22 20:16:37 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Sat, 22 May 2021 20:16:37 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v5]
In-Reply-To: 
References: 
Message-ID: 

> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
> configuration mechanisms and filter utilities.
> 
> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`:
>     http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Editorial javadoc updated based on review comments.
  Clarified behavior of rejectUndecidedClass method.
  Example test added to check status returned from file.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3996/files
  - new: https://git.openjdk.java.net/jdk/pull/3996/files/a0785e88..0274fb4f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=03-04

  Stats: 209 lines in 4 files changed: 149 ins; 9 del; 51 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3996.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3996/head:pull/3996

PR: https://git.openjdk.java.net/jdk/pull/3996

From brian.goetz at oracle.com  Sat May 22 20:35:15 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 22 May 2021 16:35:15 -0400
Subject: Builder pattern for Java records
In-Reply-To: 
References: 
Message-ID: <7E3391C4-2674-4569-B22A-12D4A3E4C1C0@oracle.com>

There is no end to patterns of code that could be generated by tools, and for each of them, one can imagine situations where they would be useful.  But in addition to the other reply about how builders are really only called for when there are a large number of _optional_ components, the premise of the question makes some incorrect assumptions about records.

Records are not a ?macro generator?; to think of records in terms of ?the compiler generates XYZ pattern of code?, while technically accurate, is missing the main point.  They are a semantic feature, that happens to dispense with some boilerplate.  

Records are best understood as _nominal tuples_; they are the language?s mechanism for representing product types.  Because Java is an OO language, we can mediate the construction process to reject invalid states or normalize state to its canonical form, and we derive the semantics for accessors, equals, hashCode, etc, from the semantics of tuples.  

If some project out there wants to have code generators for patterns that are sometimes useful for records, that?s great ? but that?s not where the language should be focusing.  

> On May 21, 2021, at 11:37 AM, Alberto Otero Rodr?guez  wrote:
> 
> Hi, I have found this project on GitHub which creates a Builder for Java records:
> https://github.com/Randgalt/record-builder
> [https://opengraph.githubassets.com/a4e3a7b3c7b16b51e0854011fe4b031577bcc09919058baef412b03613295d20/Randgalt/record-builder]
> GitHub - Randgalt/record-builder: Record builder generator for Java records
> The target package for generation is the same as the package that contains the "Include" annotation. Use packagePattern to change this (see Javadoc for details).. Usage Maven. Add the dependency that contains the @RecordBuilder annotation. < dependency > < groupId >io.soabase.record-builder < artifactId >record-builder-core < version >set-version-here github.com
> 
> And I was wondering if this could be made by default in all Java Records.
> 
> Technically a Builder is only used when creating the Object so I think is possible and, if Java creates it by default, would be less error prone than creating it manually.
> 
> Regards,
> 
> Alberto.


From albest512 at hotmail.com  Sat May 22 21:32:51 2021
From: albest512 at hotmail.com (=?Windows-1252?Q?Alberto_Otero_Rodr=EDguez?=)
Date: Sat, 22 May 2021 21:32:51 +0000
Subject: Builder pattern for Java records
In-Reply-To: <7E3391C4-2674-4569-B22A-12D4A3E4C1C0@oracle.com>
References: ,
 <7E3391C4-2674-4569-B22A-12D4A3E4C1C0@oracle.com>
Message-ID: 

Understood Brian, great answer.

Could you please answer to my other proposal?:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077955.html

Regards,

Alberto.
________________________________
De: Brian Goetz 
Enviado: s?bado, 22 de mayo de 2021 22:35
Para: Alberto Otero Rodr?guez 
Cc: core-libs-dev at openjdk.java.net 
Asunto: Re: Builder pattern for Java records

There is no end to patterns of code that could be generated by tools, and for each of them, one can imagine situations where they would be useful.  But in addition to the other reply about how builders are really only called for when there are a large number of _optional_ components, the premise of the question makes some incorrect assumptions about records.

Records are not a ?macro generator?; to think of records in terms of ?the compiler generates XYZ pattern of code?, while technically accurate, is missing the main point.  They are a semantic feature, that happens to dispense with some boilerplate.

Records are best understood as _nominal tuples_; they are the language?s mechanism for representing product types.  Because Java is an OO language, we can mediate the construction process to reject invalid states or normalize state to its canonical form, and we derive the semantics for accessors, equals, hashCode, etc, from the semantics of tuples.

If some project out there wants to have code generators for patterns that are sometimes useful for records, that?s great ? but that?s not where the language should be focusing.

> On May 21, 2021, at 11:37 AM, Alberto Otero Rodr?guez  wrote:
>
> Hi, I have found this project on GitHub which creates a Builder for Java records:
> https://github.com/Randgalt/record-builder
> [https://opengraph.githubassets.com/a4e3a7b3c7b16b51e0854011fe4b031577bcc09919058baef412b03613295d20/Randgalt/record-builder]
> GitHub - Randgalt/record-builder: Record builder generator for Java records
> The target package for generation is the same as the package that contains the "Include" annotation. Use packagePattern to change this (see Javadoc for details).. Usage Maven. Add the dependency that contains the @RecordBuilder annotation. < dependency > < groupId >io.soabase.record-builder < artifactId >record-builder-core < version >set-version-here github.com
>
> And I was wondering if this could be made by default in all Java Records.
>
> Technically a Builder is only used when creating the Object so I think is possible and, if Java creates it by default, would be less error prone than creating it manually.
>
> Regards,
>
> Alberto.


From brian.goetz at oracle.com  Sat May 22 21:41:29 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 22 May 2021 21:41:29 +0000
Subject: Builder pattern for Java records
In-Reply-To: 
References: ,
 <7E3391C4-2674-4569-B22A-12D4A3E4C1C0@oracle.com>,
 
Message-ID: <64ECE51C-2591-44B8-9065-D7FDD283BAC7@oracle.com>

As Rafaello mentioned, these seem well below the threshold for ?convenience? methods in the JDK.  The bar here is pretty high.  This seems something better suited to Apache Commons?

Sent from my iPad

> On May 22, 2021, at 5:33 PM, Alberto Otero Rodr?guez  wrote:
> 
> ?Understood Brian, great answer.
> 
> Could you please answer to my other proposal?:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077955.html
> 
> Regards,
> 
> Alberto.
> ________________________________
> De: Brian Goetz 
> Enviado: s?bado, 22 de mayo de 2021 22:35
> Para: Alberto Otero Rodr?guez 
> Cc: core-libs-dev at openjdk.java.net 
> Asunto: Re: Builder pattern for Java records
> 
> There is no end to patterns of code that could be generated by tools, and for each of them, one can imagine situations where they would be useful.  But in addition to the other reply about how builders are really only called for when there are a large number of _optional_ components, the premise of the question makes some incorrect assumptions about records.
> 
> Records are not a ?macro generator?; to think of records in terms of ?the compiler generates XYZ pattern of code?, while technically accurate, is missing the main point.  They are a semantic feature, that happens to dispense with some boilerplate.
> 
> Records are best understood as _nominal tuples_; they are the language?s mechanism for representing product types.  Because Java is an OO language, we can mediate the construction process to reject invalid states or normalize state to its canonical form, and we derive the semantics for accessors, equals, hashCode, etc, from the semantics of tuples.
> 
> If some project out there wants to have code generators for patterns that are sometimes useful for records, that?s great ? but that?s not where the language should be focusing.
> 
>> On May 21, 2021, at 11:37 AM, Alberto Otero Rodr?guez  wrote:
>> 
>> Hi, I have found this project on GitHub which creates a Builder for Java records:
>> https://github.com/Randgalt/record-builder
>> [https://opengraph.githubassets.com/a4e3a7b3c7b16b51e0854011fe4b031577bcc09919058baef412b03613295d20/Randgalt/record-builder]
>> GitHub - Randgalt/record-builder: Record builder generator for Java records
>> The target package for generation is the same as the package that contains the "Include" annotation. Use packagePattern to change this (see Javadoc for details).. Usage Maven. Add the dependency that contains the @RecordBuilder annotation. < dependency > < groupId >io.soabase.record-builder < artifactId >record-builder-core < version >set-version-here> github.com
>> 
>> And I was wondering if this could be made by default in all Java Records.
>> 
>> Technically a Builder is only used when creating the Object so I think is possible and, if Java creates it by default, would be less error prone than creating it manually.
>> 
>> Regards,
>> 
>> Alberto.
> 

From tvaleev at openjdk.java.net  Sun May 23 11:24:12 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Sun, 23 May 2021 11:24:12 GMT
Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations
 (skip, limit) [v6]
In-Reply-To: 
References: 
Message-ID: 

> With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch.
> 
> Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch:
> 
> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10   40235,534 ?     0,984    B/op
> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  106431,101 ?     0,198    B/op
> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  106544,977 ?     1,983    B/op
> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10   40121,878 ?     0,247    B/op
> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  106317,693 ?     1,083    B/op
> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  106430,954 ?     0,136    B/op
> 
> 
> After patch:
> 
> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10  40235,648 ?     1,354    B/op
> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  40355,784 ?     1,288    B/op
> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  40476,032 ?     2,855    B/op
> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10  40121,830 ?     0,308    B/op
> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  40242,554 ?     0,443    B/op
> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  40363,674 ?     1,576    B/op
> 
> 
> Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests.
> 
> Before patch:
> 
> Benchmark                         (size)   Mode  Cnt      Score     Error  Units
> ref.SliceToList.par_baseline       10000  thrpt   30  14876,723 ?  99,770  ops/s
> ref.SliceToList.par_limit          10000  thrpt   30  14856,841 ? 215,089  ops/s
> ref.SliceToList.par_skipLimit      10000  thrpt   30   9555,818 ? 991,335  ops/s
> ref.SliceToList.seq_baseline       10000  thrpt   30  23732,290 ? 444,162  ops/s
> ref.SliceToList.seq_limit          10000  thrpt   30  14894,040 ? 176,496  ops/s
> ref.SliceToList.seq_skipLimit      10000  thrpt   30  10646,929 ?  36,469  ops/s
> value.SliceToArray.par_baseline    10000  thrpt   30  25093,141 ? 376,402  ops/s
> value.SliceToArray.par_limit       10000  thrpt   30  24798,889 ? 760,762  ops/s
> value.SliceToArray.par_skipLimit   10000  thrpt   30  16456,310 ? 926,882  ops/s
> value.SliceToArray.seq_baseline    10000  thrpt   30  69669,787 ? 494,562  ops/s
> value.SliceToArray.seq_limit       10000  thrpt   30  21097,081 ? 117,338  ops/s
> value.SliceToArray.seq_skipLimit   10000  thrpt   30  15522,871 ? 112,557  ops/s
> 
> 
> After patch:
> 
> Benchmark                         (size)   Mode  Cnt      Score      Error  Units
> ref.SliceToList.par_baseline       10000  thrpt   30  14793,373 ?   64,905  ops/s
> ref.SliceToList.par_limit          10000  thrpt   30  13301,024 ? 1300,431  ops/s
> ref.SliceToList.par_skipLimit      10000  thrpt   30  11131,698 ? 1769,932  ops/s
> ref.SliceToList.seq_baseline       10000  thrpt   30  24101,048 ?  263,528  ops/s
> ref.SliceToList.seq_limit          10000  thrpt   30  16872,168 ?   76,696  ops/s
> ref.SliceToList.seq_skipLimit      10000  thrpt   30  11953,253 ?  105,231  ops/s
> value.SliceToArray.par_baseline    10000  thrpt   30  25442,442 ?  455,554  ops/s
> value.SliceToArray.par_limit       10000  thrpt   30  23111,730 ? 2246,086  ops/s
> value.SliceToArray.par_skipLimit   10000  thrpt   30  17980,750 ? 2329,077  ops/s
> value.SliceToArray.seq_baseline    10000  thrpt   30  66512,898 ? 1001,042  ops/s
> value.SliceToArray.seq_limit       10000  thrpt   30  41792,549 ? 1085,547  ops/s
> value.SliceToArray.seq_skipLimit   10000  thrpt   30  18007,613 ?  141,716  ops/s
> 
> 
> I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  SIZE_ADJUSTING flag; exactOutputSize is pure

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3427/files
  - new: https://git.openjdk.java.net/jdk/pull/3427/files/6e77cfd6..e6d7bd6a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3427&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3427&range=04-05

  Stats: 64 lines in 3 files changed: 22 ins; 25 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3427.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3427/head:pull/3427

PR: https://git.openjdk.java.net/jdk/pull/3427

From tvaleev at openjdk.java.net  Sun May 23 11:33:46 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Sun, 23 May 2021 11:33:46 GMT
Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations
 (skip, limit) [v3]
In-Reply-To: <3TMBo-E41tbmPdNPsTD_fJuaxFz9fuTzXGQ4s-IrKe4=.fc9af658-90d0-4af3-b569-c11fdea64632@github.com>
References: 
 
 
 <3TMBo-E41tbmPdNPsTD_fJuaxFz9fuTzXGQ4s-IrKe4=.fc9af658-90d0-4af3-b569-c11fdea64632@github.com>
Message-ID: <2ydAX_W_XeU0ShlZT75SiQHTErv1CITvovP0WLUHsWc=.85ef9a07-c13f-4327-938a-bbf6a1af78b2@github.com>

On Mon, 17 May 2021 22:08:01 GMT, Paul Sandoz  wrote:

>> I see your concern. I made some additional benchmarks and added them here. First, CountSized, which just gets the stream size without actual traversal. We can see how the performance changes depending on number of stream operations. I also added an optional type profile pollution that makes `exactOutputSize` virtual method polymorphic. Here's the results:
>> 
>> Baseline (The `count10Skip` test added just to ensure that patch works)
>> 
>> Benchmark  (pollute)  (size)  Mode  Cnt       Score      Error  Units
>> count0         false   10000  avgt  100      15,648 ?    0,182  ns/op
>> count2         false   10000  avgt  100      31,252 ?    0,113  ns/op
>> count4         false   10000  avgt  100      47,683 ?    0,165  ns/op
>> count6         false   10000  avgt  100      64,417 ?    0,203  ns/op
>> count8         false   10000  avgt  100      80,813 ?    0,265  ns/op
>> count10        false   10000  avgt  100     101,057 ?    0,295  ns/op
>> count10Skip    false   10000  avgt  100  497967,375 ? 5946,108  ns/op
>> count0          true   10000  avgt  100      18,843 ?    0,103  ns/op
>> count2          true   10000  avgt  100      33,716 ?    0,152  ns/op
>> count4          true   10000  avgt  100      49,062 ?    0,208  ns/op
>> count6          true   10000  avgt  100      66,773 ?    0,237  ns/op
>> count8          true   10000  avgt  100      82,727 ?    0,354  ns/op
>> count10         true   10000  avgt  100     104,499 ?    0,299  ns/op
>> count10Skip     true   10000  avgt  100  501723,220 ? 6361,932  ns/op
>> 
>> Type pollution adds some near-constant ~2ns overhead to the non-patched version as well.
>> 
>> Patched:
>> 
>> Benchmark  (pollute)  (size)  Mode  Cnt    Score   Error  Units
>> count0         false   10000  avgt  100   15,363 ? 0,086  ns/op
>> count2         false   10000  avgt  100   33,736 ? 0,138  ns/op
>> count4         false   10000  avgt  100   51,470 ? 0,205  ns/op
>> count6         false   10000  avgt  100   70,407 ? 0,262  ns/op
>> count8         false   10000  avgt  100   89,865 ? 0,262  ns/op
>> count10        false   10000  avgt  100  114,423 ? 0,363  ns/op
>> count10Skip    false   10000  avgt  100  139,963 ? 0,550  ns/op
>> count0          true   10000  avgt  100   26,538 ? 0,084  ns/op
>> count2          true   10000  avgt  100   46,089 ? 0,191  ns/op
>> count4          true   10000  avgt  100   66,560 ? 0,315  ns/op
>> count6          true   10000  avgt  100   87,852 ? 0,288  ns/op
>> count8          true   10000  avgt  100  109,037 ? 0,391  ns/op
>> count10         true   10000  avgt  100  139,759 ? 0,382  ns/op
>> count10Skip     true   10000  avgt  100  156,963 ? 1,862  ns/op
>> 
>> So indeed we have some performance drawback in patched version. Here's a chart:
>> 
>> ![image](https://user-images.githubusercontent.com/5114450/115098724-c754dd00-9f5b-11eb-86a0-b614a7d36fad.png)
>> I've calculated linear regression on (patched-baseline) times, depending on the number of ops. It's `y = 1.288x - 0.7078` for clean type profile and `y = 2.6174x + 6.9489` for polluted type profile. So, in the worst case, we have circa 2.6ns per operation plus 7ns constant overhead.
>> 
>> However, using Stream API without actually iterating the stream is very rare case. And if we iterate, the performance will be dominated by the number of iterations. I tried to model this case with SumSized benchmark (replacing count with sum, for 5 and 10 stream elements), but got very confusing results.
>> 
>> Baseline:
>> 
>> Benchmark  (pollute)  (size)  Mode  Cnt    Score    Error  Units
>> sum0            true       5  avgt  100  126,425 ?  0,793  ns/op
>> sum2            true       5  avgt  100  195,113 ?  1,359  ns/op
>> sum4            true       5  avgt  100  304,111 ?  8,302  ns/op
>> sum6            true       5  avgt  100  414,841 ?  3,215  ns/op
>> sum8            true       5  avgt  100  507,421 ?  4,781  ns/op
>> sum10           true       5  avgt  100  633,635 ?  7,105  ns/op
>> sum0           false       5  avgt  100   45,781 ?  0,258  ns/op
>> sum2           false       5  avgt  100   86,720 ?  0,573  ns/op
>> sum4           false       5  avgt  100  195,777 ?  1,145  ns/op
>> sum6           false       5  avgt  100  291,261 ?  2,091  ns/op
>> sum8           false       5  avgt  100  376,094 ?  3,283  ns/op
>> sum10          false       5  avgt  100  492,082 ?  7,914  ns/op
>> sum0            true      10  avgt  100  127,989 ?  0,758  ns/op
>> sum2            true      10  avgt  100  219,991 ?  3,081  ns/op
>> sum4            true      10  avgt  100  374,148 ?  7,426  ns/op
>> sum6            true      10  avgt  100  557,829 ?  3,959  ns/op
>> sum8            true      10  avgt  100  698,135 ?  4,915  ns/op
>> sum10           true      10  avgt  100  904,851 ? 14,458  ns/op
>> sum0           false      10  avgt  100   43,861 ?  0,107  ns/op
>> sum2           false      10  avgt  100  105,049 ?  0,276  ns/op
>> sum4           false      10  avgt  100  294,639 ?  1,499  ns/op
>> sum6           false      10  avgt  100  439,340 ?  4,223  ns/op
>> sum8           false      10  avgt  100  577,025 ?  5,760  ns/op
>> sum10          false      10  avgt  100  729,391 ?  6,045  ns/op
>> 
>> 
>> Patched:
>> 
>> Benchmark  (pollute)  (size)  Mode  Cnt    Score   Error  Units
>> sum0            true       5  avgt  100   68,466 ? 0,167  ns/op
>> sum2            true       5  avgt  100  107,240 ? 0,261  ns/op
>> sum4            true       5  avgt  100  209,469 ? 1,098  ns/op
>> sum6            true       5  avgt  100  300,873 ? 2,020  ns/op
>> sum8            true       5  avgt  100  378,654 ? 2,620  ns/op
>> sum10           true       5  avgt  100  473,769 ? 3,665  ns/op
>> sum0           false       5  avgt  100   49,435 ? 2,702  ns/op
>> sum2           false       5  avgt  100   96,237 ? 2,906  ns/op
>> sum4           false       5  avgt  100  195,196 ? 0,961  ns/op
>> sum6           false       5  avgt  100  286,542 ? 1,874  ns/op
>> sum8           false       5  avgt  100  371,664 ? 3,416  ns/op
>> sum10          false       5  avgt  100  457,178 ? 3,776  ns/op
>> sum0            true      10  avgt  100   69,223 ? 0,195  ns/op
>> sum2            true      10  avgt  100  120,507 ? 0,752  ns/op
>> sum4            true      10  avgt  100  291,328 ? 5,581  ns/op
>> sum6            true      10  avgt  100  439,136 ? 3,787  ns/op
>> sum8            true      10  avgt  100  569,188 ? 6,440  ns/op
>> sum10           true      10  avgt  100  709,916 ? 5,022  ns/op
>> sum0           false      10  avgt  100   46,347 ? 0,174  ns/op
>> sum2           false      10  avgt  100  109,131 ? 2,381  ns/op
>> sum4           false      10  avgt  100  296,566 ? 2,079  ns/op
>> sum6           false      10  avgt  100  430,852 ? 2,629  ns/op
>> sum8           false      10  avgt  100  562,795 ? 4,442  ns/op
>> sum10          false      10  avgt  100  716,229 ? 5,659  ns/op
>> 
>> 
>> Or, in graphical form:
>> ![image](https://user-images.githubusercontent.com/5114450/115098879-c2dcf400-9f5c-11eb-9fd3-f72ac7c1d59a.png)
>> ![image](https://user-images.githubusercontent.com/5114450/115098884-cc665c00-9f5c-11eb-9e9d-d7c9a7aa10ee.png)
>> 
>> For some reason, non-patched polluted version is the slowest, and I cannot see any stable overhead in patched version. For 4+ intermediate ops, patched version numbers are always better than the corresponding non-patched ones. I would be glad if somebody explains these numbers or point to a flaw in this benchmark.
>> 
>> What do you think, @PaulSandoz? Is it acceptable overhead or should I experiment with the new Stream flag?
>
> @amaembo this dropped of my radar, but the Skara reminder made it visible again!
> 
> Thank you for the detailed analysis. I cannot explain the results of when triggering profile pollution over the kinds of stream.
> I think we have good sense that the performance is not unduly perturbed for small streams (there is more work done elsewhere than determining the actual size of the sized stream).
> 
> Implementation-wise I still find it a little awkward that the operation is responsible for calling the prior op in the pipeline, and we see the consequences of that in the Slice op implementation that predicates on `isParallel`.
> 
> It might be cleaner if the op is presented with some exact size and adjusts it, something more pure e.g. for SliceOp:
> 
> long exactOutputSize(long sourceSize) {
>   return calcSize(sourceSize, skip, normalizedLimit);
> }
> 
> The default impl would be:
> 
> long exactOutputSize(long sourceSize) {
>   return sourceSize;
> }
> 
> 
> Then the pipeline helper is responsible for traversing the pipeline (be it sequentially or in parallel, in the latter case the above method would not get called since the slice op becomes the source spliterator for the next stages).
> 
> To do that efficiently does I think require a new flag, set by an op and only meaningful when SIZED is set (and cleared when SIZED is cleared, although perhaps we only need to do that splitting stages for parallel execution, see `AbstractPipeline.sourceSpliterator`).

@PaulSandoz I added a new flag and updated `exactOutputSize` per your suggestion, implementing the explicit iteration inside `AbstractPipeline#exactOutputSizeIfKnown`, along with `isParallel()` check. I'm not sure how to clear the new flag automatically but this is not so necessary, as it's not used if `SIZED` is not set. Also, I skipped the `sourceStage` (starting from `sourceState.nextStage`), to save one virtual call, as current implementation never has the source stage that adjusts the size.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3427

From tvaleev at openjdk.java.net  Sun May 23 11:33:49 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Sun, 23 May 2021 11:33:49 GMT
Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations
 (skip, limit) [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 23 May 2021 11:24:12 GMT, Tagir F. Valeev  wrote:

>> With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch.
>> 
>> Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch:
>> 
>> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10   40235,534 ?     0,984    B/op
>> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  106431,101 ?     0,198    B/op
>> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  106544,977 ?     1,983    B/op
>> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10   40121,878 ?     0,247    B/op
>> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  106317,693 ?     1,083    B/op
>> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  106430,954 ?     0,136    B/op
>> 
>> 
>> After patch:
>> 
>> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10  40235,648 ?     1,354    B/op
>> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  40355,784 ?     1,288    B/op
>> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  40476,032 ?     2,855    B/op
>> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10  40121,830 ?     0,308    B/op
>> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  40242,554 ?     0,443    B/op
>> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  40363,674 ?     1,576    B/op
>> 
>> 
>> Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests.
>> 
>> Before patch:
>> 
>> Benchmark                         (size)   Mode  Cnt      Score     Error  Units
>> ref.SliceToList.par_baseline       10000  thrpt   30  14876,723 ?  99,770  ops/s
>> ref.SliceToList.par_limit          10000  thrpt   30  14856,841 ? 215,089  ops/s
>> ref.SliceToList.par_skipLimit      10000  thrpt   30   9555,818 ? 991,335  ops/s
>> ref.SliceToList.seq_baseline       10000  thrpt   30  23732,290 ? 444,162  ops/s
>> ref.SliceToList.seq_limit          10000  thrpt   30  14894,040 ? 176,496  ops/s
>> ref.SliceToList.seq_skipLimit      10000  thrpt   30  10646,929 ?  36,469  ops/s
>> value.SliceToArray.par_baseline    10000  thrpt   30  25093,141 ? 376,402  ops/s
>> value.SliceToArray.par_limit       10000  thrpt   30  24798,889 ? 760,762  ops/s
>> value.SliceToArray.par_skipLimit   10000  thrpt   30  16456,310 ? 926,882  ops/s
>> value.SliceToArray.seq_baseline    10000  thrpt   30  69669,787 ? 494,562  ops/s
>> value.SliceToArray.seq_limit       10000  thrpt   30  21097,081 ? 117,338  ops/s
>> value.SliceToArray.seq_skipLimit   10000  thrpt   30  15522,871 ? 112,557  ops/s
>> 
>> 
>> After patch:
>> 
>> Benchmark                         (size)   Mode  Cnt      Score      Error  Units
>> ref.SliceToList.par_baseline       10000  thrpt   30  14793,373 ?   64,905  ops/s
>> ref.SliceToList.par_limit          10000  thrpt   30  13301,024 ? 1300,431  ops/s
>> ref.SliceToList.par_skipLimit      10000  thrpt   30  11131,698 ? 1769,932  ops/s
>> ref.SliceToList.seq_baseline       10000  thrpt   30  24101,048 ?  263,528  ops/s
>> ref.SliceToList.seq_limit          10000  thrpt   30  16872,168 ?   76,696  ops/s
>> ref.SliceToList.seq_skipLimit      10000  thrpt   30  11953,253 ?  105,231  ops/s
>> value.SliceToArray.par_baseline    10000  thrpt   30  25442,442 ?  455,554  ops/s
>> value.SliceToArray.par_limit       10000  thrpt   30  23111,730 ? 2246,086  ops/s
>> value.SliceToArray.par_skipLimit   10000  thrpt   30  17980,750 ? 2329,077  ops/s
>> value.SliceToArray.seq_baseline    10000  thrpt   30  66512,898 ? 1001,042  ops/s
>> value.SliceToArray.seq_limit       10000  thrpt   30  41792,549 ? 1085,547  ops/s
>> value.SliceToArray.seq_skipLimit   10000  thrpt   30  18007,613 ?  141,716  ops/s
>> 
>> 
>> I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SIZE_ADJUSTING flag; exactOutputSize is pure

src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 482:

> 480:      * Returns the exact output size of the pipeline given the exact size reported by the previous stage.
> 481:      *
> 482:      * @param previousSize the exact size reported by the previous stage

I renamed `sourceSize` parameter to `previousSize`, as `source` could be associated with `sourceStage` which is misleading here.

src/java.base/share/classes/java/util/stream/StreamOpFlag.java line 340:

> 338:                    set(Type.OP));
> 339:     
> 340:     // The following 2 flags are currently undefined and a free for any further

For some reason, the comment says 'The following 2 flags', while we had three, so it was incorrect before but correct now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3427

From amaembo at gmail.com  Sun May 23 12:14:53 2021
From: amaembo at gmail.com (Tagir Valeev)
Date: Sun, 23 May 2021 19:14:53 +0700
Subject: New java.util.Strings class
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

Hello!

> 1) I based my code in the current java.util.Objects class of Java 16. I don't know why the Objects class was a good idea, but the Strings class is not.

Because Objects class is applicable to any objects (including strings)
while Strings is applicable to strings only which greatly narrows its
domain.

> 2) It's not just treating with nulls, but also with empty strings and whitespaces. If Java doesn't have this utilities, people will have to use external libraries like Guava or Apache Commons.

People already use Guava and Apache Commons and I see nothing wrong
with this. The strong point of Java is the huge third-party libraries
ecosystem and easiness of using them in your projects. Sometimes,
adding methods to the JDK directly makes the code more concise and
more performant, compared to third-party library. For example,
String::repeat was available in many third-party libraries but
instance method in java.lang.String makes the code shorter and the
ability to use internal APIs (e.g., to encode compact-string) makes it
more performant, compared to third-party implementation. However, in
your case, adding these methods to a standard library doesn't have
these advantages, compared to using a third-party library. Moreover,
it will add confusion and inconvenience for Guava users, as there's
already Strings class in Guava, so it will be hard to use both Guava
Strings and JDK Strings.

Btw, if I understand correctly, string.strip().isEmpty() could be
replaced with a more performant string.isBlank() call.

With best regards,
Tagir Valeev

>
> 3) I don't think (when developing a programming language) it is a good idea to just think in what nowadays you think is a "properly written application". Java should be prepared for applications programmed in completely different ways.
>
> Regards,
>
> Alberto.
>
> ________________________________
> De: Raffaello Giulietti 
> Enviado: s?bado, 22 de mayo de 2021 13:22
> Para: core-libs-dev at openjdk.java.net ; Alberto Otero Rodr?guez 
> Asunto: Re: New java.util.Strings class
>
> Hi Alberto,
>
> there's an understandable tendency to wish to add convenience/utility
> methods like the ones you are proposing. Often, however, the perceived
> benefits are not assessed accurately. In other words, convenience
> methods in core libraries must be of real general interest.
>
> Coming to your class, it exposes the constant EMPTY_STRING for "". Now,
> this is 12 characters (or even more if you don't use static imports)
> against 2 for nothing in exchange: "" is very readable, is not a magic
> constant that would deserve a global name, is interned and comes exactly
> to the point. Finding/replacing all occurrences of "" in a code base, if
> so needed, is easy even with the most elementary tools.
>
> Some methods are there just to come around null strings. Now, a properly
> written application rarely uses null strings and if that happens it is
> mostly because of logical errors. The proposed methods hide them instead
> of pointing at their cause by throwing, so would even be harmful if used
> there. Thus, the general usefulness of such methods is probably more
> limited than intended by the proposal.
>
> Other methods are focused on empty strings or strings of whitespaces.
> Agreed, some business logic would have to treat them specially and could
> benefit, but what's so outstanding with them to deserve API points in a
> core lib? In addition, some methods invoke String::strip() just to test
> whether a string is whitespaces.
>
> This is not to say that your methods are not useful, only that they are
> probably not *that* useful to be included as a core lib.
>
> A great post about the tension between the desire to add convenience
> methods to the core libs and try to refrain from doing so:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077103.html
>
>
> Greetings
> Raffaello
>
>
> On 2021-05-21 11:11, Alberto Otero Rodr?guez wrote:
> > Hi,
> >
> > I have made other changes to the Strings class I proposed in my previous messages.
> >
> > The changes are:
> >
> >    *   Added the new methods compareTo and compareToIgnoreCase
> >    *   Changed WhiteSpace for Whitespace
> >
> > You can see the new code here:
> > https://github.com/Aliuken/Java-Strings/blob/main/Strings.java
> >
> > With those changes, the annotations suggested in the previous message should change to:
> > - @NonNullNorWhitespace
> > - @NonNullNorWhitespaceElse(defaultValue)
> > - @NonNullNorWhitespaceElseGet(class::supplierMethod)
> >
> > Regards,
> >
> > Alberto Otero Rodr?guez.
> > ________________________________
> > De: Alberto Otero Rodr?guez 
> > Enviado: mi?rcoles, 19 de mayo de 2021 11:36
> > Para: core-libs-dev at openjdk.java.net 
> > Asunto: RE: New java.util.Strings class
> >
> > Hi,
> >
> > I have made some changes to the Strings class I proposed in my previous message.
> >
> > The changes are:
> >
> >    *   Use str.isEmpty() instead of EMPTY_STRING.equals(str)
> >    *   Create methods using str.strip() to check a String is not Whitespace
> >
> > You can see the new code here:
> > https://github.com/Aliuken/Java-Strings/blob/main/Strings.java
> >
> > With those changes, the following annotations could also be created for method arguments and return types:
> > - @NonNullNorWhiteSpace
> > - @NonNullNorWhiteSpaceElse(defaultValue)
> > - @NonNullNorWhiteSpaceElseGet(class::supplierMethod)
> >
> > I didn't have any response to the previous message.
> >
> > Please, take this one in consideration.
> >
> > Regards,
> >
> > Alberto Otero Rodr?guez.
> >
> > ________________________________
> > De: Alberto Otero Rodr?guez
> > Enviado: lunes, 17 de mayo de 2021 14:58
> > Para: core-libs-dev at openjdk.java.net 
> > Asunto: New java.util.Strings class
> >
> > Hi, members of the core-libs developers of OpenJDK.
> >
> > I think Java needs a Strings class similar to the java.util.Objects class of Java 16 to be used in method arguments, return types and Stream filters.
> >
> > I have coded it myself here based on the Objects implementation of Java 16 (please have a look):
> > https://github.com/Aliuken/Java-Strings/blob/main/Strings.java
> >
> > In fact, I think it would be useful also adding annotations for method arguments and return types such as:
> > - @NonNull
> > - @NonNullElse(defaultValue)
> > - @NonNullElseGet(class::supplierMethod)
> > - @NonNullNorEmpty
> > - @NonNullNorEmptyElse(defaultValue)
> > - @NonNullNorEmptyElseGet(class::supplierMethod)
> >
> > With that kind of annotations, you could assume thinks like:
> > - an argument or return type cannot have value null, but an Exception
> > - an argument or return type cannot have value null, but a default value
> >
> > What do you think?
> >
> > Waiting for your response.
> >
> > PS: I am sending this email repeated. I have sended it yesterday with my other email account (alber84ou at gmail.com), but I wasn't a member of this mailing list. Now I have become a member with this other email account.
> >
> > Regards,
> >
> > Alberto Otero Rodr?guez.
> >

From albest512 at hotmail.com  Sun May 23 12:39:39 2021
From: albest512 at hotmail.com (=?iso-8859-1?Q?Alberto_Otero_Rodr=EDguez?=)
Date: Sun, 23 May 2021 12:39:39 +0000
Subject: New java.util.Strings class
In-Reply-To: 
References: 
 
 
 
 ,
 
Message-ID: 

Hi Tagir, several things I want to talk about:

1) In Guava already existed an Objects class before Java created its own Objects class. So, I don't see any problem in creating now a Strings class.

2) The idea of creating the class in Java is to use a better or more performant implementation. For example, nowadays is better using strip() instead of trim().

3) As far as I know, string.isBlank() is equivalent to string().trim().isEmpty(), but I'm not sure if it is equivalent to string.strip().isEmpty().

Regards,

Alberto.
________________________________
De: Tagir Valeev 
Enviado: domingo, 23 de mayo de 2021 14:14
Para: Alberto Otero Rodr?guez 
Cc: core-libs-dev at openjdk.java.net 
Asunto: Re: New java.util.Strings class

Hello!

> 1) I based my code in the current java.util.Objects class of Java 16. I don't know why the Objects class was a good idea, but the Strings class is not.

Because Objects class is applicable to any objects (including strings)
while Strings is applicable to strings only which greatly narrows its
domain.

> 2) It's not just treating with nulls, but also with empty strings and whitespaces. If Java doesn't have this utilities, people will have to use external libraries like Guava or Apache Commons.

People already use Guava and Apache Commons and I see nothing wrong
with this. The strong point of Java is the huge third-party libraries
ecosystem and easiness of using them in your projects. Sometimes,
adding methods to the JDK directly makes the code more concise and
more performant, compared to third-party library. For example,
String::repeat was available in many third-party libraries but
instance method in java.lang.String makes the code shorter and the
ability to use internal APIs (e.g., to encode compact-string) makes it
more performant, compared to third-party implementation. However, in
your case, adding these methods to a standard library doesn't have
these advantages, compared to using a third-party library. Moreover,
it will add confusion and inconvenience for Guava users, as there's
already Strings class in Guava, so it will be hard to use both Guava
Strings and JDK Strings.

Btw, if I understand correctly, string.strip().isEmpty() could be
replaced with a more performant string.isBlank() call.

With best regards,
Tagir Valeev

>
> 3) I don't think (when developing a programming language) it is a good idea to just think in what nowadays you think is a "properly written application". Java should be prepared for applications programmed in completely different ways.
>
> Regards,
>
> Alberto.
>
> ________________________________
> De: Raffaello Giulietti 
> Enviado: s?bado, 22 de mayo de 2021 13:22
> Para: core-libs-dev at openjdk.java.net ; Alberto Otero Rodr?guez 
> Asunto: Re: New java.util.Strings class
>
> Hi Alberto,
>
> there's an understandable tendency to wish to add convenience/utility
> methods like the ones you are proposing. Often, however, the perceived
> benefits are not assessed accurately. In other words, convenience
> methods in core libraries must be of real general interest.
>
> Coming to your class, it exposes the constant EMPTY_STRING for "". Now,
> this is 12 characters (or even more if you don't use static imports)
> against 2 for nothing in exchange: "" is very readable, is not a magic
> constant that would deserve a global name, is interned and comes exactly
> to the point. Finding/replacing all occurrences of "" in a code base, if
> so needed, is easy even with the most elementary tools.
>
> Some methods are there just to come around null strings. Now, a properly
> written application rarely uses null strings and if that happens it is
> mostly because of logical errors. The proposed methods hide them instead
> of pointing at their cause by throwing, so would even be harmful if used
> there. Thus, the general usefulness of such methods is probably more
> limited than intended by the proposal.
>
> Other methods are focused on empty strings or strings of whitespaces.
> Agreed, some business logic would have to treat them specially and could
> benefit, but what's so outstanding with them to deserve API points in a
> core lib? In addition, some methods invoke String::strip() just to test
> whether a string is whitespaces.
>
> This is not to say that your methods are not useful, only that they are
> probably not *that* useful to be included as a core lib.
>
> A great post about the tension between the desire to add convenience
> methods to the core libs and try to refrain from doing so:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077103.html
>
>
> Greetings
> Raffaello
>
>
> On 2021-05-21 11:11, Alberto Otero Rodr?guez wrote:
> > Hi,
> >
> > I have made other changes to the Strings class I proposed in my previous messages.
> >
> > The changes are:
> >
> >    *   Added the new methods compareTo and compareToIgnoreCase
> >    *   Changed WhiteSpace for Whitespace
> >
> > You can see the new code here:
> > https://github.com/Aliuken/Java-Strings/blob/main/Strings.java
> >
> > With those changes, the annotations suggested in the previous message should change to:
> > - @NonNullNorWhitespace
> > - @NonNullNorWhitespaceElse(defaultValue)
> > - @NonNullNorWhitespaceElseGet(class::supplierMethod)
> >
> > Regards,
> >
> > Alberto Otero Rodr?guez.
> > ________________________________
> > De: Alberto Otero Rodr?guez 
> > Enviado: mi?rcoles, 19 de mayo de 2021 11:36
> > Para: core-libs-dev at openjdk.java.net 
> > Asunto: RE: New java.util.Strings class
> >
> > Hi,
> >
> > I have made some changes to the Strings class I proposed in my previous message.
> >
> > The changes are:
> >
> >    *   Use str.isEmpty() instead of EMPTY_STRING.equals(str)
> >    *   Create methods using str.strip() to check a String is not Whitespace
> >
> > You can see the new code here:
> > https://github.com/Aliuken/Java-Strings/blob/main/Strings.java
> >
> > With those changes, the following annotations could also be created for method arguments and return types:
> > - @NonNullNorWhiteSpace
> > - @NonNullNorWhiteSpaceElse(defaultValue)
> > - @NonNullNorWhiteSpaceElseGet(class::supplierMethod)
> >
> > I didn't have any response to the previous message.
> >
> > Please, take this one in consideration.
> >
> > Regards,
> >
> > Alberto Otero Rodr?guez.
> >
> > ________________________________
> > De: Alberto Otero Rodr?guez
> > Enviado: lunes, 17 de mayo de 2021 14:58
> > Para: core-libs-dev at openjdk.java.net 
> > Asunto: New java.util.Strings class
> >
> > Hi, members of the core-libs developers of OpenJDK.
> >
> > I think Java needs a Strings class similar to the java.util.Objects class of Java 16 to be used in method arguments, return types and Stream filters.
> >
> > I have coded it myself here based on the Objects implementation of Java 16 (please have a look):
> > https://github.com/Aliuken/Java-Strings/blob/main/Strings.java
> >
> > In fact, I think it would be useful also adding annotations for method arguments and return types such as:
> > - @NonNull
> > - @NonNullElse(defaultValue)
> > - @NonNullElseGet(class::supplierMethod)
> > - @NonNullNorEmpty
> > - @NonNullNorEmptyElse(defaultValue)
> > - @NonNullNorEmptyElseGet(class::supplierMethod)
> >
> > With that kind of annotations, you could assume thinks like:
> > - an argument or return type cannot have value null, but an Exception
> > - an argument or return type cannot have value null, but a default value
> >
> > What do you think?
> >
> > Waiting for your response.
> >
> > PS: I am sending this email repeated. I have sended it yesterday with my other email account (alber84ou at gmail.com), but I wasn't a member of this mailing list. Now I have become a member with this other email account.
> >
> > Regards,
> >
> > Alberto Otero Rodr?guez.
> >

From alanb at openjdk.java.net  Sun May 23 15:38:38 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 23 May 2021 15:38:38 GMT
Subject: RFR: 8191441: (Process) add Readers and Writer access to
 java.lang.Process streams [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 22 May 2021 01:24:24 GMT, Roger Riggs  wrote:

>> Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process.
>> The Charset used to encode and decode characters to bytes can be specified or use the
>> operating system native encoding as is available from the "native.encoding" system property.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use BufferedWriter and OutputStreamWriter and address review comments

The updated proposal looks reasonable, as does the names of the methods.

I think the javadoc will need to specify how malformed or unmappable byte sequence are handled.  The implNote does document that it uses InputStreamReader so this means that erroneous input is replaced but this isn't normative text.

It may be useful to specify how these methods are intended to work when the process has terminated. I realise the existing getXXXX aren't clear on this point and maybe they should.

The API note that warns about unpredictable behavior then trying to use both the byte and character stream probably needs to go into the existing methods too.

NPE will need to be documented as I don't think the Process class description has a statement to avoid clutter in the method descriptions. You will eventually need to add the @since javadoc tag too.

Is there more test coverage to come? I don't see tests that exercise the redirect cases or NPE. The test updates includes an adjustment to how SerialFilterTest is run - is that meant to be included?

A formatting nit is that the line lengths are very really long compared to the rest of the source file.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4134

From mullan at openjdk.java.net  Sun May 23 16:40:59 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Sun, 23 May 2021 16:40:59 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
Message-ID: 

On Fri, 21 May 2021 15:27:39 GMT, Daniel Fuchs  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>
> src/java.base/share/classes/java/lang/SecurityManager.java line 104:
> 
>> 102:  * method will throw an {@code UnsupportedOperationException}). If the
>> 103:  * {@systemProperty java.security.manager} system property is set to the
>> 104:  * special token "{@code allow}", then a security manager will not be set at
> 
> Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.

Good point. I would remove the extra @systemProperty tags on lines 103, 106, and 113. Also, in `System.setSecurityManager` there are 3 @systemProperty java.security.manager tags, I would just keep the first one. (I think it's ok to have more than one, if they are defined in different APIs).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From kasperni at gmail.com  Sun May 23 17:16:45 2021
From: kasperni at gmail.com (Kasper Nielsen)
Date: Sun, 23 May 2021 18:16:45 +0100
Subject: RFR: 8224243: Make AccessibleObject a sealed class [v2]
In-Reply-To: <1p8BXJHpzVJ_nPh9j0sRoOJwdiYNkO_6DK9sg5T92_A=.9a001d1a-f0d9-428e-8c45-fb5f04cf79b4@github.com>
References: <4DFE3N_LB1D0jraDzmAmhGpzPGZAZrluVqCM5LFo5B4=.bbe76387-44f8-44de-ae2a-ce89d823041b@github.com>
 <1p8BXJHpzVJ_nPh9j0sRoOJwdiYNkO_6DK9sg5T92_A=.9a001d1a-f0d9-428e-8c45-fb5f04cf79b4@github.com>
Message-ID: 

On Fri, 21 May 2021 at 03:44, Joe Darcy  wrote:

> > Conceptually, AccessbileObject is a sealed class with a protected
> constructor stating
> >
> >     Constructor: only used by the Java Virtual Machine.
> >
> > With the language now supporting sealed classes, the AccessbileObject
> should be marked as sealed.
> >
> > Executable and Field are the subclasses of AccessbileObject in the JDK;
> as Executable has subclasses, it is marked as non-sealed.
> >
> > Please also review the corresponding CSR:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8224243
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
>   Update in response to review feedback.
>
> -------------
>

The implementation of setAccessible(boolean) is identical on both
Method/Constructor/Field so it could probably be pulled down into
AccessibleObject, similar to trySetAccessible().

/Kasper

From rriggs at openjdk.java.net  Mon May 24 00:33:06 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 24 May 2021 00:33:06 GMT
Subject: RFR: 8191441: (Process) add Readers and Writer access to
 java.lang.Process streams [v3]
In-Reply-To: 
References: 
Message-ID: 

> Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process.
> The Charset used to encode and decode characters to bytes can be specified or use the
> operating system native encoding as is available from the "native.encoding" system property.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Added throws for NPE, delegated zero-arg methods that use native.encoding to
  the 1-arg method with a charset, added tests for Redirect cases where the streams are null-input or null-output streams.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4134/files
  - new: https://git.openjdk.java.net/jdk/pull/4134/files/5a4a85d2..7724b82c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4134&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4134&range=01-02

  Stats: 180 lines in 3 files changed: 136 ins; 0 del; 44 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4134.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4134/head:pull/4134

PR: https://git.openjdk.java.net/jdk/pull/4134

From rriggs at openjdk.java.net  Mon May 24 01:24:24 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 24 May 2021 01:24:24 GMT
Subject: RFR: 8191441: (Process) add Readers and Writer access to
 java.lang.Process streams [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 24 May 2021 00:33:06 GMT, Roger Riggs  wrote:

>> Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process.
>> The Charset used to encode and decode characters to bytes can be specified or use the
>> operating system native encoding as is available from the "native.encoding" system property.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added throws for NPE, delegated zero-arg methods that use native.encoding to
>   the 1-arg method with a charset, added tests for Redirect cases where the streams are null-input or null-output streams.

Thanks for the comments, most are addressed.

> The updated proposal looks reasonable, as does the names of the methods.
> 
> I think the javadoc will need to specify how malformed or unmappable byte sequence are handled. The implNote does document that it uses InputStreamReader so this means that erroneous input is replaced but this isn't normative text.
> 
> It may be useful to specify how these methods are intended to work when the process has terminated. I realise the existing getXXXX aren't clear on this point and maybe they should.
> 
> The API note that warns about unpredictable behavior then trying to use both the byte and character stream probably needs to go into the existing methods too.
> 
> NPE will need to be documented as I don't think the Process class description has a statement to avoid clutter in the method descriptions. You will eventually need to add the @SInCE javadoc tag too.
> 
> Is there more test coverage to come? I don't see tests that exercise the redirect cases or NPE. The test updates includes an adjustment to how SerialFilterTest is run - is that meant to be included?
> 
> A formatting nit is that the line lengths are very really long compared to the rest of the source file.

On the question of process termination behavior, I'm not sure what can be said that could be specification.
The implementations vary between Mac, Linux, and Windows; with the common thread 
to avoid losing process output. But this may have to be included in the unspecified implementation behavior
or just an API note.  Suggestions?

I need to address what happens when these methods are called more than once.
They should return the same instance as the previous call.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4134

From tvaleev at openjdk.java.net  Mon May 24 04:33:42 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Mon, 24 May 2021 04:33:42 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch
In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
Message-ID: 

On Mon, 24 May 2021 04:20:23 GMT, Tagir F. Valeev  wrote:

> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
> 
> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?

src/java.base/share/classes/java/util/jar/JarFile.java line 201:

> 199:                 MULTI_RELEASE_FORCED = true;
> 200:             }
> 201:             default -> {

Here, explicit `case "true"` disappeared. Not sure if it's important to keep it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161

From tvaleev at openjdk.java.net  Mon May 24 04:33:40 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Mon, 24 May 2021 04:33:40 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch
Message-ID: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>

Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.

I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?

-------------

Commit messages:
 - 8267587: Update java.util to use enhanced switch

Changes: https://git.openjdk.java.net/jdk/pull/4161/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267587
  Stats: 887 lines in 17 files changed: 113 ins; 339 del; 435 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4161.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161

PR: https://git.openjdk.java.net/jdk/pull/4161

From tvaleev at openjdk.java.net  Mon May 24 04:35:42 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Mon, 24 May 2021 04:35:42 GMT
Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations
 (skip, limit) [v7]
In-Reply-To: 
References: 
Message-ID: 

> With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch.
> 
> Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch:
> 
> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10   40235,534 ?     0,984    B/op
> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  106431,101 ?     0,198    B/op
> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  106544,977 ?     1,983    B/op
> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10   40121,878 ?     0,247    B/op
> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  106317,693 ?     1,083    B/op
> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  106430,954 ?     0,136    B/op
> 
> 
> After patch:
> 
> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10  40235,648 ?     1,354    B/op
> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  40355,784 ?     1,288    B/op
> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  40476,032 ?     2,855    B/op
> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10  40121,830 ?     0,308    B/op
> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  40242,554 ?     0,443    B/op
> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  40363,674 ?     1,576    B/op
> 
> 
> Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests.
> 
> Before patch:
> 
> Benchmark                         (size)   Mode  Cnt      Score     Error  Units
> ref.SliceToList.par_baseline       10000  thrpt   30  14876,723 ?  99,770  ops/s
> ref.SliceToList.par_limit          10000  thrpt   30  14856,841 ? 215,089  ops/s
> ref.SliceToList.par_skipLimit      10000  thrpt   30   9555,818 ? 991,335  ops/s
> ref.SliceToList.seq_baseline       10000  thrpt   30  23732,290 ? 444,162  ops/s
> ref.SliceToList.seq_limit          10000  thrpt   30  14894,040 ? 176,496  ops/s
> ref.SliceToList.seq_skipLimit      10000  thrpt   30  10646,929 ?  36,469  ops/s
> value.SliceToArray.par_baseline    10000  thrpt   30  25093,141 ? 376,402  ops/s
> value.SliceToArray.par_limit       10000  thrpt   30  24798,889 ? 760,762  ops/s
> value.SliceToArray.par_skipLimit   10000  thrpt   30  16456,310 ? 926,882  ops/s
> value.SliceToArray.seq_baseline    10000  thrpt   30  69669,787 ? 494,562  ops/s
> value.SliceToArray.seq_limit       10000  thrpt   30  21097,081 ? 117,338  ops/s
> value.SliceToArray.seq_skipLimit   10000  thrpt   30  15522,871 ? 112,557  ops/s
> 
> 
> After patch:
> 
> Benchmark                         (size)   Mode  Cnt      Score      Error  Units
> ref.SliceToList.par_baseline       10000  thrpt   30  14793,373 ?   64,905  ops/s
> ref.SliceToList.par_limit          10000  thrpt   30  13301,024 ? 1300,431  ops/s
> ref.SliceToList.par_skipLimit      10000  thrpt   30  11131,698 ? 1769,932  ops/s
> ref.SliceToList.seq_baseline       10000  thrpt   30  24101,048 ?  263,528  ops/s
> ref.SliceToList.seq_limit          10000  thrpt   30  16872,168 ?   76,696  ops/s
> ref.SliceToList.seq_skipLimit      10000  thrpt   30  11953,253 ?  105,231  ops/s
> value.SliceToArray.par_baseline    10000  thrpt   30  25442,442 ?  455,554  ops/s
> value.SliceToArray.par_limit       10000  thrpt   30  23111,730 ? 2246,086  ops/s
> value.SliceToArray.par_skipLimit   10000  thrpt   30  17980,750 ? 2329,077  ops/s
> value.SliceToArray.seq_baseline    10000  thrpt   30  66512,898 ? 1001,042  ops/s
> value.SliceToArray.seq_limit       10000  thrpt   30  41792,549 ? 1085,547  ops/s
> value.SliceToArray.seq_skipLimit   10000  thrpt   30  18007,613 ?  141,716  ops/s
> 
> 
> I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Trailing whitespace removed

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3427/files
  - new: https://git.openjdk.java.net/jdk/pull/3427/files/e6d7bd6a..3da4da7c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3427&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3427&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3427.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3427/head:pull/3427

PR: https://git.openjdk.java.net/jdk/pull/3427

From jbhateja at openjdk.java.net  Mon May 24 05:50:44 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 24 May 2021 05:50:44 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v7]
In-Reply-To: 
References: 
Message-ID: 

> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
> 
>     vec1 = lanewise(VectorOperators.LSHL, n)
>     vec2 = lanewise(VectorOperators.LSHR, n)
>     res = lanewise(VectorOperations.OR, vec1 , vec2)
> 
> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
> 
> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
> 
> Please find below the performance data for included JMH benchmark.
> Machine:  Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz)
> 
> 
> Benchmark | (TESTSIZE) | Shift | Baseline AVX3 (ops/ms) | Withopt? AVX3 (ops/ms) | Gain % | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain %
> -- | -- | -- | -- | -- | -- | -- | -- | --
> ? | ? | ? | ? | ? | ? | ? | ? | ?
> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 17223.35 | 17094.69 | -0.75 | 17008.32 | 17488.06 | 2.82
> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 8944.98 | 8811.34 | -1.49 | 8878.17 | 9218.68 | 3.84
> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 17195.75 | 17137.32 | -0.34 | 16789.01 | 17780.34 | 5.90
> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 9052.67 | 8838.60 | -2.36 | 8814.62 | 9206.01 | 4.44
> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 17100.19 | 16950.64 | -0.87 | 16827.73 | 17720.37 | 5.30
> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 9079.95 | 8471.26 | -6.70 | 8888.44 | 9167.68 | 3.14
> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 21231.33 | 21513.08 | 1.33 | 21824.51 | 21479.48 | -1.58
> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 11103.62 | 11180.16 | 0.69 | 11173.67 | 11529.22 | 3.18
> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 21119.14 | 21552.04 | 2.05 | 21693.05 | 21915.37 | 1.02
> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 11048.68 | 11094.20 | 0.41 | 11049.90 | 11439.07 | 3.52
> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 21506.31 | 21391.41 | -0.53 | 21263.18 | 21986.29 | 3.40
> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 11056.12 | 11232.78 | 1.60 | 10941.59 | 11397.09 | 4.16
> RotateBenchmark.testRotateLeftB | 512.00 | 7.00 | 17976.56 | 18180.85 | 1.14 | 1212.26 | 2533.34 | 108.98
> RotateBenchmark.testRotateLeftB | 512.00 | 15.00 | 17553.70 | 18219.07 | 3.79 | 1256.73 | 2537.41 | 101.91
> RotateBenchmark.testRotateLeftB | 512.00 | 31.00 | 17618.03 | 17738.15 | 0.68 | 1214.69 | 2533.83 | 108.60
> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 7258.87 | 7468.88 | 2.89 | 7115.12 | 7117.26 | 0.03
> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 3586.65 | 3950.85 | 10.15 | 3532.17 | 3595.80 | 1.80
> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 1835.07 | 1999.68 | 8.97 | 1789.90 | 1819.93 | 1.68
> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 7273.36 | 7410.91 | 1.89 | 7198.60 | 6994.79 | -2.83
> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 3674.98 | 3926.27 | 6.84 | 3549.90 | 3755.09 | 5.78
> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 1840.94 | 1882.25 | 2.24 | 1801.56 | 1872.89 | 3.96
> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 7457.11 | 7361.48 | -1.28 | 6975.33 | 7385.94 | 5.89
> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 3570.74 | 3929.30 | 10.04 | 3635.37 | 3736.67 | 2.79
> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 1902.32 | 1960.46 | 3.06 | 1812.32 | 1813.88 | 0.09
> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 11174.24 | 12044.52 | 7.79 | 11509.87 | 11273.44 | -2.05
> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 5981.47 | 6073.70 | 1.54 | 5593.66 | 5661.93 | 1.22
> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 2932.49 | 3069.54 | 4.67 | 2950.86 | 2892.42 | -1.98
> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 11764.11 | 12098.63 | 2.84 | 11069.52 | 11476.93 | 3.68
> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 5855.20 | 6080.40 | 3.85 | 5919.11 | 5607.04 | -5.27
> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 2989.05 | 3048.56 | 1.99 | 2902.63 | 2821.83 | -2.78
> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 11652.84 | 11965.40 | 2.68 | 11525.62 | 11459.83 | -0.57
> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 5851.82 | 6164.94 | 5.35 | 5882.60 | 5842.30 | -0.69
> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 3015.99 | 3043.79 | 0.92 | 2963.71 | 2947.97 | -0.53
> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 16029.15 | 16189.79 | 1.00 | 860.43 | 2339.32 | 171.88
> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 8078.25 | 8081.84 | 0.04 | 427.39 | 1147.92 | 168.59
> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 4021.49 | 4294.03 | 6.78 | 209.25 | 582.28 | 178.27
> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 15912.98 | 16329.03 | 2.61 | 848.23 | 2296.78 | 170.77
> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 8054.10 | 8306.37 | 3.13 | 429.93 | 1146.90 | 166.77
> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 4102.58 | 4071.08 | -0.77 | 217.86 | 582.20 | 167.24
> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 16177.79 | 16287.85 | 0.68 | 857.84 | 2243.15 | 161.49
> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 8187.47 | 8410.48 | 2.72 | 434.60 | 1128.20 | 159.60
> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 4109.15 | 4233.80 | 3.03 | 208.71 | 572.43 | 174.27
> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 3755.09 | 3930.29 | 4.67 | 3604.19 | 3598.47 | -0.16
> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 1829.03 | 1957.39 | 7.02 | 1833.95 | 1808.38 | -1.39
> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 915.35 | 970.55 | 6.03 | 916.25 | 899.08 | -1.87
> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 3664.85 | 3812.26 | 4.02 | 3629.37 | 3579.23 | -1.38
> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 1829.51 | 1877.76 | 2.64 | 1781.05 | 1807.57 | 1.49
> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 913.37 | 953.42 | 4.38 | 912.26 | 908.73 | -0.39
> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 3648.45 | 3899.20 | 6.87 | 3552.67 | 3581.04 | 0.80
> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 1816.50 | 1959.68 | 7.88 | 1820.88 | 1819.71 | -0.06
> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 901.05 | 955.13 | 6.00 | 913.74 | 907.90 | -0.64
> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 5850.99 | 6108.64 | 4.40 | 5882.65 | 5755.21 | -2.17
> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 2962.21 | 3060.47 | 3.32 | 2955.20 | 2909.18 | -1.56
> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 1480.46 | 1534.72 | 3.66 | 1467.78 | 1430.60 | -2.53
> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 5858.23 | 6047.51 | 3.23 | 5770.02 | 5773.19 | 0.05
> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 2951.49 | 3096.53 | 4.91 | 2885.21 | 2899.31 | 0.49
> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 1486.26 | 1527.94 | 2.80 | 1441.93 | 1454.25 | 0.85
> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 5873.21 | 6089.75 | 3.69 | 5767.58 | 5664.11 | -1.79
> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 2969.67 | 3081.39 | 3.76 | 2878.50 | 2905.86 | 0.95
> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 1452.21 | 1520.03 | 4.67 | 1430.30 | 1485.63 | 3.87
> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 8088.65 | 8443.63 | 4.39 | 455.67 | 1226.33 | 169.13
> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 4011.95 | 4120.25 | 2.70 | 229.77 | 619.87 | 169.77
> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 2090.57 | 2109.53 | 0.91 | 115.21 | 310.36 | 169.37
> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 8166.84 | 8557.28 | 4.78 | 457.67 | 1242.86 | 171.56
> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 4137.02 | 4287.95 | 3.65 | 227.26 | 624.80 | 174.93
> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 2095.01 | 2102.86 | 0.37 | 114.26 | 310.83 | 172.03
> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 8082.68 | 8400.56 | 3.93 | 459.59 | 1230.07 | 167.64
> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 4047.67 | 4147.58 | 2.47 | 229.01 | 606.38 | 164.78
> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 2086.83 | 2126.72 | 1.91 | 111.93 | 305.66 | 173.08
> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 13597.19 | 13255.09 | -2.52 | 13818.39 | 13242.40 | -4.17
> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 7028.26 | 6826.59 | -2.87 | 6765.15 | 6907.87 | 2.11
> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 3570.40 | 3468.01 | -2.87 | 3449.66 | 3533.50 | 2.43
> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 13615.99 | 13464.40 | -1.11 | 13330.02 | 13870.57 | 4.06
> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 7043.31 | 6763.34 | -3.97 | 6928.88 | 7063.57 | 1.94
> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 3495.12 | 3537.62 | 1.22 | 3503.41 | 3457.67 | -1.31
> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 13591.66 | 13665.84 | 0.55 | 13773.27 | 13126.08 | -4.70
> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 7027.08 | 7011.24 | -0.23 | 6974.98 | 6815.50 | -2.29
> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 3568.28 | 3569.62 | 0.04 | 3580.67 | 3463.58 | -3.27
> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 21154.03 | 21416.32 | 1.24 | 21187.01 | 21401.61 | 1.01
> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 11194.24 | 10865.47 | -2.94 | 11063.19 | 10977.60 | -0.77
> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 5797.80 | 5523.94 | -4.72 | 5654.63 | 5468.78 | -3.29
> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 21333.89 | 21412.74 | 0.37 | 21610.94 | 20908.96 | -3.25
> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 11327.07 | 11113.48 | -1.89 | 11148.25 | 10678.14 | -4.22
> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 5810.69 | 5569.72 | -4.15 | 5663.26 | 5618.87 | -0.78
> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 21753.20 | 21198.43 | -2.55 | 21567.90 | 21929.81 | 1.68
> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 11517.08 | 11039.64 | -4.15 | 11103.08 | 10871.59 | -2.08
> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 5897.16 | 5606.75 | -4.92 | 5459.87 | 5604.12 | 2.64
> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 29748.53 | 28883.73 | -2.91 | 1549.02 | 3928.53 | 153.61
> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 15197.09 | 15878.19 | 4.48 | 772.59 | 1924.35 | 149.08
> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 8046.30 | 8081.19 | 0.43 | 388.11 | 990.28 | 155.16
> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 30618.04 | 29419.19 | -3.92 | 1524.22 | 3915.97 | 156.92
> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 15854.43 | 15846.37 | -0.05 | 766.09 | 1953.60 | 155.01
> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 7814.77 | 7899.30 | 1.08 | 390.82 | 970.37 | 148.29
> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 29596.82 | 28538.69 | -3.58 | 1530.45 | 3906.91 | 155.28
> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 15662.48 | 15849.25 | 1.19 | 778.08 | 1934.31 | 148.60
> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 8121.14 | 7758.59 | -4.46 | 392.78 | 959.73 | 144.34
> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 17465.84 | 17069.34 | -2.27 | 16849.73 | 17842.08 | 5.89
> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 9049.19 | 8864.15 | -2.04 | 8786.67 | 9105.34 | 3.63
> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 17703.38 | 17070.98 | -3.57 | 16595.85 | 17784.68 | 7.16
> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 9007.68 | 8817.41 | -2.11 | 8704.49 | 9185.87 | 5.53
> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 17531.05 | 16983.40 | -3.12 | 16947.69 | 17655.40 | 4.18
> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 8986.30 | 8794.15 | -2.14 | 8816.62 | 9225.95 | 4.64
> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 21293.95 | 21506.74 | 1.00 | 21163.29 | 21854.03 | 3.26
> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 11258.47 | 11072.92 | -1.65 | 11118.12 | 11338.96 | 1.99
> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 21253.36 | 21292.37 | 0.18 | 21224.39 | 21763.88 | 2.54
> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 11064.80 | 11198.35 | 1.21 | 10960.98 | 11294.14 | 3.04
> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 21358.14 | 21346.21 | -0.06 | 21487.25 | 21854.42 | 1.71
> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 11045.61 | 11208.26 | 1.47 | 10907.03 | 11415.18 | 4.66
> RotateBenchmark.testRotateRightB | 512.00 | 7.00 | 17898.61 | 18307.54 | 2.28 | 1214.65 | 2546.64 | 109.66
> RotateBenchmark.testRotateRightB | 512.00 | 15.00 | 17909.25 | 18242.51 | 1.86 | 1215.05 | 2563.98 | 111.02
> RotateBenchmark.testRotateRightB | 512.00 | 31.00 | 17883.35 | 17928.44 | 0.25 | 1220.77 | 2543.30 | 108.34
> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 7139.97 | 7626.72 | 6.82 | 6994.86 | 7075.65 | 1.15
> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 3657.37 | 3898.34 | 6.59 | 3617.06 | 3576.12 | -1.13
> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 1804.26 | 1969.19 | 9.14 | 1796.62 | 1858.84 | 3.46
> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 7404.31 | 7760.09 | 4.80 | 7036.77 | 7401.52 | 5.18
> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 3600.52 | 3956.35 | 9.88 | 3595.28 | 3560.36 | -0.97
> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 1813.32 | 1966.41 | 8.44 | 1839.95 | 1852.53 | 0.68
> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 7118.48 | 7724.81 | 8.52 | 7151.56 | 7021.09 | -1.82
> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 3529.70 | 3881.63 | 9.97 | 3623.08 | 3601.01 | -0.61
> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 1823.61 | 1961.34 | 7.55 | 1786.86 | 1748.85 | -2.13
> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 11697.98 | 11835.25 | 1.17 | 11513.16 | 11184.87 | -2.85
> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 5890.11 | 6102.57 | 3.61 | 5658.79 | 5696.08 | 0.66
> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 2964.94 | 3070.26 | 3.55 | 2945.00 | 2962.08 | 0.58
> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 11562.51 | 12151.29 | 5.09 | 11404.17 | 11120.28 | -2.49
> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 5702.93 | 6130.57 | 7.50 | 5799.54 | 5779.08 | -0.35
> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 2861.96 | 3051.44 | 6.62 | 2943.99 | 2860.65 | -2.83
> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 11203.13 | 11710.59 | 4.53 | 11363.18 | 11112.16 | -2.21
> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 5893.97 | 6070.71 | 3.00 | 5776.67 | 5648.84 | -2.21
> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 2971.83 | 3046.76 | 2.52 | 2903.35 | 2833.88 | -2.39
> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 16064.71 | 15851.35 | -1.33 | 861.93 | 2256.88 | 161.84
> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 7916.80 | 8462.65 | 6.89 | 430.23 | 1147.30 | 166.67
> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 4104.64 | 4068.28 | -0.89 | 216.30 | 572.86 | 164.84
> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 16133.09 | 16281.59 | 0.92 | 856.36 | 2229.58 | 160.35
> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 8127.26 | 8117.59 | -0.12 | 419.16 | 1176.42 | 180.66
> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 4080.11 | 4063.26 | -0.41 | 218.32 | 571.93 | 161.97
> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 15834.26 | 16314.64 | 3.03 | 865.96 | 2297.74 | 165.34
> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 7965.62 | 8270.48 | 3.83 | 428.55 | 1148.87 | 168.08
> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 4161.69 | 4034.76 | -3.05 | 215.63 | 570.19 | 164.43
> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 3556.70 | 3877.08 | 9.01 | 3596.46 | 3558.32 | -1.06
> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 1772.93 | 1993.86 | 12.46 | 1856.79 | 1783.22 | -3.96
> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 908.66 | 1000.37 | 10.09 | 944.79 | 922.91 | -2.32
> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 3742.44 | 3748.41 | 0.16 | 3788.07 | 3570.67 | -5.74
> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 1817.53 | 1985.69 | 9.25 | 1892.38 | 1833.16 | -3.13
> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 941.03 | 952.68 | 1.24 | 915.79 | 910.21 | -0.61
> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 3649.48 | 3896.56 | 6.77 | 3637.59 | 3557.53 | -2.20
> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 1840.12 | 1997.19 | 8.54 | 1821.47 | 1799.82 | -1.19
> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 901.33 | 995.67 | 10.47 | 909.20 | 902.73 | -0.71
> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 5789.93 | 5960.54 | 2.95 | 5758.14 | 5736.30 | -0.38
> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 2963.20 | 3063.30 | 3.38 | 2943.48 | 2833.84 | -3.72
> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 1501.81 | 1510.23 | 0.56 | 1463.85 | 1462.26 | -0.11
> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 5870.05 | 5951.43 | 1.39 | 5794.74 | 5604.58 | -3.28
> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 2971.36 | 3047.00 | 2.55 | 2931.19 | 2907.30 | -0.82
> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 1473.97 | 1530.54 | 3.84 | 1473.45 | 1442.40 | -2.11
> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 5858.08 | 6080.49 | 3.80 | 5863.69 | 5549.85 | -5.35
> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 2916.24 | 3045.77 | 4.44 | 2981.59 | 2815.07 | -5.58
> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 1441.20 | 1531.56 | 6.27 | 1492.47 | 1473.25 | -1.29
> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 8147.24 | 8310.05 | 2.00 | 469.45 | 1235.21 | 163.12
> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 4142.95 | 4258.86 | 2.80 | 234.14 | 615.52 | 162.88
> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 2095.48 | 2087.20 | -0.40 | 113.55 | 311.19 | 174.05
> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 8222.94 | 8246.58 | 0.29 | 458.91 | 1244.32 | 171.15
> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 4160.04 | 4226.46 | 1.60 | 227.78 | 625.38 | 174.56
> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 2064.63 | 2162.44 | 4.74 | 113.27 | 314.15 | 177.36
> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 8157.94 | 8466.90 | 3.79 | 450.26 | 1221.90 | 171.37
> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 4039.74 | 4283.33 | 6.03 | 224.82 | 612.68 | 172.53
> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 2066.88 | 2147.51 | 3.90 | 110.97 | 303.43 | 173.42
> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 13548.39 | 13245.87 | -2.23 | 13490.93 | 13084.76 | -3.01
> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 7020.16 | 6768.85 | -3.58 | 6991.39 | 7044.32 | 0.76
> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 3550.50 | 3505.19 | -1.28 | 3507.12 | 3612.86 | 3.01
> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 13743.43 | 13325.44 | -3.04 | 13696.15 | 13255.80 | -3.22
> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 6856.02 | 6969.18 | 1.65 | 6886.29 | 6834.12 | -0.76
> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 3569.53 | 3492.76 | -2.15 | 3539.02 | 3470.02 | -1.95
> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 13704.18 | 13495.07 | -1.53 | 13649.14 | 13583.87 | -0.48
> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 7011.77 | 6953.93 | -0.82 | 6978.28 | 6740.30 | -3.41
> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 3591.62 | 3620.12 | 0.79 | 3502.04 | 3510.05 | 0.23
> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 21950.71 | 22113.60 | 0.74 | 21484.27 | 21596.64 | 0.52
> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 11616.88 | 11099.73 | -4.45 | 11188.29 | 10737.68 | -4.03
> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 5872.72 | 5579.12 | -5.00 | 5784.05 | 5454.57 | -5.70
> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 22017.83 | 20817.97 | -5.45 | 21934.65 | 21356.90 | -2.63
> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 11414.27 | 11044.86 | -3.24 | 11454.35 | 11140.34 | -2.74
> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 5786.64 | 5634.05 | -2.64 | 5724.93 | 5639.99 | -1.48
> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 21754.77 | 21466.01 | -1.33 | 21140.67 | 21970.03 | 3.92
> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 11676.46 | 11358.64 | -2.72 | 11204.90 | 11213.48 | 0.08
> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 5728.20 | 5772.49 | 0.77 | 5594.33 | 5544.25 | -0.90
> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 30247.03 | 30179.41 | -0.22 | 1538.75 | 3975.82 | 158.38
> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 15988.73 | 15621.42 | -2.30 | 776.04 | 1910.91 | 146.24
> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 8115.84 | 8025.28 | -1.12 | 389.12 | 984.46 | 152.99
> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 30110.91 | 30200.69 | 0.30 | 1532.49 | 3983.77 | 159.95
> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 15957.90 | 15690.73 | -1.67 | 774.90 | 1931.00 | 149.19
> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 8113.26 | 8037.93 | -0.93 | 391.90 | 965.53 | 146.37
> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 29816.97 | 29891.54 | 0.25 | 1538.12 | 3881.93 | 152.38
> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 15405.95 | 15619.17 | 1.38 | 762.49 | 1871.00 | 145.38
> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 7919.80 | 7957.35 | 0.47 | 393.63 | 972.49 | 147.06

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge http://github.com/openjdk/jdk into JDK-8266054
 - Merge branch 'JDK-8266054' of http://github.com/jatin-bhateja/jdk into JDK-8266054
 - 8266054: Removing redundant teat templates.
 - 8266054: Code reorganization for efficient sharing of logic to check rotate operation support on a target platform.
 - 8266054: Removing redundant test templates.
 - 8266054: Review comments resolution.
 - 8266054: Review comments resolution.
 - 8266054: Review comments resolution.
 - Merge http://github.com/openjdk/jdk into JDK-8266054
 - 8266054: Changing gen-src.sh file permissions
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/4d26f22b...0439e93e

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3720/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3720&range=06
  Stats: 4392 lines in 52 files changed: 4171 ins; 60 del; 161 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3720.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3720/head:pull/3720

PR: https://git.openjdk.java.net/jdk/pull/3720

From lzang at openjdk.java.net  Mon May 24 05:55:08 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 24 May 2021 05:55:08 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP
 fields [v3]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 24 Mar 2021 10:25:44 GMT, Lance Andersen  wrote:

>> Lin Zang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update copyright
>>  - reuse arguments constructor for non-argument one.
>
> Hi Lin,
> 
> On Mar 24, 2021, at 2:51 AM, Lin Zang ***@***.******@***.***>> wrote:
> 
> 
> 
> Hi Lance?
> Thanks a lot for your review. I will update the PR ASAP.
> May I ask your help to also review the CSR?
> 
> I believe we need to flush out some of the issues I raised that were not test related as they will result in updates to the javadoc which will require an update to the CSR.
> 
> 
> 
> Thanks!
> 
> BRs,
> Lin
> 
> ?
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub, or unsubscribe.
> 
> ***@***.***
> 
> 
> 
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> ***@***.******@***.***>

Dear Lance(@LanceAndersen),

I have updated the CSR at https://bugs.openjdk.java.net/browse/JDK-8263793, which considered changes both for GZIPOutputStream and GZIPInputStream. Would you like to help check whether it looks reasonable?

I also did some investigation recently, and it shows there are rare cases that the optional fields are used in gzip file, and gunzip ingores them when uncompressing. 

So I believe the meaning of the PR is just to add the ability of setting/getting gzip file header info that defined in gzip specification.  As the use case is rare at present, I am not sure whether it is acceptable to have this PR.  

Thanks,
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/3072

From lzang at openjdk.java.net  Mon May 24 06:03:32 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 24 May 2021 06:03:32 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP
 fields [v7]
In-Reply-To: 
References: 
Message-ID: 

> 4890732: GZIPOutputStream doesn't support optional GZIP fields

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  Add api in GZIPInputStream to get header data

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3072/files
  - new: https://git.openjdk.java.net/jdk/pull/3072/files/24c1b45f..d7daf18f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=05-06

  Stats: 56 lines in 1 file changed: 49 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3072.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3072/head:pull/3072

PR: https://git.openjdk.java.net/jdk/pull/3072

From joehw at openjdk.java.net  Mon May 24 06:23:59 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 24 May 2021 06:23:59 GMT
Subject: RFR: 8265248: Implementation Specific Properties: change prefix,
 plus add existing properties [v7]
In-Reply-To: 
References: 
Message-ID: <5CFkK-ZiUWcGA7prREKAF-XaRCIudLdkoqjxrRnF-Vg=.786174c1-eece-4a91-a312-c57043847a24@github.com>

> Update module summary, add a few existing properties and features into the tables.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  Consolidated impl specific properties; deprecated legacy properties; made new ones take preference

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3644/files
  - new: https://git.openjdk.java.net/jdk/pull/3644/files/d4356925..ab349bb1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3644&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3644&range=05-06

  Stats: 2370 lines in 60 files changed: 1034 ins; 784 del; 552 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3644.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3644/head:pull/3644

PR: https://git.openjdk.java.net/jdk/pull/3644

From dholmes at openjdk.java.net  Mon May 24 06:29:04 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 24 May 2021 06:29:04 GMT
Subject: RFR: 8266310: deadlock while loading the JNI code [v5]
In-Reply-To: 
References: 
 
Message-ID: 

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 library load operation.
>> 
>> Problem being fixed:
>> 
>> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread.
>> 
>> Proposed fix:
>> 
>> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method.
>> 
>> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared.
>> 
>> Testing:  jtreg and jck testing with no regressions. A new regression test was developed.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix whitespace

Sorry Aleksei but your counted lock has me a bit mystified. Can you elaborate on the locking strategy please.

Thanks,
David

src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 511:

> 509:             if (currentLock.getCounter() == 1) {
> 510:                 // unlock and release the object if no other threads are queued
> 511:                 currentLock.unlock();

This isn't atomic so I don't see how it can work as desired. Overall I don't understand what the semantics of this "counted lock" are intended to be.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3976

From github.com+10835776+stsypanov at openjdk.java.net  Mon May 24 07:04:05 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 24 May 2021 07:04:05 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: 
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 
Message-ID: 

On Fri, 21 May 2021 14:15:53 GMT, Daniel Fuchs  wrote:

>> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
>> 
>> jdk:tier1 and jdk:tier2 are both ok
>
> src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 155:
> 
>> 153:      */
>> 154:     public List get(String fileName) {
>> 155:         ArrayList jarFiles;
> 
> This could probably be declared as:
> 
> 
> List jarFiles;

Done

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From github.com+10835776+stsypanov at openjdk.java.net  Mon May 24 07:10:40 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 24 May 2021 07:10:40 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: 
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 
Message-ID: 

On Fri, 21 May 2021 14:18:16 GMT, Daniel Fuchs  wrote:

>> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
>> 
>> jdk:tier1 and jdk:tier2 are both ok
>
> src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 264:
> 
>> 262:                 String jar = jarFiles[i];
>> 263:                 bw.write(jar + "\n");
>> 264:                 ArrayList jarlist = jarMap.get(jar);
> 
> Here again, jarList could probably be declared as `List`

Done

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From tvaleev at openjdk.java.net  Mon May 24 07:15:34 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Mon, 24 May 2021 07:15:34 GMT
Subject: RFR: 8267452: Delegate forEachRemaining in
 Spliterators.iterator() [v2]
In-Reply-To: 
References: 
Message-ID: 

> Sometimes, `Spliterator::forEachRemaining` has much more optimized implementation, compared to `Spliterator::tryAdvance`. For example, if a `Stream::spliterator` called for a stream that has intermediate operations, `tryAdvance()` may buffer intermediate elements while `forEachRemaining()` just delegates to the `wrapAndCopyInto` (see `StreamSpliterators.AbstractWrappingSpliterator` and its inheritors).
> 
> `Spliterators::iterator` methods (used in particular by `Stream::iterator`) provide adapter iterators that delegate to the supplied spliterator. Unfortunately, they don't have a specialized implementation for `Iterator::forEachRemaining`. As a result, a default implementation is used that delegates to `hasNext`/`next`, which in turn causes the delegation to `tryAdvance`. It's quite simple to implement `Iterator::forEachRemaining` here, taking advantage of possible spliterator optimizations if the iterator client decides to use `forEachRemaining`.
> 
> This patch implements Iterator::forEachRemaining in Spliterators::iterator methods. Also, I nullize the `nextElement` in `Iterator::next` to avoid accidental prolongation of the user's object lifetime when iteration is finished. Finally, a small cleanup: I added the `final` modifier where possible to private fields in `Spliterators`.
> 
> Test-wise, some scenarios are already covered by SpliteratorTraversingAndSplittingTest. However, the resulting iterator is always wrapped into `Spliterators::spliterator`, so usage scenarios are somewhat limited. In particular, calling `hasNext` (without `next`) before `forEachRemaining` was not covered there. I added more tests in `IteratorFromSpliteratorTest` to cover these scenarios. I checked that removing `valueReady = false;` or `action.accept(t);` lines from newly implemented `forEachRemaining` method causes new tests to fail (but old tests don't fail due to this).

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Test: formatting; tests for empty spliterator

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4124/files
  - new: https://git.openjdk.java.net/jdk/pull/4124/files/5b05135f..9a5e0dd2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4124&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4124&range=00-01

  Stats: 109 lines in 1 file changed: 30 ins; 14 del; 65 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4124.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4124/head:pull/4124

PR: https://git.openjdk.java.net/jdk/pull/4124

From github.com+10835776+stsypanov at openjdk.java.net  Mon May 24 07:17:08 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 24 May 2021 07:17:08 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: 
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 
 
 
Message-ID: 

On Fri, 21 May 2021 15:12:20 GMT, Thiago Henrique H?pner  wrote:

>>> IcedTea-Web seems to be using this method reflectively:
>>> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80
>> 
>> I assume this doesn't work with JDK 16, at least not without using --add-exports to export jdk.internal.util.jar.
>
> Just for completeness, they're using the add-exports:
> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/launchers/itw-modularjdk.args#L19

Should we then revert the changes to `JarIndex`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From chegar at openjdk.java.net  Mon May 24 08:15:12 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 24 May 2021 08:15:12 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
Message-ID: 

On Thu, 20 May 2021 16:10:11 GMT, Roger Riggs  wrote:

>> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
>> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
>> configuration mechanisms and filter utilities.
>> 
>> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`:
>>     http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify factory interface to BinaryOperator and cleanup the example

src/java.base/share/classes/java/io/ObjectInputFilter.java line 280:

> 278:      *      filter status
> 279:      */
> 280:     default ObjectInputFilter rejectUndecidedClass() {

It is my understanding that an implSpec will be required for this and the other default method.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From chegar at openjdk.java.net  Mon May 24 08:15:12 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 24 May 2021 08:15:12 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: 
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
 
 
Message-ID: 

On Fri, 21 May 2021 17:25:07 GMT, Roger Riggs  wrote:

> The static is intended to distinguish that single filter from the others. The static vs current distinction is part of JEP 290 from which this evolved. 

I can kinda grok that now, I see "current filter" in JEP 290. I think that the new terms "JVM-wide filter" and "stream-specific filter", are more accurate and straightforward to follow.

> The migration to "de-serialization" from the previous "serialization" is as yet incomplete.

Ok. I assume that will be completed as part of this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From chegar at openjdk.java.net  Mon May 24 08:27:07 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 24 May 2021 08:27:07 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: 
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
 
 
Message-ID: 

On Fri, 21 May 2021 17:21:15 GMT, Roger Riggs  wrote:

>> src/java.base/share/classes/java/io/ObjectInputFilter.java line 107:
>> 
>>> 105:  *     Note that the filter may be used directly or combined with other filters by the
>>> 106:  *     {@linkplain Config#setSerialFilterFactory(BinaryOperator) JVM-wide filter factory}.
>>> 107:  * 
>> 
>> This list is a little confusing to me, but could be that I don't fully grok it yet. getSerialFilterFactory returns THE JVM-wide factory, whether that be the built-in factory implementation or not is somewhat irrelevant. No need to treat them differently - one either sets a factory (in which case that is the JVM-wide factory), or one does not set the factory (in which case the built-in factory is the JVM-wide factory).
>
> In previous versions, calling OIS.setObjectInputFilter determined exactly the filter used for the stream.
> With the filter factory enhancement, the current filter factory determines how the argument to OIS.setObjectInputFilter is used. There are plenty of cases where the filter factory will combine it with other filters and the composite will becomes the filter for the stream.

Here is the source of my confusion. The bulleted list is enumerating how a stream-specific filter is determined, but I see an extra step in that which should be unnecessary. It is currently:

1. Check JVM-wide filter factory
2. If no JVM-wide, check built-in factory
3. setSerialFilterFactory

, but 1 and 2 are not separate and distinct cases - there is always a JVM-wide deserialization filter factory. The JVM-wide deserialization filter factory is either i) set through a property, or ii) set explicitly by an API call, or iii) the built-in implementation.

If the initialisation of the JVM-wide deserialization filter factory is separated out from how the stream-specific factory is determined, then I believe that it will be easier to follow.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From chegar at openjdk.java.net  Mon May 24 08:34:59 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 24 May 2021 08:34:59 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: 
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
 
 
Message-ID: 

On Fri, 21 May 2021 17:09:00 GMT, Roger Riggs  wrote:

>> src/java.base/share/classes/java/io/ObjectInputFilter.java line 365:
>> 
>>> 363:      * A utility class to set and get the JVM-wide deserialization filter factory,
>>> 364:      * the static JVM-wide filter, or to create a filter from a pattern string.
>>> 365:      * If a JVM-wide filter factory or static JVM-wide filter is set, it will determine the filter
>> 
>> This concerns me, "A JVM-wide filter factory". I was going to suggest that it should be "The ..", but then realised that there can only ever be one present at a time, but in the lifetime of a JVM there can be two (since getSerialFilterFactory if invoked before setSerialFilterFactory will subsequently return a different JVM-wide factory).   Is this intentional? It would great if this could be "The ..", so that setXXX can only be invoked successfully if getXXX has not been.   This may seen somewhat insignificant, but the fact that the JVM-wide factory can change make the model harder understand.
>
> It is reasonable to require that the factory be set before any OIS is constructed.
> Similar to the restriction that the filter on a stream cannot be changed after the first call to readObject.
> So an IllegalStateException added to Config.setSerialFilterFactory.

Ok, great. So setSerialFilterFactory cannot be successfully invoked after any of i) getSerialFilterFactory, or ii) an OIS is constructed. I don't yet see this in the code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From amaembo at gmail.com  Mon May 24 08:46:19 2021
From: amaembo at gmail.com (Tagir Valeev)
Date: Mon, 24 May 2021 15:46:19 +0700
Subject: Obviously erroneous code in
 JapaneseImperialCalendar::actualMonthLength
Message-ID: 

Hello!

When testing our static analyzer, I've found obviously erroneous code
in java.util.JapaneseImperialCalendar::actualMonthLength

int eraIndex = getTransitionEraIndex(jdate);
if (eraIndex == -1) {
    long transitionFixedDate = sinceFixedDates[eraIndex];
    CalendarDate d = eras[eraIndex].getSinceDate();
    if (transitionFixedDate <= cachedFixedDate) {
       length -= d.getDayOfMonth() - 1;
    } else {
       length = d.getDayOfMonth() - 1;
    }
}

if this 'if' statement is visited then sinceFixedDates[eraIndex] will
surely fail with ArrayIndexOutOfBoundsException. However, judging from
the usages of this method, eraIndex is never -1 here, so the whole
'if' statement is a dead code. I'm not sure whether it should be
removed, or the condition should be changed to 'eraIndex != -1' (and
probably some unit-tests should be written to cover this). I have no
expertise in this code so I'm not sure what would be a proper way to
fix it. Please take a look.

With best regards,
Tagir Valeev.

From dfuchs at openjdk.java.net  Mon May 24 09:03:10 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 24 May 2021 09:03:10 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang  wrote:

>> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
>> 
>> The code change shows some common solutions to avoid such too wide annotations:
>> 
>> 1. Extract calls into a method and add annotation on that method
>> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value.
>> 3. Put declaration and assignment into a single statement if possible.
>> 4. Rewrite code to achieve #3 above.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update FtpClient.java

Thanks for taking in my suggestions for FtpClient. I have also reviewed the changes to java.util.logging and JMX. I wish there was a way to handle doPrivileged returning void more nicely. Maybe component maintainers will be able to deal with them on a case-by-case basis later on.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4138

From github.com+5917763+remkop at openjdk.java.net  Mon May 24 09:05:16 2021
From: github.com+5917763+remkop at openjdk.java.net (Remko Popma)
Date: Mon, 24 May 2021 09:05:16 GMT
Subject: RFR: 8224243: Make AccessibleObject a sealed class [v2]
In-Reply-To: <1p8BXJHpzVJ_nPh9j0sRoOJwdiYNkO_6DK9sg5T92_A=.9a001d1a-f0d9-428e-8c45-fb5f04cf79b4@github.com>
References: <4DFE3N_LB1D0jraDzmAmhGpzPGZAZrluVqCM5LFo5B4=.bbe76387-44f8-44de-ae2a-ce89d823041b@github.com>
 <1p8BXJHpzVJ_nPh9j0sRoOJwdiYNkO_6DK9sg5T92_A=.9a001d1a-f0d9-428e-8c45-fb5f04cf79b4@github.com>
Message-ID: 

On Fri, 21 May 2021 02:42:50 GMT, Joe Darcy  wrote:

>> Conceptually, AccessbileObject is a sealed class with a protected constructor stating
>> 
>>     Constructor: only used by the Java Virtual Machine.
>> 
>> With the language now supporting sealed classes, the AccessbileObject should be marked as sealed.
>> 
>> Executable and Field are the subclasses of AccessbileObject in the JDK; as Executable has subclasses, it is marked as non-sealed.
>> 
>> Please also review the corresponding CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8224243
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update in response to review feedback.

Hi all, I am the author of picocli. 

I will look into moving away from extending `AccessibleObject` in picocli, but ?amonn McManus's comment about Guava equally applies to picocli: even with such a change, older versions of the library would fail on JDK 17.

So, thank you for reconsidering sealing `AccessibleObject` and choosing to seal `Executable` instead. That is a relief. :-)
 
(And many thanks to @kaspernielsen for making me aware of this issue!)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4133

From github.com+75078+kaspernielsen at openjdk.java.net  Mon May 24 09:05:19 2021
From: github.com+75078+kaspernielsen at openjdk.java.net (Kasper Nielsen)
Date: Mon, 24 May 2021 09:05:19 GMT
Subject: RFR: 8224243: Make AccessibleObject a sealed class [v2]
In-Reply-To: <1p8BXJHpzVJ_nPh9j0sRoOJwdiYNkO_6DK9sg5T92_A=.9a001d1a-f0d9-428e-8c45-fb5f04cf79b4@github.com>
References: <4DFE3N_LB1D0jraDzmAmhGpzPGZAZrluVqCM5LFo5B4=.bbe76387-44f8-44de-ae2a-ce89d823041b@github.com>
 <1p8BXJHpzVJ_nPh9j0sRoOJwdiYNkO_6DK9sg5T92_A=.9a001d1a-f0d9-428e-8c45-fb5f04cf79b4@github.com>
Message-ID: 

On Fri, 21 May 2021 02:42:50 GMT, Joe Darcy  wrote:

>> Conceptually, AccessbileObject is a sealed class with a protected constructor stating
>> 
>>     Constructor: only used by the Java Virtual Machine.
>> 
>> With the language now supporting sealed classes, the AccessbileObject should be marked as sealed.
>> 
>> Executable and Field are the subclasses of AccessbileObject in the JDK; as Executable has subclasses, it is marked as non-sealed.
>> 
>> Please also review the corresponding CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8224243
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update in response to review feedback.

Missed the part about only Executable being made sealed. But if Executable is sealed, setAccessible(boolean) could still be moved from Method/Constructor down to Executable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4133

From github.com+7806504+liach at openjdk.java.net  Mon May 24 09:28:15 2021
From: github.com+7806504+liach at openjdk.java.net (liach)
Date: Mon, 24 May 2021 09:28:15 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: 
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 
 
 
 
Message-ID: 

On Mon, 24 May 2021 07:13:29 GMT, ?????? ???????  wrote:

>> Just for completeness, they're using the add-exports:
>> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/launchers/itw-modularjdk.args#L19
>
> Should we then revert the changes to `JarIndex`?

But don't people access these internal code at their own risk, as jdk may change these code at any time without notice?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From github.com+10835776+stsypanov at openjdk.java.net  Mon May 24 10:17:19 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 24 May 2021 10:17:19 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: 
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 
 
 
 
 
Message-ID: 

On Mon, 24 May 2021 09:25:08 GMT, liach  wrote:

>> Should we then revert the changes to `JarIndex`?
>
> But don't people access these internal code at their own risk, as jdk may change these code at any time without notice?

True, I just wonder whether it's OK to change internals when we know for sure that this breaks 3rd party code

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From chegar at openjdk.java.net  Mon May 24 10:26:14 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 24 May 2021 10:26:14 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 22 May 2021 20:16:37 GMT, Roger Riggs  wrote:

>> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
>> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
>> configuration mechanisms and filter utilities.
>> 
>> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`:
>>     http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Editorial javadoc updated based on review comments.
>   Clarified behavior of rejectUndecidedClass method.
>   Example test added to check status returned from file.

src/java.base/share/classes/java/io/ObjectInputFilter.java line 770:

> 768:         /**
> 769:          * Returns a filter that returns {@code Status.ALLOWED} if the predicate on the class is {@code true},
> 770:          * otherwise the {@code otherStatus}.

I originally overlooked the fact that UNDECIDED can be returned by these filters. Would it be clearer to drop "otherwise the otherStatus" ?? I also wonder if otherStatus carries its own weight? How useful is it to return an otherStatus that is not UNDECIDED?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From chegar at openjdk.java.net  Mon May 24 10:31:08 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 24 May 2021 10:31:08 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v5]
In-Reply-To: 
References: 
 
Message-ID: <2OAi8LIem4ojrxnIpcocui_B1RQXPq-IX7b4qaiOub4=.38525afa-a356-46b4-b18e-5e14d7da3141@github.com>

On Sat, 22 May 2021 20:16:37 GMT, Roger Riggs  wrote:

>> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
>> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
>> configuration mechanisms and filter utilities.
>> 
>> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`:
>>     http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Editorial javadoc updated based on review comments.
>   Clarified behavior of rejectUndecidedClass method.
>   Example test added to check status returned from file.

src/java.base/share/classes/java/io/ObjectInputFilter.java line 790:

> 788:          * @return {@link Status#ALLOWED} if the predicate on the class returns {@code true},
> 789:          *          otherwise {@link Status#UNDECIDED}
> 790:          */

The return is "a filter that ..."

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From lzang at openjdk.java.net  Mon May 24 10:42:51 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 24 May 2021 10:42:51 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP
 fields [v8]
In-Reply-To: 
References: 
Message-ID: 

> 4890732: GZIPOutputStream doesn't support optional GZIP fields

Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'master' into gzip-field
 - Add api in GZIPInputStream to get header data
 - Merge remote-tracking branch 'upstream/master' into gzip-field
 - remove trailing spaces
 - Use record and Builder pattern
 - add class GZIPHeaderData, refine testcases
 - update copyright
 - reuse arguments constructor for non-argument one.
 - add test case
 - remove trailing spaces
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/31139108...daa495d4

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3072/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=07
  Stats: 635 lines in 4 files changed: 585 ins; 26 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3072.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3072/head:pull/3072

PR: https://git.openjdk.java.net/jdk/pull/3072

From chegar at openjdk.java.net  Mon May 24 11:01:09 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 24 May 2021 11:01:09 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v5]
In-Reply-To: 
References: 
 
Message-ID: <1_4iUmU8gU0wi36E1Jq0j4vUmkl2nXj6u3whQ26bMzY=.3c293611-0804-4d34-a065-b8fdb073d8ad@github.com>

On Sat, 22 May 2021 20:16:37 GMT, Roger Riggs  wrote:

>> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
>> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
>> configuration mechanisms and filter utilities.
>> 
>> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`:
>>     http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Editorial javadoc updated based on review comments.
>   Clarified behavior of rejectUndecidedClass method.
>   Example test added to check status returned from file.

src/java.base/share/classes/java/io/ObjectInputFilter.java line 829:

> 827:          * Returns a filter that returns {@code Status.ALLOWED} if the check is for limits
> 828:          * and not checking a class; otherwise {@code Status.UNDECIDED}.
> 829:          * If the {@link FilterInfo#serialClass()} is {@code null}, the filter returns

"Returns a filter that returns {@code Status.ALLOWED} ... ". Maybe "Returns a filter that allows all limits ..".

Up-levelling a bit, it seems that filter operations fall into two broad categories: 1) class-checking, and 2)limits-checking. At least, in the way that some of these factories and adapters are laid out.  If we had such a notional at the class-level, then maybe that could influence the naming of these factories - and tie them to a higher-level concept.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From github.com+2217224+kariya-mitsuru at openjdk.java.net  Mon May 24 11:17:54 2021
From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru Kariya)
Date: Mon, 24 May 2021 11:17:54 GMT
Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is
 bigger than number of elements we want to insert. [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 18 May 2021 18:44:32 GMT, Lance Andersen  wrote:

>> Mitsuru Kariya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix for length + offset > Integer.MAX_VALUE case
>
> src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialBlob.java line 306:
> 
>> 304:      *
>> 305:      * @param pos the position in the SQL BLOB value at which
>> 306:      *     to start writing. The first position is 1;
> 
> When updating the javadoc to use @code, please update all instances for consistency

Sure.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4001

From github.com+2217224+kariya-mitsuru at openjdk.java.net  Mon May 24 11:18:57 2021
From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru Kariya)
Date: Mon, 24 May 2021 11:18:57 GMT
Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is
 bigger than number of elements we want to insert. [v4]
In-Reply-To: 
References: 
Message-ID: 

> Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases:
> 
> 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()`
>    The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully.
>    (test31)
> 
> 2. `pos - 1 + length > this.length()`
>    The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1
>    (test32)
> 
> 3. `pos == this.length() + 1`
>    The original implementation throws `SerialException` but this case should end successfully. *2
>    (test33)
> 
> 4. `length < 0`
>    The original implementation throws `ArrayIndexOutOfBoundsException` but this case should throw `SerialException`.
>    (test34)
> 
> 5. `offset + length > Integer.MAX_VALUE`
>    The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`.
>    (test35)
> 
> Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases:
> 
> 1. `offset > str.length()`
>    The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`.
>    (test39)
> 
> 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()`
>    The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully.
>    (test32)
> 
> 3. `pos - 1 + length > this.length()`
>    The original implementaion throws `SerialException` but this case should end successfully. *3
>    (test40)
> 
> 4. `pos == this.length() + 1`
>    The original implementaion throws `SerialException` but this case should end successfully. *4
>    (test41)
> 
> 5. `length < 0`
>    The original implementation throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`.
>    (test42)
> 
> 6. `offset + length > Integer.MAX_VALUE`
>    The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`.
>    (test43)
> 
> 
> The javadoc has also been modified according to the above.
> 
> *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes."
> 
> *2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined."
>    So, it should work correctly when pos == length+1 of the BLOB value.
> 
> *3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters."
> 
> *4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined."
>    So, it should work correctly when pos == length+1 of the CLOB value.

Mitsuru Kariya has updated the pull request incrementally with one additional commit since the last revision:

  Modify javadoc for consistency

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4001/files
  - new: https://git.openjdk.java.net/jdk/pull/4001/files/e4346738..69fb2f4a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4001&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4001&range=02-03

  Stats: 38 lines in 2 files changed: 0 ins; 0 del; 38 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4001.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4001/head:pull/4001

PR: https://git.openjdk.java.net/jdk/pull/4001

From github.com+2217224+kariya-mitsuru at openjdk.java.net  Mon May 24 11:26:05 2021
From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru Kariya)
Date: Mon, 24 May 2021 11:26:05 GMT
Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is
 bigger than number of elements we want to insert. [v3]
In-Reply-To: <67cyn8TRFVcijg4ewkd45WQgjoAzKWwsj44chc36zME=.27b68fe2-7f42-4e1f-890c-1589611b9d2d@github.com>
References: 
 
 <67cyn8TRFVcijg4ewkd45WQgjoAzKWwsj44chc36zME=.27b68fe2-7f42-4e1f-890c-1589611b9d2d@github.com>
Message-ID: 

On Tue, 18 May 2021 19:06:56 GMT, Lance Andersen  wrote:

> I have run the JCK tests in addition to to the JTREG Tess to validate there are no additional failures due to these changes

Thanks a lot!

> src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialBlob.java line 308:
> 
>> 306:      *     to start writing. The first position is 1;
>> 307:      *     must not be less than 1 nor greater than
>> 308:      *     the length+1 of this {@code SerialBlob} object.
> 
> Changes such as this require a CSR.  I think I have convinced myself that it is OK to move forward with the CSR.

Would you please create a CSR for me?
Or should I register a CSR at https://bugreport.java.com/bugreport/ ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4001

From redestad at openjdk.java.net  Mon May 24 11:36:12 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 24 May 2021 11:36:12 GMT
Subject: RFR: 8267612: Declare package-private VarHandle.AccessMode/-Type
 counts
Message-ID: 

Slightly reduce VarHandle startup overhead by introducing package-private COUNT constants for two enums

-------------

Commit messages:
 - Declare package-private VarHandle.AccessMode/-Type counts

Changes: https://git.openjdk.java.net/jdk/pull/4164/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4164&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267612
  Stats: 18 lines in 4 files changed: 8 ins; 2 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4164.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4164/head:pull/4164

PR: https://git.openjdk.java.net/jdk/pull/4164

From redestad at openjdk.java.net  Mon May 24 11:59:09 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 24 May 2021 11:59:09 GMT
Subject: RFR: 8267614: Outline VarHandleGuards exact behavior checks
Message-ID: <_EuiNxRML-XncdKWL8mX7ycYfD8hQYOUttyXBAr-rCY=.d15edec0-cd5a-4031-95c4-48d451c4b674@github.com>

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 microbenchmarks.

-------------

Commit messages:
 - Outline VarHandleGuard exact behavior checks

Changes: https://git.openjdk.java.net/jdk/pull/4165/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4165&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267614
  Stats: 338 lines in 3 files changed: 14 ins; 243 del; 81 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4165.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4165/head:pull/4165

PR: https://git.openjdk.java.net/jdk/pull/4165

From github.com+7806504+liach at openjdk.java.net  Mon May 24 12:11:38 2021
From: github.com+7806504+liach at openjdk.java.net (liach)
Date: Mon, 24 May 2021 12:11:38 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: 
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 
 
 
 
 
 
Message-ID: 

On Mon, 24 May 2021 10:13:55 GMT, ?????? ???????  wrote:

>> But don't people access these internal code at their own risk, as jdk may change these code at any time without notice?
>
> True, I just wonder whether it's OK to change internals when we know for sure that this breaks 3rd party code

I think so. There are always unexpected ways the jdk may break and third-party libraries would need a different workaround for a new java version. For instance, in Apache log4j, its library has a special guard against the broken implementation of Reflection getCallerClass during java 7. The libraries can just handle these in their version-specific components.

Especially given the fact that the code linked above already has version-specific handling (8 vs 9), so it won't hurt much for them to add another piece of logic to handle jdk 17+ in case this optimization is merged.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From dfuchs at openjdk.java.net  Mon May 24 13:04:00 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 24 May 2021 13:04:00 GMT
Subject: RFR: 8267544: (test) rmi test NonLocalSkeleton fails if network
 has multiple adapters with the same address
In-Reply-To: 
References: 
Message-ID: 

On Sat, 22 May 2021 02:42:08 GMT, Roger Riggs  wrote:

> Correct test code that creates a set of unique hostnames from an array of non-unique hostname.
> Was using Set.of that throws if the elements are not unique.

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4151

From herrick at openjdk.java.net  Mon May 24 13:14:27 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 24 May 2021 13:14:27 GMT
Subject: RFR: JDK-8267423: Fix copyrights in jpackage tests
Message-ID: <_j5L4bWX1ODNrw_RgdBaDVIgP-el9_j_0xfiQTVDgmY=.c5d6f9e7-0801-49ae-a91c-117c65565fd6@github.com>

JDK-8267423: Fix copyrights in jpackage tests

-------------

Commit messages:
 - JDK-8267423: Fix copyrights in jpackage tests
 - JDK-8267423: Fix copyrights in jpackage tests
 - JDK-8267423: Fix copyrights in jpackage tests
 - JDK-8267423: Fix copyrights in jpackage tests

Changes: https://git.openjdk.java.net/jdk/pull/4144/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4144&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267423
  Stats: 96 lines in 10 files changed: 69 ins; 14 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4144.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4144/head:pull/4144

PR: https://git.openjdk.java.net/jdk/pull/4144

From dfuchs at openjdk.java.net  Mon May 24 13:28:11 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 24 May 2021 13:28:11 GMT
Subject: RFR: 8191441: (Process) add Readers and Writer access to
 java.lang.Process streams [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 24 May 2021 00:33:06 GMT, Roger Riggs  wrote:

>> Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process.
>> The Charset used to encode and decode characters to bytes can be specified or use the
>> operating system native encoding as is available from the "native.encoding" system property.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added throws for NPE, delegated zero-arg methods that use native.encoding to
>   the 1-arg method with a charset, added tests for Redirect cases where the streams are null-input or null-output streams.

src/java.base/share/classes/java/lang/Process.java line 178:

> 176:      *
> 177:      * 
    This method delegates to {@link #inputReader(Charset)} using the
> 178:      * {@link Charset} named by the {@systemProperty native.encoding}

I thought that `{@systemProperty ... }` was supposed to be used at the place where the system property is defined, and *not* at the place where it's being used? I might be mistaken, but if I'm not - then there would be several places to fix in this file.

src/java.base/share/classes/java/lang/Process.java line 226:

> 224:      *
> 225:      * @param charset the {@code Charset} used to decode bytes to characters, not null
> 226:      * @return a BufferedReader for the standard output of the process using the {@code charset}

`{@code BufferedReader}`

src/java.base/share/classes/java/lang/Process.java line 231:

> 229:      */
> 230:     public BufferedReader inputReader(Charset charset) {
> 231:         return new BufferedReader(new InputStreamReader(getInputStream(), charset));

I'd suggest calling Objects.requireNonNull(charset) first thing in this method instead of relying on the InputStreamReader constructor to throw the NPE.

src/java.base/share/classes/java/lang/Process.java line 283:

> 281:      *
> 282:      * @param charset the {@code Charset} used to decode bytes to characters, not null
> 283:      * @return a BufferedReader for the standard error of the process using the {@code charset}

`{@code BufferedReader}`

src/java.base/share/classes/java/lang/Process.java line 288:

> 286:      */
> 287:     public BufferedReader errorReader(Charset charset) {
> 288:         return new BufferedReader(new InputStreamReader(getErrorStream(), charset));

Same remark here: I'd suggest calling Objects.requireNonNull(charset) first thing in this method instead of relying on the InputStreamReader constructor to throw the NPE.

src/java.base/share/classes/java/lang/Process.java line 317:

> 315:      * {@linkplain BufferedWriter#flush flush} is called.
> 316:      *
> 317:      * @return a BufferedWriter to the standard input of the process using the charset

`{@code BufferedWriter}`

src/java.base/share/classes/java/lang/Process.java line 351:

> 349:      *
> 350:      * @param charset the {@code Charset} to encode characters to bytes, not null
> 351:      * @return a BufferedWriter to the standard input of the process using the {@code charset}

`{@code BufferedWriter}`

src/java.base/share/classes/java/lang/Process.java line 356:

> 354:      */
> 355:     public BufferedWriter outputWriter(Charset charset) {
> 356:         return new BufferedWriter(new OutputStreamWriter(getOutputStream(), charset));

I'd suggest calling Objects.requireNonNull(charset) first thing in this method instead of relying on the InputStreamWriter constructor to throw the NPE.

src/java.base/share/classes/java/lang/Process.java line 459:

> 457:      * 
    
> 458:      * Invoking this method on {@code Process} objects returned by
> 459:      * {@link ProcessBuilder#start()} and {@link Runtime#exec} forcibly terminate

Should the link to `Runtime#exec` be fixed in the same manner, here and elsewhere in this file?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4134

From pconcannon at openjdk.java.net  Mon May 24 13:44:41 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 24 May 2021 13:44:41 GMT
Subject: RFR: 8267110: Update java.util to use instanceof pattern variable
 [v5]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Patrick Concannon 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 six additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8267110
 - 8267110: Reverted changes made to files in java.util.concurrent
 - Merge remote-tracking branch 'origin/master' into JDK-8267110
 - 8267110: Reverted changes in java/util/Formatter as primitive to boxed types may have semantic/performance implications
 - Merge remote-tracking branch 'origin/master' into JDK-8267110
 - 8267110: Update java.util to use instanceof pattern variable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4088/files
  - new: https://git.openjdk.java.net/jdk/pull/4088/files/2c076a55..9bca9400

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=03-04

  Stats: 1931 lines in 65 files changed: 1061 ins; 429 del; 441 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4088.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4088/head:pull/4088

PR: https://git.openjdk.java.net/jdk/pull/4088

From dfuchs at openjdk.java.net  Mon May 24 13:50:12 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 24 May 2021 13:50:12 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch
In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
Message-ID: 

On Mon, 24 May 2021 04:20:23 GMT, Tagir F. Valeev  wrote:

> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
> 
> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?

src/java.base/share/classes/java/util/regex/CharPredicates.java line 217:

> 215:             case "WORD" -> WORD();
> 216:             default -> null;
> 217:         };

This file has lots of changes which are difficult to review. Maybe it should be split out of this PR.

src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 261:

> 259:             ZipEntry e = current.entry;
> 260:             switch (e.method) {
> 261:                 case DEFLATED -> {

Same remark here - it's not clear what's going on.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161

From weijun at openjdk.java.net  Mon May 24 13:53:34 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 13:53:34 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v4]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

> 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  keep only one systemProperty tag

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/c4221b5f..1f6ff6c4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=02-03

  Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Mon May 24 13:53:37 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 13:53:37 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v4]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
Message-ID: 

On Sun, 23 May 2021 16:35:43 GMT, Sean Mullan  wrote:

>> src/java.base/share/classes/java/lang/SecurityManager.java line 104:
>> 
>>> 102:  * method will throw an {@code UnsupportedOperationException}). If the
>>> 103:  * {@systemProperty java.security.manager} system property is set to the
>>> 104:  * special token "{@code allow}", then a security manager will not be set at
>> 
>> Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.
>
> Good point. I would remove the extra @systemProperty tags on lines 103, 106, and 113. Also, in `System.setSecurityManager` there are 3 @systemProperty java.security.manager tags, so we should remove those too.

New commit pushed. There is only one `@systemProperty` tag now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Mon May 24 14:05:08 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 14:05:08 GMT
Subject: RFR: 8267184: Add -Djava.security.manager=allow to tests calling
 System.setSecurityManager [v4]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

> 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.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Weijun Wang 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 20 additional commits since the last revision:

 - Merge branch 'master' into 8267184
 - feedback from Phil
   
   reverted:
 - adjust order of VM options
 - test for awt
 - test for hotspot-gc
 - test for compiler
 - test for net
 - test for core-libs
 - test for beans
 - test for xml
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/37f74de7...412264a0

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/9a3ec578..412264a0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=02-03

  Stats: 12227 lines in 453 files changed: 6978 ins; 3721 del; 1528 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071

From rriggs at openjdk.java.net  Mon May 24 14:13:14 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 24 May 2021 14:13:14 GMT
Subject: Integrated: 8267544: (test) rmi test NonLocalSkeleton fails if
 network has multiple adapters with the same address
In-Reply-To: 
References: 
Message-ID: 

On Sat, 22 May 2021 02:42:08 GMT, Roger Riggs  wrote:

> Correct test code that creates a set of unique hostnames from an array of non-unique hostname.
> Was using Set.of that throws if the elements are not unique.

This pull request has now been integrated.

Changeset: d8e6e287
Author:    Roger Riggs 
URL:       https://git.openjdk.java.net/jdk/commit/d8e6e2877aa8a89ad403f06b0adea19c7896d834
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8267544: (test) rmi test NonLocalSkeleton fails if network has multiple adapters with the same address

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.java.net/jdk/pull/4151

From kcr at openjdk.java.net  Mon May 24 14:39:03 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 24 May 2021 14:39:03 GMT
Subject: RFR: JDK-8267423: Fix copyrights in jpackage tests
In-Reply-To: <_j5L4bWX1ODNrw_RgdBaDVIgP-el9_j_0xfiQTVDgmY=.c5d6f9e7-0801-49ae-a91c-117c65565fd6@github.com>
References: <_j5L4bWX1ODNrw_RgdBaDVIgP-el9_j_0xfiQTVDgmY=.c5d6f9e7-0801-49ae-a91c-117c65565fd6@github.com>
Message-ID: 

On Fri, 21 May 2021 12:22:16 GMT, Andy Herrick  wrote:

> JDK-8267423: Fix copyrights in jpackage tests

Marked as reviewed by kcr (Author).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4144

From rriggs at openjdk.java.net  Mon May 24 15:12:06 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 24 May 2021 15:12:06 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: 
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
 
 
 
Message-ID: 

On Mon, 24 May 2021 08:31:29 GMT, Chris Hegarty  wrote:

>> It is reasonable to require that the factory be set before any OIS is constructed.
>> Similar to the restriction that the filter on a stream cannot be changed after the first call to readObject.
>> So an IllegalStateException added to Config.setSerialFilterFactory.
>
> Ok, great. So setSerialFilterFactory cannot be successfully invoked after any of i) getSerialFilterFactory, or ii) an OIS is constructed. I don't yet see this in the code.

The spec/code is forthcoming.  
ii) is sufficient to prevent ambiguity in which filter is used throughout the Java runtime; 
   though it requires a bit of package-private plumbing.

i) is too limiting.  It should be possible for an application to check whether a filter factory has been provided on the command line (by calling getSerialFilterFactory) and if not setting the factory itself.  It may also want to install its own filter factory that delegates to the builtin factory without needed to re-implement the builtin behavior.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From jlahoda at openjdk.java.net  Mon May 24 15:20:03 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 24 May 2021 15:20:03 GMT
Subject: RFR: 8224158: assertion related to NPE at
 DynamicCallSiteDesc::withArgs should be reworded
In-Reply-To: 
References: 
Message-ID: 

On Mon, 17 May 2021 16:53:24 GMT, Vicente Romero  wrote:

> This is a very small patch that is just rewording the spec for DynamicCallSiteDesc::withArgs. Basically adding that NPE can also be thrown if the content of the argument is `null`
> 
> TIA for the review

Looks good.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4067

From rriggs at openjdk.java.net  Mon May 24 15:27:25 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 24 May 2021 15:27:25 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: 
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
 
 
 
Message-ID: 

On Mon, 24 May 2021 08:22:57 GMT, Chris Hegarty  wrote:

>> In previous versions, calling OIS.setObjectInputFilter determined exactly the filter used for the stream.
>> With the filter factory enhancement, the current filter factory determines how the argument to OIS.setObjectInputFilter is used. There are plenty of cases where the filter factory will combine it with other filters and the composite will becomes the filter for the stream.
>
> Here is the source of my confusion. The bulleted list is enumerating how a stream-specific filter is determined, but I see an extra step in that which should be unnecessary. It is currently:
> 
> 1. Check JVM-wide filter factory
> 2. If no JVM-wide, check built-in factory
> 3. setSerialFilterFactory
> 
> , but 1 and 2 are not separate and distinct cases - there is always a JVM-wide deserialization filter factory. The JVM-wide deserialization filter factory is either i) set through a property, or ii) set explicitly by an API call, or iii) the built-in implementation.
> 
> If the initialisation of the JVM-wide deserialization filter factory is separated out from how the stream-specific factory is determined, then I believe that it will be easier to follow.

Yes, I will describe the filter factory selection and separately the filter composition by the factory.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From asemenyuk at openjdk.java.net  Mon May 24 15:40:08 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 24 May 2021 15:40:08 GMT
Subject: RFR: JDK-8267423: Fix copyrights in jpackage tests
In-Reply-To: <_j5L4bWX1ODNrw_RgdBaDVIgP-el9_j_0xfiQTVDgmY=.c5d6f9e7-0801-49ae-a91c-117c65565fd6@github.com>
References: <_j5L4bWX1ODNrw_RgdBaDVIgP-el9_j_0xfiQTVDgmY=.c5d6f9e7-0801-49ae-a91c-117c65565fd6@github.com>
Message-ID: <6Iw1cScA4JJ3Z3RBRSi04cunj-NPu6Qa5Fdml3pgAdc=.ebc9d84f-3367-4cf1-b906-8adf59a4e8e2@github.com>

On Fri, 21 May 2021 12:22:16 GMT, Andy Herrick  wrote:

> JDK-8267423: Fix copyrights in jpackage tests

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4144

From vromero at openjdk.java.net  Mon May 24 15:58:55 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 24 May 2021 15:58:55 GMT
Subject: Integrated: 8224158: assertion related to NPE at
 DynamicCallSiteDesc::withArgs should be reworded
In-Reply-To: 
References: 
Message-ID: 

On Mon, 17 May 2021 16:53:24 GMT, Vicente Romero  wrote:

> This is a very small patch that is just rewording the spec for DynamicCallSiteDesc::withArgs. Basically adding that NPE can also be thrown if the content of the argument is `null`
> 
> TIA for the review

This pull request has now been integrated.

Changeset: f04db5fb
Author:    Vicente Romero 
URL:       https://git.openjdk.java.net/jdk/commit/f04db5fbd77892e94a325942542815bbb24cddea
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8224158: assertion related to NPE at DynamicCallSiteDesc::withArgs should be reworded

Reviewed-by: jlahoda

-------------

PR: https://git.openjdk.java.net/jdk/pull/4067

From rriggs at openjdk.java.net  Mon May 24 15:59:00 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 24 May 2021 15:59:00 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 24 May 2021 10:23:01 GMT, Chris Hegarty  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Editorial javadoc updated based on review comments.
>>   Clarified behavior of rejectUndecidedClass method.
>>   Example test added to check status returned from file.
>
> src/java.base/share/classes/java/io/ObjectInputFilter.java line 770:
> 
>> 768:         /**
>> 769:          * Returns a filter that returns {@code Status.ALLOWED} if the predicate on the class is {@code true},
>> 770:          * otherwise the {@code otherStatus}.
> 
> I originally overlooked the fact that UNDECIDED can be returned by these filters. Would it be clearer to drop "otherwise the otherStatus" ?? I also wonder if otherStatus carries its own weight? How useful is it to return an otherStatus that is not UNDECIDED?

A filter author may prefer to return REJECTED if the predicate fails.
It gives the developer control on when UNDECIDED values can be part of a filter expression.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From mchung at openjdk.java.net  Mon May 24 16:34:09 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 24 May 2021 16:34:09 GMT
Subject: RFR: 8267612: Declare package-private VarHandle.AccessMode/-Type
 counts
In-Reply-To: 
References: 
Message-ID: 

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: 
> 1639:         static final int COUNT = 5;

Suggestion:

        static final int COUNT = GET_AND_UPDATE.ordinal() + 1;


This would avoid the hardcoded count which is a bit fragile.

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 1897:

> 1895:         ;
> 1896: 
> 1897:         static final int COUNT = 31;

Suggestion:

        static final int COUNT = GET_AND_BITWISE_XOR_ACQUIRE.ordinal() + 1;

-------------

PR: https://git.openjdk.java.net/jdk/pull/4164

From psandoz at openjdk.java.net  Mon May 24 16:38:04 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 24 May 2021 16:38:04 GMT
Subject: RFR: 8267452: Delegate forEachRemaining in
 Spliterators.iterator() [v2]
In-Reply-To: 
References: 
 
Message-ID: <1sJ0hj9Wk6TeY6fTYOi9v4d1d_51hM9pUl9b6dRKjzk=.640cf904-faad-42ed-b013-994d0d9265d5@github.com>

On Mon, 24 May 2021 07:15:34 GMT, Tagir F. Valeev  wrote:

>> Sometimes, `Spliterator::forEachRemaining` has much more optimized implementation, compared to `Spliterator::tryAdvance`. For example, if a `Stream::spliterator` called for a stream that has intermediate operations, `tryAdvance()` may buffer intermediate elements while `forEachRemaining()` just delegates to the `wrapAndCopyInto` (see `StreamSpliterators.AbstractWrappingSpliterator` and its inheritors).
>> 
>> `Spliterators::iterator` methods (used in particular by `Stream::iterator`) provide adapter iterators that delegate to the supplied spliterator. Unfortunately, they don't have a specialized implementation for `Iterator::forEachRemaining`. As a result, a default implementation is used that delegates to `hasNext`/`next`, which in turn causes the delegation to `tryAdvance`. It's quite simple to implement `Iterator::forEachRemaining` here, taking advantage of possible spliterator optimizations if the iterator client decides to use `forEachRemaining`.
>> 
>> This patch implements Iterator::forEachRemaining in Spliterators::iterator methods. Also, I nullize the `nextElement` in `Iterator::next` to avoid accidental prolongation of the user's object lifetime when iteration is finished. Finally, a small cleanup: I added the `final` modifier where possible to private fields in `Spliterators`.
>> 
>> Test-wise, some scenarios are already covered by SpliteratorTraversingAndSplittingTest. However, the resulting iterator is always wrapped into `Spliterators::spliterator`, so usage scenarios are somewhat limited. In particular, calling `hasNext` (without `next`) before `forEachRemaining` was not covered there. I added more tests in `IteratorFromSpliteratorTest` to cover these scenarios. I checked that removing `valueReady = false;` or `action.accept(t);` lines from newly implemented `forEachRemaining` method causes new tests to fail (but old tests don't fail due to this).
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test: formatting; tests for empty spliterator

Changes look good.

Testing wise we have the combo test `SpliteratorTraversingAndSplittingTest` that includes a case that tests a Spliterator produced via Spliterator -> Iterator -> Spliterator, and operations on that under various actions. GIven that case do you still think we require explicit tests?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4124

From rriggs at openjdk.java.net  Mon May 24 16:52:12 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 24 May 2021 16:52:12 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v5]
In-Reply-To: <1_4iUmU8gU0wi36E1Jq0j4vUmkl2nXj6u3whQ26bMzY=.3c293611-0804-4d34-a065-b8fdb073d8ad@github.com>
References: 
 
 <1_4iUmU8gU0wi36E1Jq0j4vUmkl2nXj6u3whQ26bMzY=.3c293611-0804-4d34-a065-b8fdb073d8ad@github.com>
Message-ID: 

On Mon, 24 May 2021 10:58:41 GMT, Chris Hegarty  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Editorial javadoc updated based on review comments.
>>   Clarified behavior of rejectUndecidedClass method.
>>   Example test added to check status returned from file.
>
> src/java.base/share/classes/java/io/ObjectInputFilter.java line 829:
> 
>> 827:          * Returns a filter that returns {@code Status.ALLOWED} if the check is for limits
>> 828:          * and not checking a class; otherwise {@code Status.UNDECIDED}.
>> 829:          * If the {@link FilterInfo#serialClass()} is {@code null}, the filter returns
> 
> "Returns a filter that returns {@code Status.ALLOWED} ... ". Maybe "Returns a filter that allows all limits ..".
> 
> Up-levelling a bit, it seems that filter operations fall into two broad categories: 1) class-checking, and 2)limits-checking. At least, in the way that some of these factories and adapters are laid out.  If we had such a notional at the class-level, then maybe that could influence the naming of these factories - and tie them to a higher-level concept.

I'll add some higher level descriptions to the Config class and to ObjectInputFilter class doc.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From github.com+28651297+mkartashev at openjdk.java.net  Mon May 24 16:54:17 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Mon, 24 May 2021 16:54:17 GMT
Subject: RFR: 8195129: System.load() fails to load from unicode paths
Message-ID: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com>

Character strings within JVM are produced and consumed in several formats. Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or dlopen()) consume strings also in UTF8. On Windows, however, the situation is far less simple: some new(er) APIs expect UTF16 (wide-character strings), some older APIs can only work with strings in a "platform" format, where not all UTF8 characters can be represented; which ones can depends on the current "code page".

This commit switches the Windows version of native library loading code to using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use of various string formats in the surrounding code. 

Namely, exception messages are made to consume strings explicitly in the UTF8 format, while logging functions (that end up using legacy Windows API) are made to consume "platform" strings in most cases. One exception is `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, which can, of course, be fixed, but was considered not worth the additional code (NB: this isn't a new bug).

The test runs in a separate JVM in order to make NIO happy about non-ASCII characters in the file name; tests are executed with LC_ALL=C and that doesn't let NIO work with non-ASCII file names even on Linux or MacOS.

Tested by running `test/hotspot/jtreg:tier1` on Linux and `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (`   jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran on those platforms as well.

Results from Linux:

Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/hotspot/jtreg:tier1                     1784  1784     0     0   
==============================
TEST SUCCESS


Building target 'run-test-only' in configuration 'linux-x86_64-server-release'
Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run:
* jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode

Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode'
Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java
Test results: passed: 1


Results from Windows 10:

Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
   jtreg:test/hotspot/jtreg/runtime                    746   746     0     0
==============================
TEST SUCCESS
Finished building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug'


Building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug'
Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run:
* jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode

Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode'
Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java
Test results: passed: 1

-------------

Commit messages:
 - 8195129: System.load() fails to load from unicode paths

Changes: https://git.openjdk.java.net/jdk/pull/4169/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4169&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8195129
  Stats: 294 lines in 7 files changed: 247 ins; 27 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4169.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4169/head:pull/4169

PR: https://git.openjdk.java.net/jdk/pull/4169

From weijun at openjdk.java.net  Mon May 24 17:02:13 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 17:02:13 GMT
Subject: Integrated: 8267184: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <3rH0Qzq38uj4gzgkoDyLE_SnE47c8710ZvGAeSK6UA4=.e080d8bc-838b-4d62-87ff-ca8b12445c8a@github.com>

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.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

This pull request has now been integrated.

Changeset: 640a2afd
Author:    Weijun Wang 
URL:       https://git.openjdk.java.net/jdk/commit/640a2afda36857410b7abf398af81e35430a62e7
Stats:     1028 lines in 852 files changed: 252 ins; 9 del; 767 mod

8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager

Co-authored-by: Lance Andersen 
Co-authored-by: Weijun Wang 
Reviewed-by: dholmes, alanb, dfuchs, mchung, mullan, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071

From naoto at openjdk.java.net  Mon May 24 17:13:12 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 24 May 2021 17:13:12 GMT
Subject: RFR: 8191441: (Process) add Readers and Writer access to
 java.lang.Process streams [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 24 May 2021 00:33:06 GMT, Roger Riggs  wrote:

>> Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process.
>> The Charset used to encode and decode characters to bytes can be specified or use the
>> operating system native encoding as is available from the "native.encoding" system property.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added throws for NPE, delegated zero-arg methods that use native.encoding to
>   the 1-arg method with a charset, added tests for Redirect cases where the streams are null-input or null-output streams.

src/java.base/share/classes/java/lang/Process.java line 292:

> 290: 
> 291:     /**
> 292:      * Returns a {@code BufferedWriter} connected to the normal input of the process the native encoding.

`the native encoding` here seems leftover.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4134

From naoto.sato at oracle.com  Mon May 24 17:21:26 2021
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 24 May 2021 10:21:26 -0700
Subject: Obviously erroneous code in
 JapaneseImperialCalendar::actualMonthLength
In-Reply-To: 
References: 
Message-ID: 

Hi Tagir,

Thank you for reporting the issue. It is in fact already reported here:

https://bugs.openjdk.java.net/browse/JDK-8187649

This is a low priority (rarely occuring) bug, but since it is now 
offending static analyzers, I will take a second look.

Naoto

On 5/24/21 1:46 AM, Tagir Valeev wrote:
> Hello!
> 
> When testing our static analyzer, I've found obviously erroneous code
> in java.util.JapaneseImperialCalendar::actualMonthLength
> 
> int eraIndex = getTransitionEraIndex(jdate);
> if (eraIndex == -1) {
>      long transitionFixedDate = sinceFixedDates[eraIndex];
>      CalendarDate d = eras[eraIndex].getSinceDate();
>      if (transitionFixedDate <= cachedFixedDate) {
>         length -= d.getDayOfMonth() - 1;
>      } else {
>         length = d.getDayOfMonth() - 1;
>      }
> }
> 
> if this 'if' statement is visited then sinceFixedDates[eraIndex] will
> surely fail with ArrayIndexOutOfBoundsException. However, judging from
> the usages of this method, eraIndex is never -1 here, so the whole
> 'if' statement is a dead code. I'm not sure whether it should be
> removed, or the condition should be changed to 'eraIndex != -1' (and
> probably some unit-tests should be written to cover this). I have no
> expertise in this code so I'm not sure what would be a proper way to
> fix it. Please take a look.
> 
> With best regards,
> Tagir Valeev.
> 

From rriggs at openjdk.java.net  Mon May 24 17:24:22 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 24 May 2021 17:24:22 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v6]
In-Reply-To: 
References: 
Message-ID: <-ZHJt0liujJfge-XvUGB1cn95cG50lVdUwS2rdV_pdE=.95a73356-dbec-4b26-8c65-46631f4e3de3@github.com>

> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
> configuration mechanisms and filter utilities.
> 
> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`:
>     http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Review suggestions included;
  Added @implSpec for default methods in OIF;
  Added restriction that the filter factory cannot be set after an ObjectInputStream has been created and applied the current filter factory

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3996/files
  - new: https://git.openjdk.java.net/jdk/pull/3996/files/0274fb4f..f1a797a5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=04-05

  Stats: 189 lines in 2 files changed: 95 ins; 27 del; 67 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3996.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3996/head:pull/3996

PR: https://git.openjdk.java.net/jdk/pull/3996

From psandoz at openjdk.java.net  Mon May 24 17:27:09 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 24 May 2021 17:27:09 GMT
Subject: RFR: 8267614: Outline VarHandleGuards exact behavior checks
In-Reply-To: <_EuiNxRML-XncdKWL8mX7ycYfD8hQYOUttyXBAr-rCY=.d15edec0-cd5a-4031-95c4-48d451c4b674@github.com>
References: <_EuiNxRML-XncdKWL8mX7ycYfD8hQYOUttyXBAr-rCY=.d15edec0-cd5a-4031-95c4-48d451c4b674@github.com>
Message-ID: 

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 microbenchmarks.

Looks good.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4165

From mchung at openjdk.java.net  Mon May 24 18:18:56 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 24 May 2021 18:18:56 GMT
Subject: RFR: 8267614: Outline VarHandleGuards exact behavior checks
In-Reply-To: <_EuiNxRML-XncdKWL8mX7ycYfD8hQYOUttyXBAr-rCY=.d15edec0-cd5a-4031-95c4-48d451c4b674@github.com>
References: <_EuiNxRML-XncdKWL8mX7ycYfD8hQYOUttyXBAr-rCY=.d15edec0-cd5a-4031-95c4-48d451c4b674@github.com>
Message-ID: 

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 microbenchmarks.

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4165

From github.com+73799211+gregcawthorne at openjdk.java.net  Mon May 24 18:50:29 2021
From: github.com+73799211+gregcawthorne at openjdk.java.net (gregcawthorne)
Date: Mon, 24 May 2021 18:50:29 GMT
Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10,
 dexp iff 2.29 or greater on AArch64.
In-Reply-To: 
References: 
Message-ID: <0JcCtbFlWgnepu7qnSZXuPeupgsPfvvOR20Az_2dJSQ=.a365b573-0b5b-4358-a834-44db59128b0d@github.com>

On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne  wrote:

> Glibc 2.29 onwards provides optimised versions of log,log10,exp.
> These functions have an accuracy of 0.9ulp or better in glibc
> 2.29.
> 
> Therefore this patch adds code to parse, store and check
> the runtime glibcs version in os_linux.cpp/hpp.
> This is then used to select the glibcs implementation of
> log, log10, exp at runtime for c1 and c2, iff we have
> glibc 2.29 or greater.
> 
> This will ensure OpenJDK can benefit from future improvements
> to glibc.
> 
> Glibc adheres to the ieee754 standard, unless stated otherwise
> in its spec.
> 
> As there are no stated exceptions in the current glibc spec
> for dlog, dlog10 and dexp, we can assume they currently follow
> ieee754 (which testing confirms). As such, future version of
> glibc are unlikely to lose this compliance with ieee754 in
> future.
> 
> W.r.t performance this patch sees ~15-30% performance improvements for
> log and log10, with ~50-80% performance improvements for exp for the
> common input ranged (which output real numbers). However for the NaN
> and inf output ranges we see a slow down of up to a factor of 2 for
> some functions and architectures.
> 
> Due to this being the uncommon case we assert that this is a
> worthwhile tradeoff.

I have been reading up on the monotonicity paper suggested by Andrew Haley:
[http://www-leland.stanford.edu/class/ee486/doc/ferguson1991.pdf](url)

In order to try and see if I can prove the current glibc implementations of log and exp, for monotonicity.

However, I have come to the conclusion that the paper calculates the relative error threshold for monotonicity for an approximation, and then relies on extra bits of floating-point hardware precision to be guaranteed monotonic. These extra bits of precision are greater than the target representations mantissa bits, which when subsequently rounded at the end (rounding is semi monotonic), leads to a monotonic implementation. No extra bits of floating-point precision are present in AArch64 in-between floating-point operations and so this paper won't help us in this case.

I am currently unsure how the current implementation (from fdlibm I believe) is proven to be monotonic. Perhaps there is a proof I am unaware of. The implementation has obviously stood the test of time at least.

If anyone has an idea of how the existing implementation was proven to be monotonic (if it has been), it could help us to apply it on the Arm optimised routine version (AOR).
What we can do for now is compare the remez approximation used in the current OpenJDK implementation (take log for example):
[https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntimeTrans.cpp#L49](url)

It states:
" The maximum error of this polynomial approximation is bounded by 2**-58.45"
Which must be the theoretical accuracy, as it would be bounded by the 52 bits of mantissa if run on AArch64. And is insufficient for a proof of monotonicity on its own.

Now if you look AOR for log (where the implementation comes from):
[https://github.com/ARM-software/optimized-routines/blob/master/math/tools/log.sollya](url)
[https://github.com/ARM-software/optimized-routines/blob/master/math/tools/log_abs.sollya](url)
And run them, you will see the abs and relative accuracies of ~2**-63 for log.sollya
And for log_abs.sollya which is used for inputs around 1.0, there is an absolute accuracy of ~2**-65 and a relative error of ~ 2**-56.

So for log the theoretical accuracy is actually higher than the current implementations, apart from when near 1.0 the relative error is slightly worse, however I have confirmed with Szabolcs Nagy at Arm who worked on the implementation, that it is the absolute error here which dictates the effective accuracy, as there is arithmetic afterwards which changes the magnitude.
As for the existing accuracy of the exp the implementation code comments state the maximum theoretical error of the remez approximation is 2**-59.

While running the exp soylla script in AOR:
[https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntimeTrans.cpp#L238](url)
It shows its remez has a theoretical accuracy of 2**-66.
[https://github.com/ARM-software/optimized-routines/blob/master/math/tools/exp.sollya](url)

Another thing to consider is the reconstruction process of the current fdlibm implementation and glibcs. glibcs exp and log uses a table lookup algorithm in order to allow their polynomial to have a smaller principle domain around 0 and it is then transformed to a larger principle domain, where as fdlibms does use this method.

A description of the table loop up scheme can be found here:
[https://dl.acm.org/doi/pdf/10.1145/63522.214389](url)
And an analysis of the error bounds of table look type approximations of functions can be found here:
[https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=709374](url)

If the remez polynomial of fdlibm isn?t definitively proven to be monotonic, and the glibcs remez polynomials has comparable accuracy. Then it might suffice to attempt to investigate further the effects of the table lookup method implementation; with regards to semi-monotonicity, even if it wouldn?t offer a total proof of the overall implementation.

My initial look at glibcs' exp implementation is that the relationship between the scale and tail variables, along with the table values themselves possibly appearing monotonic themselves, might indicate that it won't break monotonicity. However this would need further investigation and similarly for log, iff this sub sections proof of monotonicity suffices for the overall implementation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3510

From joe.darcy at oracle.com  Mon May 24 19:07:55 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 24 May 2021 12:07:55 -0700
Subject: RFR: 8224243: Make AccessibleObject a sealed class [v2]
In-Reply-To: 
References: <4DFE3N_LB1D0jraDzmAmhGpzPGZAZrluVqCM5LFo5B4=.bbe76387-44f8-44de-ae2a-ce89d823041b@github.com>
 <1p8BXJHpzVJ_nPh9j0sRoOJwdiYNkO_6DK9sg5T92_A=.9a001d1a-f0d9-428e-8c45-fb5f04cf79b4@github.com>
 
Message-ID: <690bd253-2840-1365-6361-ad023ca2bfff@oracle.com>

Hi Alan,

On 5/22/2021 9:41 AM, Alan Bateman wrote:
> On Fri, 21 May 2021 02:42:50 GMT, Joe Darcy  wrote:
>
>>> Conceptually, AccessbileObject is a sealed class with a protected constructor stating
>>>
>>>      Constructor: only used by the Java Virtual Machine.
>>>
>>> With the language now supporting sealed classes, the AccessbileObject should be marked as sealed.
>>>
>>> Executable and Field are the subclasses of AccessbileObject in the JDK; as Executable has subclasses, it is marked as non-sealed.
>>>
>>> Please also review the corresponding CSR:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8224243
>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Update in response to review feedback.
> src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 533:
>
>> 531:     @Override
>> 532:     public  T getAnnotation(Class annotationClass) {
>> 533:         throw new IllegalStateException("All subclasses should override this method");
> I'm not sure that ISE is the most appropriate exception here because there isn't an alternative state that would accept the input. UOE might be better.
>
> The new proposal to just seal Executable looks reasonable.
>
Yeah; I was looking over which exception type to use. On the whole, UOE 
looks a bit better; I've updated the PR accordingly.

Thanks,

-Joe




From joe.darcy at oracle.com  Mon May 24 19:16:15 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 24 May 2021 12:16:15 -0700
Subject: RFR: 8224243: Make AccessibleObject a sealed class [v2]
In-Reply-To: 
References: <4DFE3N_LB1D0jraDzmAmhGpzPGZAZrluVqCM5LFo5B4=.bbe76387-44f8-44de-ae2a-ce89d823041b@github.com>
 <1p8BXJHpzVJ_nPh9j0sRoOJwdiYNkO_6DK9sg5T92_A=.9a001d1a-f0d9-428e-8c45-fb5f04cf79b4@github.com>
 
Message-ID: <16ff826f-db63-89ac-de7b-33a9e99bd32a@oracle.com>


On 5/24/2021 2:05 AM, Kasper Nielsen wrote:
> On Fri, 21 May 2021 02:42:50 GMT, Joe Darcy  wrote:
>
>>> Conceptually, AccessbileObject is a sealed class with a protected constructor stating
>>>
>>>      Constructor: only used by the Java Virtual Machine.
>>>
>>> With the language now supporting sealed classes, the AccessbileObject should be marked as sealed.
>>>
>>> Executable and Field are the subclasses of AccessbileObject in the JDK; as Executable has subclasses, it is marked as non-sealed.
>>>
>>> Please also review the corresponding CSR:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8224243
>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Update in response to review feedback.
> Missed the part about only Executable being made sealed. But if Executable is sealed, setAccessible(boolean) could still be moved from Method/Constructor down to Executable.

Perhaps; the caller sensitive nature of the methods may preclude or 
complicate that. I don't plan to add such method hoisting to this PR.

Thanks,

-Joe


From weijun at openjdk.java.net  Mon May 24 21:51:32 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 21:51:32 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 24 May 2021 09:00:07 GMT, Daniel Fuchs  wrote:

> Thanks for taking in my suggestions for FtpClient. I have also reviewed the changes to java.util.logging and JMX. I wish there was a way to handle doPrivileged returning void more nicely. Maybe component maintainers will be able to deal with them on a case-by-case basis later on.

Assigning to a useless "dummy" variable looks ugly. Extracting the call to a method might make it faraway from its caller. In L114 of `FtpClient.java` I managed to invent a return value and I thought it was perfect. But you said it's "a bit strange". :-(

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From rriggs at openjdk.java.net  Mon May 24 21:51:57 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 24 May 2021 21:51:57 GMT
Subject: RFR: 8191441: (Process) add Readers and Writer access to
 java.lang.Process streams [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 20 May 2021 20:29:40 GMT, Naoto Sato  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added throws for NPE, delegated zero-arg methods that use native.encoding to
>>   the 1-arg method with a charset, added tests for Redirect cases where the streams are null-input or null-output streams.
>
> src/java.base/share/classes/java/lang/Process.java line 771:
> 
>> 769: 
>> 770:         /**
>> 771:          * {@return Charset for the native encoding or {@link Charset#defaultCharset()}
> 
> Need some edit here?

Looks odd, but is the correct syntax for the new {@return javadoc tag}.
See https://bugs.openjdk.java.net/browse/JDK-8075778

-------------

PR: https://git.openjdk.java.net/jdk/pull/4134

From avoitylov at openjdk.java.net  Mon May 24 21:53:40 2021
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Mon, 24 May 2021 21:53:40 GMT
Subject: RFR: 8266310: deadlock while loading the JNI code [v5]
In-Reply-To: 
References: 
 
 
Message-ID: <756g2ib5byYoHeOgcwSdd5RiTDVYR2UGBMHKpaXM-ew=.ef4597db-af86-4cda-8058-67c6fcff1112@github.com>

On Mon, 24 May 2021 06:24:15 GMT, David Holmes  wrote:

>> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix whitespace
>
> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 511:
> 
>> 509:             if (currentLock.getCounter() == 1) {
>> 510:                 // unlock and release the object if no other threads are queued
>> 511:                 currentLock.unlock();
> 
> This isn't atomic so I don't see how it can work as desired. Overall I don't understand what the semantics of this "counted lock" are intended to be.

Hi David,

The locking strategy is as follows:

CountedLock is a subclass of ReentrantLock that allows exact counting of threads that intend to acquire the lock object. Each time a thread calls acquireNativeLibraryLock() with a certain name, either a new CountedLock object is allocated and assigned 1 as the counter, or an existing CountedLock is incremented prior to invocation of the lock() method on it. The increment operation to the lock object is performed in the context of execution of compute() method, which is executed atomically. This allows to correctly dispose the CountedLock object when the last thread in the queue leaves releaseNativeLibraryLock(). The entire remapping function passed to computeIfPresent() method is executed atomically. 

Could you be more specific on what is not performed atomically?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3976

From darcy at openjdk.java.net  Mon May 24 21:54:09 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 24 May 2021 21:54:09 GMT
Subject: RFR: 8224243: Make AccessibleObject a sealed class [v3]
In-Reply-To: <4DFE3N_LB1D0jraDzmAmhGpzPGZAZrluVqCM5LFo5B4=.bbe76387-44f8-44de-ae2a-ce89d823041b@github.com>
References: <4DFE3N_LB1D0jraDzmAmhGpzPGZAZrluVqCM5LFo5B4=.bbe76387-44f8-44de-ae2a-ce89d823041b@github.com>
Message-ID: 

> Conceptually, AccessbileObject is a sealed class with a protected constructor stating
> 
>     Constructor: only used by the Java Virtual Machine.
> 
> With the language now supporting sealed classes, the AccessbileObject should be marked as sealed.
> 
> Executable and Field are the subclasses of AccessbileObject in the JDK; as Executable has subclasses, it is marked as non-sealed.
> 
> Please also review the corresponding CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8224243

Joe Darcy 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 five additional commits since the last revision:

 - Minor fixes.
 - Change to UnsupportedOperationException.
 - Merge branch 'master' into 8224243
 - Update in response to review feedback.
 - 8224243: Make AccessibleObject a sealed class

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4133/files
  - new: https://git.openjdk.java.net/jdk/pull/4133/files/be517cda..8d0ba447

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4133&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4133&range=01-02

  Stats: 5955 lines in 975 files changed: 2860 ins; 1801 del; 1294 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4133.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4133/head:pull/4133

PR: https://git.openjdk.java.net/jdk/pull/4133

From psandoz at openjdk.java.net  Mon May 24 21:57:08 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 24 May 2021 21:57:08 GMT
Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations
 (skip, limit) [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 24 May 2021 04:35:42 GMT, Tagir F. Valeev  wrote:

>> With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch.
>> 
>> Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch:
>> 
>> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10   40235,534 ?     0,984    B/op
>> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  106431,101 ?     0,198    B/op
>> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  106544,977 ?     1,983    B/op
>> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10   40121,878 ?     0,247    B/op
>> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  106317,693 ?     1,083    B/op
>> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  106430,954 ?     0,136    B/op
>> 
>> 
>> After patch:
>> 
>> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10  40235,648 ?     1,354    B/op
>> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  40355,784 ?     1,288    B/op
>> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  40476,032 ?     2,855    B/op
>> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10  40121,830 ?     0,308    B/op
>> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  40242,554 ?     0,443    B/op
>> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  40363,674 ?     1,576    B/op
>> 
>> 
>> Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests.
>> 
>> Before patch:
>> 
>> Benchmark                         (size)   Mode  Cnt      Score     Error  Units
>> ref.SliceToList.par_baseline       10000  thrpt   30  14876,723 ?  99,770  ops/s
>> ref.SliceToList.par_limit          10000  thrpt   30  14856,841 ? 215,089  ops/s
>> ref.SliceToList.par_skipLimit      10000  thrpt   30   9555,818 ? 991,335  ops/s
>> ref.SliceToList.seq_baseline       10000  thrpt   30  23732,290 ? 444,162  ops/s
>> ref.SliceToList.seq_limit          10000  thrpt   30  14894,040 ? 176,496  ops/s
>> ref.SliceToList.seq_skipLimit      10000  thrpt   30  10646,929 ?  36,469  ops/s
>> value.SliceToArray.par_baseline    10000  thrpt   30  25093,141 ? 376,402  ops/s
>> value.SliceToArray.par_limit       10000  thrpt   30  24798,889 ? 760,762  ops/s
>> value.SliceToArray.par_skipLimit   10000  thrpt   30  16456,310 ? 926,882  ops/s
>> value.SliceToArray.seq_baseline    10000  thrpt   30  69669,787 ? 494,562  ops/s
>> value.SliceToArray.seq_limit       10000  thrpt   30  21097,081 ? 117,338  ops/s
>> value.SliceToArray.seq_skipLimit   10000  thrpt   30  15522,871 ? 112,557  ops/s
>> 
>> 
>> After patch:
>> 
>> Benchmark                         (size)   Mode  Cnt      Score      Error  Units
>> ref.SliceToList.par_baseline       10000  thrpt   30  14793,373 ?   64,905  ops/s
>> ref.SliceToList.par_limit          10000  thrpt   30  13301,024 ? 1300,431  ops/s
>> ref.SliceToList.par_skipLimit      10000  thrpt   30  11131,698 ? 1769,932  ops/s
>> ref.SliceToList.seq_baseline       10000  thrpt   30  24101,048 ?  263,528  ops/s
>> ref.SliceToList.seq_limit          10000  thrpt   30  16872,168 ?   76,696  ops/s
>> ref.SliceToList.seq_skipLimit      10000  thrpt   30  11953,253 ?  105,231  ops/s
>> value.SliceToArray.par_baseline    10000  thrpt   30  25442,442 ?  455,554  ops/s
>> value.SliceToArray.par_limit       10000  thrpt   30  23111,730 ? 2246,086  ops/s
>> value.SliceToArray.par_skipLimit   10000  thrpt   30  17980,750 ? 2329,077  ops/s
>> value.SliceToArray.seq_baseline    10000  thrpt   30  66512,898 ? 1001,042  ops/s
>> value.SliceToArray.seq_limit       10000  thrpt   30  41792,549 ? 1085,547  ops/s
>> value.SliceToArray.seq_skipLimit   10000  thrpt   30  18007,613 ?  141,716  ops/s
>> 
>> 
>> I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Trailing whitespace removed

Very good. Thanks making the adjustments. Architecturally, i think we are in a better place. Just have some comments, mostly around code comments.

src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 471:

> 469:         int flags = getStreamAndOpFlags();
> 470:         long size = StreamOpFlag.SIZED.isKnown(flags) ? spliterator.getExactSizeIfKnown() : -1;
> 471:         if (size != -1 && StreamOpFlag.SIZE_ADJUSTING.isKnown(flags) && !isParallel()) {

Very nice. It's a good compromise to support only for sequential streams, since we have no size adjusting intermediate stateless op. If that was the case we would need to step back through the pipeline until the depth was zero, then step forward. I think it worth a comment here to inform our future selves if we ever add such an operation. 

Strictly speaking we only need to call `exactOutputSize` if the stage is size adjusting. Not sure it really matters perf-wise. If we leave as is maybe add a comment.

src/java.base/share/classes/java/util/stream/StreamOpFlag.java line 331:

> 329: 
> 330:     /**
> 331:      * Characteristic value signifying that an operation may adjust the

I think we need to add two additional constraints to the documentation:
1. The flag, if present, is only valid when SIZED is present; and
2. The flag is only valid for sequential streams.
The latter is a good compromise given we currently have no size adjusting stateless intermediate op.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3427

From rriggs at openjdk.java.net  Mon May 24 21:57:50 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 24 May 2021 21:57:50 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v7]
In-Reply-To: 
References: 
Message-ID: 

> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
> configuration mechanisms and filter utilities.
> 
> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`:
>     http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Move merge and rejectUndecidedClass methods to OIF.Config
  As default methods on OIF, their implementations were not concrete and not trustable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3996/files
  - new: https://git.openjdk.java.net/jdk/pull/3996/files/f1a797a5..141bf720

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=05-06

  Stats: 459 lines in 3 files changed: 232 ins; 141 del; 86 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3996.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3996/head:pull/3996

PR: https://git.openjdk.java.net/jdk/pull/3996

From herrick at openjdk.java.net  Mon May 24 22:10:43 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 24 May 2021 22:10:43 GMT
Subject: Integrated: JDK-8267423: Fix copyrights in jpackage tests
In-Reply-To: <_j5L4bWX1ODNrw_RgdBaDVIgP-el9_j_0xfiQTVDgmY=.c5d6f9e7-0801-49ae-a91c-117c65565fd6@github.com>
References: <_j5L4bWX1ODNrw_RgdBaDVIgP-el9_j_0xfiQTVDgmY=.c5d6f9e7-0801-49ae-a91c-117c65565fd6@github.com>
Message-ID: 

On Fri, 21 May 2021 12:22:16 GMT, Andy Herrick  wrote:

> JDK-8267423: Fix copyrights in jpackage tests

This pull request has now been integrated.

Changeset: a5467ae7
Author:    Andy Herrick 
URL:       https://git.openjdk.java.net/jdk/commit/a5467ae7bb5780f34728ad073c5c4158894c7c4b
Stats:     96 lines in 10 files changed: 69 ins; 14 del; 13 mod

8267423: Fix copyrights in jpackage tests

Reviewed-by: kcr, asemenyuk

-------------

PR: https://git.openjdk.java.net/jdk/pull/4144

From kcr at openjdk.java.net  Mon May 24 22:33:42 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 24 May 2021 22:33:42 GMT
Subject: RFR: 8191441: (Process) add Readers and Writer access to
 java.lang.Process streams [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 24 May 2021 18:55:33 GMT, Roger Riggs  wrote:

>> src/java.base/share/classes/java/lang/Process.java line 771:
>> 
>>> 769: 
>>> 770:         /**
>>> 771:          * {@return Charset for the native encoding or {@link Charset#defaultCharset()}
>> 
>> Need some edit here?
>
> Looks odd, but is the correct syntax for the new {@return javadoc tag}.
> See https://bugs.openjdk.java.net/browse/JDK-8075778

Hmm. Unless I'm missing something, you have mismatched curly braces.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4134

From redestad at openjdk.java.net  Mon May 24 22:47:52 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 24 May 2021 22:47:52 GMT
Subject: RFR: 8267614: Outline VarHandleGuards exact behavior checks
In-Reply-To: <_EuiNxRML-XncdKWL8mX7ycYfD8hQYOUttyXBAr-rCY=.d15edec0-cd5a-4031-95c4-48d451c4b674@github.com>
References: <_EuiNxRML-XncdKWL8mX7ycYfD8hQYOUttyXBAr-rCY=.d15edec0-cd5a-4031-95c4-48d451c4b674@github.com>
Message-ID: 

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 microbenchmarks.

Paul, Mandy, thanks for reviewing

-------------

PR: https://git.openjdk.java.net/jdk/pull/4165

From redestad at openjdk.java.net  Mon May 24 22:49:05 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 24 May 2021 22:49:05 GMT
Subject: RFR: 8267612: Declare package-private VarHandle.AccessMode/-Type
 counts [v2]
In-Reply-To: 
References: 
Message-ID: <9BJzykl2dqln_UMiEmV6G-evI8QRXqJ-8mTeeJG8FiU=.d709a92e-ea5e-4ea6-989f-c43e116cea54@github.com>

> 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 review

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4164/files
  - new: https://git.openjdk.java.net/jdk/pull/4164/files/89f7c64d..5b5e719f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4164&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4164&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4164.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4164/head:pull/4164

PR: https://git.openjdk.java.net/jdk/pull/4164

From rriggs at openjdk.java.net  Mon May 24 23:02:15 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 24 May 2021 23:02:15 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: <-Rpcq-g6N5dUfBhonX_RiBq7d1smTLBC5FhV1a-fIJU=.b0d003eb-082c-41e1-b981-857b4b70390b@github.com>
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
 
 <-Rpcq-g6N5dUfBhonX_RiBq7d1smTLBC5FhV1a-fIJU=.b0d003eb-082c-41e1-b981-857b4b70390b@github.com>
Message-ID: 

On Fri, 21 May 2021 16:26:46 GMT, Roger Riggs  wrote:

>> src/java.base/share/classes/java/io/ObjectInputFilter.java line 1139:
>> 
>>> 1137:          * and not classes.
>>> 1138:          */
>>> 1139:         private static class AllowMaxLimitsFilter implements ObjectInputFilter {
>> 
>> This class is maybe misnamed. If limitCheck == REJECTED it will not allow max limits. Or am I missing something?
>
> Rejection always wins in the larger scheme of things; another filter may reject based on other limits.
> In the composition of filters, any UNDECIDED results must eventually be decided.
> This filter maps, for a limit check, the UNDECIDED to allowed; it does nothing for checks for classes.
> Other names considered,  allowUnlimited().  Also, not guaranteed.
> Perhaps, something in the xxxElseYyy family.  Will reconsider the name.

The allowMaxLimitsFilter will removed, its definition is confusing and it is not clear how it would be used.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From bchristi at openjdk.java.net  Mon May 24 23:14:10 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Mon, 24 May 2021 23:14:10 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v6]
In-Reply-To: <-ZHJt0liujJfge-XvUGB1cn95cG50lVdUwS2rdV_pdE=.95a73356-dbec-4b26-8c65-46631f4e3de3@github.com>
References: 
 <-ZHJt0liujJfge-XvUGB1cn95cG50lVdUwS2rdV_pdE=.95a73356-dbec-4b26-8c65-46631f4e3de3@github.com>
Message-ID: 

On Mon, 24 May 2021 17:24:22 GMT, Roger Riggs  wrote:

>> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
>> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
>> configuration mechanisms and filter utilities.
>> 
>> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`:
>>     http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions included;
>   Added @implSpec for default methods in OIF;
>   Added restriction that the filter factory cannot be set after an ObjectInputStream has been created and applied the current filter factory

Changes requested by bchristi (Reviewer).

src/java.base/share/classes/java/io/ObjectInputFilter.java line 1222:

> 1220:             /**
> 1221:              * Apply the predicate to the class being deserialized, if the class is non-null
> 1222:              * and if it returns {@code true}, return the requested status. Otherwise, return UNDECIDED.

Isn't `ifFalseStatus` returned in the "otherwise" case, not (necessarily) `UNDECIDED` ?

src/java.base/share/classes/java/io/ObjectInputFilter.java line 1236:

> 1234:             public String toString() {
> 1235:                 return "predicate(" + predicate + ")";
> 1236:             }

Would it also be useful to also print `ifTrueStatus` and `ifFalseStatus` ?  Not sure, given this is an internal class...

src/java.base/share/classes/java/io/ObjectInputFilter.java line 1283:

> 1281:              * Returns REJECTED if either of the filters returns REJECTED,
> 1282:              * and ALLOWED if either of the filters returns ALLOWED.
> 1283:              * Returns {@code UNDECIDED} if either filter returns {@code UNDECIDED}.

The description of when `UNDECIDED` is returned should match `@return`.
Alternately, have minimal documentation here, and refer to the public merge() method, which this implements.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From bchristi at openjdk.java.net  Mon May 24 23:14:12 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Mon, 24 May 2021 23:14:12 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 24 May 2021 21:57:50 GMT, Roger Riggs  wrote:

>> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
>> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
>> configuration mechanisms and filter utilities.
>> 
>> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`:
>>     http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move merge and rejectUndecidedClass methods to OIF.Config
>   As default methods on OIF, their implementations were not concrete and not trustable

src/java.base/share/classes/java/io/ObjectInputFilter.java line 177:

> 175:  *                 // Initially this would be the static JVM-wide filter passed from the OIS constructor
> 176:  *                 // Append the filter to reject all UNDECIDED results
> 177:  *                 filter = next.merge(filter).rejectUndecidedClass();

Update for merge() now being class method

src/java.base/share/classes/java/io/ObjectInputFilter.java line 866:

> 864:         /**
> 865:          * Returns a filter that merges the status of a filter and another filter.
> 866:          * If the other filter is {@code null}, the filter is returned.

Now that this method is static, this sentence could be further clarified with some markup, IMO:
"If `{@code anotherFilter}` is `{@code null}`, `{@code filter}` is returned."

src/java.base/share/classes/java/io/ObjectInputFilter.java line 874:

> 872:          *     
  • Invoke {@code filter} on the {@code FilterInfo} to get its {@code status};
> 873:          *     
  • Return {@code REJECTED} if the {@code status} is {@code REJECTED};
> 874:          *     
  • Invoke the {@code otherFilter} to get the {@code otherStatus};

"the `otherFilter`" -> "`anotherFilter`"

src/java.base/share/classes/java/io/ObjectInputFilter.java line 892:

> 890: 
> 891:         /**
> 892:          * Returns a filter that invokes a filter and maps {@code UNDECIDED} to {@code REJECTED}

"...that invokes _the given_ filter..." ?

src/java.base/share/classes/java/io/ObjectInputFilter.java line 895:

> 893:          * for classes, with some exceptions, and otherwise returns the status.
> 894:          * The filter returned checks that classes not {@code ALLOWED} and not {@code REJECTED} by the filter
> 895:          * are {@code REJECTED}, if the class is an array and the base component type is not allowed,

Could/should this be simplified to, "...checks that classes not ALLOWED by the filter are REJECTED."?

Also, I would add something like, "...,_including_ if the class is..." or "...,_even_ if the class is..."; otherwise it sounds a bit like this _only_ applies to arrays.

src/java.base/share/classes/java/io/ObjectInputFilter.java line 1422:

> 1420:          * {@linkplain ObjectInputStream#ObjectInputStream(InputStream) ObjectInputStream constructors}.
> 1421:          * When invoked from {@link ObjectInputStream#setObjectInputFilter(ObjectInputFilter)
> 1422:          * to set the stream-specific filter} the requested filter replaces the static serial filter,

"When invoked _from to_ set the..."

src/java.base/share/classes/java/io/ObjectInputFilter.java line 1477:

> 1475: 
> 1476:             /**
> 1477:              * Returns the class name name of this builtin deserialization filter factory.

name name

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From redestad at openjdk.java.net  Mon May 24 23:06:08 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 24 May 2021 23:06:08 GMT
Subject: Integrated: 8267614: Outline VarHandleGuards exact behavior checks
In-Reply-To: <_EuiNxRML-XncdKWL8mX7ycYfD8hQYOUttyXBAr-rCY=.d15edec0-cd5a-4031-95c4-48d451c4b674@github.com>
References: <_EuiNxRML-XncdKWL8mX7ycYfD8hQYOUttyXBAr-rCY=.d15edec0-cd5a-4031-95c4-48d451c4b674@github.com>
Message-ID: 

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 microbenchmarks.

This pull request has now been integrated.

Changeset: c519ba2e
Author:    Claes Redestad 
URL:       https://git.openjdk.java.net/jdk/commit/c519ba2e437a05ac83e53b358b6a02b2f6e20563
Stats:     338 lines in 3 files changed: 14 ins; 243 del; 81 mod

8267614: Outline VarHandleGuards exact behavior checks

Reviewed-by: psandoz, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/4165

From mchung at openjdk.java.net  Mon May 24 23:18:05 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 24 May 2021 23:18:05 GMT
Subject: RFR: 8267612: Declare package-private VarHandle.AccessMode/-Type
 counts [v2]
In-Reply-To: <9BJzykl2dqln_UMiEmV6G-evI8QRXqJ-8mTeeJG8FiU=.d709a92e-ea5e-4ea6-989f-c43e116cea54@github.com>
References: 
 <9BJzykl2dqln_UMiEmV6G-evI8QRXqJ-8mTeeJG8FiU=.d709a92e-ea5e-4ea6-989f-c43e116cea54@github.com>
Message-ID: 

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 review

Looks good.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4164

From david.holmes at oracle.com  Tue May 25 01:44:24 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 25 May 2021 11:44:24 +1000
Subject: RFR: 8266310: deadlock while loading the JNI code [v5]
In-Reply-To: <756g2ib5byYoHeOgcwSdd5RiTDVYR2UGBMHKpaXM-ew=.ef4597db-af86-4cda-8058-67c6fcff1112@github.com>
References: 
 
 
 <756g2ib5byYoHeOgcwSdd5RiTDVYR2UGBMHKpaXM-ew=.ef4597db-af86-4cda-8058-67c6fcff1112@github.com>
Message-ID: 

On 25/05/2021 7:53 am, Aleksei Voitylov wrote:
> On Mon, 24 May 2021 06:24:15 GMT, David Holmes  wrote:
> 
>>> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    fix whitespace
>>
>> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 511:
>>
>>> 509:             if (currentLock.getCounter() == 1) {
>>> 510:                 // unlock and release the object if no other threads are queued
>>> 511:                 currentLock.unlock();
>>
>> This isn't atomic so I don't see how it can work as desired. Overall I don't understand what the semantics of this "counted lock" are intended to be.
> 
> Hi David,
> 
> The locking strategy is as follows:
> 
> CountedLock is a subclass of ReentrantLock that allows exact counting of threads that intend to acquire the lock object. Each time a thread calls acquireNativeLibraryLock() with a certain name, either a new CountedLock object is allocated and assigned 1 as the counter, or an existing CountedLock is incremented prior to invocation of the lock() method on it. The increment operation to the lock object is performed in the context of execution of compute() method, which is executed atomically. This allows to correctly dispose the CountedLock object when the last thread in the queue leaves releaseNativeLibraryLock(). The entire remapping function passed to computeIfPresent() method is executed atomically.

So the counting is trying to be an in-use count so that it can be 
deleted when not needed? I'm still not clear on exactly what this 
counting is doing (partly because I have trouble reading the lambda 
expressions that relate to the lock).

> Could you be more specific on what is not performed atomically?

The code I referenced. The counter is not protected by the lock that it 
counts. In the code above we hold the lock and check if the counter == 1 
before unlocking. But the counter is incremented without the lock held, 
so as soon as we have called getCounter() the count could have changed.

David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3976
> 

From yyang at openjdk.java.net  Tue May 25 02:12:03 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 25 May 2021 02:12:03 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 30 Apr 2021 19:20:54 GMT, Igor Veresov  wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   better check1-4
>
> Looks like now the test fails in the pre-submit tests?

Hi @veresov, may?I?ask?your?help?to?review?this?patch??Thanks?a?lot.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From iveresov at openjdk.java.net  Tue May 25 02:28:01 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Tue, 25 May 2021 02:28:01 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 8 May 2021 03:00:14 GMT, Yi Yang  wrote:

>> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
>> 
>> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
>> 
>> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
>> 
>> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
>> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
>> 
>> Testing: cds, compiler and jdk
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   x86_32 fails

Marked as reviewed by iveresov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From yyang at openjdk.java.net  Tue May 25 02:48:06 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 25 May 2021 02:48:06 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 30 Apr 2021 19:20:54 GMT, Igor Veresov  wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   better check1-4
>
> Looks like now the test fails in the pre-submit tests?

Thank you @veresov! 

I'm glad to have more comments from hotspot-compiler group.

Later, I'd like to integrate it if there are no more comments/objections.

Thanks!
Yang

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From tvaleev at openjdk.java.net  Tue May 25 03:52:06 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Tue, 25 May 2021 03:52:06 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch
In-Reply-To: 
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
 
Message-ID: <4cPrOLZV8ybO_73OiaHFo3Yt8TwSRoJYvFMzeOBMQMo=.0c03c713-d4f8-4631-b485-e5f4d0441374@github.com>

On Mon, 24 May 2021 13:44:36 GMT, Daniel Fuchs  wrote:

>> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
>> 
>> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?
>
> src/java.base/share/classes/java/util/regex/CharPredicates.java line 217:
> 
>> 215:             case "WORD" -> WORD();
>> 216:             default -> null;
>> 217:         };
> 
> This file has lots of changes which are difficult to review. Maybe it should be split out of this PR.

*sigh* GitHub diff tool is really poor and outdated. Here's how it looks in IntelliJ IDEA diff view:
![image](https://user-images.githubusercontent.com/5114450/119436474-6b455b80-bd46-11eb-8865-8b7f30826a8d.png)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161

From tvaleev at openjdk.java.net  Tue May 25 03:56:07 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Tue, 25 May 2021 03:56:07 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch
In-Reply-To: 
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
 
Message-ID: 

On Mon, 24 May 2021 13:46:58 GMT, Daniel Fuchs  wrote:

>> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
>> 
>> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?
>
> src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 261:
> 
>> 259:             ZipEntry e = current.entry;
>> 260:             switch (e.method) {
>> 261:                 case DEFLATED -> {
> 
> Same remark here - it's not clear what's going on.

Here, it's mostly indentation change (+4 spaces). You can set "Hide whitespace changes" and see:
![image](https://user-images.githubusercontent.com/5114450/119436860-3259b680-bd47-11eb-92d8-f940493d08c2.png)
Alternatively, I can indent back this switch, placing `case` on the same indentation level as `switch`. I'm not sure about recommended code style in OpenJDK project, it looks like it's not very consistent.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161

From tvaleev at openjdk.java.net  Tue May 25 04:13:36 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Tue, 25 May 2021 04:13:36 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v2]
In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
Message-ID: 

> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
> 
> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Unindent switch cases to simplify the review

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4161/files
  - new: https://git.openjdk.java.net/jdk/pull/4161/files/807d780d..2e966d0f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=00-01

  Stats: 64 lines in 1 file changed: 27 ins; 27 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4161.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161

PR: https://git.openjdk.java.net/jdk/pull/4161

From tvaleev at openjdk.java.net  Tue May 25 05:12:06 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Tue, 25 May 2021 05:12:06 GMT
Subject: RFR: 8267452: Delegate forEachRemaining in
 Spliterators.iterator() [v2]
In-Reply-To: <1sJ0hj9Wk6TeY6fTYOi9v4d1d_51hM9pUl9b6dRKjzk=.640cf904-faad-42ed-b013-994d0d9265d5@github.com>
References: 
 
 <1sJ0hj9Wk6TeY6fTYOi9v4d1d_51hM9pUl9b6dRKjzk=.640cf904-faad-42ed-b013-994d0d9265d5@github.com>
Message-ID: <6LuL1gzyowIj5oN3_IEAa5nxZeWCR63VZH7MP_xR_bo=.591a2cb5-06c7-4f2b-b163-ed488ea87f23@github.com>

On Mon, 24 May 2021 16:35:08 GMT, Paul Sandoz  wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test: formatting; tests for empty spliterator
>
> Changes look good.
> 
> Testing wise we have the combo test `SpliteratorTraversingAndSplittingTest` that includes a case that tests a Spliterator produced via Spliterator -> Iterator -> Spliterator, and operations on that under various actions. GIven that case do you still think we require explicit tests?

@PaulSandoz thanks for review!

As for `SpliteratorTraversingAndSplittingTest`, I commented in the issue description above:

> Test-wise, some scenarios are already covered by SpliteratorTraversingAndSplittingTest. However, the resulting iterator is always wrapped into `Spliterators::spliterator`, so usage scenarios are somewhat limited. In particular, calling `hasNext` (without `next`) before `forEachRemaining` was not covered there. I added more tests in `IteratorFromSpliteratorTest` to cover these scenarios. I checked that removing `valueReady = false;` or `action.accept(t);` lines from newly implemented `forEachRemaining` method causes new tests to fail (but old tests don't fail due to this).

In short, it doesn't pass manual mutation testing. New tests are capable to catch more possible regressions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4124

From tvaleev at openjdk.java.net  Tue May 25 06:01:49 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Tue, 25 May 2021 06:01:49 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v3]
In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
Message-ID: <78LopXMnM-8NJkcJRbMIcJFSzAEpOvyOXuhA_4vr9gg=.3a1ed69b-99e0-4a0a-912f-57a861decd2d@github.com>

> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
> 
> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Indent some lines to make GitHub diff happier

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4161/files
  - new: https://git.openjdk.java.net/jdk/pull/4161/files/2e966d0f..07a998bc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=01-02

  Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4161.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161

PR: https://git.openjdk.java.net/jdk/pull/4161

From tvaleev at openjdk.java.net  Tue May 25 06:06:05 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Tue, 25 May 2021 06:06:05 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v3]
In-Reply-To: <4cPrOLZV8ybO_73OiaHFo3Yt8TwSRoJYvFMzeOBMQMo=.0c03c713-d4f8-4631-b485-e5f4d0441374@github.com>
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
 
 <4cPrOLZV8ybO_73OiaHFo3Yt8TwSRoJYvFMzeOBMQMo=.0c03c713-d4f8-4631-b485-e5f4d0441374@github.com>
Message-ID: 

On Tue, 25 May 2021 03:48:41 GMT, Tagir F. Valeev  wrote:

>> src/java.base/share/classes/java/util/regex/CharPredicates.java line 217:
>> 
>>> 215:             case "WORD" -> WORD();
>>> 216:             default -> null;
>>> 217:         };
>> 
>> This file has lots of changes which are difficult to review. Maybe it should be split out of this PR.
>
> *sigh* GitHub diff tool is really poor and outdated. Here's how it looks in IntelliJ IDEA diff view:
> ![image](https://user-images.githubusercontent.com/5114450/119436474-6b455b80-bd46-11eb-8865-8b7f30826a8d.png)

I played with indentations and found a way to make GitHub diff happier. Now, lines like `? UPPERCASE().union(LOWERCASE(), TITLECASE())` are probably a little bit too far to the right but it's still acceptable and diff looks much easier to review now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161

From alanb at openjdk.java.net  Tue May 25 07:08:12 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 25 May 2021 07:08:12 GMT
Subject: RFR: 8224243: Make AccessibleObject a sealed class [v3]
In-Reply-To: 
References: <4DFE3N_LB1D0jraDzmAmhGpzPGZAZrluVqCM5LFo5B4=.bbe76387-44f8-44de-ae2a-ce89d823041b@github.com>
 
Message-ID: 

On Mon, 24 May 2021 21:54:09 GMT, Joe Darcy  wrote:

>> Conceptually, AccessbileObject is a sealed class with a protected constructor stating
>> 
>>     Constructor: only used by the Java Virtual Machine.
>> 
>> With the language now supporting sealed classes, the AccessbileObject should be marked as sealed.
>> 
>> Executable and Field are the subclasses of AccessbileObject in the JDK; as Executable has subclasses, it is marked as non-sealed.
>> 
>> Please also review the corresponding CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8224243
>
> Joe Darcy 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 five additional commits since the last revision:
> 
>  - Minor fixes.
>  - Change to UnsupportedOperationException.
>  - Merge branch 'master' into 8224243
>  - Update in response to review feedback.
>  - 8224243: Make AccessibleObject a sealed class

The updated proposal looks good although the JBS issue should probably be renamed as the proposal is no longer to seal AccessibleObject.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4133

From alanb at openjdk.java.net  Tue May 25 07:19:04 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 25 May 2021 07:19:04 GMT
Subject: RFR: 8191441: (Process) add Readers and Writer access to
 java.lang.Process streams [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <0XPexwHSRsGiLBMubCXkS1Z8b4Lv3H7pV7E2sszSptg=.e3361c7c-d0e4-40db-9d69-468807812364@github.com>

On Mon, 24 May 2021 01:21:09 GMT, Roger Riggs  wrote:

> On the question of process termination behavior, I'm not sure what can be said that could be specification.
> The implementations vary between Mac, Linux, and Windows; with the common thread
> to avoid losing process output. But this may have to be included in the unspecified implementation behavior
> or just an API note. Suggestions?

I think the javadoc could set expectations that the behavior when the process has terminated, and streams have not been redirected, is unspecified. Reading from the process output/error streams may read some or no bytes/characters.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4134

From alanb at openjdk.java.net  Tue May 25 07:41:08 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 25 May 2021 07:41:08 GMT
Subject: RFR: 8195129: System.load() fails to load from unicode paths
In-Reply-To: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com>
References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com>
Message-ID: 

On Mon, 24 May 2021 16:43:09 GMT, Maxim Kartashev  wrote:

> Character strings within JVM are produced and consumed in several formats. Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or dlopen()) consume strings also in UTF8. On Windows, however, the situation is far less simple: some new(er) APIs expect UTF16 (wide-character strings), some older APIs can only work with strings in a "platform" format, where not all UTF8 characters can be represented; which ones can depends on the current "code page".
> 
> This commit switches the Windows version of native library loading code to using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use of various string formats in the surrounding code. 
> 
> Namely, exception messages are made to consume strings explicitly in the UTF8 format, while logging functions (that end up using legacy Windows API) are made to consume "platform" strings in most cases. One exception is `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, which can, of course, be fixed, but was considered not worth the additional code (NB: this isn't a new bug).
> 
> The test runs in a separate JVM in order to make NIO happy about non-ASCII characters in the file name; tests are executed with LC_ALL=C and that doesn't let NIO work with non-ASCII file names even on Linux or MacOS.
> 
> Tested by running `test/hotspot/jtreg:tier1` on Linux and `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (`   jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran on those platforms as well.
> 
> Results from Linux:
> 
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg:tier1                     1784  1784     0     0   
> ==============================
> TEST SUCCESS
> 
> 
> Building target 'run-test-only' in configuration 'linux-x86_64-server-release'
> Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run:
> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode
> 
> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode'
> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java
> Test results: passed: 1
> 
> 
> Results from Windows 10:
> 
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/runtime                    746   746     0     0
> ==============================
> TEST SUCCESS
> Finished building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug'
> 
> 
> Building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug'
> Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run:
> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode
> 
> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode'
> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java
> Test results: passed: 1

test/hotspot/jtreg/runtime/jni/loadLibraryUnicode/LoadLibraryUnicode.java line 6:

> 4:  * Licensed under the Apache License, Version 2.0 (the "License");
> 5:  * you may not use this file except in compliance with the License.
> 6:  * You may obtain a copy of the License at

The test sources have Apache license, I thought we always used GPL for tests.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4169

From github.com+10835776+stsypanov at openjdk.java.net  Tue May 25 07:45:32 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 25 May 2021 07:45:32 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList [v2]
In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
Message-ID: 

> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
> 
> jdk:tier1 and jdk:tier2 are both ok

?????? ??????? has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision:

 - 8263561: Use interface List instead of particular type where possible
 - 8263561: Rename requestList -> requests
 - 8263561: Re-examine uses of LinkedList

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2744/files
  - new: https://git.openjdk.java.net/jdk/pull/2744/files/73029fe1..158006c6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=00-01

  Stats: 17 lines in 2 files changed: 0 ins; 0 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2744.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2744/head:pull/2744

PR: https://git.openjdk.java.net/jdk/pull/2744

From alanb at openjdk.java.net  Tue May 25 07:54:15 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 25 May 2021 07:54:15 GMT
Subject: RFR: 8191441: (Process) add Readers and Writer access to
 java.lang.Process streams [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 24 May 2021 00:33:06 GMT, Roger Riggs  wrote:

>> Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process.
>> The Charset used to encode and decode characters to bytes can be specified or use the
>> operating system native encoding as is available from the "native.encoding" system property.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added throws for NPE, delegated zero-arg methods that use native.encoding to
>   the 1-arg method with a charset, added tests for Redirect cases where the streams are null-input or null-output streams.

The updated javadoc addresses most of my points. The clarification to inputReader/errorReader about malformed input looks good but we will need the equivalent in outputWriter for the unmappable character case.
I assume the "not null" can be dropped from the description of the charset parameter as NPE is now specified.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4134

From aleksei.voitylov at bell-sw.com  Tue May 25 08:22:50 2021
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Tue, 25 May 2021 11:22:50 +0300
Subject: RFR: 8266310: deadlock while loading the JNI code [v5]
In-Reply-To: 
References: 
 
 
 <756g2ib5byYoHeOgcwSdd5RiTDVYR2UGBMHKpaXM-ew=.ef4597db-af86-4cda-8058-67c6fcff1112@github.com>
 
Message-ID: <5b14fc4d-e0a9-d203-5b5e-36524ed41d41@bell-sw.com>


On 25/05/2021 04:44, David Holmes wrote:
> On 25/05/2021 7:53 am, Aleksei Voitylov wrote:
>> On Mon, 24 May 2021 06:24:15 GMT, David Holmes 
>> wrote:
>>
>>>> Aleksei Voitylov has updated the pull request incrementally with
>>>> one additional commit since the last revision:
>>>>
>>>> ?? fix whitespace
>>>
>>> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java
>>> line 511:
>>>
>>>> 509:???????????? if (currentLock.getCounter() == 1) {
>>>> 510:???????????????? // unlock and release the object if no other
>>>> threads are queued
>>>> 511:???????????????? currentLock.unlock();
>>>
>>> This isn't atomic so I don't see how it can work as desired. Overall
>>> I don't understand what the semantics of this "counted lock" are
>>> intended to be.
>>
>> Hi David,
>>
>> The locking strategy is as follows:
>>
>> CountedLock is a subclass of ReentrantLock that allows exact counting
>> of threads that intend to acquire the lock object. Each time a thread
>> calls acquireNativeLibraryLock() with a certain name, either a new
>> CountedLock object is allocated and assigned 1 as the counter, or an
>> existing CountedLock is incremented prior to invocation of the lock()
>> method on it. The increment operation to the lock object is performed
>> in the context of execution of compute() method, which is executed
>> atomically. This allows to correctly dispose the CountedLock object
>> when the last thread in the queue leaves releaseNativeLibraryLock().
>> The entire remapping function passed to computeIfPresent() method is
>> executed atomically.
>
> So the counting is trying to be an in-use count so that it can be
> deleted when not needed? 
Yes. The ReentrantLock does not provide an exact count of threads in the
queue, so we had to invent something here. ReentrantLock only has the
lock.state that's exact which is the number of holds by the same thread
which is not what we need to make sure the object can be disposed.
> I'm still not clear on exactly what this counting is doing (partly
> because I have trouble reading the lambda expressions that relate to
> the lock).
The counter is incremented each time a thread calls
acquireNativeLibraryLock(), regardless of that it is the same or a
different thread.
>
>> Could you be more specific on what is not performed atomically?
>
> The code I referenced. The counter is not protected by the lock that
> it counts. 
Yes, but it is protected by a barrier created by synchronized() block in
the computeIfPresent() code. The entire lambda is executed inside that
synchronized() block. The ReentrantLock.unlock() is called here so that
the calling thread releases the per-library lock object, prior to
"forgetting" the reference to that object.
> In the code above we hold the lock and check if the counter == 1
> before unlocking. But the counter is incremented without the lock
> held, so as soon as we have called getCounter() the count could have
> changed.
The counter is incremented and decremented in the lambda expression
executed inside computeXXX() method which blocks on the hash map node
containing the lock object. That lambda is guaranteed to be executed
atomically for all threads referencing the same key.
>
> David
> -----
>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/3976
>>


From pconcannon at openjdk.java.net  Tue May 25 08:28:10 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 25 May 2021 08:28:10 GMT
Subject: Integrated: 8267110: Update java.util to use instanceof pattern
 variable
In-Reply-To: 
References: 
Message-ID: 

On Tue, 18 May 2021 10:37:21 GMT, Patrick Concannon  wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

This pull request has now been integrated.

Changeset: a52c4ede
Author:    Patrick Concannon 
URL:       https://git.openjdk.java.net/jdk/commit/a52c4ede2f043b7d4a234c7d06f91871312e9654
Stats:     267 lines in 29 files changed: 1 ins; 125 del; 141 mod

8267110: Update java.util to use instanceof pattern variable

Reviewed-by: lancea, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/4088

From chegar at openjdk.java.net  Tue May 25 09:18:04 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 25 May 2021 09:18:04 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v3]
In-Reply-To: 
References: 
 <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com>
 
 
 
 
Message-ID: 

On Mon, 24 May 2021 15:09:26 GMT, Roger Riggs  wrote:

> i) is too limiting. It should be possible for an application to check whether a filter factory has been provided on the command line (by calling getSerialFilterFactory) and if not setting the factory itself. It may also want to install its own filter factory that delegates to the builtin factory without needed to re-implement the builtin behavior.

How is this supposed to work in practice?  getSerialFilterFactory always returns a non-null factory, so how does one know whether or not the returned factory is the built-in factory, a factory set by the command line (or security property) ? (without resorting to implementation assumptions)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From redestad at openjdk.java.net  Tue May 25 09:28:01 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 25 May 2021 09:28:01 GMT
Subject: RFR: 8267612;
 Declare package-private VarHandle.AccessMode/AccessType counts [v2]
In-Reply-To: <9BJzykl2dqln_UMiEmV6G-evI8QRXqJ-8mTeeJG8FiU=.d709a92e-ea5e-4ea6-989f-c43e116cea54@github.com>
References: 
 <9BJzykl2dqln_UMiEmV6G-evI8QRXqJ-8mTeeJG8FiU=.d709a92e-ea5e-4ea6-989f-c43e116cea54@github.com>
Message-ID: 

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 review

Thanks Mandy!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4164

From godin at openjdk.java.net  Tue May 25 09:32:03 2021
From: godin at openjdk.java.net (Evgeny Mandrikov)
Date: Tue, 25 May 2021 09:32:03 GMT
Subject: RFR: 8262891: Compiler implementation for Pattern Matching for
 switch (Preview) [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 17 May 2021 19:01:01 GMT, Jan Lahoda  wrote:

>> Good work. There's a lot to take in here. I think overall, it holds up well - I like how case labels have been extended to accommodate for patterns. In the front-end, I think there are some questions over the split between Attr and Flow - maybe it is unavoidable, but I'm not sure why some control-flow analysis happens in Attr instead of Flow and I left some questions to make sure I understand what's happening.
>> 
>> In the backend it's mostly good work - but overall the structure of the code, both in Lower and in TransPattern is getting very difficult to follow, given there are many different kind of switches each with its own little twist attached to it. It would be nice, I think (maybe in a separate cleanup?) if the code paths serving the different switch kinds could be made more separate, so that, when reading the code we can worry only about one possible code shape. That would make the code easier to document as well.
>
> @mcimadamore, @forax, thanks a lot for comments! I tried to apply the requested changes in recent commits (https://github.com/openjdk/jdk/pull/3863/commits/3fc2502a33cec20f39fe571eb25538ee3b459a9b https://github.com/openjdk/jdk/pull/3863/commits/aeddb85e65bf77ed62dc7fa1ad00c29646d02c99 ).
> 
> I've also tried to update the implementation for the latest spec changes here:
> https://github.com/openjdk/jdk/pull/3863/commits/54ba974e1aac00bbde1c3bd2627f01caaaeda09b
> 
> The spec changes are: total patterns are nullable; pattern matching ("new") statement switches must be complete (as switch expressions).
> 
> Any further feedback is welcome!

Hi @lahodaj  ?? ,

I tried `javac` built from this PR and for the following `Example.java`


class Example {
        void example(Object o) {
                switch (o) {
                case String s && s.length() == 0 ->
                        System.out.println("1st case");
                case String s && s.length() == 1 ->          // line 6
                        System.out.println("2nd case");      // line 7
                case String s ->                             // line 8
                        System.out.println("3rd case");      // line 9
                default ->                                   // line 10
                        System.out.println("default case");  // line 11
                }
        }
}


execution of


javac --enable-preview --release 17 Example.java
javap -v -p Example.class


produces


  void example(java.lang.Object);
    descriptor: (Ljava/lang/Object;)V
    flags: (0x0000)
    Code:
      stack=2, locals=7, args_size=2
         0: aload_1
         1: dup
         2: invokestatic  #7                  // Method java/util/Objects.requireNonNull:(Ljava/lang/Object;)Ljava/lang/Object;
         5: pop
         6: astore_2
         7: iconst_0
         8: istore_3
         9: aload_2
        10: iload_3
        11: invokedynamic #13,  0             // InvokeDynamic #0:typeSwitch:(Ljava/lang/Object;I)I
        16: tableswitch   { // 0 to 2
                       0: 44
                       1: 74
                       2: 105
                 default: 122
            }
        44: aload_2
        45: checkcast     #17                 // class java/lang/String
        48: astore        4
        50: aload         4
        52: invokevirtual #19                 // Method java/lang/String.length:()I
        55: ifeq          63
        58: iconst_1
        59: istore_3
        60: goto          9
        63: getstatic     #23                 // Field java/lang/System.out:Ljava/io/PrintStream;
        66: ldc           #29                 // String 1st case
        68: invokevirtual #31                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
        71: goto          133
        74: aload_2
        75: checkcast     #17                 // class java/lang/String
        78: astore        5
        80: aload         5
        82: invokevirtual #19                 // Method java/lang/String.length:()I
        85: iconst_1
        86: if_icmpeq     94
        89: iconst_2
        90: istore_3
        91: goto          9
        94: getstatic     #23                 // Field java/lang/System.out:Ljava/io/PrintStream;
        97: ldc           #37                 // String 2nd case
        99: invokevirtual #31                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
       102: goto          133
       105: aload_2
       106: checkcast     #17                 // class java/lang/String
       109: astore        6
       111: getstatic     #23                 // Field java/lang/System.out:Ljava/io/PrintStream;
       114: ldc           #39                 // String 3rd case
       116: invokevirtual #31                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
       119: goto          133
       122: getstatic     #23                 // Field java/lang/System.out:Ljava/io/PrintStream;
       125: ldc           #41                 // String default case
       127: invokevirtual #31                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
       130: goto          133
       133: return
      LineNumberTable:
        line 3: 0
        line 4: 44
        line 5: 63
        line 4: 71
        line 6: 74
        line 7: 94
        line 6: 102
        line 8: 105
        line 9: 111
        line 8: 119
        line 11: 122
        line 8: 130
        line 13: 133


I believe `LineNumberTable` entries `line 6: 102`, `line 8: 119` and `line 8: 130` should not be present.
Otherwise debugger misleadingly will be showing
line `6` after step from line `7`,
line `8` after step from line `9`
and even more misleadingly line `8` after step from line `11`.

This also affects [JaCoCo](https://github.com/jacoco/jacoco) Java Code Coverage tool (I'm one of its developers), which relies on LineNumberTable to provide code coverage highlighting and these entries cause misleading highlighting - partial coverage of line `8` when default case was not executed.

Should I create separate ticket about this in https://bugs.openjdk.java.net/ or this comment here is enough?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3863

From adinn at openjdk.java.net  Tue May 25 09:37:06 2021
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Tue, 25 May 2021 09:37:06 GMT
Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10,
 dexp iff 2.29 or greater on AArch64.
In-Reply-To: 
References: 
Message-ID: 

On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne  wrote:

> Glibc 2.29 onwards provides optimised versions of log,log10,exp.
> These functions have an accuracy of 0.9ulp or better in glibc
> 2.29.
> 
> Therefore this patch adds code to parse, store and check
> the runtime glibcs version in os_linux.cpp/hpp.
> This is then used to select the glibcs implementation of
> log, log10, exp at runtime for c1 and c2, iff we have
> glibc 2.29 or greater.
> 
> This will ensure OpenJDK can benefit from future improvements
> to glibc.
> 
> Glibc adheres to the ieee754 standard, unless stated otherwise
> in its spec.
> 
> As there are no stated exceptions in the current glibc spec
> for dlog, dlog10 and dexp, we can assume they currently follow
> ieee754 (which testing confirms). As such, future version of
> glibc are unlikely to lose this compliance with ieee754 in
> future.
> 
> W.r.t performance this patch sees ~15-30% performance improvements for
> log and log10, with ~50-80% performance improvements for exp for the
> common input ranged (which output real numbers). However for the NaN
> and inf output ranges we see a slow down of up to a factor of 2 for
> some functions and architectures.
> 
> Due to this being the uncommon case we assert that this is a
> worthwhile tradeoff.

> [ One thing: Java uses the term "semi-monotonic" to
> mean "whenever the mathematical function is non-decreasing, so is
> the floating-point approximation, likewise, whenever the
> mathematical function is non-increasing, so is the floating-point
> approximation." I don't really understand what distinction means. ]

I believe this is to allow for the fact that the function is continuous and the floating-point approximation is discrete.

Let F be the actual function and f the floating point approximation.  Assume we have two successive floating point values x, x'  and, without loss of generality, F(x) <= F(x'). What are the circumstances under which we require f(x) =< f(x')? Semi-monotonicity says that is only needed when F is non-decreasing on the interval [x, x']. Expressed more precisely, the condition that F is non-decreasing is

  for all y such that x =< y =< x' : F(x) <= F(y) <= F(x').

In other words:

  if the graph only ever stays level or increases across the interval [x, x'] then we must have f(x) =< f(x')

  If the graph wiggles *up* and *down* across the interval [x, x'] we can allow f(x) > f(x').

-------------

PR: https://git.openjdk.java.net/jdk/pull/3510

From github.com+28651297+mkartashev at openjdk.java.net  Tue May 25 09:45:34 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Tue, 25 May 2021 09:45:34 GMT
Subject: RFR: 8195129: System.load() fails to load from unicode paths [v2]
In-Reply-To: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com>
References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com>
Message-ID: 

> Character strings within JVM are produced and consumed in several formats. Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or dlopen()) consume strings also in UTF8. On Windows, however, the situation is far less simple: some new(er) APIs expect UTF16 (wide-character strings), some older APIs can only work with strings in a "platform" format, where not all UTF8 characters can be represented; which ones can depends on the current "code page".
> 
> This commit switches the Windows version of native library loading code to using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use of various string formats in the surrounding code. 
> 
> Namely, exception messages are made to consume strings explicitly in the UTF8 format, while logging functions (that end up using legacy Windows API) are made to consume "platform" strings in most cases. One exception is `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, which can, of course, be fixed, but was considered not worth the additional code (NB: this isn't a new bug).
> 
> The test runs in a separate JVM in order to make NIO happy about non-ASCII characters in the file name; tests are executed with LC_ALL=C and that doesn't let NIO work with non-ASCII file names even on Linux or MacOS.
> 
> Tested by running `test/hotspot/jtreg:tier1` on Linux and `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (`   jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran on those platforms as well.
> 
> Results from Linux:
> 
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg:tier1                     1784  1784     0     0   
> ==============================
> TEST SUCCESS
> 
> 
> Building target 'run-test-only' in configuration 'linux-x86_64-server-release'
> Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run:
> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode
> 
> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode'
> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java
> Test results: passed: 1
> 
> 
> Results from Windows 10:
> 
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/runtime                    746   746     0     0
> ==============================
> TEST SUCCESS
> Finished building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug'
> 
> 
> Building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug'
> Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run:
> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode
> 
> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode'
> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java
> Test results: passed: 1

Maxim Kartashev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8195129: System.load() fails to load from unicode paths

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4169/files
  - new: https://git.openjdk.java.net/jdk/pull/4169/files/265f7907..fe661dff

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4169&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4169&range=00-01

  Stats: 55 lines in 3 files changed: 24 ins; 1 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4169.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4169/head:pull/4169

PR: https://git.openjdk.java.net/jdk/pull/4169

From chegar at openjdk.java.net  Tue May 25 10:18:34 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 25 May 2021 10:18:34 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 24 May 2021 21:57:50 GMT, Roger Riggs  wrote:

>> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
>> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
>> configuration mechanisms and filter utilities.
>> 
>> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`:
>>     http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move merge and rejectUndecidedClass methods to OIF.Config
>   As default methods on OIF, their implementations were not concrete and not trustable

The conf/security/java.security file will need to be updated as part of this change. It does not have an entry for the factory property, and also its description of jdk.serialFilter will be no longer accurate - since filter set by jdk.serialFilter may no longer have any impact on OIS, if a filter factory is specified as either a system property or security property.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996

From pconcannon at openjdk.java.net  Tue May 25 10:36:00 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 25 May 2021 10:36:00 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v3]
In-Reply-To: <78LopXMnM-8NJkcJRbMIcJFSzAEpOvyOXuhA_4vr9gg=.3a1ed69b-99e0-4a0a-912f-57a861decd2d@github.com>
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
 <78LopXMnM-8NJkcJRbMIcJFSzAEpOvyOXuhA_4vr9gg=.3a1ed69b-99e0-4a0a-912f-57a861decd2d@github.com>
Message-ID: 

On Tue, 25 May 2021 06:01:49 GMT, Tagir F. Valeev  wrote:

>> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
>> 
>> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Indent some lines to make GitHub diff happier

src/java.base/share/classes/java/util/GregorianCalendar.java line 1730:

> 1728:         int value = -1;
> 1729:         switch (field) {
> 1730:             case MONTH -> {

HI @amaembo, thanks for taking a look at this.

I think you should be careful here, and ask is introducing the enchanced switch adding any value? While I think the enchanced switch can be valuable when it makes the code more readable, it shouldn't be introduced just for the sake of using it.

src/java.base/share/classes/java/util/PropertyPermission.java line 337:

> 335:      */
> 336:     static String getActions(int mask) {
> 337:         return switch (mask & (READ | WRITE)) {

Just a suggestion, but it might be more readable if you align the lambda operators

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161

From tvaleev at openjdk.java.net  Tue May 25 11:39:45 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Tue, 25 May 2021 11:39:45 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v3]
In-Reply-To: 
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
 <78LopXMnM-8NJkcJRbMIcJFSzAEpOvyOXuhA_4vr9gg=.3a1ed69b-99e0-4a0a-912f-57a861decd2d@github.com>
 
Message-ID: 

On Tue, 25 May 2021 10:31:33 GMT, Patrick Concannon  wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Indent some lines to make GitHub diff happier
>
> src/java.base/share/classes/java/util/GregorianCalendar.java line 1730:
> 
>> 1728:         int value = -1;
>> 1729:         switch (field) {
>> 1730:             case MONTH -> {
> 
> HI @amaembo, thanks for taking a look at this.
> 
> I think you should be careful here, and ask is introducing the enchanced switch adding any value? While I think the enchanced switch can be valuable when it makes the code more readable, it shouldn't be introduced just for the sake of using it.

@pconcannon thank you for review!

In this particular place, it makes the code more better in the following points:
- It removes `break;` operators at the end of each branch, which add nothing but a visual noise
- It makes the whole switch shorter by 22 lines
- Using `->` syntax clearly states that no branch in this switch has a fall-through behavior, so the code reader should not check every branch to ensure this. Just see very first `->` and you already know that no fallthrough is here.
- In case if new branches will appear in the future, the new-style switch will protect future maintainers from accidental fall-through, an error that often happens with old-style switches.

> src/java.base/share/classes/java/util/PropertyPermission.java line 337:
> 
>> 335:      */
>> 336:     static String getActions(int mask) {
>> 337:         return switch (mask & (READ | WRITE)) {
> 
> Just a suggestion, but it might be more readable if you align the lambda operators

Thank you for pointing to this. Actually, I just noticed that there was some kind of vertical alignment before my change. I added vertical alignment for single-line switch rules.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161

From tvaleev at openjdk.java.net  Tue May 25 11:39:02 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Tue, 25 May 2021 11:39:02 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v4]
In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
Message-ID: 

> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
> 
> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Vertical alignment for single-line switch rules

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4161/files
  - new: https://git.openjdk.java.net/jdk/pull/4161/files/07a998bc..82f40605

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=02-03

  Stats: 54 lines in 10 files changed: 2 ins; 0 del; 52 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4161.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161

PR: https://git.openjdk.java.net/jdk/pull/4161

From chegar at openjdk.java.net  Tue May 25 11:40:23 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 25 May 2021 11:40:23 GMT
Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters
 [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 24 May 2021 21:57:50 GMT, Roger Riggs  wrote:

>> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
>> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
>> configuration mechanisms and filter utilities.
>> 
>> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`:
>>     http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move merge and rejectUndecidedClass methods to OIF.Config
>   As default methods on OIF, their implementations were not concrete and not trustable

src/java.base/share/classes/java/io/ObjectInputFilter.java line 73:

> 71:  *     var filter = ObjectInputFilter.Config.createFilter("example.*;java.base/*;!*")
> 72:  *     ObjectInputFilter.Config.setSerialFilter(filter);
> 73:  * }
    • It's good to have a straightforward example, but it has an implicit assumption - that the built-in filter factory is in operation ( and will not change ). I wonder if there is a way to update the example (without too much fuss), or otherwise add a textual qualification. Though, I'm not sure what this would look like. src/java.base/share/classes/java/io/ObjectInputFilter.java line 400: > 398: * {@link BinaryOperator {@literal BinaryOperator}} interface, provide its implementation and > 399: * be accessible via the {@linkplain ClassLoader#getSystemClassLoader() application class loader}. > 400: * The filter factory configured using the system or security property during initialization What is the expected behaviour if the factory property is to set to a non-class or non-accessible class? The current implementation does (it probably should be more graceful) : $ java -Djdk.serialFilterFactory=allow T Exception in thread "main" java.lang.ExceptionInInitializerError at java.base/java.io.ObjectInputFilter$Config.(ObjectInputFilter.java:537) at java.base/java.io.ObjectInputStream.(ObjectInputStream.java:394) at T.main(T.java:5) Caused by: java.lang.ClassNotFoundException: allow at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:636) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:182) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519) at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Class.java:466) at java.base/java.io.ObjectInputFilter$Config.(ObjectInputFilter.java:519) ... 2 more ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From github.com+10835776+stsypanov at openjdk.java.net Tue May 25 11:42:41 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 25 May 2021 11:42:41 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList [v2] In-Reply-To: References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: On Fri, 21 May 2021 23:16:57 GMT, Maurizio Cimadamore wrote: >> I don't remember all the comments you have received in this thread but have you verified that arbitrarily changing `LinkedList` into `ArrayList` in these classes is not going to significantly increase the footprint in the case where lists are empty or contain only one or two elements? >> >> I am not convinced that a global replacement of `LinkedList` by `ArrayList` is necessarily good - even though I agree that `ArrayList` is generally more efficient. > > I second the footprint concerns from @dfuch. I've seen with first hand cases where widespread uses of array lists for holding 1-2-3 elements (e.g. think of a graph where each node might only have a very small number of outgoing edges) lead to massive memory over-utilization. If the average size is known, at the very least I'd argue to replace with an array list which is sized correctly. > > And, all this said, the general assumption implied in this PR which linked lists are just to be avoided doesn't match my experience. If you want a "pay only as much memory as you use" data structure, you don't care about random access (e.g. all accesses are linear walks), a linked list is a perfectly fine choice. If there are use cases in the JDK where a LinkedList is used in places where it shouldn't be, then obviously _those cases_ should be replaced. Hi @mcimadamore, @dfuch after your review comments I've decided to do a deeper investigation for this. First, I've decided to check whether empty `LinkedList` is going to have smaller footprint (this could be fruitful for cases when the list is likely to remain empty in vast majority of cases, see e.g. `URLClassPath.closeLoaders()`), and apparently it isn't: @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class EmptyListBenchmark { @Benchmark public Object emptyArrayList() { return new ArrayList<>(); } @Benchmark public Object emptyLinkedList() { return new LinkedList<>(); } } This benchmark with my ad-hoc JDK build yields the following results: Benchmark Mode Cnt Score Error Units EmptyListBenchmark.emptyArrayList avgt 20 4.605 ? 0.463 ns/op EmptyListBenchmark.emptyArrayList:?gc.alloc.rate.norm avgt 20 24.002 ? 0.001 B/op EmptyListBenchmark.emptyLinkedList avgt 20 4.324 ? 0.081 ns/op EmptyListBenchmark.emptyLinkedList:?gc.alloc.rate.norm avgt 20 32.002 ? 0.001 B/op After JDK-8011200 `ArrayList` instantiated with default constructor doesn't allocate underlying array any more. However the things get more complicated when the list gets populated: @State(Scope.Thread) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class NonEmptyListBenchmark { @Param({"1", "2", "3", "4", "5"}) private int size; @Benchmark public Object arrayList() { var list = new ArrayList<>(); for (int i = 0; i < size; i++) { list.add(i); } return list; } @Benchmark public Object linkedList() { var list = new LinkedList(); for (int i = 0; i < size; i++) { list.add(i); } return list; } } Here indeed `ArrayList` looses in memory comapring to `LinkedList` in single-item case: arrayList:?gc.alloc.rate.norm 1 avgt 40 80.005 ? 0.001 B/op arrayList:?gc.alloc.rate.norm 2 avgt 40 80.006 ? 0.001 B/op arrayList:?gc.alloc.rate.norm 3 avgt 40 80.007 ? 0.001 B/op arrayList:?gc.alloc.rate.norm 4 avgt 40 80.008 ? 0.001 B/op arrayList:?gc.alloc.rate.norm 5 avgt 40 80.008 ? 0.001 B/op linkedList:?gc.alloc.rate.norm 1 avgt 40 56.004 ? 0.001 B/op linkedList:?gc.alloc.rate.norm 2 avgt 40 80.005 ? 0.001 B/op linkedList:?gc.alloc.rate.norm 3 avgt 40 104.007 ? 0.001 B/op linkedList:?gc.alloc.rate.norm 4 avgt 40 128.009 ? 0.001 B/op linkedList:?gc.alloc.rate.norm 5 avgt 40 152.010 ? 0.001 B/op And indeed there's at least one usecase in affected files where this is real-life scenario - `JarIndex`. Below on screenshot I run Spring Boot tests with Gradle: ![image](https://d.radikal.ru/d26/2105/d0/a5d588f282e6.png) However, for the same scenario one node represented with `LinkedList` can hold dozens of items: ![image](https://c.radikal.ru/c38/2105/da/80e6a78cec08.png) To fix this I propose to instantiate `ArrayList` with initial size = 1: @Benchmark public Object arrayList_sized() { var list = new ArrayList<>(1); list.add(new Object()); return list; } This reduces the footprint of a list with 1 element down to 48 bytes: arrayList_sized:?gc.alloc.rate.norm 1 avgt 40 48.004 ? 0.001 B/op ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 From forax at univ-mlv.fr Tue May 25 11:42:52 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 25 May 2021 13:42:52 +0200 (CEST) Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: <2070914630.587750.1621942972319.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Evgeny Mandrikov" > ?: "build-dev" , "compiler-dev" , "core-libs-dev" > , "javadoc-dev" > Envoy?: Mardi 25 Mai 2021 11:32:03 > Objet: Re: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] > On Mon, 17 May 2021 19:01:01 GMT, Jan Lahoda wrote: > >>> Good work. There's a lot to take in here. I think overall, it holds up well - I >>> like how case labels have been extended to accommodate for patterns. In the >>> front-end, I think there are some questions over the split between Attr and >>> Flow - maybe it is unavoidable, but I'm not sure why some control-flow analysis >>> happens in Attr instead of Flow and I left some questions to make sure I >>> understand what's happening. >>> >>> In the backend it's mostly good work - but overall the structure of the code, >>> both in Lower and in TransPattern is getting very difficult to follow, given >>> there are many different kind of switches each with its own little twist >>> attached to it. It would be nice, I think (maybe in a separate cleanup?) if the >>> code paths serving the different switch kinds could be made more separate, so >>> that, when reading the code we can worry only about one possible code shape. >>> That would make the code easier to document as well. >> >> @mcimadamore, @forax, thanks a lot for comments! I tried to apply the requested >> changes in recent commits >> (https://github.com/openjdk/jdk/pull/3863/commits/3fc2502a33cec20f39fe571eb25538ee3b459a9b >> https://github.com/openjdk/jdk/pull/3863/commits/aeddb85e65bf77ed62dc7fa1ad00c29646d02c99 >> ). >> >> I've also tried to update the implementation for the latest spec changes here: >> https://github.com/openjdk/jdk/pull/3863/commits/54ba974e1aac00bbde1c3bd2627f01caaaeda09b >> >> The spec changes are: total patterns are nullable; pattern matching ("new") >> statement switches must be complete (as switch expressions). >> >> Any further feedback is welcome! > > Hi @lahodaj ?? , > > I tried `javac` built from this PR and for the following `Example.java` > > > class Example { > void example(Object o) { > switch (o) { > case String s && s.length() == 0 -> > System.out.println("1st case"); > case String s && s.length() == 1 -> // line 6 > System.out.println("2nd case"); // line 7 > case String s -> // line 8 > System.out.println("3rd case"); // line 9 > default -> // line 10 > System.out.println("default case"); // line 11 > } > } > } > > > execution of > > > javac --enable-preview --release 17 Example.java > javap -v -p Example.class > > > produces > > > void example(java.lang.Object); > descriptor: (Ljava/lang/Object;)V > flags: (0x0000) > Code: > stack=2, locals=7, args_size=2 > 0: aload_1 > 1: dup > 2: invokestatic #7 // Method > java/util/Objects.requireNonNull:(Ljava/lang/Object;)Ljava/lang/Object; > 5: pop > 6: astore_2 > 7: iconst_0 > 8: istore_3 > 9: aload_2 > 10: iload_3 > 11: invokedynamic #13, 0 // InvokeDynamic > #0:typeSwitch:(Ljava/lang/Object;I)I > 16: tableswitch { // 0 to 2 > 0: 44 > 1: 74 > 2: 105 > default: 122 > } > 44: aload_2 > 45: checkcast #17 // class java/lang/String > 48: astore 4 > 50: aload 4 > 52: invokevirtual #19 // Method java/lang/String.length:()I > 55: ifeq 63 > 58: iconst_1 > 59: istore_3 > 60: goto 9 > 63: getstatic #23 // Field > java/lang/System.out:Ljava/io/PrintStream; > 66: ldc #29 // String 1st case > 68: invokevirtual #31 // Method > java/io/PrintStream.println:(Ljava/lang/String;)V > 71: goto 133 > 74: aload_2 > 75: checkcast #17 // class java/lang/String > 78: astore 5 > 80: aload 5 > 82: invokevirtual #19 // Method java/lang/String.length:()I > 85: iconst_1 > 86: if_icmpeq 94 > 89: iconst_2 > 90: istore_3 > 91: goto 9 > 94: getstatic #23 // Field > java/lang/System.out:Ljava/io/PrintStream; > 97: ldc #37 // String 2nd case > 99: invokevirtual #31 // Method > java/io/PrintStream.println:(Ljava/lang/String;)V > 102: goto 133 > 105: aload_2 > 106: checkcast #17 // class java/lang/String > 109: astore 6 > 111: getstatic #23 // Field > java/lang/System.out:Ljava/io/PrintStream; > 114: ldc #39 // String 3rd case > 116: invokevirtual #31 // Method > java/io/PrintStream.println:(Ljava/lang/String;)V > 119: goto 133 > 122: getstatic #23 // Field > java/lang/System.out:Ljava/io/PrintStream; > 125: ldc #41 // String default case > 127: invokevirtual #31 // Method > java/io/PrintStream.println:(Ljava/lang/String;)V > 130: goto 133 > 133: return > LineNumberTable: > line 3: 0 > line 4: 44 > line 5: 63 > line 4: 71 > line 6: 74 > line 7: 94 > line 6: 102 > line 8: 105 > line 9: 111 > line 8: 119 > line 11: 122 > line 8: 130 > line 13: 133 > > > I believe `LineNumberTable` entries `line 6: 102`, `line 8: 119` and `line 8: > 130` should not be present. > Otherwise debugger misleadingly will be showing > line `6` after step from line `7`, > line `8` after step from line `9` > and even more misleadingly line `8` after step from line `11`. > > This also affects [JaCoCo](https://github.com/jacoco/jacoco) Java Code Coverage > tool (I'm one of its developers), which relies on LineNumberTable to provide > code coverage highlighting and these entries cause misleading highlighting - > partial coverage of line `8` when default case was not executed. > > Should I create separate ticket about this in https://bugs.openjdk.java.net/ or > this comment here is enough? Also why invokedynamic take a constant int as second argument ? > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3863 R?mi From tvaleev at openjdk.java.net Tue May 25 11:49:18 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Tue, 25 May 2021 11:49:18 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v5] In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: > Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. > > I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: More vertical alignment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4161/files - new: https://git.openjdk.java.net/jdk/pull/4161/files/82f40605..f4ad5f14 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4161.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161 PR: https://git.openjdk.java.net/jdk/pull/4161 From redestad at openjdk.java.net Tue May 25 11:51:30 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 25 May 2021 11:51:30 GMT Subject: Integrated: 8267612; Declare package-private VarHandle.AccessMode/AccessType counts In-Reply-To: References: Message-ID: <21oYW32_9N0V1V3OJKDUYxFLQY_uFo0vjdjp35ggA7U=.cf6a761c-d9ff-48d0-9fa3-69b1ba7f4488@github.com> 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 This pull request has now been integrated. Changeset: 66b190e1 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/66b190e1e7d06f3fc59917b5346e94a128e928cd Stats: 18 lines in 4 files changed: 8 ins; 2 del; 8 mod 8267612: Declare package-private VarHandle.AccessMode/AccessType counts Reviewed-by: mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/4164 From pconcannon at openjdk.java.net Tue May 25 11:57:26 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Tue, 25 May 2021 11:57:26 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions Message-ID: Hi, Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? Kind regards, Patrick ------------- Commit messages: - 8267670: Update java.io, java.math, and java.text to use switch expressions Changes: https://git.openjdk.java.net/jdk/pull/4182/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267670 Stats: 328 lines in 11 files changed: 1 ins; 187 del; 140 mod Patch: https://git.openjdk.java.net/jdk/pull/4182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4182/head:pull/4182 PR: https://git.openjdk.java.net/jdk/pull/4182 From github.com+10835776+stsypanov at openjdk.java.net Tue May 25 12:03:29 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 25 May 2021 12:03:29 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList [v3] In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: > The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective. > > jdk:tier1 and jdk:tier2 are both ok ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8263561: Use sized constructor where reasonable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2744/files - new: https://git.openjdk.java.net/jdk/pull/2744/files/158006c6..40910fae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=01-02 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2744/head:pull/2744 PR: https://git.openjdk.java.net/jdk/pull/2744 From herrick at openjdk.java.net Tue May 25 12:16:54 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 25 May 2021 12:16:54 GMT Subject: RFR: 8267403: tools/jpackage/share/FileAssociationsTest.java#id0 failed with "Error: Bundler "Mac PKG Package" (pkg) failed to produce a package" In-Reply-To: References: Message-ID: <_w0MM4xwBWc7NfWZm0fBd4L729fg2y-jGhvgszVnlVQ=.8ad6005f-4d8d-495b-8092-b8596b284010@github.com> On Fri, 21 May 2021 04:34:22 GMT, Alexander Matveev wrote: > Looks like another issue similar to hdiutil (JDK-8249395) when process is gone, but we still waiting for it. I was not able to reproduce this issue by running test or pkgbuild separately and conclusion was made based on logs. Fixed in same way as hdiutil issue. Also, I added logging PID for external commands to simplify log analysis. Log will have multiple hdiutil and/or pkgbuild processes, since we running multiple tests in parallel and matching external process to test failure requires looking at command line for particular process, so PID should simplify this. Please update the bug report to contain the evaluation you have here in the PR ------------- Marked as reviewed by herrick (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4139 From jlahoda at openjdk.java.net Tue May 25 12:22:56 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 25 May 2021 12:22:56 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 08:00:12 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/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Fixing various error-related bugs. Thanks Evgeny, I'll take a look. @forax, do you mean why there is "0" in: 11: invokedynamic #13, 0 ? The "0" is an artifact of how invokedynamic is represented in the classfile (invokedynamic, 2 bytes of constant pool reference, byte 0, byte 0) - javap shows the value of the first zero byte. That is probably not needed anymore, but there is nothing special in this patch, I think - all invokedynamic calls look like this, AFAIK. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From chegar at openjdk.java.net Tue May 25 12:34:55 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 25 May 2021 12:34:55 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions In-Reply-To: References: Message-ID: <3RO89K_OHLuQJPiDTPNMTppqvW2W_U1OeQWEwJvn56U=.c3331ce0-4617-40f9-b542-adeaf9c007b6@github.com> On Tue, 25 May 2021 09:37:58 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick src/java.base/share/classes/java/io/ObjectInputStream.java line 1877: > 1875: descriptor.checkInitialized(); > 1876: } > 1877: default -> throw new StreamCorruptedException( What would you think of assigning descriptor with the value returned from evaluating the switch? Either: 1) ObjectStreamClass descriptor = switch (tc) { case TC_NULL -> (ObjectStreamClass) readNull(); case TC_PROXYCLASSDESC -> readProxyDesc(unshared); case TC_CLASSDESC -> readNonProxyDesc(unshared); case TC_REFERENCE -> readAndCheckHandle(unshared); default -> throw new StreamCorruptedException(String.format("invalid type code: %02X", tc)); }; return descriptor; } , where the body of TC_REFERENCE is enclosed in readAndCheckHandle, OR 2) Simply case TC_REFERENCE -> { var d = (ObjectStreamClass)readHandle(unshared); // Should only reference initialized class descriptors d.checkInitialized(); yield d; } ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From naoto at openjdk.java.net Tue May 25 12:47:11 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 25 May 2021 12:47:11 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions In-Reply-To: References: Message-ID: On Tue, 25 May 2021 09:37:58 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick src/java.base/share/classes/java/text/BreakIterator.java line 569: > 567: case SENTENCE_INDEX -> breakIteratorProvider.getSentenceInstance(locale); > 568: default -> null; > 569: }; No need to use the local variable `iterator` here. Simply return with the switch expression. src/java.base/share/classes/java/text/NumberFormat.java line 982: > 980: case COMPACTSTYLE -> provider.getCompactNumberInstance(locale, formatStyle); > 981: default -> null; > 982: }; Same as `BreakIterator`. No need for `numberFormat`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From chegar at openjdk.java.net Tue May 25 13:00:01 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 25 May 2021 13:00:01 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions In-Reply-To: References: Message-ID: <-mfOzgikw-2iSXIjdLfI0bOEzgYLYNjzVXG2IzkiMNE=.c8c8c32c-5959-4d74-b691-e5d7cf816685@github.com> On Tue, 25 May 2021 09:37:58 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick src/java.base/share/classes/java/io/StreamTokenizer.java line 795: > 793: * case statements > 794: */ > 795: if (ttype < 256 && ((ctype[ttype] & CT_QUOTE) != 0)) { Maybe (since its easier to grok the yield rather than the assignment of ret in branches): String ret = switch (ttype) { case TT_EOF -> "EOF"; case TT_EOL -> "EOL"; case TT_WORD -> sval; case TT_NUMBER -> "n=" + nval; case TT_NOTHING -> "NOTHING"; default -> { /* * ttype is the first character of either a quoted string or * is an ordinary character. ttype can definitely not be less * than 0, since those are reserved values used in the previous * case statements */ if (ttype < 256 && ((ctype[ttype] & CT_QUOTE) != 0)) { yield sval; } char s[] = new char[3]; s[0] = s[2] = '''; s[1] = (char) ttype; yield new String(s); } }; return "Token[" + ret + "], line " + LINENO; ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From dfuchs at openjdk.java.net Tue May 25 13:22:03 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 25 May 2021 13:22:03 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions In-Reply-To: References: Message-ID: <_wJ--fj6N1Y1wzr5ql_b4zhbSn2r7vn8VQjeezLgnkU=.01cb0252-68cd-4099-abf6-e43659539861@github.com> On Tue, 25 May 2021 09:37:58 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick src/java.base/share/classes/java/io/ObjectStreamField.java line 123: > 121: case 'D' -> type = Double.TYPE; > 122: case 'L', '[' -> type = Object.class; > 123: default -> throw new IllegalArgumentException("illegal signature"); Why not assign type here? type = switch(signature.charAt(0)) { case 'Z' -> Boolean.TYPE; .... ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From github.com+10835776+stsypanov at openjdk.java.net Tue May 25 13:44:14 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 25 May 2021 13:44:14 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList [v4] In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: <8QDoLOsBNG7VYDd7ryDVkNTHt9Z-T9QeZ2ll0bWGonQ=.0335a58a-744f-4acc-a226-6c3abbc14914@github.com> > The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective. > > jdk:tier1 and jdk:tier2 are both ok ?????? ??????? 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 five additional commits since the last revision: - Merge branch 'master' into purge-linked-list - 8263561: Use sized constructor where reasonable - 8263561: Use interface List instead of particular type where possible - 8263561: Rename requestList -> requests - 8263561: Re-examine uses of LinkedList ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2744/files - new: https://git.openjdk.java.net/jdk/pull/2744/files/40910fae..89160b3e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=02-03 Stats: 763526 lines in 11131 files changed: 166175 ins; 560683 del; 36668 mod Patch: https://git.openjdk.java.net/jdk/pull/2744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2744/head:pull/2744 PR: https://git.openjdk.java.net/jdk/pull/2744 From forax at openjdk.java.net Tue May 25 14:16:59 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Tue, 25 May 2021 14:16:59 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 12:20:02 GMT, Jan Lahoda wrote: > Thanks Evgeny, I'll take a look. > > @forax, do you mean why there is "0" in: > 11: invokedynamic #13, 0 > ? Not this one, the one on the stack. 7: iconst_0 <---- this zero 8: istore_3 9: aload_2 10: iload_3 11: invokedynamic #13, 0 // InvokeDynamic #0:typeSwitch:(Ljava/lang/Object;I)I Why the descriptor is (Ljava/lang/Object;I)I instead of (Ljava/lang/Object;)I, what is the semantics associated to that integer ? > The "0" is an artifact of how invokedynamic is represented in the classfile (invokedynamic, 2 bytes of constant pool reference, byte 0, byte 0) - javap shows the value of the first zero byte. That is probably not needed anymore, but there is nothing special in this patch, I think - all invokedynamic calls look like this, AFAIK. I know that a little to well, i'm one of the guys behind the design of indy :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Tue May 25 14:25:03 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 25 May 2021 14:25:03 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 14:13:55 GMT, R?mi Forax wrote: > > Thanks Evgeny, I'll take a look. > > @forax, do you mean why there is "0" in: > > 11: invokedynamic #13, 0 > > ? > > Not this one, the one on the stack. > > 7: iconst_0 <---- this zero > 8: istore_3 > 9: aload_2 > 10: iload_3 > 11: invokedynamic #13, 0 // InvokeDynamic > #0:typeSwitch:(Ljava/lang/Object;I)I > > Why the descriptor is (Ljava/lang/Object;I)I instead of (Ljava/lang/Object;)I, > what is the semantics associated to that integer ? The reason for this integer (which is not a constant in the case of this switch) is to restart the matching in case guards fail to "match". Considering the example here: class Example { void example(Object o) { switch (o) { case String s && s.length() == 0 -> System.out.println("1st case"); case String s && s.length() == 1 -> // line 6 System.out.println("2nd case"); // line 7 case String s -> // line 8 System.out.println("3rd case"); // line 9 default -> // line 10 System.out.println("default case"); // line 11 } } } If `o` is `String`, then the first call to indy will be `indy[...](o, 0)`, returning `0`. Then the guard will be evaluated `s.length() == 0`. If the length is not zero, the local variable 3 will be reassigned to `1`(bytecode index 58, 59) and the whole switch is restarted - just this time, the matching in the indy will start at index `1`, not `0`, i.e. `indy[...](o, 1)`. And so on. I believe there is a text explaining the meaning of the parameter in the javadoc of the bootstrap, and in TransPatterns in javac. > > > The "0" is an artifact of how invokedynamic is represented in the classfile (invokedynamic, 2 bytes of constant pool reference, byte 0, byte 0) - javap shows the value of the first zero byte. That is probably not needed anymore, but there is nothing special in this patch, I think - all invokedynamic calls look like this, AFAIK. > > I know that a little to well, i'm one of the guys behind the design of indy :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From godin at openjdk.java.net Tue May 25 14:25:02 2021 From: godin at openjdk.java.net (Evgeny Mandrikov) Date: Tue, 25 May 2021 14:25:02 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 14:13:55 GMT, R?mi Forax wrote: > 7: iconst_0 <---- this zero @forax as far as I understood this will be a value of parameter `startIndex` in `java.lang.runtime. SwitchBootstraps.doSwitch` ?? Please correct me @lahodaj if I'm wrong. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From aph at redhat.com Tue May 25 14:41:38 2021 From: aph at redhat.com (Andrew Haley) Date: Tue, 25 May 2021 15:41:38 +0100 Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64. In-Reply-To: <0JcCtbFlWgnepu7qnSZXuPeupgsPfvvOR20Az_2dJSQ=.a365b573-0b5b-4358-a834-44db59128b0d@github.com> References: <0JcCtbFlWgnepu7qnSZXuPeupgsPfvvOR20Az_2dJSQ=.a365b573-0b5b-4358-a834-44db59128b0d@github.com> Message-ID: <9ccc4cea-29b1-4dc6-2b58-f9f8c4eaee3c@redhat.com> Greg, what's your email address? Everything I try bounces. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From pconcannon at openjdk.java.net Tue May 25 14:57:22 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Tue, 25 May 2021 14:57:22 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v2] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon 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 three additional commits since the last revision: - 8267670: Updated code to use yield - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Update java.io, java.math, and java.text to use switch expressions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4182/files - new: https://git.openjdk.java.net/jdk/pull/4182/files/b98e47db..adc8af41 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=00-01 Stats: 143 lines in 16 files changed: 28 ins; 56 del; 59 mod Patch: https://git.openjdk.java.net/jdk/pull/4182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4182/head:pull/4182 PR: https://git.openjdk.java.net/jdk/pull/4182 From pconcannon at openjdk.java.net Tue May 25 14:57:24 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Tue, 25 May 2021 14:57:24 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v2] In-Reply-To: <3RO89K_OHLuQJPiDTPNMTppqvW2W_U1OeQWEwJvn56U=.c3331ce0-4617-40f9-b542-adeaf9c007b6@github.com> References: <3RO89K_OHLuQJPiDTPNMTppqvW2W_U1OeQWEwJvn56U=.c3331ce0-4617-40f9-b542-adeaf9c007b6@github.com> Message-ID: On Tue, 25 May 2021 12:31:38 GMT, Chris Hegarty wrote: >> Patrick Concannon 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 three additional commits since the last revision: >> >> - 8267670: Updated code to use yield >> - Merge remote-tracking branch 'origin/master' into JDK-8267670 >> - 8267670: Update java.io, java.math, and java.text to use switch expressions > > src/java.base/share/classes/java/io/ObjectInputStream.java line 1877: > >> 1875: descriptor.checkInitialized(); >> 1876: } >> 1877: default -> throw new StreamCorruptedException( > > What would you think of assigning descriptor with the value returned from evaluating the switch? > > Either: > > 1) > > ObjectStreamClass descriptor = switch (tc) { > case TC_NULL -> (ObjectStreamClass) readNull(); > case TC_PROXYCLASSDESC -> readProxyDesc(unshared); > case TC_CLASSDESC -> readNonProxyDesc(unshared); > case TC_REFERENCE -> readAndCheckHandle(unshared); > default -> throw new StreamCorruptedException(String.format("invalid type code: %02X", tc)); > }; > return descriptor; > } > > , where the body of TC_REFERENCE is enclosed in readAndCheckHandle, OR > > 2) Simply > > case TC_REFERENCE -> { > var d = (ObjectStreamClass)readHandle(unshared); > // Should only reference initialized class descriptors > d.checkInitialized(); > yield d; } Code updated as suggested. See adc8af4 > src/java.base/share/classes/java/io/StreamTokenizer.java line 795: > >> 793: * case statements >> 794: */ >> 795: if (ttype < 256 && ((ctype[ttype] & CT_QUOTE) != 0)) { > > Maybe (since its easier to grok the yield rather than the assignment of ret in branches): > > String ret = switch (ttype) { > case TT_EOF -> "EOF"; > case TT_EOL -> "EOL"; > case TT_WORD -> sval; > case TT_NUMBER -> "n=" + nval; > case TT_NOTHING -> "NOTHING"; > default -> { > /* > * ttype is the first character of either a quoted string or > * is an ordinary character. ttype can definitely not be less > * than 0, since those are reserved values used in the previous > * case statements > */ > if (ttype < 256 && ((ctype[ttype] & CT_QUOTE) != 0)) { > yield sval; > } > char s[] = new char[3]; > s[0] = s[2] = '''; > s[1] = (char) ttype; > yield new String(s); > } > }; > return "Token[" + ret + "], line " + LINENO; Code updated as suggested. See adc8af4 ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From pconcannon at openjdk.java.net Tue May 25 14:57:26 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Tue, 25 May 2021 14:57:26 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v2] In-Reply-To: <_wJ--fj6N1Y1wzr5ql_b4zhbSn2r7vn8VQjeezLgnkU=.01cb0252-68cd-4099-abf6-e43659539861@github.com> References: <_wJ--fj6N1Y1wzr5ql_b4zhbSn2r7vn8VQjeezLgnkU=.01cb0252-68cd-4099-abf6-e43659539861@github.com> Message-ID: On Tue, 25 May 2021 13:16:00 GMT, Daniel Fuchs wrote: >> Patrick Concannon 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 three additional commits since the last revision: >> >> - 8267670: Updated code to use yield >> - Merge remote-tracking branch 'origin/master' into JDK-8267670 >> - 8267670: Update java.io, java.math, and java.text to use switch expressions > > src/java.base/share/classes/java/io/ObjectStreamField.java line 123: > >> 121: case 'D' -> type = Double.TYPE; >> 122: case 'L', '[' -> type = Object.class; >> 123: default -> throw new IllegalArgumentException("illegal signature"); > > Why not assign type here? > > > type = switch(signature.charAt(0)) { > case 'Z' -> Boolean.TYPE; > .... Thanks for your suggestion. I've done that now. See adc8af4 ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From pconcannon at openjdk.java.net Tue May 25 14:57:28 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Tue, 25 May 2021 14:57:28 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v2] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 12:43:00 GMT, Naoto Sato wrote: >> Patrick Concannon 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 three additional commits since the last revision: >> >> - 8267670: Updated code to use yield >> - Merge remote-tracking branch 'origin/master' into JDK-8267670 >> - 8267670: Update java.io, java.math, and java.text to use switch expressions > > src/java.base/share/classes/java/text/BreakIterator.java line 569: > >> 567: case SENTENCE_INDEX -> breakIteratorProvider.getSentenceInstance(locale); >> 568: default -> null; >> 569: }; > > No need to use the local variable `iterator` here. Simply return with the switch expression. Hi Naoto, thanks for spotting this. Code updated as suggested. See adc8af4 > src/java.base/share/classes/java/text/NumberFormat.java line 982: > >> 980: case COMPACTSTYLE -> provider.getCompactNumberInstance(locale, formatStyle); >> 981: default -> null; >> 982: }; > > Same as `BreakIterator`. No need for `numberFormat`. Code updated as suggested. See adc8af4 ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From chegar at openjdk.java.net Tue May 25 15:22:59 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 25 May 2021 15:22:59 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v2] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 14:57:22 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon 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 three additional commits since the last revision: > > - 8267670: Updated code to use yield > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Update java.io, java.math, and java.text to use switch expressions src/java.base/share/classes/java/io/ObjectStreamClass.java line 2172: > 2170: switch (typeCodes[i]) { > 2171: case 'L', '[' -> vals[offsets[i]] = unsafe.getReference(obj, readKeys[i]); > 2172: default -> throw new InternalError(); suggest: vals[offsets[i]] = switch (typeCodes[i]) { case 'L', '[' -> unsafe.getReference(obj, readKeys[i]); default -> throw new InternalError(); src/java.base/share/classes/java/io/StreamTokenizer.java line 787: > 785: case TT_WORD -> ret = sval; > 786: case TT_NUMBER -> ret = "n=" + nval; > 787: case TT_NOTHING -> ret = "NOTHING"; This is not correct, the assignments to ret in these case arms is redundant. ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From chegar at openjdk.java.net Tue May 25 15:26:56 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 25 May 2021 15:26:56 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v2] In-Reply-To: References: <3RO89K_OHLuQJPiDTPNMTppqvW2W_U1OeQWEwJvn56U=.c3331ce0-4617-40f9-b542-adeaf9c007b6@github.com> Message-ID: On Tue, 25 May 2021 14:53:44 GMT, Patrick Concannon wrote: >> src/java.base/share/classes/java/io/StreamTokenizer.java line 795: >> >>> 793: * case statements >>> 794: */ >>> 795: if (ttype < 256 && ((ctype[ttype] & CT_QUOTE) != 0)) { >> >> Maybe (since its easier to grok the yield rather than the assignment of ret in branches): >> >> String ret = switch (ttype) { >> case TT_EOF -> "EOF"; >> case TT_EOL -> "EOL"; >> case TT_WORD -> sval; >> case TT_NUMBER -> "n=" + nval; >> case TT_NOTHING -> "NOTHING"; >> default -> { >> /* >> * ttype is the first character of either a quoted string or >> * is an ordinary character. ttype can definitely not be less >> * than 0, since those are reserved values used in the previous >> * case statements >> */ >> if (ttype < 256 && ((ctype[ttype] & CT_QUOTE) != 0)) { >> yield sval; >> } >> char s[] = new char[3]; >> s[0] = s[2] = '''; >> s[1] = (char) ttype; >> yield new String(s); >> } >> }; >> return "Token[" + ret + "], line " + LINENO; > > Code updated as suggested. See adc8af4 The snippet above both uses yield in the default case, and also removes the assignments from the other arms. adc8af4 overlooks the redundant assignments in the non-default cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From github.com+73799211+gregcawthorne at openjdk.java.net Tue May 25 15:35:57 2021 From: github.com+73799211+gregcawthorne at openjdk.java.net (gregcawthorne) Date: Tue, 25 May 2021 15:35:57 GMT Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64. In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne wrote: > Glibc 2.29 onwards provides optimised versions of log,log10,exp. > These functions have an accuracy of 0.9ulp or better in glibc > 2.29. > > Therefore this patch adds code to parse, store and check > the runtime glibcs version in os_linux.cpp/hpp. > This is then used to select the glibcs implementation of > log, log10, exp at runtime for c1 and c2, iff we have > glibc 2.29 or greater. > > This will ensure OpenJDK can benefit from future improvements > to glibc. > > Glibc adheres to the ieee754 standard, unless stated otherwise > in its spec. > > As there are no stated exceptions in the current glibc spec > for dlog, dlog10 and dexp, we can assume they currently follow > ieee754 (which testing confirms). As such, future version of > glibc are unlikely to lose this compliance with ieee754 in > future. > > W.r.t performance this patch sees ~15-30% performance improvements for > log and log10, with ~50-80% performance improvements for exp for the > common input ranged (which output real numbers). However for the NaN > and inf output ranges we see a slow down of up to a factor of 2 for > some functions and architectures. > > Due to this being the uncommon case we assert that this is a > worthwhile tradeoff. greg.cawthorne at arm.com Should work ------------- PR: https://git.openjdk.java.net/jdk/pull/3510 From rriggs at openjdk.java.net Tue May 25 15:46:37 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 25 May 2021 15:46:37 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v8] In-Reply-To: References: Message-ID: > JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. > The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional > configuration mechanisms and filter utilities. > > javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: > http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html Roger Riggs has updated the pull request incrementally with two additional commits since the last revision: - Moved utility filter methods to be static on ObjectInputFilter Rearranged the class javadoc of OIF to describe the parts of deserialization filtering, filters, composite filters, and the filter factory. And other review comment updates... - Refactored tests for utility functions to SerialFilterFunctionTest.java Deleted confused Config.allowMaxLimits() method Updated example to match move of methods to Config Added test of restriction on setting the filterfactory after a OIS has been created Additional Editorial updates ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3996/files - new: https://git.openjdk.java.net/jdk/pull/3996/files/141bf720..9573ae11 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=06-07 Stats: 1040 lines in 7 files changed: 533 ins; 397 del; 110 mod Patch: https://git.openjdk.java.net/jdk/pull/3996.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3996/head:pull/3996 PR: https://git.openjdk.java.net/jdk/pull/3996 From psandoz at openjdk.java.net Tue May 25 15:52:56 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 25 May 2021 15:52:56 GMT Subject: RFR: 8267452: Delegate forEachRemaining in Spliterators.iterator() [v2] In-Reply-To: References: Message-ID: <6DKwy_BC83GpeS_4joq1Wqb9CtYwY05spmrZCJDwuvQ=.eb715173-041b-47f6-9336-e9030f7d2839@github.com> On Mon, 24 May 2021 07:15:34 GMT, Tagir F. Valeev wrote: >> Sometimes, `Spliterator::forEachRemaining` has much more optimized implementation, compared to `Spliterator::tryAdvance`. For example, if a `Stream::spliterator` called for a stream that has intermediate operations, `tryAdvance()` may buffer intermediate elements while `forEachRemaining()` just delegates to the `wrapAndCopyInto` (see `StreamSpliterators.AbstractWrappingSpliterator` and its inheritors). >> >> `Spliterators::iterator` methods (used in particular by `Stream::iterator`) provide adapter iterators that delegate to the supplied spliterator. Unfortunately, they don't have a specialized implementation for `Iterator::forEachRemaining`. As a result, a default implementation is used that delegates to `hasNext`/`next`, which in turn causes the delegation to `tryAdvance`. It's quite simple to implement `Iterator::forEachRemaining` here, taking advantage of possible spliterator optimizations if the iterator client decides to use `forEachRemaining`. >> >> This patch implements Iterator::forEachRemaining in Spliterators::iterator methods. Also, I nullize the `nextElement` in `Iterator::next` to avoid accidental prolongation of the user's object lifetime when iteration is finished. Finally, a small cleanup: I added the `final` modifier where possible to private fields in `Spliterators`. >> >> Test-wise, some scenarios are already covered by SpliteratorTraversingAndSplittingTest. However, the resulting iterator is always wrapped into `Spliterators::spliterator`, so usage scenarios are somewhat limited. In particular, calling `hasNext` (without `next`) before `forEachRemaining` was not covered there. I added more tests in `IteratorFromSpliteratorTest` to cover these scenarios. I checked that removing `valueReady = false;` or `action.accept(t);` lines from newly implemented `forEachRemaining` method causes new tests to fail (but old tests don't fail due to this). > > Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: > > Test: formatting; tests for empty spliterator Oops i missed the bit about testing in the description. That's subtle, the `hasNext` occurs in the assert before the `forEachRemaining`. Could you add a comment that this is the primary purpose of the test since `SpliteratorTraversingAndSplittingTest` cannot do that for a spliterator wrapping an iterator? ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4124 From chegar at openjdk.java.net Tue May 25 15:54:57 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 25 May 2021 15:54:57 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v5] In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Tue, 25 May 2021 11:49:18 GMT, Tagir F. Valeev wrote: >> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. >> >> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? > > Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: > > More vertical alignment src/java.base/share/classes/java/util/Calendar.java line 1507: > 1505: } > 1506: case "japanese" -> cal = new JapaneseImperialCalendar(zone, locale, true); > 1507: default -> throw new IllegalArgumentException("unknown calendar type: " + type); In this case, it would be good to yield the result of the switch expression and assign that to a local, rather than assigning in each of the case arms, e.g: final Calendar cal = switch (type) { case "gregory" -> new GregorianCalendar(zone, locale, true); case "iso8601" -> { GregorianCalendar gcal = new GregorianCalendar(zone, locale, true); // make gcal a proleptic Gregorian gcal.setGregorianChange(new Date(Long.MIN_VALUE)); // and week definition to be compatible with ISO 8601 setWeekDefinition(MONDAY, 4); yield gcal; } case "buddhist" -> { var buddhistCalendar = new BuddhistCalendar(zone, locale); buddhistCalendar.clear(); yield buddhistCalendar; } case "japanese" -> new JapaneseImperialCalendar(zone, locale, true); default -> throw new IllegalArgumentException("unknown calendar type: " + type); }; ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From asemenyuk at openjdk.java.net Tue May 25 15:59:00 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 25 May 2021 15:59:00 GMT Subject: RFR: 8267403: tools/jpackage/share/FileAssociationsTest.java#id0 failed with "Error: Bundler "Mac PKG Package" (pkg) failed to produce a package" In-Reply-To: References: Message-ID: On Fri, 21 May 2021 04:34:22 GMT, Alexander Matveev wrote: > Looks like another issue similar to hdiutil (JDK-8249395) when process is gone, but we still waiting for it. I was not able to reproduce this issue by running test or pkgbuild separately and conclusion was made based on logs. Fixed in same way as hdiutil issue. Also, I added logging PID for external commands to simplify log analysis. Log will have multiple hdiutil and/or pkgbuild processes, since we running multiple tests in parallel and matching external process to test failure requires looking at command line for particular process, so PID should simplify this. Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4139 From rriggs at openjdk.java.net Tue May 25 16:00:00 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 25 May 2021 16:00:00 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v3] In-Reply-To: References: <2l4QEjmcr26yNxlkVYAOREe9oZkNg6o9Y8WCnDv6tV8=.2be72421-26b0-41f4-85a9-66f93cdb4545@github.com> Message-ID: On Tue, 25 May 2021 09:14:38 GMT, Chris Hegarty wrote: >> The spec/code is forthcoming. >> ii) is sufficient to prevent ambiguity in which filter is used throughout the Java runtime; >> though it requires a bit of package-private plumbing. >> >> i) is too limiting. It should be possible for an application to check whether a filter factory has been provided on the command line (by calling getSerialFilterFactory) and if not setting the factory itself. It may also want to install its own filter factory that delegates to the builtin factory without needed to re-implement the builtin behavior. > >> i) is too limiting. It should be possible for an application to check whether a filter factory has been provided on the command line (by calling getSerialFilterFactory) and if not setting the factory itself. It may also want to install its own filter factory that delegates to the builtin factory without needed to re-implement the builtin behavior. > > How is this supposed to work in practice? getSerialFilterFactory always returns a non-null factory, so how does one know whether or not the returned factory is the built-in factory, a factory set by the command line (or security property) ? (without resorting to implementation assumptions) If the app does not recognize the filter factory (by its class or module) then try to replace it. If it succeeds, the app is good to go. If it throws an exception then your app is not likely to run and should fail. Newer APIs generally make it possible to detect the state of things without throwing but in this case it would add extra API surface. Some alternatives, check the module of the filter returned, if it is java.base then replacing it is ok to replace. (yes an implementation assumption). An alternative would be to add a static method to return the builtin filter; creating it if has not already been created. ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From forax at openjdk.java.net Tue May 25 16:03:56 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Tue, 25 May 2021 16:03:56 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 14:22:57 GMT, Jan Lahoda wrote: > The reason for this integer (which is not a constant in the case of this switch) is to restart the matching in case guards fail to "match". Considering the example here: > > ``` > class Example { > void example(Object o) { > switch (o) { > case String s && s.length() == 0 -> > System.out.println("1st case"); > case String s && s.length() == 1 -> // line 6 > System.out.println("2nd case"); // line 7 > case String s -> // line 8 > System.out.println("3rd case"); // line 9 > default -> // line 10 > System.out.println("default case"); // line 11 > } > } > } > ``` > > If `o` is `String`, then the first call to indy will be `indy[...](o, 0)`, returning `0`. Then the guard will be evaluated `s.length() == 0`. If the length is not zero, the local variable 3 will be reassigned to `1`(bytecode index 58, 59) and the whole switch is restarted - just this time, the matching in the indy will start at index `1`, not `0`, i.e. `indy[...](o, 1)`. And so on. I believe there is a text explaining the meaning of the parameter in the javadoc of the bootstrap, and in TransPatterns in javac. The problem with this design is that calling example("foo") forces the VM will do 6 checkcast String on "foo", and it doesn't work with sub-patterns. Desugaring the guards as static method like with lambdas seems more promising, indy can be called with the pairs [String, MethodHandle(s -> s.length() == 0)], [String, MethodHandle(s -> s.length() == 0)] and [_,_] (with the guards passed as a constant method handles again like lambdas are desugared). It means that the indy needs to capture all local variables that are used in the guards, instead of passing an int. I believe that a translation using constant method handles for guards is far more efficient than using an int and a backward branch but it has a higher cost in term of runtime data structures. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Tue May 25 16:17:59 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 25 May 2021 16:17:59 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: <6SO8Ij_klMovO-wcF_I8rjji8VVd8-BSergVJ_4K7ZQ=.f04b7334-b9ee-46c5-9c0e-93d79a015004@github.com> On Tue, 25 May 2021 16:00:43 GMT, R?mi Forax wrote: > > The reason for this integer (which is not a constant in the case of this switch) is to restart the matching in case guards fail to "match". Considering the example here: > > ``` > > class Example { > > void example(Object o) { > > switch (o) { > > case String s && s.length() == 0 -> > > System.out.println("1st case"); > > case String s && s.length() == 1 -> // line 6 > > System.out.println("2nd case"); // line 7 > > case String s -> // line 8 > > System.out.println("3rd case"); // line 9 > > default -> // line 10 > > System.out.println("default case"); // line 11 > > } > > } > > } > > ``` > > > > > > > > > > > > > > > > > > > > > > > > If `o` is `String`, then the first call to indy will be `indy[...](o, 0)`, returning `0`. Then the guard will be evaluated `s.length() == 0`. If the length is not zero, the local variable 3 will be reassigned to `1`(bytecode index 58, 59) and the whole switch is restarted - just this time, the matching in the indy will start at index `1`, not `0`, i.e. `indy[...](o, 1)`. And so on. I believe there is a text explaining the meaning of the parameter in the javadoc of the bootstrap, and in TransPatterns in javac. > > The problem with this design is that calling example("foo") forces the VM will do 6 checkcast String on "foo", and it doesn't work with sub-patterns. Desugaring the guards as static method like with lambdas seems more promising, indy can be called with the pairs [String, MethodHandle(s -> s.length() == 0)], [String, MethodHandle(s -> s.length() == 0)] and [_,_] (with the guards passed as a constant method handles again like lambdas are desugared). > It means that the indy needs to capture all local variables that are used in the guards, instead of passing an int. > > I believe that a translation using constant method handles for guards is far more efficient than using an int and a backward branch but it has a higher cost in term of runtime data structures. I'd like to note this is a preview feature - we can change the desugaring. At the same time, I don't think this does not work with sub-patterns (those can be easily desugared to guards, I think). Regarding efficiency, it may be a balance between classfile overhead (which will be higher if we need to desugar every guard to a separate method), and the possibility to tweak the matching at runtime. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From brian.goetz at oracle.com Tue May 25 16:19:17 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 25 May 2021 12:19:17 -0400 Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions In-Reply-To: References: Message-ID: <5692C0A8-4489-4437-AD65-17704146E7F8@oracle.com> In the last hunk, you convert case Collator.IDENTICAL: toAddTo.append('='); break; case Collator.TERTIARY: toAddTo.append(','); break; case Collator.SECONDARY: toAddTo.append(';'); break; case Collator.PRIMARY: toAddTo.append('<'); break; case RESET: toAddTo.append('&'); break; case UNSET: toAddTo.append('?'); break; to case Collator.IDENTICAL -> toAddTo.append('='); case Collator.TERTIARY -> toAddTo.append(','); case Collator.SECONDARY -> toAddTo.append(';'); case Collator.PRIMARY -> toAddTo.append('<'); case RESET -> toAddTo.append('&'); case UNSET -> toAddTo.append('?'); But, you can go further, pulling the toAddTo.append() call out of the switch. This was one of the benefits we anticipated with expression switches; that it would expose more opportunities to push the conditional logic farther down towards the leaves. I suspect there are other opportunities for this in this patch too. > On May 25, 2021, at 7:57 AM, Patrick Concannon wrote: > > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick > > ------------- > > Commit messages: > - 8267670: Update java.io, java.math, and java.text to use switch expressions > > Changes: https://git.openjdk.java.net/jdk/pull/4182/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8267670 > Stats: 328 lines in 11 files changed: 1 ins; 187 del; 140 mod > Patch: https://git.openjdk.java.net/jdk/pull/4182.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/4182/head:pull/4182 > > PR: https://git.openjdk.java.net/jdk/pull/4182 From raffaello.giulietti at gmail.com Tue May 25 16:29:56 2021 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 25 May 2021 18:29:56 +0200 Subject: Reminder RFR: 4511638: Double.toString(double) sometimes produces incorrect results Message-ID: <932a7788-9661-e21b-a789-228e831a8613@gmail.com> Hi, a reminder to keep PR [1] alive and to invite interested reviewers to comment it. The corresponding CSR is in [2] Greetings Raffaello --- [1] https://github.com/openjdk/jdk/pull/3402 [2] https://bugs.openjdk.java.net/browse/JDK-8202555 From briangoetz at openjdk.java.net Tue May 25 16:49:59 2021 From: briangoetz at openjdk.java.net (Brian Goetz) Date: Tue, 25 May 2021 16:49:59 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v5] In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Tue, 25 May 2021 11:49:18 GMT, Tagir F. Valeev wrote: >> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. >> >> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? > > Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: > > More vertical alignment src/java.base/share/classes/java/util/Calendar.java line 1507: > 1505: } > 1506: case "japanese" -> cal = new JapaneseImperialCalendar(zone, locale, true); > 1507: default -> throw new IllegalArgumentException("unknown calendar type: " + type); Agree with Chris' suggestion here. ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From naoto at openjdk.java.net Tue May 25 16:53:07 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 25 May 2021 16:53:07 GMT Subject: RFR: 8187649: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar Message-ID: Please review the fix. The issue was informed yesterday by @amaembo that it offends some code analysis tools. Although the fix is to change the condition error, it turned out that `JapaneseImperialCalendar.roll()` did not work for `WEEK_OF_MONTH` and `DAY_OF_MONTH`. There was an inherent issue where `GregorianCalendar` does not follow the `roll()` spec, i.e., "The MONTH must not change when the WEEK_OF_MONTH is rolled." during the Julian/Gregorian transition. JDK-6191841 seems to have tried to fix it but it was closed as `Future Project`... So I simply fixed the `roll()` issue in `JapaneseImperialCalendar` to follow the spec here, which seems to be the intent of the original author. ------------- Commit messages: - 8187649: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar Changes: https://git.openjdk.java.net/jdk/pull/4191/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4191&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8187649 Stats: 46 lines in 3 files changed: 36 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4191/head:pull/4191 PR: https://git.openjdk.java.net/jdk/pull/4191 From rriggs at openjdk.java.net Tue May 25 16:53:28 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 25 May 2021 16:53:28 GMT Subject: RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams [v4] In-Reply-To: References: Message-ID: > Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process. > The Charset used to encode and decode characters to bytes can be specified or use the > operating system native encoding as is available from the "native.encoding" system property. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Described charset mapping of malformed chars in outputWriter Repeated calls to inputReader, errorReader, and outputWriter now return the same instance and check for inconsistent charset argument Added warnings about concurrently use of input/output streams and readers/writers. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4134/files - new: https://git.openjdk.java.net/jdk/pull/4134/files/7724b82c..a5ed7b73 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4134&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4134&range=02-03 Stats: 161 lines in 2 files changed: 131 ins; 0 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/4134.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4134/head:pull/4134 PR: https://git.openjdk.java.net/jdk/pull/4134 From github.com+70726043+rgiulietti at openjdk.java.net Tue May 25 16:55:05 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Tue, 25 May 2021 16:55:05 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 4511638: Double.toString(double) sometimes produces incorrect results Hi, a reminder to keep PR [1] alive and to invite interested reviewers to comment it. The corresponding CSR is in [2] Greetings Raffaello --- [1] https://github.com/openjdk/jdk/pull/3402 [2] https://bugs.openjdk.java.net/browse/JDK-8202555 ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From briangoetz at openjdk.java.net Tue May 25 16:55:06 2021 From: briangoetz at openjdk.java.net (Brian Goetz) Date: Tue, 25 May 2021 16:55:06 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v5] In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Tue, 25 May 2021 11:49:18 GMT, Tagir F. Valeev wrote: >> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. >> >> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? > > Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: > > More vertical alignment src/java.base/share/classes/java/util/JapaneseImperialCalendar.java line 1124: > 1122: return Math.max(LEAST_MAX_VALUES[YEAR], d.getYear()); > 1123: } > 1124: } A switch with one element here is kind of weird. I would turn this into "return switch (field) { ... }", with two cases, YEAR and default. src/java.base/share/classes/java/util/JapaneseImperialCalendar.java line 1371: > 1369: } > 1370: } > 1371: } Pull value assignment out of switch? ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From darcy at openjdk.java.net Tue May 25 16:57:57 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 25 May 2021 16:57:57 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v2] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 14:57:22 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon 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 three additional commits since the last revision: > > - 8267670: Updated code to use yield > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Update java.io, java.math, and java.text to use switch expressions Changes in java.math look fine. ------------- Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4182 From sviswanathan at openjdk.java.net Tue May 25 20:19:04 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 25 May 2021 20:19:04 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v14] In-Reply-To: References: Message-ID: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: Javadoc changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/4d59af0a..6cd50248 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=12-13 Stats: 58 lines in 1 file changed: 38 ins; 0 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From rriggs at openjdk.java.net Tue May 25 21:28:40 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 25 May 2021 21:28:40 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v7] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 11:18:15 GMT, Chris Hegarty wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Move merge and rejectUndecidedClass methods to OIF.Config >> As default methods on OIF, their implementations were not concrete and not trustable > > src/java.base/share/classes/java/io/ObjectInputFilter.java line 400: > >> 398: * {@link BinaryOperator {@literal BinaryOperator}} interface, provide its implementation and >> 399: * be accessible via the {@linkplain ClassLoader#getSystemClassLoader() application class loader}. >> 400: * The filter factory configured using the system or security property during initialization > > What is the expected behaviour if the factory property is to set to a non-class or non-accessible class? The current implementation does (it probably should be more graceful) : > > $ java -Djdk.serialFilterFactory=allow T > Exception in thread "main" java.lang.ExceptionInInitializerError > at java.base/java.io.ObjectInputFilter$Config.(ObjectInputFilter.java:537) > at java.base/java.io.ObjectInputStream.(ObjectInputStream.java:394) > at T.main(T.java:5) > Caused by: java.lang.ClassNotFoundException: allow > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:636) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:182) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519) > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:466) > at java.base/java.io.ObjectInputFilter$Config.(ObjectInputFilter.java:519) > ... 2 more If the factory class can not be found, the exception must be fatal; continuing to run without the filter would be a security risk. ExceptionInInitializerError was the closest I could find. I'll improve the message; Oddly, ExceptionInInitializer does not allow both a message and initCause(). And the stacktrace for the ClassNotFoundException is not going to be very interesting. ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From rriggs at openjdk.java.net Tue May 25 21:45:33 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 25 May 2021 21:45:33 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v9] In-Reply-To: References: Message-ID: > JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. > The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional > configuration mechanisms and filter utilities. > > javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: > http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Editorial updates Updated java.security properties to include jdk.serialFilterFactory Added test cases to SerialFilterFactoryTest for java.security properties and enabling of the SecurityManager with existing policy permission files Corrected a test that OIS.setObjectInputFilter could not be called twice. Removed a Factory test that was not intended to be committed ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3996/files - new: https://git.openjdk.java.net/jdk/pull/3996/files/9573ae11..b83da61a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=07-08 Stats: 245 lines in 8 files changed: 77 ins; 112 del; 56 mod Patch: https://git.openjdk.java.net/jdk/pull/3996.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3996/head:pull/3996 PR: https://git.openjdk.java.net/jdk/pull/3996 From sviswanathan at openjdk.java.net Tue May 25 22:02:39 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 25 May 2021 22:02:39 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v15] In-Reply-To: References: Message-ID: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: correct javadoc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/6cd50248..e5208a18 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=13-14 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From almatvee at openjdk.java.net Tue May 25 22:11:43 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 25 May 2021 22:11:43 GMT Subject: Integrated: 8267403: tools/jpackage/share/FileAssociationsTest.java#id0 failed with "Error: Bundler "Mac PKG Package" (pkg) failed to produce a package" In-Reply-To: References: Message-ID: <7COa3AQGPuDpPxKch4X2shRAPDCiBs7Zil75a0SwC8o=.70b5ee51-791e-4ebd-964f-9b1dfa2378ae@github.com> On Fri, 21 May 2021 04:34:22 GMT, Alexander Matveev wrote: > Looks like another issue similar to hdiutil (JDK-8249395) when process is gone, but we still waiting for it. I was not able to reproduce this issue by running test or pkgbuild separately and conclusion was made based on logs. Fixed in same way as hdiutil issue. Also, I added logging PID for external commands to simplify log analysis. Log will have multiple hdiutil and/or pkgbuild processes, since we running multiple tests in parallel and matching external process to test failure requires looking at command line for particular process, so PID should simplify this. This pull request has now been integrated. Changeset: 5aa45f2e Author: Alexander Matveev URL: https://git.openjdk.java.net/jdk/commit/5aa45f2edf278bab4403704ab4b6644096f8c077 Stats: 31 lines in 5 files changed: 16 ins; 1 del; 14 mod 8267403: tools/jpackage/share/FileAssociationsTest.java#id0 failed with "Error: Bundler "Mac PKG Package" (pkg) failed to produce a package" Reviewed-by: herrick, asemenyuk ------------- PR: https://git.openjdk.java.net/jdk/pull/4139 From pconcannon at openjdk.java.net Tue May 25 21:43:36 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Tue, 25 May 2021 21:43:36 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v3] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: 8267670: Remove redundant code from switch ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4182/files - new: https://git.openjdk.java.net/jdk/pull/4182/files/adc8af41..e503ed26 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=01-02 Stats: 24 lines in 3 files changed: 4 ins; 3 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/4182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4182/head:pull/4182 PR: https://git.openjdk.java.net/jdk/pull/4182 From chegar at openjdk.java.net Tue May 25 21:43:44 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 25 May 2021 21:43:44 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v3] In-Reply-To: References: Message-ID: <0gqeytkQm1L1FABLnM3XoXuT6RzChmUOFvGKzHd25cE=.c57641c6-198e-4910-ac68-3a1df3c919b2@github.com> On Tue, 25 May 2021 18:54:48 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: > > 8267670: Remove redundant code from switch Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From smarks at openjdk.java.net Tue May 25 22:26:43 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 25 May 2021 22:26:43 GMT Subject: RFR: 8267123: Remove RMI Activation Message-ID: This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). This is a fairly straightforward removal of this component. - Activation implementation classes removed - Activation tests removed - adjustments to various comments to remove references to Activation - adjustments to some code to remove special-case support for Activation from core RMI - adjustments to several tests to remove testing and support for, and mentions of Activation - remove `rmid` tool (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) ------------- Commit messages: - Merge branch 'master' into JDK-8267123-Remove-RMI-Activation - Merge branch 'master' into remove-rmi-activation - Clean up some old comments. - Small fixups. - First cut at removal of RMI Activation. Changes: https://git.openjdk.java.net/jdk/pull/4194/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4194&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267123 Stats: 21982 lines in 243 files changed: 0 ins; 21930 del; 52 mod Patch: https://git.openjdk.java.net/jdk/pull/4194.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4194/head:pull/4194 PR: https://git.openjdk.java.net/jdk/pull/4194 From joehw at openjdk.java.net Tue May 25 22:34:14 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 25 May 2021 22:34:14 GMT Subject: RFR: 8187649: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar In-Reply-To: References: Message-ID: On Tue, 25 May 2021 16:40:53 GMT, Naoto Sato wrote: > Please review the fix. The issue was informed yesterday by @amaembo that it offends some code analysis tools. > Although the fix is to change the condition error, it turned out that `JapaneseImperialCalendar.roll()` did not work for `WEEK_OF_MONTH` and `DAY_OF_MONTH`. There was an inherent issue where `GregorianCalendar` does not follow the `roll()` spec, i.e., "The MONTH must not change when the WEEK_OF_MONTH is rolled." during the Julian/Gregorian transition. JDK-6191841 seems to have tried to fix it but it was closed as `Future Project`... > So I simply fixed the `roll()` issue in `JapaneseImperialCalendar` to follow the spec here, which seems to be the intent of the original author. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4191 From erikj at openjdk.java.net Tue May 25 22:41:16 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 25 May 2021 22:41:16 GMT Subject: RFR: 8267123: Remove RMI Activation In-Reply-To: References: Message-ID: On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to various comments to remove references to Activation > - adjustments to some code to remove special-case support for Activation from core RMI > - adjustments to several tests to remove testing and support for, and mentions of Activation > - remove `rmid` tool > > (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4194 From bchristi at openjdk.java.net Tue May 25 23:43:24 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 25 May 2021 23:43:24 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v9] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 21:45:33 GMT, Roger Riggs wrote: >> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. >> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional >> configuration mechanisms and filter utilities. >> >> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: >> http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Editorial updates > Updated java.security properties to include jdk.serialFilterFactory > Added test cases to SerialFilterFactoryTest for java.security properties and > enabling of the SecurityManager with existing policy permission files > Corrected a test that OIS.setObjectInputFilter could not be called twice. > Removed a Factory test that was not intended to be committed src/java.base/share/classes/java/io/ObjectInputFilter.java line 513: > 511: * the static JVM-wide filter, or to create a filter from a pattern string. > 512: * The static filter factory and the static filter apply to the whole Java runtime, > 513: * or "JVM-wide", there is only one of each, for a complete description of Suggest new sentence after "_...there is only one of each. For a complete..._" src/java.base/share/classes/java/io/ObjectInputFilter.java line 551: > 549: final class Config { > 550: /** > 551: * Lock object for filter and filter factory. The lock is not used for the filter factory, is it? src/java.base/share/classes/java/io/ObjectInputFilter.java line 768: > 766: * This package private method is *only* called by {@link ObjectInputStream#ObjectInputStream()} > 767: * and {@link ObjectInputStream#ObjectInputStream(InputStream)}. > 768: * {@link ObjectInputFilter.Config#serialFilterFactory} does the enforcement. Is this still true about the enforcement? src/java.base/share/classes/java/io/ObjectInputFilter.java line 1251: > 1249: * Returns REJECTED if either of the filters returns REJECTED, > 1250: * otherwise, ALLOWED if either of the filters returns ALLOWED. > 1251: * otherwise, returns {@code UNDECIDED}. Capitalize "Otherwise" src/java.base/share/classes/java/io/ObjectInputFilter.java line 1256: > 1254: * @return REJECTED if either of the filters returns REJECTED, > 1255: * otherwise, ALLOWED if either of the filters returns ALLOWED. > 1256: * otherwise, returns {@code UNDECIDED}. Otherwise ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From bchristi at openjdk.java.net Tue May 25 23:43:22 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 25 May 2021 23:43:22 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v8] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 15:46:37 GMT, Roger Riggs wrote: >> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. >> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional >> configuration mechanisms and filter utilities. >> >> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: >> http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html > > Roger Riggs has updated the pull request incrementally with two additional commits since the last revision: > > - Moved utility filter methods to be static on ObjectInputFilter > Rearranged the class javadoc of OIF to describe the parts of > deserialization filtering, filters, composite filters, and the filter factory. > And other review comment updates... > - Refactored tests for utility functions to SerialFilterFunctionTest.java > Deleted confused Config.allowMaxLimits() method > Updated example to match move of methods to Config > Added test of restriction on setting the filterfactory after a OIS has been created > Additional Editorial updates More suggestions for ObjectInputFilter.java. I hope they're helpful. src/java.base/share/classes/java/io/ObjectInputFilter.java line 128: > 126: * provides the {@linkplain Config#getSerialFilter static JVM-wide filter} when invoked from the > 127: * {@linkplain ObjectInputStream#ObjectInputStream(InputStream) ObjectInputStream constructors} > 128: * and replaces the static filter and when invoked from "...replaces the static filter ~~and~~ when invoked..." src/java.base/share/classes/java/io/ObjectInputFilter.java line 137: > 135: * or to {@linkplain #allowFilter(Predicate, Status) allow} or > 136: * {@linkplain #rejectFilter(Predicate, Status) reject} classes based on a > 137: * {@linkplain Predicate predicate of a class}. Maybe a new sentence for the Predicate-based filters? e.g. "Filters can be created from a pattern string. Or they can allow or reject classes based on a Predicate." src/java.base/share/classes/java/io/ObjectInputFilter.java line 205: > 203: * // Returns a composite filter of the static JVM-wide filter, a thread-specific filter, > 204: * // and the stream-specific filter. > 205: * public ObjectInputFilter apply(ObjectInputFilter curr, ObjectInputFilter next) { `@Override` on `apply` ? src/java.base/share/classes/java/io/ObjectInputFilter.java line 211: > 209: * if (filter != null) { > 210: * // Prepend a filter to assert that all classes have been Allowed or Rejected > 211: * filter = ObjectInputFilter.Config.rejectUndecidedClass(filter); ~~Config~~ throughout the example src/java.base/share/classes/java/io/ObjectInputFilter.java line 301: > 299: * on the class is {@code true}. > 300: * The filter returns {@code ALLOWED} or the {@code otherStatus} based on the predicate > 301: * of the {@code non-null} class and {@code UNDECIDED} if the class is {@code null}. Can this sentence ("_The filter returns...class is null_") be removed? IMO it doesn't add to what's covered in the rest of the method doc. src/java.base/share/classes/java/io/ObjectInputFilter.java line 334: > 332: * on the class is {@code true}. > 333: * The filter returns {@code REJECTED} or the {@code otherStatus} based on the predicate > 334: * of the {@code non-null} class and {@code UNDECIDED} if the class is {@code null}. Same - can this sentence ("The filter returns...class is null") be removed? ------------- Changes requested by bchristi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3996 From naoto at openjdk.java.net Wed May 26 01:20:16 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 26 May 2021 01:20:16 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v3] In-Reply-To: References: Message-ID: <7vO2Ar5e7mqC9QJ92-OsjkDHo84AXz1kHK93GfZw_lU=.1eae87c2-5032-451d-8d3d-3f7f2c0144dd@github.com> On Tue, 25 May 2021 21:43:36 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: > > 8267670: Remove redundant code from switch Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From tvaleev at openjdk.java.net Wed May 26 01:20:47 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Wed, 26 May 2021 01:20:47 GMT Subject: RFR: 8267452: Delegate forEachRemaining in Spliterators.iterator() [v3] In-Reply-To: References: Message-ID: > Sometimes, `Spliterator::forEachRemaining` has much more optimized implementation, compared to `Spliterator::tryAdvance`. For example, if a `Stream::spliterator` called for a stream that has intermediate operations, `tryAdvance()` may buffer intermediate elements while `forEachRemaining()` just delegates to the `wrapAndCopyInto` (see `StreamSpliterators.AbstractWrappingSpliterator` and its inheritors). > > `Spliterators::iterator` methods (used in particular by `Stream::iterator`) provide adapter iterators that delegate to the supplied spliterator. Unfortunately, they don't have a specialized implementation for `Iterator::forEachRemaining`. As a result, a default implementation is used that delegates to `hasNext`/`next`, which in turn causes the delegation to `tryAdvance`. It's quite simple to implement `Iterator::forEachRemaining` here, taking advantage of possible spliterator optimizations if the iterator client decides to use `forEachRemaining`. > > This patch implements Iterator::forEachRemaining in Spliterators::iterator methods. Also, I nullize the `nextElement` in `Iterator::next` to avoid accidental prolongation of the user's object lifetime when iteration is finished. Finally, a small cleanup: I added the `final` modifier where possible to private fields in `Spliterators`. > > Test-wise, some scenarios are already covered by SpliteratorTraversingAndSplittingTest. However, the resulting iterator is always wrapped into `Spliterators::spliterator`, so usage scenarios are somewhat limited. In particular, calling `hasNext` (without `next`) before `forEachRemaining` was not covered there. I added more tests in `IteratorFromSpliteratorTest` to cover these scenarios. I checked that removing `valueReady = false;` or `action.accept(t);` lines from newly implemented `forEachRemaining` method causes new tests to fail (but old tests don't fail due to this). Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: Add a comment clarifying the purpose of the test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4124/files - new: https://git.openjdk.java.net/jdk/pull/4124/files/9a5e0dd2..cc337995 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4124&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4124&range=01-02 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4124.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4124/head:pull/4124 PR: https://git.openjdk.java.net/jdk/pull/4124 From tvaleev at openjdk.java.net Wed May 26 01:20:51 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Wed, 26 May 2021 01:20:51 GMT Subject: RFR: 8267452: Delegate forEachRemaining in Spliterators.iterator() [v2] In-Reply-To: <6DKwy_BC83GpeS_4joq1Wqb9CtYwY05spmrZCJDwuvQ=.eb715173-041b-47f6-9336-e9030f7d2839@github.com> References: <6DKwy_BC83GpeS_4joq1Wqb9CtYwY05spmrZCJDwuvQ=.eb715173-041b-47f6-9336-e9030f7d2839@github.com> Message-ID: <-mqFElKcFFOsfo5_lyNx-d94N1asq4XdL4jgZ2BIpuY=.f4a954e7-94ee-4339-809c-fd621a30ec93@github.com> On Tue, 25 May 2021 15:49:55 GMT, Paul Sandoz wrote: >> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: >> >> Test: formatting; tests for empty spliterator > > Oops i missed the bit about testing in the description. That's subtle, the `hasNext` occurs in the assert before the `forEachRemaining`. Could you add a comment that this is the primary purpose of the test since `SpliteratorTraversingAndSplittingTest` cannot do that for a spliterator wrapping an iterator? @PaulSandoz added a comment, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4124 From tvaleev at openjdk.java.net Wed May 26 01:20:54 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Wed, 26 May 2021 01:20:54 GMT Subject: Integrated: 8267452: Delegate forEachRemaining in Spliterators.iterator() In-Reply-To: References: Message-ID: On Thu, 20 May 2021 10:16:28 GMT, Tagir F. Valeev wrote: > Sometimes, `Spliterator::forEachRemaining` has much more optimized implementation, compared to `Spliterator::tryAdvance`. For example, if a `Stream::spliterator` called for a stream that has intermediate operations, `tryAdvance()` may buffer intermediate elements while `forEachRemaining()` just delegates to the `wrapAndCopyInto` (see `StreamSpliterators.AbstractWrappingSpliterator` and its inheritors). > > `Spliterators::iterator` methods (used in particular by `Stream::iterator`) provide adapter iterators that delegate to the supplied spliterator. Unfortunately, they don't have a specialized implementation for `Iterator::forEachRemaining`. As a result, a default implementation is used that delegates to `hasNext`/`next`, which in turn causes the delegation to `tryAdvance`. It's quite simple to implement `Iterator::forEachRemaining` here, taking advantage of possible spliterator optimizations if the iterator client decides to use `forEachRemaining`. > > This patch implements Iterator::forEachRemaining in Spliterators::iterator methods. Also, I nullize the `nextElement` in `Iterator::next` to avoid accidental prolongation of the user's object lifetime when iteration is finished. Finally, a small cleanup: I added the `final` modifier where possible to private fields in `Spliterators`. > > Test-wise, some scenarios are already covered by SpliteratorTraversingAndSplittingTest. However, the resulting iterator is always wrapped into `Spliterators::spliterator`, so usage scenarios are somewhat limited. In particular, calling `hasNext` (without `next`) before `forEachRemaining` was not covered there. I added more tests in `IteratorFromSpliteratorTest` to cover these scenarios. I checked that removing `valueReady = false;` or `action.accept(t);` lines from newly implemented `forEachRemaining` method causes new tests to fail (but old tests don't fail due to this). This pull request has now been integrated. Changeset: ac36b7d3 Author: Tagir F. Valeev URL: https://git.openjdk.java.net/jdk/commit/ac36b7d3e2d521652576fba3b1760586f582544f Stats: 198 lines in 2 files changed: 193 ins; 0 del; 5 mod 8267452: Delegate forEachRemaining in Spliterators.iterator() Reviewed-by: psandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/4124 From iris at openjdk.java.net Wed May 26 02:04:12 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 26 May 2021 02:04:12 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v3] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 21:43:36 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: > > 8267670: Remove redundant code from switch Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From tvaleev at openjdk.java.net Wed May 26 02:22:42 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Wed, 26 May 2021 02:22:42 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v6] In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: > Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. > > I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision: - JapaneseImperialCalendar: use switch expressions - Use yield in java.util.Calendar.Builder.build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4161/files - new: https://git.openjdk.java.net/jdk/pull/4161/files/f4ad5f14..e8cdf10e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=04-05 Stats: 155 lines in 2 files changed: 56 ins; 61 del; 38 mod Patch: https://git.openjdk.java.net/jdk/pull/4161.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161 PR: https://git.openjdk.java.net/jdk/pull/4161 From tvaleev at openjdk.java.net Wed May 26 02:22:43 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Wed, 26 May 2021 02:22:43 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v5] In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Tue, 25 May 2021 15:51:38 GMT, Chris Hegarty wrote: >> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: >> >> More vertical alignment > > src/java.base/share/classes/java/util/Calendar.java line 1507: > >> 1505: } >> 1506: case "japanese" -> cal = new JapaneseImperialCalendar(zone, locale, true); >> 1507: default -> throw new IllegalArgumentException("unknown calendar type: " + type); > > In this case, it would be good to yield the result of the switch expression and assign that to a local, rather than assigning in each of the case arms, e.g: > > final Calendar cal = switch (type) { > case "gregory" -> new GregorianCalendar(zone, locale, true); > case "iso8601" -> { > GregorianCalendar gcal = new GregorianCalendar(zone, locale, true); > // make gcal a proleptic Gregorian > gcal.setGregorianChange(new Date(Long.MIN_VALUE)); > // and week definition to be compatible with ISO 8601 > setWeekDefinition(MONDAY, 4); > yield gcal; > } > case "buddhist" -> { > var buddhistCalendar = new BuddhistCalendar(zone, locale); > buddhistCalendar.clear(); > yield buddhistCalendar; > } > case "japanese" -> new JapaneseImperialCalendar(zone, locale, true); > default -> throw new IllegalArgumentException("unknown calendar type: " + type); > }; Done, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From tvaleev at openjdk.java.net Wed May 26 02:22:45 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Wed, 26 May 2021 02:22:45 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v5] In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Tue, 25 May 2021 16:47:15 GMT, Brian Goetz wrote: >> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: >> >> More vertical alignment > > src/java.base/share/classes/java/util/Calendar.java line 1507: > >> 1505: } >> 1506: case "japanese" -> cal = new JapaneseImperialCalendar(zone, locale, true); >> 1507: default -> throw new IllegalArgumentException("unknown calendar type: " + type); > > Agree with Chris' suggestion here. Done! > src/java.base/share/classes/java/util/JapaneseImperialCalendar.java line 1124: > >> 1122: return Math.max(LEAST_MAX_VALUES[YEAR], d.getYear()); >> 1123: } >> 1124: } > > A switch with one element here is kind of weird. I would turn this into "return switch (field) { ... }", with two cases, YEAR and default. Done, also at line 1169 ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From iris at openjdk.java.net Wed May 26 02:30:13 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 26 May 2021 02:30:13 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v6] In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Wed, 26 May 2021 02:22:42 GMT, Tagir F. Valeev wrote: >> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. >> >> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? > > Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision: > > - JapaneseImperialCalendar: use switch expressions > - Use yield in java.util.Calendar.Builder.build Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From tvaleev at openjdk.java.net Wed May 26 02:30:15 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Wed, 26 May 2021 02:30:15 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v6] In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Wed, 26 May 2021 02:22:42 GMT, Tagir F. Valeev wrote: >> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. >> >> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? > > Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision: > > - JapaneseImperialCalendar: use switch expressions > - Use yield in java.util.Calendar.Builder.build src/java.base/share/classes/java/util/JapaneseImperialCalendar.java line 1316: > 1314: JapaneseImperialCalendar jc = getNormalizedCalendar(); > 1315: LocalGregorianCalendar.Date date = jc.jdate; > 1316: int normalizedYear = date.getNormalizedYear(); This variable was unused src/java.base/share/classes/java/util/JapaneseImperialCalendar.java line 1423: > 1421: case WEEK_OF_MONTH -> { > 1422: LocalGregorianCalendar.Date jd = jcal.getCalendarDate(Long.MAX_VALUE, getZone()); > 1423: if (date.getEra() == jd.getEra() && date.getYear() == jd.getYear()) { I inverted the `if` condition here, as it was negated and a much shorter branch was in `else`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From tvaleev at openjdk.java.net Wed May 26 02:30:16 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Wed, 26 May 2021 02:30:16 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v5] In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Tue, 25 May 2021 16:52:06 GMT, Brian Goetz wrote: >> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: >> >> More vertical alignment > > src/java.base/share/classes/java/util/JapaneseImperialCalendar.java line 1371: > >> 1369: } >> 1370: } >> 1371: } > > Pull value assignment out of switch? This is a much bigger change which is probably harder to review. I did it, please take a look. One point is whether to unwrap the final `else` after `yield`: if (...) { ... yield ... } else { // should we remove else? ... } I prefer unwrapping, as this reduces the indentation, so I did it. Please tell me if this contradicts with the preferred OpenJDK style. ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From dholmes at openjdk.java.net Wed May 26 02:53:12 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 26 May 2021 02:53:12 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v5] In-Reply-To: References: Message-ID: 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 library load operation. >> >> Problem being fixed: >> >> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. >> >> Proposed fix: >> >> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. >> >> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. >> >> Testing: jtreg and jck testing with no regressions. A new regression test was developed. > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > fix whitespace Hi Aleksei, Thanks for bearing with me while I got my head round the synchronization protocol - piggy-backing on the CHM logic is clever! That locking part all makes sense to me now and I think it is a good solution to reduce the scope of the deadlock potential. I'm less clear on the changes to the NativeLibraryContext as I'm not certain what it means today, so making it a per-thread mapping is not something I can really comment on. I'll leave that aspect to core-libs folk. So my approval should not be taken as an approval to push yet. Thanks, David src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 497: > 495: > 496: private static void acquireNativeLibraryLock(String libraryName) { > 497: nativeLibraryLockMap.compute(libraryName, (name, lock) -> { This would be clearer if lock were named currentLock as for releaseNLLock ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3976 From alanb at openjdk.java.net Wed May 26 06:24:22 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 26 May 2021 06:24:22 GMT Subject: RFR: 8267123: Remove RMI Activation In-Reply-To: References: Message-ID: On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to various comments to remove references to Activation > - adjustments to some code to remove special-case support for Activation from core RMI > - adjustments to several tests to remove testing and support for, and mentions of Activation > - remove `rmid` tool > > (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) One other test that might need an update is test/jdk/sun/rmi/log/ReliableLog/LogAlignmentTest.java, it might be just the summary. ------------- PR: https://git.openjdk.java.net/jdk/pull/4194 From plevart at openjdk.java.net Wed May 26 06:40:20 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 26 May 2021 06:40:20 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v9] In-Reply-To: References: Message-ID: <-9uaZza9-IuWsHoF0H-lwQVKOf1VJrOb6IhrhuYM3UM=.92fa4961-c488-472e-9c7c-eeb8b535a62d@github.com> On Tue, 25 May 2021 21:45:33 GMT, Roger Riggs wrote: >> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. >> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional >> configuration mechanisms and filter utilities. >> >> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: >> http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Editorial updates > Updated java.security properties to include jdk.serialFilterFactory > Added test cases to SerialFilterFactoryTest for java.security properties and > enabling of the SecurityManager with existing policy permission files > Corrected a test that OIS.setObjectInputFilter could not be called twice. > Removed a Factory test that was not intended to be committed Changes requested by plevart (Reviewer). src/java.base/share/classes/java/io/ObjectInputStream.java line 81: > 79: * The {@linkplain #ObjectInputStream() ObjectInputStream constructors} invoke the filter factory > 80: * to select the initial filter and it is updated by {@link #setObjectInputFilter}. > 81: *

    Strange statement: "The OIS constructors invoke the filter factory to select the initial filter and it is updated by ..." What about: "The OIS constructors invoke the filter factory to select the initial filter which may be updated / replaced by setObjectInputFilter" src/java.base/share/classes/java/io/ObjectInputStream.java line 1265: > 1263: * must return a non-null filter. It is not permitted to remove filtering once established. > 1264: * See the {@linkplain ObjectInputFilter filter models} for examples of composition and delegation. > 1265: * Hi Roger, When I first read this javadoc, I was a little confused and had to peek into the implementation. After that, I understood the above text, but without peeking and in-depth knowledge, I couldn't. The confusing part is the apparently conflicting claims made by 1st vs. 2nd paragraph. Both talk about setting the deserialization filter - the 1st just says "set the deserialization filter for the stream", and with the `setObjectInputFilter` method having a sole `filter` parameter, together these establish a simple picture - ah, just a setter method. But no, the 2nd paragraph talks about something entirely different which doesn't fit into the established picture. So would it be possible to rephrase that 1st paragraph somehow? Or what about starting with 2nd paragraph: "Set the deserialization filter for the stream to the filter returned by invoking ...." followed by 1st paragraph: "The filter can be set and only set once before reading any objects..." ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From plevart at openjdk.java.net Wed May 26 06:40:21 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 26 May 2021 06:40:21 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v9] In-Reply-To: <-9uaZza9-IuWsHoF0H-lwQVKOf1VJrOb6IhrhuYM3UM=.92fa4961-c488-472e-9c7c-eeb8b535a62d@github.com> References: <-9uaZza9-IuWsHoF0H-lwQVKOf1VJrOb6IhrhuYM3UM=.92fa4961-c488-472e-9c7c-eeb8b535a62d@github.com> Message-ID: On Wed, 26 May 2021 06:21:12 GMT, Peter Levart wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Editorial updates >> Updated java.security properties to include jdk.serialFilterFactory >> Added test cases to SerialFilterFactoryTest for java.security properties and >> enabling of the SecurityManager with existing policy permission files >> Corrected a test that OIS.setObjectInputFilter could not be called twice. >> Removed a Factory test that was not intended to be committed > > src/java.base/share/classes/java/io/ObjectInputStream.java line 1265: > >> 1263: * must return a non-null filter. It is not permitted to remove filtering once established. >> 1264: * See the {@linkplain ObjectInputFilter filter models} for examples of composition and delegation. >> 1265: * > > Hi Roger, > When I first read this javadoc, I was a little confused and had to peek into the implementation. After that, I understood the above text, but without peeking and in-depth knowledge, I couldn't. The confusing part is the apparently conflicting claims made by 1st vs. 2nd paragraph. Both talk about setting the deserialization filter - the 1st just says "set the deserialization filter for the stream", and with the `setObjectInputFilter` method having a sole `filter` parameter, together these establish a simple picture - ah, just a setter method. But no, the 2nd paragraph talks about something entirely different which doesn't fit into the established picture. So would it be possible to rephrase that 1st paragraph somehow? Or what about starting with 2nd paragraph: "Set the deserialization filter for the stream to the filter returned by invoking ...." followed by 1st paragraph: "The filter can be set and only set once before reading any objects..." Also a better wording for the following paragraph could be: "This method can only be called once and before reading any objects with this ObjectInputStream" Talking about "The filter can only be set once" is a little confusing, since the filter may actually already be set to JVM-wide filter when this methods is called to replace it with per-OIS filter. ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From plevart at openjdk.java.net Wed May 26 07:36:17 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 26 May 2021 07:36:17 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v5] In-Reply-To: References: Message-ID: 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 library load operation. >> >> Problem being fixed: >> >> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. >> >> Proposed fix: >> >> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. >> >> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. >> >> Testing: jtreg and jck testing with no regressions. A new regression test was developed. > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > fix whitespace Changes requested by plevart (Reviewer). src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 481: > 479: throw new Error("Maximum lock count exceeded"); > 480: } > 481: Hi Aleksei, I know in practice this counter will never overflow, but just to be pedantic, it would be better that you either decrement back the counter before throwing Error or you check for overflow without incrementing it. Otherwise the lock is left in a corrupted state since you use it like this: acquireNativeLibraryLock(name); try { ... } finally { releaseNativeLibraryLock(name); } ...you see, if acquire fails, it is not paired with release, which is correct since the ReentrantLock has not been acquired, but the counter *HAS* been incremented... ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From sundar at openjdk.java.net Wed May 26 08:03:23 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Wed, 26 May 2021 08:03:23 GMT Subject: RFR: 8267583: jmod fails on symlink to class file Message-ID: FileVisitOption.FOLLOW_LINKS used. Test extended for file symlinks case. ------------- Commit messages: - 8267583: jmod fails on symlink to class file Changes: https://git.openjdk.java.net/jdk/pull/4202/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4202&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267583 Stats: 41 lines in 2 files changed: 39 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4202.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4202/head:pull/4202 PR: https://git.openjdk.java.net/jdk/pull/4202 From pconcannon at openjdk.java.net Wed May 26 09:00:17 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 26 May 2021 09:00:17 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v2] In-Reply-To: References: Message-ID: <0hbVhBGdyJlPs_mHkTacFWwGyHM5JOLnDghCvXoDGdY=.f8e8e70d-3ad3-45f7-9046-21d6721c4ffd@github.com> On Tue, 25 May 2021 15:18:46 GMT, Chris Hegarty wrote: >> Patrick Concannon 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 three additional commits since the last revision: >> >> - 8267670: Updated code to use yield >> - Merge remote-tracking branch 'origin/master' into JDK-8267670 >> - 8267670: Update java.io, java.math, and java.text to use switch expressions > > src/java.base/share/classes/java/io/ObjectStreamClass.java line 2172: > >> 2170: switch (typeCodes[i]) { >> 2171: case 'L', '[' -> vals[offsets[i]] = unsafe.getReference(obj, readKeys[i]); >> 2172: default -> throw new InternalError(); > > suggest: > > vals[offsets[i]] = switch (typeCodes[i]) { > case 'L', '[' -> unsafe.getReference(obj, readKeys[i]); > default -> throw new InternalError(); Comment addressed in e503ed2 > src/java.base/share/classes/java/io/StreamTokenizer.java line 787: > >> 785: case TT_WORD -> ret = sval; >> 786: case TT_NUMBER -> ret = "n=" + nval; >> 787: case TT_NOTHING -> ret = "NOTHING"; > > This is not correct, the assignments to ret in these case arms is redundant. Comment addressed in e503ed2 ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From pconcannon at openjdk.java.net Wed May 26 09:05:34 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 26 May 2021 09:05:34 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v4] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: 8267670: Removed trailing whitespace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4182/files - new: https://git.openjdk.java.net/jdk/pull/4182/files/e503ed26..d4a6cc44 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4182/head:pull/4182 PR: https://git.openjdk.java.net/jdk/pull/4182 From pconcannon at openjdk.java.net Wed May 26 09:39:44 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 26 May 2021 09:39:44 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v4] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 09:05:34 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: > > 8267670: Removed trailing whitespace > _Mailing list message from [Brian Goetz](mailto:brian.goetz at oracle.com) on [core-libs-dev](mailto:core-libs-dev at mail.openjdk.java.net):_ > > In the last hunk, you convert > > case Collator.IDENTICAL: toAddTo.append('='); break; > case Collator.TERTIARY: toAddTo.append(','); break; > case Collator.SECONDARY: toAddTo.append(';'); break; > case Collator.PRIMARY: toAddTo.append('<'); break; > case RESET: toAddTo.append('&'); break; > case UNSET: toAddTo.append('?'); break; > > to > > case Collator.IDENTICAL -> toAddTo.append('='); > case Collator.TERTIARY -> toAddTo.append(','); > case Collator.SECONDARY -> toAddTo.append(';'); > case Collator.PRIMARY -> toAddTo.append('<'); > case RESET -> toAddTo.append('&'); > case UNSET -> toAddTo.append('?'); > > But, you can go further, pulling the toAddTo.append() call out of the switch. This was one of the benefits we anticipated with expression switches; that it would expose more opportunities to push the conditional logic farther down towards the leaves. I suspect there are other opportunities for this in this patch too. Hi Brian, Thanks for your suggestion. I've incorporated it into the PR, and you can find it in commit e503ed2 ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From pconcannon at openjdk.java.net Wed May 26 09:39:44 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 26 May 2021 09:39:44 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v5] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon 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 six additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Removed trailing whitespace - 8267670: Remove redundant code from switch - 8267670: Updated code to use yield - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Update java.io, java.math, and java.text to use switch expressions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4182/files - new: https://git.openjdk.java.net/jdk/pull/4182/files/d4a6cc44..ad7aeacd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=03-04 Stats: 1031 lines in 36 files changed: 717 ins; 101 del; 213 mod Patch: https://git.openjdk.java.net/jdk/pull/4182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4182/head:pull/4182 PR: https://git.openjdk.java.net/jdk/pull/4182 From dfuchs at openjdk.java.net Wed May 26 10:01:17 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 26 May 2021 10:01:17 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v5] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 09:39:44 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon 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 six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Removed trailing whitespace > - 8267670: Remove redundant code from switch > - 8267670: Updated code to use yield > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Update java.io, java.math, and java.text to use switch expressions Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From alanb at openjdk.java.net Wed May 26 10:10:13 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 26 May 2021 10:10:13 GMT Subject: RFR: 8267583: jmod fails on symlink to class file In-Reply-To: References: Message-ID: On Wed, 26 May 2021 07:55:53 GMT, Athijegannathan Sundararajan wrote: > FileVisitOption.FOLLOW_LINKS used. Test extended for file symlinks case. It strikes me a bit unusual to be following sym links here but okay. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4202 From pconcannon at openjdk.java.net Wed May 26 10:24:34 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 26 May 2021 10:24:34 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v6] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: 8267670: Added missing brace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4182/files - new: https://git.openjdk.java.net/jdk/pull/4182/files/ad7aeacd..a0dfbeba Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=04-05 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4182/head:pull/4182 PR: https://git.openjdk.java.net/jdk/pull/4182 From pconcannon at openjdk.java.net Wed May 26 10:30:43 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 26 May 2021 10:30:43 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v7] In-Reply-To: References: Message-ID: <5H6mlbt9InJc2lxeoRA-YxxVGa67EcT2ErCojXKj22Y=.5df1c233-91bc-4ad0-8d84-30418c9f56f3@github.com> > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon 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 eight additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Added missing brace - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Removed trailing whitespace - 8267670: Remove redundant code from switch - 8267670: Updated code to use yield - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Update java.io, java.math, and java.text to use switch expressions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4182/files - new: https://git.openjdk.java.net/jdk/pull/4182/files/a0dfbeba..57184fbf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=05-06 Stats: 29 lines in 1 file changed: 17 ins; 5 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4182/head:pull/4182 PR: https://git.openjdk.java.net/jdk/pull/4182 From sundar at openjdk.java.net Wed May 26 11:08:19 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Wed, 26 May 2021 11:08:19 GMT Subject: Integrated: 8267583: jmod fails on symlink to class file In-Reply-To: References: Message-ID: On Wed, 26 May 2021 07:55:53 GMT, Athijegannathan Sundararajan wrote: > FileVisitOption.FOLLOW_LINKS used. Test extended for file symlinks case. This pull request has now been integrated. Changeset: bf8d4a8e Author: Athijegannathan Sundararajan URL: https://git.openjdk.java.net/jdk/commit/bf8d4a8ecab216e7d117ce045d4498d1fa1a6029 Stats: 41 lines in 2 files changed: 39 ins; 0 del; 2 mod 8267583: jmod fails on symlink to class file Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/4202 From rriggs at openjdk.java.net Wed May 26 12:12:25 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 26 May 2021 12:12:25 GMT Subject: RFR: 8267751: (test) jtreg.SkippedException has no serial VersionUID Message-ID: The class `test/lib/jtreg/SkippedException.java` is missing a serialVersionUID causing additional noise in compiler output of tests. ------------- Commit messages: - Added serialVersionUID to jtreg.SkippedException to eliminate compilation warnings Changes: https://git.openjdk.java.net/jdk/pull/4197/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4197&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267751 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4197.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4197/head:pull/4197 PR: https://git.openjdk.java.net/jdk/pull/4197 From naoto at openjdk.java.net Wed May 26 13:18:15 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 26 May 2021 13:18:15 GMT Subject: RFR: 8267751: (test) jtreg.SkippedException has no serial VersionUID In-Reply-To: References: Message-ID: On Wed, 26 May 2021 01:28:17 GMT, Roger Riggs wrote: > The class `test/lib/jtreg/SkippedException.java` is missing a serialVersionUID causing additional noise in compiler output of tests. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4197 From lancea at openjdk.java.net Wed May 26 15:55:16 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 26 May 2021 15:55:16 GMT Subject: RFR: 8265248: Implementation Specific Properties: change prefix, plus add existing properties [v7] In-Reply-To: <5CFkK-ZiUWcGA7prREKAF-XaRCIudLdkoqjxrRnF-Vg=.786174c1-eece-4a91-a312-c57043847a24@github.com> References: <5CFkK-ZiUWcGA7prREKAF-XaRCIudLdkoqjxrRnF-Vg=.786174c1-eece-4a91-a312-c57043847a24@github.com> Message-ID: On Mon, 24 May 2021 06:23:59 GMT, Joe Wang wrote: >> Update module summary, add a few existing properties and features into the tables. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > Consolidated impl specific properties; deprecated legacy properties; made new ones take preference Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3644 From naoto at openjdk.java.net Wed May 26 15:56:19 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 26 May 2021 15:56:19 GMT Subject: Integrated: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current In-Reply-To: References: Message-ID: <8xyafh6jhUyivyq8jtpLoQ4HX9YX-R0wHNZ2VpWTyxY=.1a12a544-1668-49b7-bafd-ed833a292b91@github.com> On Mon, 17 May 2021 16:55:35 GMT, Naoto Sato wrote: > Please review the changes to the subject issue. java.util.Locale class has a long-standing issue for those obsolete ISO 639 languages where its normalization ends up in the obsolete codes. This change intends to flip the normalization towards the current codes, providing a system property for compatibility behavior. ResourceBundle class is also modified to load either obsolete/current bundles. For more detail, take a look at the CSR. This pull request has now been integrated. Changeset: a4c46e1e Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/a4c46e1e4f4f2f05c8002b2af683a390fc46b424 Stats: 386 lines in 35 files changed: 240 ins; 41 del; 105 mod 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current Reviewed-by: joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/4069 From rriggs at openjdk.java.net Wed May 26 16:48:57 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 26 May 2021 16:48:57 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v8] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 21:53:26 GMT, Brent Christian wrote: >> Roger Riggs has updated the pull request incrementally with two additional commits since the last revision: >> >> - Moved utility filter methods to be static on ObjectInputFilter >> Rearranged the class javadoc of OIF to describe the parts of >> deserialization filtering, filters, composite filters, and the filter factory. >> And other review comment updates... >> - Refactored tests for utility functions to SerialFilterFunctionTest.java >> Deleted confused Config.allowMaxLimits() method >> Updated example to match move of methods to Config >> Added test of restriction on setting the filterfactory after a OIS has been created >> Additional Editorial updates > > src/java.base/share/classes/java/io/ObjectInputFilter.java line 205: > >> 203: * // Returns a composite filter of the static JVM-wide filter, a thread-specific filter, >> 204: * // and the stream-specific filter. >> 205: * public ObjectInputFilter apply(ObjectInputFilter curr, ObjectInputFilter next) { > > `@Override` on `apply` ? yes, but omitted to make the code more readable. ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From rriggs at openjdk.java.net Wed May 26 16:48:53 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 26 May 2021 16:48:53 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v10] In-Reply-To: References: Message-ID: > JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. > The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional > configuration mechanisms and filter utilities. > > javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: > http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Editorial updates to review comments. Simplify the builtin filter factory implementation. Add atomic update to setting the filter factory. Clarify the description of OIS.setObjectInputFilter. Cleanup of the example code. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3996/files - new: https://git.openjdk.java.net/jdk/pull/3996/files/b83da61a..a65d6205 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=08-09 Stats: 102 lines in 3 files changed: 27 ins; 41 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/3996.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3996/head:pull/3996 PR: https://git.openjdk.java.net/jdk/pull/3996 From rriggs at openjdk.java.net Wed May 26 16:49:01 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 26 May 2021 16:49:01 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v9] In-Reply-To: References: <-9uaZza9-IuWsHoF0H-lwQVKOf1VJrOb6IhrhuYM3UM=.92fa4961-c488-472e-9c7c-eeb8b535a62d@github.com> Message-ID: On Wed, 26 May 2021 06:35:46 GMT, Peter Levart wrote: >> src/java.base/share/classes/java/io/ObjectInputStream.java line 1265: >> >>> 1263: * must return a non-null filter. It is not permitted to remove filtering once established. >>> 1264: * See the {@linkplain ObjectInputFilter filter models} for examples of composition and delegation. >>> 1265: * >> >> Hi Roger, >> When I first read this javadoc, I was a little confused and had to peek into the implementation. After that, I understood the above text, but without peeking and in-depth knowledge, I couldn't. The confusing part is the apparently conflicting claims made by 1st vs. 2nd paragraph. Both talk about setting the deserialization filter - the 1st just says "set the deserialization filter for the stream", and with the `setObjectInputFilter` method having a sole `filter` parameter, together these establish a simple picture - ah, just a setter method. But no, the 2nd paragraph talks about something entirely different which doesn't fit into the established picture. So would it be possible to rephrase that 1st paragraph somehow? Or what about starting with 2nd paragraph: "Set the deserialization filter for the stream to the filter returned by invoking ...." followed by 1st paragraph: "The filter can be set and only set once before reading any objects..." > > Also a better wording for the following paragraph could be: "This method can only be called once and before reading any objects with this ObjectInputStream" > Talking about "The filter can only be set once" is a little confusing, since the filter may actually already be set to JVM-wide filter when this methods is called to replace it with per-OIS filter. Rewrote and included your suggestions. ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From rriggs at openjdk.java.net Wed May 26 16:48:59 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 26 May 2021 16:48:59 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v9] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 23:25:41 GMT, Brent Christian wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Editorial updates >> Updated java.security properties to include jdk.serialFilterFactory >> Added test cases to SerialFilterFactoryTest for java.security properties and >> enabling of the SecurityManager with existing policy permission files >> Corrected a test that OIS.setObjectInputFilter could not be called twice. >> Removed a Factory test that was not intended to be committed > > src/java.base/share/classes/java/io/ObjectInputFilter.java line 551: > >> 549: final class Config { >> 550: /** >> 551: * Lock object for filter and filter factory. > > The lock is not used for the filter factory, is it? The lock was needed for the factory to make the check and setting atomic. ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From rriggs at openjdk.java.net Wed May 26 17:52:31 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 26 May 2021 17:52:31 GMT Subject: RFR: 8267751: (test) jtreg.SkippedException has no serial VersionUID [v2] In-Reply-To: References: Message-ID: > The class `test/lib/jtreg/SkippedException.java` is missing a serialVersionUID causing additional noise in compiler output of tests. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Removed unintended classfile ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4197/files - new: https://git.openjdk.java.net/jdk/pull/4197/files/8c629b22..7aff0846 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4197&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4197&range=00-01 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4197.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4197/head:pull/4197 PR: https://git.openjdk.java.net/jdk/pull/4197 From jlahoda at openjdk.java.net Wed May 26 17:52:36 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 26 May 2021 17:52:36 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: > 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/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac. - Correcting LineNumberTable for rule switches. - Merging master into JDK-8262891 - Fixing various error-related bugs. - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default. - Reflecting recent spec changes. - Reflecting review comments. - Reflecting review comments on SwitchBootstraps. - Trailing whitespaces. - Cleanup, reflecting review comments. - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501 ------------- Changes: https://git.openjdk.java.net/jdk/pull/3863/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=04 Stats: 4551 lines in 77 files changed: 4235 ins; 119 del; 197 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From rriggs at openjdk.java.net Wed May 26 18:01:23 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 26 May 2021 18:01:23 GMT Subject: RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams [v4] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 16:53:28 GMT, Roger Riggs wrote: >> Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process. >> The Charset used to encode and decode characters to bytes can be specified or use the >> operating system native encoding as is available from the "native.encoding" system property. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Described charset mapping of malformed chars in outputWriter > Repeated calls to inputReader, errorReader, and outputWriter now return the same instance > and check for inconsistent charset argument > Added warnings about concurrently use of input/output streams and readers/writers. Process is abstract. Is there any use for these new methods to be overridden? Perhaps they should be final. The suggestion in the CSR was to document them using @ implSpec, to acknowledge that the subclass can do something different. ------------- PR: https://git.openjdk.java.net/jdk/pull/4134 From iignatyev at openjdk.java.net Wed May 26 18:04:16 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 26 May 2021 18:04:16 GMT Subject: RFR: 8267751: (test) jtreg.SkippedException has no serial VersionUID [v2] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 17:52:31 GMT, Roger Riggs wrote: >> The class `test/lib/jtreg/SkippedException.java` is missing a serialVersionUID causing additional noise in compiler output of tests. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Removed unintended classfile LGTM ------------- Marked as reviewed by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4197 From rriggs at openjdk.java.net Wed May 26 18:12:13 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 26 May 2021 18:12:13 GMT Subject: RFR: 8265248: Implementation Specific Properties: change prefix, plus add existing properties [v7] In-Reply-To: <5CFkK-ZiUWcGA7prREKAF-XaRCIudLdkoqjxrRnF-Vg=.786174c1-eece-4a91-a312-c57043847a24@github.com> References: <5CFkK-ZiUWcGA7prREKAF-XaRCIudLdkoqjxrRnF-Vg=.786174c1-eece-4a91-a312-c57043847a24@github.com> Message-ID: On Mon, 24 May 2021 06:23:59 GMT, Joe Wang wrote: >> Update module summary, add a few existing properties and features into the tables. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > Consolidated impl specific properties; deprecated legacy properties; made new ones take preference Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3644 From rriggs at openjdk.java.net Wed May 26 18:35:21 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 26 May 2021 18:35:21 GMT Subject: RFR: 8267123: Remove RMI Activation In-Reply-To: References: Message-ID: On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to various comments to remove references to Activation > - adjustments to some code to remove special-case support for Activation from core RMI > - adjustments to several tests to remove testing and support for, and mentions of Activation > - remove `rmid` tool > > (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4194 From rriggs at openjdk.java.net Wed May 26 18:41:05 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 26 May 2021 18:41:05 GMT Subject: RFR: 8187649: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar In-Reply-To: References: Message-ID: On Tue, 25 May 2021 16:40:53 GMT, Naoto Sato wrote: > Please review the fix. The issue was informed yesterday by @amaembo that it offends some code analysis tools. > Although the fix is to change the condition error, it turned out that `JapaneseImperialCalendar.roll()` did not work for `WEEK_OF_MONTH` and `DAY_OF_MONTH`. There was an inherent issue where `GregorianCalendar` does not follow the `roll()` spec, i.e., "The MONTH must not change when the WEEK_OF_MONTH is rolled." during the Julian/Gregorian transition. JDK-6191841 seems to have tried to fix it but it was closed as `Future Project`... > So I simply fixed the `roll()` issue in `JapaneseImperialCalendar` to follow the spec here, which seems to be the intent of the original author. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4191 From iris at openjdk.java.net Wed May 26 18:53:53 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 26 May 2021 18:53:53 GMT Subject: RFR: 8267751: (test) jtreg.SkippedException has no serial VersionUID [v2] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 17:52:31 GMT, Roger Riggs wrote: >> The class `test/lib/jtreg/SkippedException.java` is missing a serialVersionUID causing additional noise in compiler output of tests. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Removed unintended classfile Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4197 From joehw at openjdk.java.net Wed May 26 19:37:10 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 26 May 2021 19:37:10 GMT Subject: Integrated: 8265248: Implementation Specific Properties: change prefix, plus add existing properties In-Reply-To: References: Message-ID: <0dqbAbtz9Aj82iOStQ3TeTEj3v6K7AaJgPJKQoRLgI4=.349604f3-030b-4628-a303-2dd3ab576b89@github.com> On Fri, 23 Apr 2021 00:41:17 GMT, Joe Wang wrote: > Update module summary, add a few existing properties and features into the tables. This pull request has now been integrated. Changeset: 8c4719a5 Author: Joe Wang URL: https://git.openjdk.java.net/jdk/commit/8c4719a58834dddcea39d69b199abf1aabf780e2 Stats: 2869 lines in 61 files changed: 1571 ins; 678 del; 620 mod 8265248: Implementation Specific Properties: change prefix, plus add existing properties Reviewed-by: lancea, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/3644 From jlahoda at openjdk.java.net Wed May 26 19:42:12 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 26 May 2021 19:42:12 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 17:52:36 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/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac. > - Correcting LineNumberTable for rule switches. > - Merging master into JDK-8262891 > - Fixing various error-related bugs. > - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default. > - Reflecting recent spec changes. > - Reflecting review comments. > - Reflecting review comments on SwitchBootstraps. > - Trailing whitespaces. > - Cleanup, reflecting review comments. > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501 In: https://github.com/openjdk/jdk/pull/3863/commits/7d1abc141ecfecaf0798a2bad899705c116154e7 I've updated the code to produce better/more useful LineNumberTable for rule switches. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From smarks at openjdk.java.net Wed May 26 19:49:04 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 26 May 2021 19:49:04 GMT Subject: RFR: 8267123: Remove RMI Activation In-Reply-To: References: Message-ID: <6dMALeSEys26_TFkj3m4WSgOehMYVZuZzUHRQf9kp3I=.b3b00dab-9265-4522-88e6-fc0cb9593a3f@github.com> On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to various comments to remove references to Activation > - adjustments to some code to remove special-case support for Activation from core RMI > - adjustments to several tests to remove testing and support for, and mentions of Activation > - remove `rmid` tool > > (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) AlanBateman wrote: > test/jdk/sun/rmi/log/ReliableLog/LogAlignmentTest.java Oh yes, this test mentions `rmid`, but it is basically a direct test of the `ReliableLog` stuff and it doesn't actually use or depend on Activation or `rmid`. The test still runs and passes. I'll do a followup pass to see if anything in the system uses anything in the `sun.rmi.log` package. Maybe the only user was Activation. ------------- PR: https://git.openjdk.java.net/jdk/pull/4194 From forax at openjdk.java.net Wed May 26 20:24:06 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 26 May 2021 20:24:06 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: <6SO8Ij_klMovO-wcF_I8rjji8VVd8-BSergVJ_4K7ZQ=.f04b7334-b9ee-46c5-9c0e-93d79a015004@github.com> References: <6SO8Ij_klMovO-wcF_I8rjji8VVd8-BSergVJ_4K7ZQ=.f04b7334-b9ee-46c5-9c0e-93d79a015004@github.com> Message-ID: On Tue, 25 May 2021 16:14:56 GMT, Jan Lahoda wrote: > I'd like to note this is a preview feature - we can change the desugaring. At the same time, I don't think this does not work with sub-patterns (those can be easily desugared to guards, I think). Yes, but in that case the classcheck du to a sub-pattern matching will be either an instanceof or some other invokedynamic. Having several indy will bloat the code and if we use instanceof, why not using instanceof all along the way. > Regarding efficiency, it may be a balance between classfile overhead (which will be higher if we need to desugar every guard to a separate method), and the possibility to tweak the matching at runtime. I fear more the 2 bytes length bytecode limit of a method than the constant pool length limit mostly because people are already using a bunch of lambdas to simulate pattern matching. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From gziemski at openjdk.java.net Wed May 26 20:59:06 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 26 May 2021 20:59:06 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v2] In-Reply-To: References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> Message-ID: On Tue, 25 May 2021 09:45:34 GMT, Maxim Kartashev wrote: >> Character strings within JVM are produced and consumed in several formats. Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or dlopen()) consume strings also in UTF8. On Windows, however, the situation is far less simple: some new(er) APIs expect UTF16 (wide-character strings), some older APIs can only work with strings in a "platform" format, where not all UTF8 characters can be represented; which ones can depends on the current "code page". >> >> This commit switches the Windows version of native library loading code to using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use of various string formats in the surrounding code. >> >> Namely, exception messages are made to consume strings explicitly in the UTF8 format, while logging functions (that end up using legacy Windows API) are made to consume "platform" strings in most cases. One exception is `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, which can, of course, be fixed, but was considered not worth the additional code (NB: this isn't a new bug). >> >> The test runs in a separate JVM in order to make NIO happy about non-ASCII characters in the file name; tests are executed with LC_ALL=C and that doesn't let NIO work with non-ASCII file names even on Linux or MacOS. >> >> Tested by running `test/hotspot/jtreg:tier1` on Linux and `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (` jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran on those platforms as well. >> >> Results from Linux: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg:tier1 1784 1784 0 0 >> ============================== >> TEST SUCCESS >> >> >> Building target 'run-test-only' in configuration 'linux-x86_64-server-release' >> Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: >> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode >> >> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' >> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java >> Test results: passed: 1 >> >> >> Results from Windows 10: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg/runtime 746 746 0 0 >> ============================== >> TEST SUCCESS >> Finished building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' >> >> >> Building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' >> Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: >> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode >> >> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' >> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java >> Test results: passed: 1 > > Maxim Kartashev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8195129: System.load() fails to load from unicode paths I tried verifying the test on **macOS** by running: `jtreg -nr -va -jdk:./build/macosx-x86_64-server-fastdebug/images/jdk test/hotspot/jtreg/runtime/jni/loadLibraryUnicode` and I get: `TEST RESULT: Error. Use -nativepath to specify the location of native code` I looked at the test and thought it was handling loading the native lib on its own, without the test needing to set **nativepath** explicitly. What am I doing wrong? ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From mr at openjdk.java.net Wed May 26 20:59:13 2021 From: mr at openjdk.java.net (Mark Reinhold) Date: Wed, 26 May 2021 20:59:13 GMT Subject: Integrated: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals In-Reply-To: References: Message-ID: <9NYZ1R5LctYzlt6HwT2lWjSmUtWfbnwYpQYa4guwn0Q=.f2fc355a-d587-403b-94df-c9464346a68d@github.com> On Thu, 13 May 2021 17:14:36 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. This pull request has now been integrated. Changeset: e6302354 Author: Mark Reinhold URL: https://git.openjdk.java.net/jdk/commit/e63023546aaf48ae39c72ab37f6ef3f5474e19cc Stats: 2842 lines in 26 files changed: 0 ins; 2792 del; 50 mod 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals Co-authored-by: Alan Bateman Reviewed-by: mchung, alanb, hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/4015 From rriggs at openjdk.java.net Wed May 26 21:37:40 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 26 May 2021 21:37:40 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v11] In-Reply-To: References: Message-ID: <3BxQaodZQwM1Ik1NcDGwe-BwJDVxQK442GbNkTAayrY=.1b2bcd88-013e-4e7f-a3fe-9d5bff253f3f@github.com> > JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. > The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional > configuration mechanisms and filter utilities. > > javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: > http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Added test for rejectUndecidedClass array cases Added test for preventing disabling filter factory Test cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3996/files - new: https://git.openjdk.java.net/jdk/pull/3996/files/a65d6205..19b6aad3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=09-10 Stats: 71 lines in 3 files changed: 55 ins; 7 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3996.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3996/head:pull/3996 PR: https://git.openjdk.java.net/jdk/pull/3996 From naoto at openjdk.java.net Wed May 26 21:42:14 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 26 May 2021 21:42:14 GMT Subject: RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams [v4] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 16:53:28 GMT, Roger Riggs wrote: >> Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process. >> The Charset used to encode and decode characters to bytes can be specified or use the >> operating system native encoding as is available from the "native.encoding" system property. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Described charset mapping of malformed chars in outputWriter > Repeated calls to inputReader, errorReader, and outputWriter now return the same instance > and check for inconsistent charset argument > Added warnings about concurrently use of input/output streams and readers/writers. src/java.base/share/classes/java/lang/Process.java line 254: > 252: * {@code > 253: * return new BufferedReader(new InputStreamReader(getInputStream(), charset)); > 254: * } Does not seem to be equivalent any longer. Also, should it describe the behavior that it rejects the different Charset after the first invocation? src/java.base/share/classes/java/lang/Process.java line 326: > 324: * {@code > 325: * return new BufferedReader(new InputStreamReader(getErrorStream(), charset)); > 326: * } Same comment in `inputReader(Charset)` stands here too. ------------- PR: https://git.openjdk.java.net/jdk/pull/4134 From rriggs at openjdk.java.net Wed May 26 22:06:14 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 26 May 2021 22:06:14 GMT Subject: Integrated: 8267751: (test) jtreg.SkippedException has no serial VersionUID In-Reply-To: References: Message-ID: On Wed, 26 May 2021 01:28:17 GMT, Roger Riggs wrote: > The class `test/lib/jtreg/SkippedException.java` is missing a serialVersionUID causing additional noise in compiler output of tests. This pull request has now been integrated. Changeset: 0fc7c8d1 Author: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/0fc7c8d101d526f1bc86831996b6883209d77451 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8267751: (test) jtreg.SkippedException has no serial VersionUID Reviewed-by: naoto, iignatyev, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/4197 From rriggs at openjdk.java.net Wed May 26 22:11:54 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 26 May 2021 22:11:54 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v12] In-Reply-To: References: Message-ID: > JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. > The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional > configuration mechanisms and filter utilities. > > javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: > http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html Roger Riggs 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 revision: - Merge branch 'master' into 8264859-context-filter-factory - Added test for rejectUndecidedClass array cases Added test for preventing disabling filter factory Test cleanup - Editorial updates to review comments. Simplify the builtin filter factory implementation. Add atomic update to setting the filter factory. Clarify the description of OIS.setObjectInputFilter. Cleanup of the example code. - Editorial updates Updated java.security properties to include jdk.serialFilterFactory Added test cases to SerialFilterFactoryTest for java.security properties and enabling of the SecurityManager with existing policy permission files Corrected a test that OIS.setObjectInputFilter could not be called twice. Removed a Factory test that was not intended to be committed - Moved utility filter methods to be static on ObjectInputFilter Rearranged the class javadoc of OIF to describe the parts of deserialization filtering, filters, composite filters, and the filter factory. And other review comment updates... - Refactored tests for utility functions to SerialFilterFunctionTest.java Deleted confused Config.allowMaxLimits() method Updated example to match move of methods to Config Added test of restriction on setting the filterfactory after a OIS has been created Additional Editorial updates - Move merge and rejectUndecidedClass methods to OIF.Config As default methods on OIF, their implementations were not concrete and not trustable - Review suggestions included; Added @implSpec for default methods in OIF; Added restriction that the filter factory cannot be set after an ObjectInputStream has been created and applied the current filter factory - Editorial javadoc updated based on review comments. Clarified behavior of rejectUndecidedClass method. Example test added to check status returned from file. - Editorial updates to review comments Add filter tracing support - ... and 3 more: https://git.openjdk.java.net/jdk/compare/9870b028...0930f0f8 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3996/files - new: https://git.openjdk.java.net/jdk/pull/3996/files/19b6aad3..0930f0f8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=10-11 Stats: 44803 lines in 2037 files changed: 20137 ins; 18278 del; 6388 mod Patch: https://git.openjdk.java.net/jdk/pull/3996.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3996/head:pull/3996 PR: https://git.openjdk.java.net/jdk/pull/3996 From bchristi at openjdk.java.net Wed May 26 23:36:11 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Wed, 26 May 2021 23:36:11 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v10] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 16:48:53 GMT, Roger Riggs wrote: >> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. >> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional >> configuration mechanisms and filter utilities. >> >> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: >> http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Editorial updates to review comments. > Simplify the builtin filter factory implementation. > Add atomic update to setting the filter factory. > Clarify the description of OIS.setObjectInputFilter. > Cleanup of the example code. test/jdk/java/io/Serializable/serialFilter/SerialFilterFactoryTest.java line 328: > 326: public void current(ObjectInputFilter current) { > 327: this.current = current; > 328: } Is this current() used anywhere ? test/jdk/java/io/Serializable/serialFilter/SerialFilterFactoryTest.java line 332: > 330: public void next(ObjectInputFilter next) { > 331: this. next = next; > 332: } Is this next() used anywhere ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From mchung at openjdk.java.net Wed May 26 23:47:06 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 26 May 2021 23:47:06 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v5] In-Reply-To: References: Message-ID: 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 library load operation. >> >> Problem being fixed: >> >> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. >> >> Proposed fix: >> >> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. >> >> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. >> >> Testing: jtreg and jck testing with no regressions. A new regression test was developed. > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > fix whitespace Hi Aleksei, I'll review it next week as I'm taking some time off this week. Mandy ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From rriggs at openjdk.java.net Thu May 27 00:52:13 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 27 May 2021 00:52:13 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v10] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 22:02:36 GMT, Brent Christian wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Editorial updates to review comments. >> Simplify the builtin filter factory implementation. >> Add atomic update to setting the filter factory. >> Clarify the description of OIS.setObjectInputFilter. >> Cleanup of the example code. > > test/jdk/java/io/Serializable/serialFilter/SerialFilterFactoryTest.java line 332: > >> 330: public void next(ObjectInputFilter next) { >> 331: this. next = next; >> 332: } > > Is this next() used anywhere ? Neither is used, IntellJ was happy to create getters and setters... Can be removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From david.holmes at oracle.com Thu May 27 04:14:19 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 May 2021 14:14:19 +1000 Subject: RFR: 8195129: System.load() fails to load from unicode paths [v2] In-Reply-To: References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> Message-ID: On 27/05/2021 6:59 am, Gerard Ziemski wrote: > On Tue, 25 May 2021 09:45:34 GMT, Maxim Kartashev wrote: > I tried verifying the test on **macOS** by running: > > `jtreg -nr -va -jdk:./build/macosx-x86_64-server-fastdebug/images/jdk test/hotspot/jtreg/runtime/jni/loadLibraryUnicode` > > and I get: > > `TEST RESULT: Error. Use -nativepath to specify the location of native code` > > I looked at the test and thought it was handling loading the native lib on its own, without the test needing to set **nativepath** explicitly. What am I doing wrong? You always have to set nativepath explicitly for jtreg. The test then reads the property that jtreg defines using the value of -nativepath: String testNativePath = LoadLibraryUnicodeTest.getSystemProperty("test.nativepath"); Cheers, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4169 > From dholmes at openjdk.java.net Thu May 27 05:08:07 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 27 May 2021 05:08:07 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v2] In-Reply-To: References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> Message-ID: On Tue, 25 May 2021 09:45:34 GMT, Maxim Kartashev wrote: >> Character strings within JVM are produced and consumed in several formats. Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or dlopen()) consume strings also in UTF8. On Windows, however, the situation is far less simple: some new(er) APIs expect UTF16 (wide-character strings), some older APIs can only work with strings in a "platform" format, where not all UTF8 characters can be represented; which ones can depends on the current "code page". >> >> This commit switches the Windows version of native library loading code to using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use of various string formats in the surrounding code. >> >> Namely, exception messages are made to consume strings explicitly in the UTF8 format, while logging functions (that end up using legacy Windows API) are made to consume "platform" strings in most cases. One exception is `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, which can, of course, be fixed, but was considered not worth the additional code (NB: this isn't a new bug). >> >> The test runs in a separate JVM in order to make NIO happy about non-ASCII characters in the file name; tests are executed with LC_ALL=C and that doesn't let NIO work with non-ASCII file names even on Linux or MacOS. >> >> Tested by running `test/hotspot/jtreg:tier1` on Linux and `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (` jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran on those platforms as well. >> >> Results from Linux: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg:tier1 1784 1784 0 0 >> ============================== >> TEST SUCCESS >> >> >> Building target 'run-test-only' in configuration 'linux-x86_64-server-release' >> Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: >> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode >> >> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' >> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java >> Test results: passed: 1 >> >> >> Results from Windows 10: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg/runtime 746 746 0 0 >> ============================== >> TEST SUCCESS >> Finished building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' >> >> >> Building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' >> Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: >> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode >> >> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' >> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java >> Test results: passed: 1 > > Maxim Kartashev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8195129: System.load() fails to load from unicode paths Hi Maxim, Please don't force-push changes once you have opened a PR and review has commenced as it messes up the history and comments. Just push each commit directly. The final integration will squash everything into one clean commit. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From dholmes at openjdk.java.net Thu May 27 05:28:06 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 27 May 2021 05:28:06 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v2] In-Reply-To: References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> Message-ID: On Tue, 25 May 2021 09:45:34 GMT, Maxim Kartashev wrote: >> Character strings within JVM are produced and consumed in several formats. Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or dlopen()) consume strings also in UTF8. On Windows, however, the situation is far less simple: some new(er) APIs expect UTF16 (wide-character strings), some older APIs can only work with strings in a "platform" format, where not all UTF8 characters can be represented; which ones can depends on the current "code page". >> >> This commit switches the Windows version of native library loading code to using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use of various string formats in the surrounding code. >> >> Namely, exception messages are made to consume strings explicitly in the UTF8 format, while logging functions (that end up using legacy Windows API) are made to consume "platform" strings in most cases. One exception is `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, which can, of course, be fixed, but was considered not worth the additional code (NB: this isn't a new bug). >> >> The test runs in a separate JVM in order to make NIO happy about non-ASCII characters in the file name; tests are executed with LC_ALL=C and that doesn't let NIO work with non-ASCII file names even on Linux or MacOS. >> >> Tested by running `test/hotspot/jtreg:tier1` on Linux and `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (` jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran on those platforms as well. >> >> Results from Linux: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg:tier1 1784 1784 0 0 >> ============================== >> TEST SUCCESS >> >> >> Building target 'run-test-only' in configuration 'linux-x86_64-server-release' >> Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: >> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode >> >> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' >> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java >> Test results: passed: 1 >> >> >> Results from Windows 10: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg/runtime 746 746 0 0 >> ============================== >> TEST SUCCESS >> Finished building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' >> >> >> Building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' >> Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: >> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode >> >> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' >> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java >> Test results: passed: 1 > > Maxim Kartashev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8195129: System.load() fails to load from unicode paths Hi Maxim, Overall this seems okay. I've focused mainly on the hotspot parts, including the test. A few minor changes requested. I do have some concerns about the impact on startup though and the efficiency of the conversion routines. Thanks, David src/hotspot/os/windows/os_windows.cpp line 1462: > 1460: const int flag_source_str_is_null_terminated = -1; > 1461: const int flag_estimate_chars_count = 0; > 1462: int utf16_chars_count_estimated = MultiByteToWideChar(source_encoding, Your local naming style is somewhat excessive. You could just comment the values of the flags when you pass them eg: MultiByteToWideChar(source_encoding, MB_ERR_INVALID_CHARS, source_str, -1, //source is null-terminated NULL, // no output buffer 0); // calculate required buffer size Or you could just add a comment before the call: // Perform a dummy conversion so that we can get the required size of the buffer to // allocate. The source is null-terminated. Trying to document parameter semantics by variable naming doesn't work in my opinion - at some point if you want to know you have to RTFM for the API. And utf16_len is perfectly adequate for the returned size. src/hotspot/os/windows/os_windows.cpp line 1541: > 1539: void * os::dll_load(const char *utf8_name, char *ebuf, int ebuflen) { > 1540: LPWSTR utf16_name = NULL; > 1541: errno_t err = convert_UTF8_to_UTF16(utf8_name, &utf16_name); Do you have any figures on the cost of this additional conversion in relation to startup time? I'm already concerned to see that we have to perform each conversion twice via MultiByteToWideChar/WideCharToMultiByte, once to get the size and then to actually get the characters! This seems potentially very inefficient. test/hotspot/jtreg/runtime/jni/loadLibraryUnicode/LoadLibraryUnicode.java line 48: > 46: } else { > 47: throw new Error("Unsupported OS"); > 48: } Please use the test library function `Platform.sharedLibraryExt()` to get the library file extension. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4169 From alanb at openjdk.java.net Thu May 27 05:53:14 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 27 May 2021 05:53:14 GMT Subject: RFR: 8267123: Remove RMI Activation In-Reply-To: References: Message-ID: On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to various comments to remove references to Activation > - adjustments to some code to remove special-case support for Activation from core RMI > - adjustments to several tests to remove testing and support for, and mentions of Activation > - remove `rmid` tool > > (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4194 From tvaleev at openjdk.java.net Thu May 27 06:13:40 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Thu, 27 May 2021 06:13:40 GMT Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit) [v8] In-Reply-To: References: Message-ID: > With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch. > > Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch: > > ref.SliceToList.seq_baseline:?gc.alloc.rate.norm 10000 thrpt 10 40235,534 ? 0,984 B/op > ref.SliceToList.seq_limit:?gc.alloc.rate.norm 10000 thrpt 10 106431,101 ? 0,198 B/op > ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm 10000 thrpt 10 106544,977 ? 1,983 B/op > value.SliceToArray.seq_baseline:?gc.alloc.rate.norm 10000 thrpt 10 40121,878 ? 0,247 B/op > value.SliceToArray.seq_limit:?gc.alloc.rate.norm 10000 thrpt 10 106317,693 ? 1,083 B/op > value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm 10000 thrpt 10 106430,954 ? 0,136 B/op > > > After patch: > > ref.SliceToList.seq_baseline:?gc.alloc.rate.norm 10000 thrpt 10 40235,648 ? 1,354 B/op > ref.SliceToList.seq_limit:?gc.alloc.rate.norm 10000 thrpt 10 40355,784 ? 1,288 B/op > ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm 10000 thrpt 10 40476,032 ? 2,855 B/op > value.SliceToArray.seq_baseline:?gc.alloc.rate.norm 10000 thrpt 10 40121,830 ? 0,308 B/op > value.SliceToArray.seq_limit:?gc.alloc.rate.norm 10000 thrpt 10 40242,554 ? 0,443 B/op > value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm 10000 thrpt 10 40363,674 ? 1,576 B/op > > > Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests. > > Before patch: > > Benchmark (size) Mode Cnt Score Error Units > ref.SliceToList.par_baseline 10000 thrpt 30 14876,723 ? 99,770 ops/s > ref.SliceToList.par_limit 10000 thrpt 30 14856,841 ? 215,089 ops/s > ref.SliceToList.par_skipLimit 10000 thrpt 30 9555,818 ? 991,335 ops/s > ref.SliceToList.seq_baseline 10000 thrpt 30 23732,290 ? 444,162 ops/s > ref.SliceToList.seq_limit 10000 thrpt 30 14894,040 ? 176,496 ops/s > ref.SliceToList.seq_skipLimit 10000 thrpt 30 10646,929 ? 36,469 ops/s > value.SliceToArray.par_baseline 10000 thrpt 30 25093,141 ? 376,402 ops/s > value.SliceToArray.par_limit 10000 thrpt 30 24798,889 ? 760,762 ops/s > value.SliceToArray.par_skipLimit 10000 thrpt 30 16456,310 ? 926,882 ops/s > value.SliceToArray.seq_baseline 10000 thrpt 30 69669,787 ? 494,562 ops/s > value.SliceToArray.seq_limit 10000 thrpt 30 21097,081 ? 117,338 ops/s > value.SliceToArray.seq_skipLimit 10000 thrpt 30 15522,871 ? 112,557 ops/s > > > After patch: > > Benchmark (size) Mode Cnt Score Error Units > ref.SliceToList.par_baseline 10000 thrpt 30 14793,373 ? 64,905 ops/s > ref.SliceToList.par_limit 10000 thrpt 30 13301,024 ? 1300,431 ops/s > ref.SliceToList.par_skipLimit 10000 thrpt 30 11131,698 ? 1769,932 ops/s > ref.SliceToList.seq_baseline 10000 thrpt 30 24101,048 ? 263,528 ops/s > ref.SliceToList.seq_limit 10000 thrpt 30 16872,168 ? 76,696 ops/s > ref.SliceToList.seq_skipLimit 10000 thrpt 30 11953,253 ? 105,231 ops/s > value.SliceToArray.par_baseline 10000 thrpt 30 25442,442 ? 455,554 ops/s > value.SliceToArray.par_limit 10000 thrpt 30 23111,730 ? 2246,086 ops/s > value.SliceToArray.par_skipLimit 10000 thrpt 30 17980,750 ? 2329,077 ops/s > value.SliceToArray.seq_baseline 10000 thrpt 30 66512,898 ? 1001,042 ops/s > value.SliceToArray.seq_limit 10000 thrpt 30 41792,549 ? 1085,547 ops/s > value.SliceToArray.seq_skipLimit 10000 thrpt 30 18007,613 ? 141,716 ops/s > > > I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes. Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: Clarifying comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3427/files - new: https://git.openjdk.java.net/jdk/pull/3427/files/3da4da7c..719fee72 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3427&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3427&range=06-07 Stats: 11 lines in 2 files changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3427.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3427/head:pull/3427 PR: https://git.openjdk.java.net/jdk/pull/3427 From tvaleev at openjdk.java.net Thu May 27 06:13:44 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Thu, 27 May 2021 06:13:44 GMT Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit) [v7] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 19:51:04 GMT, Paul Sandoz wrote: >> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: >> >> Trailing whitespace removed > > src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 471: > >> 469: int flags = getStreamAndOpFlags(); >> 470: long size = StreamOpFlag.SIZED.isKnown(flags) ? spliterator.getExactSizeIfKnown() : -1; >> 471: if (size != -1 && StreamOpFlag.SIZE_ADJUSTING.isKnown(flags) && !isParallel()) { > > Very nice. It's a good compromise to support only for sequential streams, since we have no size adjusting intermediate stateless op. If that was the case we would need to step back through the pipeline until the depth was zero, then step forward. I think it worth a comment here to inform our future selves if we ever add such an operation. > > Strictly speaking we only need to call `exactOutputSize` if the stage is size adjusting. Not sure it really matters perf-wise. If we leave as is maybe add a comment. It's hard to imagine SIZE_ADJUSTING stateless intermediate op (probably the op that duplicates every stream element like `flatMap(x -> Stream.of(x, x))` as a single op?). Nevertheless, I added the comment. Please check if it's clear enough. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3427 From alanb at openjdk.java.net Thu May 27 06:56:05 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 27 May 2021 06:56:05 GMT Subject: RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams [v4] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 17:58:06 GMT, Roger Riggs wrote: > Process is abstract. Is there any use for these new methods to be overridden? > Perhaps they should be final. It's not clear to me that it is useful to extend Process outside of the JDK. Testing, wrapping, ...? It feels like this class wants to be sealed. Maybe we should look at deprecating the no-arg constructor, like Joe did recently with AccessibleObject. ------------- PR: https://git.openjdk.java.net/jdk/pull/4134 From github.com+10835776+stsypanov at openjdk.java.net Thu May 27 08:13:21 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 27 May 2021 08:13:21 GMT Subject: RFR: 8265418: Clean-up redundant null-checks of Class.getPackageName() [v2] In-Reply-To: References: Message-ID: > As discussed in https://github.com/openjdk/jdk/pull/3464 we can clean-up null-checks remaining after [8142968](https://bugs.openjdk.java.net/browse/JDK-8142968) as Class.getPackageName() never returns null. ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into 8265418 # Conflicts: # src/java.base/share/classes/java/lang/Class.java - 8265418: Clean-up redundant null-checks of Class.getPackageName() ------------- Changes: https://git.openjdk.java.net/jdk/pull/3571/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3571&range=01 Stats: 18 lines in 7 files changed: 1 ins; 7 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3571.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3571/head:pull/3571 PR: https://git.openjdk.java.net/jdk/pull/3571 From sundar at openjdk.java.net Thu May 27 09:31:17 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Thu, 27 May 2021 09:31:17 GMT Subject: RFR: 8240347: remove undocumented options from jlink --help message Message-ID: fixed constructor argument passing issue. ------------- Commit messages: - 8240347: remove undocumented options from jlink --help message Changes: https://git.openjdk.java.net/jdk/pull/4221/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4221&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240347 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4221.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4221/head:pull/4221 PR: https://git.openjdk.java.net/jdk/pull/4221 From alanb at openjdk.java.net Thu May 27 09:41:08 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 27 May 2021 09:41:08 GMT Subject: RFR: 8240347: remove undocumented options from jlink --help message In-Reply-To: References: Message-ID: On Thu, 27 May 2021 09:23:50 GMT, Athijegannathan Sundararajan wrote: > fixed constructor argument passing issue. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4221 From redestad at openjdk.java.net Thu May 27 09:45:13 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 27 May 2021 09:45:13 GMT Subject: RFR: 8240347: remove undocumented options from jlink --help message In-Reply-To: References: Message-ID: On Thu, 27 May 2021 09:23:50 GMT, Athijegannathan Sundararajan wrote: > fixed constructor argument passing issue. Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4221 From mcimadamore at openjdk.java.net Thu May 27 10:11:43 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 27 May 2021 10:11:43 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v25] In-Reply-To: References: Message-ID: > 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://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: * Add missing `final` in some static fields * Downgrade native methods in ProgrammableUpcallHandler to package-private ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/e927c235..e1fcd2d3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=24 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=23-24 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From redestad at openjdk.java.net Thu May 27 10:13:05 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 27 May 2021 10:13:05 GMT Subject: RFR: 8265418: Clean-up redundant null-checks of Class.getPackageName() [v2] In-Reply-To: References: <0WxB-NH33GzJXA0TYpM-G-bVDdeLWqmFFKLi_R8-54o=.6968a96f-c349-4988-96a4-d982458ebe8e@github.com> Message-ID: <7GRBv0pOK7Lv2lGLHvcrMJGHSKfNnt6uPZ9azODYRwk=.558b472d-630f-4bd6-981c-82b782ea2aab@github.com> On Mon, 26 Apr 2021 11:24:23 GMT, ?????? ??????? wrote: >> That should be fine, the null check in Objects.equals is benign with these usages. > > One more thing I'm thinking about (not to be done in this PR of course) is to move call to `String.intern()` from where it is now in `Class.getPackageName()` > > public String getPackageName() { > String pn = this.packageName; > if (pn == null) { > Class c = this; > while (c.isArray()) { > c = c.getComponentType(); > } > if (c.isPrimitive()) { > pn = "java.lang"; > } else { > String cn = c.getName(); > int dot = cn.lastIndexOf('.'); > pn = (dot != -1) ? cn.substring(0, dot).intern() : ""; // <--- > } > this.packageName = pn; > } > return pn; > } > > to `packageName` field assignement like > > this.packageName = pn.intern(); > > this would add two more Strings (`""` and `"java.lang"`) into string table and allow to avoid `String.equals()` in favour of `==` call when comparing package names. What do you think? String literals are implicitly interned: System.out.println("" == new String("")); // false System.out.println("" == new String("").intern()); // true System.out.println("java.lang" == new String("java.lang")); // false System.out.println("java.lang" == new String("java.lang").intern()); // true So we could already use `==` instead of `equals` when evaluating the result of `getPackageName`, which might be a good optimization in some places (`ReflectionFactory::isSamePackage` shows up in profiles of some reflection-related benchmarks). ------------- PR: https://git.openjdk.java.net/jdk/pull/3571 From mcimadamore at openjdk.java.net Thu May 27 10:37:38 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 27 May 2021 10:37:38 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v26] In-Reply-To: References: Message-ID: <9sO-moMQsSpzVGkmQ50SQAS1dcBNpC0EyO83lwDGFNI=.a4c737f0-7d4f-43a7-a5f8-2a504b20690f@github.com> > 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://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: - Merge branch 'master' into JEP-412 - * Add missing `final` in some static fields * Downgrade native methods in ProgrammableUpcallHandler to package-private - Add sealed modifiers in morally sealed API interfaces - Merge branch 'master' into JEP-412 - Fix VaList test Remove unused code in Utils - Merge pull request #11 from JornVernee/JEP-412-MXCSR Add MXCSR save and restore to upcall stubs for non-windows platforms - Add MXCSR save and restore to upcall stubs for non-windows platforms - Merge branch 'master' into JEP-412 - Fix issue with bounded arena allocator - Rename is_entry_blob to is_optimized_entry_blob Rename as_entry_blob to as_optimized_entry_blob Fix misc typos and indentation issues - ... and 27 more: https://git.openjdk.java.net/jdk/compare/7278f56b...8bbddfc2 ------------- Changes: https://git.openjdk.java.net/jdk/pull/3699/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=25 Stats: 14501 lines in 219 files changed: 8847 ins; 3642 del; 2012 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Thu May 27 10:45:11 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 27 May 2021 10:45:11 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 17:52:36 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/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac. > - Correcting LineNumberTable for rule switches. > - Merging master into JDK-8262891 > - Fixing various error-related bugs. > - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default. > - Reflecting recent spec changes. > - Reflecting review comments. > - Reflecting review comments on SwitchBootstraps. > - Trailing whitespaces. > - Cleanup, reflecting review comments. > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501 Compiler changes look good src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1657: > 1655: > 1656: try { > 1657: boolean enumSwitch = (seltype.tsym.flags() & Flags.ENUM) != 0; This is getting convoluted enough that an enum on the AST (e.g. SwitchKind) might be helpful to save some of these classification properties - which I imagine we have to redo at some point later (e.g. in Lower/TransPattern). I'm ok with fixing in a followup issue. ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3863 From github.com+10835776+stsypanov at openjdk.java.net Thu May 27 11:19:24 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 27 May 2021 11:19:24 GMT Subject: RFR: 8265418: Clean-up redundant null-checks of Class.getPackageName() [v3] In-Reply-To: References: Message-ID: > As discussed in https://github.com/openjdk/jdk/pull/3464 we can clean-up null-checks remaining after [8142968](https://bugs.openjdk.java.net/browse/JDK-8142968) as Class.getPackageName() never returns null. ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8265418: Compare package names with == instead of equals() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3571/files - new: https://git.openjdk.java.net/jdk/pull/3571/files/7d52a13d..dc91091b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3571&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3571&range=01-02 Stats: 7 lines in 6 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3571.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3571/head:pull/3571 PR: https://git.openjdk.java.net/jdk/pull/3571 From github.com+10835776+stsypanov at openjdk.java.net Thu May 27 11:19:24 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 27 May 2021 11:19:24 GMT Subject: RFR: 8265418: Clean-up redundant null-checks of Class.getPackageName() [v3] In-Reply-To: <7GRBv0pOK7Lv2lGLHvcrMJGHSKfNnt6uPZ9azODYRwk=.558b472d-630f-4bd6-981c-82b782ea2aab@github.com> References: <0WxB-NH33GzJXA0TYpM-G-bVDdeLWqmFFKLi_R8-54o=.6968a96f-c349-4988-96a4-d982458ebe8e@github.com> <7GRBv0pOK7Lv2lGLHvcrMJGHSKfNnt6uPZ9azODYRwk=.558b472d-630f-4bd6-981c-82b782ea2aab@github.com> Message-ID: On Thu, 27 May 2021 10:08:17 GMT, Claes Redestad wrote: >> One more thing I'm thinking about (not to be done in this PR of course) is to move call to `String.intern()` from where it is now in `Class.getPackageName()` >> >> public String getPackageName() { >> String pn = this.packageName; >> if (pn == null) { >> Class c = this; >> while (c.isArray()) { >> c = c.getComponentType(); >> } >> if (c.isPrimitive()) { >> pn = "java.lang"; >> } else { >> String cn = c.getName(); >> int dot = cn.lastIndexOf('.'); >> pn = (dot != -1) ? cn.substring(0, dot).intern() : ""; // <--- >> } >> this.packageName = pn; >> } >> return pn; >> } >> >> to `packageName` field assignement like >> >> this.packageName = pn.intern(); >> >> this would add two more Strings (`""` and `"java.lang"`) into string table and allow to avoid `String.equals()` in favour of `==` call when comparing package names. What do you think? > > String literals are implicitly interned: > > System.out.println("" == new String("")); // false > System.out.println("" == new String("").intern()); // true > System.out.println("java.lang" == new String("java.lang")); // false > System.out.println("java.lang" == new String("java.lang").intern()); // true > > > So we could already use `==` instead of `equals` when evaluating the result of `getPackageName`, which might be a good optimization in some places (`ReflectionFactory::isSamePackage` shows up in profiles of some reflection-related benchmarks). Done! ------------- PR: https://git.openjdk.java.net/jdk/pull/3571 From redestad at openjdk.java.net Thu May 27 12:04:07 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 27 May 2021 12:04:07 GMT Subject: RFR: 8265418: Clean-up redundant null-checks of Class.getPackageName() [v3] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 11:19:24 GMT, ?????? ??????? wrote: >> As discussed in https://github.com/openjdk/jdk/pull/3464 we can clean-up null-checks remaining after [8142968](https://bugs.openjdk.java.net/browse/JDK-8142968) as Class.getPackageName() never returns null. > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8265418: Compare package names with == instead of equals() LGTM src/java.base/share/classes/sun/reflect/misc/ReflectUtil.java line 129: > 127: while (clazz.isArray()) { > 128: clazz = clazz.getComponentType(); > 129: } Pre-existing issue (so consider filing a follow-up) but this loop is redundant since `getPackageName` will already return the package name of the innermost component type. ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3571 From jvernee at openjdk.java.net Thu May 27 12:31:11 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 27 May 2021 12:31:11 GMT Subject: Integrated: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 18:51:21 GMT, Jorn Vernee wrote: > This patch adds a `tableSwitch` combinator that can be used to switch over a set of method handles given an index, with a fallback in case the index is out of bounds, much like the `tableswitch` bytecode. Here is a description of how it works (copied from the javadoc): > > Creates a table switch method handle, which can be used to switch over a set of target > method handles, based on a given target index, called selector. > > For a selector value of {@code n}, where {@code n} falls in the range {@code [0, N)}, > and where {@code N} is the number of target method handles, the table switch method > handle will invoke the n-th target method handle from the list of target method handles. > > For a selector value that does not fall in the range {@code [0, N)}, the table switch > method handle will invoke the given fallback method handle. > > All method handles passed to this method must have the same type, with the additional > requirement that the leading parameter be of type {@code int}. The leading parameter > represents the selector. > > Any trailing parameters present in the type will appear on the returned table switch > method handle as well. Any arguments assigned to these parameters will be forwarded, > together with the selector value, to the selected method handle when invoking it. > > The combinator does not support specifying the starting index, so the switch cases always run from 0 to however many target handles are specified. A starting index can be added manually with another combination step that filters the input index by adding or subtracting a constant from it, which does not affect performance. One of the reasons for not supporting a starting index is that it allows for more lambda form sharing, but also simplifies the implementation somewhat. I guess an open question is if a convenience overload should be added for that case? > > Lookup switch can also be simulated by filtering the input through an injection function that translates it into a case index, which has also proven to have the ability to have comparable performance to, or even better performance than, a bytecode-native `lookupswitch` instruction. I plan to add such an injection function to the runtime libraries in the future as well. Maybe at that point it could be evaluated if it's worth it to add a lookup switch combinator as well, but I don't see an immediate need to include it in this patch. > > The current bytecode intrinsification generates a call for each switch case, which guarantees full inlining of the target method handles. Alternatively we could only have 1 callsite at the end of the switch, where each case just loads the target method handle, but currently this does not allow for inlining of the handles, since they are not constant. > > Maybe a future C2 optimization could look at the receiver input for invokeBasic call sites, and if the input is a phi node, clone the call for each constant input of the phi. I believe that would allow simplifying the bytecode without giving up on inlining. > > Some numbers from the added benchmarks: > > Benchmark (numCases) (offset) (sorted) Mode Cnt Score Error Units > MethodHandlesTableSwitchConstant.testSwitch 5 0 N/A avgt 30 4.186 ? 0.054 ms/op > MethodHandlesTableSwitchConstant.testSwitch 5 150 N/A avgt 30 4.164 ? 0.057 ms/op > MethodHandlesTableSwitchConstant.testSwitch 10 0 N/A avgt 30 4.124 ? 0.023 ms/op > MethodHandlesTableSwitchConstant.testSwitch 10 150 N/A avgt 30 4.126 ? 0.025 ms/op > MethodHandlesTableSwitchConstant.testSwitch 25 0 N/A avgt 30 4.137 ? 0.042 ms/op > MethodHandlesTableSwitchConstant.testSwitch 25 150 N/A avgt 30 4.113 ? 0.016 ms/op > MethodHandlesTableSwitchConstant.testSwitch 50 0 N/A avgt 30 4.118 ? 0.028 ms/op > MethodHandlesTableSwitchConstant.testSwitch 50 150 N/A avgt 30 4.127 ? 0.019 ms/op > MethodHandlesTableSwitchConstant.testSwitch 100 0 N/A avgt 30 4.116 ? 0.013 ms/op > MethodHandlesTableSwitchConstant.testSwitch 100 150 N/A avgt 30 4.121 ? 0.020 ms/op > MethodHandlesTableSwitchOpaqueSingle.testSwitch 5 0 N/A avgt 30 4.113 ? 0.009 ms/op > MethodHandlesTableSwitchOpaqueSingle.testSwitch 5 150 N/A avgt 30 4.149 ? 0.041 ms/op > MethodHandlesTableSwitchOpaqueSingle.testSwitch 10 0 N/A avgt 30 4.121 ? 0.026 ms/op > MethodHandlesTableSwitchOpaqueSingle.testSwitch 10 150 N/A avgt 30 4.113 ? 0.021 ms/op > MethodHandlesTableSwitchOpaqueSingle.testSwitch 25 0 N/A avgt 30 4.129 ? 0.028 ms/op > MethodHandlesTableSwitchOpaqueSingle.testSwitch 25 150 N/A avgt 30 4.105 ? 0.019 ms/op > MethodHandlesTableSwitchOpaqueSingle.testSwitch 50 0 N/A avgt 30 4.097 ? 0.021 ms/op > MethodHandlesTableSwitchOpaqueSingle.testSwitch 50 150 N/A avgt 30 4.131 ? 0.037 ms/op > MethodHandlesTableSwitchOpaqueSingle.testSwitch 100 0 N/A avgt 30 4.135 ? 0.025 ms/op > MethodHandlesTableSwitchOpaqueSingle.testSwitch 100 150 N/A avgt 30 4.139 ? 0.145 ms/op > MethodHandlesTableSwitchRandom.testSwitch 5 0 true avgt 30 4.894 ? 0.028 ms/op > MethodHandlesTableSwitchRandom.testSwitch 5 0 false avgt 30 11.526 ? 0.194 ms/op > MethodHandlesTableSwitchRandom.testSwitch 5 150 true avgt 30 4.882 ? 0.025 ms/op > MethodHandlesTableSwitchRandom.testSwitch 5 150 false avgt 30 11.532 ? 0.034 ms/op > MethodHandlesTableSwitchRandom.testSwitch 10 0 true avgt 30 5.065 ? 0.076 ms/op > MethodHandlesTableSwitchRandom.testSwitch 10 0 false avgt 30 13.016 ? 0.020 ms/op > MethodHandlesTableSwitchRandom.testSwitch 10 150 true avgt 30 5.103 ? 0.051 ms/op > MethodHandlesTableSwitchRandom.testSwitch 10 150 false avgt 30 12.984 ? 0.102 ms/op > MethodHandlesTableSwitchRandom.testSwitch 25 0 true avgt 30 8.441 ? 0.165 ms/op > MethodHandlesTableSwitchRandom.testSwitch 25 0 false avgt 30 13.371 ? 0.060 ms/op > MethodHandlesTableSwitchRandom.testSwitch 25 150 true avgt 30 8.628 ? 0.032 ms/op > MethodHandlesTableSwitchRandom.testSwitch 25 150 false avgt 30 13.542 ? 0.020 ms/op > MethodHandlesTableSwitchRandom.testSwitch 50 0 true avgt 30 4.701 ? 0.015 ms/op > MethodHandlesTableSwitchRandom.testSwitch 50 0 false avgt 30 13.562 ? 0.063 ms/op > MethodHandlesTableSwitchRandom.testSwitch 50 150 true avgt 30 7.991 ? 3.111 ms/op > MethodHandlesTableSwitchRandom.testSwitch 50 150 false avgt 30 13.543 ? 0.088 ms/op > MethodHandlesTableSwitchRandom.testSwitch 100 0 true avgt 30 4.712 ? 0.020 ms/op > MethodHandlesTableSwitchRandom.testSwitch 100 0 false avgt 30 13.600 ? 0.085 ms/op > MethodHandlesTableSwitchRandom.testSwitch 100 150 true avgt 30 4.676 ? 0.011 ms/op > MethodHandlesTableSwitchRandom.testSwitch 100 150 false avgt 30 13.476 ? 0.043 ms/op > > > Testing: > - [x] Running of included benchmarks > - [x] Inspecting inlining trace and verifying method handle targets are inlined > - [x] Running TestTableSwitch test (currently the only user of the new code) > - [x] Running java/lang/invoke tests (just in case) > - [x] Some manual testing > > Thanks, > Jorn This pull request has now been integrated. Changeset: 3623abb7 Author: Jorn Vernee URL: https://git.openjdk.java.net/jdk/commit/3623abb7f6d9112d4cbcffd89852e826c56ae348 Stats: 986 lines in 10 files changed: 960 ins; 12 del; 14 mod 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/3401 From sundar at openjdk.java.net Thu May 27 12:33:10 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Thu, 27 May 2021 12:33:10 GMT Subject: Integrated: 8240347: remove undocumented options from jlink --help message In-Reply-To: References: Message-ID: On Thu, 27 May 2021 09:23:50 GMT, Athijegannathan Sundararajan wrote: > fixed constructor argument passing issue. This pull request has now been integrated. Changeset: ec65cf83 Author: Athijegannathan Sundararajan URL: https://git.openjdk.java.net/jdk/commit/ec65cf833294e21e9dc59dfe014148d3e1210b53 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8240347: remove undocumented options from jlink --help message Reviewed-by: alanb, redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/4221 From naoto at openjdk.java.net Thu May 27 13:22:09 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 27 May 2021 13:22:09 GMT Subject: Integrated: 8187649: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar In-Reply-To: References: Message-ID: On Tue, 25 May 2021 16:40:53 GMT, Naoto Sato wrote: > Please review the fix. The issue was informed yesterday by @amaembo that it offends some code analysis tools. > Although the fix is to change the condition error, it turned out that `JapaneseImperialCalendar.roll()` did not work for `WEEK_OF_MONTH` and `DAY_OF_MONTH`. There was an inherent issue where `GregorianCalendar` does not follow the `roll()` spec, i.e., "The MONTH must not change when the WEEK_OF_MONTH is rolled." during the Julian/Gregorian transition. JDK-6191841 seems to have tried to fix it but it was closed as `Future Project`... > So I simply fixed the `roll()` issue in `JapaneseImperialCalendar` to follow the spec here, which seems to be the intent of the original author. This pull request has now been integrated. Changeset: bea4109e Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/bea4109ef75a6536af4296db56e6ec90ab0f30fc Stats: 46 lines in 3 files changed: 36 ins; 0 del; 10 mod 8187649: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar Reviewed-by: joehw, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/4191 From github.com+10835776+stsypanov at openjdk.java.net Thu May 27 13:46:06 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 27 May 2021 13:46:06 GMT Subject: RFR: 8265418: Clean-up redundant null-checks of Class.getPackageName() [v3] In-Reply-To: References: Message-ID: <3uznK_b5YZYFBa_7tqmIImxrNTRLwaslQ3c_g_Asg9Q=.e514866d-d4a5-43ab-9c82-1557a23f58b9@github.com> On Thu, 27 May 2021 12:00:46 GMT, Claes Redestad wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8265418: Compare package names with == instead of equals() > > src/java.base/share/classes/sun/reflect/misc/ReflectUtil.java line 129: > >> 127: while (clazz.isArray()) { >> 128: clazz = clazz.getComponentType(); >> 129: } > > Pre-existing issue (so consider filing a follow-up) but this loop is redundant since `getPackageName` will already return the package name of the innermost component type. Seems to be true, I'll file another ticket for this ------------- PR: https://git.openjdk.java.net/jdk/pull/3571 From dfuchs at openjdk.java.net Thu May 27 13:58:13 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 27 May 2021 13:58:13 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v6] In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Wed, 26 May 2021 02:22:42 GMT, Tagir F. Valeev wrote: >> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. >> >> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? > > Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision: > > - JapaneseImperialCalendar: use switch expressions > - Use yield in java.util.Calendar.Builder.build Globally looks good. I haven't reviewed `src/java.base/share/classes/java/util/regex/Pattern.java` due to formatting issues. See also my other remark about `java.util.concurrent`. src/java.base/share/classes/java/util/concurrent/FutureTask.java line 495: > 493: * @return a string representation of this FutureTask > 494: */ > 495: public String toString() { Classes in java.util.concurrent are handled upstream. It would probably be better to leave them out of this patch. Or synchronize with @DougLea to see how to bring these changes in the upstream repo. ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From avoitylov at openjdk.java.net Thu May 27 14:31:59 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Thu, 27 May 2021 14:31:59 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v6] In-Reply-To: References: Message-ID: > 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 library load operation. > > Problem being fixed: > > The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. > > Proposed fix: > > The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. > > The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. > > Testing: jtreg and jck testing with no regressions. A new regression test was developed. Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3976/files - new: https://git.openjdk.java.net/jdk/pull/3976/files/8e735117..85005d57 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3976&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3976&range=04-05 Stats: 11 lines in 1 file changed: 3 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3976.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3976/head:pull/3976 PR: https://git.openjdk.java.net/jdk/pull/3976 From avoitylov at openjdk.java.net Thu May 27 14:32:02 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Thu, 27 May 2021 14:32:02 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v5] In-Reply-To: References: Message-ID: 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 library load operation. >> >> Problem being fixed: >> >> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. >> >> Proposed fix: >> >> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. >> >> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. >> >> Testing: jtreg and jck testing with no regressions. A new regression test was developed. > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > fix whitespace Thanks Mandy, that would be great. Waiting on your and other core-libs members reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From avoitylov at openjdk.java.net Thu May 27 14:32:04 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Thu, 27 May 2021 14:32:04 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v5] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 07:30:10 GMT, Peter Levart wrote: >> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: >> >> fix whitespace > > src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 481: > >> 479: throw new Error("Maximum lock count exceeded"); >> 480: } >> 481: > > Hi Aleksei, > I know in practice this counter will never overflow, but just to be pedantic, it would be better that you either decrement back the counter before throwing Error or you check for overflow without incrementing it. Otherwise the lock is left in a corrupted state since you use it like this: > > > acquireNativeLibraryLock(name); > try { > ... > } finally { > releaseNativeLibraryLock(name); > } > > ...you see, if acquire fails, it is not paired with release, which is correct since the ReentrantLock has not been acquired, but the counter *HAS* been incremented... Peter, the updated version checks if counter hits MAX_VALUE before incrementing. It also means the counter can't underflow, so that check is removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From avoitylov at openjdk.java.net Thu May 27 14:32:07 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Thu, 27 May 2021 14:32:07 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v5] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 02:36:34 GMT, David Holmes wrote: >> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: >> >> fix whitespace > > src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 497: > >> 495: >> 496: private static void acquireNativeLibraryLock(String libraryName) { >> 497: nativeLibraryLockMap.compute(libraryName, (name, lock) -> { > > This would be clearer if lock were named currentLock as for releaseNLLock David, lock is now renamed to currentLock ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From github.com+9004656+yaaz at openjdk.java.net Thu May 27 15:06:19 2021 From: github.com+9004656+yaaz at openjdk.java.net (Nikita Gubarkov) Date: Thu, 27 May 2021 15:06:19 GMT Subject: RFR: 8267706: bin/idea.sh tries to use cygpath on WSL Message-ID: 8267706: bin/idea.sh tries to use cygpath on WSL ------------- Commit messages: - 8267706: Added shell run configurations instead of Ant for IDEA project - 8267706: Improved IDEA project setup - 8267706: Fix bin/idea.sh cygpath usage on WSL Changes: https://git.openjdk.java.net/jdk/pull/4190/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4190&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267706 Stats: 668 lines in 14 files changed: 67 ins; 498 del; 103 mod Patch: https://git.openjdk.java.net/jdk/pull/4190.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4190/head:pull/4190 PR: https://git.openjdk.java.net/jdk/pull/4190 From aefimov at openjdk.java.net Thu May 27 15:21:17 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Thu, 27 May 2021 15:21:17 GMT Subject: RFR: 8265309: com/sun/jndi/dns/ConfigTests/Timeout.java fails with "Address already in use" BindException Message-ID: Hi, `com/sun/jndi/dns/ConfigTests/Timeout.java ` was seen failing intermittently with "Address already in use" `BindException`. The reason of this failure is that `disconnect` call in JNDI `DnsClient` fails to rebind the datagram socket to the original port during `disconnect` call (the failure is in `DatagramChannel::repairSocket`). Since Datagram socket is not reused and closed after the failure `finally` block with the `disconnect` call can be removed. The fix was tested with all available JNDI/DNS tests, and no failures related to the change were observed. ------------- Commit messages: - 8265309: com/sun/jndi/dns/ConfigTests/Timeout.java fails with "Address already in use" BindException Changes: https://git.openjdk.java.net/jdk/pull/4227/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4227&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265309 Stats: 30 lines in 1 file changed: 0 ins; 5 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/4227.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4227/head:pull/4227 PR: https://git.openjdk.java.net/jdk/pull/4227 From smarks at openjdk.java.net Thu May 27 15:23:10 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 27 May 2021 15:23:10 GMT Subject: Integrated: 8267123: Remove RMI Activation In-Reply-To: References: Message-ID: On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to various comments to remove references to Activation > - adjustments to some code to remove special-case support for Activation from core RMI > - adjustments to several tests to remove testing and support for, and mentions of Activation > - remove `rmid` tool > > (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) This pull request has now been integrated. Changeset: 7c85f351 Author: Stuart Marks URL: https://git.openjdk.java.net/jdk/commit/7c85f3510cb84881ff232548fbcc933ef4b34972 Stats: 21982 lines in 243 files changed: 0 ins; 21930 del; 52 mod 8267123: Remove RMI Activation Reviewed-by: erikj, rriggs, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/4194 From pconcannon at openjdk.java.net Thu May 27 15:33:36 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Thu, 27 May 2021 15:33:36 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v8] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon 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 ten additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8267670 - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Added missing brace - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Removed trailing whitespace - 8267670: Remove redundant code from switch - 8267670: Updated code to use yield - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Update java.io, java.math, and java.text to use switch expressions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4182/files - new: https://git.openjdk.java.net/jdk/pull/4182/files/57184fbf..933e59e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=06-07 Stats: 29913 lines in 434 files changed: 3355 ins; 25561 del; 997 mod Patch: https://git.openjdk.java.net/jdk/pull/4182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4182/head:pull/4182 PR: https://git.openjdk.java.net/jdk/pull/4182 From dfuchs at openjdk.java.net Thu May 27 15:36:05 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 27 May 2021 15:36:05 GMT Subject: RFR: 8265309: com/sun/jndi/dns/ConfigTests/Timeout.java fails with "Address already in use" BindException In-Reply-To: References: Message-ID: <35beK_amOfKDb-6unSx6XNu7UzJ56FCv2vStups2J_0=.73cb124c-2db8-47e2-9e24-3ca5c07cd055@github.com> On Thu, 27 May 2021 15:02:01 GMT, Aleksei Efimov wrote: > Hi, > > `com/sun/jndi/dns/ConfigTests/Timeout.java ` was seen failing intermittently with "Address already in use" `BindException`. The reason of this failure is that `disconnect` call in JNDI `DnsClient` fails to rebind the datagram socket to the original port during `disconnect` call (the failure is in `DatagramChannel::repairSocket`). > Since Datagram socket is not reused and closed after the failure `finally` block with the `disconnect` call can be removed. > > The fix was tested with all available JNDI/DNS tests, and no failures related to the change were observed. LGTM. I really wish git had a better `diff` ! Can you add `@bug 8265309` to com/sun/jndi/dns/ConfigTests/Timeout.java since this is a product change? ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4227 From psandoz at openjdk.java.net Thu May 27 15:38:05 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 27 May 2021 15:38:05 GMT Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit) [v8] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 06:13:40 GMT, Tagir F. Valeev wrote: >> With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch. >> >> Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch: >> >> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm 10000 thrpt 10 40235,534 ? 0,984 B/op >> ref.SliceToList.seq_limit:?gc.alloc.rate.norm 10000 thrpt 10 106431,101 ? 0,198 B/op >> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm 10000 thrpt 10 106544,977 ? 1,983 B/op >> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm 10000 thrpt 10 40121,878 ? 0,247 B/op >> value.SliceToArray.seq_limit:?gc.alloc.rate.norm 10000 thrpt 10 106317,693 ? 1,083 B/op >> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm 10000 thrpt 10 106430,954 ? 0,136 B/op >> >> >> After patch: >> >> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm 10000 thrpt 10 40235,648 ? 1,354 B/op >> ref.SliceToList.seq_limit:?gc.alloc.rate.norm 10000 thrpt 10 40355,784 ? 1,288 B/op >> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm 10000 thrpt 10 40476,032 ? 2,855 B/op >> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm 10000 thrpt 10 40121,830 ? 0,308 B/op >> value.SliceToArray.seq_limit:?gc.alloc.rate.norm 10000 thrpt 10 40242,554 ? 0,443 B/op >> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm 10000 thrpt 10 40363,674 ? 1,576 B/op >> >> >> Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests. >> >> Before patch: >> >> Benchmark (size) Mode Cnt Score Error Units >> ref.SliceToList.par_baseline 10000 thrpt 30 14876,723 ? 99,770 ops/s >> ref.SliceToList.par_limit 10000 thrpt 30 14856,841 ? 215,089 ops/s >> ref.SliceToList.par_skipLimit 10000 thrpt 30 9555,818 ? 991,335 ops/s >> ref.SliceToList.seq_baseline 10000 thrpt 30 23732,290 ? 444,162 ops/s >> ref.SliceToList.seq_limit 10000 thrpt 30 14894,040 ? 176,496 ops/s >> ref.SliceToList.seq_skipLimit 10000 thrpt 30 10646,929 ? 36,469 ops/s >> value.SliceToArray.par_baseline 10000 thrpt 30 25093,141 ? 376,402 ops/s >> value.SliceToArray.par_limit 10000 thrpt 30 24798,889 ? 760,762 ops/s >> value.SliceToArray.par_skipLimit 10000 thrpt 30 16456,310 ? 926,882 ops/s >> value.SliceToArray.seq_baseline 10000 thrpt 30 69669,787 ? 494,562 ops/s >> value.SliceToArray.seq_limit 10000 thrpt 30 21097,081 ? 117,338 ops/s >> value.SliceToArray.seq_skipLimit 10000 thrpt 30 15522,871 ? 112,557 ops/s >> >> >> After patch: >> >> Benchmark (size) Mode Cnt Score Error Units >> ref.SliceToList.par_baseline 10000 thrpt 30 14793,373 ? 64,905 ops/s >> ref.SliceToList.par_limit 10000 thrpt 30 13301,024 ? 1300,431 ops/s >> ref.SliceToList.par_skipLimit 10000 thrpt 30 11131,698 ? 1769,932 ops/s >> ref.SliceToList.seq_baseline 10000 thrpt 30 24101,048 ? 263,528 ops/s >> ref.SliceToList.seq_limit 10000 thrpt 30 16872,168 ? 76,696 ops/s >> ref.SliceToList.seq_skipLimit 10000 thrpt 30 11953,253 ? 105,231 ops/s >> value.SliceToArray.par_baseline 10000 thrpt 30 25442,442 ? 455,554 ops/s >> value.SliceToArray.par_limit 10000 thrpt 30 23111,730 ? 2246,086 ops/s >> value.SliceToArray.par_skipLimit 10000 thrpt 30 17980,750 ? 2329,077 ops/s >> value.SliceToArray.seq_baseline 10000 thrpt 30 66512,898 ? 1001,042 ops/s >> value.SliceToArray.seq_limit 10000 thrpt 30 41792,549 ? 1085,547 ops/s >> value.SliceToArray.seq_skipLimit 10000 thrpt 30 18007,613 ? 141,716 ops/s >> >> >> I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes. > > Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: > > Clarifying comments I agree the likelihood of some stateless size adjusting op is small but i think its worthwhile capturing the thinking, since this area of streams is quite complex. Thanks for adding the comment. src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 477: > 475: // If we ever have SIZE_ADJUSTING intermediate operation, > 476: // we would need step back until depth == 0, then call exactOutputSize() for > 477: // the subsequent stages. Suggestion: // Currently, we have no stateless SIZE_ADJUSTING intermediate operations, // so we can simply ignore SIZE_ADJUSTING in parallel streams, since adjustments // are already accounted in the input spliterator. // // If we ever have a stateless SIZE_ADJUSTING intermediate operation, // we would need step back until depth == 0, then call exactOutputSize() for // the subsequent stages. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3427 From lancea at openjdk.java.net Thu May 27 15:47:12 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 27 May 2021 15:47:12 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v8] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 15:33:36 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon 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 ten additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Added missing brace > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Removed trailing whitespace > - 8267670: Remove redundant code from switch > - 8267670: Updated code to use yield > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Update java.io, java.math, and java.text to use switch expressions Looks good Patrick ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4182 From aefimov at openjdk.java.net Thu May 27 15:57:27 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Thu, 27 May 2021 15:57:27 GMT Subject: RFR: 8265309: com/sun/jndi/dns/ConfigTests/Timeout.java fails with "Address already in use" BindException [v2] In-Reply-To: References: Message-ID: > Hi, > > `com/sun/jndi/dns/ConfigTests/Timeout.java ` was seen failing intermittently with "Address already in use" `BindException`. The reason of this failure is that `disconnect` call in JNDI `DnsClient` fails to rebind the datagram socket to the original port during `disconnect` call (the failure is in `DatagramChannel::repairSocket`). > Since Datagram socket is not reused and closed after the failure `finally` block with the `disconnect` call can be removed. > > The fix was tested with all available JNDI/DNS tests, and no failures related to the change were observed. Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: Add bug id to Timeout.java jtreg header ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4227/files - new: https://git.openjdk.java.net/jdk/pull/4227/files/f3671fc5..82d026db Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4227&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4227&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4227.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4227/head:pull/4227 PR: https://git.openjdk.java.net/jdk/pull/4227 From aefimov at openjdk.java.net Thu May 27 15:57:28 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Thu, 27 May 2021 15:57:28 GMT Subject: RFR: 8265309: com/sun/jndi/dns/ConfigTests/Timeout.java fails with "Address already in use" BindException [v2] In-Reply-To: <35beK_amOfKDb-6unSx6XNu7UzJ56FCv2vStups2J_0=.73cb124c-2db8-47e2-9e24-3ca5c07cd055@github.com> References: <35beK_amOfKDb-6unSx6XNu7UzJ56FCv2vStups2J_0=.73cb124c-2db8-47e2-9e24-3ca5c07cd055@github.com> Message-ID: On Thu, 27 May 2021 15:33:00 GMT, Daniel Fuchs wrote: > LGTM. I really wish git had a better `diff` ! > Can you add `@bug 8265309` to com/sun/jndi/dns/ConfigTests/Timeout.java since this is a product change? Thanks for the review and the suggestion @dfuch . Bug ID has been added. ------------- PR: https://git.openjdk.java.net/jdk/pull/4227 From dfuchs at openjdk.java.net Thu May 27 16:04:09 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 27 May 2021 16:04:09 GMT Subject: RFR: 8265309: com/sun/jndi/dns/ConfigTests/Timeout.java fails with "Address already in use" BindException [v2] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 15:57:27 GMT, Aleksei Efimov wrote: >> Hi, >> >> `com/sun/jndi/dns/ConfigTests/Timeout.java ` was seen failing intermittently with "Address already in use" `BindException`. The reason of this failure is that `disconnect` call in JNDI `DnsClient` fails to rebind the datagram socket to the original port during `disconnect` call (the failure is in `DatagramChannel::repairSocket`). >> Since Datagram socket is not reused and closed after the failure `finally` block with the `disconnect` call can be removed. >> >> The fix was tested with all available JNDI/DNS tests, and no failures related to the change were observed. > > Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: > > Add bug id to Timeout.java jtreg header Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4227 From github.com+28651297+mkartashev at openjdk.java.net Thu May 27 16:14:38 2021 From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev) Date: Thu, 27 May 2021 16:14:38 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v3] In-Reply-To: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> Message-ID: <3y0nPfUyTPbNksPn1y5pvopzN2AReOgIl2CafPKD4b4=.3b490e90-5098-4d9f-8d7e-2770f5548895@github.com> > Character strings within JVM are produced and consumed in several formats. Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or dlopen()) consume strings also in UTF8. On Windows, however, the situation is far less simple: some new(er) APIs expect UTF16 (wide-character strings), some older APIs can only work with strings in a "platform" format, where not all UTF8 characters can be represented; which ones can depends on the current "code page". > > This commit switches the Windows version of native library loading code to using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use of various string formats in the surrounding code. > > Namely, exception messages are made to consume strings explicitly in the UTF8 format, while logging functions (that end up using legacy Windows API) are made to consume "platform" strings in most cases. One exception is `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, which can, of course, be fixed, but was considered not worth the additional code (NB: this isn't a new bug). > > The test runs in a separate JVM in order to make NIO happy about non-ASCII characters in the file name; tests are executed with LC_ALL=C and that doesn't let NIO work with non-ASCII file names even on Linux or MacOS. > > Tested by running `test/hotspot/jtreg:tier1` on Linux and `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (` jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran on those platforms as well. > > Results from Linux: > > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg:tier1 1784 1784 0 0 > ============================== > TEST SUCCESS > > > Building target 'run-test-only' in configuration 'linux-x86_64-server-release' > Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: > * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode > > Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' > Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java > Test results: passed: 1 > > > Results from Windows 10: > > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg/runtime 746 746 0 0 > ============================== > TEST SUCCESS > Finished building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' > > > Building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' > Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: > * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode > > Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' > Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java > Test results: passed: 1 Maxim Kartashev has updated the pull request incrementally with two additional commits since the last revision: - Coding style-related corrections. - Corrected the test to use Platform.sharedLibraryExt() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4169/files - new: https://git.openjdk.java.net/jdk/pull/4169/files/fe661dff..c8ef8b64 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4169&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4169&range=01-02 Stats: 43 lines in 2 files changed: 7 ins; 9 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/4169.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4169/head:pull/4169 PR: https://git.openjdk.java.net/jdk/pull/4169 From github.com+28651297+mkartashev at openjdk.java.net Thu May 27 16:14:43 2021 From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev) Date: Thu, 27 May 2021 16:14:43 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v2] In-Reply-To: References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> Message-ID: On Thu, 27 May 2021 04:23:16 GMT, David Holmes wrote: >> Maxim Kartashev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 8195129: System.load() fails to load from unicode paths > > src/hotspot/os/windows/os_windows.cpp line 1462: > >> 1460: const int flag_source_str_is_null_terminated = -1; >> 1461: const int flag_estimate_chars_count = 0; >> 1462: int utf16_chars_count_estimated = MultiByteToWideChar(source_encoding, > > Your local naming style is somewhat excessive. You could just comment the values of the flags when you pass them eg: > > MultiByteToWideChar(source_encoding, > MB_ERR_INVALID_CHARS, > source_str, > -1, //source is null-terminated > NULL, // no output buffer > 0); // calculate required buffer size > > Or you could just add a comment before the call: > > // Perform a dummy conversion so that we can get the required size of the buffer to > // allocate. The source is null-terminated. > > Trying to document parameter semantics by variable naming doesn't work in my opinion - at some point if you want to know you have to RTFM for the API. > > And utf16_len is perfectly adequate for the returned size. Fair enough. Corrected. ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From github.com+28651297+mkartashev at openjdk.java.net Thu May 27 16:21:09 2021 From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev) Date: Thu, 27 May 2021 16:21:09 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v2] In-Reply-To: References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> Message-ID: On Thu, 27 May 2021 05:18:50 GMT, David Holmes wrote: >> Maxim Kartashev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 8195129: System.load() fails to load from unicode paths > > test/hotspot/jtreg/runtime/jni/loadLibraryUnicode/LoadLibraryUnicode.java line 48: > >> 46: } else { >> 47: throw new Error("Unsupported OS"); >> 48: } > > Please use the test library function `Platform.sharedLibraryExt()` to get the library file extension. Thanks for the suggestion. Rewrote this piece. (Side note: since the libraries' prefix differs between platforms also, it'd be nice to have something like `Platform.sharedLibraryName(name)`; this is the way all the code that uses `Platform.sharedLibraryExt()` is structured anyway. But I guess it's best not to conflate things). ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From github.com+28651297+mkartashev at openjdk.java.net Thu May 27 16:31:05 2021 From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev) Date: Thu, 27 May 2021 16:31:05 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v2] In-Reply-To: References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> Message-ID: On Thu, 27 May 2021 05:13:44 GMT, David Holmes wrote: >> Maxim Kartashev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 8195129: System.load() fails to load from unicode paths > > src/hotspot/os/windows/os_windows.cpp line 1541: > >> 1539: void * os::dll_load(const char *utf8_name, char *ebuf, int ebuflen) { >> 1540: LPWSTR utf16_name = NULL; >> 1541: errno_t err = convert_UTF8_to_UTF16(utf8_name, &utf16_name); > > Do you have any figures on the cost of this additional conversion in relation to startup time? > > I'm already concerned to see that we have to perform each conversion twice via MultiByteToWideChar/WideCharToMultiByte, once to get the size and then to actually get the characters! This seems potentially very inefficient. I measured time spend converting the library path name relative to the overall time of a (successful) `os::dll_load()` call. It varies between a fraction of a percent to ~3% (see below for the actual data from a `release` build). I'll defer to your expertise wrt to these numbers. What can be done here (without changing os::dll_load() API) is to have a "fast path" for ascii-only path names, in which case no conversion is necessary, and a "slow path" for all the rest. This will complicate things a bit, but not by much, I believe. I am certainly willing to give that a try. Let me know what do you think. ./build/windows-x86_64-server-release/images/jdk/bin/java -jar ./build/windows-x86_64-server-fastdebug/images/jdk/demo/jfc/SwingSet2/SwingSet2.jar 0.050% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\jimage.dll 2.273% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.dll 0.177% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\net.dll 0.541% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\nio.dll 0.359% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\zip.dll 3.186% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\jimage.dll 0.075% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\awt.dll 0.232% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\freetype.dll 0.136% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\fontmanager.dll 0.170% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\javajpeg.dll ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From erikj at openjdk.java.net Thu May 27 16:55:08 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 27 May 2021 16:55:08 GMT Subject: RFR: 8267706: bin/idea.sh tries to use cygpath on WSL In-Reply-To: References: Message-ID: On Tue, 25 May 2021 16:37:30 GMT, Nikita Gubarkov wrote: > 8267706: bin/idea.sh tries to use cygpath on WSL I think this looks ok, though I'm not very familiar with the details of this code. I also very rarely use the idea projects. It would be good if some frequent users could take this for a spin. make/ide/idea/jdk/idea.gmk line 50: > 48: idea: > 49: $(ECHO) "SUPPORT=$(SUPPORT_OUTPUTDIR)" > $(OUT) > 50: $(ECHO) "MODULES=\"$(foreach mod, $(SEL_MODULES), module='$(mod)' moduleSrcDirs='$(call FindModuleSrcDirs,$(mod))' moduleDependencies='$(call FindTransitiveDepsForModule,$(mod))' #)\"" >> $(OUT) If you can find a way to break this line, it would be appreciated. We try to keep line length "reasonable" within the build files. (Reasonable meaning, not strict 80, but with future 3-way merges on a normal screen in mind) ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4190 From prr at openjdk.java.net Thu May 27 17:15:06 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 27 May 2021 17:15:06 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v4] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 24 May 2021 13:53:34 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > keep only one systemProperty tag Marked as reviewed by prr (Reviewer). I'm OK with this now given that the refactoring is already underway at https://github.com/openjdk/jdk/pull/4138 ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From redestad at openjdk.java.net Thu May 27 17:44:19 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 27 May 2021 17:44:19 GMT Subject: RFR: 8267529: StringJoiner can create a String that breaks String::equals Message-ID: This patch fixes a regression caused by https://bugs.openjdk.java.net/browse/JDK-8265237 where the result of String.join always get a UTF-16 coder if the delimiter is UTF-16, even when no delimiter is emitted. ------------- Commit messages: - Fix copyright, @bug - 8267529: StringJoiner can create a String that breaks String::equals Changes: https://git.openjdk.java.net/jdk/pull/4228/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4228&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267529 Stats: 18 lines in 2 files changed: 14 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4228.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4228/head:pull/4228 PR: https://git.openjdk.java.net/jdk/pull/4228 From github.com+9004656+yaaz at openjdk.java.net Thu May 27 17:45:40 2021 From: github.com+9004656+yaaz at openjdk.java.net (Nikita Gubarkov) Date: Thu, 27 May 2021 17:45:40 GMT Subject: RFR: 8267706: bin/idea.sh tries to use cygpath on WSL [v2] In-Reply-To: References: Message-ID: <0DoaFAz7PiavGkIxVLtyz_rIZl33AIZNHghzurXptnU=.82272491-d35c-4cb1-970a-2e2b6134d846@github.com> > 8267706: bin/idea.sh tries to use cygpath on WSL Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision: 8267706: Break long line in make/ide/idea/jdk/idea.gmk ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4190/files - new: https://git.openjdk.java.net/jdk/pull/4190/files/e1617757..f8d6c405 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4190&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4190&range=00-01 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4190.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4190/head:pull/4190 PR: https://git.openjdk.java.net/jdk/pull/4190 From prr at openjdk.java.net Thu May 27 17:46:07 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 27 May 2021 17:46:07 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang wrote: >> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed. >> >> The code change shows some common solutions to avoid such too wide annotations: >> >> 1. Extract calls into a method and add annotation on that method >> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded. >> 3. Put declaration and assignment into a single statement if possible. >> 4. Rewrite code to achieve #3 above. >> >> I'll add a copyright year update commit before integration. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > update FtpClient.java src/java.desktop/share/classes/java/awt/Component.java line 630: > 628: } > 629: > 630: @SuppressWarnings("removal") I'm confused. I thought the reason this wasn't done in the JEP implementation PR is because of refactoring that was needed because of the usage in this static block and you could not apply the annotation here. Yet it seems you are doing exactly what was supposed to be impossible with no refactoring. Can you explain ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4138 From godin at openjdk.java.net Thu May 27 18:06:20 2021 From: godin at openjdk.java.net (Evgeny Mandrikov) Date: Thu, 27 May 2021 18:06:20 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 17:52:36 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/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac. > - Correcting LineNumberTable for rule switches. > - Merging master into JDK-8262891 > - Fixing various error-related bugs. > - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default. > - Reflecting recent spec changes. > - Reflecting review comments. > - Reflecting review comments on SwitchBootstraps. > - Trailing whitespaces. > - Cleanup, reflecting review comments. > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501 > I've updated the code to produce better/more useful LineNumberTable for rule switches. @lahodaj I re-tested previous example and tested few others. Now everything seems to be good with `LineNumberTable` entries ?? ---- However I also noticed that for class Example { void example(String s) { switch (s) { case "a": System.out.println("a"); } } } there is difference in frames before and after this PR javap -v -p Example.class diff is line 3: 0 line 5: 60 line 7: 68 - StackMapTable: number_of_entries = 4 + StackMapTable: number_of_entries = 5 frame_type = 253 /* append */ - offset_delta = 28 + offset_delta = 4 locals = [ class java/lang/String, int ] + frame_type = 23 /* same */ frame_type = 10 /* same */ frame_type = 20 /* same */ frame_type = 249 /* chop */ and java -cp asm-util-9.1.jar:asm-9.1.jar org.objectweb.asm.util.Textifier Example.class diff is + L1 + FRAME APPEND [java/lang/String I] ALOAD 2 INVOKEVIRTUAL java/lang/String.hashCode ()I LOOKUPSWITCH - 97: L1 - default: L2 - L1 - FRAME APPEND [java/lang/String I] + 97: L2 + default: L3 + L2 + FRAME SAME Don't know about importance of this, and whether this was expected, but decided to mention. ------------- Marked as reviewed by godin (Author). PR: https://git.openjdk.java.net/jdk/pull/3863 From erikj at openjdk.java.net Thu May 27 18:10:07 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 27 May 2021 18:10:07 GMT Subject: RFR: 8267706: bin/idea.sh tries to use cygpath on WSL [v2] In-Reply-To: <0DoaFAz7PiavGkIxVLtyz_rIZl33AIZNHghzurXptnU=.82272491-d35c-4cb1-970a-2e2b6134d846@github.com> References: <0DoaFAz7PiavGkIxVLtyz_rIZl33AIZNHghzurXptnU=.82272491-d35c-4cb1-970a-2e2b6134d846@github.com> Message-ID: On Thu, 27 May 2021 17:45:40 GMT, Nikita Gubarkov wrote: >> 8267706: bin/idea.sh tries to use cygpath on WSL > > Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision: > > 8267706: Break long line in make/ide/idea/jdk/idea.gmk Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4190 From forax at openjdk.java.net Thu May 27 18:22:13 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 27 May 2021 18:22:13 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 17:52:36 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/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac. > - Correcting LineNumberTable for rule switches. > - Merging master into JDK-8262891 > - Fixing various error-related bugs. > - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default. > - Reflecting recent spec changes. > - Reflecting review comments. > - Reflecting review comments on SwitchBootstraps. > - Trailing whitespaces. > - Cleanup, reflecting review comments. > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501 > > I've updated the code to produce better/more useful LineNumberTable for rule switches. > > @lahodaj I re-tested previous example and tested few others. Now everything seems to be good with `LineNumberTable` entries +1 > [...] > Don't know about importance of this, and whether this was expected, but decided to mention. Look likes a mistake for me, you only need a StackFrame in front of the call to invokedynamic if it's the target of a goto and in your example, there is no guard so no backward goto. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From godin at openjdk.java.net Thu May 27 18:31:09 2021 From: godin at openjdk.java.net (Evgeny Mandrikov) Date: Thu, 27 May 2021 18:31:09 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 18:19:38 GMT, R?mi Forax wrote: > in your example, there is no guard so no backward goto @forax btw this example is not about switch pattern matching - it is about already existing string switch, where indy not involed ?? void example(java.lang.String); descriptor: (Ljava/lang/String;)V flags: (0x0000) Code: stack=2, locals=4, args_size=2 0: aload_1 1: astore_2 2: iconst_m1 3: istore_3 4: aload_2 5: invokevirtual #7 // Method java/lang/String.hashCode:()I 8: lookupswitch { // 1 97: 28 default: 39 } 28: aload_2 29: ldc #13 // String a 31: invokevirtual #15 // Method java/lang/String.equals:(Ljava/lang/Object;)Z 34: ifeq 39 37: iconst_0 38: istore_3 39: iload_3 40: lookupswitch { // 1 0: 60 default: 68 } 60: getstatic #19 // Field java/lang/System.out:Ljava/io/PrintStream; 63: ldc #13 // String a 65: invokevirtual #25 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 68: return LineNumberTable: line 3: 0 line 5: 60 line 7: 68 StackMapTable: number_of_entries = 5 frame_type = 253 /* append */ offset_delta = 4 locals = [ class java/lang/String, int ] frame_type = 23 /* same */ frame_type = 10 /* same */ frame_type = 20 /* same */ frame_type = 249 /* chop */ offset_delta = 7 ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From naoto at openjdk.java.net Thu May 27 20:11:12 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 27 May 2021 20:11:12 GMT Subject: RFR: 8267529: StringJoiner can create a String that breaks String::equals In-Reply-To: References: Message-ID: <5t5TLbiC5yGxRuL6YxV-QKQyl2n0FuBhiswbzsZDIG0=.acc7d696-6c86-4bd0-9566-616c6f6efefc@github.com> On Thu, 27 May 2021 17:38:42 GMT, Claes Redestad wrote: > This patch fixes a regression caused by https://bugs.openjdk.java.net/browse/JDK-8265237 where the result of String.join always get a UTF-16 coder if the delimiter is UTF-16, even when no delimiter is emitted. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4228 From weijun at openjdk.java.net Thu May 27 20:16:25 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 27 May 2021 20:16:25 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v5] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: > 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - move one annotation to new method - merge from master, two files removed, one needs merge - keep only one systemProperty tag - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java - feedback from Sean, Phil and Alan - add supresswarnings annotations automatically - manual change before automatic annotating - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal ------------- Changes: https://git.openjdk.java.net/jdk/pull/4073/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=04 Stats: 2022 lines in 825 files changed: 1884 ins; 10 del; 128 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From github.com+10835776+stsypanov at openjdk.java.net Thu May 27 20:25:11 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 27 May 2021 20:25:11 GMT Subject: Integrated: 8265418: Clean-up redundant null-checks of Class.getPackageName() In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 14:05:31 GMT, ?????? ??????? wrote: > As discussed in https://github.com/openjdk/jdk/pull/3464 we can clean-up null-checks remaining after [8142968](https://bugs.openjdk.java.net/browse/JDK-8142968) as Class.getPackageName() never returns null. This pull request has now been integrated. Changeset: ae258f1e Author: ?????? ??????? Committer: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/ae258f1e6a6335585190aaa9358a4290a453fdbf Stats: 20 lines in 8 files changed: 1 ins; 7 del; 12 mod 8265418: Clean-up redundant null-checks of Class.getPackageName() Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/3571 From redestad at openjdk.java.net Thu May 27 20:25:35 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 27 May 2021 20:25:35 GMT Subject: RFR: 8267529: StringJoiner can create a String that breaks String::equals [v2] In-Reply-To: References: Message-ID: > This patch fixes a regression caused by https://bugs.openjdk.java.net/browse/JDK-8265237 where the result of String.join always get a UTF-16 coder if the delimiter is UTF-16, even when no delimiter is emitted. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Add join of zero strings, clarify comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4228/files - new: https://git.openjdk.java.net/jdk/pull/4228/files/0e2ca7cd..b4b9d14d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4228&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4228&range=00-01 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4228.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4228/head:pull/4228 PR: https://git.openjdk.java.net/jdk/pull/4228 From dcubed at openjdk.java.net Thu May 27 20:29:22 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 27 May 2021 20:29:22 GMT Subject: Integrated: 8267886: ProblemList javax/management/remote/mandatory/connection/RMIConnector_NPETest.java Message-ID: A trivial fix to ProblemList javax/management/remote/mandatory/connection/RMIConnector_NPETest.java. ------------- Commit messages: - 8267886: ProblemList javax/management/remote/mandatory/connection/RMIConnector_NPETest.java Changes: https://git.openjdk.java.net/jdk/pull/4231/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4231&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267886 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4231/head:pull/4231 PR: https://git.openjdk.java.net/jdk/pull/4231 From smarks at openjdk.java.net Thu May 27 20:29:22 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 27 May 2021 20:29:22 GMT Subject: Integrated: 8267886: ProblemList javax/management/remote/mandatory/connection/RMIConnector_NPETest.java In-Reply-To: References: Message-ID: On Thu, 27 May 2021 20:17:59 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList javax/management/remote/mandatory/connection/RMIConnector_NPETest.java. Marked as reviewed by smarks (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4231 From dcubed at openjdk.java.net Thu May 27 20:29:22 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 27 May 2021 20:29:22 GMT Subject: Integrated: 8267886: ProblemList javax/management/remote/mandatory/connection/RMIConnector_NPETest.java In-Reply-To: References: Message-ID: On Thu, 27 May 2021 20:22:31 GMT, Stuart Marks wrote: >> A trivial fix to ProblemList javax/management/remote/mandatory/connection/RMIConnector_NPETest.java. > > Marked as reviewed by smarks (Reviewer). @stuart-marks - Thanks for the fast review. ------------- PR: https://git.openjdk.java.net/jdk/pull/4231 From dcubed at openjdk.java.net Thu May 27 20:29:23 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 27 May 2021 20:29:23 GMT Subject: Integrated: 8267886: ProblemList javax/management/remote/mandatory/connection/RMIConnector_NPETest.java In-Reply-To: References: Message-ID: On Thu, 27 May 2021 20:17:59 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList javax/management/remote/mandatory/connection/RMIConnector_NPETest.java. This pull request has now been integrated. Changeset: 8a31c075 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/8a31c07598cd5ea1305a9706d80b0251fd3a1e6d Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8267886: ProblemList javax/management/remote/mandatory/connection/RMIConnector_NPETest.java Reviewed-by: smarks ------------- PR: https://git.openjdk.java.net/jdk/pull/4231 From bpb at openjdk.java.net Thu May 27 20:42:20 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 27 May 2021 20:42:20 GMT Subject: RFR: 8267569: java.io.File.equals contains misleading Javadoc Message-ID: Modify the specification of `java.io.File.equals` to clarify that equality is based only on a comparison of abstract pathnames as opposed to the file system objects that the `File`s represent. ------------- Commit messages: - 8267569: java.io.File.equals contains misleading Javadoc Changes: https://git.openjdk.java.net/jdk/pull/4232/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4232&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267569 Stats: 9 lines in 1 file changed: 4 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4232.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4232/head:pull/4232 PR: https://git.openjdk.java.net/jdk/pull/4232 From lmesnik at openjdk.java.net Thu May 27 22:18:26 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 27 May 2021 22:18:26 GMT Subject: RFR: 8267893: Improve EFH do get native/mixed stack traces for cores and live processes Message-ID: EFH is improved to process cores and get mixed stack traces with jhsdb and native stack traces with gdb/lldb. It might be useful because hs_err doesn't contain info about all threads, sometimes it is even not generated. ------------- Commit messages: - Merge branch 'master' of https://github.com/openjdk/jdk into efh - EFH improvements Changes: https://git.openjdk.java.net/jdk/pull/4234/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4234&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267893 Stats: 188 lines in 13 files changed: 158 ins; 6 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/4234.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4234/head:pull/4234 PR: https://git.openjdk.java.net/jdk/pull/4234 From redestad at openjdk.java.net Thu May 27 23:13:10 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 27 May 2021 23:13:10 GMT Subject: RFR: 8267529: StringJoiner can create a String that breaks String::equals [v2] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 20:25:35 GMT, Claes Redestad wrote: >> This patch fixes a regression caused by https://bugs.openjdk.java.net/browse/JDK-8265237 where the result of String.join always get a UTF-16 coder if the delimiter is UTF-16, even when no delimiter is emitted. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Add join of zero strings, clarify comment Thanks for reviewing, Naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/4228 From redestad at openjdk.java.net Thu May 27 23:13:11 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 27 May 2021 23:13:11 GMT Subject: Integrated: 8267529: StringJoiner can create a String that breaks String::equals In-Reply-To: References: Message-ID: On Thu, 27 May 2021 17:38:42 GMT, Claes Redestad wrote: > This patch fixes a regression caused by https://bugs.openjdk.java.net/browse/JDK-8265237 where the result of String.join always get a UTF-16 coder if the delimiter is UTF-16, even when no delimiter is emitted. This pull request has now been integrated. Changeset: 95b1fa7a Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/95b1fa7a88ec3c017734c9d0a6b6b6117f74a610 Stats: 20 lines in 2 files changed: 16 ins; 0 del; 4 mod 8267529: StringJoiner can create a String that breaks String::equals Reviewed-by: naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/4228 From dholmes at openjdk.java.net Thu May 27 23:42:08 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 27 May 2021 23:42:08 GMT Subject: RFR: 8267893: Improve EFH do get native/mixed stack traces for cores and live processes In-Reply-To: References: Message-ID: On Thu, 27 May 2021 22:05:55 GMT, Leonid Mesnik wrote: > EFH is improved to process cores and get mixed stack traces with jhsdb and native stack traces with gdb/lldb. It might be useful because hs_err doesn't contain info about all threads, sometimes it is even not generated. Hi Leonid, What is EFH? Please update the bug and PR to explain. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/4234 From scolebourne at joda.org Fri May 28 00:03:22 2021 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 28 May 2021 01:03:22 +0100 Subject: Proposal for new interface: TimeSource In-Reply-To: References: <6622fc7d-3689-47c7-36ea-0bcb027bc1e0@oracle.com> Message-ID: Hi all, Is there anything I need to do to progress the CSR and/or PR? thanks Stephen On Thu, 13 May 2021 at 22:05, Stephen Colebourne wrote: > > On Wed, 12 May 2021 at 18:41, Roger Riggs wrote: > > Will you be posting a PR for the implementation? > > It is frequently helpful to evaluate the CSR and the implementation > > concurrently. > > PR: https://github.com/openjdk/jdk/pull/4016 > Issue: https://bugs.openjdk.java.net/browse/JDK-8266846 > CSR: https://bugs.openjdk.java.net/browse/JDK-8266847 > > The PR takes a middle ground approach to the implementation. > > It is not practical to remove the existing package-scoped Clock > implementation classes (SystemClock, TickClock, FixedClock, > OffsetClock) despite the fact that these would be better expressed as > classes that only implement `InstantSource`. However, given that > "system" is the 99%+ use case, I do believe it is worth adding a > dedicated `SystemInstantSource` class, as per the PR. > > To achieve this I moved the actual logic using > `VM.getNanoAdjustment()` into a static method which can then be called > directly from three places - Instant.now(), SystemClock and > SystemInstantSource. Previously, every instance of SystemClock > performed the VM/offset calculations separately. The new logic > performs them once based on a single shared static variable. I have no > reason to believe this changes the memory model or performance, but I > must flag it up for reviewers. > > When initially discussing the proposal, I planned to add a new static > method `Clock.of(InstantSource, ZoneId)`. When implementing the change > I found that the method was adding no value as the instance method > `InstantSource.withZone(ZoneId)` achieves the same outcome, so I > omitted it. > > The Mac test failure appears to be unconnected to the change. > > Thanks for any and all reviews! > Stephen From joe.darcy at oracle.com Fri May 28 00:06:04 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 27 May 2021 17:06:04 -0700 Subject: Proposal for new interface: TimeSource In-Reply-To: References: <6622fc7d-3689-47c7-36ea-0bcb027bc1e0@oracle.com> Message-ID: <03858b5e-6726-b2e5-5582-0295361c14cf@oracle.com> On 5/27/2021 5:03 PM, Stephen Colebourne wrote: > Hi all, > Is there anything I need to do to progress the CSR and/or PR? The CSR is in Provisional state. To request the second phase of CSR review, the assignee can Finalize the CSR; for more details see ??? https://wiki.openjdk.java.net/display/csr/Main HTH, -Joe From lmesnik at openjdk.java.net Fri May 28 00:57:09 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Fri, 28 May 2021 00:57:09 GMT Subject: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes In-Reply-To: References: Message-ID: On Thu, 27 May 2021 23:38:48 GMT, David Holmes wrote: > Hi Leonid, > > What is EFH? Please update the bug and PR to explain. > > Thanks, > David Updated summary to "Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes". ------------- PR: https://git.openjdk.java.net/jdk/pull/4234 From tvaleev at openjdk.java.net Fri May 28 02:00:55 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Fri, 28 May 2021 02:00:55 GMT Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit) [v9] In-Reply-To: References: Message-ID: > With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch. > > Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch: > > ref.SliceToList.seq_baseline:?gc.alloc.rate.norm 10000 thrpt 10 40235,534 ? 0,984 B/op > ref.SliceToList.seq_limit:?gc.alloc.rate.norm 10000 thrpt 10 106431,101 ? 0,198 B/op > ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm 10000 thrpt 10 106544,977 ? 1,983 B/op > value.SliceToArray.seq_baseline:?gc.alloc.rate.norm 10000 thrpt 10 40121,878 ? 0,247 B/op > value.SliceToArray.seq_limit:?gc.alloc.rate.norm 10000 thrpt 10 106317,693 ? 1,083 B/op > value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm 10000 thrpt 10 106430,954 ? 0,136 B/op > > > After patch: > > ref.SliceToList.seq_baseline:?gc.alloc.rate.norm 10000 thrpt 10 40235,648 ? 1,354 B/op > ref.SliceToList.seq_limit:?gc.alloc.rate.norm 10000 thrpt 10 40355,784 ? 1,288 B/op > ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm 10000 thrpt 10 40476,032 ? 2,855 B/op > value.SliceToArray.seq_baseline:?gc.alloc.rate.norm 10000 thrpt 10 40121,830 ? 0,308 B/op > value.SliceToArray.seq_limit:?gc.alloc.rate.norm 10000 thrpt 10 40242,554 ? 0,443 B/op > value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm 10000 thrpt 10 40363,674 ? 1,576 B/op > > > Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests. > > Before patch: > > Benchmark (size) Mode Cnt Score Error Units > ref.SliceToList.par_baseline 10000 thrpt 30 14876,723 ? 99,770 ops/s > ref.SliceToList.par_limit 10000 thrpt 30 14856,841 ? 215,089 ops/s > ref.SliceToList.par_skipLimit 10000 thrpt 30 9555,818 ? 991,335 ops/s > ref.SliceToList.seq_baseline 10000 thrpt 30 23732,290 ? 444,162 ops/s > ref.SliceToList.seq_limit 10000 thrpt 30 14894,040 ? 176,496 ops/s > ref.SliceToList.seq_skipLimit 10000 thrpt 30 10646,929 ? 36,469 ops/s > value.SliceToArray.par_baseline 10000 thrpt 30 25093,141 ? 376,402 ops/s > value.SliceToArray.par_limit 10000 thrpt 30 24798,889 ? 760,762 ops/s > value.SliceToArray.par_skipLimit 10000 thrpt 30 16456,310 ? 926,882 ops/s > value.SliceToArray.seq_baseline 10000 thrpt 30 69669,787 ? 494,562 ops/s > value.SliceToArray.seq_limit 10000 thrpt 30 21097,081 ? 117,338 ops/s > value.SliceToArray.seq_skipLimit 10000 thrpt 30 15522,871 ? 112,557 ops/s > > > After patch: > > Benchmark (size) Mode Cnt Score Error Units > ref.SliceToList.par_baseline 10000 thrpt 30 14793,373 ? 64,905 ops/s > ref.SliceToList.par_limit 10000 thrpt 30 13301,024 ? 1300,431 ops/s > ref.SliceToList.par_skipLimit 10000 thrpt 30 11131,698 ? 1769,932 ops/s > ref.SliceToList.seq_baseline 10000 thrpt 30 24101,048 ? 263,528 ops/s > ref.SliceToList.seq_limit 10000 thrpt 30 16872,168 ? 76,696 ops/s > ref.SliceToList.seq_skipLimit 10000 thrpt 30 11953,253 ? 105,231 ops/s > value.SliceToArray.par_baseline 10000 thrpt 30 25442,442 ? 455,554 ops/s > value.SliceToArray.par_limit 10000 thrpt 30 23111,730 ? 2246,086 ops/s > value.SliceToArray.par_skipLimit 10000 thrpt 30 17980,750 ? 2329,077 ops/s > value.SliceToArray.seq_baseline 10000 thrpt 30 66512,898 ? 1001,042 ops/s > value.SliceToArray.seq_limit 10000 thrpt 30 41792,549 ? 1085,547 ops/s > value.SliceToArray.seq_skipLimit 10000 thrpt 30 18007,613 ? 141,716 ops/s > > > I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes. Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/java/util/stream/AbstractPipeline.java Co-authored-by: Paul Sandoz ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3427/files - new: https://git.openjdk.java.net/jdk/pull/3427/files/719fee72..f21593e8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3427&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3427&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3427.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3427/head:pull/3427 PR: https://git.openjdk.java.net/jdk/pull/3427 From tvaleev at openjdk.java.net Fri May 28 02:00:56 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Fri, 28 May 2021 02:00:56 GMT Subject: Integrated: 8265029: Preserve SIZED characteristics on slice operations (skip, limit) In-Reply-To: References: Message-ID: On Sat, 10 Apr 2021 06:30:33 GMT, Tagir F. Valeev wrote: > With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch. > > Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch: > > ref.SliceToList.seq_baseline:?gc.alloc.rate.norm 10000 thrpt 10 40235,534 ? 0,984 B/op > ref.SliceToList.seq_limit:?gc.alloc.rate.norm 10000 thrpt 10 106431,101 ? 0,198 B/op > ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm 10000 thrpt 10 106544,977 ? 1,983 B/op > value.SliceToArray.seq_baseline:?gc.alloc.rate.norm 10000 thrpt 10 40121,878 ? 0,247 B/op > value.SliceToArray.seq_limit:?gc.alloc.rate.norm 10000 thrpt 10 106317,693 ? 1,083 B/op > value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm 10000 thrpt 10 106430,954 ? 0,136 B/op > > > After patch: > > ref.SliceToList.seq_baseline:?gc.alloc.rate.norm 10000 thrpt 10 40235,648 ? 1,354 B/op > ref.SliceToList.seq_limit:?gc.alloc.rate.norm 10000 thrpt 10 40355,784 ? 1,288 B/op > ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm 10000 thrpt 10 40476,032 ? 2,855 B/op > value.SliceToArray.seq_baseline:?gc.alloc.rate.norm 10000 thrpt 10 40121,830 ? 0,308 B/op > value.SliceToArray.seq_limit:?gc.alloc.rate.norm 10000 thrpt 10 40242,554 ? 0,443 B/op > value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm 10000 thrpt 10 40363,674 ? 1,576 B/op > > > Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests. > > Before patch: > > Benchmark (size) Mode Cnt Score Error Units > ref.SliceToList.par_baseline 10000 thrpt 30 14876,723 ? 99,770 ops/s > ref.SliceToList.par_limit 10000 thrpt 30 14856,841 ? 215,089 ops/s > ref.SliceToList.par_skipLimit 10000 thrpt 30 9555,818 ? 991,335 ops/s > ref.SliceToList.seq_baseline 10000 thrpt 30 23732,290 ? 444,162 ops/s > ref.SliceToList.seq_limit 10000 thrpt 30 14894,040 ? 176,496 ops/s > ref.SliceToList.seq_skipLimit 10000 thrpt 30 10646,929 ? 36,469 ops/s > value.SliceToArray.par_baseline 10000 thrpt 30 25093,141 ? 376,402 ops/s > value.SliceToArray.par_limit 10000 thrpt 30 24798,889 ? 760,762 ops/s > value.SliceToArray.par_skipLimit 10000 thrpt 30 16456,310 ? 926,882 ops/s > value.SliceToArray.seq_baseline 10000 thrpt 30 69669,787 ? 494,562 ops/s > value.SliceToArray.seq_limit 10000 thrpt 30 21097,081 ? 117,338 ops/s > value.SliceToArray.seq_skipLimit 10000 thrpt 30 15522,871 ? 112,557 ops/s > > > After patch: > > Benchmark (size) Mode Cnt Score Error Units > ref.SliceToList.par_baseline 10000 thrpt 30 14793,373 ? 64,905 ops/s > ref.SliceToList.par_limit 10000 thrpt 30 13301,024 ? 1300,431 ops/s > ref.SliceToList.par_skipLimit 10000 thrpt 30 11131,698 ? 1769,932 ops/s > ref.SliceToList.seq_baseline 10000 thrpt 30 24101,048 ? 263,528 ops/s > ref.SliceToList.seq_limit 10000 thrpt 30 16872,168 ? 76,696 ops/s > ref.SliceToList.seq_skipLimit 10000 thrpt 30 11953,253 ? 105,231 ops/s > value.SliceToArray.par_baseline 10000 thrpt 30 25442,442 ? 455,554 ops/s > value.SliceToArray.par_limit 10000 thrpt 30 23111,730 ? 2246,086 ops/s > value.SliceToArray.par_skipLimit 10000 thrpt 30 17980,750 ? 2329,077 ops/s > value.SliceToArray.seq_baseline 10000 thrpt 30 66512,898 ? 1001,042 ops/s > value.SliceToArray.seq_limit 10000 thrpt 30 41792,549 ? 1085,547 ops/s > value.SliceToArray.seq_skipLimit 10000 thrpt 30 18007,613 ? 141,716 ops/s > > > I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes. This pull request has now been integrated. Changeset: 0c9daa7e Author: Tagir F. Valeev URL: https://git.openjdk.java.net/jdk/commit/0c9daa7ed579cd82343f37a68964876ebc48122e Stats: 719 lines in 12 files changed: 623 ins; 8 del; 88 mod 8265029: Preserve SIZED characteristics on slice operations (skip, limit) Reviewed-by: psandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/3427 From weijun at openjdk.java.net Fri May 28 02:01:19 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 28 May 2021 02:01:19 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v5] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Thu, 27 May 2021 20:16:25 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - move one annotation to new method > - merge from master, two files removed, one needs merge > - keep only one systemProperty tag > - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java > - feedback from Sean, Phil and Alan > - add supresswarnings annotations automatically > - manual change before automatic annotating > - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal Two files were removed by JEP 403 and JEP 407, respectively. One method in `XMLSchemaFactory.java` got [its own](https://github.com/openjdk/jdk/commit/8c4719a58834dddcea39d69b199abf1aabf780e2#diff-593a224979eaff03e2a3df1863fcaf865364a31a2212cc0d1fe67a8458057857R429) `@SuppressWarnings` and have to be merged with the one here. Another file `ResourceBundle.java` had a portion of a method extracted into a [new method](https://github.com/openjdk/jdk/commit/a4c46e1e4f4f2f05c8002b2af683a390fc46b424#diff-59caf1a68085064b4b3eb4f6e33e440bb85ea93719f34660970e2d4eaf8ce469R3175) and the annotation must be moved there. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From iignatyev at openjdk.java.net Fri May 28 02:29:06 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 28 May 2021 02:29:06 GMT Subject: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes In-Reply-To: References: Message-ID: On Thu, 27 May 2021 22:05:55 GMT, Leonid Mesnik wrote: > EFH is improved to process cores and get mixed stack traces with jhsdb and native stack traces with gdb/lldb. It might be useful because hs_err doesn't contain info about all threads, sometimes it is even not generated. @lmesnik , how has this been tested? test/failure_handler/Makefile line 41: > 39: CONF_DIR = src/share/conf > 40: > 41: JAVA_RELEASE = 7 could you please update `DEPENDENCES` section in `test/failure_handler/README`? test/failure_handler/src/share/classes/jdk/test/failurehandler/ToolKit.java line 69: > 67: } > 68: } catch (IOException ioe) { > 69: // just silently skip gzipped core processing we don't silently ignore exceptions in `failure_handler`, we tend to print them so we at least have some echoes of what happened. test/failure_handler/src/share/classes/jdk/test/failurehandler/ToolKit.java line 71: > 69: // just silently skip gzipped core processing > 70: } > 71: unpackedCore.toFile().delete(); Suggestion: Paths.delete(unpackedCore); ``` ? test/failure_handler/src/share/classes/jdk/test/failurehandler/Utils.java line 73: > 71: InputStream stream = Utils.class.getResourceAsStream(resourceName); > 72: > 73: // EFH_CONF_DIR might re-defined to load custom configs for development purposes this also seems to be unrelated to the subject and does require documentation in `test/failure_handler/README`. test/failure_handler/src/share/classes/jdk/test/failurehandler/action/PatternAction.java line 63: > 61: } > 62: for (int i = 0, n = args.length; i < n; ++i) { > 63: args[i] = args[i].replace("%java", helper.findApp("java").getAbsolutePath()); are we sure that `java` from `PATH` (which is what `findApp` returns) is the right `java`? test/failure_handler/src/share/conf/common.properties line 38: > 36: jcmd.vm.system_properties \ > 37: jcmd.gc.heap_info jcmd.gc.class_histogram jcmd.gc.finalizer_info \ > 38: jcmd.vm.info \ this seems to be unrelated to the RFE you are working on. test/failure_handler/src/share/conf/common.properties line 67: > 65: cores=jhsdb.jstack > 66: jhsdb.jstack.app=jhsdb > 67: jhsdb.jstack.args=jstack --mixed --core %p --exe %java strictly speaking, we can't guarantee that the executable is always `bin/java`, but it's the most common and the most interesting case, so this assumption is good enough for our pourposes. could you please add a comment explaining this so the further reading won't be puzzled? test/failure_handler/src/share/conf/mac.properties line 68: > 66: native.jhsdb.app=bash > 67: native.jhsdb.jstack.delimiter=\0 > 68: native.jhsdb.jstack.args=-c\0DevToolsSecurity --status | grep -q enabled && jhsdb jstack --mixed --pid %p AFAICS `jhsdb` does check "Developer mode" on macos before trying to attach and will just report 'lack of privileges' (as opposed to hanging with a modal window asking for permission), so you can move `jshdb.jstack` to `common.properties`. ------------- Changes requested by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4234 From weijun at openjdk.java.net Fri May 28 02:54:05 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 28 May 2021 02:54:05 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 17:42:56 GMT, Phil Race wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> update FtpClient.java > > src/java.desktop/share/classes/java/awt/Component.java line 630: > >> 628: } >> 629: >> 630: @SuppressWarnings("removal") > > I'm confused. I thought the reason this wasn't done in the JEP implementation PR is because of refactoring > that was needed because of the usage in this static block and you could not apply the annotation here. > Yet it seems you are doing exactly what was supposed to be impossible with no refactoring. > Can you explain ? There *is* a tiny refactoring here: a new variable `s2` is introduced so the 2nd `doPrivileged` call on line 636 is now also in a declaration statement (for `s2`) and therefore annotatable. Without this I cannot add the annotation on line 635. ------------- PR: https://git.openjdk.java.net/jdk/pull/4138 From prr at openjdk.java.net Fri May 28 03:15:12 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 28 May 2021 03:15:12 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 02:50:55 GMT, Weijun Wang wrote: >> src/java.desktop/share/classes/java/awt/Component.java line 630: >> >>> 628: } >>> 629: >>> 630: @SuppressWarnings("removal") >> >> I'm confused. I thought the reason this wasn't done in the JEP implementation PR is because of refactoring >> that was needed because of the usage in this static block and you could not apply the annotation here. >> Yet it seems you are doing exactly what was supposed to be impossible with no refactoring. >> Can you explain ? > > There *is* a tiny refactoring here: a new variable `s2` is introduced so the 2nd `doPrivileged` call on line 636 is now also in a declaration statement (for `s2`) and therefore annotatable. Without this I cannot add the annotation on line 635. Ok. But I will quote you "This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class" So the way you explained this before made it sound like any time there was any SM API usage in a static block, the entire class needed to be annotated. Why has the explanation changed ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4138 From weijun at openjdk.java.net Fri May 28 03:22:03 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 28 May 2021 03:22:03 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 03:12:35 GMT, Phil Race wrote: >> There *is* a tiny refactoring here: a new variable `s2` is introduced so the 2nd `doPrivileged` call on line 636 is now also in a declaration statement (for `s2`) and therefore annotatable. Without this I cannot add the annotation on line 635. > > Ok. But I will quote you > "This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class" > > So the way you explained this before made it sound like any time there was any SM API usage in a static block, the entire class needed to be annotated. > > Why has the explanation changed ? I should have been more precise. An annotation can only be added on a declaration, whether it's a variable, a method, or a class. Static block is not a declaration and the only one covers it is the class. But then if it's on a local variable declaration inside a static block, we certainly can annotate on that variable. ------------- PR: https://git.openjdk.java.net/jdk/pull/4138 From dholmes at openjdk.java.net Fri May 28 05:50:06 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 28 May 2021 05:50:06 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v2] In-Reply-To: References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> Message-ID: On Thu, 27 May 2021 16:28:14 GMT, Maxim Kartashev wrote: >> src/hotspot/os/windows/os_windows.cpp line 1541: >> >>> 1539: void * os::dll_load(const char *utf8_name, char *ebuf, int ebuflen) { >>> 1540: LPWSTR utf16_name = NULL; >>> 1541: errno_t err = convert_UTF8_to_UTF16(utf8_name, &utf16_name); >> >> Do you have any figures on the cost of this additional conversion in relation to startup time? >> >> I'm already concerned to see that we have to perform each conversion twice via MultiByteToWideChar/WideCharToMultiByte, once to get the size and then to actually get the characters! This seems potentially very inefficient. > > I measured time spend converting the library path name relative to the overall time of a (successful) `os::dll_load()` call. It varies between a fraction of a percent to ~3% (see below for the actual data from a `release` build). I'll defer to your expertise wrt to these numbers. > > What can be done here (without changing os::dll_load() API) is to have a "fast path" for ascii-only path names, in which case no conversion is necessary, and a "slow path" for all the rest. This will complicate things a bit, but not by much, I believe. I am certainly willing to give that a try. Let me know what do you think. > > > > ./build/windows-x86_64-server-release/images/jdk/bin/java -jar ./build/windows-x86_64-server-fastdebug/images/jdk/demo/jfc/SwingSet2/SwingSet2.jar > 0.050% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\jimage.dll > 2.273% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.dll > 0.177% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\net.dll > 0.541% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\nio.dll > 0.359% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\zip.dll > 3.186% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\jimage.dll > 0.075% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\awt.dll > 0.232% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\freetype.dll > 0.136% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\fontmanager.dll > 0.170% for C:\cygwin64\home\maxim\work\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk\bin\javajpeg.dll The core-libs folks have the experience/expertise with these character encoding issues so I will defer to them. But someone should run this through our startup benchmarks to see if it makes a difference. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From alanb at openjdk.java.net Fri May 28 06:45:09 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 28 May 2021 06:45:09 GMT Subject: RFR: 8265418: Clean-up redundant null-checks of Class.getPackageName() [v3] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 11:19:24 GMT, ?????? ??????? wrote: >> As discussed in https://github.com/openjdk/jdk/pull/3464 we can clean-up null-checks remaining after [8142968](https://bugs.openjdk.java.net/browse/JDK-8142968) as Class.getPackageName() never returns null. > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8265418: Compare package names with == instead of equals() I see this has been integrated but I have concerns that the use-sites now all assume that the package name has been intern'ed. We may some crumbs, maybe in an implNote or comment in the Class::getPackageName code, otherwise we risk breakage if getPackageName changed to return a non-intern'ed string at some point. ------------- PR: https://git.openjdk.java.net/jdk/pull/3571 From github.com+10835776+stsypanov at openjdk.java.net Fri May 28 07:39:10 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 28 May 2021 07:39:10 GMT Subject: RFR: 8265418: Clean-up redundant null-checks of Class.getPackageName() [v3] In-Reply-To: References: Message-ID: <3fjgMp4uKWnUauQ-wvukKUAOsTYMvfPWrvtRi6FZxO8=.8e6dacaa-4e51-48b7-aaf6-628eb892e0b6@github.com> On Fri, 28 May 2021 06:41:51 GMT, Alan Bateman wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8265418: Compare package names with == instead of equals() > > I see this has been integrated but I have concerns that the use-sites now all assume that the package name has been intern'ed. We may some crumbs, maybe in an implNote or comment in the Class::getPackageName code, otherwise we risk breakage if getPackageName changed to return a non-intern'ed string at some point. @AlanBateman should I then add an implNote to explicitly specify that returned value must be interned? ------------- PR: https://git.openjdk.java.net/jdk/pull/3571 From alanb at openjdk.java.net Fri May 28 11:06:10 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 28 May 2021 11:06:10 GMT Subject: RFR: 8265418: Clean-up redundant null-checks of Class.getPackageName() [v3] In-Reply-To: References: Message-ID: <0LhQAhxiGFnzmrAKlKqKppwquze8jl6s8pU1Fb2Sh8w=.56e091d7-3208-48bf-8e25-2070dea8c93c@github.com> On Fri, 28 May 2021 06:41:51 GMT, Alan Bateman wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8265418: Compare package names with == instead of equals() > > I see this has been integrated but I have concerns that the use-sites now all assume that the package name has been intern'ed. We may some crumbs, maybe in an implNote or comment in the Class::getPackageName code, otherwise we risk breakage if getPackageName changed to return a non-intern'ed string at some point. > @AlanBateman should I then add an implNote to explicitly specify that returned value must be interned? We need to think about this. It's we are 200% sure it will always be intern'ed then it could be specified. If we aren't sure and document it in an implNote then I've doubt that code outside of the JDK may rely on it and we'll never be able to change it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3571 From jlahoda at openjdk.java.net Fri May 28 11:08:42 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 28 May 2021 11:08:42 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v6] In-Reply-To: References: Message-ID: <9siiRgAecypi4U4cS7zXk2MwDk3EsPZwvUtEMaGTJz8=.ed45bb06-c5d8-4efd-a35a-7e8a566858dd@github.com> > 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/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Avoiding unnecessary StackMap point. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/fd748501..a57d306b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=04-05 Stats: 76 lines in 2 files changed: 72 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Fri May 28 11:08:43 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 28 May 2021 11:08:43 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 18:28:13 GMT, Evgeny Mandrikov wrote: >>> > I've updated the code to produce better/more useful LineNumberTable for rule switches. >>> >>> @lahodaj I re-tested previous example and tested few others. Now everything seems to be good with `LineNumberTable` entries +1 >>> >> [...] >>> Don't know about importance of this, and whether this was expected, but decided to mention. >> >> Look likes a mistake for me, you only need a StackFrame in front of the call to invokedynamic if it's the target of a goto and in your example, there is no guard so no backward goto. > >> in your example, there is no guard so no backward goto > > @forax btw this example is not about switch pattern matching - it is about already existing string switch, where indy not involed ?? > > > void example(java.lang.String); > descriptor: (Ljava/lang/String;)V > flags: (0x0000) > Code: > stack=2, locals=4, args_size=2 > 0: aload_1 > 1: astore_2 > 2: iconst_m1 > 3: istore_3 > 4: aload_2 > 5: invokevirtual #7 // Method java/lang/String.hashCode:()I > 8: lookupswitch { // 1 > 97: 28 > default: 39 > } > 28: aload_2 > 29: ldc #13 // String a > 31: invokevirtual #15 // Method java/lang/String.equals:(Ljava/lang/Object;)Z > 34: ifeq 39 > 37: iconst_0 > 38: istore_3 > 39: iload_3 > 40: lookupswitch { // 1 > 0: 60 > default: 68 > } > 60: getstatic #19 // Field java/lang/System.out:Ljava/io/PrintStream; > 63: ldc #13 // String a > 65: invokevirtual #25 // Method java/io/PrintStream.println:(Ljava/lang/String;)V > 68: return > LineNumberTable: > line 3: 0 > line 5: 60 > line 7: 68 > StackMapTable: number_of_entries = 5 > frame_type = 253 /* append */ > offset_delta = 4 > locals = [ class java/lang/String, int ] > frame_type = 23 /* same */ > frame_type = 10 /* same */ > frame_type = 20 /* same */ > frame_type = 249 /* chop */ > offset_delta = 7 @Godin thanks for noticing the unnecessary point in the StackMap! I've limited the entry to only be present for pattern matching switches, so ordinary switches should now look as before. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From github.com+10835776+stsypanov at openjdk.java.net Fri May 28 11:35:08 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 28 May 2021 11:35:08 GMT Subject: RFR: 8265418: Clean-up redundant null-checks of Class.getPackageName() [v3] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 11:19:24 GMT, ?????? ??????? wrote: >> As discussed in https://github.com/openjdk/jdk/pull/3464 we can clean-up null-checks remaining after [8142968](https://bugs.openjdk.java.net/browse/JDK-8142968) as Class.getPackageName() never returns null. > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8265418: Compare package names with == instead of equals() I've looked into history and it appears, that the name of the package has been interned both in `NamedPackage` and `Class` since 8142968 where modular system was introduced ------------- PR: https://git.openjdk.java.net/jdk/pull/3571 From jlahoda at openjdk.java.net Fri May 28 11:36:10 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 28 May 2021 11:36:10 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 10:38:08 GMT, Maurizio Cimadamore wrote: >> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac. >> - Correcting LineNumberTable for rule switches. >> - Merging master into JDK-8262891 >> - Fixing various error-related bugs. >> - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default. >> - Reflecting recent spec changes. >> - Reflecting review comments. >> - Reflecting review comments on SwitchBootstraps. >> - Trailing whitespaces. >> - Cleanup, reflecting review comments. >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501 > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1657: > >> 1655: >> 1656: try { >> 1657: boolean enumSwitch = (seltype.tsym.flags() & Flags.ENUM) != 0; > > This is getting convoluted enough that an enum on the AST (e.g. SwitchKind) might be helpful to save some of these classification properties - which I imagine we have to redo at some point later (e.g. in Lower/TransPattern). I'm ok with fixing in a followup issue. Thanks Maurizio. Yes, some of the logic is partly repeated elsewhere, but I need to investigate how to improve that. I've filled: https://bugs.openjdk.java.net/browse/JDK-8267929 ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From aefimov at openjdk.java.net Fri May 28 14:58:10 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Fri, 28 May 2021 14:58:10 GMT Subject: Integrated: 8265309: com/sun/jndi/dns/ConfigTests/Timeout.java fails with "Address already in use" BindException In-Reply-To: References: Message-ID: On Thu, 27 May 2021 15:02:01 GMT, Aleksei Efimov wrote: > Hi, > > `com/sun/jndi/dns/ConfigTests/Timeout.java ` was seen failing intermittently with "Address already in use" `BindException`. The reason of this failure is that `disconnect` call in JNDI `DnsClient` fails to rebind the datagram socket to the original port during `disconnect` call (the failure is in `DatagramChannel::repairSocket`). > Since Datagram socket is not reused and closed after the failure `finally` block with the `disconnect` call can be removed. > > The fix was tested with all available JNDI/DNS tests, and no failures related to the change were observed. This pull request has now been integrated. Changeset: 0c0ff7fb Author: Aleksei Efimov URL: https://git.openjdk.java.net/jdk/commit/0c0ff7fb0c1ff45ebaee863f73902cab1e9de4f3 Stats: 31 lines in 2 files changed: 0 ins; 5 del; 26 mod 8265309: com/sun/jndi/dns/ConfigTests/Timeout.java fails with "Address already in use" BindException Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/4227 From rriggs at openjdk.java.net Fri May 28 15:07:07 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 28 May 2021 15:07:07 GMT Subject: RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams [v4] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 06:53:18 GMT, Alan Bateman wrote: > > Process is abstract. Is there any use for these new methods to be overridden? > > Perhaps they should be final. > > It's not clear to me that it is useful to extend Process outside of the JDK. Testing, wrapping, ...? It feels like this class wants to be sealed. Maybe we should look at deprecating the no-arg constructor, like Joe did recently with AccessibleObject. There are subclasses, even in the test suite, see ProcessTools, so its too late to seal it; It would be a compatibility issue. We can look at deprecation and strength reduction but in the current time frame (RPD1) I'd suggest making the new methods final. ------------- PR: https://git.openjdk.java.net/jdk/pull/4134 From dfuchs at openjdk.java.net Fri May 28 16:27:27 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 28 May 2021 16:27:27 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v12] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 22:11:54 GMT, Roger Riggs wrote: >> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. >> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional >> configuration mechanisms and filter utilities. >> >> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: >> http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html > > Roger Riggs 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 revision: > > - Merge branch 'master' into 8264859-context-filter-factory > - Added test for rejectUndecidedClass array cases > Added test for preventing disabling filter factory > Test cleanup > - Editorial updates to review comments. > Simplify the builtin filter factory implementation. > Add atomic update to setting the filter factory. > Clarify the description of OIS.setObjectInputFilter. > Cleanup of the example code. > - Editorial updates > Updated java.security properties to include jdk.serialFilterFactory > Added test cases to SerialFilterFactoryTest for java.security properties and > enabling of the SecurityManager with existing policy permission files > Corrected a test that OIS.setObjectInputFilter could not be called twice. > Removed a Factory test that was not intended to be committed > - Moved utility filter methods to be static on ObjectInputFilter > Rearranged the class javadoc of OIF to describe the parts of > deserialization filtering, filters, composite filters, and the filter factory. > And other review comment updates... > - Refactored tests for utility functions to SerialFilterFunctionTest.java > Deleted confused Config.allowMaxLimits() method > Updated example to match move of methods to Config > Added test of restriction on setting the filterfactory after a OIS has been created > Additional Editorial updates > - Move merge and rejectUndecidedClass methods to OIF.Config > As default methods on OIF, their implementations were not concrete and not trustable > - Review suggestions included; > Added @implSpec for default methods in OIF; > Added restriction that the filter factory cannot be set after an ObjectInputStream has been created and applied the current filter factory > - Editorial javadoc updated based on review comments. > Clarified behavior of rejectUndecidedClass method. > Example test added to check status returned from file. > - Editorial updates to review comments > Add filter tracing support > - ... and 3 more: https://git.openjdk.java.net/jdk/compare/cad27daf...0930f0f8 src/java.base/share/classes/java/io/ObjectInputFilter.java line 170: > 168: *

    For an application composed from multiple modules or libraries, the structure > 169: * of the application can be used to identify the classes to be allowed or rejected > 170: * by each {@linkplain ObjectInputStream} in each context of the application. Nit: should be `{@link }` here. src/java.base/share/classes/java/io/ObjectInputFilter.java line 352: > 350: * > 351: * @param predicate a predicate to test a non-null Class, non-null > 352: * @param otherStatus a Status to use if the predicate is {@code false} should it be specified that the `otherStatus` must also be non-null? Is there a blanket statement somewhere for NPE, or are `@throws NPE` clauses missing everywhere? I'm asking because elsewhere in the JDK we usually specify that "unless otherwise specified, null parameters are not allowed and a NullPointerException will be thrown". But here it seems the opposite direction has been taken (which is fine), but the fact that NPE will be thrown if `null` is passed for a parameter specified as non-null seems to be implicit. src/java.base/share/classes/java/io/ObjectInputFilter.java line 385: > 383: * @since 17 > 384: */ > 385: static ObjectInputFilter merge(ObjectInputFilter filter, ObjectInputFilter anotherFilter) { Same remark about NPE. Should it `@throws` or is there a blanket statement that makes it unnecessary? src/java.base/share/classes/java/io/ObjectInputFilter.java line 396: > 394: * are {@code REJECTED}. Either the class is not {@code ALLOWED} or > 395: * if the class is an array and the base component type is not allowed, > 396: * otherwise the result is {@code UNDECIDED}. Is there some part of the sentence missing here? I don't fully understand the "Either, or, otherwise" construct. src/java.base/share/classes/java/io/ObjectInputFilter.java line 638: > 636: if (filterString != null) { > 637: configLog.log(INFO, > 638: "Creating deserialization filter from {0}", filterString); Just double checking that you really want an `INFO` message here. With the default logging configuration, `INFO` messages will show up on the console. src/java.base/share/classes/java/io/ObjectInputFilter.java line 653: > 651: if (factoryClassName != null) { > 652: configLog.log(INFO, > 653: "Creating deserialization filter factory for {0}", factoryClassName); Same remark about using `INFO` level here. src/java.base/share/classes/java/io/ObjectInputFilter.java line 719: > 717: * @throws SecurityException if there is security manager and the > 718: * {@code SerializablePermission("serialFilter")} is not granted > 719: * @throws IllegalStateException if the filter has already been set {@code non-null} `* @throws IllegalStateException if the filter has already been set {@code non-null}` Is there a typo/word missing ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From naoto.sato at oracle.com Fri May 28 16:53:19 2021 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 28 May 2021 09:53:19 -0700 Subject: Proposal for new interface: TimeSource In-Reply-To: References: <6622fc7d-3689-47c7-36ea-0bcb027bc1e0@oracle.com> Message-ID: <4583d18e-39ca-9a41-31b1-0f494c2d8524@oracle.com> As I commented on the PR, the test needs to run in othervm mode: https://github.com/openjdk/jdk/pull/4016#issuecomment-844551175 --- a/test/jdk/java/time/test/TEST.properties +++ b/test/jdk/java/time/test/TEST.properties @@ -1,5 +1,5 @@ # java.time tests use TestNG TestNG.dirs = .. -othervm.dirs = java/time/chrono java/time/format +othervm.dirs = java/time lib.dirs = /test/lib /test/jdk/tools/lib lib.build = jdk.test.lib.RandomFactory This will run the test case in java/time directory explicitly in othervm mode, but other tests in java/time too, which may be unnecessary. I am not aware of other way to specify it individually. Naoto On 5/27/21 5:03 PM, Stephen Colebourne wrote: > Hi all, > Is there anything I need to do to progress the CSR and/or PR? > thanks > Stephen > > On Thu, 13 May 2021 at 22:05, Stephen Colebourne wrote: >> >> On Wed, 12 May 2021 at 18:41, Roger Riggs wrote: >>> Will you be posting a PR for the implementation? >>> It is frequently helpful to evaluate the CSR and the implementation >>> concurrently. >> >> PR: https://github.com/openjdk/jdk/pull/4016 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8266846 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8266847 >> >> The PR takes a middle ground approach to the implementation. >> >> It is not practical to remove the existing package-scoped Clock >> implementation classes (SystemClock, TickClock, FixedClock, >> OffsetClock) despite the fact that these would be better expressed as >> classes that only implement `InstantSource`. However, given that >> "system" is the 99%+ use case, I do believe it is worth adding a >> dedicated `SystemInstantSource` class, as per the PR. >> >> To achieve this I moved the actual logic using >> `VM.getNanoAdjustment()` into a static method which can then be called >> directly from three places - Instant.now(), SystemClock and >> SystemInstantSource. Previously, every instance of SystemClock >> performed the VM/offset calculations separately. The new logic >> performs them once based on a single shared static variable. I have no >> reason to believe this changes the memory model or performance, but I >> must flag it up for reviewers. >> >> When initially discussing the proposal, I planned to add a new static >> method `Clock.of(InstantSource, ZoneId)`. When implementing the change >> I found that the method was adding no value as the instance method >> `InstantSource.withZone(ZoneId)` achieves the same outcome, so I >> omitted it. >> >> The Mac test failure appears to be unconnected to the change. >> >> Thanks for any and all reviews! >> Stephen From bchristi at openjdk.java.net Fri May 28 19:19:56 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Fri, 28 May 2021 19:19:56 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v12] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 22:11:54 GMT, Roger Riggs wrote: >> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. >> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional >> configuration mechanisms and filter utilities. >> >> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: >> http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html > > Roger Riggs 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 revision: > > - Merge branch 'master' into 8264859-context-filter-factory > - Added test for rejectUndecidedClass array cases > Added test for preventing disabling filter factory > Test cleanup > - Editorial updates to review comments. > Simplify the builtin filter factory implementation. > Add atomic update to setting the filter factory. > Clarify the description of OIS.setObjectInputFilter. > Cleanup of the example code. > - Editorial updates > Updated java.security properties to include jdk.serialFilterFactory > Added test cases to SerialFilterFactoryTest for java.security properties and > enabling of the SecurityManager with existing policy permission files > Corrected a test that OIS.setObjectInputFilter could not be called twice. > Removed a Factory test that was not intended to be committed > - Moved utility filter methods to be static on ObjectInputFilter > Rearranged the class javadoc of OIF to describe the parts of > deserialization filtering, filters, composite filters, and the filter factory. > And other review comment updates... > - Refactored tests for utility functions to SerialFilterFunctionTest.java > Deleted confused Config.allowMaxLimits() method > Updated example to match move of methods to Config > Added test of restriction on setting the filterfactory after a OIS has been created > Additional Editorial updates > - Move merge and rejectUndecidedClass methods to OIF.Config > As default methods on OIF, their implementations were not concrete and not trustable > - Review suggestions included; > Added @implSpec for default methods in OIF; > Added restriction that the filter factory cannot be set after an ObjectInputStream has been created and applied the current filter factory > - Editorial javadoc updated based on review comments. > Clarified behavior of rejectUndecidedClass method. > Example test added to check status returned from file. > - Editorial updates to review comments > Add filter tracing support > - ... and 3 more: https://git.openjdk.java.net/jdk/compare/30e4a509...0930f0f8 Changes requested by bchristi (Reviewer). src/java.base/share/classes/java/io/ObjectInputFilter.java line 137: > 135: * {@linkplain #allowFilter(Predicate, Status) allow} or > 136: * {@linkplain #rejectFilter(Predicate, Status) reject} classes. > 137: *. Extra '.' on this line ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From rriggs at openjdk.java.net Fri May 28 19:55:37 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 28 May 2021 19:55:37 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v12] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 15:43:14 GMT, Daniel Fuchs wrote: >> Roger Riggs 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 revision: >> >> - Merge branch 'master' into 8264859-context-filter-factory >> - Added test for rejectUndecidedClass array cases >> Added test for preventing disabling filter factory >> Test cleanup >> - Editorial updates to review comments. >> Simplify the builtin filter factory implementation. >> Add atomic update to setting the filter factory. >> Clarify the description of OIS.setObjectInputFilter. >> Cleanup of the example code. >> - Editorial updates >> Updated java.security properties to include jdk.serialFilterFactory >> Added test cases to SerialFilterFactoryTest for java.security properties and >> enabling of the SecurityManager with existing policy permission files >> Corrected a test that OIS.setObjectInputFilter could not be called twice. >> Removed a Factory test that was not intended to be committed >> - Moved utility filter methods to be static on ObjectInputFilter >> Rearranged the class javadoc of OIF to describe the parts of >> deserialization filtering, filters, composite filters, and the filter factory. >> And other review comment updates... >> - Refactored tests for utility functions to SerialFilterFunctionTest.java >> Deleted confused Config.allowMaxLimits() method >> Updated example to match move of methods to Config >> Added test of restriction on setting the filterfactory after a OIS has been created >> Additional Editorial updates >> - Move merge and rejectUndecidedClass methods to OIF.Config >> As default methods on OIF, their implementations were not concrete and not trustable >> - Review suggestions included; >> Added @implSpec for default methods in OIF; >> Added restriction that the filter factory cannot be set after an ObjectInputStream has been created and applied the current filter factory >> - Editorial javadoc updated based on review comments. >> Clarified behavior of rejectUndecidedClass method. >> Example test added to check status returned from file. >> - Editorial updates to review comments >> Add filter tracing support >> - ... and 3 more: https://git.openjdk.java.net/jdk/compare/0c26d863...0930f0f8 > > src/java.base/share/classes/java/io/ObjectInputFilter.java line 396: > >> 394: * are {@code REJECTED}. Either the class is not {@code ALLOWED} or >> 395: * if the class is an array and the base component type is not allowed, >> 396: * otherwise the result is {@code UNDECIDED}. > > Is there some part of the sentence missing here? I don't fully understand the "Either, or, otherwise" construct. There is an extra "if" at line 395. it should be a more readable version of the list below implementing checkfilter. If it does not aid in understanding, it can be removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From github.com+9004656+yaaz at openjdk.java.net Fri May 28 19:57:26 2021 From: github.com+9004656+yaaz at openjdk.java.net (Nikita Gubarkov) Date: Fri, 28 May 2021 19:57:26 GMT Subject: Integrated: 8267706: bin/idea.sh tries to use cygpath on WSL In-Reply-To: References: Message-ID: <5fGbEK82GLJFg3mkT2fPEpjVena3PplrG_MMU3V_iAU=.3fc19daa-e42a-4979-a53c-574d826945b7@github.com> On Tue, 25 May 2021 16:37:30 GMT, Nikita Gubarkov wrote: > 8267706: bin/idea.sh tries to use cygpath on WSL This pull request has now been integrated. Changeset: 964bac9e Author: Nikita Gubarkov Committer: Alexey Ushakov URL: https://git.openjdk.java.net/jdk/commit/964bac9e38460df4bd1ad9d25136d5e9743028dd Stats: 672 lines in 14 files changed: 71 ins; 498 del; 103 mod 8267706: bin/idea.sh tries to use cygpath on WSL Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/4190 From rriggs at openjdk.java.net Fri May 28 19:59:39 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 28 May 2021 19:59:39 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v12] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 15:50:29 GMT, Daniel Fuchs wrote: >> Roger Riggs 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 revision: >> >> - Merge branch 'master' into 8264859-context-filter-factory >> - Added test for rejectUndecidedClass array cases >> Added test for preventing disabling filter factory >> Test cleanup >> - Editorial updates to review comments. >> Simplify the builtin filter factory implementation. >> Add atomic update to setting the filter factory. >> Clarify the description of OIS.setObjectInputFilter. >> Cleanup of the example code. >> - Editorial updates >> Updated java.security properties to include jdk.serialFilterFactory >> Added test cases to SerialFilterFactoryTest for java.security properties and >> enabling of the SecurityManager with existing policy permission files >> Corrected a test that OIS.setObjectInputFilter could not be called twice. >> Removed a Factory test that was not intended to be committed >> - Moved utility filter methods to be static on ObjectInputFilter >> Rearranged the class javadoc of OIF to describe the parts of >> deserialization filtering, filters, composite filters, and the filter factory. >> And other review comment updates... >> - Refactored tests for utility functions to SerialFilterFunctionTest.java >> Deleted confused Config.allowMaxLimits() method >> Updated example to match move of methods to Config >> Added test of restriction on setting the filterfactory after a OIS has been created >> Additional Editorial updates >> - Move merge and rejectUndecidedClass methods to OIF.Config >> As default methods on OIF, their implementations were not concrete and not trustable >> - Review suggestions included; >> Added @implSpec for default methods in OIF; >> Added restriction that the filter factory cannot be set after an ObjectInputStream has been created and applied the current filter factory >> - Editorial javadoc updated based on review comments. >> Clarified behavior of rejectUndecidedClass method. >> Example test added to check status returned from file. >> - Editorial updates to review comments >> Add filter tracing support >> - ... and 3 more: https://git.openjdk.java.net/jdk/compare/3d56b7b2...0930f0f8 > > src/java.base/share/classes/java/io/ObjectInputFilter.java line 352: > >> 350: * >> 351: * @param predicate a predicate to test a non-null Class, non-null >> 352: * @param otherStatus a Status to use if the predicate is {@code false} > > should it be specified that the `otherStatus` must also be non-null? > Is there a blanket statement somewhere for NPE, or are `@throws NPE` clauses missing everywhere? > I'm asking because elsewhere in the JDK we usually specify that "unless otherwise specified, null parameters are not allowed and a NullPointerException will be thrown". But here it seems the opposite direction has been taken (which is fine), but the fact that NPE will be thrown if `null` is passed for a parameter specified as non-null seems to be implicit. At the end of FIlterInputStream javadoc, there is the blanket statement. * Unless otherwise noted, passing a {@code null} argument to a * method in this interface and its nested classes will cause a * {@link NullPointerException} to be thrown.``` including non-null on the @ param line reinforces the point ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From rriggs at openjdk.java.net Fri May 28 20:07:37 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 28 May 2021 20:07:37 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v12] In-Reply-To: References: Message-ID: <5RLFIo18Kj3_-WodEZ8MK6teYR_KiJHweLeC0g5DDN0=.6449df00-40e2-404b-afce-a12f30a4a7e2@github.com> On Fri, 28 May 2021 15:58:17 GMT, Daniel Fuchs wrote: >> Roger Riggs 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 revision: >> >> - Merge branch 'master' into 8264859-context-filter-factory >> - Added test for rejectUndecidedClass array cases >> Added test for preventing disabling filter factory >> Test cleanup >> - Editorial updates to review comments. >> Simplify the builtin filter factory implementation. >> Add atomic update to setting the filter factory. >> Clarify the description of OIS.setObjectInputFilter. >> Cleanup of the example code. >> - Editorial updates >> Updated java.security properties to include jdk.serialFilterFactory >> Added test cases to SerialFilterFactoryTest for java.security properties and >> enabling of the SecurityManager with existing policy permission files >> Corrected a test that OIS.setObjectInputFilter could not be called twice. >> Removed a Factory test that was not intended to be committed >> - Moved utility filter methods to be static on ObjectInputFilter >> Rearranged the class javadoc of OIF to describe the parts of >> deserialization filtering, filters, composite filters, and the filter factory. >> And other review comment updates... >> - Refactored tests for utility functions to SerialFilterFunctionTest.java >> Deleted confused Config.allowMaxLimits() method >> Updated example to match move of methods to Config >> Added test of restriction on setting the filterfactory after a OIS has been created >> Additional Editorial updates >> - Move merge and rejectUndecidedClass methods to OIF.Config >> As default methods on OIF, their implementations were not concrete and not trustable >> - Review suggestions included; >> Added @implSpec for default methods in OIF; >> Added restriction that the filter factory cannot be set after an ObjectInputStream has been created and applied the current filter factory >> - Editorial javadoc updated based on review comments. >> Clarified behavior of rejectUndecidedClass method. >> Example test added to check status returned from file. >> - Editorial updates to review comments >> Add filter tracing support >> - ... and 3 more: https://git.openjdk.java.net/jdk/compare/62744b1b...0930f0f8 > > src/java.base/share/classes/java/io/ObjectInputFilter.java line 638: > >> 636: if (filterString != null) { >> 637: configLog.log(INFO, >> 638: "Creating deserialization filter from {0}", filterString); > > Just double checking that you really want an `INFO` message here. With the default logging configuration, `INFO` messages will show up on the console. That is unchanged in the PR, though DEBUG might be more appropriate. > src/java.base/share/classes/java/io/ObjectInputFilter.java line 719: > >> 717: * @throws SecurityException if there is security manager and the >> 718: * {@code SerializablePermission("serialFilter")} is not granted >> 719: * @throws IllegalStateException if the filter has already been set {@code non-null} > > `* @throws IllegalStateException if the filter has already been set {@code non-null}` > > Is there a typo/word missing ? non-null is unnecessary. ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From henryjen at openjdk.java.net Fri May 28 22:04:31 2021 From: henryjen at openjdk.java.net (Henry Jen) Date: Fri, 28 May 2021 22:04:31 GMT Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS Message-ID: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> ?d on macOS This patch simply round up the specified stack size to multiple of the system page size. Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output. ```code:java public class StackLeak { public int depth = 0; public void stackLeak() { depth++; stackLeak(); } public static void main(String[] args) { var test = new StackLeak(); try { test.stackLeak(); } catch (Throwable e) { System.out.println(test.depth); } } } ------------- Commit messages: - JDK-8236569: -Xss not multiple of 4K does not work for the main thread on macOS Changes: https://git.openjdk.java.net/jdk/pull/4256/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4256&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8236569 Stats: 23 lines in 2 files changed: 21 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4256.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4256/head:pull/4256 PR: https://git.openjdk.java.net/jdk/pull/4256 From bpb at openjdk.java.net Fri May 28 23:42:39 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 28 May 2021 23:42:39 GMT Subject: RFR: 8267569: java.io.File.equals contains misleading Javadoc [v2] In-Reply-To: References: Message-ID: > Modify the specification of `java.io.File.equals` to clarify that equality is based only on a comparison of abstract pathnames as opposed to the file system objects that the `File`s represent. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8267569: Put clarifying verbiage in an @implNote ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4232/files - new: https://git.openjdk.java.net/jdk/pull/4232/files/e9ac2179..acd072ab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4232&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4232&range=00-01 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4232.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4232/head:pull/4232 PR: https://git.openjdk.java.net/jdk/pull/4232 From joehw at openjdk.java.net Sat May 29 00:20:26 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Sat, 29 May 2021 00:20:26 GMT Subject: RFR: 8266559: XPathEvaluationResult.XPathResultType.NODESET maps to incorrect type Message-ID: Makes a correction to XPathEvaluationResult.XPathResultType.NODESET mapping. Clarifies the supported types for the evaluateExpression methods. Other changes were javadoc tag usages, e.g. s/the code tag/{@code ------------- Commit messages: - 8266559: XPathEvaluationResult.XPathResultType.NODESET maps to incorrect type Changes: https://git.openjdk.java.net/jdk/pull/4258/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4258&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266559 Stats: 77 lines in 4 files changed: 28 ins; 0 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/4258.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4258/head:pull/4258 PR: https://git.openjdk.java.net/jdk/pull/4258 From github.com+26887752+jaroslavtulach at openjdk.java.net Sat May 29 07:20:36 2021 From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach) Date: Sat, 29 May 2021 07:20:36 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code Message-ID: This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. This PR provides a test and a single line fix that makes `-XX:+PreserveAllAnnotations` useful in cooperation with `Class.getAnnotation(...)`. ------------- Commit messages: - Expose runtime invisible annotations via Class.getAnnotation when -XX:+PreserveAllAnnotations is on Changes: https://git.openjdk.java.net/jdk/pull/4245/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4245&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267936 Stats: 65 lines in 2 files changed: 61 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4245.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4245/head:pull/4245 PR: https://git.openjdk.java.net/jdk/pull/4245 From github.com+26887752+jaroslavtulach at openjdk.java.net Sat May 29 07:20:37 2021 From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach) Date: Sat, 29 May 2021 07:20:37 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code In-Reply-To: References: Message-ID: On Fri, 28 May 2021 12:56:39 GMT, Jaroslav Tulach wrote: > This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. > > Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. > > This PR provides a test and a single line fix that makes `-XX:+PreserveAllAnnotations` useful in cooperation with `Class.getAnnotation(...)`. There is an existing failing `test/jdk/java/lang/annotation/AnnotationType/AnnotationTypeRuntimeAssumptionTest.java` test - probably I should modify the fix to only skip the `Retention.RUNTIME` check when the `-XX:+PreserveAllAnnotations` option is on. Suggestions how to properly check value of `-XX:+PreserveAllAnnotations` from `sun/reflect/annotation/AnnotationParser.java ` welcomed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From scolebourne at openjdk.java.net Sun May 30 00:49:56 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Sun, 30 May 2021 00:49:56 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v5] In-Reply-To: References: Message-ID: <_bf5gSg6d_TO3LNPvS1R-1S1EO5E5cY_6v96jAlh1CQ=.98952087-dfcd-4919-8029-f3aaa055f69d@github.com> > 8266846: Add java.time.InstantSource Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: 8266846: Add java.time.InstantSource ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4016/files - new: https://git.openjdk.java.net/jdk/pull/4016/files/c7d9076b..f01c5cdd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4016&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4016&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4016.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4016/head:pull/4016 PR: https://git.openjdk.java.net/jdk/pull/4016 From dholmes at openjdk.java.net Sun May 30 03:03:11 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 30 May 2021 03:03:11 GMT Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS In-Reply-To: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: On Fri, 28 May 2021 21:55:24 GMT, Henry Jen wrote: > ?d on macOS > > This patch simply round up the specified stack size to multiple of the system page size. > > Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output. > > ```code:java > public class StackLeak { > public int depth = 0; > public void stackLeak() { > depth++; > stackLeak(); > } > > public static void main(String[] args) { > var test = new StackLeak(); > try { > test.stackLeak(); > } catch (Throwable e) { > System.out.println(test.depth); > } > } > } src/java.base/macosx/native/libjli/java_md_macosx.m line 727: > 725: > 726: static size_t alignUp(size_t stack_size) { > 727: long page_size = sysconf(_SC_PAGESIZE); In hotspot we use `getpagesize()`. There is also a guard for a very large stack (within a page of SIZE_MAX) so that rounding up does not produce zero. ------------- PR: https://git.openjdk.java.net/jdk/pull/4256 From alanb at openjdk.java.net Sun May 30 07:34:30 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 30 May 2021 07:34:30 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code In-Reply-To: References: Message-ID: On Fri, 28 May 2021 12:56:39 GMT, Jaroslav Tulach wrote: > This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. > > Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. > > This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on. JVMS 4.7.17 does allow for an implementation specific means to make available these annotations at run-time. I think we need to look into the history of `-XX:+PreserveAllAnnotations` to know if it was introduced for testing the VM code or for making available these otherwise invisible annotations at run-time as you propose. I'm also wondering how it might be used, is it to avoid tools needing to parse class files? is it because someone has missed RetentionPolicy.RUNTIME somewhere? ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From raffaello.giulietti at gmail.com Sun May 30 16:03:14 2021 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Sun, 30 May 2021 18:03:14 +0200 Subject: java.util.List missing from "Collections Framework Overview" javadoc Message-ID: <41ebc855-9767-91ea-aaff-c343846dec4d@gmail.com> Hello, seems like java.util.List is missing from the list in the "Collection Interfaces" section in https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/doc-files/coll-overview.html Should be easy to fix and doesn't seem to require a CSR as the document is non-normative. Greetings Raffaello From prr at openjdk.java.net Sun May 30 17:44:23 2021 From: prr at openjdk.java.net (Phil Race) Date: Sun, 30 May 2021 17:44:23 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang wrote: >> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed. >> >> The code change shows some common solutions to avoid such too wide annotations: >> >> 1. Extract calls into a method and add annotation on that method >> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded. >> 3. Put declaration and assignment into a single statement if possible. >> 4. Rewrite code to achieve #3 above. >> >> I'll add a copyright year update commit before integration. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > update FtpClient.java Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4138 From alanb at openjdk.java.net Sun May 30 18:44:17 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 30 May 2021 18:44:17 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code In-Reply-To: References: Message-ID: On Fri, 28 May 2021 12:56:39 GMT, Jaroslav Tulach wrote: > This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. > > Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. > > This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on. I checked the pre-OpenJDK history and `-XX:+PreserveAllAnnotations` dates from when JSR-175 support was added in JDK 5. It may have been useful during the development but I don't see any tests using it now. I don't think we want to create an attractive nuisance here and maybe this XX option should be deprecated so that it can be obsoleted and eventually removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From github.com+26887752+jaroslavtulach at openjdk.java.net Sun May 30 19:56:52 2021 From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach) Date: Sun, 30 May 2021 19:56:52 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v2] In-Reply-To: References: Message-ID: > This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. > > Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. > > This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on. Jaroslav Tulach has updated the pull request incrementally with one additional commit since the last revision: Only expose non RetentionPolicy.RUNTIME annotations when -XX:+PreserveAllAnnotations is specified ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4245/files - new: https://git.openjdk.java.net/jdk/pull/4245/files/e1aa800e..699861ef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4245&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4245&range=00-01 Stats: 20 lines in 5 files changed: 19 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4245.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4245/head:pull/4245 PR: https://git.openjdk.java.net/jdk/pull/4245 From github.com+26887752+jaroslavtulach at openjdk.java.net Sun May 30 20:09:19 2021 From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach) Date: Sun, 30 May 2021 20:09:19 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v2] In-Reply-To: References: Message-ID: On Sun, 30 May 2021 19:56:52 GMT, Jaroslav Tulach wrote: >> This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. >> >> Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. >> >> This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on. > > Jaroslav Tulach has updated the pull request incrementally with one additional commit since the last revision: > > Only expose non RetentionPolicy.RUNTIME annotations when -XX:+PreserveAllAnnotations is specified My use-case relates to [@JavaScriptBody](https://bits.netbeans.org/html+java/1.7.1/net/java/html/js/package-summary.html) annotation used for Java/JavaScript interop. Originally all existing usages (Post Processing Classes, Instrumentation Agent, Special classloading, etc.) of the annotation performed the manipulation on `.class` files. However recently a new use-case relying on JVMCI appeared. JVMCI is working on "live" classes and doesn't provide access to the `.class` files (as far as I know, CCing @dougxc). Using `-XX:+PreserveAllAnnotation` solved the first part of problem - the HotSpot code loaded the `RuntimeInvisibleAnnotations`"in". The second part was solved by on the fly patching of `@JavaScriptBody` class to claim to have`RetentionPolicy.RUNTIME`. That part is a bit tricky, so I created this pull request for your consideration. Obvious suggestion is to change the `@JavaScriptBody` retention to `RUNTIME` - however there are plenty of libraries already compiled with the existing annotation and they would have to be all recompiled to new version. I'd rather avoid that and that's another reason why I decided to bring the `-XX:+PreserveAllAnnotation` to your attention and propose to improve it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From dholmes at openjdk.java.net Sun May 30 22:10:20 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 30 May 2021 22:10:20 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v2] In-Reply-To: References: Message-ID: <002Atw8V5zaO1V3AoYbci_bhcdrHoqQFyfHYbkgIahM=.7aae1617-412b-4c4e-9292-0cc259540fb2@github.com> On Sun, 30 May 2021 19:56:52 GMT, Jaroslav Tulach wrote: >> This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. >> >> Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. >> >> This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on. > > Jaroslav Tulach has updated the pull request incrementally with one additional commit since the last revision: > > Only expose non RetentionPolicy.RUNTIME annotations when -XX:+PreserveAllAnnotations is specified Hotspot changes need to be reviewed on a hotspot mailing list ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From david.holmes at oracle.com Sun May 30 23:01:37 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 31 May 2021 09:01:37 +1000 Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code In-Reply-To: References: Message-ID: <39a1abe6-eb97-db67-9565-d99f4dba8a00@oracle.com> On 31/05/2021 4:44 am, Alan Bateman wrote: > On Fri, 28 May 2021 12:56:39 GMT, Jaroslav Tulach wrote: > >> This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. >> >> Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. >> >> This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on. > > I checked the pre-OpenJDK history and `-XX:+PreserveAllAnnotations` dates from when JSR-175 support was added in JDK 5. It may have been useful during the development but I don't see any tests using it now. I don't think we want to create an attractive nuisance here and maybe this XX option should be deprecated so that it can be obsoleted and eventually removed. I was a bit confused by this PR until I realized that annotations with CLASS retention policy must be represented in the classfile as RuntimeInvisible annotations - as the only affect of PreserveAllAnnotations is to make invisible annotations remain present in the runtime representation of the classfile, as allowed for by JVMS 4.7.17 (and related). As Alan notes we don't seem to have any tests (current or historical) for the operation of this flag (which is quite surprising) but its affect in the VM code is quite simple and obvious - and was recently extended to handle record attributes. I don't know what the design intent on the core reflection side was in relation to this. I could imagine a design that always asks the VM for any CLASS or RUNTIME retention annotation, knowing that the VM may have been instructed to preserve CLASS annotations. In that way the core reflection code would be oblivious to the means by which the VM was instructed to preserve said annotations. If core reflection has never exposed CLASS retention annotations even when PreserveAllAnnotations is set, then I would not support starting now. But if it is the case that only some recently added annotations are not conforming to pre-existing behaviour then I would support fixing those cases. However, given we have not previously needed to tell core reflection about the PreserveAllAnnotations flag, I would not want to start doing so now, as it should not be necessary. If PreserveAllAnnotations has hitherto been working exactly as one would expect given JVMS 4.7.17 etc, then I would certainly not support deprecating and removing it. But we should add in some tests. Cheers, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4245 > From tvaleev at openjdk.java.net Mon May 31 03:44:31 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Mon, 31 May 2021 03:44:31 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v7] In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: > Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. > > I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? Tagir F. Valeev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Rollback changes in j.u.concurrent (including formatting) - Rollback changes in j.u.concurrent - JapaneseImperialCalendar: use switch expressions - Use yield in java.util.Calendar.Builder.build - More vertical alignment - Vertical alignment for single-line switch rules - Indent some lines to make GitHub diff happier - Unindent switch cases to simplify the review - 8267587: Update java.util to use enhanced switch ------------- Changes: https://git.openjdk.java.net/jdk/pull/4161/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=06 Stats: 884 lines in 15 files changed: 108 ins; 328 del; 448 mod Patch: https://git.openjdk.java.net/jdk/pull/4161.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161 PR: https://git.openjdk.java.net/jdk/pull/4161 From tvaleev at openjdk.java.net Mon May 31 03:44:32 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Mon, 31 May 2021 03:44:32 GMT Subject: RFR: 8267587: Update java.util to use enhanced switch [v6] In-Reply-To: References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: <9TPuteZ19ff8QThVw9ABT1rkUXDBscW6RYLC8whOwUE=.d179dd55-5d88-4946-8088-cf34aa4ed241@github.com> On Thu, 27 May 2021 13:47:16 GMT, Daniel Fuchs wrote: >> Tagir F. Valeev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > src/java.base/share/classes/java/util/concurrent/FutureTask.java line 495: > >> 493: * @return a string representation of this FutureTask >> 494: */ >> 495: public String toString() { > > Classes in java.util.concurrent are handled upstream. It would probably be better to leave them out of this patch. Or synchronize with @DougLea to see how to bring these changes in the upstream repo. I rolled back changes in java.util.concurrent. Also, rebased the branch due to conflicts in JapaneseImperialCalendar.java ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From dholmes at openjdk.java.net Mon May 31 05:04:21 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 31 May 2021 05:04:21 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v6] In-Reply-To: References: Message-ID: 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 library load operation. >> >> Problem being fixed: >> >> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. >> >> Proposed fix: >> >> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. >> >> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. >> >> Testing: jtreg and jck testing with no regressions. A new regression test was developed. > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From github.com+26887752+jaroslavtulach at openjdk.java.net Mon May 31 05:58:54 2021 From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach) Date: Mon, 31 May 2021 05:58:54 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v3] In-Reply-To: References: Message-ID: <_6UOmCRmbn0sf-g1SgrV55lqd0kqIPZq3YwuOAJOnPs=.f543f365-c2ab-4bcf-9bd3-97eb24b61ea2@github.com> > This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. > > Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. > > This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on. Jaroslav Tulach has updated the pull request incrementally with two additional commits since the last revision: - Merging with test for long time existing behavior of -XX:+PreserveAllAnnotations - Test long time existing behavior of -XX:+PreserveAllAnnotations ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4245/files - new: https://git.openjdk.java.net/jdk/pull/4245/files/699861ef..9548a565 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4245&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4245&range=01-02 Stats: 172 lines in 1 file changed: 172 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4245.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4245/head:pull/4245 PR: https://git.openjdk.java.net/jdk/pull/4245 From github.com+26887752+jaroslavtulach at openjdk.java.net Mon May 31 06:06:37 2021 From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach) Date: Mon, 31 May 2021 06:06:37 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v4] In-Reply-To: References: Message-ID: > This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. > > Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. > > This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on. Jaroslav Tulach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision: - Merging with test for long time existing behavior of -XX:+PreserveAllAnnotations - Test long time existing behavior of -XX:+PreserveAllAnnotations ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4245/files - new: https://git.openjdk.java.net/jdk/pull/4245/files/9548a565..0fd2fced Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4245&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4245&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4245.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4245/head:pull/4245 PR: https://git.openjdk.java.net/jdk/pull/4245 From github.com+26887752+jaroslavtulach at openjdk.java.net Mon May 31 06:11:18 2021 From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach) Date: Mon, 31 May 2021 06:11:18 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code In-Reply-To: <39a1abe6-eb97-db67-9565-d99f4dba8a00@oracle.com> References: <39a1abe6-eb97-db67-9565-d99f4dba8a00@oracle.com> Message-ID: On Sun, 30 May 2021 23:03:55 GMT, David Holmes wrote: > But we should add in some tests. Right, I was surprised by missing tests as well. I've just created a _"standalone"_ commit 0f689ea that adds such test and also shows the way I am currently using the `-XX:+PreserveAllAnnotations` flag. It [requires some tricks](https://github.com/openjdk/jdk/pull/4245/files#r642231785) with `ClassLoader` and bytecode manipulation to change the retention to `RUNTIME` and then (in combination with `-XX:+PreserveAllAnnotations`) the annotation is accessible. The test in 0f689ea is _"standalone"_ - e.g. it can be merged without my other changes. However I continue to hope the change in `Class.getAnnotation` could get in: the `-XX:+PreserveAllAnnotation` option hasn't caused any issues since Java 5 - this is the first improvement ever requested. Possibly also the last one - tests are written & the functionality works - what else could one want? ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From github.com+26887752+jaroslavtulach at openjdk.java.net Mon May 31 06:11:19 2021 From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach) Date: Mon, 31 May 2021 06:11:19 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v4] In-Reply-To: References: Message-ID: <4AhvezrrqEsGgjQvac9Uw0sZa1TTjpVzEX8YPvwLQsk=.c12ac5c9-e8c4-4fbe-8c5e-80105ffef298@github.com> On Mon, 31 May 2021 06:06:37 GMT, Jaroslav Tulach wrote: >> This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. >> >> Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. >> >> This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on. > > Jaroslav Tulach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. test/jdk/java/lang/annotation/AnnotationType/AnnotationTypeChangedToRuntimeTest.java line 56: > 54: @Retention(RUNTIME) > 55: @AnnB > 56: public @interface AnnA_v2 { The `AltClassLoader` uses `AnnA_v2` instead of `AnnA_v1` when loading the classes and that makes (in cooperation with `-XX:+PreserveAllAnnotations` flag) the `RuntimeInvisibleAnnotation` visible. ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From david.holmes at oracle.com Mon May 31 06:53:09 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 31 May 2021 16:53:09 +1000 Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code In-Reply-To: References: <39a1abe6-eb97-db67-9565-d99f4dba8a00@oracle.com> Message-ID: <15f96673-d3cf-95eb-a8ed-aa2570066c2d@oracle.com> On 31/05/2021 4:11 pm, Jaroslav Tulach wrote: > On Sun, 30 May 2021 23:03:55 GMT, David Holmes wrote: > >> But we should add in some tests. > > Right, I was surprised by missing tests as well. I've just created a _"standalone"_ commit 0f689ea that adds such test and also shows the way I am currently using the `-XX:+PreserveAllAnnotations` flag. It [requires some tricks](https://github.com/openjdk/jdk/pull/4245/files#r642231785) with `ClassLoader` and bytecode manipulation to change the retention to `RUNTIME` and then (in combination with `-XX:+PreserveAllAnnotations`) the annotation is accessible. I was thinking (not for this PR of course) of something a bit more comprehensive that simply defined a class with methods/fields with both class-retention and runtime-retention attributes (there are 8 cases of "invisible" annotations IIRC) that verified their presence/absence both with and without PreserveAllAnnotation. > The test in 0f689ea is _"standalone"_ - e.g. it can be merged without my other changes. However I continue to hope the change in `Class.getAnnotation` could get in: the `-XX:+PreserveAllAnnotation` option hasn't caused any issues since Java 5 - this is the first improvement ever requested. Possibly also the last one - tests are written & the functionality works - what else could one want? I'll have to defer to core-libs folk here. As I said I would have expected the Java code to just ask the VM for the annotations applied to a given element, and that the VM would return the CLASS retention ones if PreserveAllAnnotation was set. I don't understand how the AnnotationParser is used in general and as it is not part of the VM the part of the JVMS that talks about exposing invisible annotations is not really applicable. Perhaps an oversight when this API was created, but I don't know. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4245 > From alanb at openjdk.java.net Mon May 31 07:10:18 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 31 May 2021 07:10:18 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v2] In-Reply-To: References: Message-ID: <3zOePsWq4Kio0lgR1mfkshO5RYsbvB9GKQai7emntYs=.3e205c99-0fdf-46b1-8213-74699237babd@github.com> On Sun, 30 May 2021 20:06:49 GMT, Jaroslav Tulach wrote: > Obvious suggestion is to change the `@JavaScriptBody` retention to `RUNTIME` - however there are plenty of libraries already compiled with the existing annotation and they would have to be all recompiled to new version. I'd rather avoid that and that's another reason why I decided to bring the `-XX:+PreserveAllAnnotation` to your attention and propose to improve it. I don't know anything about JavaScriptBody but this reads like they declared their annotations to have CLASS retention when they should have used RUNTIME retention. There's something very uncomfortable with changing the JDK as a workaround and telling JavaScriptBody users that you need to run with +PreserveAllAnnotations to get correct behavior. I would be concerned that leads to frameworks requesting it be the default so they can avoid parsing class files. @dougxc @vnkozlov Has there been any other cases where the Graal compiler has needed to get access to the class files? ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From github.com+10835776+stsypanov at openjdk.java.net Mon May 31 07:45:37 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 31 May 2021 07:45:37 GMT Subject: RFR: 8267921: Remove redundant loop from sun.reflect.misc.ReflectUtil.privateCheckPackageAccess() Message-ID: 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 innermost component type. ------------- Commit messages: - 8267921: Remove redundant loop from sun.reflect.misc.ReflectUtil.privateCheckPackageAccess() Changes: https://git.openjdk.java.net/jdk/pull/4268/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4268&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267921 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4268.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4268/head:pull/4268 PR: https://git.openjdk.java.net/jdk/pull/4268 From tvaleev at openjdk.java.net Mon May 31 08:52:23 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Mon, 31 May 2021 08:52:23 GMT Subject: Integrated: 8267587: Update java.util to use enhanced switch In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com> Message-ID: On Mon, 24 May 2021 04:20:23 GMT, Tagir F. Valeev wrote: > Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. > > I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? This pull request has now been integrated. Changeset: ab5a7ff2 Author: Tagir F. Valeev URL: https://git.openjdk.java.net/jdk/commit/ab5a7ff2304dd4cb069ae2bbd6fdd99b3de7a6a3 Stats: 884 lines in 15 files changed: 108 ins; 328 del; 448 mod 8267587: Update java.util to use enhanced switch Reviewed-by: iris ------------- PR: https://git.openjdk.java.net/jdk/pull/4161 From dnsimon at openjdk.java.net Mon May 31 09:06:21 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 31 May 2021 09:06:21 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v4] In-Reply-To: References: Message-ID: On Mon, 31 May 2021 06:06:37 GMT, Jaroslav Tulach wrote: >> This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. >> >> Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. >> >> This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on. > > Jaroslav Tulach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. There is [support for parsing class files in Graal](https://github.com/oracle/graal/blob/89e4cfc7ae/compiler/src/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/classfile/ClassfileBytecodeProvider.java#L45-L47) which exists to avoids all bytecode preprocessing and instrumentation that may be performed on the VM internal bytecode representation. This is only done for trusted bytecode that comes from Graal classes (e.g. [Java source code snippets](https://github.com/oracle/graal/blob/89e4cfc7ae/compiler/src/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/AllocationSnippets.java#L50-L72) used to express compiler (sub)graphs as Java source code). ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From plevart at openjdk.java.net Mon May 31 09:57:21 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 31 May 2021 09:57:21 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v6] In-Reply-To: References: Message-ID: <646K-BjGnrNG16m4_8XvFdOqZF514oJVQPDp0snmCQM=.8ef59b65-00d7-4fc5-8534-7494d0cf8cbd@github.com> 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 library load operation. >> >> Problem being fixed: >> >> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. >> >> Proposed fix: >> >> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. >> >> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. >> >> Testing: jtreg and jck testing with no regressions. A new regression test was developed. > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > address review comments The changes look good, Aleksei. ------------- Marked as reviewed by plevart (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3976 From plevart at openjdk.java.net Mon May 31 09:57:22 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 31 May 2021 09:57:22 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v5] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 14:28:09 GMT, Aleksei Voitylov wrote: >> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 481: >> >>> 479: throw new Error("Maximum lock count exceeded"); >>> 480: } >>> 481: >> >> Hi Aleksei, >> I know in practice this counter will never overflow, but just to be pedantic, it would be better that you either decrement back the counter before throwing Error or you check for overflow without incrementing it. Otherwise the lock is left in a corrupted state since you use it like this: >> >> >> acquireNativeLibraryLock(name); >> try { >> ... >> } finally { >> releaseNativeLibraryLock(name); >> } >> >> ...you see, if acquire fails, it is not paired with release, which is correct since the ReentrantLock has not been acquired, but the counter *HAS* been incremented... > > Peter, the updated version checks if counter hits MAX_VALUE before incrementing. It also means the counter can't underflow, so that check is removed. This is good now. ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From plevart at openjdk.java.net Mon May 31 10:29:23 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 31 May 2021 10:29:23 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v2] In-Reply-To: References: Message-ID: On Sun, 30 May 2021 20:06:49 GMT, Jaroslav Tulach wrote: > My use-case relates to [@JavaScriptBody](https://bits.netbeans.org/html+java/1.7.1/net/java/html/js/package-summary.html) annotation used for Java/JavaScript interop. Originally all existing usages (Post Processing Classes, Instrumentation Agent, Special classloading, etc.) of the annotation performed the manipulation on `.class` files. However recently a new use-case relying on JVMCI appeared. JVMCI is working on "live" classes and doesn't provide access to the `.class` files (as far as I know, CCing @dougxc). Using `-XX:+PreserveAllAnnotation` solved the first part of problem - the HotSpot code loaded the `RuntimeInvisibleAnnotations`"in". The second part was solved by on the fly patching of `@JavaScriptBody` class to claim to have`RetentionPolicy.RUNTIME`. That part is a bit tricky, so I created this pull request for your consideration. > > Obvious suggestion is to change the `@JavaScriptBody` retention to `RUNTIME` - however there are plenty of libraries already compiled with the existing annotation and they would have to be all recompiled to new version. I'd rather avoid that and that's another reason why I decided to bring the `-XX:+PreserveAllAnnotation` to your attention and propose to improve it. Hi Jaroslav, If you change `@JavaScriptBody` retention to `RUNTIME`, you don't need to re-compile any code that uses this annotation. You just have to use `-XX:+PreserveAllAnnotations` to expose all anotations to JVM and consequently to AnnotationParser. The parser will then return just the `RUNTIME` retention-marked annotations. This means you just have to run the app with the version of the JavaScriptBody.class that is retention-marked as `RUNTIME`... I think that `-XX:+PreserveAllAnnotations` was meant as a migration aid for exactly the case when some annotations migrate from `CLASS` to `RUNTIME` retention and libraries using such annotations are not re-compiled yet. ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From xgong at openjdk.java.net Mon May 31 10:32:35 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Mon, 31 May 2021 10:32:35 GMT Subject: RFR: 8267969: Add vectorized implementation for VectorMask.eq() Message-ID: <-oNx_BVgkjNGZHqtQhQ2hfnyibAd-NIj14iA3OUMBNk=.7be0c875-fab0-47b2-8af6-603eaf168941@github.com> Currently `"VectorMask.eq()" `is not vectorized: public VectorMask eq(VectorMask m) { // FIXME: Generate good code here. return bOp(m, (i, a, b) -> a == b); } This can be implemented by calling `"xor(m.not())"` directly. The performance improved about 1.4x ~ 1.9x for the following benchmark with different basic types: @Benchmark public Object eq() { boolean[] ma = fm.apply(size); boolean[] mb = fmb.apply(size); boolean[] mt = fmt.apply(size); VectorMask m = VectorMask.fromArray(SPECIES, mt, 0); for (int ic = 0; ic < INVOC_COUNT; ic++) { for (int i = 0; i < ma.length; i += SPECIES.length()) { var av = SPECIES.loadMask(ma, i); var bv = SPECIES.loadMask(mb, i); // accumulate results, so JIT can't eliminate relevant computations m = m.and(av.eq(bv)); } } return m; } ------------- Commit messages: - 8267969: Add vectorized implementation for VectorMask.eq() Changes: https://git.openjdk.java.net/jdk/pull/4272/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4272&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267969 Stats: 254 lines in 32 files changed: 248 ins; 6 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4272.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4272/head:pull/4272 PR: https://git.openjdk.java.net/jdk/pull/4272 From plevart at openjdk.java.net Mon May 31 10:36:20 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 31 May 2021 10:36:20 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v4] In-Reply-To: References: Message-ID: On Mon, 31 May 2021 06:06:37 GMT, Jaroslav Tulach wrote: >> This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. >> >> Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. >> >> This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on. > > Jaroslav Tulach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. I think it would be wrong to extend the meaning of `-XX:+PreserveAllAnnotations` to the AnnotationParser so it would return CLASS retention-marked annotations. `-XX:+PreserveAllAnnotations` is just disabling the JVM optimization and it is not meant to be "visible" in the Java code. ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From chegar at openjdk.java.net Mon May 31 10:37:23 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Mon, 31 May 2021 10:37:23 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v6] In-Reply-To: References: Message-ID: 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 library load operation. >> >> Problem being fixed: >> >> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. >> >> Proposed fix: >> >> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. >> >> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. >> >> Testing: jtreg and jck testing with no regressions. A new regression test was developed. > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From plevart at openjdk.java.net Mon May 31 12:05:23 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 31 May 2021 12:05:23 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v4] In-Reply-To: References: Message-ID: On Mon, 31 May 2021 06:06:37 GMT, Jaroslav Tulach wrote: >> This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. >> >> Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. >> >> This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on. > > Jaroslav Tulach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. A suggestion for this RFR. Maybe the title of the issue could be rephrased as: "Add a test for -XX+PreserveAllAnnotations option" A test could be constructed so that it would mimic the migration of an annotation from CLASS to RUNTIME retention by using separate compilation of: 1. an annotation with CLASS retention together with a class that uses it to annotate itself 2. the same type of annotation but with RUNTIME retention The test would use a class from compilation (1) combined with annotation from compilation (2) together with `-XX+PreserveAllAnnotations` JVM option to verify that the annotation is visible via reflection. No ClassLoader magic is necessary. WDYT? ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From david.holmes at oracle.com Mon May 31 12:35:54 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 31 May 2021 22:35:54 +1000 Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v2] In-Reply-To: References: Message-ID: <77371781-b7f8-f2b0-8299-f56f485fd222@oracle.com> On 31/05/2021 8:29 pm, Peter Levart wrote: > On Sun, 30 May 2021 20:06:49 GMT, Jaroslav Tulach wrote: > >> My use-case relates to [@JavaScriptBody](https://bits.netbeans.org/html+java/1.7.1/net/java/html/js/package-summary.html) annotation used for Java/JavaScript interop. Originally all existing usages (Post Processing Classes, Instrumentation Agent, Special classloading, etc.) of the annotation performed the manipulation on `.class` files. However recently a new use-case relying on JVMCI appeared. JVMCI is working on "live" classes and doesn't provide access to the `.class` files (as far as I know, CCing @dougxc). Using `-XX:+PreserveAllAnnotation` solved the first part of problem - the HotSpot code loaded the `RuntimeInvisibleAnnotations`"in". The second part was solved by on the fly patching of `@JavaScriptBody` class to claim to have`RetentionPolicy.RUNTIME`. That part is a bit tricky, so I created this pull request for your consideration. >> >> Obvious suggestion is to change the `@JavaScriptBody` retention to `RUNTIME` - however there are plenty of libraries already compiled with the existing annotation and they would have to be all recompiled to new version. I'd rather avoid that and that's another reason why I decided to bring the `-XX:+PreserveAllAnnotation` to your attention and propose to improve it. > > Hi Jaroslav, > > If you change `@JavaScriptBody` retention to `RUNTIME`, you don't need to re-compile any code that uses this annotation. You just have to use `-XX:+PreserveAllAnnotations` to expose all anotations to JVM and consequently to AnnotationParser. The parser will then return just the `RUNTIME` retention-marked annotations. This means you just have to run the app with the version of the JavaScriptBody.class that is retention-marked as `RUNTIME`... > > I think that `-XX:+PreserveAllAnnotations` was meant as a migration aid for exactly the case when some annotations migrate from `CLASS` to `RUNTIME` retention and libraries using such annotations are not re-compiled yet. That reads backwards to me. +PreserveAllAnnotations means that CLASS retention annotations are retained by the VM not just RUNTIME ones. So in that sense it might be a migration aid if moving from RUNTIME to CLASS, not CLASS to RUNTIME. David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4245 > From jlahoda at openjdk.java.net Mon May 31 13:49:56 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 31 May 2021 13:49:56 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v7] In-Reply-To: References: Message-ID: > 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/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision: - Fixing tests. - Total pattern dominates the null pattern. - Properly report errors for pattern+default clash. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/a57d306b..a49b6109 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=05-06 Stats: 52 lines in 6 files changed: 45 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From chegar at openjdk.java.net Mon May 31 14:10:57 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Mon, 31 May 2021 14:10:57 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v9] In-Reply-To: <9qJLk6We2yEGQiMS0y-A8ggivVfCwcwrD7YP3IVC7qw=.017684f1-3e5f-4ae9-ba1e-c13b62127698@github.com> References: <9qJLk6We2yEGQiMS0y-A8ggivVfCwcwrD7YP3IVC7qw=.017684f1-3e5f-4ae9-ba1e-c13b62127698@github.com> Message-ID: On Mon, 31 May 2021 14:07:54 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon 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 10 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Added missing brace > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Removed trailing whitespace > - 8267670: Remove redundant code from switch > - 8267670: Updated code to use yield > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Update java.io, java.math, and java.text to use switch expressions Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From pconcannon at openjdk.java.net Mon May 31 14:10:50 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Mon, 31 May 2021 14:10:50 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v9] In-Reply-To: References: Message-ID: <9qJLk6We2yEGQiMS0y-A8ggivVfCwcwrD7YP3IVC7qw=.017684f1-3e5f-4ae9-ba1e-c13b62127698@github.com> > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon 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 10 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8267670 - Merge remote-tracking branch 'origin/master' into JDK-8267670 - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Added missing brace - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Removed trailing whitespace - 8267670: Remove redundant code from switch - 8267670: Updated code to use yield - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Update java.io, java.math, and java.text to use switch expressions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4182/files - new: https://git.openjdk.java.net/jdk/pull/4182/files/933e59e9..44886603 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=07-08 Stats: 6066 lines in 412 files changed: 3749 ins; 1268 del; 1049 mod Patch: https://git.openjdk.java.net/jdk/pull/4182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4182/head:pull/4182 PR: https://git.openjdk.java.net/jdk/pull/4182 From weijun at openjdk.java.net Mon May 31 15:02:57 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 31 May 2021 15:02:57 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v6] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com> > 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: default behavior reverted to allow ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4073/files - new: https://git.openjdk.java.net/jdk/pull/4073/files/01dc4c0d..8fd09c39 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=04-05 Stats: 183 lines in 6 files changed: 127 ins; 23 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Mon May 31 15:09:27 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 31 May 2021 15:09:27 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v6] In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com> Message-ID: On Mon, 31 May 2021 15:02:57 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > default behavior reverted to allow New commit pushed. The default behavior is now reverted to be equivalent to `-Djava.security.manager=allow`. No warning will be shown when the system property is set to "allow", "disallow", or not set. A new test is added to check these warning messages. Some tests are updated to match the new behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From rriggs at openjdk.java.net Mon May 31 15:44:06 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 31 May 2021 15:44:06 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v13] In-Reply-To: References: Message-ID: > JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. > The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional > configuration mechanisms and filter utilities. > > javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: > http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html Roger Riggs 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 15 additional commits since the last revision: - Added protections to aid in auditing of filter and filter factory to ensure effective filtering and compatibility with previous releases. Fixed a bug in allow/rejectFilter() Cleanup of error stages and messages related setting filter factory with Config.setSerialFilterFactory. Updated tests to match. - Merge branch 'master' into 8264859-context-filter-factory - Merge branch 'master' into 8264859-context-filter-factory - Added test for rejectUndecidedClass array cases Added test for preventing disabling filter factory Test cleanup - Editorial updates to review comments. Simplify the builtin filter factory implementation. Add atomic update to setting the filter factory. Clarify the description of OIS.setObjectInputFilter. Cleanup of the example code. - Editorial updates Updated java.security properties to include jdk.serialFilterFactory Added test cases to SerialFilterFactoryTest for java.security properties and enabling of the SecurityManager with existing policy permission files Corrected a test that OIS.setObjectInputFilter could not be called twice. Removed a Factory test that was not intended to be committed - Moved utility filter methods to be static on ObjectInputFilter Rearranged the class javadoc of OIF to describe the parts of deserialization filtering, filters, composite filters, and the filter factory. And other review comment updates... - Refactored tests for utility functions to SerialFilterFunctionTest.java Deleted confused Config.allowMaxLimits() method Updated example to match move of methods to Config Added test of restriction on setting the filterfactory after a OIS has been created Additional Editorial updates - Move merge and rejectUndecidedClass methods to OIF.Config As default methods on OIF, their implementations were not concrete and not trustable - Review suggestions included; Added @implSpec for default methods in OIF; Added restriction that the filter factory cannot be set after an ObjectInputStream has been created and applied the current filter factory - ... and 5 more: https://git.openjdk.java.net/jdk/compare/1325f0b0...6d07298f ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3996/files - new: https://git.openjdk.java.net/jdk/pull/3996/files/0930f0f8..6d07298f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=11-12 Stats: 27002 lines in 388 files changed: 3591 ins; 22765 del; 646 mod Patch: https://git.openjdk.java.net/jdk/pull/3996.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3996/head:pull/3996 PR: https://git.openjdk.java.net/jdk/pull/3996 From dfuchs at openjdk.java.net Mon May 31 16:03:38 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 31 May 2021 16:03:38 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v13] In-Reply-To: References: Message-ID: <2rM_T6Rrcs4SrORNU8HPHUkFKXzJ9xFXkmIJ0KY2VyY=.e074418a-2c8f-4954-933f-94c8dddb220f@github.com> On Mon, 31 May 2021 15:44:06 GMT, Roger Riggs wrote: >> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. >> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional >> configuration mechanisms and filter utilities. >> >> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: >> http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html > > Roger Riggs 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 15 additional commits since the last revision: > > - Added protections to aid in auditing of filter and filter factory to > ensure effective filtering and compatibility with previous releases. > Fixed a bug in allow/rejectFilter() > Cleanup of error stages and messages related setting filter factory > with Config.setSerialFilterFactory. > Updated tests to match. > - Merge branch 'master' into 8264859-context-filter-factory > - Merge branch 'master' into 8264859-context-filter-factory > - Added test for rejectUndecidedClass array cases > Added test for preventing disabling filter factory > Test cleanup > - Editorial updates to review comments. > Simplify the builtin filter factory implementation. > Add atomic update to setting the filter factory. > Clarify the description of OIS.setObjectInputFilter. > Cleanup of the example code. > - Editorial updates > Updated java.security properties to include jdk.serialFilterFactory > Added test cases to SerialFilterFactoryTest for java.security properties and > enabling of the SecurityManager with existing policy permission files > Corrected a test that OIS.setObjectInputFilter could not be called twice. > Removed a Factory test that was not intended to be committed > - Moved utility filter methods to be static on ObjectInputFilter > Rearranged the class javadoc of OIF to describe the parts of > deserialization filtering, filters, composite filters, and the filter factory. > And other review comment updates... > - Refactored tests for utility functions to SerialFilterFunctionTest.java > Deleted confused Config.allowMaxLimits() method > Updated example to match move of methods to Config > Added test of restriction on setting the filterfactory after a OIS has been created > Additional Editorial updates > - Move merge and rejectUndecidedClass methods to OIF.Config > As default methods on OIF, their implementations were not concrete and not trustable > - Review suggestions included; > Added @implSpec for default methods in OIF; > Added restriction that the filter factory cannot be set after an ObjectInputStream has been created and applied the current filter factory > - ... and 5 more: https://git.openjdk.java.net/jdk/compare/c4cf067d...6d07298f Marked as reviewed by dfuchs (Reviewer). src/java.base/share/classes/java/io/ObjectInputFilter.java line 601: > 599: * @see Config#setSerialFilterFactory(BinaryOperator) > 600: */ > 601: private static final AtomicBoolean filterFactoryNoReplace = new AtomicBoolean(false); Nit: This could simply be `new AtomicBoolean()`; IIRC it saves a volatile write. ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From alanb at openjdk.java.net Mon May 31 16:13:21 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 31 May 2021 16:13:21 GMT Subject: RFR: 8267921: Remove redundant loop from sun.reflect.misc.ReflectUtil.privateCheckPackageAccess() In-Reply-To: References: Message-ID: <0FixTD58JWl7sQ9zfnwCxzJIMYGslWfn3mlweQ9B37I=.db3cd51b-b6d2-4f3d-a1af-8fb6fe32d433@github.com> 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 innermost component type. getPackageName went through a few iterations in JDK 9 and this is probably a left over. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4268 From lancea at openjdk.java.net Mon May 31 16:24:24 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 31 May 2021 16:24:24 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v6] In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com> Message-ID: <95Pzw60HuW83TYfd9Dogs6AdG0GDq0Ajh8McoTvRhJU=.37e0db8a-8670-408f-81cd-b5d30ea724ce@github.com> On Mon, 31 May 2021 15:02:57 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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > default behavior reverted to allow Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From mchung at openjdk.java.net Mon May 31 16:56:24 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 31 May 2021 16:56:24 GMT Subject: RFR: 8267921: Remove redundant loop from sun.reflect.misc.ReflectUtil.privateCheckPackageAccess() In-Reply-To: References: Message-ID: 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 innermost component type. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4268 From github.com+10835776+stsypanov at openjdk.java.net Mon May 31 17:02:26 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 31 May 2021 17:02:26 GMT Subject: Integrated: 8267921: Remove redundant loop from sun.reflect.misc.ReflectUtil.privateCheckPackageAccess() In-Reply-To: References: Message-ID: 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 innermost component type. This pull request has now been integrated. Changeset: c06db45f Author: Sergey Tsypanov Committer: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/c06db45fa77c8a90518d6ff023de6c46b7c89997 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod 8267921: Remove redundant loop from sun.reflect.misc.ReflectUtil.privateCheckPackageAccess() Reviewed-by: alanb, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/4268 From plevart at openjdk.java.net Mon May 31 17:56:26 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 31 May 2021 17:56:26 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code In-Reply-To: <77371781-b7f8-f2b0-8299-f56f485fd222@oracle.com> References: <77371781-b7f8-f2b0-8299-f56f485fd222@oracle.com> Message-ID: On Mon, 31 May 2021 12:37:55 GMT, David Holmes wrote: > > Hi Jaroslav, > > If you change `@JavaScriptBody` retention to `RUNTIME`, you don't need to re-compile any code that uses this annotation. You just have to use `-XX:+PreserveAllAnnotations` to expose all anotations to JVM and consequently to AnnotationParser. The parser will then return just the `RUNTIME` retention-marked annotations. This means you just have to run the app with the version of the JavaScriptBody.class that is retention-marked as `RUNTIME`... > > I think that `-XX:+PreserveAllAnnotations` was meant as a migration aid for exactly the case when some annotations migrate from `CLASS` to `RUNTIME` retention and libraries using such annotations are not re-compiled yet. > > That reads backwards to me. +PreserveAllAnnotations means that CLASS > retention annotations are retained by the VM not just RUNTIME ones. So > in that sense it might be a migration aid if moving from RUNTIME to > CLASS, not CLASS to RUNTIME. > > David Why? If an annotation has a CLASS retention when some source that uses it is compiled, such annotation usage is compiled into the `RuntimeInvisibleAnnotations` attribute of the class that corresponds to the source that uses the annotation. So when later the annotation is migrated to have RUNTIME retention, the AnnotationParser would return such annotation if only its encoded bytestream has been given to it. But since it is present in the `RuntimeInvisibleAnnotations` attribute of the class that uses such annotation, by default it is not (only `RuntimeVisibleAnnotations` attribute annotations are passed to AnnotationParser). Unless you give JVM the `-XX:+PreserveAllAnnotations` option to also preserve (in its internal structures) all annotations (from `RuntimeVisibleAnnotations` and `RuntimeInvisibleAnnotations` attributes). So in that case, the AnnotationParser has a chance to parse such "migrated" annotation for which the usages have not been recompiled yet. When such usages get re compiled, such annotation uses will get compiled into `RuntimeVisibleAnnotations` attribute(s) of classes that use the annotation and the option will not be needed any more... This is how I understand the JVM option. I might be wrong. ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From plevart at openjdk.java.net Mon May 31 18:20:22 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 31 May 2021 18:20:22 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code In-Reply-To: <77371781-b7f8-f2b0-8299-f56f485fd222@oracle.com> References: <77371781-b7f8-f2b0-8299-f56f485fd222@oracle.com> Message-ID: On Mon, 31 May 2021 12:37:55 GMT, David Holmes wrote: > That reads backwards to me. +PreserveAllAnnotations means that CLASS > retention annotations are retained by the VM not just RUNTIME ones. So > in that sense it might be a migration aid if moving from RUNTIME to > CLASS, not CLASS to RUNTIME. > > David Ah, I know why you think that way. You think that when an annotation is migrated from RUNTIME to CLASS retention, that some users would still want to "see" it via reflection (at runtime)... No, I don't think this was the intention of the JVM option. Migrating from RUNTIME to CLASS retention means that the ways of looking up such annotation are shrinking. Such change to the annotation should only be attempted when there are no more runtime lookups to support. So 1st deprecation of RUNTIME retention on the annotation should be published, followed by change to CLASS retention. OTOH when CLASS retention is changing to RUNTIME, such as in this case, the ways of looking up are widening (there is some new desire to lookup the annotation at runtime via reflection). To facilitate that, the annotation maintainer changes the retention to RUNTIME. But unfortunately, old uses of the annotation are baked in the ` RuntimeInvisibleAnnotations` attributes of the classes that were compiled with the old version of the annotation when the retention was still CLASS. Until all such classes are recompiled, the JVM option can be used to make such annotation usages visible at runtime. That makes more sense to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From iris at openjdk.java.net Mon May 31 18:50:32 2021 From: iris at openjdk.java.net (Iris Clark) Date: Mon, 31 May 2021 18:50:32 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v9] In-Reply-To: <9qJLk6We2yEGQiMS0y-A8ggivVfCwcwrD7YP3IVC7qw=.017684f1-3e5f-4ae9-ba1e-c13b62127698@github.com> References: <9qJLk6We2yEGQiMS0y-A8ggivVfCwcwrD7YP3IVC7qw=.017684f1-3e5f-4ae9-ba1e-c13b62127698@github.com> Message-ID: On Mon, 31 May 2021 14:10:50 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon 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 10 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Added missing brace > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Removed trailing whitespace > - 8267670: Remove redundant code from switch > - 8267670: Updated code to use yield > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Update java.io, java.math, and java.text to use switch expressions Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From vkempik at openjdk.java.net Mon May 31 20:27:26 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 31 May 2021 20:27:26 GMT Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS In-Reply-To: References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: On Sun, 30 May 2021 03:00:56 GMT, David Holmes wrote: >> ?d on macOS >> >> This patch simply round up the specified stack size to multiple of the system page size. >> >> Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output. >> >> ```code:java >> public class StackLeak { >> public int depth = 0; >> public void stackLeak() { >> depth++; >> stackLeak(); >> } >> >> public static void main(String[] args) { >> var test = new StackLeak(); >> try { >> test.stackLeak(); >> } catch (Throwable e) { >> System.out.println(test.depth); >> } >> } >> } > > src/java.base/macosx/native/libjli/java_md_macosx.m line 727: > >> 725: >> 726: static size_t alignUp(size_t stack_size) { >> 727: long page_size = sysconf(_SC_PAGESIZE); > > In hotspot we use `getpagesize()`. There is also a guard for a very large stack (within a page of SIZE_MAX) so that rounding up does not produce zero. sounds like that (getpagesize) should work with m1 mac as well, as they have 16k pages. will it ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4256 From david.holmes at oracle.com Mon May 31 22:35:04 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Jun 2021 08:35:04 +1000 Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code In-Reply-To: References: <77371781-b7f8-f2b0-8299-f56f485fd222@oracle.com> Message-ID: On 1/06/2021 4:20 am, Peter Levart wrote: > On Mon, 31 May 2021 12:37:55 GMT, David Holmes wrote: > >> That reads backwards to me. +PreserveAllAnnotations means that CLASS >> retention annotations are retained by the VM not just RUNTIME ones. So >> in that sense it might be a migration aid if moving from RUNTIME to >> CLASS, not CLASS to RUNTIME. >> >> David > > Ah, I know why you think that way. You think that when an annotation is migrated from RUNTIME to CLASS retention, that some users would still want to "see" it via reflection (at runtime)... Yes. > No, I don't think this was the intention of the JVM option. Migrating from RUNTIME to CLASS retention means that the ways of looking up such annotation are shrinking. Such change to the annotation should only be attempted when there are no more runtime lookups to support. So 1st deprecation of RUNTIME retention on the annotation should be published, followed by change to CLASS retention. > > OTOH when CLASS retention is changing to RUNTIME, such as in this case, the ways of looking up are widening (there is some new desire to lookup the annotation at runtime via reflection). To facilitate that, the annotation maintainer changes the retention to RUNTIME. But unfortunately, old uses of the annotation are baked in the ` RuntimeInvisibleAnnotations` attributes of the classes that were compiled with the old version of the annotation when the retention was still CLASS. Until all such classes are recompiled, the JVM option can be used to make such annotation usages visible at runtime. That makes more sense to me. That sounds like the code that wants to inspect the annotations is using knowledge that the target classes have been updated (in terms of the source change from CLASS to RUNTIME) but it only has access to old binaries. That scenario doesn't really make sense to me. In any case the operation of the flag is very simple and has no bearing on how AnnotationParser works. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4245 > From plevart at openjdk.java.net Mon May 31 23:55:20 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 31 May 2021 23:55:20 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code In-Reply-To: References: Message-ID: On Mon, 31 May 2021 22:36:52 GMT, David Holmes wrote: > > OTOH when CLASS retention is changing to RUNTIME, such as in this case, the ways of looking up are widening (there is some new desire to lookup the annotation at runtime via reflection). To facilitate that, the annotation maintainer changes the retention to RUNTIME. But unfortunately, old uses of the annotation are baked in the ` RuntimeInvisibleAnnotations` attributes of the classes that were compiled with the old version of the annotation when the retention was still CLASS. Until all such classes are recompiled, the JVM option can be used to make such annotation usages visible at runtime. That makes more sense to me. > > That sounds like the code that wants to inspect the annotations is using > knowledge that the target classes have been updated (in terms of the > source change from CLASS to RUNTIME) but it only has access to old > binaries. That scenario doesn't really make sense to me. The code that wants to inspect the annotation knows that the annotation itself has been updated from CLASS to RUNTIME retention and is running with the new version of annotation on classpath. But the uses of that annotation are in other code - neither in the code that wants to inspect the annotation nor in the code that represents the annotation declaration and holds the @Retention meta-annotation use. The code that uses the annotation is the code that has been compiled before the annotation has been updated and therefore keeps annotation uses in the `RuntimeInvisibleAnnotations` attributes of class files representing that code. To be more concrete, let's illustrate with the example: // annotation_v1.jar @Retention(CLASS) public @interface Ann {} // use.jar (compiled with annotation_v1.jar on classpath, // so Use.class encodes the @Ann use in the `RuntimeInvisibleAnnotations` attribute) @Ann public class Use {} // annotation_v2.jar (the new version of annotation that migrated to RUNTIME retention) @Retention(RUNTIME) public @interface Ann {} // main.jar (running with: -cp use.jar:annotation_v2.jar:main.jar -XX:+PreserveAllAnnotations) public class Main { public static void main(String[] a) { Ann ann = Use.class.getAnnotation(Ann.class); ... } } > > In any case the operation of the flag is very simple and has no bearing > on how AnnotationParser works. Exactly. It does affect which encoded annotation data is passed to AnnotationParser though. Either just `RuntimeVisibleAnnotations` or both `RuntimeVisibleAnnotations` and `RuntimeInvisibleAnnotations`. In any case the parser filters out annotations that don't have the RUNTIME retention in their declaration. > > Cheers, > David Regards, Peter ------------- PR: https://git.openjdk.java.net/jdk/pull/4245