From attila at openjdk.java.net  Sat Jan  2 15:09:09 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Sat, 2 Jan 2021 15:09:09 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type converters
Message-ID: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>

_(NB: For this leak to occur, an application needs to be either creating and discarding linkers frequently, or creating and discarding class loaders frequently while creating Dynalink type converters for classes in them. Neither is typical usage, although they can occur in dynamic code loading environments such as OSGi.)_

I'll explain this one in a bit more detail. Dynalink's creates and caches method handles for language-specific conversions between types. Each conversion is thus characterized by a `Class` object representing the type converted from, and a `Class` object representing the type converted to, thus they're keyed by a pair of `(Class, Class)`. Java API provides the excellent `ClassValue` class for associating values with a single class, but it lacks the ? admittedly more niche ? facility for associating a value with a pair of classes. I originally solved this problem using something that looks like a `ClassValue<Map<Class<?>, T>>`. I say "looks like" because Dynalink has a specialized `ClassMap` class that works like `Map<Class<?>, T>` but it also goes to some pains to _not_ establish strong references from a class loader to either its children or to unrelated class loaders, for obvious reasons.

Surprisingly, the problem didn't lie in there, though. The problem was in the fact that `TypeConverterFactory` used `ClassValue` objects that were its non-static anonymous inner classes, and further the values they computed were also of non-static anonymous inner classes. Due to the way `ClassValue` internals work, this led to the `TypeConverterFactory` objects becoming anchored in a GC root of `Class.classValueMap` through the synthetic `this$0` reference chains in said inner classes? talk about non-obvious memory leaks. (I guess there's a lesson in there about not using `ClassValue` as an instance field, but there's a genuine need for them here, so?)

? so the first thing I did was I deconstructed all those anonymous inner classes into named static inner classes, and ended up with something that _did_ fix the memory leak (yay!) but at the same time there was a bunch of copying of constructor parameters from outer classes into the inner classes, the whole thing was very clunky with scary amounts of boilerplate. I felt there must exist a better solution.

And it exists! I ended up replacing the `ClassValue<ClassMap<T>>` construct with a ground-up implementation of `BiClassValue<T>`, representation of lazily computed values associated with a pair of types. This was the right abstraction the `TypeConverterFactory` code needed all along. `BiClassValue<T>` is also not implemented as an abstract class but rather it is a final class and takes a `BiFunction<Class<?>, Class<?>, T>` for computation of its values, thus there's never a risk of making it an instance-specific inner class (well, you still need to be careful with the bifunction lambda?) It also has an even better solution for avoiding strong references to child class loaders.

And that's why I'm not submitting here the smallest possible point fix to the memory leak, but rather a slightly larger one that architecturally fixes it the right way.

There are two test classes, they test subtly different scenarios. `TypeConverterFactoryMemoryLeakTest` tests that when a `TypeConverterFactory` instance becomes unreachable, all method handles it created also become eligible for collection. `TypeConverterFactoryRetentionTests` on the other hand test that the factory itself won't prevent class loaders from being collected by virtue of creating converters for them.

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

Commit messages:
 - Create the right abstraction, BiClassValue and retire ClassMap.
 - Create a test

Changes: https://git.openjdk.java.net/jdk/pull/1918/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1918&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8198540
  Stats: 746 lines in 5 files changed: 512 ins; 220 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1918.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1918/head:pull/1918

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

From github.com+652983+dasbrain at openjdk.java.net  Sat Jan  2 16:24:56 2021
From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn)
Date: Sat, 2 Jan 2021 16:24:56 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters
In-Reply-To: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
Message-ID: <CpazimBsgEg03UKHE1p2JfollTOcpzrD8qnw8sCeALs=.1ea18769-9815-49a9-9229-49a8c1af7d18@github.com>

On Sat, 2 Jan 2021 14:45:51 GMT, Attila Szegedi <attila at openjdk.org> wrote:

> _(NB: For this leak to occur, an application needs to be either creating and discarding linkers frequently, or creating and discarding class loaders frequently while creating Dynalink type converters for classes in them. Neither is typical usage, although they can occur in dynamic code loading environments such as OSGi.)_
> 
> I'll explain this one in a bit more detail. Dynalink's creates and caches method handles for language-specific conversions between types. Each conversion is thus characterized by a `Class` object representing the type converted from, and a `Class` object representing the type converted to, thus they're keyed by a pair of `(Class, Class)`. Java API provides the excellent `ClassValue` class for associating values with a single class, but it lacks the ? admittedly more niche ? facility for associating a value with a pair of classes. I originally solved this problem using something that looks like a `ClassValue<Map<Class<?>, T>>`. I say "looks like" because Dynalink has a specialized `ClassMap` class that works like `Map<Class<?>, T>` but it also goes to some pains to _not_ establish strong references from a class loader to either its children or to unrelated class loaders, for obvious reasons.
> 
> Surprisingly, the problem didn't lie in there, though. The problem was in the fact that `TypeConverterFactory` used `ClassValue` objects that were its non-static anonymous inner classes, and further the values they computed were also of non-static anonymous inner classes. Due to the way `ClassValue` internals work, this led to the `TypeConverterFactory` objects becoming anchored in a GC root of `Class.classValueMap` through the synthetic `this$0` reference chains in said inner classes? talk about non-obvious memory leaks. (I guess there's a lesson in there about not using `ClassValue` as an instance field, but there's a genuine need for them here, so?)
> 
> ? so the first thing I did was I deconstructed all those anonymous inner classes into named static inner classes, and ended up with something that _did_ fix the memory leak (yay!) but at the same time there was a bunch of copying of constructor parameters from outer classes into the inner classes, the whole thing was very clunky with scary amounts of boilerplate. I felt there must exist a better solution.
> 
> And it exists! I ended up replacing the `ClassValue<ClassMap<T>>` construct with a ground-up implementation of `BiClassValue<T>`, representation of lazily computed values associated with a pair of types. This was the right abstraction the `TypeConverterFactory` code needed all along. `BiClassValue<T>` is also not implemented as an abstract class but rather it is a final class and takes a `BiFunction<Class<?>, Class<?>, T>` for computation of its values, thus there's never a risk of making it an instance-specific inner class (well, you still need to be careful with the bifunction lambda?) It also has an even better solution for avoiding strong references to child class loaders.
> 
> And that's why I'm not submitting here the smallest possible point fix to the memory leak, but rather a slightly larger one that architecturally fixes it the right way.
> 
> There are two test classes, they test subtly different scenarios. `TypeConverterFactoryMemoryLeakTest` tests that when a `TypeConverterFactory` instance becomes unreachable, all method handles it created also become eligible for collection. `TypeConverterFactoryRetentionTests` on the other hand test that the factory itself won't prevent class loaders from being collected by virtue of creating converters for them.

test/jdk/jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java line 69:

> 67:         public GuardedInvocation convertToType(Class<?> sourceType, Class<?> targetType, Supplier<MethodHandles.Lookup> lookupSupplier) {
> 68:             // Never meant to be invoked, just a dummy MH that conforms to the expected type.
> 69:             MethodHandle result = MethodHandles.constant(Object.class, null).asType(MethodType.methodType(targetType));

Suggestion:

            MethodHandle result = MethodHandles.zero(targetType);

test/jdk/jdk/dynalink/TypeConverterFactoryRetentionTests.java line 64:

> 62:         public GuardedInvocation convertToType(Class<?> sourceType, Class<?> targetType, Supplier<MethodHandles.Lookup> lookupSupplier) {
> 63:             // Never meant to be invoked, just a dummy MH that conforms to the expected type.
> 64:             MethodHandle result = MethodHandles.constant(Object.class, null).asType(MethodType.methodType(targetType));

Suggestion:

            MethodHandle result = MethodHandles.zero(targetType);

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

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

From github.com+652983+dasbrain at openjdk.java.net  Sat Jan  2 16:30:57 2021
From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn)
Date: Sat, 2 Jan 2021 16:30:57 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters
In-Reply-To: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
Message-ID: <zoH9LkGyKKA32SjXotq71dKDFs1-wYLiboY4yvKZwmk=.21ed959b-7e39-42fb-baf1-6d8e856326d5@github.com>

On Sat, 2 Jan 2021 14:45:51 GMT, Attila Szegedi <attila at openjdk.org> wrote:

> _(NB: For this leak to occur, an application needs to be either creating and discarding linkers frequently, or creating and discarding class loaders frequently while creating Dynalink type converters for classes in them. Neither is typical usage, although they can occur in dynamic code loading environments such as OSGi.)_
> 
> I'll explain this one in a bit more detail. Dynalink's creates and caches method handles for language-specific conversions between types. Each conversion is thus characterized by a `Class` object representing the type converted from, and a `Class` object representing the type converted to, thus they're keyed by a pair of `(Class, Class)`. Java API provides the excellent `ClassValue` class for associating values with a single class, but it lacks the ? admittedly more niche ? facility for associating a value with a pair of classes. I originally solved this problem using something that looks like a `ClassValue<Map<Class<?>, T>>`. I say "looks like" because Dynalink has a specialized `ClassMap` class that works like `Map<Class<?>, T>` but it also goes to some pains to _not_ establish strong references from a class loader to either its children or to unrelated class loaders, for obvious reasons.
> 
> Surprisingly, the problem didn't lie in there, though. The problem was in the fact that `TypeConverterFactory` used `ClassValue` objects that were its non-static anonymous inner classes, and further the values they computed were also of non-static anonymous inner classes. Due to the way `ClassValue` internals work, this led to the `TypeConverterFactory` objects becoming anchored in a GC root of `Class.classValueMap` through the synthetic `this$0` reference chains in said inner classes? talk about non-obvious memory leaks. (I guess there's a lesson in there about not using `ClassValue` as an instance field, but there's a genuine need for them here, so?)
> 
> ? so the first thing I did was I deconstructed all those anonymous inner classes into named static inner classes, and ended up with something that _did_ fix the memory leak (yay!) but at the same time there was a bunch of copying of constructor parameters from outer classes into the inner classes, the whole thing was very clunky with scary amounts of boilerplate. I felt there must exist a better solution.
> 
> And it exists! I ended up replacing the `ClassValue<ClassMap<T>>` construct with a ground-up implementation of `BiClassValue<T>`, representation of lazily computed values associated with a pair of types. This was the right abstraction the `TypeConverterFactory` code needed all along. `BiClassValue<T>` is also not implemented as an abstract class but rather it is a final class and takes a `BiFunction<Class<?>, Class<?>, T>` for computation of its values, thus there's never a risk of making it an instance-specific inner class (well, you still need to be careful with the bifunction lambda?) It also has an even better solution for avoiding strong references to child class loaders.
> 
> And that's why I'm not submitting here the smallest possible point fix to the memory leak, but rather a slightly larger one that architecturally fixes it the right way.
> 
> There are two test classes, they test subtly different scenarios. `TypeConverterFactoryMemoryLeakTest` tests that when a `TypeConverterFactory` instance becomes unreachable, all method handles it created also become eligible for collection. `TypeConverterFactoryRetentionTests` on the other hand test that the factory itself won't prevent class loaders from being collected by virtue of creating converters for them.

Just a small suggestion using `MethodHandles.empty` instead of `MethodHandles.constant().asType().dropArguments()`.

test/jdk/jdk/dynalink/TypeConverterFactoryRetentionTests.java line 65:

> 63:             // Never meant to be invoked, just a dummy MH that conforms to the expected type.
> 64:             MethodHandle result = MethodHandles.constant(Object.class, null).asType(MethodType.methodType(targetType));
> 65:             result = MethodHandles.dropArguments(result, 0, sourceType);

Suggestion:

            MethodHandle result = MethodHandles.empty(MethodType.methodType(targetType, sourceType));

test/jdk/jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java line 70:

> 68:             // Never meant to be invoked, just a dummy MH that conforms to the expected type.
> 69:             MethodHandle result = MethodHandles.constant(Object.class, null).asType(MethodType.methodType(targetType));
> 70:             result = MethodHandles.dropArguments(result, 0, sourceType);

Suggestion:

            MethodHandle result = MethodHandles.empty(MethodType.methodType(targetType, sourceType));

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

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

From attila at openjdk.java.net  Sat Jan  2 18:39:17 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Sat, 2 Jan 2021 18:39:17 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v2]
In-Reply-To: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
Message-ID: <o0cyq2PT6QBh9597Gb24GYnAccPb-r-aO9rcugNb5fM=.acb0037d-ffdb-4b2f-8649-a27a7bbf65b0@github.com>

> _(NB: For this leak to occur, an application needs to be either creating and discarding linkers frequently, or creating and discarding class loaders frequently while creating Dynalink type converters for classes in them. Neither is typical usage, although they can occur in dynamic code loading environments such as OSGi.)_
> 
> I'll explain this one in a bit more detail. Dynalink's creates and caches method handles for language-specific conversions between types. Each conversion is thus characterized by a `Class` object representing the type converted from, and a `Class` object representing the type converted to, thus they're keyed by a pair of `(Class, Class)`. Java API provides the excellent `ClassValue` class for associating values with a single class, but it lacks the ? admittedly more niche ? facility for associating a value with a pair of classes. I originally solved this problem using something that looks like a `ClassValue<Map<Class<?>, T>>`. I say "looks like" because Dynalink has a specialized `ClassMap` class that works like `Map<Class<?>, T>` but it also goes to some pains to _not_ establish strong references from a class loader to either its children or to unrelated class loaders, for obvious reasons.
> 
> Surprisingly, the problem didn't lie in there, though. The problem was in the fact that `TypeConverterFactory` used `ClassValue` objects that were its non-static anonymous inner classes, and further the values they computed were also of non-static anonymous inner classes. Due to the way `ClassValue` internals work, this led to the `TypeConverterFactory` objects becoming anchored in a GC root of `Class.classValueMap` through the synthetic `this$0` reference chains in said inner classes? talk about non-obvious memory leaks. (I guess there's a lesson in there about not using `ClassValue` as an instance field, but there's a genuine need for them here, so?)
> 
> ? so the first thing I did was I deconstructed all those anonymous inner classes into named static inner classes, and ended up with something that _did_ fix the memory leak (yay!) but at the same time there was a bunch of copying of constructor parameters from outer classes into the inner classes, the whole thing was very clunky with scary amounts of boilerplate. I felt there must exist a better solution.
> 
> And it exists! I ended up replacing the `ClassValue<ClassMap<T>>` construct with a ground-up implementation of `BiClassValue<T>`, representation of lazily computed values associated with a pair of types. This was the right abstraction the `TypeConverterFactory` code needed all along. `BiClassValue<T>` is also not implemented as an abstract class but rather it is a final class and takes a `BiFunction<Class<?>, Class<?>, T>` for computation of its values, thus there's never a risk of making it an instance-specific inner class (well, you still need to be careful with the bifunction lambda?) It also has an even better solution for avoiding strong references to child class loaders.
> 
> And that's why I'm not submitting here the smallest possible point fix to the memory leak, but rather a slightly larger one that architecturally fixes it the right way.
> 
> There are two test classes, they test subtly different scenarios. `TypeConverterFactoryMemoryLeakTest` tests that when a `TypeConverterFactory` instance becomes unreachable, all method handles it created also become eligible for collection. `TypeConverterFactoryRetentionTests` on the other hand test that the factory itself won't prevent class loaders from being collected by virtue of creating converters for them.

Attila Szegedi has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Johannes Kuhn <DasBrain at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1918/files
  - new: https://git.openjdk.java.net/jdk/pull/1918/files/24d37872..3f3efed2

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

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

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

From attila at openjdk.java.net  Sat Jan  2 18:44:16 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Sat, 2 Jan 2021 18:44:16 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v3]
In-Reply-To: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
Message-ID: <CinMgBqJ8whkZu3yDh5vyBAfMl9SSEcJl4cON3D1Idk=.8afd0106-af52-4679-be11-dd77edf0a0a8@github.com>

> _(NB: For this leak to occur, an application needs to be either creating and discarding linkers frequently, or creating and discarding class loaders frequently while creating Dynalink type converters for classes in them. Neither is typical usage, although they can occur in dynamic code loading environments such as OSGi.)_
> 
> I'll explain this one in a bit more detail. Dynalink's creates and caches method handles for language-specific conversions between types. Each conversion is thus characterized by a `Class` object representing the type converted from, and a `Class` object representing the type converted to, thus they're keyed by a pair of `(Class, Class)`. Java API provides the excellent `ClassValue` class for associating values with a single class, but it lacks the ? admittedly more niche ? facility for associating a value with a pair of classes. I originally solved this problem using something that looks like a `ClassValue<Map<Class<?>, T>>`. I say "looks like" because Dynalink has a specialized `ClassMap` class that works like `Map<Class<?>, T>` but it also goes to some pains to _not_ establish strong references from a class loader to either its children or to unrelated class loaders, for obvious reasons.
> 
> Surprisingly, the problem didn't lie in there, though. The problem was in the fact that `TypeConverterFactory` used `ClassValue` objects that were its non-static anonymous inner classes, and further the values they computed were also of non-static anonymous inner classes. Due to the way `ClassValue` internals work, this led to the `TypeConverterFactory` objects becoming anchored in a GC root of `Class.classValueMap` through the synthetic `this$0` reference chains in said inner classes? talk about non-obvious memory leaks. (I guess there's a lesson in there about not using `ClassValue` as an instance field, but there's a genuine need for them here, so?)
> 
> ? so the first thing I did was I deconstructed all those anonymous inner classes into named static inner classes, and ended up with something that _did_ fix the memory leak (yay!) but at the same time there was a bunch of copying of constructor parameters from outer classes into the inner classes, the whole thing was very clunky with scary amounts of boilerplate. I felt there must exist a better solution.
> 
> And it exists! I ended up replacing the `ClassValue<ClassMap<T>>` construct with a ground-up implementation of `BiClassValue<T>`, representation of lazily computed values associated with a pair of types. This was the right abstraction the `TypeConverterFactory` code needed all along. `BiClassValue<T>` is also not implemented as an abstract class but rather it is a final class and takes a `BiFunction<Class<?>, Class<?>, T>` for computation of its values, thus there's never a risk of making it an instance-specific inner class (well, you still need to be careful with the bifunction lambda?) It also has an even better solution for avoiding strong references to child class loaders.
> 
> And that's why I'm not submitting here the smallest possible point fix to the memory leak, but rather a slightly larger one that architecturally fixes it the right way.
> 
> There are two test classes, they test subtly different scenarios. `TypeConverterFactoryMemoryLeakTest` tests that when a `TypeConverterFactory` instance becomes unreachable, all method handles it created also become eligible for collection. `TypeConverterFactoryRetentionTests` on the other hand test that the factory itself won't prevent class loaders from being collected by virtue of creating converters for them.

Attila Szegedi has updated the pull request incrementally with one additional commit since the last revision:

  jtreg runs with assertions on, so using the assert keyword is sufficient

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1918/files
  - new: https://git.openjdk.java.net/jdk/pull/1918/files/3f3efed2..eaddc17b

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

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

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

From shade at openjdk.java.net  Mon Jan  4 09:55:56 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 4 Jan 2021 09:55:56 GMT
Subject: RFR: 8259021 avoid double racy reads from non-volatile fields of
 SharedSecrets
In-Reply-To: <VkaRcc6Rsal_pvBfNP-rtC-VWd8MJ9eH7PHlkW0pSj4=.20a3f97b-f1be-422f-adc6-854ce9cf1519@github.com>
References: <VkaRcc6Rsal_pvBfNP-rtC-VWd8MJ9eH7PHlkW0pSj4=.20a3f97b-f1be-422f-adc6-854ce9cf1519@github.com>
Message-ID: <UTAaG6qQKAhdpkeAQRYZtvNQwlsGooJ-WuIr0jgwX-w=.4de9a565-1f67-4a75-aaee-a63d41397764@github.com>

On Thu, 31 Dec 2020 10:02:01 GMT, Peter Levart <plevart at openjdk.org> wrote:

> See: https://bugs.openjdk.java.net/browse/JDK-8259021
> See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html

Looks good, but can we not do the behavioral change in `ensureClassInitialized`? There are methods like this in JDK, which could probably be changed wholesale?

src/java.base/share/classes/jdk/internal/access/SharedSecrets.java line 419:

> 417:         } catch (IllegalAccessException e) {
> 418:             throw new InternalError(e);
> 419:         }

This is a potential behavioral change that has little to do with the issue at hand, right?

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

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

From plevart at openjdk.java.net  Mon Jan  4 13:34:56 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Mon, 4 Jan 2021 13:34:56 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v3]
In-Reply-To: <zoH9LkGyKKA32SjXotq71dKDFs1-wYLiboY4yvKZwmk=.21ed959b-7e39-42fb-baf1-6d8e856326d5@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
 <zoH9LkGyKKA32SjXotq71dKDFs1-wYLiboY4yvKZwmk=.21ed959b-7e39-42fb-baf1-6d8e856326d5@github.com>
Message-ID: <lTmAigU7IJZfXkwns9PuXCtgPvowhr2cY26dalEDRG4=.ff495634-8d11-42ac-84ad-9185f676c958@github.com>

On Sat, 2 Jan 2021 16:28:19 GMT, Johannes Kuhn <github.com+652983+DasBrain at openjdk.org> wrote:

>> Attila Szegedi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   jtreg runs with assertions on, so using the assert keyword is sufficient
>
> Just a small suggestion using `MethodHandles.empty` instead of `MethodHandles.constant().asType().dropArguments()`.

Hi Attila,

This looks good.

If I understand correctly, your `BiClassValue` is a holder for a `BiFunction` and a `BiClassValueRoot` which is a `ClassValue<BiClassValues>`. The `BiClassValues` contains two lazily constructed Map(s): `forward` and `reverse`. You then employ a logic where you either use the `forward` map obtained from c1 if c1.classLoader sees c2.classLoader or `backward` map obtained from c2 if c2.classLoader sees c1.classLoader or you don't employ caching if c1.classLoader and c2.classLoader are unrelated.
The need for two Maps is probably because the two Class components of the "bi-key" are ordered, right? So `BiClassValue bcv = ...;` `bcv.get(c1, c2)` is not the same as `bcv.get(c2, c1)` ....
Alternatively you could have a `BiClassValue` with two embedded `ClassValue`(s):

final CVRoot<T> forward = new CVRoot<>();
final CVRoot<T> reverse = new CVRoor<>();

static class CVRoot<T> extends ClassValue<CHMCL<T>> {
  public CHMCL<T> get(Class<?> clazz) { return new CHMCL<>(getClassLoader(clazz)); }
}

static class CHMCL<T> extends ConcurrentHashMap<Class<?>, T> {
  final ClassLoader classLoader;
  CHMCL(ClassLoader cl) { classLoader = cl; }
}

...with that you could get rid of the intermediary BiClassValues object. It would be replaced with a ConcurrentHashMap subclass that would contain a field to hold the cached ClassLoader of the c1/c2. One de-reference less...

As for the main logic, it would be similar to what you have now. Or it could be different. I wonder what is the performance of canReferenceDirectly(). If you used SharedSecrets to obtain a ClassLoader of a Class without security checks (and thus overhead), you could perhaps evaluate the canReferenceDirectly() before lookups so you would not needlessly trigger initialization of ClassValue(s) that don't need to get initialized. 

WDYT?

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

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

From jlaskey at openjdk.java.net  Mon Jan  4 13:56:58 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 4 Jan 2021 13:56:58 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <8dxwtqYBhApNqL8YPdxd7DD2vSCh4l7Uty-yC5GQL1k=.c46a32df-87db-4bdb-a741-3a576061fbb8@github.com>

On Wed, 18 Nov 2020 13:45:12 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Stayin' alive

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

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

From plevart at openjdk.java.net  Mon Jan  4 14:27:09 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Mon, 4 Jan 2021 14:27:09 GMT
Subject: RFR: 8259021 avoid double racy reads from non-volatile fields of
 SharedSecrets [v2]
In-Reply-To: <VkaRcc6Rsal_pvBfNP-rtC-VWd8MJ9eH7PHlkW0pSj4=.20a3f97b-f1be-422f-adc6-854ce9cf1519@github.com>
References: <VkaRcc6Rsal_pvBfNP-rtC-VWd8MJ9eH7PHlkW0pSj4=.20a3f97b-f1be-422f-adc6-854ce9cf1519@github.com>
Message-ID: <ruJqHXUZ-yUCc1xFU0t3x9WMQC_L-or1K6x-PRhKGIM=.270c39c0-9d06-4314-9281-ead4c2e1a940@github.com>

> See: https://bugs.openjdk.java.net/browse/JDK-8259021
> See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html

Peter Levart has updated the pull request incrementally with one additional commit since the last revision:

  revert the unrelated change

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1914/files
  - new: https://git.openjdk.java.net/jdk/pull/1914/files/d3b4c98f..dd1447a0

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

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

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

From redestad at openjdk.java.net  Mon Jan  4 14:52:58 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 4 Jan 2021 14:52:58 GMT
Subject: RFR: 8259021 avoid double racy reads from non-volatile fields of
 SharedSecrets [v2]
In-Reply-To: <ruJqHXUZ-yUCc1xFU0t3x9WMQC_L-or1K6x-PRhKGIM=.270c39c0-9d06-4314-9281-ead4c2e1a940@github.com>
References: <VkaRcc6Rsal_pvBfNP-rtC-VWd8MJ9eH7PHlkW0pSj4=.20a3f97b-f1be-422f-adc6-854ce9cf1519@github.com>
 <ruJqHXUZ-yUCc1xFU0t3x9WMQC_L-or1K6x-PRhKGIM=.270c39c0-9d06-4314-9281-ead4c2e1a940@github.com>
Message-ID: <6GjMahjRqJn3D0nUUnhfxSN3uGggEv5OS_gb7ywaXEo=.38bb3b20-a182-4437-a68d-2d7c04a5f63d@github.com>

On Mon, 4 Jan 2021 14:27:09 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> See: https://bugs.openjdk.java.net/browse/JDK-8259021
>> See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html
>
> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert the unrelated change

Marked as reviewed by redestad (Reviewer).

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

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

From herrick at openjdk.java.net  Mon Jan  4 15:12:12 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 4 Jan 2021 15:12:12 GMT
Subject: RFR: JDK-8223322: Improve concurrency in jpackage instances [v2]
In-Reply-To: <kLf7uN9jJH7HeAAsR7egERJdwg85lP_N6SwYrBhnM9w=.3cd2410b-40d0-4a4b-a004-f9ab5931519a@github.com>
References: <kLf7uN9jJH7HeAAsR7egERJdwg85lP_N6SwYrBhnM9w=.3cd2410b-40d0-4a4b-a004-f9ab5931519a@github.com>
Message-ID: <KJoHMSv2VI6wRcS3YzIull_QR7tqq8tKAt6213gh-nE=.a25012b9-392c-43dd-a4ec-9dbfbac99bb0@github.com>

> Remove all non final static variables in jpackage java code (using InheritableThreadLocal for Logger and Argument instances) and remove sychronization in JPackageToolProvider.

Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8223322: Improve concurrency in jpackage instances

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1829/files
  - new: https://git.openjdk.java.net/jdk/pull/1829/files/dfa7c507..2baef323

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

  Stats: 103 lines in 4 files changed: 33 ins; 43 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1829.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1829/head:pull/1829

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

From rriggs at openjdk.java.net  Mon Jan  4 15:13:55 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 4 Jan 2021 15:13:55 GMT
Subject: RFR: 8259021 avoid double racy reads from non-volatile fields of
 SharedSecrets [v2]
In-Reply-To: <ruJqHXUZ-yUCc1xFU0t3x9WMQC_L-or1K6x-PRhKGIM=.270c39c0-9d06-4314-9281-ead4c2e1a940@github.com>
References: <VkaRcc6Rsal_pvBfNP-rtC-VWd8MJ9eH7PHlkW0pSj4=.20a3f97b-f1be-422f-adc6-854ce9cf1519@github.com>
 <ruJqHXUZ-yUCc1xFU0t3x9WMQC_L-or1K6x-PRhKGIM=.270c39c0-9d06-4314-9281-ead4c2e1a940@github.com>
Message-ID: <vOofC6irzRsiYn4XGMoX7hY_u_tgTGhFOhQdvz-eTQ4=.5fb77a1f-6c2e-4508-9428-ba91947afb46@github.com>

On Mon, 4 Jan 2021 14:27:09 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> See: https://bugs.openjdk.java.net/browse/JDK-8259021
>> See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html
>
> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert the unrelated change

The bug title and the PR title need to be the same.
Editing either one is fine.

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

Marked as reviewed by rriggs (Reviewer).

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

From erikj at openjdk.java.net  Mon Jan  4 15:32:11 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 4 Jan 2021 15:32:11 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v4]
In-Reply-To: <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>
Message-ID: <Pou_LYeQxlmfSUKL7idTqkfyI-sslh0f43ZYcRpK2M0=.34bd1893-3b67-4d08-bbaf-389022f89923@github.com>

On Tue, 15 Dec 2020 22:56:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [ ] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie 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:
> 
>  - Update comment refering to "make" dir
>  - Move new symbols to jdk.compiler
>  - Merge branch 'master' into shuffle-data
>  - Move macosxicons from share to macosx
>  - Move to share/data, and move jdwp.spec to java.se
>  - Update references in test
>  - Step 2: Update references
>  - First stage, move actual data files

Marked as reviewed by erikj (Reviewer).

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

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

From rrich at openjdk.java.net  Mon Jan  4 15:59:58 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Mon, 4 Jan 2021 15:59:58 GMT
Subject: RFR: 8259021 avoid double racy reads from non-volatile fields of
 SharedSecrets [v2]
In-Reply-To: <vOofC6irzRsiYn4XGMoX7hY_u_tgTGhFOhQdvz-eTQ4=.5fb77a1f-6c2e-4508-9428-ba91947afb46@github.com>
References: <VkaRcc6Rsal_pvBfNP-rtC-VWd8MJ9eH7PHlkW0pSj4=.20a3f97b-f1be-422f-adc6-854ce9cf1519@github.com>
 <ruJqHXUZ-yUCc1xFU0t3x9WMQC_L-or1K6x-PRhKGIM=.270c39c0-9d06-4314-9281-ead4c2e1a940@github.com>
 <vOofC6irzRsiYn4XGMoX7hY_u_tgTGhFOhQdvz-eTQ4=.5fb77a1f-6c2e-4508-9428-ba91947afb46@github.com>
Message-ID: <7MBH2JiOtwASAlXwxLRoJRQfrVdqKI6hGiPCU-DCohw=.993d3b32-d590-4346-b213-2d5a5e01dd66@github.com>

On Mon, 4 Jan 2021 15:11:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert the unrelated change
>
> The bug title and the PR title need to be the same.
> Editing either one is fine.

But wouldn't it be legal for a compiler (java to bytecode or bytecode to
machinecode) to replace references of my_local_copy with references to
static_field?

Foo my_local_copy = static_field;
if (my_copy == null) {
   initialize();
   my_local_copy = static_field;
}
return my_local_copy;

Only if static_field was volatile this would be illegal, wouldn't it?

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

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

From plevart at openjdk.java.net  Mon Jan  4 16:32:00 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Mon, 4 Jan 2021 16:32:00 GMT
Subject: RFR: 8259021: SharedSecrets should avoid double racy reads from
 non-volatile fields [v2]
In-Reply-To: <7MBH2JiOtwASAlXwxLRoJRQfrVdqKI6hGiPCU-DCohw=.993d3b32-d590-4346-b213-2d5a5e01dd66@github.com>
References: <VkaRcc6Rsal_pvBfNP-rtC-VWd8MJ9eH7PHlkW0pSj4=.20a3f97b-f1be-422f-adc6-854ce9cf1519@github.com>
 <ruJqHXUZ-yUCc1xFU0t3x9WMQC_L-or1K6x-PRhKGIM=.270c39c0-9d06-4314-9281-ead4c2e1a940@github.com>
 <vOofC6irzRsiYn4XGMoX7hY_u_tgTGhFOhQdvz-eTQ4=.5fb77a1f-6c2e-4508-9428-ba91947afb46@github.com>
 <7MBH2JiOtwASAlXwxLRoJRQfrVdqKI6hGiPCU-DCohw=.993d3b32-d590-4346-b213-2d5a5e01dd66@github.com>
Message-ID: <VrYODNJY4VT1ZRxaP-OUAFc0K-FMKoHxVsHZKcrfqb8=.e02efe5e-3c36-4c07-81cb-07fbfb9852ff@github.com>

On Mon, 4 Jan 2021 15:57:33 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> The bug title and the PR title need to be the same.
>> Editing either one is fine.
>
> But wouldn't it be legal for a compiler (java to bytecode or bytecode to
> machinecode) to replace references of my_local_copy with references to
> static_field?
> 
> Foo my_local_copy = static_field;
> if (my_copy == null) {
>    initialize();
>    my_local_copy = static_field;
> }
> return my_local_copy;
> 
> Only if static_field was volatile this would be illegal, wouldn't it?

@reinrich I don't think Java compilers may do that. If this was allowed, such variables would not be called "local".

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

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

From shade at openjdk.java.net  Mon Jan  4 17:43:57 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 4 Jan 2021 17:43:57 GMT
Subject: RFR: 8259021: SharedSecrets should avoid double racy reads from
 non-volatile fields [v2]
In-Reply-To: <ruJqHXUZ-yUCc1xFU0t3x9WMQC_L-or1K6x-PRhKGIM=.270c39c0-9d06-4314-9281-ead4c2e1a940@github.com>
References: <VkaRcc6Rsal_pvBfNP-rtC-VWd8MJ9eH7PHlkW0pSj4=.20a3f97b-f1be-422f-adc6-854ce9cf1519@github.com>
 <ruJqHXUZ-yUCc1xFU0t3x9WMQC_L-or1K6x-PRhKGIM=.270c39c0-9d06-4314-9281-ead4c2e1a940@github.com>
Message-ID: <8kMKZLqpHzKTAWeXeyvmj-Yu_lMXoCgDeazcXoc5rIU=.c0d87c92-7811-4327-8ff8-c74344b0c8ff@github.com>

On Mon, 4 Jan 2021 14:27:09 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> See: https://bugs.openjdk.java.net/browse/JDK-8259021
>> See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html
>
> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert the unrelated change

Marked as reviewed by shade (Reviewer).

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

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

From github.com+471021+marschall at openjdk.java.net  Mon Jan  4 17:50:10 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Mon, 4 Jan 2021 17:50:10 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v2]
In-Reply-To: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
Message-ID: <JXlsEiP6ji1qvL3p8rqZL1GvCPY2QVU4cz_ln6l6T6M=.c1aee1a8-db72-42f5-ba8f-ce3c775eebd4@github.com>

> Implement three optimiztations for Reader.read(CharBuffer)
> 
> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.

Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision:

  Fix off-heap code path
  
  The off-heap code path was missing a buffer.put

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1915/files
  - new: https://git.openjdk.java.net/jdk/pull/1915/files/967b314a..a88cd931

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

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

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

From hboehm at google.com  Mon Jan  4 17:50:44 2021
From: hboehm at google.com (Hans Boehm)
Date: Mon, 4 Jan 2021 09:50:44 -0800
Subject: RFR: 8259021: SharedSecrets should avoid double racy reads from
 non-volatile fields [v2]
In-Reply-To: <VrYODNJY4VT1ZRxaP-OUAFc0K-FMKoHxVsHZKcrfqb8=.e02efe5e-3c36-4c07-81cb-07fbfb9852ff@github.com>
References: <VkaRcc6Rsal_pvBfNP-rtC-VWd8MJ9eH7PHlkW0pSj4=.20a3f97b-f1be-422f-adc6-854ce9cf1519@github.com>
 <ruJqHXUZ-yUCc1xFU0t3x9WMQC_L-or1K6x-PRhKGIM=.270c39c0-9d06-4314-9281-ead4c2e1a940@github.com>
 <vOofC6irzRsiYn4XGMoX7hY_u_tgTGhFOhQdvz-eTQ4=.5fb77a1f-6c2e-4508-9428-ba91947afb46@github.com>
 <7MBH2JiOtwASAlXwxLRoJRQfrVdqKI6hGiPCU-DCohw=.993d3b32-d590-4346-b213-2d5a5e01dd66@github.com>
 <VrYODNJY4VT1ZRxaP-OUAFc0K-FMKoHxVsHZKcrfqb8=.e02efe5e-3c36-4c07-81cb-07fbfb9852ff@github.com>
Message-ID: <CAMOCf+jzP_Ofj9Q02iZw9-hrFgjSsMw0MgemABFkb2GNMnz_BA@mail.gmail.com>

On Mon, Jan 4, 2021 at 8:34 AM Peter Levart <plevart at openjdk.java.net>
wrote:
>
> On Mon, 4 Jan 2021 15:57:33 GMT, Richard Reingruber <rrich at openjdk.org>
wrote:
>
> >> The bug title and the PR title need to be the same.
> >> Editing either one is fine.
> >
> > But wouldn't it be legal for a compiler (java to bytecode or bytecode to
> > machinecode) to replace references of my_local_copy with references to
> > static_field?
> >
> > Foo my_local_copy = static_field;
> > if (my_copy == null) {
> >    initialize();
> >    my_local_copy = static_field;
> > }
> > return my_local_copy;
> >
> > Only if static_field was volatile this would be illegal, wouldn't it?
>
> @reinrich I don't think Java compilers may do that. If this was allowed,
such variables would not be called "local".
>

Indeed. Such transformations are allowed in C and C++ (since data races
result in undefined behavior, and thus the
compiler is allowed to assume there are no concurrent writes), but not in
Java.

From mchung at openjdk.java.net  Mon Jan  4 17:47:57 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 4 Jan 2021 17:47:57 GMT
Subject: RFR: 8259021: SharedSecrets should avoid double racy reads from
 non-volatile fields [v2]
In-Reply-To: <ruJqHXUZ-yUCc1xFU0t3x9WMQC_L-or1K6x-PRhKGIM=.270c39c0-9d06-4314-9281-ead4c2e1a940@github.com>
References: <VkaRcc6Rsal_pvBfNP-rtC-VWd8MJ9eH7PHlkW0pSj4=.20a3f97b-f1be-422f-adc6-854ce9cf1519@github.com>
 <ruJqHXUZ-yUCc1xFU0t3x9WMQC_L-or1K6x-PRhKGIM=.270c39c0-9d06-4314-9281-ead4c2e1a940@github.com>
Message-ID: <QLfPiqut8mCst88y1aHCVE2FPgJe2fM5KMHJi2S5mYk=.c4f9a736-6623-4021-813f-897732ab13be@github.com>

On Mon, 4 Jan 2021 14:27:09 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> See: https://bugs.openjdk.java.net/browse/JDK-8259021
>> See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html
>
> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert the unrelated change

Marked as reviewed by mchung (Reviewer).

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

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

From rrich at openjdk.java.net  Mon Jan  4 18:20:58 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Mon, 4 Jan 2021 18:20:58 GMT
Subject: RFR: 8259021: SharedSecrets should avoid double racy reads from
 non-volatile fields [v2]
In-Reply-To: <QLfPiqut8mCst88y1aHCVE2FPgJe2fM5KMHJi2S5mYk=.c4f9a736-6623-4021-813f-897732ab13be@github.com>
References: <VkaRcc6Rsal_pvBfNP-rtC-VWd8MJ9eH7PHlkW0pSj4=.20a3f97b-f1be-422f-adc6-854ce9cf1519@github.com>
 <ruJqHXUZ-yUCc1xFU0t3x9WMQC_L-or1K6x-PRhKGIM=.270c39c0-9d06-4314-9281-ead4c2e1a940@github.com>
 <QLfPiqut8mCst88y1aHCVE2FPgJe2fM5KMHJi2S5mYk=.c4f9a736-6623-4021-813f-897732ab13be@github.com>
Message-ID: <F2RdU9RX6qkQy5d9BvDcK5rV4BVYJTJru5KZeZL2x3c=.ddf7779f-3733-4302-ab7a-18db41ccbbcb@github.com>

On Mon, 4 Jan 2021 17:45:25 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert the unrelated change
>
> Marked as reviewed by mchung (Reviewer).

> 
> 
> _Mailing list message from [Hans Boehm](mailto:hboehm at google.com) on [core-libs-dev](mailto:core-libs-dev at openjdk.java.net):_
> 
> On Mon, Jan 4, 2021 at 8:34 AM Peter Levart <plevart at openjdk.java.net>
> wrote:
> 
> > On Mon, 4 Jan 2021 15:57:33 GMT, Richard Reingruber <rrich at openjdk.org>
> 
> wrote:
> 
> > > > The bug title and the PR title need to be the same.
> > > > Editing either one is fine.
> > > 
> > > 
> > > But wouldn't it be legal for a compiler (java to bytecode or bytecode to
> > > machinecode) to replace references of my_local_copy with references to
> > > static_field?
> > > Foo my_local_copy = static_field;
> > > if (my_copy == null) {
> > > initialize();
> > > my_local_copy = static_field;
> > > }
> > > return my_local_copy;
> > > Only if static_field was volatile this would be illegal, wouldn't it?
> > 
> > 
> > @reinrich I don't think Java compilers may do that. If this was allowed,
> 
> such variables would not be called "local".
> 
> > 
> 
> Indeed. Such transformations are allowed in C and C++ (since data races
> result in undefined behavior, and thus the
> compiler is allowed to assume there are no concurrent writes), but not in
> Java.

Thanks for the explanation.

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

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

From rrich at openjdk.java.net  Mon Jan  4 18:24:57 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Mon, 4 Jan 2021 18:24:57 GMT
Subject: RFR: 8259021: SharedSecrets should avoid double racy reads from
 non-volatile fields [v2]
In-Reply-To: <ruJqHXUZ-yUCc1xFU0t3x9WMQC_L-or1K6x-PRhKGIM=.270c39c0-9d06-4314-9281-ead4c2e1a940@github.com>
References: <VkaRcc6Rsal_pvBfNP-rtC-VWd8MJ9eH7PHlkW0pSj4=.20a3f97b-f1be-422f-adc6-854ce9cf1519@github.com>
 <ruJqHXUZ-yUCc1xFU0t3x9WMQC_L-or1K6x-PRhKGIM=.270c39c0-9d06-4314-9281-ead4c2e1a940@github.com>
Message-ID: <TiofD1L3jFtRviLcCfEE_u9JnCnzo4Oq34iNYttWrI8=.e390b112-f0d2-487a-8afc-49885cb3bd6f@github.com>

On Mon, 4 Jan 2021 14:27:09 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> See: https://bugs.openjdk.java.net/browse/JDK-8259021
>> See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html
>
> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert the unrelated change

Marked as reviewed by rrich (Committer).

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

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

From naoto at openjdk.java.net  Mon Jan  4 18:42:57 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 4 Jan 2021 18:42:57 GMT
Subject: RFR: 8258878: (tz) Upgrade time-zone data to tzdata2020e
In-Reply-To: <9Vhqq8tJSSFttfpVHRl2YMj8DHXs8IhYajW61wQbMhs=.a9a11b2e-9b08-474c-a1cb-cbfa34b4c0d2@github.com>
References: <9Vhqq8tJSSFttfpVHRl2YMj8DHXs8IhYajW61wQbMhs=.a9a11b2e-9b08-474c-a1cb-cbfa34b4c0d2@github.com>
Message-ID: <7r3wdiUnqGu6e_8opiRMohNAHmpacTreFd9w16bizpw=.39cb08c2-1a7d-4ced-a425-0062c0d9f181@github.com>

On Mon, 4 Jan 2021 18:11:05 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the integration of tzdata2020e to JDK.
> 
> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-December/000063.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258878
> 
> Most of the changes are about correcting past timestamps and Australia/Currie timezone is removed.
> 
> Regression Tests pass along with JCK.
> 
> Please let me know if the changes are good to push.
> 
> Thanks,
> Kiran

Looks good.
IIUC, 2020f is already out, and the 2020e-2020f diff does not seem to include any data change. Would you change this PR to incorporate 2020f?

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

Marked as reviewed by naoto (Reviewer).

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

From erikj at openjdk.java.net  Mon Jan  4 18:54:55 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 4 Jan 2021 18:54:55 GMT
Subject: RFR: 8258878: (tz) Upgrade time-zone data to tzdata2020e
In-Reply-To: <9Vhqq8tJSSFttfpVHRl2YMj8DHXs8IhYajW61wQbMhs=.a9a11b2e-9b08-474c-a1cb-cbfa34b4c0d2@github.com>
References: <9Vhqq8tJSSFttfpVHRl2YMj8DHXs8IhYajW61wQbMhs=.a9a11b2e-9b08-474c-a1cb-cbfa34b4c0d2@github.com>
Message-ID: <XDCpnJTd3byPDyNNtweggKAOWGwXClPHI2P85U5fMF4=.d23588ff-e7ec-45f8-9d30-6d75d1ec9e6f@github.com>

On Mon, 4 Jan 2021 18:11:05 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the integration of tzdata2020e to JDK.
> 
> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-December/000063.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258878
> 
> Most of the changes are about correcting past timestamps and Australia/Currie timezone is removed.
> 
> Regression Tests pass along with JCK.
> 
> Please let me know if the changes are good to push.
> 
> Thanks,
> Kiran

Marked as reviewed by erikj (Reviewer).

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

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

From jlaskey at openjdk.java.net  Mon Jan  4 19:52:18 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 4 Jan 2021 19:52:18 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v9]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <1x-JXb6q5tPjvf2SZItze0r1etXGKnIPZ3wtORNMKro=.485a0405-bf2f-45d4-92a1-732f6f743b80@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

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

 - Merge branch 'master' into 8248862
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Added coverage testing
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Cleanups from Chris H.
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Propagate exception
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Override AbstractSplittableGenerator
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Fix extends
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Use Map.of instead of Map.ofEntries
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Changes to RandomGeneratorFactory requested by @PaulSandoz
 - Review changes
   
   @PaulSandoz and @rogermb
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Update package-info.java
 - ... and 24 more: https://git.openjdk.java.net/jdk/compare/f80c63b3...e75cc844

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

Changes: https://git.openjdk.java.net/jdk/pull/1292/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=08
  Stats: 13525 lines in 26 files changed: 11366 ins; 2040 del; 119 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

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

From prr at openjdk.java.net  Mon Jan  4 21:24:14 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 4 Jan 2021 21:24:14 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v4]
In-Reply-To: <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>
Message-ID: <YT7on7W1w9GJRTMfz2KtftKo7yGbVTgZxYcqXv1POBU=.59b49a13-da41-4c93-88c7-1830b87d0b63@github.com>

On Tue, 15 Dec 2020 22:56:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [ ] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie 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:
> 
>  - Update comment refering to "make" dir
>  - Move new symbols to jdk.compiler
>  - Merge branch 'master' into shuffle-data
>  - Move macosxicons from share to macosx
>  - Move to share/data, and move jdwp.spec to java.se
>  - Update references in test
>  - Step 2: Update references
>  - First stage, move actual data files

Marked as reviewed by prr (Reviewer).

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

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

From peter.levart at gmail.com  Mon Jan  4 21:48:00 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 4 Jan 2021 22:48:00 +0100
Subject: Is SharedSecrets thread-safe?
In-Reply-To: <1114179516.261393.1609435545716@mail.vodafone.de>
References: <938640011.238938.1609249350345@mail.vodafone.de>
 <99d009fe-8901-d107-0779-c8965dfb257b@j-kuhn.de>
 <CAMOCf+j05BGap5C_VjRi+nm5FHVwdJ4bmwejEL1pHf1Jro5yxA@mail.gmail.com>
 <1927632433.243197.1609284763289@mail.vodafone.de>
 <9863a935-29ab-4426-2aa1-75ef0808de41@oracle.com>
 <CAMOCf+gogQti=Hfp3+GSD=+=qrsddaSf1mxosgbWEHONHFxk1A@mail.gmail.com>
 <0de44a07-cbf3-9924-c667-2e624728e84e@gmail.com>
 <1114179516.261393.1609435545716@mail.vodafone.de>
Message-ID: <68044bb3-b7e2-a4b3-e89c-03c5d35b6dc9@gmail.com>

Hello 99206970363698485155,


Thanks for these pointers. I would prefer to untangle those knots one at 
a time, if you don't mind, since some of them touch other parts of code 
while this change to SharedSecrets is pretty straightforward and localized.


Regards, Peter


On 12/31/20 6:25 PM, some-java-user-99206970363698485155 at vodafonemail.de 
wrote:
> Hello Peter,
> the changes look good, however there might be more to consider:
>
> - `jdk.internal.access.SharedSecrets.getJavaLangRefAccess()`
>    Might be good to add a comment there or for `java.lang.ref.Reference` that it is (hopefully?)
>    initialized during JVM start-up. Similar to the comment for `AccessibleObject` which states
>    that it is initialized in "initPhase1".
>    Currently without special knowledge about JVM start-up, it is not obvious that this construct
>    is safe.
>
> - `java.io.Console.cons`
>    This is pretty brittle. It is currently only thread-safe because the only accessor is
>    `System.console()` which has its own synchronization. However, I doubt that the author was aware
>    that `Console.cons` on its own is not thread-safe.
>    In general, why is there lazy initialization twice? Once in `System.console()` and then in the
>    accessor for `Console.cons`. In my opinion *only* `java.io.Console` should have the lazy
>    initialization logic (with proper synchronization!) and make sure that only one `Console` instance
>    exists.
>
> - `jdk.internal.access.JavaIOAccess.charset()`
>    The implementation of this one is extremely brittle. While it documents that the `Password` class
>    calling it will make sure that `System.console()` has been called before, in that `Password` class
>    there is not such notice, so it could easily happen that someone breaks this at a later point.
>    Additionally the field `Console.cs` it accesses is not `final`, making it even more brittle.
>
>    In my opinion there should be two changes:
>    1. Change `JavaIOAccess.charset()` -> `charset(Console)`, which then accesses the charset from that
>       Console argument.
>       This enforces that the user of the access already has the Console initialized and indirectly
>       establishes the happens-before relationship for `Console.cs`.
>    2. The Console class should have the following fields `final`:
>       readLock, writeLock, reader, out, pw, formatter, cs
>       For `cs` this would merely require introducing a local variable.
>
>    In general `sun.security.util.Password.convertToBytes(char[])` is problematic because it makes
>    passwords unportable when one OS uses a different terminal encoding than another.
>    The cleaner backward compatible solution might be to simply block all non-ASCII chars (i.e. throw
>    exception for them)?
>    This would break for all existing users which used non-ASCII chars or where their terminal has an
>    encoding not based on ASCII, but these users might already have different problems due to the
>    existing implementation.
>
> - `jdk.internal.access.SharedSecrets.setJavaAWTAccess(JavaAWTAccess)`
>    Might have to establish a happens-before relationship for `getJavaAWTAccess()` because caller
>    appears to expect a `JavaAWTAccess` in case respective class has been loaded.
>
>    On a side note here: The implementation of that access appears to contain redundant code:
>    https://github.com/openjdk/jdk/blob/8435f0daf2413a4c17578dd288e093fe006b3880/src/java.desktop/share/classes/sun/awt/AppContext.java#L866
>    The null check there makes no sense because `ecx` is always null at that point.
>
> - `jdk.internal.access.SharedSecrets.setJavaAWTFontAccess(JavaAWTFontAccess)`
>    This seems to be rather brittle as well because its callers check whether the access has already
>    been initialized.
>    Additionally this seems to be more complicated than it has to be: It appears to be simpler to have
>    `SharedSecrets` initialize the access by initializing only `NumericShaper` (or `TextAttribute`,
>    ultimately does not matter which class from that package is used) when `getJavaAWTFontAccess()` is
>    called. The performance penalty (if any) is likely negligible.
>
> - `com.sun.jmx.mbeanserver.JavaBeansAccessor`
>    Since the static initializer of that class is loading `Introspector` (which sets access object)
>    anyways it might be saner to have this initialization logic in `SharedSecrets` instead.
>
> Kind regards
>
>> Peter Levart <peter.levart at gmail.com> hat am 31. Dezember 2020 um 11:07 geschrieben:
>>
>>
>>
>> On 12/31/20 2:30 AM, Hans Boehm wrote:
>>> It sounds as though this would be correct if
>>>
>>> if (static_field == null) {
>>>     initialize();
>>> }
>>> return static_field;
>>> ```
>>>
>>> were rewritten as
>>>
>>> Foo my_local_copy = static_field;
>>> if (my_copy == null) {
>>>      initialize();
>>>      my_local_copy = static_field;
>>> }
>>> return my_local_copy;
>>>
>>> That would prevent the redundant read of static_field unless this thread
>>> did the initialization, in which case the original null would no longer be
>>> visible to the second read.
>>>
>>> Hans
>>
>> I agree. The initialize() part is triggering some class initialization
>> where concurrent attempts do establish a HB edge so the 2nd read of
>> static_field after initialize() is ordered properly and can't read null.
>>
>> I created a JIRA ticket here:
>> https://bugs.openjdk.java.net/browse/JDK-8259021
>>
>> And prepared a PR here: https://github.com/openjdk/jdk/pull/1914
>>
>>
>> Happy new year,
>>
>> Peter
>>
>>
>>> On Tue, Dec 29, 2020 at 4:55 PM Claes Redestad <claes.redestad at oracle.com>
>>> wrote:
>>>
>>>> Hans' assessment seems about right in the generic case he's describing.
>>>>
>>>> But consider:
>>>>
>>>> 1. There is no concurrent setting of anything here - it's done in a
>>>> static initializer which will happen exactly once by the thread
>>>> initializing the class ($ 12.2.4 item 9).
>>>>
>>>> 2. While there is a data race on the access of the fields in
>>>> SharedSecrets, all of the Access instances are stateless. This means the
>>>> race is benign in the sense that when reading the field only a null or
>>>> a safely published instance can be observed.
>>>>
>>>> I wouldn't swear there's a strict guarantee a null can never be returned
>>>> from a SharedSecrets accessor though. Perhaps that's something that
>>>> could be hardened.
>>>>
>>>> /Claes
>>>>
>>>> On 2020-12-30 00:32, some-java-user-99206970363698485155 at vodafonemail.de
>>>> wrote:
>>>>> That would also be my understanding of the current situation, though
>>>> this contradicts what
>>>>> Claes wrote.
>>>>> Maybe the JVM behaves in a way which does not allow reordering, but the
>>>> JLS definitely seems
>>>>> to allow it. Section ? 12.2.4 [0] only mentions that for the class to be
>>>> initialized there
>>>>> has to exist a lock LC (or at least the happens-before relationship),
>>>> but there is no
>>>>> "freeze the world" or anything similar which would force a
>>>> happens-before relationship
>>>>> for the code in `SharedSecrets`.
>>>>>
>>>>> Maybe most of the `SharedSecrets` methods are thread-safe (albeit
>>>> extremely brittle) because
>>>>> the classes to which the accessor objects belong to have previously
>>>> already been loaded
>>>>> before `SharedSecrets` is used, therefore having already established a
>>>> happens-before
>>>>> relationship.
>>>>> However, this is definitely not the case for all of the methods as shown
>>>> by the following
>>>>> example:
>>>>> ```
>>>>> CookieHandler.setDefault(new CookieHandler() {
>>>>>        @Override
>>>>>        public void put(URI uri, Map<String, List<String>> responseHeaders)
>>>> throws IOException { }
>>>>>        @Override
>>>>>        public Map<String, List<String>> get(URI uri, Map<String,
>>>> List<String>> requestHeaders) throws IOException {
>>>>>            return Collections.emptyMap();
>>>>>        }
>>>>> });
>>>>>
>>>>> // Any site which uses cookies (i.e. Set-Cookie or Set-Cookie2 header)
>>>>> URL url = new URL("https://oracle.com");
>>>>> url.openConnection().getHeaderFields();
>>>>> ```
>>>>>
>>>>> Running this code with `openjdk 15 2020-09-15` shows that the call to
>>>>> `SharedSecrets.getJavaNetHttpCookieAccess()` is made before the class
>>>> `HttpCookie` has
>>>>> been accessed and initialized. Therefore merely running this code in two
>>>> separate threads
>>>>> (both having been started before the code is executed, since
>>>> `Thread.start()` establishes
>>>>> a happens-before relationship) should be enough to render that
>>>> `SharedSecrets` method
>>>>> non-thread-safe.
>>>>>
>>>>> Kind regards
>>>>>
>>>>>
>>>>> [0]
>>>> https://docs.oracle.com/javase/specs/jls/se15/html/jls-12.html#jls-12.4.2
>>>>>> Hans Boehm <hboehm at google.com> hat am 29. Dezember 2020 um 18:53
>>>> geschrieben:
>>>>>> If static_field is not volatile, and set concurrently, then the first
>>>> read of static_field may return non-null and the second null, without
>>>> initialize() even being executed. The Java memory model does not prevent
>>>> reordering of non-volatile reads from the same field (for good reason).
>>>>>> Even if initialize() is executed and performs a volatile read, this
>>>> reasoning doesn't hold. The initial static_field read may be delayed past
>>>> the volatile read inside the conditional and hence, at least theoretically,
>>>> past the second read. Control dependencies don't order reads, either in
>>>> Java, or in modern weakly-ordered architectures with branch prediction.
>>>> This doesn't matter if initialize() sets static_field.
>>>>>> This all assumes that having two threads call initialize() is OK.
>>>>>>
>>>>>> Java code with data races is extremely tricky and rarely correct.
>>>>>>
>>>>>> Hans

From info at j-kuhn.de  Mon Jan  4 23:09:48 2021
From: info at j-kuhn.de (Johannes Kuhn)
Date: Tue, 5 Jan 2021 00:09:48 +0100
Subject: java.io.Console (was: Is SharedSecrets thread-safe?)
In-Reply-To: <68044bb3-b7e2-a4b3-e89c-03c5d35b6dc9@gmail.com>
References: <938640011.238938.1609249350345@mail.vodafone.de>
 <99d009fe-8901-d107-0779-c8965dfb257b@j-kuhn.de>
 <CAMOCf+j05BGap5C_VjRi+nm5FHVwdJ4bmwejEL1pHf1Jro5yxA@mail.gmail.com>
 <1927632433.243197.1609284763289@mail.vodafone.de>
 <9863a935-29ab-4426-2aa1-75ef0808de41@oracle.com>
 <CAMOCf+gogQti=Hfp3+GSD=+=qrsddaSf1mxosgbWEHONHFxk1A@mail.gmail.com>
 <0de44a07-cbf3-9924-c667-2e624728e84e@gmail.com>
 <1114179516.261393.1609435545716@mail.vodafone.de>
 <68044bb3-b7e2-a4b3-e89c-03c5d35b6dc9@gmail.com>
Message-ID: <5c576124-23e6-462a-8208-d16ee017db56@j-kuhn.de>

This brings up some stuff I wanted to mention for some time:

* Console.cs is one of the fields projects like JRuby hack into (at 
least in the past). My guess is that they handle encodings in Ruby, and 
not using the Java facilities for that.

The fact that it is also exported as shared secret for some unrelated 
stuff (sun.security.util) shows that there might be a need for a 
supported, public API.

* java.io.Console has a nice API - but it only works (at least on 
Windows) if there is indeed a console attached. It usually doesn't work 
inside an IDE.

Is there an interest to allow IDEs to create their own Console 
implementation, exposed through SPI?
I would volunteer to write the spec and a patch, but there should be 
some general interest for this - as someone has to sponsor that.
(And as a fair warning: It would be my first bigger contribution to 
OpenJDK.)

- Johannes

On 04-Jan-21 22:48, Peter Levart wrote:
> Hello 99206970363698485155,
> 
> 
> Thanks for these pointers. I would prefer to untangle those knots one at 
> a time, if you don't mind, since some of them touch other parts of code 
> while this change to SharedSecrets is pretty straightforward and localized.
> 
> 
> Regards, Peter
> 
> 
> On 12/31/20 6:25 PM, some-java-user-99206970363698485155 at vodafonemail.de 
> wrote:
>> Hello Peter,
>> the changes look good, however there might be more to consider:
>>
>> - `jdk.internal.access.SharedSecrets.getJavaLangRefAccess()`
>> ?? Might be good to add a comment there or for 
>> `java.lang.ref.Reference` that it is (hopefully?)
>> ?? initialized during JVM start-up. Similar to the comment for 
>> `AccessibleObject` which states
>> ?? that it is initialized in "initPhase1".
>> ?? Currently without special knowledge about JVM start-up, it is not 
>> obvious that this construct
>> ?? is safe.
>>
>> - `java.io.Console.cons`
>> ?? This is pretty brittle. It is currently only thread-safe because 
>> the only accessor is
>> ?? `System.console()` which has its own synchronization. However, I 
>> doubt that the author was aware
>> ?? that `Console.cons` on its own is not thread-safe.
>> ?? In general, why is there lazy initialization twice? Once in 
>> `System.console()` and then in the
>> ?? accessor for `Console.cons`. In my opinion *only* `java.io.Console` 
>> should have the lazy
>> ?? initialization logic (with proper synchronization!) and make sure 
>> that only one `Console` instance
>> ?? exists.
>>
>> - `jdk.internal.access.JavaIOAccess.charset()`
>> ?? The implementation of this one is extremely brittle. While it 
>> documents that the `Password` class
>> ?? calling it will make sure that `System.console()` has been called 
>> before, in that `Password` class
>> ?? there is not such notice, so it could easily happen that someone 
>> breaks this at a later point.
>> ?? Additionally the field `Console.cs` it accesses is not `final`, 
>> making it even more brittle.
>>
>> ?? In my opinion there should be two changes:
>> ?? 1. Change `JavaIOAccess.charset()` -> `charset(Console)`, which 
>> then accesses the charset from that
>> ????? Console argument.
>> ????? This enforces that the user of the access already has the 
>> Console initialized and indirectly
>> ????? establishes the happens-before relationship for `Console.cs`.
>> ?? 2. The Console class should have the following fields `final`:
>> ????? readLock, writeLock, reader, out, pw, formatter, cs
>> ????? For `cs` this would merely require introducing a local variable.
>>
>> ?? In general `sun.security.util.Password.convertToBytes(char[])` is 
>> problematic because it makes
>> ?? passwords unportable when one OS uses a different terminal encoding 
>> than another.
>> ?? The cleaner backward compatible solution might be to simply block 
>> all non-ASCII chars (i.e. throw
>> ?? exception for them)?
>> ?? This would break for all existing users which used non-ASCII chars 
>> or where their terminal has an
>> ?? encoding not based on ASCII, but these users might already have 
>> different problems due to the
>> ?? existing implementation.
>>
>> - `jdk.internal.access.SharedSecrets.setJavaAWTAccess(JavaAWTAccess)`
>> ?? Might have to establish a happens-before relationship for 
>> `getJavaAWTAccess()` because caller
>> ?? appears to expect a `JavaAWTAccess` in case respective class has 
>> been loaded.
>>
>> ?? On a side note here: The implementation of that access appears to 
>> contain redundant code:
>>    
>> https://github.com/openjdk/jdk/blob/8435f0daf2413a4c17578dd288e093fe006b3880/src/java.desktop/share/classes/sun/awt/AppContext.java#L866 
>>
>> ?? The null check there makes no sense because `ecx` is always null at 
>> that point.
>>
>> - 
>> `jdk.internal.access.SharedSecrets.setJavaAWTFontAccess(JavaAWTFontAccess)` 
>>
>> ?? This seems to be rather brittle as well because its callers check 
>> whether the access has already
>> ?? been initialized.
>> ?? Additionally this seems to be more complicated than it has to be: 
>> It appears to be simpler to have
>> ?? `SharedSecrets` initialize the access by initializing only 
>> `NumericShaper` (or `TextAttribute`,
>> ?? ultimately does not matter which class from that package is used) 
>> when `getJavaAWTFontAccess()` is
>> ?? called. The performance penalty (if any) is likely negligible.
>>
>> - `com.sun.jmx.mbeanserver.JavaBeansAccessor`
>> ?? Since the static initializer of that class is loading 
>> `Introspector` (which sets access object)
>> ?? anyways it might be saner to have this initialization logic in 
>> `SharedSecrets` instead.
>>
>> Kind regards
>>
>>> Peter Levart <peter.levart at gmail.com> hat am 31. Dezember 2020 um 
>>> 11:07 geschrieben:
>>>
>>>
>>>
>>> On 12/31/20 2:30 AM, Hans Boehm wrote:
>>>> It sounds as though this would be correct if
>>>>
>>>> if (static_field == null) {
>>>> ??? initialize();
>>>> }
>>>> return static_field;
>>>> ```
>>>>
>>>> were rewritten as
>>>>
>>>> Foo my_local_copy = static_field;
>>>> if (my_copy == null) {
>>>> ???? initialize();
>>>> ???? my_local_copy = static_field;
>>>> }
>>>> return my_local_copy;
>>>>
>>>> That would prevent the redundant read of static_field unless this 
>>>> thread
>>>> did the initialization, in which case the original null would no 
>>>> longer be
>>>> visible to the second read.
>>>>
>>>> Hans
>>>
>>> I agree. The initialize() part is triggering some class initialization
>>> where concurrent attempts do establish a HB edge so the 2nd read of
>>> static_field after initialize() is ordered properly and can't read null.
>>>
>>> I created a JIRA ticket here:
>>> https://bugs.openjdk.java.net/browse/JDK-8259021
>>>
>>> And prepared a PR here: https://github.com/openjdk/jdk/pull/1914
>>>
>>>
>>> Happy new year,
>>>
>>> Peter
>>>
>>>
>>>> On Tue, Dec 29, 2020 at 4:55 PM Claes Redestad 
>>>> <claes.redestad at oracle.com>
>>>> wrote:
>>>>
>>>>> Hans' assessment seems about right in the generic case he's 
>>>>> describing.
>>>>>
>>>>> But consider:
>>>>>
>>>>> 1. There is no concurrent setting of anything here - it's done in a
>>>>> static initializer which will happen exactly once by the thread
>>>>> initializing the class ($ 12.2.4 item 9).
>>>>>
>>>>> 2. While there is a data race on the access of the fields in
>>>>> SharedSecrets, all of the Access instances are stateless. This 
>>>>> means the
>>>>> race is benign in the sense that when reading the field only a null or
>>>>> a safely published instance can be observed.
>>>>>
>>>>> I wouldn't swear there's a strict guarantee a null can never be 
>>>>> returned
>>>>> from a SharedSecrets accessor though. Perhaps that's something that
>>>>> could be hardened.
>>>>>
>>>>> /Claes
>>>>>
>>>>> On 2020-12-30 00:32, 
>>>>> some-java-user-99206970363698485155 at vodafonemail.de
>>>>> wrote:
>>>>>> That would also be my understanding of the current situation, though
>>>>> this contradicts what
>>>>>> Claes wrote.
>>>>>> Maybe the JVM behaves in a way which does not allow reordering, 
>>>>>> but the
>>>>> JLS definitely seems
>>>>>> to allow it. Section ? 12.2.4 [0] only mentions that for the class 
>>>>>> to be
>>>>> initialized there
>>>>>> has to exist a lock LC (or at least the happens-before relationship),
>>>>> but there is no
>>>>>> "freeze the world" or anything similar which would force a
>>>>> happens-before relationship
>>>>>> for the code in `SharedSecrets`.
>>>>>>
>>>>>> Maybe most of the `SharedSecrets` methods are thread-safe (albeit
>>>>> extremely brittle) because
>>>>>> the classes to which the accessor objects belong to have previously
>>>>> already been loaded
>>>>>> before `SharedSecrets` is used, therefore having already 
>>>>>> established a
>>>>> happens-before
>>>>>> relationship.
>>>>>> However, this is definitely not the case for all of the methods as 
>>>>>> shown
>>>>> by the following
>>>>>> example:
>>>>>> ```
>>>>>> CookieHandler.setDefault(new CookieHandler() {
>>>>>> ?????? @Override
>>>>>> ?????? public void put(URI uri, Map<String, List<String>> 
>>>>>> responseHeaders)
>>>>> throws IOException { }
>>>>>> ?????? @Override
>>>>>> ?????? public Map<String, List<String>> get(URI uri, Map<String,
>>>>> List<String>> requestHeaders) throws IOException {
>>>>>> ?????????? return Collections.emptyMap();
>>>>>> ?????? }
>>>>>> });
>>>>>>
>>>>>> // Any site which uses cookies (i.e. Set-Cookie or Set-Cookie2 
>>>>>> header)
>>>>>> URL url = new URL("https://oracle.com");
>>>>>> url.openConnection().getHeaderFields();
>>>>>> ```
>>>>>>
>>>>>> Running this code with `openjdk 15 2020-09-15` shows that the call to
>>>>>> `SharedSecrets.getJavaNetHttpCookieAccess()` is made before the class
>>>>> `HttpCookie` has
>>>>>> been accessed and initialized. Therefore merely running this code 
>>>>>> in two
>>>>> separate threads
>>>>>> (both having been started before the code is executed, since
>>>>> `Thread.start()` establishes
>>>>>> a happens-before relationship) should be enough to render that
>>>>> `SharedSecrets` method
>>>>>> non-thread-safe.
>>>>>>
>>>>>> Kind regards
>>>>>>
>>>>>>
>>>>>> [0]
>>>>> https://docs.oracle.com/javase/specs/jls/se15/html/jls-12.html#jls-12.4.2 
>>>>>
>>>>>>> Hans Boehm <hboehm at google.com> hat am 29. Dezember 2020 um 18:53
>>>>> geschrieben:
>>>>>>> If static_field is not volatile, and set concurrently, then the 
>>>>>>> first
>>>>> read of static_field may return non-null and the second null, without
>>>>> initialize() even being executed. The Java memory model does not 
>>>>> prevent
>>>>> reordering of non-volatile reads from the same field (for good 
>>>>> reason).
>>>>>>> Even if initialize() is executed and performs a volatile read, this
>>>>> reasoning doesn't hold. The initial static_field read may be 
>>>>> delayed past
>>>>> the volatile read inside the conditional and hence, at least 
>>>>> theoretically,
>>>>> past the second read. Control dependencies don't order reads, 
>>>>> either in
>>>>> Java, or in modern weakly-ordered architectures with branch 
>>>>> prediction.
>>>>> This doesn't matter if initialize() sets static_field.
>>>>>>> This all assumes that having two threads call initialize() is OK.
>>>>>>>
>>>>>>> Java code with data races is extremely tricky and rarely correct.
>>>>>>>
>>>>>>> Hans

From rriggs at openjdk.java.net  Mon Jan  4 23:11:58 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 4 Jan 2021 23:11:58 GMT
Subject: RFR: 8166026: Refactor java/lang shell tests to java [v4]
In-Reply-To: <b-QUXe2Fdn9KuSt0-rhLktqNcBJQcFMpLjopYakb8D4=.f57e2ec6-e8d9-42f5-8e6d-450ed5823852@github.com>
References: <4X7LH_dpuKqcZGxizMls2cG80YGIxdBI-DO2K2BnMmQ=.dddd0edf-ce77-439d-a04b-8a435df9f857@github.com>
 <b-QUXe2Fdn9KuSt0-rhLktqNcBJQcFMpLjopYakb8D4=.f57e2ec6-e8d9-42f5-8e6d-450ed5823852@github.com>
Message-ID: <IRxTtSmd5Z9g-4Ruk8lQP5fB1f_LNZv3v6P0mgKqprw=.9fe75dde-db47-43b9-ba77-956aa8d332b3@github.com>

On Mon, 7 Dec 2020 20:15:29 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

>> Refactor `test/jdk/java/lang/Thread/UncaughtExceptions.sh` as java test.
>
> Ivan ?ipka has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8166026: Refactor java/lang shell tests to java
>  - 8166026: Refactor java/lang shell tests to java

Sorry I missed the date; looks fine.

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

Marked as reviewed by rriggs (Reviewer).

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

From bpb at openjdk.java.net  Tue Jan  5 00:53:00 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 5 Jan 2021 00:53:00 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer)
In-Reply-To: <4qIH_bGcy898jYpAfO_Ahwpv63-gDAcA-XEQX-O30pg=.8ad77702-353c-4c6b-8010-1b89f729c691@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <4qIH_bGcy898jYpAfO_Ahwpv63-gDAcA-XEQX-O30pg=.8ad77702-353c-4c6b-8010-1b89f729c691@github.com>
Message-ID: <FhXV1UKPiHE7wey3jjBBJjQzLpKZPhe5aD4sGKneMz0=.16c382e1-b55c-4d63-8538-4e68adfca109@github.com>

On Thu, 31 Dec 2020 10:11:58 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Implement three optimiztations for Reader.read(CharBuffer)
>> 
>> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
>> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
>> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
>
> A couple of implementation notes:
> 
> Reader#read(CharBuffer)
> 
> on-heap case
> 
> I introduced a dedicated path for the on-heap case and directly read into the backing array. This completely avoids the intermediate allocation and copy. Compared to the initial proposal the buffer position is updated. This has to be done because we bypass the buffer and directly read into the array. This also handles the case that #read returns -1.
> 
> I am using a c-style array declaration because the rest of the class uses it.
> 
> off-heap case
> 
> I limit the intermadiate allocation to TRANSFER_BUFFER_SIZE. In order to reduce the total intermediate allocation we now call #read multiple times until the buffer is full or EOF is reached. This changes the behavior slightly as now possibly more data is read. However this should contribute to reduce the overall intermediate allocations.
> 
> A lock is acquired to keep the the read atomic. This is consistent with #skip which also holds a lock over multiple #read calls. This is inconsistent with #transferTo which does not acquire a lock over multiple #read calls. 
> 
> The implementation took inspiration from java.io.InputStream#readNBytes(int).
> 
> InputStreamReader#read(CharBuffer)
> 
> Since StreamDecoder is a Reader as well we can simply delegate.
> 
> StreamDecoder#read(CharBuffer)
> 
> Interestingly this was not implemented even though StreamDecoder internally works on NIO buffers.
> 
> on-heap case
> 
> We see a performance improvement and the elimination of all intermediate allocation.
> 
> StreamDecoder#read(char[], int, int) and InputStreamReader#read(char[], int, int) may get a small improvement as we no longer #slice the buffer.
> 
> off-heap case
> 
> We see the elimination of all intermediate allocation but a performance penalty because we hit the slow path in #decodeLoop. There is a trade-off here, we could improve the performance to previous levels by introducing intermediate allocation again. I don't know how much the users of off-heap buffers care about introducing intermediate allocation vs maximum throughput.
> 
> I was struggling to come up with microbenchmarks because the built in InputStream and Reader implementations are finite but JMH calls the benchmark methods repeatably. I ended up implementing custom infinite InputStream and Reader implementations. The code can be found there:
> 
> https://github.com/marschall/reader-benchmarks/tree/master/src/main/java/com/github/marschall/readerbenchmarks
> 
> An Excel with charts can be found here:
> 
> https://github.com/marschall/reader-benchmarks/raw/master/src/main/resources/4926314.xlsx
> 
> I looked for java.io.Reader#read(CharBuffer) users in the JDK and only found java.util.Scanner#readInput(). I wrote a microbenchmark for this but only found minuscule improvements due to regex dominating the runtime.
> 
> There seem to be no direct Reader tests in the tier1 suite, the initial code was wrong because I forgot to update the buffer code position but I only found out because some Scanner tests failed.

I changed the JBS issue summary to match the title of this PR so that integration blocker is removed.

How does the performance of `InputStreamReader.read(CharBuffer)` compare for the case where only the change to `Reader` is made versus if all your proposed changes are applied?

Some kind of specific test should likely be included.

Note that the more recent copyright year is now 2021.

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

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

From sviswanathan at openjdk.java.net  Tue Jan  5 01:12:13 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 5 Jan 2021 01:12:13 GMT
Subject: [jdk16] RFR: 8259213: Vector conversion with part > 0 is not getting
 intrinsic implementation
Message-ID: <x6nVs7y6VOqt1KwLfLnAAG_80Kf2eKXmnXErqmXcMAY=.df7e3d2f-6f48-4f4d-be0b-44bedb7b8e73@github.com>

Vector conversion with part > 0 is implemented using slice(origin, vector) instead of slice(origin).
The slice(origin) has intrinsic implementation whereas slice(origin, vector) doesn?t.
Slice(origin) is written using vector API methods like rearrange and blend which all have intrinsic implementations.
Also, VectorIntrinsics.VECTOR_ACCESS_OOB_CHECK code is missing from rearrange checkIndexes.

Please review this patch which fixes the above issue.

Best Regards,
Sandhya

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

Commit messages:
 - 8259213: Vector conversion with part > 0 is not getting intrinsic implementation

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

PR: https://git.openjdk.java.net/jdk16/pull/79

From Alan.Bateman at oracle.com  Tue Jan  5 07:28:43 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 5 Jan 2021 07:28:43 +0000
Subject: java.io.Console (was: Is SharedSecrets thread-safe?)
In-Reply-To: <5c576124-23e6-462a-8208-d16ee017db56@j-kuhn.de>
References: <938640011.238938.1609249350345@mail.vodafone.de>
 <99d009fe-8901-d107-0779-c8965dfb257b@j-kuhn.de>
 <CAMOCf+j05BGap5C_VjRi+nm5FHVwdJ4bmwejEL1pHf1Jro5yxA@mail.gmail.com>
 <1927632433.243197.1609284763289@mail.vodafone.de>
 <9863a935-29ab-4426-2aa1-75ef0808de41@oracle.com>
 <CAMOCf+gogQti=Hfp3+GSD=+=qrsddaSf1mxosgbWEHONHFxk1A@mail.gmail.com>
 <0de44a07-cbf3-9924-c667-2e624728e84e@gmail.com>
 <1114179516.261393.1609435545716@mail.vodafone.de>
 <68044bb3-b7e2-a4b3-e89c-03c5d35b6dc9@gmail.com>
 <5c576124-23e6-462a-8208-d16ee017db56@j-kuhn.de>
Message-ID: <06a45ee3-8643-92bf-fd90-abb19bc97e6b@oracle.com>

On 04/01/2021 23:09, Johannes Kuhn wrote:
> This brings up some stuff I wanted to mention for some time:
>
> * Console.cs is one of the fields projects like JRuby hack into (at 
> least in the past). My guess is that they handle encodings in Ruby, 
> and not using the Java facilities for that.
>
> The fact that it is also exported as shared secret for some unrelated 
> stuff (sun.security.util) shows that there might be a need for a 
> supported, public API.
This was discussed here at length in 2016 but there wasn't agreement to 
expose an API at the time.? At issue is that Console is an API for 
reading Strings and char[], not bytes. Maybe it needs to be looked at 
again but we should minimally change the security password code to use 
the internal property so that this shared secret can be removed.

-Alan.

From alanb at openjdk.java.net  Tue Jan  5 08:21:59 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 5 Jan 2021 08:21:59 GMT
Subject: RFR: 8259021: SharedSecrets should avoid double racy reads from
 non-volatile fields [v2]
In-Reply-To: <ruJqHXUZ-yUCc1xFU0t3x9WMQC_L-or1K6x-PRhKGIM=.270c39c0-9d06-4314-9281-ead4c2e1a940@github.com>
References: <VkaRcc6Rsal_pvBfNP-rtC-VWd8MJ9eH7PHlkW0pSj4=.20a3f97b-f1be-422f-adc6-854ce9cf1519@github.com>
 <ruJqHXUZ-yUCc1xFU0t3x9WMQC_L-or1K6x-PRhKGIM=.270c39c0-9d06-4314-9281-ead4c2e1a940@github.com>
Message-ID: <VtFiOIgs9FR8IBvEkiD1wQIBlMVi2eO0zfKk821UBUY=.395d71ec-3e64-4ae2-b594-3baa66a03679@github.com>

On Mon, 4 Jan 2021 14:27:09 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> See: https://bugs.openjdk.java.net/browse/JDK-8259021
>> See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html
>
> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert the unrelated change

Marked as reviewed by alanb (Reviewer).

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

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

From Alan.Bateman at oracle.com  Tue Jan  5 10:02:17 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 5 Jan 2021 10:02:17 +0000
Subject: java.io.Console (was: Is SharedSecrets thread-safe?)
In-Reply-To: <5c576124-23e6-462a-8208-d16ee017db56@j-kuhn.de>
References: <938640011.238938.1609249350345@mail.vodafone.de>
 <99d009fe-8901-d107-0779-c8965dfb257b@j-kuhn.de>
 <CAMOCf+j05BGap5C_VjRi+nm5FHVwdJ4bmwejEL1pHf1Jro5yxA@mail.gmail.com>
 <1927632433.243197.1609284763289@mail.vodafone.de>
 <9863a935-29ab-4426-2aa1-75ef0808de41@oracle.com>
 <CAMOCf+gogQti=Hfp3+GSD=+=qrsddaSf1mxosgbWEHONHFxk1A@mail.gmail.com>
 <0de44a07-cbf3-9924-c667-2e624728e84e@gmail.com>
 <1114179516.261393.1609435545716@mail.vodafone.de>
 <68044bb3-b7e2-a4b3-e89c-03c5d35b6dc9@gmail.com>
 <5c576124-23e6-462a-8208-d16ee017db56@j-kuhn.de>
Message-ID: <c9213c9a-74fc-8399-7c8a-7d6becd47f9b@oracle.com>

On 04/01/2021 23:09, Johannes Kuhn wrote:
> :
>
> * java.io.Console has a nice API - but it only works (at least on 
> Windows) if there is indeed a console attached. It usually doesn't 
> work inside an IDE.
>
> Is there an interest to allow IDEs to create their own Console 
> implementation, exposed through SPI?
> I would volunteer to write the spec and a patch, but there should be 
> some general interest for this - as someone has to sponsor that.
> (And as a fair warning: It would be my first bigger contribution to 
> OpenJDK.)

If you have cycles to explore, prototype, and write-up options then it 
could be useful for the discussion. The issue of System::console has 
come up once or twice in the context of IDEs. It may be that we don't 
need a provide implementation that is located by ServiceLoader, instead 
it might be that the JDK just needs something specified to the java 
launcher to run it with an alternative Console implementation.

-Alan


From winterhalter at openjdk.java.net  Tue Jan  5 12:08:10 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Tue, 5 Jan 2021 12:08:10 GMT
Subject: [jdk16] RFR: 8259224: (ann) getAnnotatedReceiverType should not
 parameterize owner(s) of statically nested classes
Message-ID: <3PDkIdfiG84iX79Edt8NPtylPIGrxWDGaH8kJR-278w=.de5791f1-ba08-4fcc-98d1-2e79ef5edfda@github.com>

This change avoid that owner types of static nested classes are returned as parameterized types.

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

Commit messages:
 - 8259224: (ann) getAnnotatedReceiverType should not parameterize owner(s) of statically nested classes

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

PR: https://git.openjdk.java.net/jdk16/pull/82

From winterhalter at openjdk.java.net  Tue Jan  5 12:51:17 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Tue, 5 Jan 2021 12:51:17 GMT
Subject: [jdk16] RFR: 8259224: (ann) getAnnotatedReceiverType should not
 parameterize owner(s) of statically nested classes [v2]
In-Reply-To: <3PDkIdfiG84iX79Edt8NPtylPIGrxWDGaH8kJR-278w=.de5791f1-ba08-4fcc-98d1-2e79ef5edfda@github.com>
References: <3PDkIdfiG84iX79Edt8NPtylPIGrxWDGaH8kJR-278w=.de5791f1-ba08-4fcc-98d1-2e79ef5edfda@github.com>
Message-ID: <NHZX_uK1VaceaEnpfc4Wz8x3llxacCAugHVu1CLRDso=.1f9b9b4d-e22e-4282-9aa9-1b632dc49705@github.com>

> This change avoid that owner types of static nested classes are returned as parameterized types.

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:

  8259224: (ann) getAnnotatedReceiverType should not parameterize owner(s) of statically nested classes

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/82/files
  - new: https://git.openjdk.java.net/jdk16/pull/82/files/dc764ce9..54a9447c

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

  Stats: 136 lines in 3 files changed: 69 ins; 66 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/82.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/82/head:pull/82

PR: https://git.openjdk.java.net/jdk16/pull/82

From mcimadamore at openjdk.java.net  Tue Jan  5 13:02:03 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 5 Jan 2021 13:02:03 GMT
Subject: [jdk16] RFR: 8259027: NullPointerException in makeMappedSegment due
 to NULL Unmapper when length of segment is 0
Message-ID: <2LwfjRhMA5YvA7jxlu5fHJ-f8Vz5DFP1OrDHXHQDw9g=.0bc8fc1b-569a-46fa-a742-8889da218e25@github.com>

When the size of the memory map is zero, FileChannelImpl returns a `null` Unmapper - this creates issues to the mapped memory segment implementation.

To fix, I've created an empty mapped segment class which is initialized to sensible defaults, and whose implenentation of force/load etc. do nothing.

We already had a test for this condition - but the test was missing the `@Test` annotation, so it was not run! I've now beefed up the test a bit to make sure that mapped segment operations do not throw.

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

Commit messages:
 - Create subclass for empty mappings
 - Return dummy mapping when mapping length is zero

Changes: https://git.openjdk.java.net/jdk16/pull/83/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=83&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259027
  Stats: 46 lines in 2 files changed: 40 ins; 2 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/83.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/83/head:pull/83

PR: https://git.openjdk.java.net/jdk16/pull/83

From chegar at openjdk.java.net  Tue Jan  5 14:03:03 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 5 Jan 2021 14:03:03 GMT
Subject: [jdk16] RFR: 8259027: NullPointerException in makeMappedSegment
 due to NULL Unmapper when length of segment is 0
In-Reply-To: <2LwfjRhMA5YvA7jxlu5fHJ-f8Vz5DFP1OrDHXHQDw9g=.0bc8fc1b-569a-46fa-a742-8889da218e25@github.com>
References: <2LwfjRhMA5YvA7jxlu5fHJ-f8Vz5DFP1OrDHXHQDw9g=.0bc8fc1b-569a-46fa-a742-8889da218e25@github.com>
Message-ID: <0NUldegO4Ynn5cKg0O8ddJSS2dY0kLS5lgabQMJOOso=.2f38c8d2-fabb-4d15-9499-4efead4a053c@github.com>

On Tue, 5 Jan 2021 12:56:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> When the size of the memory map is zero, FileChannelImpl returns a `null` Unmapper - this creates issues to the mapped memory segment implementation.
> 
> To fix, I've created an empty mapped segment class which is initialized to sensible defaults, and whose implenentation of force/load etc. do nothing.
> 
> We already had a test for this condition - but the test was missing the `@Test` annotation, so it was not run! I've now beefed up the test a bit to make sure that mapped segment operations do not throw.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MappedMemorySegmentImpl.java line 128:

> 126:                         modes, scope);
> 127:             } else {
> 128:                 return new EmptyMappedMemorySegmentImpl();

While a little pedantic, should the `mapMode` be considered so that an empty mapped segment will feature the expected access modes when queried through the `accessModes` API ?

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

PR: https://git.openjdk.java.net/jdk16/pull/83

From mcimadamore at openjdk.java.net  Tue Jan  5 15:37:00 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 5 Jan 2021 15:37:00 GMT
Subject: [jdk16] RFR: 8259027: NullPointerException in makeMappedSegment
 due to NULL Unmapper when length of segment is 0
In-Reply-To: <0NUldegO4Ynn5cKg0O8ddJSS2dY0kLS5lgabQMJOOso=.2f38c8d2-fabb-4d15-9499-4efead4a053c@github.com>
References: <2LwfjRhMA5YvA7jxlu5fHJ-f8Vz5DFP1OrDHXHQDw9g=.0bc8fc1b-569a-46fa-a742-8889da218e25@github.com>
 <0NUldegO4Ynn5cKg0O8ddJSS2dY0kLS5lgabQMJOOso=.2f38c8d2-fabb-4d15-9499-4efead4a053c@github.com>
Message-ID: <XmbVqkeA5RyllGp_UzzFlx31OShSmNna8N_t_shNb1E=.81a329d9-72c2-4d1a-a9d4-0bffda86c1f3@github.com>

On Tue, 5 Jan 2021 14:00:44 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> When the size of the memory map is zero, FileChannelImpl returns a `null` Unmapper - this creates issues to the mapped memory segment implementation.
>> 
>> To fix, I've created an empty mapped segment class which is initialized to sensible defaults, and whose implenentation of force/load etc. do nothing.
>> 
>> We already had a test for this condition - but the test was missing the `@Test` annotation, so it was not run! I've now beefed up the test a bit to make sure that mapped segment operations do not throw.
>
> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MappedMemorySegmentImpl.java line 128:
> 
>> 126:                         modes, scope);
>> 127:             } else {
>> 128:                 return new EmptyMappedMemorySegmentImpl();
> 
> While a little pedantic, should the `mapMode` be considered so that an empty mapped segment will feature the expected access modes when queried through the `accessModes` API ?

Ugh - yes, good point

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

PR: https://git.openjdk.java.net/jdk16/pull/83

From mcimadamore at openjdk.java.net  Tue Jan  5 15:39:01 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 5 Jan 2021 15:39:01 GMT
Subject: [jdk16] RFR: 8259032: MappedMemorySegmentImpl#makeMappedSegment()
 ignores Unmapper#pagePosition
Message-ID: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>

Hi,
this patch fixes an oversight where the address() method in FileChannelImpl.Unmapper does not take into account the value of `pagePosition` - this leads to a situation in which, effectively, the specified offset when mapping the segment is ignored by the runtime (because base address will always be aligned to some known quantity - which is OS/platform dependent).

To test this I had to break open into FileChannelImpl and ready the granularity.

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

Commit messages:
 - Fix issue in Unmapper implementation not including `pagePosition` in address computation

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

PR: https://git.openjdk.java.net/jdk16/pull/84

From mcimadamore at openjdk.java.net  Tue Jan  5 15:42:11 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 5 Jan 2021 15:42:11 GMT
Subject: [jdk16] RFR: 8259027: NullPointerException in makeMappedSegment
 due to NULL Unmapper when length of segment is 0 [v2]
In-Reply-To: <2LwfjRhMA5YvA7jxlu5fHJ-f8Vz5DFP1OrDHXHQDw9g=.0bc8fc1b-569a-46fa-a742-8889da218e25@github.com>
References: <2LwfjRhMA5YvA7jxlu5fHJ-f8Vz5DFP1OrDHXHQDw9g=.0bc8fc1b-569a-46fa-a742-8889da218e25@github.com>
Message-ID: <PwPKV_Lyulc5Ihda3yre1GhTjsOaC9L5Nrt9l7iK7zs=.32547740-3588-4ce3-a1f8-95af2e18f8a5@github.com>

> When the size of the memory map is zero, FileChannelImpl returns a `null` Unmapper - this creates issues to the mapped memory segment implementation.
> 
> To fix, I've created an empty mapped segment class which is initialized to sensible defaults, and whose implenentation of force/load etc. do nothing.
> 
> We already had a test for this condition - but the test was missing the `@Test` annotation, so it was not run! I've now beefed up the test a bit to make sure that mapped segment operations do not throw.

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

  Added empty mapping support for different access modes

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/83/files
  - new: https://git.openjdk.java.net/jdk16/pull/83/files/10c26170..4dcee6b9

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

  Stats: 23 lines in 2 files changed: 16 ins; 4 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/83.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/83/head:pull/83

PR: https://git.openjdk.java.net/jdk16/pull/83

From chegar at openjdk.java.net  Tue Jan  5 15:44:56 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 5 Jan 2021 15:44:56 GMT
Subject: [jdk16] RFR: 8259027: NullPointerException in makeMappedSegment
 due to NULL Unmapper when length of segment is 0 [v2]
In-Reply-To: <PwPKV_Lyulc5Ihda3yre1GhTjsOaC9L5Nrt9l7iK7zs=.32547740-3588-4ce3-a1f8-95af2e18f8a5@github.com>
References: <2LwfjRhMA5YvA7jxlu5fHJ-f8Vz5DFP1OrDHXHQDw9g=.0bc8fc1b-569a-46fa-a742-8889da218e25@github.com>
 <PwPKV_Lyulc5Ihda3yre1GhTjsOaC9L5Nrt9l7iK7zs=.32547740-3588-4ce3-a1f8-95af2e18f8a5@github.com>
Message-ID: <E324Y7xRgTGWWNhDsxHEV-AcCqD2fTi7dpDyz7nUtRY=.eebe1db3-878d-4d03-99e8-f5bcb5ed830e@github.com>

On Tue, 5 Jan 2021 15:42:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> When the size of the memory map is zero, FileChannelImpl returns a `null` Unmapper - this creates issues to the mapped memory segment implementation.
>> 
>> To fix, I've created an empty mapped segment class which is initialized to sensible defaults, and whose implenentation of force/load etc. do nothing.
>> 
>> We already had a test for this condition - but the test was missing the `@Test` annotation, so it was not run! I've now beefed up the test a bit to make sure that mapped segment operations do not throw.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added empty mapping support for different access modes

Looks good to me.

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

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/83

From alanb at openjdk.java.net  Tue Jan  5 15:47:57 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 5 Jan 2021 15:47:57 GMT
Subject: [jdk16] RFR: 8259032: MappedMemorySegmentImpl#makeMappedSegment()
 ignores Unmapper#pagePosition
In-Reply-To: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
References: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
Message-ID: <6k21VP3g6k6xubRsu9fCvTKcLMJksumesEI4SXXSVP0=.6897afa5-5af0-484a-8c82-3ef39d6da606@github.com>

On Tue, 5 Jan 2021 15:33:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Hi,
> this patch fixes an oversight where the address() method in FileChannelImpl.Unmapper does not take into account the value of `pagePosition` - this leads to a situation in which, effectively, the specified offset when mapping the segment is ignored by the runtime (because base address will always be aligned to some known quantity - which is OS/platform dependent).
> 
> To test this I had to break open into FileChannelImpl and ready the granularity.

test/jdk/java/foreign/TestByteBuffer.java line 28:

> 26:  * @modules java.base/sun.nio.ch
> 27:  *          jdk.incubator.foreign/jdk.internal.foreign
> 28:  * @run testng/othervm --illegal-access=permit -Dforeign.restricted=permit TestByteBuffer

Can you change java.base/sun.nio.ch to java.base/sun.nio.ch:+open instead? That would avoid the --illegal-access=permit.

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

PR: https://git.openjdk.java.net/jdk16/pull/84

From psandoz at openjdk.java.net  Tue Jan  5 15:53:55 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 5 Jan 2021 15:53:55 GMT
Subject: [jdk16] RFR: 8259213: Vector conversion with part > 0 is not
 getting intrinsic implementation
In-Reply-To: <x6nVs7y6VOqt1KwLfLnAAG_80Kf2eKXmnXErqmXcMAY=.df7e3d2f-6f48-4f4d-be0b-44bedb7b8e73@github.com>
References: <x6nVs7y6VOqt1KwLfLnAAG_80Kf2eKXmnXErqmXcMAY=.df7e3d2f-6f48-4f4d-be0b-44bedb7b8e73@github.com>
Message-ID: <Ox1CUdHW3QG5v3BiKHIT2bDBnFasUmJvKQLHM9vUank=.bafe30bb-422a-41f1-be9a-39e1f536721c@github.com>

On Tue, 5 Jan 2021 01:03:55 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Vector conversion with part > 0 is implemented using slice(origin, vector) instead of slice(origin).
> The slice(origin) has intrinsic implementation whereas slice(origin, vector) doesn?t.
> Slice(origin) is written using vector API methods like rearrange and blend which all have intrinsic implementations.
> Also, VectorIntrinsics.VECTOR_ACCESS_OOB_CHECK code is missing from rearrange checkIndexes.
> 
> Please review this patch which fixes the above issue.
> 
> Best Regards,
> Sandhya

Looks good. Can you please update the copyright year before integrating?

I notice the issue is not assigned to you, unsure of Skara will make it so once integrated.

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

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/79

From uschindler at openjdk.java.net  Tue Jan  5 15:53:56 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Tue, 5 Jan 2021 15:53:56 GMT
Subject: [jdk16] RFR: 8259027: NullPointerException in makeMappedSegment
 due to NULL Unmapper when length of segment is 0 [v2]
In-Reply-To: <PwPKV_Lyulc5Ihda3yre1GhTjsOaC9L5Nrt9l7iK7zs=.32547740-3588-4ce3-a1f8-95af2e18f8a5@github.com>
References: <2LwfjRhMA5YvA7jxlu5fHJ-f8Vz5DFP1OrDHXHQDw9g=.0bc8fc1b-569a-46fa-a742-8889da218e25@github.com>
 <PwPKV_Lyulc5Ihda3yre1GhTjsOaC9L5Nrt9l7iK7zs=.32547740-3588-4ce3-a1f8-95af2e18f8a5@github.com>
Message-ID: <u3xoXxsrdqo7ugjTF9cBOabBOR9dhoh8LxQH01kE310=.2bbedadb-1069-42b4-8c17-5fd63b12c57f@github.com>

On Tue, 5 Jan 2021 15:42:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> When the size of the memory map is zero, FileChannelImpl returns a `null` Unmapper - this creates issues to the mapped memory segment implementation.
>> 
>> To fix, I've created an empty mapped segment class which is initialized to sensible defaults, and whose implenentation of force/load etc. do nothing.
>> 
>> We already had a test for this condition - but the test was missing the `@Test` annotation, so it was not run! I've now beefed up the test a bit to make sure that mapped segment operations do not throw.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added empty mapping support for different access modes

Looks fine!
In fact it's more complicated than the workaround, but this allows to call load() or force().

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

Marked as reviewed by uschindler (Author).

PR: https://git.openjdk.java.net/jdk16/pull/83

From uschindler at openjdk.java.net  Tue Jan  5 15:57:57 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Tue, 5 Jan 2021 15:57:57 GMT
Subject: [jdk16] RFR: 8259032: MappedMemorySegmentImpl#makeMappedSegment()
 ignores Unmapper#pagePosition
In-Reply-To: <6k21VP3g6k6xubRsu9fCvTKcLMJksumesEI4SXXSVP0=.6897afa5-5af0-484a-8c82-3ef39d6da606@github.com>
References: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
 <6k21VP3g6k6xubRsu9fCvTKcLMJksumesEI4SXXSVP0=.6897afa5-5af0-484a-8c82-3ef39d6da606@github.com>
Message-ID: <rfSd13qs3N61u-RQdxTj1YW6-e7I8yf4zSvrHu6pYjQ=.88db13d2-4fb8-498f-9daa-428ce41e4fe9@github.com>

On Tue, 5 Jan 2021 15:44:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi,
>> this patch fixes an oversight where the address() method in FileChannelImpl.Unmapper does not take into account the value of `pagePosition` - this leads to a situation in which, effectively, the specified offset when mapping the segment is ignored by the runtime (because base address will always be aligned to some known quantity - which is OS/platform dependent).
>> 
>> To test this I had to break open into FileChannelImpl and ready the granularity.
>
> test/jdk/java/foreign/TestByteBuffer.java line 28:
> 
>> 26:  * @modules java.base/sun.nio.ch
>> 27:  *          jdk.incubator.foreign/jdk.internal.foreign
>> 28:  * @run testng/othervm --illegal-access=permit -Dforeign.restricted=permit TestByteBuffer
> 
> Can you change java.base/sun.nio.ch to java.base/sun.nio.ch:+open instead? That would avoid the --illegal-access=permit.

I am not sure if a test like this is really needed.
The alignment is pageSize on Linux and some arbitrary value (65536) on Windows. If you have some test file that writes like a few bytes (1, 2, 3, 4,...) To a file and then maps it with offsets other than zero, you just have to get the first byte and compare it to offset.

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

PR: https://git.openjdk.java.net/jdk16/pull/84

From uschindler at openjdk.java.net  Tue Jan  5 16:06:56 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Tue, 5 Jan 2021 16:06:56 GMT
Subject: [jdk16] RFR: 8259032: MappedMemorySegmentImpl#makeMappedSegment()
 ignores Unmapper#pagePosition
In-Reply-To: <rfSd13qs3N61u-RQdxTj1YW6-e7I8yf4zSvrHu6pYjQ=.88db13d2-4fb8-498f-9daa-428ce41e4fe9@github.com>
References: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
 <6k21VP3g6k6xubRsu9fCvTKcLMJksumesEI4SXXSVP0=.6897afa5-5af0-484a-8c82-3ef39d6da606@github.com>
 <rfSd13qs3N61u-RQdxTj1YW6-e7I8yf4zSvrHu6pYjQ=.88db13d2-4fb8-498f-9daa-428ce41e4fe9@github.com>
Message-ID: <BBIK5-AVrPp_Zwflq2j9rDyCJC6DCTgh0ANm9JHDPJY=.b8eb8956-9ad0-4ce9-bbef-99c6796d62b1@github.com>

On Tue, 5 Jan 2021 15:55:10 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

>> test/jdk/java/foreign/TestByteBuffer.java line 28:
>> 
>>> 26:  * @modules java.base/sun.nio.ch
>>> 27:  *          jdk.incubator.foreign/jdk.internal.foreign
>>> 28:  * @run testng/othervm --illegal-access=permit -Dforeign.restricted=permit TestByteBuffer
>> 
>> Can you change java.base/sun.nio.ch to java.base/sun.nio.ch:+open instead? That would avoid the --illegal-access=permit.
>
> I am not sure if a test like this is really needed.
> The alignment is pageSize on Linux and some arbitrary value (65536) on Windows. If you have some test file that writes like a few bytes (1, 2, 3, 4,...) To a file and then maps it with offsets other than zero, you just have to get the first byte and compare it to offset.

In fact the new test only checks if everything is aligned like we expect, but it does not test that our mapping returns a memory segment with expected contents.

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

PR: https://git.openjdk.java.net/jdk16/pull/84

From uschindler at openjdk.java.net  Tue Jan  5 16:06:56 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Tue, 5 Jan 2021 16:06:56 GMT
Subject: [jdk16] RFR: 8259032: MappedMemorySegmentImpl#makeMappedSegment()
 ignores Unmapper#pagePosition
In-Reply-To: <BBIK5-AVrPp_Zwflq2j9rDyCJC6DCTgh0ANm9JHDPJY=.b8eb8956-9ad0-4ce9-bbef-99c6796d62b1@github.com>
References: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
 <6k21VP3g6k6xubRsu9fCvTKcLMJksumesEI4SXXSVP0=.6897afa5-5af0-484a-8c82-3ef39d6da606@github.com>
 <rfSd13qs3N61u-RQdxTj1YW6-e7I8yf4zSvrHu6pYjQ=.88db13d2-4fb8-498f-9daa-428ce41e4fe9@github.com>
 <BBIK5-AVrPp_Zwflq2j9rDyCJC6DCTgh0ANm9JHDPJY=.b8eb8956-9ad0-4ce9-bbef-99c6796d62b1@github.com>
Message-ID: <dA3VqCIVGItosjmklXMYrwD7CiIe8emJdiJqt_Ov-BQ=.0c14b436-2ad4-4c96-ad6f-de1af6d21666@github.com>

On Tue, 5 Jan 2021 16:01:11 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

>> I am not sure if a test like this is really needed.
>> The alignment is pageSize on Linux and some arbitrary value (65536) on Windows. If you have some test file that writes like a few bytes (1, 2, 3, 4,...) To a file and then maps it with offsets other than zero, you just have to get the first byte and compare it to offset.
>
> In fact the new test only checks if everything is aligned like we expect, but it does not test that our mapping returns a memory segment with expected contents.

So I tend to make a simple test without reflection that writes a defined sequence of bytes to a file and then maps it with various offsets, checking that the first byte in the mapped segment is from that sequence.

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

PR: https://git.openjdk.java.net/jdk16/pull/84

From github.com+654217+bastie at openjdk.java.net  Tue Jan  5 16:11:57 2021
From: github.com+654217+bastie at openjdk.java.net (Sebastian Ritter)
Date: Tue, 5 Jan 2021 16:11:57 GMT
Subject: Withdrawn: 8066622 8066637: remove deprecated using
 java.io.File.toURL() in internal classes
In-Reply-To: <EbSZJq5R0_NZWXVivUsn-nJoOwHQCtYwUrUrPOeKa0c=.5877af1b-0db2-4064-bc35-638151ecc774@github.com>
References: <EbSZJq5R0_NZWXVivUsn-nJoOwHQCtYwUrUrPOeKa0c=.5877af1b-0db2-4064-bc35-638151ecc774@github.com>
Message-ID: <LgoblOa9PxgjaP6NdmEMWskG3W71yfettzq-1879WdE=.cb525af0-f6a9-44cc-a10c-f88d1ce3098c@github.com>

On Sat, 7 Nov 2020 07:55:03 GMT, Sebastian Ritter <github.com+654217+bastie at openjdk.org> wrote:

> In result of Javadoc to do not use java.io.File.toURL()
> Change use  java.io.File.toURL().toURI() instead.

This pull request has been closed without being integrated.

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

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

From mcimadamore at openjdk.java.net  Tue Jan  5 16:15:57 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 5 Jan 2021 16:15:57 GMT
Subject: [jdk16] RFR: 8259032: MappedMemorySegmentImpl#makeMappedSegment()
 ignores Unmapper#pagePosition
In-Reply-To: <dA3VqCIVGItosjmklXMYrwD7CiIe8emJdiJqt_Ov-BQ=.0c14b436-2ad4-4c96-ad6f-de1af6d21666@github.com>
References: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
 <6k21VP3g6k6xubRsu9fCvTKcLMJksumesEI4SXXSVP0=.6897afa5-5af0-484a-8c82-3ef39d6da606@github.com>
 <rfSd13qs3N61u-RQdxTj1YW6-e7I8yf4zSvrHu6pYjQ=.88db13d2-4fb8-498f-9daa-428ce41e4fe9@github.com>
 <BBIK5-AVrPp_Zwflq2j9rDyCJC6DCTgh0ANm9JHDPJY=.b8eb8956-9ad0-4ce9-bbef-99c6796d62b1@github.com>
 <dA3VqCIVGItosjmklXMYrwD7CiIe8emJdiJqt_Ov-BQ=.0c14b436-2ad4-4c96-ad6f-de1af6d21666@github.com>
Message-ID: <98zeUvOyyXJSIqA7bs-K2krugdkrkWK12aFunEVWUcc=.d8a7158c-a6b0-4d01-9426-6bc869eee66e@github.com>

On Tue, 5 Jan 2021 16:03:04 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

>> In fact the new test only checks if everything is aligned like we expect, but it does not test that our mapping returns a memory segment with expected contents.
>
> So I tend to make a simple test without reflection that writes a defined sequence of bytes to a file and then maps it with various offsets, checking that the first byte in the mapped segment is from that sequence.

Good suggestion!

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

PR: https://git.openjdk.java.net/jdk16/pull/84

From mcimadamore at openjdk.java.net  Tue Jan  5 16:17:59 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 5 Jan 2021 16:17:59 GMT
Subject: [jdk16] Integrated: 8259027: NullPointerException in
 makeMappedSegment due to NULL Unmapper when length of segment is 0
In-Reply-To: <2LwfjRhMA5YvA7jxlu5fHJ-f8Vz5DFP1OrDHXHQDw9g=.0bc8fc1b-569a-46fa-a742-8889da218e25@github.com>
References: <2LwfjRhMA5YvA7jxlu5fHJ-f8Vz5DFP1OrDHXHQDw9g=.0bc8fc1b-569a-46fa-a742-8889da218e25@github.com>
Message-ID: <KyN0Dl5Or5Uv_6RqqO_DVBB6r_gVTmeKuQYO_NXPgho=.29007478-e4a3-4dc0-8c5a-8485d1f8e763@github.com>

On Tue, 5 Jan 2021 12:56:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> When the size of the memory map is zero, FileChannelImpl returns a `null` Unmapper - this creates issues to the mapped memory segment implementation.
> 
> To fix, I've created an empty mapped segment class which is initialized to sensible defaults, and whose implenentation of force/load etc. do nothing.
> 
> We already had a test for this condition - but the test was missing the `@Test` annotation, so it was not run! I've now beefed up the test a bit to make sure that mapped segment operations do not throw.

This pull request has now been integrated.

Changeset: b7940aa1
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/b7940aa1
Stats:     54 lines in 2 files changed: 51 ins; 1 del; 2 mod

8259027: NullPointerException in makeMappedSegment due to NULL Unmapper when length of segment is 0

Reviewed-by: chegar, uschindler

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

PR: https://git.openjdk.java.net/jdk16/pull/83

From sviswanathan at openjdk.java.net  Tue Jan  5 17:17:11 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 5 Jan 2021 17:17:11 GMT
Subject: [jdk16] RFR: 8259213: Vector conversion with part > 0 is not
 getting intrinsic implementation [v2]
In-Reply-To: <x6nVs7y6VOqt1KwLfLnAAG_80Kf2eKXmnXErqmXcMAY=.df7e3d2f-6f48-4f4d-be0b-44bedb7b8e73@github.com>
References: <x6nVs7y6VOqt1KwLfLnAAG_80Kf2eKXmnXErqmXcMAY=.df7e3d2f-6f48-4f4d-be0b-44bedb7b8e73@github.com>
Message-ID: <0JtoDeYrCblrZAyD7ODvI1i1TDeOVX9qIsiyN1y0qAk=.2108d536-7648-4c80-98c0-06e5212cd55b@github.com>

> Vector conversion with part > 0 is implemented using slice(origin, vector) instead of slice(origin).
> The slice(origin) has intrinsic implementation whereas slice(origin, vector) doesn?t.
> Slice(origin) is written using vector API methods like rearrange and blend which all have intrinsic implementations.
> Also, VectorIntrinsics.VECTOR_ACCESS_OOB_CHECK code is missing from rearrange checkIndexes.
> 
> Please review this patch which fixes the above issue.
> 
> Best Regards,
> Sandhya

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

  update copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/79/files
  - new: https://git.openjdk.java.net/jdk16/pull/79/files/c283812f..29ed8e43

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

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

PR: https://git.openjdk.java.net/jdk16/pull/79

From sviswanathan at openjdk.java.net  Tue Jan  5 17:20:00 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 5 Jan 2021 17:20:00 GMT
Subject: [jdk16] RFR: 8259213: Vector conversion with part > 0 is not
 getting intrinsic implementation [v2]
In-Reply-To: <Ox1CUdHW3QG5v3BiKHIT2bDBnFasUmJvKQLHM9vUank=.bafe30bb-422a-41f1-be9a-39e1f536721c@github.com>
References: <x6nVs7y6VOqt1KwLfLnAAG_80Kf2eKXmnXErqmXcMAY=.df7e3d2f-6f48-4f4d-be0b-44bedb7b8e73@github.com>
 <Ox1CUdHW3QG5v3BiKHIT2bDBnFasUmJvKQLHM9vUank=.bafe30bb-422a-41f1-be9a-39e1f536721c@github.com>
Message-ID: <NP1holLEoH91fF8kCg0DBOzox0jQPiCyI7Fl51rcwC8=.39dda856-013c-40a2-a79a-73d54b2fe30d@github.com>

On Tue, 5 Jan 2021 15:51:08 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyright year
>
> Looks good. Can you please update the copyright year before integrating?
> 
> I notice the issue is not assigned to you, unsure of Skara will make it so once integrated.

@PaulSandoz Thanks a lot for the review. I have updated the copyright year. Please let me know if I can go ahead and integrate.

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

PR: https://git.openjdk.java.net/jdk16/pull/79

From mcimadamore at openjdk.java.net  Tue Jan  5 17:28:10 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 5 Jan 2021 17:28:10 GMT
Subject: [jdk16] RFR: 8259032: MappedMemorySegmentImpl#makeMappedSegment()
 ignores Unmapper#pagePosition [v2]
In-Reply-To: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
References: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
Message-ID: <ioK4uSSuUrjGcdnoJ89hWcfoFOUbwSrhVMG9aozZIzE=.b3308414-1528-4152-acba-87fa764ade8b@github.com>

> Hi,
> this patch fixes an oversight where the address() method in FileChannelImpl.Unmapper does not take into account the value of `pagePosition` - this leads to a situation in which, effectively, the specified offset when mapping the segment is ignored by the runtime (because base address will always be aligned to some known quantity - which is OS/platform dependent).
> 
> To test this I had to break open into FileChannelImpl and ready the granularity.

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

  Simplify test not to depend on implementation internals

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/84/files
  - new: https://git.openjdk.java.net/jdk16/pull/84/files/b58a381c..7a78d724

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

  Stats: 25 lines in 1 file changed: 7 ins; 14 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/84.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/84/head:pull/84

PR: https://git.openjdk.java.net/jdk16/pull/84

From psandoz at openjdk.java.net  Tue Jan  5 17:33:56 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 5 Jan 2021 17:33:56 GMT
Subject: [jdk16] RFR: 8259213: Vector conversion with part > 0 is not
 getting intrinsic implementation [v2]
In-Reply-To: <Ox1CUdHW3QG5v3BiKHIT2bDBnFasUmJvKQLHM9vUank=.bafe30bb-422a-41f1-be9a-39e1f536721c@github.com>
References: <x6nVs7y6VOqt1KwLfLnAAG_80Kf2eKXmnXErqmXcMAY=.df7e3d2f-6f48-4f4d-be0b-44bedb7b8e73@github.com>
 <Ox1CUdHW3QG5v3BiKHIT2bDBnFasUmJvKQLHM9vUank=.bafe30bb-422a-41f1-be9a-39e1f536721c@github.com>
Message-ID: <7fz4H7u0nulJP4-2XpQaGTNiwKHAMzDULJCK9hmuRac=.04dee001-5510-4ea1-90eb-d99e50e692d6@github.com>

On Tue, 5 Jan 2021 15:51:08 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyright year
>
> Looks good. Can you please update the copyright year before integrating?
> 
> I notice the issue is not assigned to you, unsure of Skara will make it so once integrated.

> @PaulSandoz Thanks a lot for the review. I have updated the copyright year. Please let me know if I can go ahead and integrate.

All good.

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

PR: https://git.openjdk.java.net/jdk16/pull/79

From github.com+471021+marschall at openjdk.java.net  Tue Jan  5 17:44:20 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Tue, 5 Jan 2021 17:44:20 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v3]
In-Reply-To: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
Message-ID: <12KyBCHFk1ApB6qI4bPcYvsdXSWbKX9VeKc_LUsvnnM=.a0fd1617-108f-4522-b546-f6e5482cf13f@github.com>

> Implement three optimiztations for Reader.read(CharBuffer)
> 
> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.

Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright years

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1915/files
  - new: https://git.openjdk.java.net/jdk/pull/1915/files/a88cd931..8d405587

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

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

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

From plevart at openjdk.java.net  Tue Jan  5 17:44:57 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Tue, 5 Jan 2021 17:44:57 GMT
Subject: Integrated: 8259021: SharedSecrets should avoid double racy reads
 from non-volatile fields
In-Reply-To: <VkaRcc6Rsal_pvBfNP-rtC-VWd8MJ9eH7PHlkW0pSj4=.20a3f97b-f1be-422f-adc6-854ce9cf1519@github.com>
References: <VkaRcc6Rsal_pvBfNP-rtC-VWd8MJ9eH7PHlkW0pSj4=.20a3f97b-f1be-422f-adc6-854ce9cf1519@github.com>
Message-ID: <PfpKDGuFNqT_23svauLh7wAkST5mwqVmwZZq8n-01Yk=.4cdb7321-d51e-485b-b758-aabfb3a2d08a@github.com>

On Thu, 31 Dec 2020 10:02:01 GMT, Peter Levart <plevart at openjdk.org> wrote:

> See: https://bugs.openjdk.java.net/browse/JDK-8259021
> See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html

This pull request has now been integrated.

Changeset: 85bac8c4
Author:    Peter Levart <plevart at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/85bac8c4
Stats:     93 lines in 1 file changed: 48 ins; 0 del; 45 mod

8259021: SharedSecrets should avoid double racy reads from non-volatile fields

Reviewed-by: shade, redestad, rriggs, mchung, rrich, alanb

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

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

From sviswanathan at openjdk.java.net  Tue Jan  5 17:44:59 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 5 Jan 2021 17:44:59 GMT
Subject: [jdk16] Integrated: 8259213: Vector conversion with part > 0 is not
 getting intrinsic implementation
In-Reply-To: <x6nVs7y6VOqt1KwLfLnAAG_80Kf2eKXmnXErqmXcMAY=.df7e3d2f-6f48-4f4d-be0b-44bedb7b8e73@github.com>
References: <x6nVs7y6VOqt1KwLfLnAAG_80Kf2eKXmnXErqmXcMAY=.df7e3d2f-6f48-4f4d-be0b-44bedb7b8e73@github.com>
Message-ID: <lGqtS2tS5k8XNPdDybC6xtmxlZ4e3tIOWjl8Qmn3mD4=.ffea1ec0-a8d1-40c0-9b63-b936c3f8c11e@github.com>

On Tue, 5 Jan 2021 01:03:55 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Vector conversion with part > 0 is implemented using slice(origin, vector) instead of slice(origin).
> The slice(origin) has intrinsic implementation whereas slice(origin, vector) doesn?t.
> Slice(origin) is written using vector API methods like rearrange and blend which all have intrinsic implementations.
> Also, VectorIntrinsics.VECTOR_ACCESS_OOB_CHECK code is missing from rearrange checkIndexes.
> 
> Please review this patch which fixes the above issue.
> 
> Best Regards,
> Sandhya

This pull request has now been integrated.

Changeset: 50bf4330
Author:    Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/50bf4330
Stats:     10 lines in 2 files changed: 6 ins; 0 del; 4 mod

8259213: Vector conversion with part > 0 is not getting intrinsic implementation

Reviewed-by: psandoz

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

PR: https://git.openjdk.java.net/jdk16/pull/79

From kustos at gmx.net  Tue Jan  5 17:53:06 2021
From: kustos at gmx.net (Philippe Marschall)
Date: Tue, 5 Jan 2021 18:53:06 +0100
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer)
In-Reply-To: <FhXV1UKPiHE7wey3jjBBJjQzLpKZPhe5aD4sGKneMz0=.16c382e1-b55c-4d63-8538-4e68adfca109@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <4qIH_bGcy898jYpAfO_Ahwpv63-gDAcA-XEQX-O30pg=.8ad77702-353c-4c6b-8010-1b89f729c691@github.com>
 <FhXV1UKPiHE7wey3jjBBJjQzLpKZPhe5aD4sGKneMz0=.16c382e1-b55c-4d63-8538-4e68adfca109@github.com>
Message-ID: <415bcf9c-e257-9fe5-1ff0-97a6c45b9a41@gmx.net>



On 05.01.21 01:53, Brian Burkhalter wrote:
> ...
>
> I changed the JBS issue summary to match the title of this PR so that integration blocker is removed.

Thank you.

> How does the performance of `InputStreamReader.read(CharBuffer)` compare for the case where only the change to `Reader` is made versus if all your proposed changes are applied?

I can look into this, this will take a moment. I guess it would also
make sense to have a comparison with a version that does intermediate
heap allocation for off-heap buffers in InputStreamReader#read(CharBuffer).

> Some kind of specific test should likely be included.

Sure. The existing tests in this area seem to be #main-based. Would you
prefer #main based tests or TestNG tests?

> Note that the more recent copyright year is now 2021.

Indeed it is, fixed.

Cheers
Philippe

From naoto at openjdk.java.net  Tue Jan  5 18:07:09 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 5 Jan 2021 18:07:09 GMT
Subject: [jdk16] RFR: 8259075: Update the copyright notice in the files
 generated by CLDR Converter tool
Message-ID: <XXdFf3N8oQz8g9ptH0wZubHk6v_qRD8y9szU92NBc6k=.e6a3e1ca-817a-4c0d-9be1-f871c38c92a4@github.com>

Please review this copyright notice update in the CLDR Converter tool. It is now synched with src/java.base/share/legal/cldr.md file.

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

Commit messages:
 - 8259075: Update the copyright notice in the files generated by CLDR Converter tool

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

PR: https://git.openjdk.java.net/jdk16/pull/85

From brian.burkhalter at oracle.com  Tue Jan  5 18:08:19 2021
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 5 Jan 2021 10:08:19 -0800
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer)
In-Reply-To: <415bcf9c-e257-9fe5-1ff0-97a6c45b9a41@gmx.net>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <4qIH_bGcy898jYpAfO_Ahwpv63-gDAcA-XEQX-O30pg=.8ad77702-353c-4c6b-8010-1b89f729c691@github.com>
 <FhXV1UKPiHE7wey3jjBBJjQzLpKZPhe5aD4sGKneMz0=.16c382e1-b55c-4d63-8538-4e68adfca109@github.com>
 <415bcf9c-e257-9fe5-1ff0-97a6c45b9a41@gmx.net>
Message-ID: <DCA62E36-DD65-4CA7-8C7D-E0C90B5C4A6E@oracle.com>


> On Jan 5, 2021, at 9:53 AM, Philippe Marschall <kustos at gmx.net> wrote:
> 
>> How does the performance of `InputStreamReader.read(CharBuffer)` compare for the case where only the change to `Reader` is made versus if all your proposed changes are applied?
> 
> I can look into this, this will take a moment. I guess it would also
> make sense to have a comparison with a version that does intermediate
> heap allocation for off-heap buffers in InputStreamReader#read(CharBuffer).

If you like. I was just wondering whether the change to Reader.read(CharBuffer) would be enough.

>> Some kind of specific test should likely be included.
> 
> Sure. The existing tests in this area seem to be #main-based. Would you
> prefer #main based tests or TestNG tests?

For new tests we seem to be preferring Tests NG.

>> Note that the more recent copyright year is now 2021.
> 
> Indeed it is, fixed.

Thanks.

Brian

From rriggs at openjdk.java.net  Tue Jan  5 19:02:56 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 5 Jan 2021 19:02:56 GMT
Subject: RFR: 8166026: refactor shell tests to java [v3]
In-Reply-To: <YjqkPGpeQAtzPTePPc-oC9IQffJtZSs7upW_Uq-XTTI=.951cc3a8-ad17-41df-b074-105a149c4338@github.com>
References: <H2UZy1486X04VxMmEPt1dG78BSsv6F-qqhUNWMcpW4g=.08c502e1-d13c-4fa2-8174-1227072f7d63@github.com>
 <TBkohlFN17a_8HNW2u958lx38cJ01I8y0-jZbz5ErLI=.ea89580e-9630-45ee-9251-864582b52ca5@github.com>
 <YjqkPGpeQAtzPTePPc-oC9IQffJtZSs7upW_Uq-XTTI=.951cc3a8-ad17-41df-b074-105a149c4338@github.com>
Message-ID: <ZdDnEc86MGQhzX2NAQbCXjTCtJ4Za0k41N_Ek_9PD-I=.20027ab1-2348-4e77-97ec-5e009ed9f39c@github.com>

On Thu, 3 Dec 2020 21:41:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8166026: Refactor java/lang shell tests to java
>
> Marked as reviewed by rriggs (Reviewer).

Some update is needed before this can be integrated.
The BugID has already been resolved.  (And the title did not match the title of the PR).
Perhaps the wrong bugid was referrenced; 8166026 is an umbrella bug for a whole series of changes.

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

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

From rriggs at openjdk.java.net  Tue Jan  5 19:06:56 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 5 Jan 2021 19:06:56 GMT
Subject: RFR: 8166026: Refactor java/lang shell tests to java [v4]
In-Reply-To: <IRxTtSmd5Z9g-4Ruk8lQP5fB1f_LNZv3v6P0mgKqprw=.9fe75dde-db47-43b9-ba77-956aa8d332b3@github.com>
References: <4X7LH_dpuKqcZGxizMls2cG80YGIxdBI-DO2K2BnMmQ=.dddd0edf-ce77-439d-a04b-8a435df9f857@github.com>
 <b-QUXe2Fdn9KuSt0-rhLktqNcBJQcFMpLjopYakb8D4=.f57e2ec6-e8d9-42f5-8e6d-450ed5823852@github.com>
 <IRxTtSmd5Z9g-4Ruk8lQP5fB1f_LNZv3v6P0mgKqprw=.9fe75dde-db47-43b9-ba77-956aa8d332b3@github.com>
Message-ID: <g-JX6S8HFZxfsSbvNNt_rVbTeMq5nUbpj-C3o1v0ROY=.c989c1fb-bd68-440c-8def-7e99d2890475@github.com>

On Mon, 4 Jan 2021 23:09:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ivan ?ipka has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8166026: Refactor java/lang shell tests to java
>>  - 8166026: Refactor java/lang shell tests to java
>
> Sorry I missed the update; looks fine.

Please synchronize the PR with the bug, the bugid 8166026 has been resolved already.

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

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

From jlaskey at openjdk.java.net  Tue Jan  5 19:52:14 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 5 Jan 2021 19:52:14 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v10]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <lqM0P1IBhQ6OW21mcWLXLTZYcdhxPujtIDaTTH3aWQg=.6b371d95-6a98-447a-9570-561d0dfaa6c8@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

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

 - Use annotation for properties. Add getDefault().
 - Merge branch 'master' into 8248862
 - Introduce RandomGeneratorProperties annotation
 - Merge branch 'master' into 8248862
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Added coverage testing
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Cleanups from Chris H.
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Propagate exception
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Override AbstractSplittableGenerator
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Fix extends
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Use Map.of instead of Map.ofEntries
 - ... and 27 more: https://git.openjdk.java.net/jdk/compare/a6c08813...da9fec11

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

Changes: https://git.openjdk.java.net/jdk/pull/1292/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=09
  Stats: 13205 lines in 26 files changed: 11043 ins; 2046 del; 116 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

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

From alanb at openjdk.java.net  Tue Jan  5 20:01:00 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 5 Jan 2021 20:01:00 GMT
Subject: [jdk16] RFR: 8259032: MappedMemorySegmentImpl#makeMappedSegment()
 ignores Unmapper#pagePosition [v2]
In-Reply-To: <ioK4uSSuUrjGcdnoJ89hWcfoFOUbwSrhVMG9aozZIzE=.b3308414-1528-4152-acba-87fa764ade8b@github.com>
References: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
 <ioK4uSSuUrjGcdnoJ89hWcfoFOUbwSrhVMG9aozZIzE=.b3308414-1528-4152-acba-87fa764ade8b@github.com>
Message-ID: <3zS2UwSEWBPJt-YvPvSLYDP1arY5BzYL2IxMoo0EvZo=.96bae7e6-37a1-48a7-b9ec-79ab7d264801@github.com>

On Tue, 5 Jan 2021 17:28:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hi,
>> this patch fixes an oversight where the address() method in FileChannelImpl.Unmapper does not take into account the value of `pagePosition` - this leads to a situation in which, effectively, the specified offset when mapping the segment is ignored by the runtime (because base address will always be aligned to some known quantity - which is OS/platform dependent).
>> 
>> To test this I had to break open into FileChannelImpl and ready the granularity.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify test not to depend on implementation internals

Good suggestion from Uwe.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/84

From uschindler at openjdk.java.net  Tue Jan  5 19:41:59 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Tue, 5 Jan 2021 19:41:59 GMT
Subject: [jdk16] RFR: 8259032: MappedMemorySegmentImpl#makeMappedSegment()
 ignores Unmapper#pagePosition
In-Reply-To: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
References: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
Message-ID: <oC_c14bF3vLyUclYQNw66jC9u6Mx3Lmq36IfpX9gTk0=.13c63b2e-ce87-4768-8c8e-b7cad260e813@github.com>

On Tue, 5 Jan 2021 15:33:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Hi,
> this patch fixes an oversight where the address() method in FileChannelImpl.Unmapper does not take into account the value of `pagePosition` - this leads to a situation in which, effectively, the specified offset when mapping the segment is ignored by the runtime (because base address will always be aligned to some known quantity - which is OS/platform dependent).
> 
> To test this I had to break open into FileChannelImpl and ready the granularity.

Hi,
The new test looks fine to me.
Uwe

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

PR: https://git.openjdk.java.net/jdk16/pull/84

From joehw at openjdk.java.net  Tue Jan  5 20:35:56 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 5 Jan 2021 20:35:56 GMT
Subject: [jdk16] RFR: 8259075: Update the copyright notice in the files
 generated by CLDR Converter tool
In-Reply-To: <XXdFf3N8oQz8g9ptH0wZubHk6v_qRD8y9szU92NBc6k=.e6a3e1ca-817a-4c0d-9be1-f871c38c92a4@github.com>
References: <XXdFf3N8oQz8g9ptH0wZubHk6v_qRD8y9szU92NBc6k=.e6a3e1ca-817a-4c0d-9be1-f871c38c92a4@github.com>
Message-ID: <dh07qjcG8xdzxCU_njN_bTtlqHIKexJ93kin0mv5O10=.4137bb7f-81e0-4da8-aa36-c5de452c0702@github.com>

On Tue, 5 Jan 2021 17:59:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this copyright notice update in the CLDR Converter tool. It is now synched with src/java.base/share/legal/cldr.md file.

Marked as reviewed by joehw (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/85

From isipka at openjdk.java.net  Tue Jan  5 21:02:02 2021
From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=)
Date: Tue, 5 Jan 2021 21:02:02 GMT
Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v3]
In-Reply-To: <ER7KwRyn_fdSvVGVIg1OP20XjFS5oe-tiltPfwb5iZ0=.ff65483c-1a86-4380-8dcb-a4472cd8481f@github.com>
References: <Idcz1uT7CMcM5WM3JKoekIxUS_eLcnAzYXxhz-zJjtE=.5c22a60d-14a1-426d-a63d-06cb42f1718d@github.com>
 <O5GrZ730BMrprdK-Xx6M_30_pWaq5DyBJSYzdRqItDU=.33d2f775-2d88-4a26-bea3-8f0458936445@github.com>
 <ER7KwRyn_fdSvVGVIg1OP20XjFS5oe-tiltPfwb5iZ0=.ff65483c-1a86-4380-8dcb-a4472cd8481f@github.com>
Message-ID: <XwvUNddZI82M8EZvC3j3eywPdmYqPJBV9VxmO-APVsA=.1d81d07f-ac8d-4225-b74e-0a1dedc5399b@github.com>

On Fri, 11 Dec 2020 13:47:54 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8166026: Refactor java/lang shell tests to java
>
> test/jdk/java/lang/annotation/LoaderLeakTest.java line 54:
> 
>> 52:         List<String> classes = List.of("A.class", "B.class", "C.class");
>> 53:         for (String fileName : classes) {
>> 54:             Files.move(
> 
> I don't think it's a good idea to move files created and managed by `jtreg`. I'd recommend you copying them here and, in `runJavaProcess...` constructing `ProcessBuilder` youself:
> 
> var args = new ArrayList<String>(command.length + 1);
> args.add(JDKToolFinder.getJDKTool("java"));
> Collections.addAll(args, command);
> var pb = new ProcessBuilder(args).directory(Paths.get(Utils.TEST_CLASSES).toFile());

They are intentionally moved out of class path so that the application class loader can not find them. If they are not moved they will be loaded by the application class loader and they need to be [loaded](https://github.com/openjdk/jdk/blob/bc56a63702b8730abc1d0aebee133a5884145fa1/test/jdk/java/lang/annotation/LoaderLeakTest.java#L96) by the tests very own `SimpleClassLoader` in order to be able to test for the leakage.

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

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

From iignatyev at openjdk.java.net  Tue Jan  5 21:36:57 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 5 Jan 2021 21:36:57 GMT
Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v3]
In-Reply-To: <XwvUNddZI82M8EZvC3j3eywPdmYqPJBV9VxmO-APVsA=.1d81d07f-ac8d-4225-b74e-0a1dedc5399b@github.com>
References: <Idcz1uT7CMcM5WM3JKoekIxUS_eLcnAzYXxhz-zJjtE=.5c22a60d-14a1-426d-a63d-06cb42f1718d@github.com>
 <O5GrZ730BMrprdK-Xx6M_30_pWaq5DyBJSYzdRqItDU=.33d2f775-2d88-4a26-bea3-8f0458936445@github.com>
 <ER7KwRyn_fdSvVGVIg1OP20XjFS5oe-tiltPfwb5iZ0=.ff65483c-1a86-4380-8dcb-a4472cd8481f@github.com>
 <XwvUNddZI82M8EZvC3j3eywPdmYqPJBV9VxmO-APVsA=.1d81d07f-ac8d-4225-b74e-0a1dedc5399b@github.com>
Message-ID: <eJ94SPjLIO3JJjFOBJuVJ3152XEDWW_v763bBRpQC3g=.47afaed7-f071-4dc8-8448-d29c940b62da@github.com>

On Tue, 5 Jan 2021 20:58:37 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

>> test/jdk/java/lang/annotation/LoaderLeakTest.java line 54:
>> 
>>> 52:         List<String> classes = List.of("A.class", "B.class", "C.class");
>>> 53:         for (String fileName : classes) {
>>> 54:             Files.move(
>> 
>> I don't think it's a good idea to move files created and managed by `jtreg`. I'd recommend you copying them here and, in `runJavaProcess...` constructing `ProcessBuilder` youself:
>> 
>> var args = new ArrayList<String>(command.length + 1);
>> args.add(JDKToolFinder.getJDKTool("java"));
>> Collections.addAll(args, command);
>> var pb = new ProcessBuilder(args).directory(Paths.get(Utils.TEST_CLASSES).toFile());
>
> They are intentionally moved out of class path so that the application class loader can not find them. If they are not moved they will be loaded by the application class loader and they need to be [loaded](https://github.com/openjdk/jdk/blob/bc56a63702b8730abc1d0aebee133a5884145fa1/test/jdk/java/lang/annotation/LoaderLeakTest.java#L96) by the tests very own `SimpleClassLoader` in order to be able to test for the leakage.

I understand the intention, but it can be achieved w/o messing around w/ jtreg managed directories, for example by changing `SimpleClassLoader` to not delegate the loading of `A`, `B`, `C` classes to the application CL.

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

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

From tludwig at vmware.com  Wed Jan  6 03:11:05 2021
From: tludwig at vmware.com (Tommy Ludwig)
Date: Wed, 6 Jan 2021 03:11:05 +0000
Subject: Monitoring wrapped ThreadPoolExecutor returned from Executors
Message-ID: <BYAPR05MB65998619D6784F8FB6E13700DFD00@BYAPR05MB6599.namprd05.prod.outlook.com>

Hello,

In the Micrometer project, we provide metrics instrumentation of `ExectorService`s. For `ThreadPoolExecutor`s, we track the number of completed tasks, active tasks, thread pool sizes, task queue size and remaining capacity via methods from `ThreadPoolExecutor`. We are currently using a brittle reflection hack[1] to do this for the wrapped `ThreadPoolExecutor` returned from `Executors` methods `newSingleThreadExecutor` and `newSingleThreadScheduledExecutor`. With the introduction of JEP-396 in JDK 16, our reflection hack throws an InaccessibleObjectException by default.

I am not seeing a proper way to get at the methods we use for the metrics (e.g. `ThreadPoolExecutor::getCompletedTaskCount`) in this case. Is there a way that I am missing?

>From the JavaDocs, the intention of the wrapping is to prevent changing the ThreadPool configuration. Our use case does not call for changing the thread pool configuration - we want to observe the ExecutorService (e.g. thread pool state) via getter methods for monitoring purposes.

Thanks,
Tommy

[1] https://github.com/micrometer-metrics/micrometer/blob/25f120833f8b73e4bd7cf604831dfddf0112fe9c/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/jvm/ExecutorServiceMetrics.java#L272-L301


From jfranck at openjdk.java.net  Wed Jan  6 11:04:59 2021
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Wed, 6 Jan 2021 11:04:59 GMT
Subject: [jdk16] RFR: 8259224: (ann) getAnnotatedReceiverType should not
 parameterize owner(s) of statically nested classes [v2]
In-Reply-To: <NHZX_uK1VaceaEnpfc4Wz8x3llxacCAugHVu1CLRDso=.1f9b9b4d-e22e-4282-9aa9-1b632dc49705@github.com>
References: <3PDkIdfiG84iX79Edt8NPtylPIGrxWDGaH8kJR-278w=.de5791f1-ba08-4fcc-98d1-2e79ef5edfda@github.com>
 <NHZX_uK1VaceaEnpfc4Wz8x3llxacCAugHVu1CLRDso=.1f9b9b4d-e22e-4282-9aa9-1b632dc49705@github.com>
Message-ID: <Tf9TQMyt_uApNerVSgCWR2XNtmVm30kt56TpdqXXURc=.1c9b4ff0-d696-4bff-8c3a-d087f59e789e@github.com>

On Tue, 5 Jan 2021 12:51:17 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> This change avoid that owner types of static nested classes are returned as parameterized types.
>
> 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.

Marked as reviewed by jfranck (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/82

From pavel.rappo at oracle.com  Wed Jan  6 12:20:56 2021
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 6 Jan 2021 12:20:56 +0000
Subject: Monitoring wrapped ThreadPoolExecutor returned from Executors
In-Reply-To: <BYAPR05MB65998619D6784F8FB6E13700DFD00@BYAPR05MB6599.namprd05.prod.outlook.com>
References: <BYAPR05MB65998619D6784F8FB6E13700DFD00@BYAPR05MB6599.namprd05.prod.outlook.com>
Message-ID: <E919CA94-D009-4706-8181-582D408CCEDD@oracle.com>

Questions related to the contents of java.util.concurrent.** should generally be asked on the "Concurrency-interest" mailing list: http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

-Pavel

> On 6 Jan 2021, at 03:11, Tommy Ludwig <tludwig at vmware.com> wrote:
> 
> Hello,
> 
> In the Micrometer project, we provide metrics instrumentation of `ExectorService`s. For `ThreadPoolExecutor`s, we track the number of completed tasks, active tasks, thread pool sizes, task queue size and remaining capacity via methods from `ThreadPoolExecutor`. We are currently using a brittle reflection hack[1] to do this for the wrapped `ThreadPoolExecutor` returned from `Executors` methods `newSingleThreadExecutor` and `newSingleThreadScheduledExecutor`. With the introduction of JEP-396 in JDK 16, our reflection hack throws an InaccessibleObjectException by default.
> 
> I am not seeing a proper way to get at the methods we use for the metrics (e.g. `ThreadPoolExecutor::getCompletedTaskCount`) in this case. Is there a way that I am missing?
> 
> From the JavaDocs, the intention of the wrapping is to prevent changing the ThreadPool configuration. Our use case does not call for changing the thread pool configuration - we want to observe the ExecutorService (e.g. thread pool state) via getter methods for monitoring purposes.
> 
> Thanks,
> Tommy
> 
> [1] https://github.com/micrometer-metrics/micrometer/blob/25f120833f8b73e4bd7cf604831dfddf0112fe9c/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/jvm/ExecutorServiceMetrics.java#L272-L301
> 


From mcimadamore at openjdk.java.net  Wed Jan  6 12:22:12 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 6 Jan 2021 12:22:12 GMT
Subject: [jdk16] Integrated: 8259032:
 MappedMemorySegmentImpl#makeMappedSegment() ignores Unmapper#pagePosition
In-Reply-To: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
References: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
Message-ID: <5TOdOdUJT-N3v_rxpxtyGGt7ZKe1I2u_25kdJThuLXQ=.c4560205-c9dc-4673-a11a-bfb338fa25d5@github.com>

On Tue, 5 Jan 2021 15:33:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Hi,
> this patch fixes an oversight where the address() method in FileChannelImpl.Unmapper does not take into account the value of `pagePosition` - this leads to a situation in which, effectively, the specified offset when mapping the segment is ignored by the runtime (because base address will always be aligned to some known quantity - which is OS/platform dependent).
> 
> To test this I had to break open into FileChannelImpl and ready the granularity.

This pull request has now been integrated.

Changeset: e66187d8
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/e66187d8
Stats:     23 lines in 2 files changed: 22 ins; 0 del; 1 mod

8259032: MappedMemorySegmentImpl#makeMappedSegment() ignores Unmapper#pagePosition

Co-authored-by: Uwe Schindler <uschindler at openjdk.org>
Reviewed-by: alanb

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

PR: https://git.openjdk.java.net/jdk16/pull/84

From mcimadamore at openjdk.java.net  Wed Jan  6 12:22:11 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 6 Jan 2021 12:22:11 GMT
Subject: [jdk16] RFR: 8259032: MappedMemorySegmentImpl#makeMappedSegment()
 ignores Unmapper#pagePosition [v3]
In-Reply-To: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
References: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
Message-ID: <P7TguVL_o-BnwQh92jFcyJ4TZoZkSvnAdXj1AaTeydY=.3177ff16-447f-4245-9c44-20f9f0a7f2b9@github.com>

> Hi,
> this patch fixes an oversight where the address() method in FileChannelImpl.Unmapper does not take into account the value of `pagePosition` - this leads to a situation in which, effectively, the specified offset when mapping the segment is ignored by the runtime (because base address will always be aligned to some known quantity - which is OS/platform dependent).
> 
> To test this I had to break open into FileChannelImpl and ready the granularity.

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into 8259032_pagepos
 - Simplify test not to depend on implementation internals
 - Fix issue in Unmapper implementation not including `pagePosition` in address computation

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

Changes: https://git.openjdk.java.net/jdk16/pull/84/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=84&range=02
  Stats: 23 lines in 2 files changed: 22 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/84.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/84/head:pull/84

PR: https://git.openjdk.java.net/jdk16/pull/84

From jlaskey at openjdk.java.net  Wed Jan  6 14:28:35 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 6 Jan 2021 14:28:35 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v11]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <F1x3njRMDi0kkco1QRDau58i_X6Gi-6XHIieBHStPNE=.ddcaf4a9-4b9a-4b96-af12-99564bca3d55@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

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

 - Merge branch 'master' into 8248862
 - Use annotation for properties. Add getDefault().
 - Merge branch 'master' into 8248862
 - Introduce RandomGeneratorProperties annotation
 - Merge branch 'master' into 8248862
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Added coverage testing
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Cleanups from Chris H.
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Propagate exception
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Override AbstractSplittableGenerator
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Fix extends
 - ... and 28 more: https://git.openjdk.java.net/jdk/compare/7e01bc96...cb78fa11

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

Changes: https://git.openjdk.java.net/jdk/pull/1292/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=10
  Stats: 13205 lines in 26 files changed: 11043 ins; 2046 del; 116 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

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

From github.com+2996845+bokken at openjdk.java.net  Wed Jan  6 15:01:11 2021
From: github.com+2996845+bokken at openjdk.java.net (Brett Okken)
Date: Wed, 6 Jan 2021 15:01:11 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v9]
In-Reply-To: <1x-JXb6q5tPjvf2SZItze0r1etXGKnIPZ3wtORNMKro=.485a0405-bf2f-45d4-92a1-732f6f743b80@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <1x-JXb6q5tPjvf2SZItze0r1etXGKnIPZ3wtORNMKro=.485a0405-bf2f-45d4-92a1-732f6f743b80@github.com>
Message-ID: <mxtNYuA4SEzKtVCJ5-MjoDynROJZ4qhEIu_wNKLdAgs=.24d0d430-e317-4978-a60b-47e6e3b43355@github.com>

On Mon, 4 Jan 2021 19:52:18 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
>> 
>> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
>> 
>> old PR:  https://github.com/openjdk/jdk/pull/1273
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - Merge branch 'master' into 8248862
>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>    
>    Added coverage testing
>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>    
>    Cleanups from Chris H.
>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>    
>    Propagate exception
>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>    
>    Override AbstractSplittableGenerator
>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>    
>    Fix extends
>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>    
>    Use Map.of instead of Map.ofEntries
>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>    
>    Changes to RandomGeneratorFactory requested by @PaulSandoz
>  - Review changes
>    
>    @PaulSandoz and @rogermb
>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>    
>    Update package-info.java
>  - ... and 24 more: https://git.openjdk.java.net/jdk/compare/f80c63b3...e75cc844

src/java.base/share/classes/java/util/random/RandomGenerator.java line 439:

> 437:      * Fills a user-supplied byte array with generated byte values
> 438:      * (pseudo)randomly chosen uniformly from the range of values between -128
> 439:      * (inclusive) and 255 (inclusive).

Should this be
between -128 (inclusive) and **127** (inclusive)

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

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

From jlaskey at openjdk.java.net  Wed Jan  6 15:36:29 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 6 Jan 2021 15:36:29 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v9]
In-Reply-To: <mxtNYuA4SEzKtVCJ5-MjoDynROJZ4qhEIu_wNKLdAgs=.24d0d430-e317-4978-a60b-47e6e3b43355@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <1x-JXb6q5tPjvf2SZItze0r1etXGKnIPZ3wtORNMKro=.485a0405-bf2f-45d4-92a1-732f6f743b80@github.com>
 <mxtNYuA4SEzKtVCJ5-MjoDynROJZ4qhEIu_wNKLdAgs=.24d0d430-e317-4978-a60b-47e6e3b43355@github.com>
Message-ID: <rZSTG9XCGfdSq2jNqfKdmwxzP-CU8V3UTuT97_n2phs=.9fe00731-ccff-45a1-9677-07a1b6a35642@github.com>

On Tue, 5 Jan 2021 02:43:08 GMT, Brett Okken <github.com+2996845+bokken at openjdk.org> wrote:

>> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
>> 
>>  - Merge branch 'master' into 8248862
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Added coverage testing
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Cleanups from Chris H.
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Propagate exception
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Override AbstractSplittableGenerator
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Fix extends
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Use Map.of instead of Map.ofEntries
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Changes to RandomGeneratorFactory requested by @PaulSandoz
>>  - Review changes
>>    
>>    @PaulSandoz and @rogermb
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Update package-info.java
>>  - ... and 24 more: https://git.openjdk.java.net/jdk/compare/f80c63b3...e75cc844
>
> src/java.base/share/classes/java/util/random/RandomGenerator.java line 439:
> 
>> 437:      * Fills a user-supplied byte array with generated byte values
>> 438:      * (pseudo)randomly chosen uniformly from the range of values between -128
>> 439:      * (inclusive) and 255 (inclusive).
> 
> Should this be
> between -128 (inclusive) and **127** (inclusive)

Thanks. Will update.

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

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

From jlaskey at openjdk.java.net  Wed Jan  6 15:36:21 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 6 Jan 2021 15:36:21 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v12]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <Uw8EsJMeICzA3pJOK9-uPfspC2_wqeO7rVT9nTiykqU=.2c686a4a-ff34-4b93-bb42-ee94407aaffa@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Correct range used by nextBytes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/cb78fa11..f76fa7a7

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

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

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

From jlaskey at openjdk.java.net  Wed Jan  6 15:36:30 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 6 Jan 2021 15:36:30 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <UxV18zfx_-k4CyNP6q-2Hmc7Bt0yupu2SnmmVM5iUI0=.ebfae99d-3800-4684-9139-fbda7f211926@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
 <LRBogL2R7DxnUrcUem3ewE17aRuljl4UlEZS3dW7Mko=.d61114e3-2f10-469a-8cc4-5e8561d2e687@github.com>
 <XR2JLadsxF5N2joFIw8aUe0E6ngyje_AmYEWLX_Loss=.624e9180-4d9a-4196-984d-30134023f1bc@github.com>
 <UxV18zfx_-k4CyNP6q-2Hmc7Bt0yupu2SnmmVM5iUI0=.ebfae99d-3800-4684-9139-fbda7f211926@github.com>
Message-ID: <5RmKd5_sJoQ14BoS1NPzzhpjIHgIc0V3mjMlp1VG2Ek=.9cb2989d-b0a5-4696-b847-197e1d4afc5b@github.com>

On Wed, 6 Jan 2021 15:31:32 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> I kind of like the idea - not sure how expressive a BigInteger string is though. I might be able to express as <i, j, k>  BigInteger.ONE.shiftLeft(i).subtract(j).shiftLeft(k). Will ponder.
>
> Done

Also added getDefault and getDefaultFactory to RandomGenerato.

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

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

From jlaskey at openjdk.java.net  Wed Jan  6 15:36:30 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 6 Jan 2021 15:36:30 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <XR2JLadsxF5N2joFIw8aUe0E6ngyje_AmYEWLX_Loss=.624e9180-4d9a-4196-984d-30134023f1bc@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
 <LRBogL2R7DxnUrcUem3ewE17aRuljl4UlEZS3dW7Mko=.d61114e3-2f10-469a-8cc4-5e8561d2e687@github.com>
 <XR2JLadsxF5N2joFIw8aUe0E6ngyje_AmYEWLX_Loss=.624e9180-4d9a-4196-984d-30134023f1bc@github.com>
Message-ID: <UxV18zfx_-k4CyNP6q-2Hmc7Bt0yupu2SnmmVM5iUI0=.ebfae99d-3800-4684-9139-fbda7f211926@github.com>

On Thu, 26 Nov 2020 15:41:16 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 46:
>> 
>>> 44: import java.util.stream.Stream;
>>> 45: import jdk.internal.util.random.RandomSupport.RandomGeneratorProperty;
>>> 46: 
>> 
>> Instead of calling a method properties to create a Map, it's usually far easier to use an annotation,
>> annotation values supports less runtime type so BigInteger is not supported but using a String instead should be OK.
>
> I kind of like the idea - not sure how expressive a BigInteger string is though. I might be able to express as <i, j, k>  BigInteger.ONE.shiftLeft(i).subtract(j).shiftLeft(k). Will ponder.

Done

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

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

From github.com+2996845+bokken at openjdk.java.net  Wed Jan  6 15:40:02 2021
From: github.com+2996845+bokken at openjdk.java.net (Brett Okken)
Date: Wed, 6 Jan 2021 15:40:02 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <TTJDYGNjz8D1miykGB3imf4k_Hm2W_nWLRA4HfDpImQ=.a4715d2d-d5ed-4d29-985d-ab28a056f9ce@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
 <TTJDYGNjz8D1miykGB3imf4k_Hm2W_nWLRA4HfDpImQ=.a4715d2d-d5ed-4d29-985d-ab28a056f9ce@github.com>
Message-ID: <bC6L2Phcq6NYbKwlO0CD5GNmGe28IHHTBRaNVyx6ZN0=.a1a4537d-46d5-40db-a643-5b42945ba492@github.com>

On Wed, 25 Nov 2020 14:07:04 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8248862: Implement Enhanced Pseudo-Random Number Generators
>>   
>>   Changes to RandomGeneratorFactory requested by @PaulSandoz
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 335:
> 
>> 333:                         ctorBytes = tmpCtorBytes;
>> 334:                         ctorLong = tmpCtorLong;
>> 335:                         ctor = tmpCtor;
> 
> This one is a volatile write, so the idea is that ctorBytes and ctorLong does not need to be volatile too, which i think is not true if there is a code somewhere that uses ctorBytes or ctorLong without reading ctor.
> This code is too smart for me, i'm pretty sure it is wrong too on non TSO cpu.

The 2 uses call ensureConstructors, which calls this method, which reads ctor.
The memory model guarantees this to be safe, even on non tso hardware.
https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#pitfall-avoiding

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

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

From mbalao at openjdk.java.net  Wed Jan  6 15:40:10 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Wed, 6 Jan 2021 15:40:10 GMT
Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's
 classes
Message-ID: <u0MKmmnw4k2MnkDD-a26NsLCRk1NEtbf9MY4MHSPa6Y=.9d02a25d-9eb8-4ed2-88c8-9d239be0f7df@github.com>

As described in JDK-8259319 [1], this fix proposal is to set proper access permissions so the SunPKCS11 provider can create instances of SunJCE classes when a Security Manager is installed and the fallback scheme is used.

No regressions found in jdk/sun/security/pkcs11 tests category.

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8259319

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

Commit messages:
 - 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes

Changes: https://git.openjdk.java.net/jdk/pull/1961/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1961&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259319
  Stats: 115 lines in 4 files changed: 105 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1961.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1961/head:pull/1961

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

From winterhalter at openjdk.java.net  Wed Jan  6 15:50:00 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Wed, 6 Jan 2021 15:50:00 GMT
Subject: [jdk16] Integrated: 8259224: (ann) getAnnotatedReceiverType should
 not parameterize owner(s) of statically nested classes
In-Reply-To: <3PDkIdfiG84iX79Edt8NPtylPIGrxWDGaH8kJR-278w=.de5791f1-ba08-4fcc-98d1-2e79ef5edfda@github.com>
References: <3PDkIdfiG84iX79Edt8NPtylPIGrxWDGaH8kJR-278w=.de5791f1-ba08-4fcc-98d1-2e79ef5edfda@github.com>
Message-ID: <7zpLZTwGJ8CTw5SnnM-6sn8C350VCizU3IL-mWCRguE=.c73d00f9-2c7e-47f5-936c-d6b3fd336199@github.com>

On Tue, 5 Jan 2021 12:03:43 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> This change avoid that owner types of static nested classes are returned as parameterized types.

This pull request has now been integrated.

Changeset: d25a1bed
Author:    Rafael Winterhalter <winterhalter at openjdk.org>
Committer: Joel Borggr?n-Franck <jfranck at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/d25a1bed
Stats:     70 lines in 2 files changed: 69 ins; 0 del; 1 mod

8259224: (ann) getAnnotatedReceiverType should not parameterize owner(s) of statically nested classes

Reviewed-by: jfranck

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

PR: https://git.openjdk.java.net/jdk16/pull/82

From github.com+2996845+bokken at openjdk.java.net  Wed Jan  6 16:11:59 2021
From: github.com+2996845+bokken at openjdk.java.net (Brett Okken)
Date: Wed, 6 Jan 2021 16:11:59 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v12]
In-Reply-To: <Uw8EsJMeICzA3pJOK9-uPfspC2_wqeO7rVT9nTiykqU=.2c686a4a-ff34-4b93-bb42-ee94407aaffa@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <Uw8EsJMeICzA3pJOK9-uPfspC2_wqeO7rVT9nTiykqU=.2c686a4a-ff34-4b93-bb42-ee94407aaffa@github.com>
Message-ID: <6iRrJ5Qqo2vCFuoIwtJo-rw1ktpixHmFtc95cRE88Kc=.58e3cb3f-ea4b-49da-804b-a4a5fe0b1a6a@github.com>

On Wed, 6 Jan 2021 15:36:21 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
>> 
>> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
>> 
>> old PR:  https://github.com/openjdk/jdk/pull/1273
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct range used by nextBytes

src/java.base/share/classes/java/util/random/RandomGenerator.java line 147:

> 145:      *
> 146:      * @implNote  Since algorithms will improve over time, there is no
> 147:      * guarantee that this method will return the same algorithm each time.

is there a guarantee that within a running jvm each invocation will return the same algorithm?

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

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

From mcimadamore at openjdk.java.net  Wed Jan  6 16:16:07 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 6 Jan 2021 16:16:07 GMT
Subject: [jdk16] RFR: 8259028: ClassCastException when using custom filesystem
 with wrapper FileChannel impl
Message-ID: <RXdR008wzVvkTM5LjK2tptKRknWJnGI9vuxJev-RYbA=.9ffabb2a-2c0c-4e6f-b871-91ccb25038bb@github.com>

This patch tweaks `MemorySegment::mapFile` so that it will throw `IllegalArgumentException` whenever the path to be mapped is associated with a custom file system provider.

The check in the implementation is heavily borrowed by what `UnixDomainSocketAddress::of(Path)` does (thanks Alan for the tip!). Not only we have to check if file system is the default one, but also if the default FS belongs to java.base (since that can be overridden).

The test simply check that paths coming from the (internal) JRT file system are not supported by the factory.

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

Commit messages:
 - Tweak javadoc
 - Clarify javadoc of MemorySegment::mapFile w.r.t. custom file systems

Changes: https://git.openjdk.java.net/jdk16/pull/90/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=90&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259028
  Stats: 22 lines in 3 files changed: 16 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/90.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/90/head:pull/90

PR: https://git.openjdk.java.net/jdk16/pull/90

From mcimadamore at openjdk.java.net  Wed Jan  6 16:16:07 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 6 Jan 2021 16:16:07 GMT
Subject: [jdk16] RFR: 8259028: ClassCastException when using custom
 filesystem with wrapper FileChannel impl
In-Reply-To: <RXdR008wzVvkTM5LjK2tptKRknWJnGI9vuxJev-RYbA=.9ffabb2a-2c0c-4e6f-b871-91ccb25038bb@github.com>
References: <RXdR008wzVvkTM5LjK2tptKRknWJnGI9vuxJev-RYbA=.9ffabb2a-2c0c-4e6f-b871-91ccb25038bb@github.com>
Message-ID: <EYUD5crkg4Az7RagZxqIbBKcK6j_GOO_a3vroJJWcSw=.342d8826-7c8a-485d-959e-5b70b550317b@github.com>

On Wed, 6 Jan 2021 16:10:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch tweaks `MemorySegment::mapFile` so that it will throw `IllegalArgumentException` whenever the path to be mapped is associated with a custom file system provider.
> 
> The check in the implementation is heavily borrowed by what `UnixDomainSocketAddress::of(Path)` does (thanks Alan for the tip!). Not only we have to check if file system is the default one, but also if the default FS belongs to java.base (since that can be overridden).
> 
> The test simply check that paths coming from the (internal) JRT file system are not supported by the factory.

CSR: https://bugs.openjdk.java.net/browse/JDK-8259321

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

PR: https://git.openjdk.java.net/jdk16/pull/90

From github.com+34924738+mahendrachhipa at openjdk.java.net  Wed Jan  6 16:26:10 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Wed, 6 Jan 2021 16:26:10 GMT
Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with
 jaxp.library.SimpleHttpServer [v6]
In-Reply-To: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
References: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
Message-ID: <isR-HAF6xahbZLAGrIwyyStcQWtrOml8EXg3cFEIngc=.cbe23f3b-21a3-4028-8278-a153dbbb03d1@github.com>

> jaxp.library.SimpleHttpServer
> https://bugs.openjdk.java.net/browse/JDK-8212035

Mahendra Chhipa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Implemented the review comments
 - Merge branch 'master' into JDK-8212035
 - Implemented the Review comments.
 - Implemented the review comments
 - Merge branch 'JDK-8212035' of https://github.com/mahendrachhipa/jdk into JDK-8212035
 - Implemnted the review comments.
 - Implemnted the review comments.
 - Implemented the review comments.
 - JDK-8212035 merge jdk.test.lib.util.SimpleHttpServer with
   jaxp.library.SimpleHttpServer
   https://bugs.openjdk.java.net/browse/JDK-8212035

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

Changes: https://git.openjdk.java.net/jdk/pull/1632/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1632&range=05
  Stats: 651 lines in 17 files changed: 227 ins; 321 del; 103 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1632.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1632/head:pull/1632

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

From jlaskey at openjdk.java.net  Wed Jan  6 16:28:58 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 6 Jan 2021 16:28:58 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v12]
In-Reply-To: <6iRrJ5Qqo2vCFuoIwtJo-rw1ktpixHmFtc95cRE88Kc=.58e3cb3f-ea4b-49da-804b-a4a5fe0b1a6a@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <Uw8EsJMeICzA3pJOK9-uPfspC2_wqeO7rVT9nTiykqU=.2c686a4a-ff34-4b93-bb42-ee94407aaffa@github.com>
 <6iRrJ5Qqo2vCFuoIwtJo-rw1ktpixHmFtc95cRE88Kc=.58e3cb3f-ea4b-49da-804b-a4a5fe0b1a6a@github.com>
Message-ID: <Pb7uhXgbPHSrYNLwhzMc0QnGUHTHyyUpmV_ZkBTHWCg=.b4b7e68d-0418-4433-a988-18520081eb32@github.com>

On Wed, 6 Jan 2021 16:09:25 GMT, Brett Okken <github.com+2996845+bokken at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct range used by nextBytes
>
> src/java.base/share/classes/java/util/random/RandomGenerator.java line 147:
> 
>> 145:      *
>> 146:      * @implNote  Since algorithms will improve over time, there is no
>> 147:      * guarantee that this method will return the same algorithm each time.
> 
> is there a guarantee that within a running jvm each invocation will return the same algorithm?

In practice terms yes. The point is that the user should not assume they will be getting the same algorithm each time.

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

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

From mcimadamore at openjdk.java.net  Wed Jan  6 16:32:17 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 6 Jan 2021 16:32:17 GMT
Subject: [jdk16] RFR: 8259028: ClassCastException when using custom
 filesystem with wrapper FileChannel impl [v2]
In-Reply-To: <RXdR008wzVvkTM5LjK2tptKRknWJnGI9vuxJev-RYbA=.9ffabb2a-2c0c-4e6f-b871-91ccb25038bb@github.com>
References: <RXdR008wzVvkTM5LjK2tptKRknWJnGI9vuxJev-RYbA=.9ffabb2a-2c0c-4e6f-b871-91ccb25038bb@github.com>
Message-ID: <6kEvoDM0enXAF41uAkBlTDg_aB8NU_xMkHFnz_w3Ub8=.2be73ef8-0490-4c4d-9814-9b32e8a3f516@github.com>

> This patch tweaks `MemorySegment::mapFile` so that it will throw `IllegalArgumentException` whenever the path to be mapped is associated with a custom file system provider.
> 
> The check in the implementation is heavily borrowed by what `UnixDomainSocketAddress::of(Path)` does (thanks Alan for the tip!). Not only we have to check if file system is the default one, but also if the default FS belongs to java.base (since that can be overridden).
> 
> The test simply check that paths coming from the (internal) JRT file system are not supported by the factory.

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

  Simplify test not to depend on JDK internals

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/90/files
  - new: https://git.openjdk.java.net/jdk16/pull/90/files/4ff84b5b..aaea5ece

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

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

PR: https://git.openjdk.java.net/jdk16/pull/90

From naoto at openjdk.java.net  Wed Jan  6 16:33:59 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 6 Jan 2021 16:33:59 GMT
Subject: [jdk16] Integrated: 8259075: Update the copyright notice in the files
 generated by CLDR Converter tool
In-Reply-To: <XXdFf3N8oQz8g9ptH0wZubHk6v_qRD8y9szU92NBc6k=.e6a3e1ca-817a-4c0d-9be1-f871c38c92a4@github.com>
References: <XXdFf3N8oQz8g9ptH0wZubHk6v_qRD8y9szU92NBc6k=.e6a3e1ca-817a-4c0d-9be1-f871c38c92a4@github.com>
Message-ID: <T5IDzp5L8Zw88mwnnwsbNc643gsO4-6ystOPrfg0o3U=.ba3d7faf-f2f8-4ccf-b486-07fb21baffe0@github.com>

On Tue, 5 Jan 2021 17:59:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this copyright notice update in the CLDR Converter tool. It is now synched with src/java.base/share/legal/cldr.md file.

This pull request has now been integrated.

Changeset: 4a5786b5
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/4a5786b5
Stats:     13 lines in 1 file changed: 0 ins; 4 del; 9 mod

8259075: Update the copyright notice in the files generated by CLDR Converter tool

Reviewed-by: joehw

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

PR: https://git.openjdk.java.net/jdk16/pull/85

From chegar at openjdk.java.net  Wed Jan  6 16:38:59 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 6 Jan 2021 16:38:59 GMT
Subject: [jdk16] RFR: 8259028: ClassCastException when using custom
 filesystem with wrapper FileChannel impl [v2]
In-Reply-To: <6kEvoDM0enXAF41uAkBlTDg_aB8NU_xMkHFnz_w3Ub8=.2be73ef8-0490-4c4d-9814-9b32e8a3f516@github.com>
References: <RXdR008wzVvkTM5LjK2tptKRknWJnGI9vuxJev-RYbA=.9ffabb2a-2c0c-4e6f-b871-91ccb25038bb@github.com>
 <6kEvoDM0enXAF41uAkBlTDg_aB8NU_xMkHFnz_w3Ub8=.2be73ef8-0490-4c4d-9814-9b32e8a3f516@github.com>
Message-ID: <CMncf77ar6nUr2T0C37-u-4Kr7NhOhMv_mpw1xSjHZY=.86479579-5e52-4126-aae7-40386e1c506b@github.com>

On Wed, 6 Jan 2021 16:32:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch tweaks `MemorySegment::mapFile` so that it will throw `IllegalArgumentException` whenever the path to be mapped is associated with a custom file system provider.
>> 
>> The check in the implementation is heavily borrowed by what `UnixDomainSocketAddress::of(Path)` does (thanks Alan for the tip!). Not only we have to check if file system is the default one, but also if the default FS belongs to java.base (since that can be overridden).
>> 
>> The test simply check that paths coming from the (internal) JRT file system are not supported by the factory.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify test not to depend on JDK internals

Marked as reviewed by chegar (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/90

From alanb at openjdk.java.net  Wed Jan  6 16:44:01 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 6 Jan 2021 16:44:01 GMT
Subject: [jdk16] RFR: 8259028: ClassCastException when using custom
 filesystem with wrapper FileChannel impl [v2]
In-Reply-To: <6kEvoDM0enXAF41uAkBlTDg_aB8NU_xMkHFnz_w3Ub8=.2be73ef8-0490-4c4d-9814-9b32e8a3f516@github.com>
References: <RXdR008wzVvkTM5LjK2tptKRknWJnGI9vuxJev-RYbA=.9ffabb2a-2c0c-4e6f-b871-91ccb25038bb@github.com>
 <6kEvoDM0enXAF41uAkBlTDg_aB8NU_xMkHFnz_w3Ub8=.2be73ef8-0490-4c4d-9814-9b32e8a3f516@github.com>
Message-ID: <4MpXIAqwMCRhQ_HLx42Qq3CyOF2QBEKY4DB-Mzgv56E=.4c528377-ac54-4bc3-935c-63d3b10a16ac@github.com>

On Wed, 6 Jan 2021 16:32:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch tweaks `MemorySegment::mapFile` so that it will throw `IllegalArgumentException` whenever the path to be mapped is associated with a custom file system provider.
>> 
>> The check in the implementation is heavily borrowed by what `UnixDomainSocketAddress::of(Path)` does (thanks Alan for the tip!). Not only we have to check if file system is the default one, but also if the default FS belongs to java.base (since that can be overridden).
>> 
>> The test simply check that paths coming from the (internal) JRT file system are not supported by the factory.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify test not to depend on JDK internals

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/90

From uschindler at openjdk.java.net  Wed Jan  6 17:54:10 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Wed, 6 Jan 2021 17:54:10 GMT
Subject: [jdk16] RFR: 8259028: ClassCastException when using custom
 filesystem with wrapper FileChannel impl [v2]
In-Reply-To: <6kEvoDM0enXAF41uAkBlTDg_aB8NU_xMkHFnz_w3Ub8=.2be73ef8-0490-4c4d-9814-9b32e8a3f516@github.com>
References: <RXdR008wzVvkTM5LjK2tptKRknWJnGI9vuxJev-RYbA=.9ffabb2a-2c0c-4e6f-b871-91ccb25038bb@github.com>
 <6kEvoDM0enXAF41uAkBlTDg_aB8NU_xMkHFnz_w3Ub8=.2be73ef8-0490-4c4d-9814-9b32e8a3f516@github.com>
Message-ID: <upQjt_jxZbfMtUb_oyf4k30bI18zYITGL3JPgIwwo9A=.eb5f996a-d83d-4a3e-bea3-b0a75b3737a1@github.com>

On Wed, 6 Jan 2021 16:32:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch tweaks `MemorySegment::mapFile` so that it will throw `IllegalArgumentException` whenever the path to be mapped is associated with a custom file system provider.
>> 
>> The check in the implementation is heavily borrowed by what `UnixDomainSocketAddress::of(Path)` does (thanks Alan for the tip!). Not only we have to check if file system is the default one, but also if the default FS belongs to java.base (since that can be overridden).
>> 
>> The test simply check that paths coming from the (internal) JRT file system are not supported by the factory.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify test not to depend on JDK internals

Looks fine to me.

Another option would have been to just check the class with instanceof. If the FileChannel returned by the path's filesystem has wrong type, it won't work. If we have some custom filesystem that just returns the original FileChannelImpl but does some additional checks before or after (e.g to hide some files from user), this would still work.

But I think it's better to be clear here and deny anything which is not default operating system filesystem, until we have a better solution.

In Lucene I added some hack that removes our test-only filesystem wrappers from the path. I will later go the route to mark those path instances with some interface Unwrappable that provides a method unwrap().

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

Marked as reviewed by uschindler (Author).

PR: https://git.openjdk.java.net/jdk16/pull/90

From mcimadamore at openjdk.java.net  Wed Jan  6 17:57:59 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 6 Jan 2021 17:57:59 GMT
Subject: [jdk16] RFR: 8259028: ClassCastException when using custom
 filesystem with wrapper FileChannel impl [v2]
In-Reply-To: <upQjt_jxZbfMtUb_oyf4k30bI18zYITGL3JPgIwwo9A=.eb5f996a-d83d-4a3e-bea3-b0a75b3737a1@github.com>
References: <RXdR008wzVvkTM5LjK2tptKRknWJnGI9vuxJev-RYbA=.9ffabb2a-2c0c-4e6f-b871-91ccb25038bb@github.com>
 <6kEvoDM0enXAF41uAkBlTDg_aB8NU_xMkHFnz_w3Ub8=.2be73ef8-0490-4c4d-9814-9b32e8a3f516@github.com>
 <upQjt_jxZbfMtUb_oyf4k30bI18zYITGL3JPgIwwo9A=.eb5f996a-d83d-4a3e-bea3-b0a75b3737a1@github.com>
Message-ID: <1wYVQA6IH7zXqy5ms9TjlvCUcqFn7bRdPWeL_E2I_ik=.2e5034c1-54c7-4dda-a7d3-4a12953a56e1@github.com>

On Wed, 6 Jan 2021 17:51:20 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

> Another option would have been to just check the class with instanceof. If the FileChannel returned by the path's filesystem has wrong type, it won't work. If we have some custom filesystem that just returns the original FileChannelImpl but does some additional checks before or after (e.g to hide some files from user), this would still work.

We considered this - but we opted for better clarity and alignment with existing APIs.

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

PR: https://git.openjdk.java.net/jdk16/pull/90

From dl at cs.oswego.edu  Thu Jan  7 13:09:27 2021
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 7 Jan 2021 08:09:27 -0500
Subject: Monitoring wrapped ThreadPoolExecutor returned from Executors
In-Reply-To: <BYAPR05MB65998619D6784F8FB6E13700DFD00@BYAPR05MB6599.namprd05.prod.outlook.com>
References: <BYAPR05MB65998619D6784F8FB6E13700DFD00@BYAPR05MB6599.namprd05.prod.outlook.com>
Message-ID: <fa7f2656-c249-688f-5215-626a2250b22c@cs.oswego.edu>

On 1/5/21 10:11 PM, Tommy Ludwig wrote:
> In the Micrometer project, we provide metrics instrumentation of `ExectorService`s. For `ThreadPoolExecutor`s, we track the number of completed tasks, active tasks, thread pool sizes, task queue size and remaining capacity via methods from `ThreadPoolExecutor`. We are currently using a brittle reflection hack[1] to do this for the wrapped `ThreadPoolExecutor` returned from `Executors` methods `newSingleThreadExecutor` and `newSingleThreadScheduledExecutor`. With the introduction of JEP-396 in JDK 16, our reflection hack throws an InaccessibleObjectException by default.
>
> I am not seeing a proper way to get at the methods we use for the metrics (e.g. `ThreadPoolExecutor::getCompletedTaskCount`) in this case. Is there a way that I am missing?

There's no guarantee that newSingleThreadExecutor returns a restricted 
view of a ThreadPoolExecutor, so there can't be a guaranteed way of 
accessing it,

But I'm sympathetic to the idea that under the current implementation 
(which is unlikely to change anytime soon), the stats are available, and 
should be available to monitoring tools. But none of the ways to do this 
are very attractive: Creating a MonitorableExecutorService interface and 
returning that? Making the internal view class public with a protected 
getExecutor method?



From plevart at openjdk.java.net  Thu Jan  7 16:42:56 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Thu, 7 Jan 2021 16:42:56 GMT
Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached
In-Reply-To: <zGhr7ogSfH81CE_7Jcq1ukbTc1LKnYQyYqKmjr8SF7E=.d3dd2cf9-86de-41f6-ad47-80b6758f2a52@github.com>
References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com>
 <RfY50ivUIozAD5-LocBW86nZG9awy4kNgGlSI3AKBH0=.8db0797b-32dd-4b1f-aad8-8921d8f37d2d@github.com>
 <EzYmzka4PzZcK7NAjq-Mw2W75Ld8Q4tDO6-9lR2HaVo=.da56add3-9039-4427-95e3-e3416a6500eb@github.com>
 <u_U1igoAzasYgZSA8ssJa2a9ShTlw_1NlzAKLu7KCSo=.a2624e81-45f1-49d6-86de-fbc3c9d63357@github.com>
 <zw4zpLGloGNrMzkXqEg1i5SQoNcdBBe6jkImTG-z8-M=.d787766a-2527-4f11-8db8-288ef18494be@github.com>
 <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com>
 <sKf-QKlrAEPFA2pKi1REBGEIOuv6xKtOFutCjSvPWwE=.86717b36-5b10-4903-aa2c-96c43bef1c1e@github.com>
 <i4bNHquF1lkB097yvKvMk_BCBDFcMYxHJBwZs1O__IE=.e2362c4a-b500-4b28-9668-0ac6741417f5@github.com>
 <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com>
 <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com>
 <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQ
 WBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com>
 <zGhr7ogSfH81CE_7Jcq1ukbTc1LKnYQyYqKmjr8SF7E=.d3dd2cf9-86de-41f6-ad47-80b6758f2a52@github.com>
Message-ID: <mQAzW0_kvVhM9UUvp7hHMbKprUvyzC5CtD29m_KsMvA=.38270a5a-ebf5-40d6-add8-19fa762c9f67@github.com>

On Sun, 20 Dec 2020 22:41:33 GMT, PROgrm_JARvis <github.com+7693005+JarvisCraft at openjdk.org> wrote:

>>> I have to say that introducing a ThreadLocal here seems like a step in the wrong direction. With a ThreadLocal, if I read this correctly, a MessageDigest will be cached with each thread that ever calls this API, and it won't be garbage collected until the thread dies. Some threads live indefinitely, e.g., the ones in the fork-join common pool. Is this what we want? Is UUID creation so frequent that each thread needs its own, or could thread safety be handled using a simple locking protocol?
>> 
>> This is a good point. Significant effort has gone into recent releases to reduce the use of TLs in the (JDK-8245309, JDK-8245308, JDK-8245304, JDK-8245302) so adding new usages is a disappointing. So I think this PR does need good justifications, and probably a lot more exploration of options.
>
>> I have to say that introducing a ThreadLocal here seems like a step in the wrong direction. With a ThreadLocal, if I read this correctly, a MessageDigest will be cached with each thread that ever calls this API, and it won't be garbage collected until the thread dies. Some threads live indefinitely, e.g., the ones in the fork-join common pool. Is this what we want? Is UUID creation so frequent that each thread needs its own, or could thread safety be handled using a simple locking protocol?
> 
> Fair enough; the solution proposed by Claes in #1855 seems to be a better alternative.
> 
> Currently, I will keep this PR open but I expect this to be superseded by the latter.

Hi Claes,
Would flattening the state of MD5 bring any further improvements?
https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083

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

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

From redestad at openjdk.java.net  Thu Jan  7 17:12:00 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 7 Jan 2021 17:12:00 GMT
Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached
In-Reply-To: <mQAzW0_kvVhM9UUvp7hHMbKprUvyzC5CtD29m_KsMvA=.38270a5a-ebf5-40d6-add8-19fa762c9f67@github.com>
References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com>
 <RfY50ivUIozAD5-LocBW86nZG9awy4kNgGlSI3AKBH0=.8db0797b-32dd-4b1f-aad8-8921d8f37d2d@github.com>
 <EzYmzka4PzZcK7NAjq-Mw2W75Ld8Q4tDO6-9lR2HaVo=.da56add3-9039-4427-95e3-e3416a6500eb@github.com>
 <u_U1igoAzasYgZSA8ssJa2a9ShTlw_1NlzAKLu7KCSo=.a2624e81-45f1-49d6-86de-fbc3c9d63357@github.com>
 <zw4zpLGloGNrMzkXqEg1i5SQoNcdBBe6jkImTG-z8-M=.d787766a-2527-4f11-8db8-288ef18494be@github.com>
 <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com>
 <sKf-QKlrAEPFA2pKi1REBGEIOuv6xKtOFutCjSvPWwE=.86717b36-5b10-4903-aa2c-96c43bef1c1e@github.com>
 <i4bNHquF1lkB097yvKvMk_BCBDFcMYxHJBwZs1O__IE=.e2362c4a-b500-4b28-9668-0ac6741417f5@github.com>
 <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com>
 <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com>
 <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQ
 WBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com>
 <zGhr7ogSfH81CE_7Jcq1ukbTc1LKnYQyYqKmjr8SF7E=.d3dd2cf9-86de-41f6-ad47-80b6758f2a52@github.com>
 <mQAzW0_kvVhM9UUvp7hHMbKprUvyzC5CtD29m_KsMvA=.38270a5a-ebf5-40d6-add8-19fa762c9f67@github.com>
Message-ID: <C6jNl_P0GW_WeMkTTEmeg-0VqvMm1pzdMb2rb5CgcQY=.03ef0191-d470-49f5-958c-4563dd3ab5b0@github.com>

On Thu, 7 Jan 2021 16:39:48 GMT, Peter Levart <plevart at openjdk.org> wrote:

>>> I have to say that introducing a ThreadLocal here seems like a step in the wrong direction. With a ThreadLocal, if I read this correctly, a MessageDigest will be cached with each thread that ever calls this API, and it won't be garbage collected until the thread dies. Some threads live indefinitely, e.g., the ones in the fork-join common pool. Is this what we want? Is UUID creation so frequent that each thread needs its own, or could thread safety be handled using a simple locking protocol?
>> 
>> Fair enough; the solution proposed by Claes in #1855 seems to be a better alternative.
>> 
>> Currently, I will keep this PR open but I expect this to be superseded by the latter.
>
> Hi Claes,
> Would flattening the state of MD5 bring any further improvements?
> https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083

> Hi Claes,
> Would flattening the state of MD5 bring any further improvements?
> [plevart at 92bf48f](https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083)

I think it might, marginally, but it seemed to me that the implCompress0 MD5 intrinsic is using `state` so I've not tried that yet since rewriting and checking the intrinsic code is a lot of work. (I've blogged about my experiments in this area and mentioned this issue in passing: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#accidental-constraints)

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

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

From jason_mehrens at hotmail.com  Thu Jan  7 17:57:41 2021
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Thu, 7 Jan 2021 17:57:41 +0000
Subject: Monitoring wrapped ThreadPoolExecutor returned from Executors
In-Reply-To: <fa7f2656-c249-688f-5215-626a2250b22c@cs.oswego.edu>
References: <BYAPR05MB65998619D6784F8FB6E13700DFD00@BYAPR05MB6599.namprd05.prod.outlook.com>,
 <fa7f2656-c249-688f-5215-626a2250b22c@cs.oswego.edu>
Message-ID: <SN7PR18MB40165BE278DEA37BB110363483AF9@SN7PR18MB4016.namprd18.prod.outlook.com>

Hi Doug,

What are your thoughts on promoting monitoring methods from TPE and or FJP to AbstractExecutorService?  The default implementations could just return -1.  An example precedent is OperatingSystemMXBean::getSystemLoadAverage.  The Executors.DelegatedExecutorService could then be modified to extend AbstractExecutorService and forward the new methods and the existing AES::taskFor calls when the wrapped Executor is also an AbstractExecutorService.  The return types of the Executors.newXXX would remain the same.

I suppose the tradeoff is that adding any new default method to ExecutorService and or new methods to AbstractExecutorService could break 3rd party code.

Jason

________________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of Doug Lea <dl at cs.oswego.edu>
Sent: Thursday, January 7, 2021 7:09 AM
To: core-libs-dev at openjdk.java.net
Subject: Re: Monitoring wrapped ThreadPoolExecutor returned from Executors

On 1/5/21 10:11 PM, Tommy Ludwig wrote:
> In the Micrometer project, we provide metrics instrumentation of `ExectorService`s. For `ThreadPoolExecutor`s, we track the number of completed tasks, active tasks, thread pool sizes, task queue size and remaining capacity via methods from `ThreadPoolExecutor`. We are currently using a brittle reflection hack[1] to do this for the wrapped `ThreadPoolExecutor` returned from `Executors` methods `newSingleThreadExecutor` and `newSingleThreadScheduledExecutor`. With the introduction of JEP-396 in JDK 16, our reflection hack throws an InaccessibleObjectException by default.
>
> I am not seeing a proper way to get at the methods we use for the metrics (e.g. `ThreadPoolExecutor::getCompletedTaskCount`) in this case. Is there a way that I am missing?

There's no guarantee that newSingleThreadExecutor returns a restricted
view of a ThreadPoolExecutor, so there can't be a guaranteed way of
accessing it,

But I'm sympathetic to the idea that under the current implementation
(which is unlikely to change anytime soon), the stats are available, and
should be available to monitoring tools. But none of the ways to do this
are very attractive: Creating a MonitorableExecutorService interface and
returning that? Making the internal view class public with a protected
getExecutor method?



From rhalade at openjdk.java.net  Thu Jan  7 18:33:07 2021
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Thu, 7 Jan 2021 18:33:07 GMT
Subject: RFR: 8039278: console.sh failed Automatically with exit code 1
Message-ID: <8YBfbRvm-51IsoLpP1TAJuaZyBC0P4Ja_qOCyvMep48=.004d5b1c-85a8-4af1-b6c6-bd7dd8b62a2c@github.com>

8039278: console.sh failed Automatically with exit code 1

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

Commit messages:
 - 8039278: update TEST.groups to remove console.sh
 - 8039278: console.sh failed Automatically with exit code 1

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

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

From weijun at openjdk.java.net  Thu Jan  7 18:50:56 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 7 Jan 2021 18:50:56 GMT
Subject: RFR: 8039278: console.sh failed Automatically with exit code 1
In-Reply-To: <8YBfbRvm-51IsoLpP1TAJuaZyBC0P4Ja_qOCyvMep48=.004d5b1c-85a8-4af1-b6c6-bd7dd8b62a2c@github.com>
References: <8YBfbRvm-51IsoLpP1TAJuaZyBC0P4Ja_qOCyvMep48=.004d5b1c-85a8-4af1-b6c6-bd7dd8b62a2c@github.com>
Message-ID: <JF3LYrNASyuKZr4l_mHhJFUElaGmHU00ra41PNpweQM=.ca437aff-b009-4cf9-923d-f47d936fb6b5@github.com>

On Thu, 7 Jan 2021 18:26:12 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> 8039278: console.sh failed Automatically with exit code 1

Marked as reviewed by weijun (Reviewer).

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

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

From xuelei at openjdk.java.net  Thu Jan  7 18:50:56 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 7 Jan 2021 18:50:56 GMT
Subject: RFR: 8039278: console.sh failed Automatically with exit code 1
In-Reply-To: <8YBfbRvm-51IsoLpP1TAJuaZyBC0P4Ja_qOCyvMep48=.004d5b1c-85a8-4af1-b6c6-bd7dd8b62a2c@github.com>
References: <8YBfbRvm-51IsoLpP1TAJuaZyBC0P4Ja_qOCyvMep48=.004d5b1c-85a8-4af1-b6c6-bd7dd8b62a2c@github.com>
Message-ID: <AYbfTRFZmlljkrZsWwxQM2fsa94xFVWihKQIxwXYs1s=.f35fe056-6646-484b-89d7-1a4c0a09d82f@github.com>

On Thu, 7 Jan 2021 18:26:12 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> 8039278: console.sh failed Automatically with exit code 1

Marked as reviewed by xuelei (Reviewer).

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

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

From rhalade at openjdk.java.net  Thu Jan  7 18:50:57 2021
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Thu, 7 Jan 2021 18:50:57 GMT
Subject: Integrated: 8039278: console.sh failed Automatically with exit code 1
In-Reply-To: <8YBfbRvm-51IsoLpP1TAJuaZyBC0P4Ja_qOCyvMep48=.004d5b1c-85a8-4af1-b6c6-bd7dd8b62a2c@github.com>
References: <8YBfbRvm-51IsoLpP1TAJuaZyBC0P4Ja_qOCyvMep48=.004d5b1c-85a8-4af1-b6c6-bd7dd8b62a2c@github.com>
Message-ID: <q4-Btqc5VnF0kGizZcoP_YZofrll_DXUvo_g1aDFohY=.837819e9-8699-4afc-97fd-3d0b563fb0cb@github.com>

On Thu, 7 Jan 2021 18:26:12 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> 8039278: console.sh failed Automatically with exit code 1

This pull request has now been integrated.

Changeset: 4ce83f2a
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4ce83f2a
Stats:     130 lines in 2 files changed: 0 ins; 129 del; 1 mod

8039278: console.sh failed Automatically with exit code 1

Reviewed-by: xuelei, weijun

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

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

From rhalade at openjdk.java.net  Thu Jan  7 19:25:09 2021
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Thu, 7 Jan 2021 19:25:09 GMT
Subject: [jdk16] Integrated: 8039278: console.sh failed Automatically with
 exit code 1
Message-ID: <g02yQWP9xEocNv3yuua_3e2V_63mbiU9AXMHvJ8zv-U=.bc4d99dc-221f-46c0-b753-b27e8580adcc@github.com>

Reviewed-by: xuelei, weijun

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

Commit messages:
 - 8039278: console.sh failed Automatically with exit code 1

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

PR: https://git.openjdk.java.net/jdk16/pull/93

From rhalade at openjdk.java.net  Thu Jan  7 19:25:10 2021
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Thu, 7 Jan 2021 19:25:10 GMT
Subject: [jdk16] Integrated: 8039278: console.sh failed Automatically with
 exit code 1
In-Reply-To: <g02yQWP9xEocNv3yuua_3e2V_63mbiU9AXMHvJ8zv-U=.bc4d99dc-221f-46c0-b753-b27e8580adcc@github.com>
References: <g02yQWP9xEocNv3yuua_3e2V_63mbiU9AXMHvJ8zv-U=.bc4d99dc-221f-46c0-b753-b27e8580adcc@github.com>
Message-ID: <_nkFc6UffCK49iU8BQw94oazB3MB_8G9YFHrW_SHst8=.adade213-983e-4447-a3b4-2cf2e5ededc7@github.com>

On Thu, 7 Jan 2021 19:19:32 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Reviewed-by: xuelei, weijun

This pull request has now been integrated.

Changeset: 1973fbee
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/1973fbee
Stats:     130 lines in 2 files changed: 0 ins; 129 del; 1 mod

8039278: console.sh failed Automatically with exit code 1

Backport-of: 4ce83f2a3a6c5fe11c298bed557c341e286e068a

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

PR: https://git.openjdk.java.net/jdk16/pull/93

From valeriep at openjdk.java.net  Thu Jan  7 19:31:55 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 7 Jan 2021 19:31:55 GMT
Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires
 SunJCE's classes
In-Reply-To: <u0MKmmnw4k2MnkDD-a26NsLCRk1NEtbf9MY4MHSPa6Y=.9d02a25d-9eb8-4ed2-88c8-9d239be0f7df@github.com>
References: <u0MKmmnw4k2MnkDD-a26NsLCRk1NEtbf9MY4MHSPa6Y=.9d02a25d-9eb8-4ed2-88c8-9d239be0f7df@github.com>
Message-ID: <EenNcVFNV3ZMLJT-KvaxLm0Zilkt7VVgk_0tiVlj-rs=.df94bb74-11c1-4167-af17-b22f7eb66ee9@github.com>

On Wed, 6 Jan 2021 15:33:59 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> As described in JDK-8259319 [1], this fix proposal is to set proper access permissions so the SunPKCS11 provider can create instances of SunJCE classes when a Security Manager is installed and the fallback scheme is used.
> 
> No regressions found in jdk/sun/security/pkcs11 tests category.
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8259319

Obscure bug, thanks for report and the fix. I will take a look.

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

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

From jlahoda at openjdk.java.net  Thu Jan  7 20:23:17 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 7 Jan 2021 20:23:17 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v12]
In-Reply-To: <k1SYjoM2awbCbJ9aK3_biTQRgLTIa62VlyOOqi1-IHQ=.c33493b3-4c7e-409e-b02d-13cdc467d71f@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <mCFx_-zaZljumWnBwZfRwVqIs2zBHbQXMec4CBaQKS8=.f75babcd-333b-427d-9152-6f386736bb7f@github.com>
 <k1SYjoM2awbCbJ9aK3_biTQRgLTIa62VlyOOqi1-IHQ=.c33493b3-4c7e-409e-b02d-13cdc467d71f@github.com>
Message-ID: <8Op-CSXTHItDGmtN_VyoyOdZe1WR9g4JkRe852pe274=.367211a5-5f71-473b-be53-ee3706e50786@github.com>

On Wed, 9 Dec 2020 13:30:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> 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 55 commits:
>> 
>>  - Merging recent master changes into JDK-8250768
>>  - Fixing navigator for the PREVIEW page.
>>  - Fixing typo.
>>  - Removing obsolette @PreviewFeature.
>>  - Merging master into JDK-8250768
>>  - Removing unnecessary property keys.
>>  - Cleanup - removing unnecessary code.
>>  - Merging master into JDK-8250768-dev4
>>  - Reflecting review comments.
>>  - Removing trailing whitespace.
>>  - ... and 45 more: https://git.openjdk.java.net/jdk/compare/044616bd...0c1c4d57
>
> Build changes still good.

I've merged the PR with the recent mainline, and I'd like to integrate sometime soon. Please let me know if there's any issue with that. Thanks!

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

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

From jlahoda at openjdk.java.net  Thu Jan  7 20:23:16 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 7 Jan 2021 20:23:16 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v13]
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <1Hv0w0gv07ik40DRi5JBB-G6opt0v3HjdbJc8Y-8kXs=.756df108-047c-414b-9e34-ca73ade932a4@github.com>

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
> 
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits:

 - Fixing tests after a merge.
 - Merging master into JDK-8250768
 - Merging recent master changes into JDK-8250768
 - Fixing navigator for the PREVIEW page.
 - Fixing typo.
 - Removing obsolette @PreviewFeature.
 - Merging master into JDK-8250768
 - Removing unnecessary property keys.
 - Cleanup - removing unnecessary code.
 - Merging master into JDK-8250768-dev4
 - ... and 47 more: https://git.openjdk.java.net/jdk/compare/81c06242...a8046dde

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

Changes: https://git.openjdk.java.net/jdk/pull/703/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=12
  Stats: 3719 lines in 134 files changed: 2724 ins; 695 del; 300 mod
  Patch: https://git.openjdk.java.net/jdk/pull/703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703

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

From jwilhelm at openjdk.java.net  Thu Jan  7 20:45:15 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 7 Jan 2021 20:45:15 GMT
Subject: RFR: Merge jdk16
Message-ID: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com>

Forwardport JDK 16 -> JDK 17

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

Commit messages:
 - Merge
 - 8249633: doclint reports missing javadoc for JavaFX property methods that have a property description
 - 8251200: False positive messages about missing comments for serialization
 - 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days
 - 8259075: Update the copyright notice in the files generated by CLDR Converter tool
 - 8259224: (ann) getAnnotatedReceiverType should not parameterize owner(s) of statically nested classes
 - 8258558: Revert changes for JDK-8252505 and related issues
 - 8259032: MappedMemorySegmentImpl#makeMappedSegment() ignores Unmapper#pagePosition
 - 8259007: This test printed a blank page
 - 8258989: JVM is failed to inline in jdk.internal.vm.vector.VectorSupport::convert
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/0e6de4eb...bbd6426f

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=1989&range=00.0
 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=1989&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/1989/files
  Stats: 2957 lines in 68 files changed: 751 ins; 2142 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1989.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1989/head:pull/1989

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

From jwilhelm at openjdk.java.net  Thu Jan  7 21:21:57 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 7 Jan 2021 21:21:57 GMT
Subject: Integrated: Merge jdk16
In-Reply-To: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com>
References: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com>
Message-ID: <g7HsOL7HlE5kiLX6yzRNwvx5XNa7P_bh7ZlqKQgSMhM=.de687feb-4dbe-428e-9552-fa4b54dc2e04@github.com>

On Thu, 7 Jan 2021 20:40:49 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: 555641ed
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/555641ed
Stats:     2957 lines in 68 files changed: 751 ins; 2142 del; 64 mod

Merge

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

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

From mullan at openjdk.java.net  Thu Jan  7 21:26:55 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 7 Jan 2021 21:26:55 GMT
Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires
 SunJCE's classes
In-Reply-To: <u0MKmmnw4k2MnkDD-a26NsLCRk1NEtbf9MY4MHSPa6Y=.9d02a25d-9eb8-4ed2-88c8-9d239be0f7df@github.com>
References: <u0MKmmnw4k2MnkDD-a26NsLCRk1NEtbf9MY4MHSPa6Y=.9d02a25d-9eb8-4ed2-88c8-9d239be0f7df@github.com>
Message-ID: <dhc_yeLFkK-0o8cwc6Aqa95ZE_e5sOKt9FU0ACn3y-c=.7bbb66ec-6ce4-493b-a5da-bddb21c85c7c@github.com>

On Wed, 6 Jan 2021 15:33:59 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> As described in JDK-8259319 [1], this fix proposal is to set proper access permissions so the SunPKCS11 provider can create instances of SunJCE classes when a Security Manager is installed and the fallback scheme is used.
> 
> No regressions found in jdk/sun/security/pkcs11 tests category.
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8259319

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java line 90:

> 88:         p = Security.getProvider(providerName);
> 89:         if (p == null) {
> 90:             p = AccessController.doPrivileged(

Could you use the limited version of doPrivileged and only assert the permissions that are strictly necessary to instantiate a provider?

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

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

From jjg at openjdk.java.net  Fri Jan  8 02:01:06 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 8 Jan 2021 02:01:06 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v13]
In-Reply-To: <1Hv0w0gv07ik40DRi5JBB-G6opt0v3HjdbJc8Y-8kXs=.756df108-047c-414b-9e34-ca73ade932a4@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <1Hv0w0gv07ik40DRi5JBB-G6opt0v3HjdbJc8Y-8kXs=.756df108-047c-414b-9e34-ca73ade932a4@github.com>
Message-ID: <b9bIUIojeQyDZdGaeCIWt0wsFc8oxCQmrQ3TCsz46HU=.8cecf9b7-de69-457d-a10f-3415ef47615d@github.com>

On Thu, 7 Jan 2021 20:23:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
>> 
>> The notable changes are:
>> 
>>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>>  
>>  Please also see the CSR [6] for more information.
>>  
>>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits:
> 
>  - Fixing tests after a merge.
>  - Merging master into JDK-8250768
>  - Merging recent master changes into JDK-8250768
>  - Fixing navigator for the PREVIEW page.
>  - Fixing typo.
>  - Removing obsolette @PreviewFeature.
>  - Merging master into JDK-8250768
>  - Removing unnecessary property keys.
>  - Cleanup - removing unnecessary code.
>  - Merging master into JDK-8250768-dev4
>  - ... and 47 more: https://git.openjdk.java.net/jdk/compare/81c06242...a8046dde

I've looked at all the files that were marked as changed since I last looked at them.

There's one suggested enhancement to reduce string bashing between `Utils` and `ClassWriterImpl` that could be done now or later.

There's a pending conflict with a PR of mine to change to use a new type `HtmlId` for HTML ids. This JEP12 work has been in progress for a while, and so it would be good to get it in before the `HtmlId` work, and I'll deal with the merge conflict in due course.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java line 194:

> 192: 
> 193:     @Override @SuppressWarnings("preview")
> 194:     public void addClassSignature(String modifiers, Content classInfoTree) {

It seems less than ideal for this method to take a `String` and to then have to take it apart and reassemble it. It looks like it should be possible (and conceptually better) to change the signature to `List<String>` and to make the corresponding change to `utils.modifiersToString`, probably renaming it as `utils.modifiersToStrings` or something like that, and dropping the always-`true` argument for `trailingSpace`.  

But, the code is OK as is, and the suggestion is just for an enhancement, so is OK to defer it, if you would prefer.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java line 2:

> 1: /*
> 2:  * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.

(minor) now 2021

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java line 61:

> 59: public abstract class SummaryListWriter<L extends SummaryAPIListBuilder> extends SubWriterHolderWriter {
> 60: 
> 61:     private String getAnchorName(SummaryElementKind kind) {

Heads-up: at some point this will conflict with another change in progress/review, to introduce a new type `HtmlId`  to use instead of `String` for ids.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java line 227:

> 225:      * @param contentTree the content tree to which the summary table will be added
> 226:      */
> 227:     protected void addSummaryAPI(SortedSet<Element> apiList, String id,

Heads-up, here's another occurrence of where there will be a conflict for ids.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 154:

> 152: doclet.Errors=Errors
> 153: doclet.Classes=Classes
> 154: doclet.Records=Records

I guess I'm mildly surprised to see all these items being removed...

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/SummaryAPIListBuilder.java line 2:

> 1: /*
> 2:  * Copyright (c) 1998, 2020, Oracle and/or its affiliates. All rights reserved.

Year

test/langtools/jdk/javadoc/doclet/testPreview/TestPreview.java line 2:

> 1: /*
> 2:  * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.

2021. I assume you will do a bulk update for affected files.

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

Marked as reviewed by jjg (Reviewer).

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

From jjg at openjdk.java.net  Fri Jan  8 04:14:04 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 8 Jan 2021 04:14:04 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v13]
In-Reply-To: <b9bIUIojeQyDZdGaeCIWt0wsFc8oxCQmrQ3TCsz46HU=.8cecf9b7-de69-457d-a10f-3415ef47615d@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <1Hv0w0gv07ik40DRi5JBB-G6opt0v3HjdbJc8Y-8kXs=.756df108-047c-414b-9e34-ca73ade932a4@github.com>
 <b9bIUIojeQyDZdGaeCIWt0wsFc8oxCQmrQ3TCsz46HU=.8cecf9b7-de69-457d-a10f-3415ef47615d@github.com>
Message-ID: <BDOACTqp_2PmXmXr_C69thMynzJfgTA8a4C5yyvely0=.9a32e84e-6a68-477d-8e24-3657c88582ab@github.com>

On Fri, 8 Jan 2021 01:58:07 GMT, Jonathan Gibbons <jjg at openjdk.org> 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 57 commits:
>> 
>>  - Fixing tests after a merge.
>>  - Merging master into JDK-8250768
>>  - Merging recent master changes into JDK-8250768
>>  - Fixing navigator for the PREVIEW page.
>>  - Fixing typo.
>>  - Removing obsolette @PreviewFeature.
>>  - Merging master into JDK-8250768
>>  - Removing unnecessary property keys.
>>  - Cleanup - removing unnecessary code.
>>  - Merging master into JDK-8250768-dev4
>>  - ... and 47 more: https://git.openjdk.java.net/jdk/compare/81c06242...a8046dde
>
> I've looked at all the files that were marked as changed since I last looked at them.
> 
> There's one suggested enhancement to reduce string bashing between `Utils` and `ClassWriterImpl` that could be done now or later.
> 
> There's a pending conflict with a PR of mine to change to use a new type `HtmlId` for HTML ids. This JEP12 work has been in progress for a while, and so it would be good to get it in before the `HtmlId` work, and I'll deal with the merge conflict in due course.

+1

-- Jon

On 1/7/21 12:19 PM, Jan Lahoda wrote:
>
> I've merged the PR with the recent mainline, and I'd like to integrate 
> sometime soon. Please let me know if there's any issue with that. Thanks!
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/703*issuecomment-756360085__;Iw!!GqivPVa7Brio!Oxxf6GpefmtstD2fCT8IKF4r-blOVCGWCibSjA4m4l24mI8j6j-RDEJAiBRtFfHCMqNb7Q$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRTWQAZF7NEGTD3FSGDSYYJOPANCNFSM4STPEYJQ__;!!GqivPVa7Brio!Oxxf6GpefmtstD2fCT8IKF4r-blOVCGWCibSjA4m4l24mI8j6j-RDEJAiBRtFfFTnE3pGg$>.
>

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

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

From attila at openjdk.java.net  Fri Jan  8 08:53:19 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Fri, 8 Jan 2021 08:53:19 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v4]
In-Reply-To: <lTmAigU7IJZfXkwns9PuXCtgPvowhr2cY26dalEDRG4=.ff495634-8d11-42ac-84ad-9185f676c958@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
 <zoH9LkGyKKA32SjXotq71dKDFs1-wYLiboY4yvKZwmk=.21ed959b-7e39-42fb-baf1-6d8e856326d5@github.com>
 <lTmAigU7IJZfXkwns9PuXCtgPvowhr2cY26dalEDRG4=.ff495634-8d11-42ac-84ad-9185f676c958@github.com>
Message-ID: <fNTCiDKRV2h2jzOE1ON6bNWhiovpWHXDz5Kn491fOK8=.3bcce888-dc27-40bf-9e98-5f9f0bde5e70@github.com>

On Mon, 4 Jan 2021 13:31:41 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Just a small suggestion using `MethodHandles.empty` instead of `MethodHandles.constant().asType().dropArguments()`.
>
> Hi Attila,
> 
> This looks good.
> 
> If I understand correctly, your `BiClassValue` is a holder for a `BiFunction` and a `BiClassValueRoot` which is a `ClassValue<BiClassValues>`. The `BiClassValues` contains two lazily constructed Map(s): `forward` and `reverse`. You then employ a logic where you either use the `forward` map obtained from c1 if c1.classLoader sees c2.classLoader or `backward` map obtained from c2 if c2.classLoader sees c1.classLoader or you don't employ caching if c1.classLoader and c2.classLoader are unrelated.
> The need for two Maps is probably because the two Class components of the "bi-key" are ordered, right? So `BiClassValue bcv = ...;` `bcv.get(c1, c2)` is not the same as `bcv.get(c2, c1)` ....
> Alternatively you could have a `BiClassValue` with two embedded `ClassValue`(s):
> 
> final CVRoot<T> forward = new CVRoot<>();
> final CVRoot<T> reverse = new CVRoor<>();
> 
> static class CVRoot<T> extends ClassValue<CHMCL<T>> {
>   public CHMCL<T> get(Class<?> clazz) { return new CHMCL<>(getClassLoader(clazz)); }
> }
> 
> static class CHMCL<T> extends ConcurrentHashMap<Class<?>, T> {
>   final ClassLoader classLoader;
>   CHMCL(ClassLoader cl) { classLoader = cl; }
> }
> 
> ...with that you could get rid of the intermediary BiClassValues object. It would be replaced with a ConcurrentHashMap subclass that would contain a field to hold the cached ClassLoader of the c1/c2. One de-reference less...
> 
> As for the main logic, it would be similar to what you have now. Or it could be different. I wonder what is the performance of canReferenceDirectly(). If you used SharedSecrets to obtain a ClassLoader of a Class without security checks (and thus overhead), you could perhaps evaluate the canReferenceDirectly() before lookups so you would not needlessly trigger initialization of ClassValue(s) that don't need to get initialized. 
> 
> WDYT?

Hey Peter,

thank you for the most thoughtful review! You understood everything right. Your approach looks mostly equivalent to mine, with bit of different tradeoffs. I'm indeed using `BiClassValues` as an intermediate object; it has two benefits. The smaller benefit is that the class loader lookup is performed once per class and stored only once per class. The larger benefit is that it defers the creation of the CHMs until it has something to put into them. Most of the time, only one of either forward or reverse will be created. You're right that the same benefit could be had if we checked `canReferenceDirectly` first, although I'm trying to make the fast path as fast as possible.

I'm even thinking I could afford to read the class loader on each use of main logic when a cached value is not available and not even use a CHM subclass to hold it. [canReferenceDirectly](https://github.com/openjdk/jdk/blob/master/src/jdk.dynalink/share/classes/jdk/dynalink/internal/InternalTypeUtilities.java#L70) is basically equivalent to "isDescendantOf" and can be evaluated fairly quickly, unless there's a really long class loader chain. (FWIW, it is also equivalent to [`!ClassLoader.needsClassLoaderPermissionCheck(from, to)`](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/ClassLoader.java#L2016) but, alas, that's private, and even `ClassLoader.isAncestor` that I could similarly use is package-private.

In any case, your suggestion nudged me towards a different rework: `BiClassValues` now uses immutable maps instead of concurrent ones, and uses those `VarHandles` for `compareAndExchange` on them. In this sense, `BiClassValue` is now little more than a pair of atomic references. I decided CHM was an overkill here as the map contents stabilize over time; using immutable maps feels more natural.

I also realized that `canReferenceDirectly` invocations also need to happen in a `doPrivileged` block (Dynalink itself is loaded through the platform class loader, so needs these.)

FWIW, your suggestion to use `SharedSecrets` is intriguing - if I could access both `ClassLoader.isAncestor` and `ClassLoader.getClassLoader` through `JavaLangAccess`, that'd indeed spare me having to go through `doPrivileged` blocks. OTOH, there's other places in Dynalink that could benefit from those methods, and strictly speaking it's a performance optimization, so I'll rather save that for a separate PR instead of expanding this one's scope. If I adopted using `JavaLangAccess` I might also look into whether I could replace this class' implementation with a `ClassLoaderValue` instead, but again, that's beyond the scope of this PR.

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

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

From attila at openjdk.java.net  Fri Jan  8 08:53:19 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Fri, 8 Jan 2021 08:53:19 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v4]
In-Reply-To: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
Message-ID: <jhpOkKQW5l1kiMXee9eg3p4kykfB2ns0AJlulVYOrww=.94fdb6ce-19c5-4166-b789-58bdec0718f4@github.com>

> _(NB: For this leak to occur, an application needs to be either creating and discarding linkers frequently, or creating and discarding class loaders frequently while creating Dynalink type converters for classes in them. Neither is typical usage, although they can occur in dynamic code loading environments such as OSGi.)_
> 
> I'll explain this one in a bit more detail. Dynalink creates and caches method handles for language-specific conversions between types. Each conversion is thus characterized by a `Class` object representing the type converted from, and a `Class` object representing the type converted to, thus they're keyed by a pair of `(Class, Class)`. Java API provides the excellent `ClassValue` class for associating values with a single class, but it lacks the ? admittedly more niche ? facility for associating a value with a pair of classes. I originally solved this problem using something that looks like a `ClassValue<Map<Class<?>, T>>`. I say "looks like" because Dynalink has a specialized `ClassMap` class that works like `Map<Class<?>, T>` but it also goes to some pains to _not_ establish strong references from a class loader to either its children or to unrelated class loaders, for obvious reasons.
> 
> Surprisingly, the problem didn't lie in there, though. The problem was in the fact that `TypeConverterFactory` used `ClassValue` objects that were its non-static anonymous inner classes, and further the values they computed were also of non-static anonymous inner classes. Due to the way `ClassValue` internals work, this led to the `TypeConverterFactory` objects becoming anchored in a GC root of `Class.classValueMap` through the synthetic `this$0` reference chains in said inner classes? talk about non-obvious memory leaks. (I guess there's a lesson in there about not using `ClassValue` as an instance field, but there's a genuine need for them here, so?)
> 
> ? so the first thing I did was I deconstructed all those anonymous inner classes into named static inner classes, and ended up with something that _did_ fix the memory leak (yay!) but at the same time there was a bunch of copying of constructor parameters from outer classes into the inner classes, the whole thing was very clunky with scary amounts of boilerplate. I felt there must exist a better solution.
> 
> And it exists! I ended up replacing the `ClassValue<ClassMap<T>>` construct with a ground-up implementation of `BiClassValue<T>`, representation of lazily computed values associated with a pair of types. This was the right abstraction the `TypeConverterFactory` code needed all along. `BiClassValue<T>` is also not implemented as an abstract class but rather it is a final class and takes a `BiFunction<Class<?>, Class<?>, T>` for computation of its values, thus there's never a risk of making it an instance-specific inner class (well, you still need to be careful with the bifunction lambda?) It also has an even better solution for avoiding strong references to child class loaders.
> 
> And that's why I'm not submitting here the smallest possible point fix to the memory leak, but rather a slightly larger one that architecturally fixes it the right way.
> 
> There are two test classes, they test subtly different scenarios. `TypeConverterFactoryMemoryLeakTest` tests that when a `TypeConverterFactory` instance becomes unreachable, all method handles it created also become eligible for collection. `TypeConverterFactoryRetentionTests` on the other hand test that the factory itself won't prevent class loaders from being collected by virtue of creating converters for them.

Attila Szegedi has updated the pull request incrementally with two additional commits since the last revision:

 - Use immutable maps instead of concurrent ones
 - Remove classLoader field from BiClassValues and evaluate class loader relationships in a doPrivileged block

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1918/files
  - new: https://git.openjdk.java.net/jdk/pull/1918/files/eaddc17b..3f934a21

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

  Stats: 92 lines in 1 file changed: 48 ins; 16 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1918.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1918/head:pull/1918

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

From github.com+10835776+stsypanov at openjdk.java.net  Fri Jan  8 09:40:00 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, 8 Jan 2021 09:40:00 GMT
Subject: RFR: 8193031: Collections.addAll is likely to perform worse than
 Collection.addAll
In-Reply-To: <HGsYr1kNCPjCwV5bnXUUsSvxHd15C3G99FulbSkpFYE=.18613967-548c-488e-8d12-1e40bcfffa72@github.com>
References: <TB3epXzVEKg86PLsoPvHgfKAC2XHrLGCH2ZsuCJw2h4=.c75b4032-abb7-4f95-b19e-65788727f049@github.com>
 <X4vHouF0uVTx1XTeRjmqZ0ldcYtqP-Zkf1ujMzvRbtM=.633d7310-3d0b-4296-95ba-7b6829482b43@github.com>
 <HGsYr1kNCPjCwV5bnXUUsSvxHd15C3G99FulbSkpFYE=.18613967-548c-488e-8d12-1e40bcfffa72@github.com>
Message-ID: <47B7kkUUmzlTIJLb14nPTXYckKtrXTREVZLU2iilSGU=.b1c05f13-aea1-4d90-bc2b-37d2ab6280dd@github.com>

On Thu, 17 Dec 2020 10:36:17 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Looks like I've found the original ticket: https://bugs.openjdk.java.net/browse/JDK-8193031
>
> Apart from the @SuppressWarnings, this looks good to me.
> And i like the irony of this.

@forax, @plevart could I ask for review once again?

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

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

From plevart at openjdk.java.net  Fri Jan  8 09:46:58 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 8 Jan 2021 09:46:58 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v4]
In-Reply-To: <jhpOkKQW5l1kiMXee9eg3p4kykfB2ns0AJlulVYOrww=.94fdb6ce-19c5-4166-b789-58bdec0718f4@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
 <jhpOkKQW5l1kiMXee9eg3p4kykfB2ns0AJlulVYOrww=.94fdb6ce-19c5-4166-b789-58bdec0718f4@github.com>
Message-ID: <FJmeH3PPj0JH8pXn3dmVwdV3rtDqnYSMBSganQYAqaw=.6fa33b85-1698-4413-87df-3fc4cc28513c@github.com>

On Fri, 8 Jan 2021 08:53:19 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> _(NB: For this leak to occur, an application needs to be either creating and discarding linkers frequently, or creating and discarding class loaders frequently while creating Dynalink type converters for classes in them. Neither is typical usage, although they can occur in dynamic code loading environments such as OSGi.)_
>> 
>> I'll explain this one in a bit more detail. Dynalink creates and caches method handles for language-specific conversions between types. Each conversion is thus characterized by a `Class` object representing the type converted from, and a `Class` object representing the type converted to, thus they're keyed by a pair of `(Class, Class)`. Java API provides the excellent `ClassValue` class for associating values with a single class, but it lacks the ? admittedly more niche ? facility for associating a value with a pair of classes. I originally solved this problem using something that looks like a `ClassValue<Map<Class<?>, T>>`. I say "looks like" because Dynalink has a specialized `ClassMap` class that works like `Map<Class<?>, T>` but it also goes to some pains to _not_ establish strong references from a class loader to either its children or to unrelated class loaders, for obvious reasons.
>> 
>> Surprisingly, the problem didn't lie in there, though. The problem was in the fact that `TypeConverterFactory` used `ClassValue` objects that were its non-static anonymous inner classes, and further the values they computed were also of non-static anonymous inner classes. Due to the way `ClassValue` internals work, this led to the `TypeConverterFactory` objects becoming anchored in a GC root of `Class.classValueMap` through the synthetic `this$0` reference chains in said inner classes? talk about non-obvious memory leaks. (I guess there's a lesson in there about not using `ClassValue` as an instance field, but there's a genuine need for them here, so?)
>> 
>> ? so the first thing I did was I deconstructed all those anonymous inner classes into named static inner classes, and ended up with something that _did_ fix the memory leak (yay!) but at the same time there was a bunch of copying of constructor parameters from outer classes into the inner classes, the whole thing was very clunky with scary amounts of boilerplate. I felt there must exist a better solution.
>> 
>> And it exists! I ended up replacing the `ClassValue<ClassMap<T>>` construct with a ground-up implementation of `BiClassValue<T>`, representation of lazily computed values associated with a pair of types. This was the right abstraction the `TypeConverterFactory` code needed all along. `BiClassValue<T>` is also not implemented as an abstract class but rather it is a final class and takes a `BiFunction<Class<?>, Class<?>, T>` for computation of its values, thus there's never a risk of making it an instance-specific inner class (well, you still need to be careful with the bifunction lambda?) It also has an even better solution for avoiding strong references to child class loaders.
>> 
>> And that's why I'm not submitting here the smallest possible point fix to the memory leak, but rather a slightly larger one that architecturally fixes it the right way.
>> 
>> There are two test classes, they test subtly different scenarios. `TypeConverterFactoryMemoryLeakTest` tests that when a `TypeConverterFactory` instance becomes unreachable, all method handles it created also become eligible for collection. `TypeConverterFactoryRetentionTests` on the other hand test that the factory itself won't prevent class loaders from being collected by virtue of creating converters for them.
>
> Attila Szegedi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use immutable maps instead of concurrent ones
>  - Remove classLoader field from BiClassValues and evaluate class loader relationships in a doPrivileged block

src/jdk.dynalink/share/classes/jdk/dynalink/BiClassValue.java line 126:

> 124:                     entries.add(Map.entry(c, value));
> 125:                     @SuppressWarnings("rawtypes")
> 126:                     final var newEntries = entries.toArray(new Map.Entry[0]);

Since map is immutable now, instead of:

var entries = new ArrayList<>(map.entrySet());
entries.add(Map.entry(c, value));
var newEntries = entries.toArray(new Map.Entry[0]); 

you could write:

var entries = map.entrySet().toArray(new Map.Entry[map.size() + 1]);
entries[map.size()] = Map.entry(c, value);

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

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

From github.com+652983+dasbrain at openjdk.java.net  Fri Jan  8 09:56:07 2021
From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn)
Date: Fri, 8 Jan 2021 09:56:07 GMT
Subject: RFR: JDK-8259395 Patching automatic module with additional packages
 re-creates module without "requires java.base"
Message-ID: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>

Simple fix, complex test case.

Thanks to @AlanBateman for pointing out the right fix.

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

Commit messages:
 - * Minor cleanup.
 - * Fix Whitespace V2
 - * Fix whitespace
 - * Fix JDK-8259395 - test now passes
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8259395
 - * Add failing tests for JDK-8259395

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

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

From plevart at openjdk.java.net  Fri Jan  8 09:56:59 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 8 Jan 2021 09:56:59 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v4]
In-Reply-To: <jhpOkKQW5l1kiMXee9eg3p4kykfB2ns0AJlulVYOrww=.94fdb6ce-19c5-4166-b789-58bdec0718f4@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
 <jhpOkKQW5l1kiMXee9eg3p4kykfB2ns0AJlulVYOrww=.94fdb6ce-19c5-4166-b789-58bdec0718f4@github.com>
Message-ID: <e4mz-HdLk3BnPUBLDSVwR5Gp8AWZEXVoNrKDVs_RhFY=.1c47c478-02e7-489f-ab2c-fed208c53624@github.com>

On Fri, 8 Jan 2021 08:53:19 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> _(NB: For this leak to occur, an application needs to be either creating and discarding linkers frequently, or creating and discarding class loaders frequently while creating Dynalink type converters for classes in them. Neither is typical usage, although they can occur in dynamic code loading environments such as OSGi.)_
>> 
>> I'll explain this one in a bit more detail. Dynalink creates and caches method handles for language-specific conversions between types. Each conversion is thus characterized by a `Class` object representing the type converted from, and a `Class` object representing the type converted to, thus they're keyed by a pair of `(Class, Class)`. Java API provides the excellent `ClassValue` class for associating values with a single class, but it lacks the ? admittedly more niche ? facility for associating a value with a pair of classes. I originally solved this problem using something that looks like a `ClassValue<Map<Class<?>, T>>`. I say "looks like" because Dynalink has a specialized `ClassMap` class that works like `Map<Class<?>, T>` but it also goes to some pains to _not_ establish strong references from a class loader to either its children or to unrelated class loaders, for obvious reasons.
>> 
>> Surprisingly, the problem didn't lie in there, though. The problem was in the fact that `TypeConverterFactory` used `ClassValue` objects that were its non-static anonymous inner classes, and further the values they computed were also of non-static anonymous inner classes. Due to the way `ClassValue` internals work, this led to the `TypeConverterFactory` objects becoming anchored in a GC root of `Class.classValueMap` through the synthetic `this$0` reference chains in said inner classes? talk about non-obvious memory leaks. (I guess there's a lesson in there about not using `ClassValue` as an instance field, but there's a genuine need for them here, so?)
>> 
>> ? so the first thing I did was I deconstructed all those anonymous inner classes into named static inner classes, and ended up with something that _did_ fix the memory leak (yay!) but at the same time there was a bunch of copying of constructor parameters from outer classes into the inner classes, the whole thing was very clunky with scary amounts of boilerplate. I felt there must exist a better solution.
>> 
>> And it exists! I ended up replacing the `ClassValue<ClassMap<T>>` construct with a ground-up implementation of `BiClassValue<T>`, representation of lazily computed values associated with a pair of types. This was the right abstraction the `TypeConverterFactory` code needed all along. `BiClassValue<T>` is also not implemented as an abstract class but rather it is a final class and takes a `BiFunction<Class<?>, Class<?>, T>` for computation of its values, thus there's never a risk of making it an instance-specific inner class (well, you still need to be careful with the bifunction lambda?) It also has an even better solution for avoiding strong references to child class loaders.
>> 
>> And that's why I'm not submitting here the smallest possible point fix to the memory leak, but rather a slightly larger one that architecturally fixes it the right way.
>> 
>> There are two test classes, they test subtly different scenarios. `TypeConverterFactoryMemoryLeakTest` tests that when a `TypeConverterFactory` instance becomes unreachable, all method handles it created also become eligible for collection. `TypeConverterFactoryRetentionTests` on the other hand test that the factory itself won't prevent class loaders from being collected by virtue of creating converters for them.
>
> Attila Szegedi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use immutable maps instead of concurrent ones
>  - Remove classLoader field from BiClassValues and evaluate class loader relationships in a doPrivileged block

src/jdk.dynalink/share/classes/jdk/dynalink/BiClassValue.java line 106:

> 104: 
> 105:         private volatile Map<Class<?>, T> forward = Map.of();
> 106:         private volatile Map<Class<?>, T> reverse = Map.of();

Since maps are immutable now and allow safe publication via data race (i.e. their internal state is composed of final fields), you could relax the forward/referse fields to be plain fields. You would just have to leave them uninitialized then and check for null at some places if BiClassValues could be published via data race since I don't know whether ClassValue guarantees that the associated values are published safely or not. If it does, then you could pre-initialize the field with empty maps as now, if it does not, then even volatile modifiers don't guarantee that unsafely published BiClassValues object can only be seen with the fields initialized. i.e. you could read null from them.

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

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

From plevart at openjdk.java.net  Fri Jan  8 11:08:57 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 8 Jan 2021 11:08:57 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v4]
In-Reply-To: <fNTCiDKRV2h2jzOE1ON6bNWhiovpWHXDz5Kn491fOK8=.3bcce888-dc27-40bf-9e98-5f9f0bde5e70@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
 <zoH9LkGyKKA32SjXotq71dKDFs1-wYLiboY4yvKZwmk=.21ed959b-7e39-42fb-baf1-6d8e856326d5@github.com>
 <lTmAigU7IJZfXkwns9PuXCtgPvowhr2cY26dalEDRG4=.ff495634-8d11-42ac-84ad-9185f676c958@github.com>
 <fNTCiDKRV2h2jzOE1ON6bNWhiovpWHXDz5Kn491fOK8=.3bcce888-dc27-40bf-9e98-5f9f0bde5e70@github.com>
Message-ID: <W3php0n2KC0PSvw7NfZ2nN4eu1e7rhQbGTH5QDkNGQc=.951f0c81-6c9b-40b3-8d48-ac93ec58b4fe@github.com>

On Fri, 8 Jan 2021 08:49:44 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> Hi Attila,
>> 
>> This looks good.
>> 
>> If I understand correctly, your `BiClassValue` is a holder for a `BiFunction` and a `BiClassValueRoot` which is a `ClassValue<BiClassValues>`. The `BiClassValues` contains two lazily constructed Map(s): `forward` and `reverse`. You then employ a logic where you either use the `forward` map obtained from c1 if c1.classLoader sees c2.classLoader or `backward` map obtained from c2 if c2.classLoader sees c1.classLoader or you don't employ caching if c1.classLoader and c2.classLoader are unrelated.
>> The need for two Maps is probably because the two Class components of the "bi-key" are ordered, right? So `BiClassValue bcv = ...;` `bcv.get(c1, c2)` is not the same as `bcv.get(c2, c1)` ....
>> Alternatively you could have a `BiClassValue` with two embedded `ClassValue`(s):
>> 
>> final CVRoot<T> forward = new CVRoot<>();
>> final CVRoot<T> reverse = new CVRoor<>();
>> 
>> static class CVRoot<T> extends ClassValue<CHMCL<T>> {
>>   public CHMCL<T> get(Class<?> clazz) { return new CHMCL<>(getClassLoader(clazz)); }
>> }
>> 
>> static class CHMCL<T> extends ConcurrentHashMap<Class<?>, T> {
>>   final ClassLoader classLoader;
>>   CHMCL(ClassLoader cl) { classLoader = cl; }
>> }
>> 
>> ...with that you could get rid of the intermediary BiClassValues object. It would be replaced with a ConcurrentHashMap subclass that would contain a field to hold the cached ClassLoader of the c1/c2. One de-reference less...
>> 
>> As for the main logic, it would be similar to what you have now. Or it could be different. I wonder what is the performance of canReferenceDirectly(). If you used SharedSecrets to obtain a ClassLoader of a Class without security checks (and thus overhead), you could perhaps evaluate the canReferenceDirectly() before lookups so you would not needlessly trigger initialization of ClassValue(s) that don't need to get initialized. 
>> 
>> WDYT?
>
> Hey Peter,
> 
> thank you for the most thoughtful review! You understood everything right. Your approach looks mostly equivalent to mine, with bit of different tradeoffs. I'm indeed using `BiClassValues` as an intermediate object; it has two benefits. The smaller benefit is that the class loader lookup is performed once per class and stored only once per class. The larger benefit is that it defers the creation of the CHMs until it has something to put into them. Most of the time, only one of either forward or reverse will be created. You're right that the same benefit could be had if we checked `canReferenceDirectly` first, although I'm trying to make the fast path as fast as possible.
> 
> I'm even thinking I could afford to read the class loader on each use of main logic when a cached value is not available and not even use a CHM subclass to hold it. [canReferenceDirectly](https://github.com/openjdk/jdk/blob/master/src/jdk.dynalink/share/classes/jdk/dynalink/internal/InternalTypeUtilities.java#L70) is basically equivalent to "isDescendantOf" and can be evaluated fairly quickly, unless there's a really long class loader chain. (FWIW, it is also equivalent to [`!ClassLoader.needsClassLoaderPermissionCheck(from, to)`](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/ClassLoader.java#L2016) but, alas, that's private, and even `ClassLoader.isAncestor` that I could similarly use is package-private.
> 
> In any case, your suggestion nudged me towards a different rework: `BiClassValues` now uses immutable maps instead of concurrent ones, and uses those `VarHandles` for `compareAndExchange` on them. In this sense, `BiClassValue` is now little more than a pair of atomic references. I decided CHM was an overkill here as the map contents stabilize over time; using immutable maps feels more natural.
> 
> I also realized that `canReferenceDirectly` invocations also need to happen in a `doPrivileged` block (Dynalink itself is loaded through the platform class loader, so needs these.)
> 
> FWIW, your suggestion to use `SharedSecrets` is intriguing - if I could access both `ClassLoader.isAncestor` and `ClassLoader.getClassLoader` through `JavaLangAccess`, that'd indeed spare me having to go through `doPrivileged` blocks. OTOH, there's other places in Dynalink that could benefit from those methods, and strictly speaking it's a performance optimization, so I'll rather save that for a separate PR instead of expanding this one's scope. If I adopted using `JavaLangAccess` I might also look into whether I could replace this class' implementation with a `ClassLoaderValue` instead, but again, that's beyond the scope of this PR.

So what do you think of this variant:
https://github.com/plevart/jdk/commit/7af5b81d486d6ee3b7b4c6be90895478fb45868d
...reading of forward/reverse fields in compute can still be volatile while in fast path it can be relaxed. In addition, since the ClassValue spec does not say whether it publishes associated values safely or not (I think the impl. does publish them safely), it is better to not rely on that and not pre-initialize the forward/reverse fields with empty maps and rely on them never to be observed as null...

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

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

From plevart at openjdk.java.net  Fri Jan  8 11:30:55 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 8 Jan 2021 11:30:55 GMT
Subject: RFR: 8193031: Collections.addAll is likely to perform worse than
 Collection.addAll
In-Reply-To: <47B7kkUUmzlTIJLb14nPTXYckKtrXTREVZLU2iilSGU=.b1c05f13-aea1-4d90-bc2b-37d2ab6280dd@github.com>
References: <TB3epXzVEKg86PLsoPvHgfKAC2XHrLGCH2ZsuCJw2h4=.c75b4032-abb7-4f95-b19e-65788727f049@github.com>
 <X4vHouF0uVTx1XTeRjmqZ0ldcYtqP-Zkf1ujMzvRbtM=.633d7310-3d0b-4296-95ba-7b6829482b43@github.com>
 <HGsYr1kNCPjCwV5bnXUUsSvxHd15C3G99FulbSkpFYE=.18613967-548c-488e-8d12-1e40bcfffa72@github.com>
 <47B7kkUUmzlTIJLb14nPTXYckKtrXTREVZLU2iilSGU=.b1c05f13-aea1-4d90-bc2b-37d2ab6280dd@github.com>
Message-ID: <MMgyNFF6k3ovq--q8ZWNOUhVxKhs46sTCVYe1ucrYXo=.887bfa14-1c3e-4fc8-86e3-d5a8442277ff@github.com>

On Fri, 8 Jan 2021 09:37:23 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Apart from the @SuppressWarnings, this looks good to me.
>> And i like the irony of this.
>
> @forax, @plevart could I ask for review once again?

Hi @stsypanov, 

> The **behavior** of this convenience method is **identical** to that of c.addAll(Arrays.asList(elements))

What about:

> The **behaviour** of this convenience method is **similar** to that of c.addAll(Arrays.asList(elements))

...since it is not entirely identical. The outcome is usually identical because collections usually adhere to the specification, but we can not claim the behaviour is identical if the target collection does not adhere.

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

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

From plevart at openjdk.java.net  Fri Jan  8 11:41:55 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 8 Jan 2021 11:41:55 GMT
Subject: RFR: 8193031: Collections.addAll is likely to perform worse than
 Collection.addAll
In-Reply-To: <MMgyNFF6k3ovq--q8ZWNOUhVxKhs46sTCVYe1ucrYXo=.887bfa14-1c3e-4fc8-86e3-d5a8442277ff@github.com>
References: <TB3epXzVEKg86PLsoPvHgfKAC2XHrLGCH2ZsuCJw2h4=.c75b4032-abb7-4f95-b19e-65788727f049@github.com>
 <X4vHouF0uVTx1XTeRjmqZ0ldcYtqP-Zkf1ujMzvRbtM=.633d7310-3d0b-4296-95ba-7b6829482b43@github.com>
 <HGsYr1kNCPjCwV5bnXUUsSvxHd15C3G99FulbSkpFYE=.18613967-548c-488e-8d12-1e40bcfffa72@github.com>
 <47B7kkUUmzlTIJLb14nPTXYckKtrXTREVZLU2iilSGU=.b1c05f13-aea1-4d90-bc2b-37d2ab6280dd@github.com>
 <MMgyNFF6k3ovq--q8ZWNOUhVxKhs46sTCVYe1ucrYXo=.887bfa14-1c3e-4fc8-86e3-d5a8442277ff@github.com>
Message-ID: <uXM0w30njrZNn9c68Sn_jjcAnJZGZWZXzoA0wRJcwRM=.6d6408b3-8d28-4272-8bdf-921b9d1ae971@github.com>

On Fri, 8 Jan 2021 11:27:57 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> @forax, @plevart could I ask for review once again?
>
> Hi @stsypanov, 
> 
>> The **behavior** of this convenience method is **identical** to that of c.addAll(Arrays.asList(elements))
> 
> What about:
> 
>> The **behaviour** of this convenience method is **similar** to that of c.addAll(Arrays.asList(elements))
> 
> ...since it is not entirely identical. The outcome is usually identical because collections usually adhere to the specification, but we can not claim the behaviour is identical if the target collection does not adhere.

...but we could employ this method to guarantee more than `c.addAll(Arrays.asList(elements))` does. So what about:

> The behaviour of this convenience method is similar to that of `c.addAll(Collections.unmodifiableList(Arrays.asList(elements)))`

This means that the method guarantees that the passed in `elements` array will not be modified even if given collection `c` is not trusted. Speaking of that, perhaps you could try benchmarking such `c.addAll(Collections.unmodifiableList(Arrays.asList(elements)))` and see how it compares. The speed-up you observed from `c.addAll(Arrays.asList(elements))` with some collections was probably a result of them calling .toArray() on the argument collection and incorporating the resulting array into their own data structure in a bulk-copying-way. So `c.addAll(Collections.unmodifiableList(Arrays.asList(elements)))` might have same performance characteristics while guaranteeing same things about argument array. It might be slower when Iterator is employed though because unmodifiableList wrapper wraps Iterator(s) too....

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

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

From attila at openjdk.java.net  Fri Jan  8 12:25:55 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Fri, 8 Jan 2021 12:25:55 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v4]
In-Reply-To: <W3php0n2KC0PSvw7NfZ2nN4eu1e7rhQbGTH5QDkNGQc=.951f0c81-6c9b-40b3-8d48-ac93ec58b4fe@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
 <zoH9LkGyKKA32SjXotq71dKDFs1-wYLiboY4yvKZwmk=.21ed959b-7e39-42fb-baf1-6d8e856326d5@github.com>
 <lTmAigU7IJZfXkwns9PuXCtgPvowhr2cY26dalEDRG4=.ff495634-8d11-42ac-84ad-9185f676c958@github.com>
 <fNTCiDKRV2h2jzOE1ON6bNWhiovpWHXDz5Kn491fOK8=.3bcce888-dc27-40bf-9e98-5f9f0bde5e70@github.com>
 <W3php0n2KC0PSvw7NfZ2nN4eu1e7rhQbGTH5QDkNGQc=.951f0c81-6c9b-40b3-8d48-ac93ec58b4fe@github.com>
Message-ID: <3p6wFSLodVRRy2-ZBAAWtpoFjEaGkNBPNVFAtXwfj8U=.24d43d1b-03d6-42a6-a036-b1c55fe156ac@github.com>

On Fri, 8 Jan 2021 11:06:17 GMT, Peter Levart <plevart at openjdk.org> wrote:

> So what do you think of this variant:

I like it. I originally kept the fields volatile so that we don't observe stale values on `getForward`/`getReverse`, but you're right in that even if we do, the correct value will be observed when doing a volatile read in compute, at the additional expense of evaluating class loader relationships, but again, that's the slow path.

IIUC, your changes mostly all flow from the decision to declare the fields as non-volatile; if they were still declared as volatile then it'd be impossible to observe null in them, I think (correct me if I'm wrong; it seems like you thought through this quite thoroughly) as then I don't see how could a volatile read happen before the initial volatile writes as the writes are part of the ClassValues constructor invocation and the reference to the ClassValues object is unavailable externally before the constructor completes. In any case, your approach definitely avoids any of these concerns so I'm inclined to go with it.

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

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

From attila at openjdk.java.net  Fri Jan  8 12:47:17 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Fri, 8 Jan 2021 12:47:17 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v5]
In-Reply-To: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
Message-ID: <6RivA3zjvIwixfAnodE2Y7vLsyMsjgAPRQXGX3LvtDs=.b7d94cc4-263f-4559-9720-6cb9bbc14747@github.com>

> _(NB: For this leak to occur, an application needs to be either creating and discarding linkers frequently, or creating and discarding class loaders frequently while creating Dynalink type converters for classes in them. Neither is typical usage, although they can occur in dynamic code loading environments such as OSGi.)_
> 
> I'll explain this one in a bit more detail. Dynalink creates and caches method handles for language-specific conversions between types. Each conversion is thus characterized by a `Class` object representing the type converted from, and a `Class` object representing the type converted to, thus they're keyed by a pair of `(Class, Class)`. Java API provides the excellent `ClassValue` class for associating values with a single class, but it lacks the ? admittedly more niche ? facility for associating a value with a pair of classes. I originally solved this problem using something that looks like a `ClassValue<Map<Class<?>, T>>`. I say "looks like" because Dynalink has a specialized `ClassMap` class that works like `Map<Class<?>, T>` but it also goes to some pains to _not_ establish strong references from a class loader to either its children or to unrelated class loaders, for obvious reasons.
> 
> Surprisingly, the problem didn't lie in there, though. The problem was in the fact that `TypeConverterFactory` used `ClassValue` objects that were its non-static anonymous inner classes, and further the values they computed were also of non-static anonymous inner classes. Due to the way `ClassValue` internals work, this led to the `TypeConverterFactory` objects becoming anchored in a GC root of `Class.classValueMap` through the synthetic `this$0` reference chains in said inner classes? talk about non-obvious memory leaks. (I guess there's a lesson in there about not using `ClassValue` as an instance field, but there's a genuine need for them here, so?)
> 
> ? so the first thing I did was I deconstructed all those anonymous inner classes into named static inner classes, and ended up with something that _did_ fix the memory leak (yay!) but at the same time there was a bunch of copying of constructor parameters from outer classes into the inner classes, the whole thing was very clunky with scary amounts of boilerplate. I felt there must exist a better solution.
> 
> And it exists! I ended up replacing the `ClassValue<ClassMap<T>>` construct with a ground-up implementation of `BiClassValue<T>`, representation of lazily computed values associated with a pair of types. This was the right abstraction the `TypeConverterFactory` code needed all along. `BiClassValue<T>` is also not implemented as an abstract class but rather it is a final class and takes a `BiFunction<Class<?>, Class<?>, T>` for computation of its values, thus there's never a risk of making it an instance-specific inner class (well, you still need to be careful with the bifunction lambda?) It also has an even better solution for avoiding strong references to child class loaders.
> 
> And that's why I'm not submitting here the smallest possible point fix to the memory leak, but rather a slightly larger one that architecturally fixes it the right way.
> 
> There are two test classes, they test subtly different scenarios. `TypeConverterFactoryMemoryLeakTest` tests that when a `TypeConverterFactory` instance becomes unreachable, all method handles it created also become eligible for collection. `TypeConverterFactoryRetentionTests` on the other hand test that the factory itself won't prevent class loaders from being collected by virtue of creating converters for them.

Attila Szegedi has updated the pull request incrementally with three additional commits since the last revision:

 - Reduce some code duplication; make some local vars final.
 - Bugfix
 - non-volatile forward/reverse

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1918/files
  - new: https://git.openjdk.java.net/jdk/pull/1918/files/3f934a21..a8d81ebb

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

  Stats: 42 lines in 1 file changed: 15 ins; 4 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1918.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1918/head:pull/1918

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

From plevart at openjdk.java.net  Fri Jan  8 13:03:56 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 8 Jan 2021 13:03:56 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v5]
In-Reply-To: <3p6wFSLodVRRy2-ZBAAWtpoFjEaGkNBPNVFAtXwfj8U=.24d43d1b-03d6-42a6-a036-b1c55fe156ac@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
 <zoH9LkGyKKA32SjXotq71dKDFs1-wYLiboY4yvKZwmk=.21ed959b-7e39-42fb-baf1-6d8e856326d5@github.com>
 <lTmAigU7IJZfXkwns9PuXCtgPvowhr2cY26dalEDRG4=.ff495634-8d11-42ac-84ad-9185f676c958@github.com>
 <fNTCiDKRV2h2jzOE1ON6bNWhiovpWHXDz5Kn491fOK8=.3bcce888-dc27-40bf-9e98-5f9f0bde5e70@github.com>
 <W3php0n2KC0PSvw7NfZ2nN4eu1e7rhQbGTH5QDkNGQc=.951f0c81-6c9b-40b3-8d48-ac93ec58b4fe@github.com>
 <3p6wFSLodVRRy2-ZBAAWtpoFjEaGkNBPNVFAtXwfj8U=.24d43d1b-03d6-42a6-a036-b1c55fe156ac@github.com>
Message-ID: <dobvEKxlc9DXft9y67QNUTWZsJtC_XCvOaPajJQ83Pg=.f59cd6d8-e110-40c8-8b8a-22f2e224aeff@github.com>

On Fri, 8 Jan 2021 12:23:36 GMT, Attila Szegedi <attila at openjdk.org> wrote:

> IIUC, your changes mostly all flow from the decision to declare the fields as non-volatile; if they were still declared as volatile then it'd be impossible to observe null in them, I think (correct me if I'm wrong; it seems like you thought through this quite thoroughly) as then I don't see how could a volatile read happen before the initial volatile writes as the writes are part of the ClassValues constructor invocation and the reference to the ClassValues object is unavailable externally before the constructor completes. In any case, your approach definitely avoids any of these concerns so I'm inclined to go with it.

It depends entirely on the guarantees of ClassValue and not on whether the fields are volatile or not. If ClassValue publishes the BiClassValues object via data race then even if the fields in BiClassValues are volatile and initialized in constructor, the publishing write in ClassValue could get reordered past the volatile writes of the fields, so you could observe the fields uninitialized.
I can't find in the spec of ClassValue any guarantees of ordering, but I guess the implementation does guarantee safe publication. So if you want to rely on ClassValue guaranteeing safe publication, you can pre-initialized the fields in constructor and code can assume they are never null even if they are not volatile.

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

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

From plevart at openjdk.java.net  Fri Jan  8 13:06:58 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 8 Jan 2021 13:06:58 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v5]
In-Reply-To: <6RivA3zjvIwixfAnodE2Y7vLsyMsjgAPRQXGX3LvtDs=.b7d94cc4-263f-4559-9720-6cb9bbc14747@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
 <6RivA3zjvIwixfAnodE2Y7vLsyMsjgAPRQXGX3LvtDs=.b7d94cc4-263f-4559-9720-6cb9bbc14747@github.com>
Message-ID: <Onf44IjAXZLt5t7xhgE0yflbhnEwXHs7JWqtNQb0uUE=.ed9f4cc1-055f-4775-b34b-f2f2084b76d7@github.com>

On Fri, 8 Jan 2021 12:47:17 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> _(NB: For this leak to occur, an application needs to be either creating and discarding linkers frequently, or creating and discarding class loaders frequently while creating Dynalink type converters for classes in them. Neither is typical usage, although they can occur in dynamic code loading environments such as OSGi.)_
>> 
>> I'll explain this one in a bit more detail. Dynalink creates and caches method handles for language-specific conversions between types. Each conversion is thus characterized by a `Class` object representing the type converted from, and a `Class` object representing the type converted to, thus they're keyed by a pair of `(Class, Class)`. Java API provides the excellent `ClassValue` class for associating values with a single class, but it lacks the ? admittedly more niche ? facility for associating a value with a pair of classes. I originally solved this problem using something that looks like a `ClassValue<Map<Class<?>, T>>`. I say "looks like" because Dynalink has a specialized `ClassMap` class that works like `Map<Class<?>, T>` but it also goes to some pains to _not_ establish strong references from a class loader to either its children or to unrelated class loaders, for obvious reasons.
>> 
>> Surprisingly, the problem didn't lie in there, though. The problem was in the fact that `TypeConverterFactory` used `ClassValue` objects that were its non-static anonymous inner classes, and further the values they computed were also of non-static anonymous inner classes. Due to the way `ClassValue` internals work, this led to the `TypeConverterFactory` objects becoming anchored in a GC root of `Class.classValueMap` through the synthetic `this$0` reference chains in said inner classes? talk about non-obvious memory leaks. (I guess there's a lesson in there about not using `ClassValue` as an instance field, but there's a genuine need for them here, so?)
>> 
>> ? so the first thing I did was I deconstructed all those anonymous inner classes into named static inner classes, and ended up with something that _did_ fix the memory leak (yay!) but at the same time there was a bunch of copying of constructor parameters from outer classes into the inner classes, the whole thing was very clunky with scary amounts of boilerplate. I felt there must exist a better solution.
>> 
>> And it exists! I ended up replacing the `ClassValue<ClassMap<T>>` construct with a ground-up implementation of `BiClassValue<T>`, representation of lazily computed values associated with a pair of types. This was the right abstraction the `TypeConverterFactory` code needed all along. `BiClassValue<T>` is also not implemented as an abstract class but rather it is a final class and takes a `BiFunction<Class<?>, Class<?>, T>` for computation of its values, thus there's never a risk of making it an instance-specific inner class (well, you still need to be careful with the bifunction lambda?) It also has an even better solution for avoiding strong references to child class loaders.
>> 
>> And that's why I'm not submitting here the smallest possible point fix to the memory leak, but rather a slightly larger one that architecturally fixes it the right way.
>> 
>> There are two test classes, they test subtly different scenarios. `TypeConverterFactoryMemoryLeakTest` tests that when a `TypeConverterFactory` instance becomes unreachable, all method handles it created also become eligible for collection. `TypeConverterFactoryRetentionTests` on the other hand test that the factory itself won't prevent class loaders from being collected by virtue of creating converters for them.
>
> Attila Szegedi has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Reduce some code duplication; make some local vars final.
>  - Bugfix
>  - non-volatile forward/reverse

src/jdk.dynalink/share/classes/jdk/dynalink/BiClassValue.java line 136:

> 134:                     Map.Entry<Class<?>, T>[] entries = map.entrySet().toArray(new Map.Entry[map.size() + 1]);
> 135:                     entries[map.size()] = Map.entry(c, newValue);
> 136:                     newMap = Map.ofEntries(entries);

Pardon me! A result of introducing new local late in the process.

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

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

From peter.levart at gmail.com  Fri Jan  8 13:13:45 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 8 Jan 2021 14:13:45 +0100
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v5]
In-Reply-To: <dobvEKxlc9DXft9y67QNUTWZsJtC_XCvOaPajJQ83Pg=.f59cd6d8-e110-40c8-8b8a-22f2e224aeff@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
 <zoH9LkGyKKA32SjXotq71dKDFs1-wYLiboY4yvKZwmk=.21ed959b-7e39-42fb-baf1-6d8e856326d5@github.com>
 <lTmAigU7IJZfXkwns9PuXCtgPvowhr2cY26dalEDRG4=.ff495634-8d11-42ac-84ad-9185f676c958@github.com>
 <fNTCiDKRV2h2jzOE1ON6bNWhiovpWHXDz5Kn491fOK8=.3bcce888-dc27-40bf-9e98-5f9f0bde5e70@github.com>
 <W3php0n2KC0PSvw7NfZ2nN4eu1e7rhQbGTH5QDkNGQc=.951f0c81-6c9b-40b3-8d48-ac93ec58b4fe@github.com>
 <3p6wFSLodVRRy2-ZBAAWtpoFjEaGkNBPNVFAtXwfj8U=.24d43d1b-03d6-42a6-a036-b1c55fe156ac@github.com>
 <dobvEKxlc9DXft9y67QNUTWZsJtC_XCvOaPajJQ83Pg=.f59cd6d8-e110-40c8-8b8a-22f2e224aeff@github.com>
Message-ID: <ce514e62-a2f4-c847-f634-51c8efa182f7@gmail.com>


On 1/8/21 2:03 PM, Peter Levart wrote:
> On Fri, 8 Jan 2021 12:23:36 GMT, Attila Szegedi <attila at openjdk.org> wrote:
>
>> IIUC, your changes mostly all flow from the decision to declare the fields as non-volatile; if they were still declared as volatile then it'd be impossible to observe null in them, I think (correct me if I'm wrong; it seems like you thought through this quite thoroughly) as then I don't see how could a volatile read happen before the initial volatile writes as the writes are part of the ClassValues constructor invocation and the reference to the ClassValues object is unavailable externally before the constructor completes. In any case, your approach definitely avoids any of these concerns so I'm inclined to go with it.
> It depends entirely on the guarantees of ClassValue and not on whether the fields are volatile or not. If ClassValue publishes the BiClassValues object via data race then even if the fields in BiClassValues are volatile and initialized in constructor, the publishing write in ClassValue could get reordered past


correction: past -> before


>   the volatile writes of the fields, so you could observe the fields uninitialized.
> I can't find in the spec of ClassValue any guarantees of ordering, but I guess the implementation does guarantee safe publication. So if you want to rely on ClassValue guaranteeing safe publication, you can pre-initialized the fields in constructor and code can assume they are never null even if they are not volatile.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/1918


To explain: Normal writes that appear in program order before a volatile 
write can not be observed to appear later than the volatile write. But 
normal writes that appear in program order after a volatile write can be 
observed to appear before the volatile write.


Regards, Peter



From aefimov at openjdk.java.net  Fri Jan  8 13:22:53 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Fri, 8 Jan 2021 13:22:53 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v4]
In-Reply-To: <GQZRQa0eTs-vhF2x1W-wqp3uBpxtR-evPQNPs4eiW9c=.8839784d-fccf-4d5d-ad47-af2c11aed30e@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
 <WfWVy9NtoNsW2S4UA74_eJAZTwspjzmzwO9mlIXCcCQ=.843478a1-bcd2-497a-9cea-2bd37fb833ad@github.com>
 <GQZRQa0eTs-vhF2x1W-wqp3uBpxtR-evPQNPs4eiW9c=.8839784d-fccf-4d5d-ad47-af2c11aed30e@github.com>
Message-ID: <pi8KRqBhZKpymYUR49AVIZn0NsgvUAPaNguuY_Iimsc=.29869180-4a40-435e-9be6-932de1e7b226@github.com>

On Sat, 19 Dec 2020 10:29:23 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Thank you for checking `HttpURLConnection` and `Socket`.
>> The latest version looks good to me.
>
> This issue is blocked by [8258657][1]. It should not be integrated until after 8258657 has been resolved. The JIRA issues have been linked up to reflect this.
> 
> [1]: https://bugs.openjdk.java.net/browse/JDK-8258657

[JDK-8258657](https://bugs.openjdk.java.net/browse/JDK-8258657) has been resolved. The changes reverted by [JDK-8258696](https://bugs.openjdk.java.net/browse/JDK-8258696) could also be re-applied to `HttpClientImpl` class.

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

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

From plevart at openjdk.java.net  Fri Jan  8 13:34:56 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 8 Jan 2021 13:34:56 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v5]
In-Reply-To: <dobvEKxlc9DXft9y67QNUTWZsJtC_XCvOaPajJQ83Pg=.f59cd6d8-e110-40c8-8b8a-22f2e224aeff@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
 <zoH9LkGyKKA32SjXotq71dKDFs1-wYLiboY4yvKZwmk=.21ed959b-7e39-42fb-baf1-6d8e856326d5@github.com>
 <lTmAigU7IJZfXkwns9PuXCtgPvowhr2cY26dalEDRG4=.ff495634-8d11-42ac-84ad-9185f676c958@github.com>
 <fNTCiDKRV2h2jzOE1ON6bNWhiovpWHXDz5Kn491fOK8=.3bcce888-dc27-40bf-9e98-5f9f0bde5e70@github.com>
 <W3php0n2KC0PSvw7NfZ2nN4eu1e7rhQbGTH5QDkNGQc=.951f0c81-6c9b-40b3-8d48-ac93ec58b4fe@github.com>
 <3p6wFSLodVRRy2-ZBAAWtpoFjEaGkNBPNVFAtXwfj8U=.24d43d1b-03d6-42a6-a036-b1c55fe156ac@github.com>
 <dobvEKxlc9DXft9y67QNUTWZsJtC_XCvOaPajJQ83Pg=.f59cd6d8-e110-40c8-8b8a-22f2e224aeff@github.com>
Message-ID: <fvt_Tj5UwTHYS9yPGAOZL9VwitgjJAtVXWGJ5Yvthao=.4d54187c-e287-48c2-9f81-793523c0c720@github.com>

On Fri, 8 Jan 2021 13:00:16 GMT, Peter Levart <plevart at openjdk.org> wrote:

>>> So what do you think of this variant:
>> 
>> I like it. I originally kept the fields volatile so that we don't observe stale values on `getForward`/`getReverse`, but you're right in that even if we do, the correct value will be observed when doing a volatile read in compute, at the additional expense of evaluating class loader relationships, but again, that's the slow path.
>> 
>> IIUC, your changes mostly all flow from the decision to declare the fields as non-volatile; if they were still declared as volatile then it'd be impossible to observe null in them, I think (correct me if I'm wrong; it seems like you thought through this quite thoroughly) as then I don't see how could a volatile read happen before the initial volatile writes as the writes are part of the ClassValues constructor invocation and the reference to the ClassValues object is unavailable externally before the constructor completes. In any case, your approach definitely avoids any of these concerns so I'm inclined to go with it.
>
>> IIUC, your changes mostly all flow from the decision to declare the fields as non-volatile; if they were still declared as volatile then it'd be impossible to observe null in them, I think (correct me if I'm wrong; it seems like you thought through this quite thoroughly) as then I don't see how could a volatile read happen before the initial volatile writes as the writes are part of the ClassValues constructor invocation and the reference to the ClassValues object is unavailable externally before the constructor completes. In any case, your approach definitely avoids any of these concerns so I'm inclined to go with it.
> 
> It depends entirely on the guarantees of ClassValue and not on whether the fields are volatile or not. If ClassValue publishes the BiClassValues object via data race then even if the fields in BiClassValues are volatile and initialized in constructor, the publishing write in ClassValue could get reordered before the volatile writes of the fields, so you could observe the fields uninitialized.
> I can't find in the spec of ClassValue any guarantees of ordering, but I guess the implementation does guarantee safe publication. So if you want to rely on ClassValue guaranteeing safe publication, you can pre-initialized the fields in constructor and code can assume they are never null even if they are not volatile.

I checked the code of ClassValue and it can be assumed that it publishes associated values safely. The proof is that it keeps values that it publishes assigned to the final field `java.lang.ClassValue.Entry#value`.

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

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

From chegar at openjdk.java.net  Fri Jan  8 15:03:58 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 8 Jan 2021 15:03:58 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v4]
In-Reply-To: <pi8KRqBhZKpymYUR49AVIZn0NsgvUAPaNguuY_Iimsc=.29869180-4a40-435e-9be6-932de1e7b226@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
 <WfWVy9NtoNsW2S4UA74_eJAZTwspjzmzwO9mlIXCcCQ=.843478a1-bcd2-497a-9cea-2bd37fb833ad@github.com>
 <GQZRQa0eTs-vhF2x1W-wqp3uBpxtR-evPQNPs4eiW9c=.8839784d-fccf-4d5d-ad47-af2c11aed30e@github.com>
 <pi8KRqBhZKpymYUR49AVIZn0NsgvUAPaNguuY_Iimsc=.29869180-4a40-435e-9be6-932de1e7b226@github.com>
Message-ID: <wDuCc-RJWxdVNzjpTM9CODuGR3SDQUfiJK81NIUQVfk=.f2fc5c1a-8b72-4523-9fb7-2ee4c97b3f8b@github.com>

On Fri, 8 Jan 2021 13:20:38 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This issue is blocked by [8258657][1]. It should not be integrated until after 8258657 has been resolved. The JIRA issues have been linked up to reflect this.
>> 
>> [1]: https://bugs.openjdk.java.net/browse/JDK-8258657
>
> [JDK-8258657](https://bugs.openjdk.java.net/browse/JDK-8258657) has been resolved. The changes reverted by [JDK-8258696](https://bugs.openjdk.java.net/browse/JDK-8258696) could also be re-applied to `HttpClientImpl` class.

@AlekseiEfimov Yes please. Whatever is easier, include the changes to HttpClientImpl in this PR, or followup separately. Otherwise, I see no reason why this PR cannot proceed.

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

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

From jlahoda at openjdk.java.net  Fri Jan  8 15:26:04 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 8 Jan 2021 15:26:04 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v13]
In-Reply-To: <b9bIUIojeQyDZdGaeCIWt0wsFc8oxCQmrQ3TCsz46HU=.8cecf9b7-de69-457d-a10f-3415ef47615d@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <1Hv0w0gv07ik40DRi5JBB-G6opt0v3HjdbJc8Y-8kXs=.756df108-047c-414b-9e34-ca73ade932a4@github.com>
 <b9bIUIojeQyDZdGaeCIWt0wsFc8oxCQmrQ3TCsz46HU=.8cecf9b7-de69-457d-a10f-3415ef47615d@github.com>
Message-ID: <Rcw_W4WZFDmyy2_yrPMpqNhAUwfg242oDI-ozfHN7jY=.09703af7-da12-40a5-b766-f1a9bbd1b3dd@github.com>

On Fri, 8 Jan 2021 01:51:52 GMT, Jonathan Gibbons <jjg at openjdk.org> 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 57 commits:
>> 
>>  - Fixing tests after a merge.
>>  - Merging master into JDK-8250768
>>  - Merging recent master changes into JDK-8250768
>>  - Fixing navigator for the PREVIEW page.
>>  - Fixing typo.
>>  - Removing obsolette @PreviewFeature.
>>  - Merging master into JDK-8250768
>>  - Removing unnecessary property keys.
>>  - Cleanup - removing unnecessary code.
>>  - Merging master into JDK-8250768-dev4
>>  - ... and 47 more: https://git.openjdk.java.net/jdk/compare/81c06242...a8046dde
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 154:
> 
>> 152: doclet.Errors=Errors
>> 153: doclet.Classes=Classes
>> 154: doclet.Records=Records
> 
> I guess I'm mildly surprised to see all these items being removed...

These were used from DeprecatedListWriter.getSummaryKey which is removed by this patch (and is unused in the current mainline, as far as I know).

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

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

From jlahoda at openjdk.java.net  Fri Jan  8 15:29:22 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 8 Jan 2021 15:29:22 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v14]
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <5yqRThkGhxW8tDtwfkBzOB8k6-CoWkengMWAgeGogr0=.fa0c0a28-abe8-47bb-86f8-cd18b1ed3aa0@github.com>

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
> 
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Updating copyright years.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/703/files
  - new: https://git.openjdk.java.net/jdk/pull/703/files/a8046dde..56371c47

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

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

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

From rriggs at openjdk.java.net  Fri Jan  8 15:52:04 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 8 Jan 2021 15:52:04 GMT
Subject: RFR: 8258796: [test] Apply HexFormat to tests for java.security
Message-ID: <uqMxr0rtpoILbqnGodp5oCz-Uhq6CEUHta-HGFZdpAo=.b20ecd37-1d98-4435-8468-232f32e15cf0@github.com>

Followup to the addition of java.util.HexFormat.  
Uses of adhoc hexadecimal conversions are replaced with HexFormat.
Redundant utility methods are modified or removed.
In a few places the data being printed is ASN.1 and the test utility HexPrinter with the ASNFormatter is added.

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

Commit messages:
 - 8258796: [test] Apply HexFormat to tests for java.security

Changes: https://git.openjdk.java.net/jdk/pull/2006/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2006&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258796
  Stats: 738 lines in 43 files changed: 81 ins; 466 del; 191 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2006.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2006/head:pull/2006

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

From rriggs at openjdk.java.net  Fri Jan  8 16:09:55 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 8 Jan 2021 16:09:55 GMT
Subject: RFR: 8258796: [test] Apply HexFormat to tests for java.security
In-Reply-To: <uqMxr0rtpoILbqnGodp5oCz-Uhq6CEUHta-HGFZdpAo=.b20ecd37-1d98-4435-8468-232f32e15cf0@github.com>
References: <uqMxr0rtpoILbqnGodp5oCz-Uhq6CEUHta-HGFZdpAo=.b20ecd37-1d98-4435-8468-232f32e15cf0@github.com>
Message-ID: <kOOZ6oqJX8DVpaluuidbEQCZXhEvfMYIVlHiiUfbff0=.576db1e4-8eb5-4e38-8aa2-74745f99bea1@github.com>

On Fri, 8 Jan 2021 15:43:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Followup to the addition of java.util.HexFormat.  
> Uses of adhoc hexadecimal conversions are replaced with HexFormat.
> Redundant utility methods are modified or removed.
> In a few places the data being printed is ASN.1 and the test utility HexPrinter with the ASNFormatter is added.

Removing the hotspot-runtime label to avoid spamming that alias. 
Add it back if it is warranted.

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

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

From dl at cs.oswego.edu  Fri Jan  8 16:24:42 2021
From: dl at cs.oswego.edu (Doug Lea)
Date: Fri, 8 Jan 2021 11:24:42 -0500
Subject: Monitoring wrapped ThreadPoolExecutor returned from Executors
In-Reply-To: <SN7PR18MB40165BE278DEA37BB110363483AF9@SN7PR18MB4016.namprd18.prod.outlook.com>
References: <BYAPR05MB65998619D6784F8FB6E13700DFD00@BYAPR05MB6599.namprd05.prod.outlook.com>
 <fa7f2656-c249-688f-5215-626a2250b22c@cs.oswego.edu>
 <SN7PR18MB40165BE278DEA37BB110363483AF9@SN7PR18MB4016.namprd18.prod.outlook.com>
Message-ID: <347c5e67-69b4-9bd5-89ba-34efbfcb5baa@cs.oswego.edu>

On 1/7/21 12:57 PM, Jason Mehrens wrote:
> Hi Doug,
>
> What are your thoughts on promoting monitoring methods from TPE and or FJP to AbstractExecutorService?  The default implementations could just return -1.  An example precedent is OperatingSystemMXBean::getSystemLoadAverage.  The Executors.DelegatedExecutorService could then be modified to extend AbstractExecutorService and forward the new methods and the existing AES::taskFor calls when the wrapped Executor is also an AbstractExecutorService.  The return types of the Executors.newXXX would remain the same.

Maybe. But for now, here's a cheap trick that might be tolerable: Add to 
DelegatedExecutorService:

public String toString() { return e.toString(); }

The juc executors (ThreadPoolExecutor and ForkJoinPool that could be 
wrapped here) both print pool size, active threads, queued tasks, and 
completed tasks. It would require not-very-pleasant string parsing in 
monitoring tools, but this might be good enough for Micrometer and others?


>
> I suppose the tradeoff is that adding any new default method to ExecutorService and or new methods to AbstractExecutorService could break 3rd party code.
>
> Jason
>
> ________________________________________
> From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of Doug Lea <dl at cs.oswego.edu>
> Sent: Thursday, January 7, 2021 7:09 AM
> To: core-libs-dev at openjdk.java.net
> Subject: Re: Monitoring wrapped ThreadPoolExecutor returned from Executors
>
> On 1/5/21 10:11 PM, Tommy Ludwig wrote:
>> In the Micrometer project, we provide metrics instrumentation of `ExectorService`s. For `ThreadPoolExecutor`s, we track the number of completed tasks, active tasks, thread pool sizes, task queue size and remaining capacity via methods from `ThreadPoolExecutor`. We are currently using a brittle reflection hack[1] to do this for the wrapped `ThreadPoolExecutor` returned from `Executors` methods `newSingleThreadExecutor` and `newSingleThreadScheduledExecutor`. With the introduction of JEP-396 in JDK 16, our reflection hack throws an InaccessibleObjectException by default.
>>
>> I am not seeing a proper way to get at the methods we use for the metrics (e.g. `ThreadPoolExecutor::getCompletedTaskCount`) in this case. Is there a way that I am missing?
> There's no guarantee that newSingleThreadExecutor returns a restricted
> view of a ThreadPoolExecutor, so there can't be a guaranteed way of
> accessing it,
>
> But I'm sympathetic to the idea that under the current implementation
> (which is unlikely to change anytime soon), the stats are available, and
> should be available to monitoring tools. But none of the ways to do this
> are very attractive: Creating a MonitorableExecutorService interface and
> returning that? Making the internal view class public with a protected
> getExecutor method?
>
>

From rriggs at openjdk.java.net  Fri Jan  8 16:26:09 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 8 Jan 2021 16:26:09 GMT
Subject: RFR: 8258796: [test] Apply HexFormat to tests for java.security
 [v2]
In-Reply-To: <uqMxr0rtpoILbqnGodp5oCz-Uhq6CEUHta-HGFZdpAo=.b20ecd37-1d98-4435-8468-232f32e15cf0@github.com>
References: <uqMxr0rtpoILbqnGodp5oCz-Uhq6CEUHta-HGFZdpAo=.b20ecd37-1d98-4435-8468-232f32e15cf0@github.com>
Message-ID: <2OMJyKBDALaXTS-eoUt9sasUZ_RZ62oIDAswaAhQZSE=.0f445bed-6960-4cb7-a5c9-88c182f454c7@github.com>

> Followup to the addition of java.util.HexFormat.  
> Uses of adhoc hexadecimal conversions are replaced with HexFormat.
> Redundant utility methods are modified or removed.
> In a few places the data being printed is ASN.1 and the test utility HexPrinter with the ASNFormatter is added.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Update copyrights to 2021

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2006/files
  - new: https://git.openjdk.java.net/jdk/pull/2006/files/c437a74b..b6908530

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

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

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

From attila at openjdk.java.net  Fri Jan  8 16:53:01 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Fri, 8 Jan 2021 16:53:01 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v5]
In-Reply-To: <fvt_Tj5UwTHYS9yPGAOZL9VwitgjJAtVXWGJ5Yvthao=.4d54187c-e287-48c2-9f81-793523c0c720@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
 <zoH9LkGyKKA32SjXotq71dKDFs1-wYLiboY4yvKZwmk=.21ed959b-7e39-42fb-baf1-6d8e856326d5@github.com>
 <lTmAigU7IJZfXkwns9PuXCtgPvowhr2cY26dalEDRG4=.ff495634-8d11-42ac-84ad-9185f676c958@github.com>
 <fNTCiDKRV2h2jzOE1ON6bNWhiovpWHXDz5Kn491fOK8=.3bcce888-dc27-40bf-9e98-5f9f0bde5e70@github.com>
 <W3php0n2KC0PSvw7NfZ2nN4eu1e7rhQbGTH5QDkNGQc=.951f0c81-6c9b-40b3-8d48-ac93ec58b4fe@github.com>
 <3p6wFSLodVRRy2-ZBAAWtpoFjEaGkNBPNVFAtXwfj8U=.24d43d1b-03d6-42a6-a036-b1c55fe156ac@github.com>
 <dobvEKxlc9DXft9y67QNUTWZsJtC_XCvOaPajJQ83Pg=.f59cd6d8-e110-40c8-8b8a-22f2e224aeff@github.com>
 <fvt_Tj5UwTHYS9yPGAOZL9VwitgjJAtVXWGJ5Yvthao=.4d54187c-e287-48c2-9f81-793523c0c720@github.com>
Message-ID: <3aOD4KfYXvu_fe2JRGevhkCsChzQN1FfT6rwZl5Qytk=.82cfe6f8-3026-419b-9961-6cc63b16d8d8@github.com>

On Fri, 8 Jan 2021 13:32:08 GMT, Peter Levart <plevart at openjdk.org> wrote:

>>> IIUC, your changes mostly all flow from the decision to declare the fields as non-volatile; if they were still declared as volatile then it'd be impossible to observe null in them, I think (correct me if I'm wrong; it seems like you thought through this quite thoroughly) as then I don't see how could a volatile read happen before the initial volatile writes as the writes are part of the ClassValues constructor invocation and the reference to the ClassValues object is unavailable externally before the constructor completes. In any case, your approach definitely avoids any of these concerns so I'm inclined to go with it.
>> 
>> It depends entirely on the guarantees of ClassValue and not on whether the fields are volatile or not. If ClassValue publishes the BiClassValues object via data race then even if the fields in BiClassValues are volatile and initialized in constructor, the publishing write in ClassValue could get reordered before the volatile writes of the fields, so you could observe the fields uninitialized.
>> I can't find in the spec of ClassValue any guarantees of ordering, but I guess the implementation does guarantee safe publication. So if you want to rely on ClassValue guaranteeing safe publication, you can pre-initialized the fields in constructor and code can assume they are never null even if they are not volatile.
>
> I checked the code of ClassValue and it can be assumed that it publishes associated values safely. The proof is that it keeps values that it publishes assigned to the final field `java.lang.ClassValue.Entry#value`.

So, are you saying the solution where I kept the fields volatile and initialized them with `Map.of()` is safe? If so, that'd be good news; I'm inclined these days to write as much null-free code as possible :-)

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

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

From xuelei at openjdk.java.net  Fri Jan  8 17:04:55 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 8 Jan 2021 17:04:55 GMT
Subject: RFR: 8258796: [test] Apply HexFormat to tests for java.security
 [v2]
In-Reply-To: <2OMJyKBDALaXTS-eoUt9sasUZ_RZ62oIDAswaAhQZSE=.0f445bed-6960-4cb7-a5c9-88c182f454c7@github.com>
References: <uqMxr0rtpoILbqnGodp5oCz-Uhq6CEUHta-HGFZdpAo=.b20ecd37-1d98-4435-8468-232f32e15cf0@github.com>
 <2OMJyKBDALaXTS-eoUt9sasUZ_RZ62oIDAswaAhQZSE=.0f445bed-6960-4cb7-a5c9-88c182f454c7@github.com>
Message-ID: <CcNyPjKEXpHnkYaHvKwjMxZzGJi9nX4Iwdr1LxoByLI=.95bb4059-6c23-4dc5-936b-77eb32433e40@github.com>

On Fri, 8 Jan 2021 16:26:09 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Followup to the addition of java.util.HexFormat.  
>> Uses of adhoc hexadecimal conversions are replaced with HexFormat.
>> Redundant utility methods are modified or removed.
>> In a few places the data being printed is ASN.1 and the test utility HexPrinter with the ASNFormatter is added.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyrights to 2021

Looks good to me.  Thank you!

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

Marked as reviewed by xuelei (Reviewer).

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

From jlahoda at openjdk.java.net  Fri Jan  8 17:22:19 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 8 Jan 2021 17:22:19 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v15]
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <1l2ZGdCLlmLZ_hbqsEG0AnTrX7pob7FJ_kJ73_qLLu8=.a116a4b4-229e-41dc-ba22-d72f139ce2dd@github.com>

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
> 
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits:

 - Merging master into JDK-8250768
 - Updating copyright years.
 - Fixing tests after a merge.
 - Merging master into JDK-8250768
 - Merging recent master changes into JDK-8250768
 - Fixing navigator for the PREVIEW page.
 - Fixing typo.
 - Removing obsolette @PreviewFeature.
 - Merging master into JDK-8250768
 - Removing unnecessary property keys.
 - ... and 49 more: https://git.openjdk.java.net/jdk/compare/090bd3af...4f654955

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

Changes: https://git.openjdk.java.net/jdk/pull/703/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=14
  Stats: 3802 lines in 133 files changed: 2724 ins; 695 del; 383 mod
  Patch: https://git.openjdk.java.net/jdk/pull/703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703

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

From plevart at openjdk.java.net  Fri Jan  8 19:00:57 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 8 Jan 2021 19:00:57 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v5]
In-Reply-To: <3aOD4KfYXvu_fe2JRGevhkCsChzQN1FfT6rwZl5Qytk=.82cfe6f8-3026-419b-9961-6cc63b16d8d8@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
 <zoH9LkGyKKA32SjXotq71dKDFs1-wYLiboY4yvKZwmk=.21ed959b-7e39-42fb-baf1-6d8e856326d5@github.com>
 <lTmAigU7IJZfXkwns9PuXCtgPvowhr2cY26dalEDRG4=.ff495634-8d11-42ac-84ad-9185f676c958@github.com>
 <fNTCiDKRV2h2jzOE1ON6bNWhiovpWHXDz5Kn491fOK8=.3bcce888-dc27-40bf-9e98-5f9f0bde5e70@github.com>
 <W3php0n2KC0PSvw7NfZ2nN4eu1e7rhQbGTH5QDkNGQc=.951f0c81-6c9b-40b3-8d48-ac93ec58b4fe@github.com>
 <3p6wFSLodVRRy2-ZBAAWtpoFjEaGkNBPNVFAtXwfj8U=.24d43d1b-03d6-42a6-a036-b1c55fe156ac@github.com>
 <dobvEKxlc9DXft9y67QNUTWZsJtC_XCvOaPajJQ83Pg=.f59cd6d8-e110-40c8-8b8a-22f2e224aeff@github.com>
 <fvt_Tj5UwTHYS9yPGAOZL9VwitgjJAtVXWGJ5Yvthao=.4d54187c-e287-48c2-9f81-793523c0c720@github.com>
 <3aOD4KfYXvu_fe2JRGevhkCsChzQN1FfT6rwZl5Qytk=.82cfe6f8-3026-419b-9961-6cc63b16d8d8@github.com>
Message-ID: <rn6v7GqMq5f16LyoZwdZKwY8ADofNNlJdDPuHE6L2us=.f49ab91c-b3ff-4bc5-9cc1-0fe3a952d91a@github.com>

On Fri, 8 Jan 2021 16:50:24 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> I checked the code of ClassValue and it can be assumed that it publishes associated values safely. The proof is that it keeps values that it publishes assigned to the final field `java.lang.ClassValue.Entry#value`.
>
> So, are you saying the solution where I kept the fields volatile and initialized them with `Map.of()` is safe? If so, that'd be good news; I'm inclined these days to write as much null-free code as possible :-)

Yes, the pre-initialized fields to Map.of() are safe regardless of whether they are volatile or not (so I would keep them non-volatile to optimize fast-path). Because the BiClassValues instance is published safely to other threads via ClassValue and because you never assign null to the fields later on.

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

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

From valeriep at openjdk.java.net  Fri Jan  8 19:38:59 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 8 Jan 2021 19:38:59 GMT
Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires
 SunJCE's classes
In-Reply-To: <u0MKmmnw4k2MnkDD-a26NsLCRk1NEtbf9MY4MHSPa6Y=.9d02a25d-9eb8-4ed2-88c8-9d239be0f7df@github.com>
References: <u0MKmmnw4k2MnkDD-a26NsLCRk1NEtbf9MY4MHSPa6Y=.9d02a25d-9eb8-4ed2-88c8-9d239be0f7df@github.com>
Message-ID: <2W16hPK_xZwzfPMWUg7S4aadNREfN5uAgX147J3-wbM=.c61cb3c9-66fa-45ab-8ea7-1b32b95302a8@github.com>

On Wed, 6 Jan 2021 15:33:59 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> As described in JDK-8259319 [1], this fix proposal is to set proper access permissions so the SunPKCS11 provider can create instances of SunJCE classes when a Security Manager is installed and the fallback scheme is used.
> 
> No regressions found in jdk/sun/security/pkcs11 tests category.
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8259319

test/jdk/sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java line 96:

> 94:     }
> 95: 
> 96: }

nit: add a newline here, to get rid of the red icon...

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

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

From valeriep at openjdk.java.net  Fri Jan  8 19:42:04 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 8 Jan 2021 19:42:04 GMT
Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires
 SunJCE's classes
In-Reply-To: <u0MKmmnw4k2MnkDD-a26NsLCRk1NEtbf9MY4MHSPa6Y=.9d02a25d-9eb8-4ed2-88c8-9d239be0f7df@github.com>
References: <u0MKmmnw4k2MnkDD-a26NsLCRk1NEtbf9MY4MHSPa6Y=.9d02a25d-9eb8-4ed2-88c8-9d239be0f7df@github.com>
Message-ID: <ADrX8fcltkRQ2DTqDTGvgSLKzp9FGNJ1ZiOsSOpF9rQ=.bfacd08e-856e-4718-823a-69b0259e69be@github.com>

On Wed, 6 Jan 2021 15:33:59 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> As described in JDK-8259319 [1], this fix proposal is to set proper access permissions so the SunPKCS11 provider can create instances of SunJCE classes when a Security Manager is installed and the fallback scheme is used.
> 
> No regressions found in jdk/sun/security/pkcs11 tests category.
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8259319

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java line 102:

> 100:                         }
> 101:                     }
> 102:                 });

Sean's suggestion is to add additional arguments here, e.g. null, new RuntimePermission("accessClassInPackage." + <pkgName>).

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

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

From rriggs at openjdk.java.net  Fri Jan  8 20:39:02 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 8 Jan 2021 20:39:02 GMT
Subject: RFR: 8259493: [test] Use HexFormat instead of adhoc hex utilities in
 network code and locale SoftKeys
Message-ID: <A86gsCKIH4koAWtClTDlzOBeAKuyfAzs-ABay_DK970=.3c82dba4-0ef4-4cdc-b743-eeee1ffdd9c9@github.com>

Cleanup of tests test/jdk/java/net and test/jdk/sun/net that format hexadecimal strings to use java.util.HexFormat methods.
Also in tests test/jdk/java/util/Locale/SoftKeys.

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

Commit messages:
 - 8259493: [test] Use HexFormat instead of adhoc hex utilities in network code and locale SoftKeys

Changes: https://git.openjdk.java.net/jdk/pull/2009/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2009&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259493
  Stats: 75 lines in 5 files changed: 2 ins; 63 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2009.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2009/head:pull/2009

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

From lancea at openjdk.java.net  Fri Jan  8 20:43:57 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 8 Jan 2021 20:43:57 GMT
Subject: RFR: 8259493: [test] Use HexFormat instead of adhoc hex utilities
 in network code and locale SoftKeys
In-Reply-To: <A86gsCKIH4koAWtClTDlzOBeAKuyfAzs-ABay_DK970=.3c82dba4-0ef4-4cdc-b743-eeee1ffdd9c9@github.com>
References: <A86gsCKIH4koAWtClTDlzOBeAKuyfAzs-ABay_DK970=.3c82dba4-0ef4-4cdc-b743-eeee1ffdd9c9@github.com>
Message-ID: <Fmk9868BKjH_pS1R9siMX-fyJUPdKNVhjPQ-6MtxhCs=.17e68a26-84a4-4b14-8813-d091df3f8c81@github.com>

On Fri, 8 Jan 2021 20:34:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Cleanup of tests test/jdk/java/net and test/jdk/sun/net that format hexadecimal strings to use java.util.HexFormat methods.
> Also in tests test/jdk/java/util/Locale/SoftKeys.

Looks good Roger.  Nice cleanup.

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

Marked as reviewed by lancea (Reviewer).

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

From naoto at openjdk.java.net  Fri Jan  8 20:56:00 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 8 Jan 2021 20:56:00 GMT
Subject: RFR: 8259493: [test] Use HexFormat instead of adhoc hex utilities
 in network code and locale SoftKeys
In-Reply-To: <A86gsCKIH4koAWtClTDlzOBeAKuyfAzs-ABay_DK970=.3c82dba4-0ef4-4cdc-b743-eeee1ffdd9c9@github.com>
References: <A86gsCKIH4koAWtClTDlzOBeAKuyfAzs-ABay_DK970=.3c82dba4-0ef4-4cdc-b743-eeee1ffdd9c9@github.com>
Message-ID: <ZsqqnMU53jR8hwtwy_JcHTwwXgZlM9MKg6mCB_XdHrA=.1a55a1f3-85d2-4dbd-a935-6014cb0ed835@github.com>

On Fri, 8 Jan 2021 20:34:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Cleanup of tests test/jdk/java/net and test/jdk/sun/net that format hexadecimal strings to use java.util.HexFormat methods.
> Also in tests test/jdk/java/util/Locale/SoftKeys.

+1

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

Marked as reviewed by naoto (Reviewer).

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

From mbalao at openjdk.java.net  Fri Jan  8 21:30:14 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Fri, 8 Jan 2021 21:30:14 GMT
Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires
 SunJCE's classes [v2]
In-Reply-To: <u0MKmmnw4k2MnkDD-a26NsLCRk1NEtbf9MY4MHSPa6Y=.9d02a25d-9eb8-4ed2-88c8-9d239be0f7df@github.com>
References: <u0MKmmnw4k2MnkDD-a26NsLCRk1NEtbf9MY4MHSPa6Y=.9d02a25d-9eb8-4ed2-88c8-9d239be0f7df@github.com>
Message-ID: <AT4umlZ1DhQNj2RkUXyIXqmIGCBTPeEcj56e3iX8F-g=.1f3459e5-c480-41bb-bf54-eb50335936aa@github.com>

> As described in JDK-8259319 [1], this fix proposal is to set proper access permissions so the SunPKCS11 provider can create instances of SunJCE classes when a Security Manager is installed and the fallback scheme is used.
> 
> No regressions found in jdk/sun/security/pkcs11 tests category.
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8259319

Martin Balao has updated the pull request incrementally with two additional commits since the last revision:

 - Limit P11Util::getProvider privileged access to the required 'accessClassInPackage' RuntimePermission only.
 - New line character inserted at the end of IllegalPackageAccess.java test file

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1961/files
  - new: https://git.openjdk.java.net/jdk/pull/1961/files/2fcfa69a..5e1e0a97

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

  Stats: 23 lines in 2 files changed: 10 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1961.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1961/head:pull/1961

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

From mbalao at openjdk.java.net  Fri Jan  8 21:30:14 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Fri, 8 Jan 2021 21:30:14 GMT
Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires
 SunJCE's classes
In-Reply-To: <EenNcVFNV3ZMLJT-KvaxLm0Zilkt7VVgk_0tiVlj-rs=.df94bb74-11c1-4167-af17-b22f7eb66ee9@github.com>
References: <u0MKmmnw4k2MnkDD-a26NsLCRk1NEtbf9MY4MHSPa6Y=.9d02a25d-9eb8-4ed2-88c8-9d239be0f7df@github.com>
 <EenNcVFNV3ZMLJT-KvaxLm0Zilkt7VVgk_0tiVlj-rs=.df94bb74-11c1-4167-af17-b22f7eb66ee9@github.com>
Message-ID: <eakfS5KJXxvrEu-bn3Q0KYL253uAi4ILYnphpORPdwM=.9acc7945-b2a7-47db-a010-42de55e261de@github.com>

On Thu, 7 Jan 2021 19:29:29 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> As described in JDK-8259319 [1], this fix proposal is to set proper access permissions so the SunPKCS11 provider can create instances of SunJCE classes when a Security Manager is installed and the fallback scheme is used.
>> 
>> No regressions found in jdk/sun/security/pkcs11 tests category.
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8259319
>
> Obscure bug, thanks for report and the fix. I will take a look.

New proposal limiting the privileges in P11Util::getProvider method and adding a new line character at the end of the IllegalPackageAccess test file.

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

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

From mbalao at openjdk.java.net  Fri Jan  8 21:30:15 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Fri, 8 Jan 2021 21:30:15 GMT
Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires
 SunJCE's classes [v2]
In-Reply-To: <dhc_yeLFkK-0o8cwc6Aqa95ZE_e5sOKt9FU0ACn3y-c=.7bbb66ec-6ce4-493b-a5da-bddb21c85c7c@github.com>
References: <u0MKmmnw4k2MnkDD-a26NsLCRk1NEtbf9MY4MHSPa6Y=.9d02a25d-9eb8-4ed2-88c8-9d239be0f7df@github.com>
 <dhc_yeLFkK-0o8cwc6Aqa95ZE_e5sOKt9FU0ACn3y-c=.7bbb66ec-6ce4-493b-a5da-bddb21c85c7c@github.com>
Message-ID: <5L1bIDYvFJJ8NBhxvBj7umjZ2o7oVgE6Ure2UBOIOkI=.738f45ea-898c-419d-bb56-f16925c7c302@github.com>

On Thu, 7 Jan 2021 21:23:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Martin Balao has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Limit P11Util::getProvider privileged access to the required 'accessClassInPackage' RuntimePermission only.
>>  - New line character inserted at the end of IllegalPackageAccess.java test file
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java line 90:
> 
>> 88:         p = Security.getProvider(providerName);
>> 89:         if (p == null) {
>> 90:             p = AccessController.doPrivileged(
> 
> Could you use the limited version of doPrivileged and only assert the permissions that are strictly necessary to instantiate a provider?

Yes, makes sense. Thanks for your feedback.

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

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

From mbalao at openjdk.java.net  Fri Jan  8 21:30:16 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Fri, 8 Jan 2021 21:30:16 GMT
Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires
 SunJCE's classes [v2]
In-Reply-To: <2W16hPK_xZwzfPMWUg7S4aadNREfN5uAgX147J3-wbM=.c61cb3c9-66fa-45ab-8ea7-1b32b95302a8@github.com>
References: <u0MKmmnw4k2MnkDD-a26NsLCRk1NEtbf9MY4MHSPa6Y=.9d02a25d-9eb8-4ed2-88c8-9d239be0f7df@github.com>
 <2W16hPK_xZwzfPMWUg7S4aadNREfN5uAgX147J3-wbM=.c61cb3c9-66fa-45ab-8ea7-1b32b95302a8@github.com>
Message-ID: <h3GQc2YQCDIlDgCBR3Oc1x5FKTinPdJIpCiRaRJ28XM=.2b366f4b-1c72-45c9-ae89-4d715ac0b903@github.com>

On Fri, 8 Jan 2021 19:35:47 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Martin Balao has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Limit P11Util::getProvider privileged access to the required 'accessClassInPackage' RuntimePermission only.
>>  - New line character inserted at the end of IllegalPackageAccess.java test file
>
> test/jdk/sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java line 96:
> 
>> 94:     }
>> 95: 
>> 96: }
> 
> nit: add a newline here, to get rid of the red icon...

Yes, sure. Thanks for your feedback.

> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java line 102:
> 
>> 100:                         }
>> 101:                     }
>> 102:                 });
> 
> Sean's suggestion is to add additional arguments here, e.g. null, new RuntimePermission("accessClassInPackage." + <pkgName>).

Yes, replied to Sean above. Thanks.

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

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

From rriggs at openjdk.java.net  Fri Jan  8 21:34:57 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 8 Jan 2021 21:34:57 GMT
Subject: Integrated: 8259493: [test] Use HexFormat instead of adhoc hex
 utilities in network code and locale SoftKeys
In-Reply-To: <A86gsCKIH4koAWtClTDlzOBeAKuyfAzs-ABay_DK970=.3c82dba4-0ef4-4cdc-b743-eeee1ffdd9c9@github.com>
References: <A86gsCKIH4koAWtClTDlzOBeAKuyfAzs-ABay_DK970=.3c82dba4-0ef4-4cdc-b743-eeee1ffdd9c9@github.com>
Message-ID: <d-uKMg8n04jGZDFxbBQ-FccQM9roqOuVNwTBsvj0QUw=.ea99a86e-6d26-4bfb-a623-2e02d724f6df@github.com>

On Fri, 8 Jan 2021 20:34:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Cleanup of tests test/jdk/java/net and test/jdk/sun/net that format hexadecimal strings to use java.util.HexFormat methods.
> Also in tests test/jdk/java/util/Locale/SoftKeys.

This pull request has now been integrated.

Changeset: 876c7fb5
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/876c7fb5
Stats:     75 lines in 5 files changed: 2 ins; 63 del; 10 mod

8259493: [test] Use HexFormat instead of adhoc hex utilities in network code and locale SoftKeys

Reviewed-by: lancea, naoto

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

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

From rriggs at openjdk.java.net  Fri Jan  8 21:35:53 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 8 Jan 2021 21:35:53 GMT
Subject: Integrated: 8258796: [test] Apply HexFormat to tests for java.security
In-Reply-To: <uqMxr0rtpoILbqnGodp5oCz-Uhq6CEUHta-HGFZdpAo=.b20ecd37-1d98-4435-8468-232f32e15cf0@github.com>
References: <uqMxr0rtpoILbqnGodp5oCz-Uhq6CEUHta-HGFZdpAo=.b20ecd37-1d98-4435-8468-232f32e15cf0@github.com>
Message-ID: <Kclo-mVR128QHGcxbMIJ4R3qjmLJraFvY-ok2jBFZPs=.80a4d817-ab5f-4b90-849a-f676b3fd82be@github.com>

On Fri, 8 Jan 2021 15:43:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Followup to the addition of java.util.HexFormat.  
> Uses of adhoc hexadecimal conversions are replaced with HexFormat.
> Redundant utility methods are modified or removed.
> In a few places the data being printed is ASN.1 and the test utility HexPrinter with the ASNFormatter is added.

This pull request has now been integrated.

Changeset: 628c546b
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/628c546b
Stats:     758 lines in 43 files changed: 81 ins; 466 del; 211 mod

8258796: [test] Apply HexFormat to tests for java.security

Reviewed-by: xuelei

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

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

From redestad at openjdk.java.net  Fri Jan  8 22:41:05 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 8 Jan 2021 22:41:05 GMT
Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests
Message-ID: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>

- The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration
- Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization.
- Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence.

Baseline:
                              (digesterName)  (length)    Cnt     Score      Error   Units
MessageDigests.digest                                MD5        16     15  2714.307 ?   21.133  ops/ms
MessageDigests.digest                                MD5      1024     15   318.087 ?    0.637  ops/ms
MessageDigests.digest                              SHA-1        16     15  1387.266 ?   40.932  ops/ms
MessageDigests.digest                              SHA-1      1024     15   109.273 ?    0.149  ops/ms
MessageDigests.digest                            SHA-256        16     15   995.566 ?   21.186  ops/ms
MessageDigests.digest                            SHA-256      1024     15    89.104 ?    0.079  ops/ms
MessageDigests.digest                            SHA-512        16     15   803.030 ?   15.722  ops/ms
MessageDigests.digest                            SHA-512      1024     15   115.611 ?    0.234  ops/ms
MessageDigests.getAndDigest                          MD5        16     15  2190.367 ?   97.037  ops/ms
MessageDigests.getAndDigest                          MD5      1024     15   302.903 ?    1.809  ops/ms
MessageDigests.getAndDigest                        SHA-1        16     15  1262.656 ?   43.751  ops/ms
MessageDigests.getAndDigest                        SHA-1      1024     15   104.889 ?    3.554  ops/ms
MessageDigests.getAndDigest                      SHA-256        16     15   914.541 ?   55.621  ops/ms
MessageDigests.getAndDigest                      SHA-256      1024     15    85.708 ?    1.394  ops/ms
MessageDigests.getAndDigest                      SHA-512        16     15   737.719 ?   53.671  ops/ms
MessageDigests.getAndDigest                      SHA-512      1024     15   112.307 ?    1.950  ops/ms

GC:
MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   312.011 ?    0.005    B/op
MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.020 ?    0.006    B/op
MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   544.019 ?    0.016    B/op
MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15  1056.037 ?    0.003    B/op

Target:
Benchmark                                 (digesterName)  (length)    Cnt     Score      Error   Units
MessageDigests.digest                                MD5        16     15  3134.462 ?   43.685  ops/ms
MessageDigests.digest                                MD5      1024     15   323.667 ?    0.633  ops/ms
MessageDigests.digest                              SHA-1        16     15  1418.742 ?   38.223  ops/ms
MessageDigests.digest                              SHA-1      1024     15   110.178 ?    0.788  ops/ms
MessageDigests.digest                            SHA-256        16     15  1037.949 ?   21.214  ops/ms
MessageDigests.digest                            SHA-256      1024     15    89.671 ?    0.228  ops/ms
MessageDigests.digest                            SHA-512        16     15   812.028 ?   39.489  ops/ms
MessageDigests.digest                            SHA-512      1024     15   116.738 ?    0.249  ops/ms
MessageDigests.getAndDigest                          MD5        16     15  2314.379 ?  229.294  ops/ms
MessageDigests.getAndDigest                          MD5      1024     15   307.835 ?    5.730  ops/ms
MessageDigests.getAndDigest                        SHA-1        16     15  1326.887 ?   63.263  ops/ms
MessageDigests.getAndDigest                        SHA-1      1024     15   106.611 ?    2.292  ops/ms
MessageDigests.getAndDigest                      SHA-256        16     15   961.589 ?   82.052  ops/ms
MessageDigests.getAndDigest                      SHA-256      1024     15    88.646 ?    0.194  ops/ms
MessageDigests.getAndDigest                      SHA-512        16     15   775.417 ?   56.775  ops/ms
MessageDigests.getAndDigest                      SHA-512      1024     15   112.904 ?    2.014  ops/ms

GC
MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   232.009 ?    0.006    B/op
MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.021 ?    0.001    B/op
MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   272.012 ?    0.015    B/op
MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15   400.017 ?    0.019    B/op

For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW.

For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test.

I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show.

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

Commit messages:
 - Remove unused Unsafe import
 - Harmonize MD4 impl, remove now-redundant checks from ByteArrayAccess (VHs do bounds checks, most of which will be optimized away)
 - Merge branch 'master' into improve_md5
 - Apply allocation avoiding optimizations to all SHA versions sharing structural similarities with MD5
 - Remove unused reverseBytes imports
 - Copyrights
 - Fix copy-paste error
 - Various fixes (IDE stopped IDEing..)
 - Add imports
 - mismatched parens
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/090bd3af...e1c943c5

Changes: https://git.openjdk.java.net/jdk/pull/1855/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1855&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259498
  Stats: 649 lines in 8 files changed: 83 ins; 344 del; 222 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1855.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1855/head:pull/1855

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

From github.com+14116124+dellcliff at openjdk.java.net  Fri Jan  8 22:41:05 2021
From: github.com+14116124+dellcliff at openjdk.java.net (DellCliff)
Date: Fri, 8 Jan 2021 22:41:05 GMT
Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests
In-Reply-To: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
References: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
Message-ID: <Pn3d8r5Xx1SOhCSiU-aXvab87-uq1Llbv0xngYxUxMU=.bf269dd2-c111-4f13-b908-53b04d882d9a@github.com>

On Sun, 20 Dec 2020 20:27:03 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration
> - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization.
> - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence.
> 
> Baseline:
>                               (digesterName)  (length)    Cnt     Score      Error   Units
> MessageDigests.digest                                MD5        16     15  2714.307 ?   21.133  ops/ms
> MessageDigests.digest                                MD5      1024     15   318.087 ?    0.637  ops/ms
> MessageDigests.digest                              SHA-1        16     15  1387.266 ?   40.932  ops/ms
> MessageDigests.digest                              SHA-1      1024     15   109.273 ?    0.149  ops/ms
> MessageDigests.digest                            SHA-256        16     15   995.566 ?   21.186  ops/ms
> MessageDigests.digest                            SHA-256      1024     15    89.104 ?    0.079  ops/ms
> MessageDigests.digest                            SHA-512        16     15   803.030 ?   15.722  ops/ms
> MessageDigests.digest                            SHA-512      1024     15   115.611 ?    0.234  ops/ms
> MessageDigests.getAndDigest                          MD5        16     15  2190.367 ?   97.037  ops/ms
> MessageDigests.getAndDigest                          MD5      1024     15   302.903 ?    1.809  ops/ms
> MessageDigests.getAndDigest                        SHA-1        16     15  1262.656 ?   43.751  ops/ms
> MessageDigests.getAndDigest                        SHA-1      1024     15   104.889 ?    3.554  ops/ms
> MessageDigests.getAndDigest                      SHA-256        16     15   914.541 ?   55.621  ops/ms
> MessageDigests.getAndDigest                      SHA-256      1024     15    85.708 ?    1.394  ops/ms
> MessageDigests.getAndDigest                      SHA-512        16     15   737.719 ?   53.671  ops/ms
> MessageDigests.getAndDigest                      SHA-512      1024     15   112.307 ?    1.950  ops/ms
> 
> GC:
> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   312.011 ?    0.005    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.020 ?    0.006    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   544.019 ?    0.016    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15  1056.037 ?    0.003    B/op
> 
> Target:
> Benchmark                                 (digesterName)  (length)    Cnt     Score      Error   Units
> MessageDigests.digest                                MD5        16     15  3134.462 ?   43.685  ops/ms
> MessageDigests.digest                                MD5      1024     15   323.667 ?    0.633  ops/ms
> MessageDigests.digest                              SHA-1        16     15  1418.742 ?   38.223  ops/ms
> MessageDigests.digest                              SHA-1      1024     15   110.178 ?    0.788  ops/ms
> MessageDigests.digest                            SHA-256        16     15  1037.949 ?   21.214  ops/ms
> MessageDigests.digest                            SHA-256      1024     15    89.671 ?    0.228  ops/ms
> MessageDigests.digest                            SHA-512        16     15   812.028 ?   39.489  ops/ms
> MessageDigests.digest                            SHA-512      1024     15   116.738 ?    0.249  ops/ms
> MessageDigests.getAndDigest                          MD5        16     15  2314.379 ?  229.294  ops/ms
> MessageDigests.getAndDigest                          MD5      1024     15   307.835 ?    5.730  ops/ms
> MessageDigests.getAndDigest                        SHA-1        16     15  1326.887 ?   63.263  ops/ms
> MessageDigests.getAndDigest                        SHA-1      1024     15   106.611 ?    2.292  ops/ms
> MessageDigests.getAndDigest                      SHA-256        16     15   961.589 ?   82.052  ops/ms
> MessageDigests.getAndDigest                      SHA-256      1024     15    88.646 ?    0.194  ops/ms
> MessageDigests.getAndDigest                      SHA-512        16     15   775.417 ?   56.775  ops/ms
> MessageDigests.getAndDigest                      SHA-512      1024     15   112.904 ?    2.014  ops/ms
> 
> GC
> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   232.009 ?    0.006    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.021 ?    0.001    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   272.012 ?    0.015    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15   400.017 ?    0.019    B/op
> 
> For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW.
> 
> For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test.
> 
> I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show.

Since `java.util.UUID` and `sun.security.provider.MD5` are both in `java.base`, would it make sense to create new instances by calling `new MD5()` instead of `java.security.MessageDigest.getInstance("MD5")` and bypassing the whole MessageDigest logic?

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

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

From github.com+14116124+dellcliff at openjdk.java.net  Fri Jan  8 22:41:06 2021
From: github.com+14116124+dellcliff at openjdk.java.net (DellCliff)
Date: Fri, 8 Jan 2021 22:41:06 GMT
Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests
In-Reply-To: <Pn3d8r5Xx1SOhCSiU-aXvab87-uq1Llbv0xngYxUxMU=.bf269dd2-c111-4f13-b908-53b04d882d9a@github.com>
References: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
 <Pn3d8r5Xx1SOhCSiU-aXvab87-uq1Llbv0xngYxUxMU=.bf269dd2-c111-4f13-b908-53b04d882d9a@github.com>
Message-ID: <-U8jAG-h-jY8A4fC0qLCt8VK3hKfblzH-MHp-k7cppA=.f604d5fe-a835-49a2-aec9-d9283275603e@github.com>

On Tue, 5 Jan 2021 21:51:51 GMT, DellCliff <github.com+14116124+DellCliff at openjdk.org> wrote:

>> - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration
>> - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization.
>> - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence.
>> 
>> Baseline:
>>                               (digesterName)  (length)    Cnt     Score      Error   Units
>> MessageDigests.digest                                MD5        16     15  2714.307 ?   21.133  ops/ms
>> MessageDigests.digest                                MD5      1024     15   318.087 ?    0.637  ops/ms
>> MessageDigests.digest                              SHA-1        16     15  1387.266 ?   40.932  ops/ms
>> MessageDigests.digest                              SHA-1      1024     15   109.273 ?    0.149  ops/ms
>> MessageDigests.digest                            SHA-256        16     15   995.566 ?   21.186  ops/ms
>> MessageDigests.digest                            SHA-256      1024     15    89.104 ?    0.079  ops/ms
>> MessageDigests.digest                            SHA-512        16     15   803.030 ?   15.722  ops/ms
>> MessageDigests.digest                            SHA-512      1024     15   115.611 ?    0.234  ops/ms
>> MessageDigests.getAndDigest                          MD5        16     15  2190.367 ?   97.037  ops/ms
>> MessageDigests.getAndDigest                          MD5      1024     15   302.903 ?    1.809  ops/ms
>> MessageDigests.getAndDigest                        SHA-1        16     15  1262.656 ?   43.751  ops/ms
>> MessageDigests.getAndDigest                        SHA-1      1024     15   104.889 ?    3.554  ops/ms
>> MessageDigests.getAndDigest                      SHA-256        16     15   914.541 ?   55.621  ops/ms
>> MessageDigests.getAndDigest                      SHA-256      1024     15    85.708 ?    1.394  ops/ms
>> MessageDigests.getAndDigest                      SHA-512        16     15   737.719 ?   53.671  ops/ms
>> MessageDigests.getAndDigest                      SHA-512      1024     15   112.307 ?    1.950  ops/ms
>> 
>> GC:
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   312.011 ?    0.005    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.020 ?    0.006    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   544.019 ?    0.016    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15  1056.037 ?    0.003    B/op
>> 
>> Target:
>> Benchmark                                 (digesterName)  (length)    Cnt     Score      Error   Units
>> MessageDigests.digest                                MD5        16     15  3134.462 ?   43.685  ops/ms
>> MessageDigests.digest                                MD5      1024     15   323.667 ?    0.633  ops/ms
>> MessageDigests.digest                              SHA-1        16     15  1418.742 ?   38.223  ops/ms
>> MessageDigests.digest                              SHA-1      1024     15   110.178 ?    0.788  ops/ms
>> MessageDigests.digest                            SHA-256        16     15  1037.949 ?   21.214  ops/ms
>> MessageDigests.digest                            SHA-256      1024     15    89.671 ?    0.228  ops/ms
>> MessageDigests.digest                            SHA-512        16     15   812.028 ?   39.489  ops/ms
>> MessageDigests.digest                            SHA-512      1024     15   116.738 ?    0.249  ops/ms
>> MessageDigests.getAndDigest                          MD5        16     15  2314.379 ?  229.294  ops/ms
>> MessageDigests.getAndDigest                          MD5      1024     15   307.835 ?    5.730  ops/ms
>> MessageDigests.getAndDigest                        SHA-1        16     15  1326.887 ?   63.263  ops/ms
>> MessageDigests.getAndDigest                        SHA-1      1024     15   106.611 ?    2.292  ops/ms
>> MessageDigests.getAndDigest                      SHA-256        16     15   961.589 ?   82.052  ops/ms
>> MessageDigests.getAndDigest                      SHA-256      1024     15    88.646 ?    0.194  ops/ms
>> MessageDigests.getAndDigest                      SHA-512        16     15   775.417 ?   56.775  ops/ms
>> MessageDigests.getAndDigest                      SHA-512      1024     15   112.904 ?    2.014  ops/ms
>> 
>> GC
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   232.009 ?    0.006    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.021 ?    0.001    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   272.012 ?    0.015    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15   400.017 ?    0.019    B/op
>> 
>> For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW.
>> 
>> For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test.
>> 
>> I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show.
>
> Since `java.util.UUID` and `sun.security.provider.MD5` are both in `java.base`, would it make sense to create new instances by calling `new MD5()` instead of `java.security.MessageDigest.getInstance("MD5")` and bypassing the whole MessageDigest logic?

Are you sure you're not ending up paying more using a VarHandle and having to cast and using a var args call `(long) LONG_ARRAY_HANDLE.get(buf, ofs);` instead of creating a ByteBuffer once via `ByteBuffer.wrap(buffer).order(ByteOrder.nativeOrder()).asLongBuffer()`?

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

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

From redestad at openjdk.java.net  Fri Jan  8 22:41:06 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 8 Jan 2021 22:41:06 GMT
Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests
In-Reply-To: <lRiAsnEUYx-SVegGg-5x0VzYzPadDDhw5fZjY5guIs0=.17d2bdf5-aa18-4282-9c42-a654f2a672ff@github.com>
References: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
 <Pn3d8r5Xx1SOhCSiU-aXvab87-uq1Llbv0xngYxUxMU=.bf269dd2-c111-4f13-b908-53b04d882d9a@github.com>
 <-U8jAG-h-jY8A4fC0qLCt8VK3hKfblzH-MHp-k7cppA=.f604d5fe-a835-49a2-aec9-d9283275603e@github.com>
 <lRiAsnEUYx-SVegGg-5x0VzYzPadDDhw5fZjY5guIs0=.17d2bdf5-aa18-4282-9c42-a654f2a672ff@github.com>
Message-ID: <CaAWIqQ65gRTYNby5Zy0j8vj2F3m-wikrkxYKw1ojYk=.d44dccc0-0f0b-4517-96e9-44976bf99fb5@github.com>

On Wed, 6 Jan 2021 00:41:29 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Are you sure you're not ending up paying more using a VarHandle and having to cast and using a var args call `(long) LONG_ARRAY_HANDLE.get(buf, ofs);` instead of creating a ByteBuffer once via `ByteBuffer.wrap(buffer).order(ByteOrder.nativeOrder()).asLongBuffer()`?
>
> Hitting up `new MD5()` directly could be a great idea. I expect this would be just as fast as the cache+clone (if not faster), but I'm a bit worried we'd be short-circuiting the ability to install an alternative MD5 provider (which may or may not be a thing we must support..), but it's worth exploring.
> 
> Comparing performance of this against a `ByteBuffer` impl is on my TODO. The `VarHandle` gets heavily inlined and optimized here, though, with performance in my tests similar to the `Unsafe` use in `ByteArrayAccess`.

I've identified a number of optimizations to the plumbing behind `MessageDigest.getDigest(..)` over in #1933 that removes 80-90% of the throughput overhead and all the allocation overhead compared to the `clone()` approach prototyped here. The remaining 20ns/op overhead might not be enough of a concern to do a point fix in `UUID::nameUUIDFromBytes`.

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

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

From redestad at openjdk.java.net  Fri Jan  8 22:41:06 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 8 Jan 2021 22:41:06 GMT
Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests
In-Reply-To: <-U8jAG-h-jY8A4fC0qLCt8VK3hKfblzH-MHp-k7cppA=.f604d5fe-a835-49a2-aec9-d9283275603e@github.com>
References: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
 <Pn3d8r5Xx1SOhCSiU-aXvab87-uq1Llbv0xngYxUxMU=.bf269dd2-c111-4f13-b908-53b04d882d9a@github.com>
 <-U8jAG-h-jY8A4fC0qLCt8VK3hKfblzH-MHp-k7cppA=.f604d5fe-a835-49a2-aec9-d9283275603e@github.com>
Message-ID: <lRiAsnEUYx-SVegGg-5x0VzYzPadDDhw5fZjY5guIs0=.17d2bdf5-aa18-4282-9c42-a654f2a672ff@github.com>

On Tue, 5 Jan 2021 23:08:43 GMT, DellCliff <github.com+14116124+DellCliff at openjdk.org> wrote:

>> Since `java.util.UUID` and `sun.security.provider.MD5` are both in `java.base`, would it make sense to create new instances by calling `new MD5()` instead of `java.security.MessageDigest.getInstance("MD5")` and bypassing the whole MessageDigest logic?
>
> Are you sure you're not ending up paying more using a VarHandle and having to cast and using a var args call `(long) LONG_ARRAY_HANDLE.get(buf, ofs);` instead of creating a ByteBuffer once via `ByteBuffer.wrap(buffer).order(ByteOrder.nativeOrder()).asLongBuffer()`?

Hitting up `new MD5()` directly could be a great idea. I expect this would be just as fast as the cache+clone (if not faster), but I'm a bit worried we'd be short-circuiting the ability to install an alternative MD5 provider (which may or may not be a thing we must support..), but it's worth exploring.

Comparing performance of this against a `ByteBuffer` impl is on my TODO. The `VarHandle` gets heavily inlined and optimized here, though, with performance in my tests similar to the `Unsafe` use in `ByteArrayAccess`.

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

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

From redestad at openjdk.java.net  Fri Jan  8 22:41:06 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 8 Jan 2021 22:41:06 GMT
Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests
In-Reply-To: <CaAWIqQ65gRTYNby5Zy0j8vj2F3m-wikrkxYKw1ojYk=.d44dccc0-0f0b-4517-96e9-44976bf99fb5@github.com>
References: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
 <Pn3d8r5Xx1SOhCSiU-aXvab87-uq1Llbv0xngYxUxMU=.bf269dd2-c111-4f13-b908-53b04d882d9a@github.com>
 <-U8jAG-h-jY8A4fC0qLCt8VK3hKfblzH-MHp-k7cppA=.f604d5fe-a835-49a2-aec9-d9283275603e@github.com>
 <lRiAsnEUYx-SVegGg-5x0VzYzPadDDhw5fZjY5guIs0=.17d2bdf5-aa18-4282-9c42-a654f2a672ff@github.com>
 <CaAWIqQ65gRTYNby5Zy0j8vj2F3m-wikrkxYKw1ojYk=.d44dccc0-0f0b-4517-96e9-44976bf99fb5@github.com>
Message-ID: <GDqNO-QP0nohRA2aAVxzMrRLiZg7WGiVSG-n-OQobx4=.8c191619-e4ae-43d8-bbde-11b5ac6375d9@github.com>

On Wed, 6 Jan 2021 01:27:52 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Hitting up `new MD5()` directly could be a great idea. I expect this would be just as fast as the cache+clone (if not faster), but I'm a bit worried we'd be short-circuiting the ability to install an alternative MD5 provider (which may or may not be a thing we must support..), but it's worth exploring.
>> 
>> Comparing performance of this against a `ByteBuffer` impl is on my TODO. The `VarHandle` gets heavily inlined and optimized here, though, with performance in my tests similar to the `Unsafe` use in `ByteArrayAccess`.
>
> I've identified a number of optimizations to the plumbing behind `MessageDigest.getDigest(..)` over in #1933 that removes 80-90% of the throughput overhead and all the allocation overhead compared to the `clone()` approach prototyped here. The remaining 20ns/op overhead might not be enough of a concern to do a point fix in `UUID::nameUUIDFromBytes`.

Removing the UUID clone cache and running the microbenchmark along with the changes in #1933:

Benchmark                                                  (size)   Mode  Cnt    Score    Error   Units
UUIDBench.fromType3Bytes                                    20000  thrpt   12    2.182 ?  0.090  ops/us
UUIDBench.fromType3Bytes:?gc.alloc.rate                     20000  thrpt   12  439.020 ? 18.241  MB/sec
UUIDBench.fromType3Bytes:?gc.alloc.rate.norm                20000  thrpt   12  264.022 ?  0.003    B/op

The goal now is if to simplify the digest code and compare alternatives.

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

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

From redestad at openjdk.java.net  Fri Jan  8 22:41:06 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 8 Jan 2021 22:41:06 GMT
Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests
In-Reply-To: <GDqNO-QP0nohRA2aAVxzMrRLiZg7WGiVSG-n-OQobx4=.8c191619-e4ae-43d8-bbde-11b5ac6375d9@github.com>
References: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
 <Pn3d8r5Xx1SOhCSiU-aXvab87-uq1Llbv0xngYxUxMU=.bf269dd2-c111-4f13-b908-53b04d882d9a@github.com>
 <-U8jAG-h-jY8A4fC0qLCt8VK3hKfblzH-MHp-k7cppA=.f604d5fe-a835-49a2-aec9-d9283275603e@github.com>
 <lRiAsnEUYx-SVegGg-5x0VzYzPadDDhw5fZjY5guIs0=.17d2bdf5-aa18-4282-9c42-a654f2a672ff@github.com>
 <CaAWIqQ65gRTYNby5Zy0j8vj2F3m-wikrkxYKw1ojYk=.d44dccc0-0f0b-4517-96e9-44976bf99fb5@github.com>
 <GDqNO-QP0nohRA2aAVxzMrRLiZg7WGiVSG-n-OQobx4=.8c191619-e4ae-43d8-bbde-11b5ac6375d9@github.com>
Message-ID: <uf-mqauyRYR8pTAR30tTSd3wBoJlBWQZNBppVZlEGac=.4e00ca14-4a17-4a67-886e-af16c742f282@github.com>

On Thu, 7 Jan 2021 14:45:03 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I've identified a number of optimizations to the plumbing behind `MessageDigest.getDigest(..)` over in #1933 that removes 80-90% of the throughput overhead and all the allocation overhead compared to the `clone()` approach prototyped here. The remaining 20ns/op overhead might not be enough of a concern to do a point fix in `UUID::nameUUIDFromBytes`.
>
> Removing the UUID clone cache and running the microbenchmark along with the changes in #1933:
> 
> Benchmark                                                  (size)   Mode  Cnt    Score    Error   Units
> UUIDBench.fromType3Bytes                                    20000  thrpt   12    2.182 ?  0.090  ops/us
> UUIDBench.fromType3Bytes:?gc.alloc.rate                     20000  thrpt   12  439.020 ? 18.241  MB/sec
> UUIDBench.fromType3Bytes:?gc.alloc.rate.norm                20000  thrpt   12  264.022 ?  0.003    B/op
> 
> The goal now is if to simplify the digest code and compare alternatives.

I've run various tests and concluded that the `VarHandle`ized code is matching or improving upon the `Unsafe`-riddled code in `ByteArrayAccess`. I then went ahead and consolidated to use similar code pattern in `ByteArrayAccess` for consistency, which amounts to a good cleanup.

With MD5 intrinsics disabled, I get this baseline:

Benchmark                                                  (size)   Mode  Cnt    Score    Error   Units
UUIDBench.fromType3Bytes                                    20000  thrpt   12    1.245 ?  0.077  ops/us
UUIDBench.fromType3Bytes:?gc.alloc.rate.norm                20000  thrpt   12  488.042 ?  0.004    B/op

With the current patch here (not including #1933): 
Benchmark                                                  (size)   Mode  Cnt    Score    Error   Units
UUIDBench.fromType3Bytes                                    20000  thrpt   12    1.431 ?  0.106  ops/us
UUIDBench.fromType3Bytes:?gc.alloc.rate.norm                20000  thrpt   12  408.035 ?  0.006    B/op

If I isolate the `ByteArrayAccess` changes I'm getting performance neutral or slightly better numbers compared to baseline for these tests:

Benchmark                                                  (size)   Mode  Cnt    Score    Error   Units
UUIDBench.fromType3Bytes                                    20000  thrpt   12    1.317 ?  0.092  ops/us
UUIDBench.fromType3Bytes:?gc.alloc.rate.norm                20000  thrpt   12  488.042 ?  0.004    B/op

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

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

From martin at openjdk.java.net  Sat Jan  9 08:20:23 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sat, 9 Jan 2021 08:20:23 GMT
Subject: RFR: 8246585: ForkJoin updates [v5]
In-Reply-To: <EbJWeYHxjbdpK21JU4fPdLxw7g6eNZ0eKJHClg2BYiA=.468750c9-cda0-4101-8919-a8a9882e9d13@github.com>
References: <EbJWeYHxjbdpK21JU4fPdLxw7g6eNZ0eKJHClg2BYiA=.468750c9-cda0-4101-8919-a8a9882e9d13@github.com>
Message-ID: <Rdqi_jN_HbwXz-KSdbR2_Eol713rbRIPjV91YwiUeeM=.4ad7f9f6-12fe-4135-9563-49f26e7421e2@github.com>

> 8246585: ForkJoin updates

Martin Buchholz 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 one additional commit since the last revision:

  JDK-8246585

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1646/files
  - new: https://git.openjdk.java.net/jdk/pull/1646/files/b10694b5..cbd81886

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

  Stats: 20983 lines in 878 files changed: 3582 ins; 8199 del; 9202 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1646.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1646/head:pull/1646

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

From martin at openjdk.java.net  Sat Jan  9 21:00:54 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sat, 9 Jan 2021 21:00:54 GMT
Subject: Integrated: 8246585: ForkJoin updates
In-Reply-To: <EbJWeYHxjbdpK21JU4fPdLxw7g6eNZ0eKJHClg2BYiA=.468750c9-cda0-4101-8919-a8a9882e9d13@github.com>
References: <EbJWeYHxjbdpK21JU4fPdLxw7g6eNZ0eKJHClg2BYiA=.468750c9-cda0-4101-8919-a8a9882e9d13@github.com>
Message-ID: <tzR7uZHHC-ImRIHJ5pjnaeaiu0PuXJ1z3DoFx76hvPU=.dc81cf2a-72b6-45e1-8b52-65ce12904127@github.com>

On Sun, 6 Dec 2020 02:56:34 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> 8246585: ForkJoin updates

This pull request has now been integrated.

Changeset: 5cfa8c94
Author:    Martin Buchholz <martin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5cfa8c94
Stats:     3771 lines in 9 files changed: 1594 ins; 1097 del; 1080 mod

8246585: ForkJoin updates
8229253: forkjoin/FJExceptionTableLeak.java fails "AssertionError: failed to satisfy condition"

Reviewed-by: dl

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

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

From martin at openjdk.java.net  Sat Jan  9 21:11:57 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sat, 9 Jan 2021 21:11:57 GMT
Subject: Integrated: 8246677: LinkedTransferQueue and SynchronousQueue
 synchronization updates
In-Reply-To: <f-rKFJLHQ3uNDT7mIi4gpOXQ5IY1H4IUAoiA7albUWQ=.f0bc6954-66c4-4a99-a252-3abecccfc3d4@github.com>
References: <f-rKFJLHQ3uNDT7mIi4gpOXQ5IY1H4IUAoiA7albUWQ=.f0bc6954-66c4-4a99-a252-3abecccfc3d4@github.com>
Message-ID: <01mC4DHivN_S8x3b-I5AvCNiFdGZOow7va9gqcQIhgA=.c745932b-07a4-4251-9222-abc6fb53f713@github.com>

On Sun, 6 Dec 2020 02:56:04 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> 8246677: LinkedTransferQueue and SynchronousQueue synchronization updates

This pull request has now been integrated.

Changeset: 63e3bd76
Author:    Martin Buchholz <martin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/63e3bd76
Stats:     538 lines in 3 files changed: 143 ins; 294 del; 101 mod

8246677: LinkedTransferQueue and SynchronousQueue synchronization updates

Reviewed-by: alanb, dl

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

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

From martin at openjdk.java.net  Sat Jan  9 22:02:55 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sat, 9 Jan 2021 22:02:55 GMT
Subject: Integrated: 8234131: Miscellaneous changes imported from jsr166 CVS
 2021-01
In-Reply-To: <d2JXMH9trBAaijw5BS8OBBjEKgrW-IotK7LvccWKM1Q=.90eea921-6265-469f-85ee-950f568119ae@github.com>
References: <d2JXMH9trBAaijw5BS8OBBjEKgrW-IotK7LvccWKM1Q=.90eea921-6265-469f-85ee-950f568119ae@github.com>
Message-ID: <vbDN2VsDpA6U2mkBwCTzTkE2ey3HXEX9n5iF_6Riogc=.b7883637-b4c2-44ec-a6e4-76fcbbb1b6a8@github.com>

On Sun, 6 Dec 2020 02:57:03 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> 8234131: Miscellaneous changes imported from jsr166 CVS 2021-01

This pull request has now been integrated.

Changeset: 270014ab
Author:    Martin Buchholz <martin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/270014ab
Stats:     314 lines in 41 files changed: 107 ins; 41 del; 166 mod

8234131: Miscellaneous changes imported from jsr166 CVS 2021-01
8257671: ThreadPoolExecutor.Discard*Policy: rejected tasks are not cancelled

Reviewed-by: alanb, prappo, dl

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

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

From github.com+471021+marschall at openjdk.java.net  Sat Jan  9 23:06:22 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Sat, 9 Jan 2021 23:06:22 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v4]
In-Reply-To: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
Message-ID: <E8UILDsjWetV8n_CS6BsLUpAS9YNOyFup_zlV0uXaNY=.7df5871c-da6d-41e8-a0a5-c39503e50297@github.com>

> Implement three optimiztations for Reader.read(CharBuffer)
> 
> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.

Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision:

  Add unit tests
  
  - add unit test for Reader#read(CharBuffer)
  - add unit test for InputStreamReader#reader(CharBuffer)
  - test with both on-heap and off-heap buffers

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1915/files
  - new: https://git.openjdk.java.net/jdk/pull/1915/files/8d405587..d247b637

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

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

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

From martin at openjdk.java.net  Sat Jan  9 23:46:05 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sat, 9 Jan 2021 23:46:05 GMT
Subject: RFR: 8258217: PriorityBlockingQueue constructor spec and behavior
 mismatch
Message-ID: <Zo76nzySmVbduIkD47cJvhjY7vRiGTJfg8SRAgk2uHU=.77351317-3bfc-4ec5-b734-25c358af7aa1@github.com>

8258217: PriorityBlockingQueue constructor spec and behavior mismatch

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

Commit messages:
 - JDK-8258217

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

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

From martin at openjdk.java.net  Sat Jan  9 23:48:02 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sat, 9 Jan 2021 23:48:02 GMT
Subject: RFR: 8259518: Fixes for rare test failures due to 8246585: ForkJoin
 updates
Message-ID: <-VIPU-q3UICjNvtgxZhViXqNQuMvKXYHZ2DRPU8_9bA=.ca0c886d-6b82-4567-ac83-e3944da3dad5@github.com>

8259518: Fixes for rare test failures due to 8246585: ForkJoin updates

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

Commit messages:
 - JDK-8259518

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

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

From github.com+2996845+bokken at openjdk.java.net  Sun Jan 10 02:01:59 2021
From: github.com+2996845+bokken at openjdk.java.net (Brett Okken)
Date: Sun, 10 Jan 2021 02:01:59 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v4]
In-Reply-To: <E8UILDsjWetV8n_CS6BsLUpAS9YNOyFup_zlV0uXaNY=.7df5871c-da6d-41e8-a0a5-c39503e50297@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <E8UILDsjWetV8n_CS6BsLUpAS9YNOyFup_zlV0uXaNY=.7df5871c-da6d-41e8-a0a5-c39503e50297@github.com>
Message-ID: <tEZQI1hwWbNe6n5aZmAJYWN2xpTqwntGtNNVTIsjQ5Q=.82cbeddb-8468-4b4f-a770-a25b9c5f5acf@github.com>

On Sat, 9 Jan 2021 23:06:22 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Implement three optimiztations for Reader.read(CharBuffer)
>> 
>> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
>> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
>> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
>
> Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add unit tests
>   
>   - add unit test for Reader#read(CharBuffer)
>   - add unit test for InputStreamReader#reader(CharBuffer)
>   - test with both on-heap and off-heap buffers

src/java.base/share/classes/java/io/Reader.java line 198:

> 196:         } else {
> 197:             int remaining = target.remaining();
> 198:             char cbuf[] = new char[Math.min(remaining, TRANSFER_BUFFER_SIZE)];

Would there be value in making this a (lazily created) member variable? That would allow a single instance to be reused. It seems likely that, if one call is made with a direct CharBuffer, subsequent calls will also be made with direct instances (probably same instance?).

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

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

From dl at openjdk.java.net  Sun Jan 10 12:03:54 2021
From: dl at openjdk.java.net (Doug Lea)
Date: Sun, 10 Jan 2021 12:03:54 GMT
Subject: RFR: 8258217: PriorityBlockingQueue constructor spec and behavior
 mismatch
In-Reply-To: <Zo76nzySmVbduIkD47cJvhjY7vRiGTJfg8SRAgk2uHU=.77351317-3bfc-4ec5-b734-25c358af7aa1@github.com>
References: <Zo76nzySmVbduIkD47cJvhjY7vRiGTJfg8SRAgk2uHU=.77351317-3bfc-4ec5-b734-25c358af7aa1@github.com>
Message-ID: <JXQgvv84QyIlbDTn3wMcd5-ON14lyzSGdGRsap90Q50=.f9d75ef5-08dc-4e42-9f90-264cd2fd1a03@github.com>

On Sat, 9 Jan 2021 23:41:24 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> 8258217: PriorityBlockingQueue constructor spec and behavior mismatch

Marked as reviewed by dl (Reviewer).

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

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

From dl at openjdk.java.net  Sun Jan 10 12:04:57 2021
From: dl at openjdk.java.net (Doug Lea)
Date: Sun, 10 Jan 2021 12:04:57 GMT
Subject: RFR: 8259518: Fixes for rare test failures due to 8246585:
 ForkJoin updates
In-Reply-To: <-VIPU-q3UICjNvtgxZhViXqNQuMvKXYHZ2DRPU8_9bA=.ca0c886d-6b82-4567-ac83-e3944da3dad5@github.com>
References: <-VIPU-q3UICjNvtgxZhViXqNQuMvKXYHZ2DRPU8_9bA=.ca0c886d-6b82-4567-ac83-e3944da3dad5@github.com>
Message-ID: <0M7TpBNpabL9p3urbpWZN8ZdH0tT7fwf1jx8LBnyGbY=.6e52491e-6d6e-425a-b451-77b15e8e004f@github.com>

On Sat, 9 Jan 2021 23:44:13 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> 8259518: Fixes for rare test failures due to 8246585: ForkJoin updates

Marked as reviewed by dl (Reviewer).

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

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

From alanb at openjdk.java.net  Sun Jan 10 15:16:53 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 10 Jan 2021 15:16:53 GMT
Subject: RFR: JDK-8259395 Patching automatic module with additional
 packages re-creates module without "requires java.base"
In-Reply-To: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
References: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
Message-ID: <537UDnvslW5FrqoTONgkzQ3eR_BPDBQcAzpigD8FK6A=.78360779-9ae2-4a54-8d1a-37e4883e9894@github.com>

On Fri, 8 Jan 2021 09:38:40 GMT, Johannes Kuhn <github.com+652983+DasBrain at openjdk.org> wrote:

> Simple fix - one line change: https://openjdk.github.io/cr/?repo=jdk&pr=2000&range=00#sdiff-0.
> 
> Most of the changes come from an additional test that fails without this fix:
> 
>      Error: Unable to load main class somelib.test.TestMain in module somelib
>     	java.lang.IllegalAccessError: superclass access check failed: class somelib.test.TestMain (in module somelib) cannot access class java.lang.Object (in module java.base) because module java.base does not export java.lang to module somelib
> 
> As described in JDK-8259395.
> You can view the output of the test without patch here: https://github.com/DasBrain/jdk/runs/1668078245
> 
> Thanks to @AlanBateman for pointing out the right fix.

test/jdk/jdk/modules/scenarios/automaticmodules/RunWithAutomaticModules.java line 186:

> 184:     }
> 185: 
> 186:     /**

The update to ModulePatcher is fine,  that was an oversight that was missed because it's a real corner to have an automatic module be the initial module and patch it to add additional packages at the same time.

The tests for --patch-module are in jdk/tools/launcher/modules/patch. I was planning to add tests there for patching automatic modules when I created the issue (I didn't know you were going to create a PR for it).

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

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

From github.com+652983+dasbrain at openjdk.java.net  Sun Jan 10 15:29:00 2021
From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn)
Date: Sun, 10 Jan 2021 15:29:00 GMT
Subject: RFR: JDK-8259395 Patching automatic module with additional
 packages re-creates module without "requires java.base"
In-Reply-To: <537UDnvslW5FrqoTONgkzQ3eR_BPDBQcAzpigD8FK6A=.78360779-9ae2-4a54-8d1a-37e4883e9894@github.com>
References: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
 <537UDnvslW5FrqoTONgkzQ3eR_BPDBQcAzpigD8FK6A=.78360779-9ae2-4a54-8d1a-37e4883e9894@github.com>
Message-ID: <t3FAIhSjBVi7ENSIz81YHb-KD2OFV4SWdr_G1yS1jtM=.988cf68d-3755-4704-ac70-4432af9d0e2c@github.com>

On Sun, 10 Jan 2021 15:14:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Simple fix - one line change: https://openjdk.github.io/cr/?repo=jdk&pr=2000&range=00#sdiff-0.
>> 
>> Most of the changes come from an additional test that fails without this fix:
>> 
>>      Error: Unable to load main class somelib.test.TestMain in module somelib
>>     	java.lang.IllegalAccessError: superclass access check failed: class somelib.test.TestMain (in module somelib) cannot access class java.lang.Object (in module java.base) because module java.base does not export java.lang to module somelib
>> 
>> As described in JDK-8259395.
>> You can view the output of the test without patch here: https://github.com/DasBrain/jdk/runs/1668078245
>> 
>> Thanks to @AlanBateman for pointing out the right fix.
>
> test/jdk/jdk/modules/scenarios/automaticmodules/RunWithAutomaticModules.java line 186:
> 
>> 184:     }
>> 185: 
>> 186:     /**
> 
> The update to ModulePatcher is fine,  that was an oversight that was missed because it's a real corner to have an automatic module be the initial module and patch it to add additional packages at the same time.
> 
> The tests for --patch-module are in jdk/tools/launcher/modules/patch. I was planning to add tests there for patching automatic modules when I created the issue (I didn't know you were going to create a PR for it).

Choosing the right place for the test was one of the harder parts.

I did choose automaticmodules because it already has most of the necessary machinery already in place.  
But I will move the tests to jdk/tools/launcher/modules/patch.

And making a PR was a shortcut reaction - "Hey, I could do this".

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

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

From github.com+652983+dasbrain at openjdk.java.net  Sun Jan 10 16:35:17 2021
From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn)
Date: Sun, 10 Jan 2021 16:35:17 GMT
Subject: RFR: JDK-8259395 Patching automatic module with additional
 packages re-creates module without "requires java.base" [v2]
In-Reply-To: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
References: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
Message-ID: <phRPzKFFGjrO4lbgHHXut9rNUegy2v9sASLfPTozz_Y=.e0307c63-af2e-4f60-9307-0abf11a653d1@github.com>

> Simple fix - one line change: https://openjdk.github.io/cr/?repo=jdk&pr=2000&range=00#sdiff-0.
> 
> Most of the changes come from an additional test that fails without this fix:
> 
>      Error: Unable to load main class somelib.test.TestMain in module somelib
>     	java.lang.IllegalAccessError: superclass access check failed: class somelib.test.TestMain (in module somelib) cannot access class java.lang.Object (in module java.base) because module java.base does not export java.lang to module somelib
> 
> As described in JDK-8259395.
> You can view the output of the test without patch here: https://github.com/DasBrain/jdk/runs/1668078245
> 
> Thanks to @AlanBateman for pointing out the right fix.

Johannes Kuhn has updated the pull request incrementally with one additional commit since the last revision:

  Move tests to test/jdk/tools/launcher/modules/patch/automatic.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2000/files
  - new: https://git.openjdk.java.net/jdk/pull/2000/files/bf715a8c..73ac7fde

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

  Stats: 176 lines in 4 files changed: 114 ins; 61 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2000.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2000/head:pull/2000

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

From attila at openjdk.java.net  Sun Jan 10 16:59:16 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Sun, 10 Jan 2021 16:59:16 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v6]
In-Reply-To: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
Message-ID: <JdpLmZVBs4TZxwNt2y3lb4caDnF_NizA6GAa5ElC4p4=.8569ad0b-e10f-4981-b57b-55dd5256005d@github.com>

> _(NB: For this leak to occur, an application needs to be either creating and discarding linkers frequently, or creating and discarding class loaders frequently while creating Dynalink type converters for classes in them. Neither is typical usage, although they can occur in dynamic code loading environments such as OSGi.)_
> 
> I'll explain this one in a bit more detail. Dynalink creates and caches method handles for language-specific conversions between types. Each conversion is thus characterized by a `Class` object representing the type converted from, and a `Class` object representing the type converted to, thus they're keyed by a pair of `(Class, Class)`. Java API provides the excellent `ClassValue` class for associating values with a single class, but it lacks the ? admittedly more niche ? facility for associating a value with a pair of classes. I originally solved this problem using something that looks like a `ClassValue<Map<Class<?>, T>>`. I say "looks like" because Dynalink has a specialized `ClassMap` class that works like `Map<Class<?>, T>` but it also goes to some pains to _not_ establish strong references from a class loader to either its children or to unrelated class loaders, for obvious reasons.
> 
> Surprisingly, the problem didn't lie in there, though. The problem was in the fact that `TypeConverterFactory` used `ClassValue` objects that were its non-static anonymous inner classes, and further the values they computed were also of non-static anonymous inner classes. Due to the way `ClassValue` internals work, this led to the `TypeConverterFactory` objects becoming anchored in a GC root of `Class.classValueMap` through the synthetic `this$0` reference chains in said inner classes? talk about non-obvious memory leaks. (I guess there's a lesson in there about not using `ClassValue` as an instance field, but there's a genuine need for them here, so?)
> 
> ? so the first thing I did was I deconstructed all those anonymous inner classes into named static inner classes, and ended up with something that _did_ fix the memory leak (yay!) but at the same time there was a bunch of copying of constructor parameters from outer classes into the inner classes, the whole thing was very clunky with scary amounts of boilerplate. I felt there must exist a better solution.
> 
> And it exists! I ended up replacing the `ClassValue<ClassMap<T>>` construct with a ground-up implementation of `BiClassValue<T>`, representation of lazily computed values associated with a pair of types. This was the right abstraction the `TypeConverterFactory` code needed all along. `BiClassValue<T>` is also not implemented as an abstract class but rather it is a final class and takes a `BiFunction<Class<?>, Class<?>, T>` for computation of its values, thus there's never a risk of making it an instance-specific inner class (well, you still need to be careful with the bifunction lambda?) It also has an even better solution for avoiding strong references to child class loaders.
> 
> And that's why I'm not submitting here the smallest possible point fix to the memory leak, but rather a slightly larger one that architecturally fixes it the right way.
> 
> There are two test classes, they test subtly different scenarios. `TypeConverterFactoryMemoryLeakTest` tests that when a `TypeConverterFactory` instance becomes unreachable, all method handles it created also become eligible for collection. `TypeConverterFactoryRetentionTests` on the other hand test that the factory itself won't prevent class loaders from being collected by virtue of creating converters for them.

Attila Szegedi has updated the pull request incrementally with one additional commit since the last revision:

  Avoid null values in fields again

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1918/files
  - new: https://git.openjdk.java.net/jdk/pull/1918/files/a8d81ebb..cb399d7b

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

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

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

From attila at openjdk.java.net  Sun Jan 10 17:04:19 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Sun, 10 Jan 2021 17:04:19 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v7]
In-Reply-To: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
Message-ID: <4xzM-PeZchhV65P2V2KHn2bmwEWd3HzLOSJLSe4nt2Q=.419fc509-471c-454b-be94-b9c103761103@github.com>

> _(NB: For this leak to occur, an application needs to be either creating and discarding linkers frequently, or creating and discarding class loaders frequently while creating Dynalink type converters for classes in them. Neither is typical usage, although they can occur in dynamic code loading environments such as OSGi.)_
> 
> I'll explain this one in a bit more detail. Dynalink creates and caches method handles for language-specific conversions between types. Each conversion is thus characterized by a `Class` object representing the type converted from, and a `Class` object representing the type converted to, thus they're keyed by a pair of `(Class, Class)`. Java API provides the excellent `ClassValue` class for associating values with a single class, but it lacks the ? admittedly more niche ? facility for associating a value with a pair of classes. I originally solved this problem using something that looks like a `ClassValue<Map<Class<?>, T>>`. I say "looks like" because Dynalink has a specialized `ClassMap` class that works like `Map<Class<?>, T>` but it also goes to some pains to _not_ establish strong references from a class loader to either its children or to unrelated class loaders, for obvious reasons.
> 
> Surprisingly, the problem didn't lie in there, though. The problem was in the fact that `TypeConverterFactory` used `ClassValue` objects that were its non-static anonymous inner classes, and further the values they computed were also of non-static anonymous inner classes. Due to the way `ClassValue` internals work, this led to the `TypeConverterFactory` objects becoming anchored in a GC root of `Class.classValueMap` through the synthetic `this$0` reference chains in said inner classes? talk about non-obvious memory leaks. (I guess there's a lesson in there about not using `ClassValue` as an instance field, but there's a genuine need for them here, so?)
> 
> ? so the first thing I did was I deconstructed all those anonymous inner classes into named static inner classes, and ended up with something that _did_ fix the memory leak (yay!) but at the same time there was a bunch of copying of constructor parameters from outer classes into the inner classes, the whole thing was very clunky with scary amounts of boilerplate. I felt there must exist a better solution.
> 
> And it exists! I ended up replacing the `ClassValue<ClassMap<T>>` construct with a ground-up implementation of `BiClassValue<T>`, representation of lazily computed values associated with a pair of types. This was the right abstraction the `TypeConverterFactory` code needed all along. `BiClassValue<T>` is also not implemented as an abstract class but rather it is a final class and takes a `BiFunction<Class<?>, Class<?>, T>` for computation of its values, thus there's never a risk of making it an instance-specific inner class (well, you still need to be careful with the bifunction lambda?) It also has an even better solution for avoiding strong references to child class loaders.
> 
> And that's why I'm not submitting here the smallest possible point fix to the memory leak, but rather a slightly larger one that architecturally fixes it the right way.
> 
> There are two test classes, they test subtly different scenarios. `TypeConverterFactoryMemoryLeakTest` tests that when a `TypeConverterFactory` instance becomes unreachable, all method handles it created also become eligible for collection. `TypeConverterFactoryRetentionTests` on the other hand test that the factory itself won't prevent class loaders from being collected by virtue of creating converters for them.

Attila Szegedi has updated the pull request incrementally with one additional commit since the last revision:

  Rename ClassLoaderRelation to RetentionDirection; it is better self-documenting this way.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1918/files
  - new: https://git.openjdk.java.net/jdk/pull/1918/files/cb399d7b..81bf988e

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

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

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

From attila at openjdk.java.net  Sun Jan 10 17:04:19 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Sun, 10 Jan 2021 17:04:19 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v7]
In-Reply-To: <rn6v7GqMq5f16LyoZwdZKwY8ADofNNlJdDPuHE6L2us=.f49ab91c-b3ff-4bc5-9cc1-0fe3a952d91a@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
 <zoH9LkGyKKA32SjXotq71dKDFs1-wYLiboY4yvKZwmk=.21ed959b-7e39-42fb-baf1-6d8e856326d5@github.com>
 <lTmAigU7IJZfXkwns9PuXCtgPvowhr2cY26dalEDRG4=.ff495634-8d11-42ac-84ad-9185f676c958@github.com>
 <fNTCiDKRV2h2jzOE1ON6bNWhiovpWHXDz5Kn491fOK8=.3bcce888-dc27-40bf-9e98-5f9f0bde5e70@github.com>
 <W3php0n2KC0PSvw7NfZ2nN4eu1e7rhQbGTH5QDkNGQc=.951f0c81-6c9b-40b3-8d48-ac93ec58b4fe@github.com>
 <3p6wFSLodVRRy2-ZBAAWtpoFjEaGkNBPNVFAtXwfj8U=.24d43d1b-03d6-42a6-a036-b1c55fe156ac@github.com>
 <dobvEKxlc9DXft9y67QNUTWZsJtC_XCvOaPajJQ83Pg=.f59cd6d8-e110-40c8-8b8a-22f2e224aeff@github.com>
 <fvt_Tj5UwTHYS9yPGAOZL9VwitgjJAtVXWGJ5Yvthao=.4d54187c-e287-48c2-9f81-793523c0c720@github.com>
 <3aOD4KfYXvu_fe2JRGevhkCsChzQN1FfT6rwZl5Qytk=.82cfe6f8-3026-419b-9961-6cc63b16d8d8@github.com>
 <rn6v7GqMq5f16LyoZwdZKwY8ADofNNlJdDPuHE6L2us=.f49ab91c-b3ff-4bc5-9cc1-0fe3a952d91a@github.com>
Message-ID: <7EjvqRxHVP05KEfozC-pv8WaQ-hSMKWMaE3oXwcymjE=.19daa9d3-5dae-409f-8d2b-62d76c485b31@github.com>

On Fri, 8 Jan 2021 18:58:03 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> So, are you saying the solution where I kept the fields volatile and initialized them with `Map.of()` is safe? If so, that'd be good news; I'm inclined these days to write as much null-free code as possible :-)
>
> Yes, the pre-initialized fields to Map.of() are safe regardless of whether they are volatile or not (so I would keep them non-volatile to optimize fast-path). Because the BiClassValues instance is published safely to other threads via ClassValue and because you never assign null to the fields later on.

Alright, I made a new hybrid of non-volatile fields and never null fields. Hopefully we're getting to the ideal. Again, I really appreciate all the advice and direction you provided here.

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

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

From plevart at openjdk.java.net  Sun Jan 10 17:20:58 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Sun, 10 Jan 2021 17:20:58 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v7]
In-Reply-To: <7EjvqRxHVP05KEfozC-pv8WaQ-hSMKWMaE3oXwcymjE=.19daa9d3-5dae-409f-8d2b-62d76c485b31@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
 <zoH9LkGyKKA32SjXotq71dKDFs1-wYLiboY4yvKZwmk=.21ed959b-7e39-42fb-baf1-6d8e856326d5@github.com>
 <lTmAigU7IJZfXkwns9PuXCtgPvowhr2cY26dalEDRG4=.ff495634-8d11-42ac-84ad-9185f676c958@github.com>
 <fNTCiDKRV2h2jzOE1ON6bNWhiovpWHXDz5Kn491fOK8=.3bcce888-dc27-40bf-9e98-5f9f0bde5e70@github.com>
 <W3php0n2KC0PSvw7NfZ2nN4eu1e7rhQbGTH5QDkNGQc=.951f0c81-6c9b-40b3-8d48-ac93ec58b4fe@github.com>
 <3p6wFSLodVRRy2-ZBAAWtpoFjEaGkNBPNVFAtXwfj8U=.24d43d1b-03d6-42a6-a036-b1c55fe156ac@github.com>
 <dobvEKxlc9DXft9y67QNUTWZsJtC_XCvOaPajJQ83Pg=.f59cd6d8-e110-40c8-8b8a-22f2e224aeff@github.com>
 <fvt_Tj5UwTHYS9yPGAOZL9VwitgjJAtVXWGJ5Yvthao=.4d54187c-e287-48c2-9f81-793523c0c720@github.com>
 <3aOD4KfYXvu_fe2JRGevhkCsChzQN1FfT6rwZl5Qytk=.82cfe6f8-3026-419b-9961-6cc63b16d8d8@github.com>
 <rn6v7GqMq5f16LyoZwdZKwY8ADofNNlJdDPuHE6L2us=.f49ab91c-b3ff-4bc5-9cc1-0fe3a952d91a@github.com>
 <7EjvqRxHVP05KEfozC-pv8WaQ-hSMKWMaE3
 oXwcymjE=.19daa9d3-5dae-409f-8d2b-62d76c485b31@github.com>
Message-ID: <RTHiNoMONnacG5ALTHxUBT_U9zyo-Dhqc1S9ss6j9nQ=.d831192c-097c-45be-8894-188b0038d995@github.com>

On Sun, 10 Jan 2021 17:01:31 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> Yes, the pre-initialized fields to Map.of() are safe regardless of whether they are volatile or not (so I would keep them non-volatile to optimize fast-path). Because the BiClassValues instance is published safely to other threads via ClassValue and because you never assign null to the fields later on.
>
> Alright, I made a new hybrid of non-volatile fields and never null fields. Hopefully we're getting to the ideal. Again, I really appreciate all the advice and direction you provided here.

Hello Attila,
This looks good to me. Just a question: How frequent are situations where the two classloaders are unrelated?

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

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

From martin at openjdk.java.net  Sun Jan 10 18:23:55 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sun, 10 Jan 2021 18:23:55 GMT
Subject: Integrated: 8258217: PriorityBlockingQueue constructor spec and
 behavior mismatch
In-Reply-To: <Zo76nzySmVbduIkD47cJvhjY7vRiGTJfg8SRAgk2uHU=.77351317-3bfc-4ec5-b734-25c358af7aa1@github.com>
References: <Zo76nzySmVbduIkD47cJvhjY7vRiGTJfg8SRAgk2uHU=.77351317-3bfc-4ec5-b734-25c358af7aa1@github.com>
Message-ID: <CfqBfvWXjW50ewBM7HbdEz0BBgf8A0J7DEL5BPKBL34=.12281c18-2dcf-433f-8d0e-4c02a21ab940@github.com>

On Sat, 9 Jan 2021 23:41:24 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> 8258217: PriorityBlockingQueue constructor spec and behavior mismatch

This pull request has now been integrated.

Changeset: 11d5b047
Author:    Martin Buchholz <martin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/11d5b047
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8258217: PriorityBlockingQueue constructor spec and behavior mismatch

Reviewed-by: dl

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

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

From martin at openjdk.java.net  Sun Jan 10 18:26:55 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sun, 10 Jan 2021 18:26:55 GMT
Subject: RFR: 8259518: Fixes for rare test failures due to 8246585:
 ForkJoin updates
In-Reply-To: <0M7TpBNpabL9p3urbpWZN8ZdH0tT7fwf1jx8LBnyGbY=.6e52491e-6d6e-425a-b451-77b15e8e004f@github.com>
References: <-VIPU-q3UICjNvtgxZhViXqNQuMvKXYHZ2DRPU8_9bA=.ca0c886d-6b82-4567-ac83-e3944da3dad5@github.com>
 <0M7TpBNpabL9p3urbpWZN8ZdH0tT7fwf1jx8LBnyGbY=.6e52491e-6d6e-425a-b451-77b15e8e004f@github.com>
Message-ID: <HThT7M40litYGXGcG5T1J7DGDT1wX1CHAe_cyW-2u34=.1bae63b8-71fc-4172-8e1b-6e9c85533fc8@github.com>

On Sun, 10 Jan 2021 12:01:44 GMT, Doug Lea <dl at openjdk.org> wrote:

>> 8259518: Fixes for rare test failures due to 8246585: ForkJoin updates
>
> Marked as reviewed by dl (Reviewer).

The code is good, but this is actually a fix for 
JDK-8258187 IllegalMonitorStateException in ArrayBlockingQueue
I will fiddle with the PR and JBS metadata.

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

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

From martin at openjdk.java.net  Sun Jan 10 18:40:54 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sun, 10 Jan 2021 18:40:54 GMT
Subject: Integrated: JDK-8258187 IllegalMonitorStateException in
 ArrayBlockingQueue
In-Reply-To: <-VIPU-q3UICjNvtgxZhViXqNQuMvKXYHZ2DRPU8_9bA=.ca0c886d-6b82-4567-ac83-e3944da3dad5@github.com>
References: <-VIPU-q3UICjNvtgxZhViXqNQuMvKXYHZ2DRPU8_9bA=.ca0c886d-6b82-4567-ac83-e3944da3dad5@github.com>
Message-ID: <BFRcRfvdhA7gImgNSADuHqVGMCNM2BlTU0StYe4DlUw=.524b726e-69f2-4854-a217-6ee4404d43cc@github.com>

On Sat, 9 Jan 2021 23:44:13 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> JDK-8258187 IllegalMonitorStateException in ArrayBlockingQueue

This pull request has now been integrated.

Changeset: e7c17408
Author:    Martin Buchholz <martin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e7c17408
Stats:     30 lines in 2 files changed: 22 ins; 0 del; 8 mod

8258187: IllegalMonitorStateException in ArrayBlockingQueue

Reviewed-by: dl

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

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

From attila at openjdk.java.net  Sun Jan 10 19:40:57 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Sun, 10 Jan 2021 19:40:57 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v7]
In-Reply-To: <RTHiNoMONnacG5ALTHxUBT_U9zyo-Dhqc1S9ss6j9nQ=.d831192c-097c-45be-8894-188b0038d995@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
 <zoH9LkGyKKA32SjXotq71dKDFs1-wYLiboY4yvKZwmk=.21ed959b-7e39-42fb-baf1-6d8e856326d5@github.com>
 <lTmAigU7IJZfXkwns9PuXCtgPvowhr2cY26dalEDRG4=.ff495634-8d11-42ac-84ad-9185f676c958@github.com>
 <fNTCiDKRV2h2jzOE1ON6bNWhiovpWHXDz5Kn491fOK8=.3bcce888-dc27-40bf-9e98-5f9f0bde5e70@github.com>
 <W3php0n2KC0PSvw7NfZ2nN4eu1e7rhQbGTH5QDkNGQc=.951f0c81-6c9b-40b3-8d48-ac93ec58b4fe@github.com>
 <3p6wFSLodVRRy2-ZBAAWtpoFjEaGkNBPNVFAtXwfj8U=.24d43d1b-03d6-42a6-a036-b1c55fe156ac@github.com>
 <dobvEKxlc9DXft9y67QNUTWZsJtC_XCvOaPajJQ83Pg=.f59cd6d8-e110-40c8-8b8a-22f2e224aeff@github.com>
 <fvt_Tj5UwTHYS9yPGAOZL9VwitgjJAtVXWGJ5Yvthao=.4d54187c-e287-48c2-9f81-793523c0c720@github.com>
 <3aOD4KfYXvu_fe2JRGevhkCsChzQN1FfT6rwZl5Qytk=.82cfe6f8-3026-419b-9961-6cc63b16d8d8@github.com>
 <rn6v7GqMq5f16LyoZwdZKwY8ADofNNlJdDPuHE6L2us=.f49ab91c-b3ff-4bc5-9cc1-0fe3a952d91a@github.com>
 <7EjvqRxHVP05KEfozC-pv8WaQ-hSMKWMaE3
 oXwcymjE=.19daa9d3-5dae-409f-8d2b-62d76c485b31@github.com>
 <RTHiNoMONnacG5ALTHxUBT_U9zyo-Dhqc1S9ss6j9nQ=.d831192c-097c-45be-8894-188b0038d995@github.com>
Message-ID: <6SyoHul5LMKYpyvpUjmC0fvU4XnURtM9zs2FOxMfKbE=.5ff01a63-89b4-4057-a446-25e3cc7fc50a@github.com>

On Sun, 10 Jan 2021 17:18:37 GMT, Peter Levart <plevart at openjdk.org> wrote:

> How frequent are situations where the two classloaders are unrelated?

I think they'd be extremely unlikely. The only user of these right now is Dynalink's type converter factory. I _can imagine_ a situation where there's a conversion from a dynamic language runtime's internal "object" type to an application-specific Java interface, or from its internal "function object" type to an app-specific Java SAM type, and for some reason the app-specific types aren't in the same or descendant class loader of the language runtime's loader.
Frankly, I'd expect 99.99% of the time, app classes would be in the same-or-descendant class loader relative to the dynamic language runtime types. It'd have to be a really exotic setup for this not to be the case, but I'd rather not second guess the users and provide a reasonable functionality even in this case. 
If you're thinking of rather throwing an exception when they're unrelated? well, we could certainly do that but I give it a mean time of six months before somebody runs into it and asks about it on Stack Overflow.

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

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

From attila at openjdk.java.net  Sun Jan 10 20:01:56 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Sun, 10 Jan 2021 20:01:56 GMT
Subject: RFR: JDK-8259395 Patching automatic module with additional
 packages re-creates module without "requires java.base" [v2]
In-Reply-To: <phRPzKFFGjrO4lbgHHXut9rNUegy2v9sASLfPTozz_Y=.e0307c63-af2e-4f60-9307-0abf11a653d1@github.com>
References: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
 <phRPzKFFGjrO4lbgHHXut9rNUegy2v9sASLfPTozz_Y=.e0307c63-af2e-4f60-9307-0abf11a653d1@github.com>
Message-ID: <qUqZQrJ5BMBsvfHyxoH5UbfOTQ4FTrZYzfqh5FHQCP8=.7c5556f9-fcb0-446b-8f2e-7ba21528bb25@github.com>

On Sun, 10 Jan 2021 16:35:17 GMT, Johannes Kuhn <github.com+652983+DasBrain at openjdk.org> wrote:

>> Simple fix - one line change: https://openjdk.github.io/cr/?repo=jdk&pr=2000&range=00#sdiff-0.
>> 
>> Most of the changes come from an additional test that fails without this fix:
>> 
>>      Error: Unable to load main class somelib.test.TestMain in module somelib
>>     	java.lang.IllegalAccessError: superclass access check failed: class somelib.test.TestMain (in module somelib) cannot access class java.lang.Object (in module java.base) because module java.base does not export java.lang to module somelib
>> 
>> As described in JDK-8259395.
>> You can view the output of the test without patch here: https://github.com/DasBrain/jdk/runs/1668078245
>> 
>> Thanks to @AlanBateman for pointing out the right fix.
>
> Johannes Kuhn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move tests to test/jdk/tools/launcher/modules/patch/automatic.

Looks good aside from that one pesky missing newline.

test/jdk/tools/launcher/modules/patch/automatic/somelib/somelib/Dummy.java line 30:

> 28:         return true;
> 29:     }
> 30: }

No newline at the end of the file. Funny that the whitespace checker doesn't catch this.

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

Changes requested by attila (Reviewer).

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

From martin at openjdk.java.net  Sun Jan 10 20:18:03 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sun, 10 Jan 2021 20:18:03 GMT
Subject: RFR: 8254973: CompletableFuture.ThreadPerTaskExecutor does not throw
 NPE in #execute
Message-ID: <wNjlSLwXm5WwyginmmnnS15iTBgK7lI2u8ECIyjIr1g=.e8bff629-02aa-49c0-a2ab-62e391255e06@github.com>

8254973: CompletableFuture.ThreadPerTaskExecutor does not throw NPE in #execute

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

Commit messages:
 - JDK-8254973

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

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

From dl at openjdk.java.net  Sun Jan 10 22:04:57 2021
From: dl at openjdk.java.net (Doug Lea)
Date: Sun, 10 Jan 2021 22:04:57 GMT
Subject: RFR: 8254973: CompletableFuture.ThreadPerTaskExecutor does not
 throw NPE in #execute
In-Reply-To: <wNjlSLwXm5WwyginmmnnS15iTBgK7lI2u8ECIyjIr1g=.e8bff629-02aa-49c0-a2ab-62e391255e06@github.com>
References: <wNjlSLwXm5WwyginmmnnS15iTBgK7lI2u8ECIyjIr1g=.e8bff629-02aa-49c0-a2ab-62e391255e06@github.com>
Message-ID: <V8Ul1fwSdAYR5ZhryT--TrH0btUfYNGXa3Fet-Rnlo0=.b546a275-fc3d-4318-99d7-a0c427f93f47@github.com>

On Sun, 10 Jan 2021 20:13:07 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> 8254973: CompletableFuture.ThreadPerTaskExecutor does not throw NPE in #execute

Marked as reviewed by dl (Reviewer).

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

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

From plevart at openjdk.java.net  Sun Jan 10 23:33:53 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Sun, 10 Jan 2021 23:33:53 GMT
Subject: RFR: 8198540: Dynalink leaks memory when generating type
 converters [v7]
In-Reply-To: <6SyoHul5LMKYpyvpUjmC0fvU4XnURtM9zs2FOxMfKbE=.5ff01a63-89b4-4057-a446-25e3cc7fc50a@github.com>
References: <LVB_148H9lfj2o4dEa24ADxTg30CYRDOJy9ZF4Q90Og=.eb4e6092-c4c8-4b71-a6f0-5e72ae172f87@github.com>
 <zoH9LkGyKKA32SjXotq71dKDFs1-wYLiboY4yvKZwmk=.21ed959b-7e39-42fb-baf1-6d8e856326d5@github.com>
 <lTmAigU7IJZfXkwns9PuXCtgPvowhr2cY26dalEDRG4=.ff495634-8d11-42ac-84ad-9185f676c958@github.com>
 <fNTCiDKRV2h2jzOE1ON6bNWhiovpWHXDz5Kn491fOK8=.3bcce888-dc27-40bf-9e98-5f9f0bde5e70@github.com>
 <W3php0n2KC0PSvw7NfZ2nN4eu1e7rhQbGTH5QDkNGQc=.951f0c81-6c9b-40b3-8d48-ac93ec58b4fe@github.com>
 <3p6wFSLodVRRy2-ZBAAWtpoFjEaGkNBPNVFAtXwfj8U=.24d43d1b-03d6-42a6-a036-b1c55fe156ac@github.com>
 <dobvEKxlc9DXft9y67QNUTWZsJtC_XCvOaPajJQ83Pg=.f59cd6d8-e110-40c8-8b8a-22f2e224aeff@github.com>
 <fvt_Tj5UwTHYS9yPGAOZL9VwitgjJAtVXWGJ5Yvthao=.4d54187c-e287-48c2-9f81-793523c0c720@github.com>
 <3aOD4KfYXvu_fe2JRGevhkCsChzQN1FfT6rwZl5Qytk=.82cfe6f8-3026-419b-9961-6cc63b16d8d8@github.com>
 <rn6v7GqMq5f16LyoZwdZKwY8ADofNNlJdDPuHE6L2us=.f49ab91c-b3ff-4bc5-9cc1-0fe3a952d91a@github.com>
 <7EjvqRxHVP05KEfozC-pv8WaQ-hSMKWMaE3
 oXwcymjE=.19daa9d3-5dae-409f-8d2b-62d76c485b31@github.com>
 <RTHiNoMONnacG5ALTHxUBT_U9zyo-Dhqc1S9ss6j9nQ=.d831192c-097c-45be-8894-188b0038d995@github.com>
 <6SyoHul5LMKYpyvpUjmC0fvU4XnURtM9zs2FOxMfKbE=.5ff01a63-89b4-4057-a446-25e3cc7fc50a@github.com>
Message-ID: <l2Py3ZiHmhVPB1KR4Vkm9fGgisR8tcC5hfIVUb66WsA=.c9990f5b-96a8-4983-91f6-a8f9c999a5c1@github.com>

On Sun, 10 Jan 2021 19:38:11 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> Hello Attila,
>> This looks good to me. Just a question: How frequent are situations where the two classloaders are unrelated?
>
>> How frequent are situations where the two classloaders are unrelated?
> 
> I think they'd be extremely unlikely. The only user of these right now is Dynalink's type converter factory. I _can imagine_ a situation where there's a conversion from a dynamic language runtime's internal "object" type to an application-specific Java interface, or from its internal "function object" type to an app-specific Java SAM type, and for some reason the app-specific types aren't in the same or descendant class loader of the language runtime's loader.
> Frankly, I'd expect 99.99% of the time, app classes would be in the same-or-descendant class loader relative to the dynamic language runtime types. It'd have to be a really exotic setup for this not to be the case, but I'd rather not second guess the users and provide a reasonable functionality even in this case. 
> If you're thinking of rather throwing an exception when they're unrelated? well, we could certainly do that but I give it a mean time of six months before somebody runs into it and asks about it on Stack Overflow.

Well, I was just thinking if it might be more frequent and would benefit from caching the result too. But if it is not, then what you have now is OK.

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

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

From martin at openjdk.java.net  Sun Jan 10 23:49:56 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sun, 10 Jan 2021 23:49:56 GMT
Subject: Integrated: 8254973: CompletableFuture.ThreadPerTaskExecutor does not
 throw NPE in #execute
In-Reply-To: <wNjlSLwXm5WwyginmmnnS15iTBgK7lI2u8ECIyjIr1g=.e8bff629-02aa-49c0-a2ab-62e391255e06@github.com>
References: <wNjlSLwXm5WwyginmmnnS15iTBgK7lI2u8ECIyjIr1g=.e8bff629-02aa-49c0-a2ab-62e391255e06@github.com>
Message-ID: <bweRQfXgWbxhxxDK6avxdhzIOypHqi1LIBsGDSSGkKA=.cf835793-b8ea-4f94-92b4-a29ec9644840@github.com>

On Sun, 10 Jan 2021 20:13:07 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> 8254973: CompletableFuture.ThreadPerTaskExecutor does not throw NPE in #execute

This pull request has now been integrated.

Changeset: 9154f643
Author:    Martin Buchholz <martin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9154f643
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8254973: CompletableFuture.ThreadPerTaskExecutor does not throw NPE in #execute

Reviewed-by: dl

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

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

From herrick at openjdk.java.net  Mon Jan 11 01:56:56 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 11 Jan 2021 01:56:56 GMT
Subject: Withdrawn: JDK-8189198: Add "forRemoval = true" to Applet APIs
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <W1UkrX-Pby-7JTwj25LZVphkdeZ1merEib-AWXWU93Q=.79b50980-33b7-4b1e-8141-6e6939819f1f@github.com>

On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8189198: Add "forRemoval = true" to Applet APIs

This pull request has been closed without being integrated.

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

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

From github.com+652983+dasbrain at openjdk.java.net  Mon Jan 11 05:12:11 2021
From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn)
Date: Mon, 11 Jan 2021 05:12:11 GMT
Subject: RFR: JDK-8259395 Patching automatic module with additional
 packages re-creates module without "requires java.base" [v3]
In-Reply-To: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
References: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
Message-ID: <xPmjPGTgkdOOuaNrcm9fO0FhBtsUb-L9FGbJ40bDUNo=.4112f09a-b483-4e7d-b57a-be8e208721aa@github.com>

> Simple fix - one line change: https://openjdk.github.io/cr/?repo=jdk&pr=2000&range=00#sdiff-0.
> 
> Most of the changes come from an additional test that fails without this fix:
> 
>      Error: Unable to load main class somelib.test.TestMain in module somelib
>     	java.lang.IllegalAccessError: superclass access check failed: class somelib.test.TestMain (in module somelib) cannot access class java.lang.Object (in module java.base) because module java.base does not export java.lang to module somelib
> 
> As described in JDK-8259395.
> You can view the output of the test without patch here: https://github.com/DasBrain/jdk/runs/1668078245
> 
> Thanks to @AlanBateman for pointing out the right fix.

Johannes Kuhn has updated the pull request incrementally with one additional commit since the last revision:

  Add a missing pesky newline.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2000/files
  - new: https://git.openjdk.java.net/jdk/pull/2000/files/73ac7fde..7c2ed088

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

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

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

From github.com+1926185+robberphex at openjdk.java.net  Mon Jan 11 08:49:56 2021
From: github.com+1926185+robberphex at openjdk.java.net (Robert LU)
Date: Mon, 11 Jan 2021 08:49:56 GMT
Subject: Withdrawn: 8253280: Use class name as class loading lock
In-Reply-To: <5DnzvOcYJwLegT48SxwqBUqvg8HnihAgaqUpdraS3CU=.516c26fb-e88f-4b7f-9090-26f770e54f05@github.com>
References: <5DnzvOcYJwLegT48SxwqBUqvg8HnihAgaqUpdraS3CU=.516c26fb-e88f-4b7f-9090-26f770e54f05@github.com>
Message-ID: <vU47UgPLDjgjiz0HQ5c7iQsbCY17fazyd1n1ZEwxn7c=.bb707387-1bac-43a3-8098-4c24736fd378@github.com>

On Thu, 10 Sep 2020 05:25:43 GMT, Robert LU <github.com+1926185+RobberPhex at openjdk.org> wrote:

> When many thread try to load same class, the thread will stuck on `ClassLoader.loadClass`.
> At current jdk, the stacktrace by example program is:
> "Thread-1" prio=5 Id=12 BLOCKED on java.lang.Object at 2e817b38 owned by "Thread-0" Id=11
>         at java.base at 15/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:616)
>         -  blocked on java.lang.Object at 2e817b38
>         at java.base at 15/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:604)
>         at java.base at 15/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:168)
>         at java.base at 15/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
>         at app//Main.test(Main.java:19)
>         at app//Main$$Lambda$2/0x0000000800b8c468.run(Unknown Source)
>         at java.base at 15/java.lang.Thread.run(Thread.java:832)
> There is no way to get which class stuck the thread.
> 
> **After this patch, the stacktrace will be**:
> "Thread-1" prio=5 Id=13 BLOCKED on java.lang.String at 724af044 owned by "Thread-0" Id=12
>         at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:646)
>         -  blocked on java.lang.String at 724af044 val="java.lang.String"
>         at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:634)
>         at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:182)
>         at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
>         at app//Main2.test(Main2.java:19)
>         at app//Main2$$Lambda$37/0x00000001000c2a20.run(Unknown Source)
>         at java.base/java.lang.Thread.run(Thread.java:831)
> That is, user will know which class stuck the thread, in this example, the class is `java.lang.String`. It's helpful for troubleshooting.
> 
> The example program:
> Before patch:
> <details>
> <summary>Main.java</summary>
> 
> // Main.java
> import java.io.PrintStream;
> import java.lang.management.*;
> 
> public final class Main {
>     private synchronized static void test1() {
>         while (true) {
>             try {
>                 Thread.sleep(1000);
>             } catch (InterruptedException e) {
>                 e.printStackTrace();
>             }
>         }
>     }
> 
>     private static void test() {
>         while (true) {
>             try {
>                 Main.class.getClassLoader().loadClass("java.lang.String");
>             } catch (ClassNotFoundException e) {
>             }
>         }
>     }
> 
>     public static void main(String[] args) throws InterruptedException, NoSuchFieldException, IllegalAccessException {
>         new Thread(Main::test).start();
>         new Thread(Main::test).start();
>         new Thread(Main::test).start();
>         new Thread(Main::test).start();
>         new Thread(Main::test).start();
> 
>         while (true) {
>             Thread.sleep(1000);
>             ThreadMXBean bean = ManagementFactory.getThreadMXBean();
>             ThreadInfo[] infos = bean.dumpAllThreads(true, true);
>             for (ThreadInfo info : infos) {
>                 System.out.println(printThreadInfo(info));
>             }
>         }
>     }
> 
>     private static String printThreadInfo(ThreadInfo threadInfo) {
>         StringBuilder sb = new StringBuilder(""" + threadInfo.getThreadName() + """ +
>                 (threadInfo.isDaemon() ? " daemon" : "") +
>                 " prio=" + threadInfo.getPriority() +
>                 " Id=" + threadInfo.getThreadId() + " " +
>                 threadInfo.getThreadState());
>         if (threadInfo.getLockName() != null) {
>             sb.append(" on " + threadInfo.getLockName());
>         }
>         if (threadInfo.getLockOwnerName() != null) {
>             sb.append(" owned by "" + threadInfo.getLockOwnerName() +
>                     "" Id=" + threadInfo.getLockOwnerId());
>         }
>         if (threadInfo.isSuspended()) {
>             sb.append(" (suspended)");
>         }
>         if (threadInfo.isInNative()) {
>             sb.append(" (in native)");
>         }
>         sb.append('\n');
>         int i = 0;
>         StackTraceElement[] stackTrace = threadInfo.getStackTrace();
>         for (; i < stackTrace.length; i++) {
>             StackTraceElement ste = stackTrace[i];
>             sb.append("\tat " + ste.toString());
>             sb.append('\n');
>             if (i == 0 && threadInfo.getLockInfo() != null) {
>                 Thread.State ts = threadInfo.getThreadState();
>                 switch (ts) {
>                     case BLOCKED:
>                         sb.append("\t-  blocked on " + printLockInfo(threadInfo.getLockInfo()));
>                         sb.append('\n');
>                         break;
>                     case WAITING:
>                         sb.append("\t-  waiting on " + printLockInfo(threadInfo.getLockInfo()));
>                         sb.append('\n');
>                         break;
>                     case TIMED_WAITING:
>                         sb.append("\t-  waiting on " + printLockInfo(threadInfo.getLockInfo()));
>                         sb.append('\n');
>                         break;
>                     default:
>                 }
>             }
> 
>             for (MonitorInfo mi : threadInfo.getLockedMonitors()) {
>                 if (mi.getLockedStackDepth() == i) {
>                     sb.append("\t-  locked " + printLockInfo(mi));
>                     sb.append('\n');
>                 }
>             }
>         }
>         if (i < stackTrace.length) {
>             sb.append("\t...");
>             sb.append('\n');
>         }
> 
>         LockInfo[] locks = threadInfo.getLockedSynchronizers();
>         if (locks.length > 0) {
>             sb.append("\n\tNumber of locked synchronizers = " + locks.length);
>             sb.append('\n');
>             for (LockInfo li : locks) {
>                 sb.append("\t- " + printLockInfo(li));
>                 sb.append('\n');
>             }
>         }
>         sb.append('\n');
>         return sb.toString();
>     }
> 
>     private static String printLockInfo(LockInfo li) {
>         String res = li.getClassName() + '@' + Integer.toHexString(li.getIdentityHashCode());
>         return res;
>     }
> }
> </details>
> After patch:
> <details>
> <summary>Main2.java</summary>
> 
> // Main2.java
> import java.io.PrintStream;
> import java.lang.management.*;
> 
> public final class Main2 {
>     private synchronized static void test1() {
>         while (true) {
>             try {
>                 Thread.sleep(1000);
>             } catch (InterruptedException e) {
>                 e.printStackTrace();
>             }
>         }
>     }
> 
>     private static void test() {
>         while (true) {
>             try {
>                 Main2.class.getClassLoader().loadClass("java.lang.String");
>             } catch (ClassNotFoundException e) {
>             }
>         }
>     }
> 
>     public static void main(String[] args) throws InterruptedException, NoSuchFieldException, IllegalAccessException {
>         new Thread(Main2::test).start();
>         new Thread(Main2::test).start();
>         new Thread(Main2::test).start();
>         new Thread(Main2::test).start();
>         new Thread(Main2::test).start();
> 
>         while (true) {
>             Thread.sleep(1000);
>             ThreadMXBean bean = ManagementFactory.getThreadMXBean();
>             ThreadInfo[] infos = bean.dumpAllThreads(true, true);
>             for (ThreadInfo info : infos) {
>                 System.out.println(printThreadInfo(info));
>             }
>         }
>     }
> 
>     private static String printThreadInfo(ThreadInfo threadInfo) {
>         StringBuilder sb = new StringBuilder(""" + threadInfo.getThreadName() + """ +
>                 (threadInfo.isDaemon() ? " daemon" : "") +
>                 " prio=" + threadInfo.getPriority() +
>                 " Id=" + threadInfo.getThreadId() + " " +
>                 threadInfo.getThreadState());
>         if (threadInfo.getLockName() != null) {
>             sb.append(" on " + threadInfo.getLockName());
>         }
>         if (threadInfo.getLockOwnerName() != null) {
>             sb.append(" owned by "" + threadInfo.getLockOwnerName() +
>                     "" Id=" + threadInfo.getLockOwnerId());
>         }
>         if (threadInfo.isSuspended()) {
>             sb.append(" (suspended)");
>         }
>         if (threadInfo.isInNative()) {
>             sb.append(" (in native)");
>         }
>         sb.append('\n');
>         int i = 0;
>         StackTraceElement[] stackTrace = threadInfo.getStackTrace();
>         for (; i < stackTrace.length; i++) {
>             StackTraceElement ste = stackTrace[i];
>             sb.append("\tat " + ste.toString());
>             sb.append('\n');
>             if (i == 0 && threadInfo.getLockInfo() != null) {
>                 Thread.State ts = threadInfo.getThreadState();
>                 switch (ts) {
>                     case BLOCKED:
>                         sb.append("\t-  blocked on " + printLockInfo(threadInfo.getLockInfo()));
>                         sb.append('\n');
>                         break;
>                     case WAITING:
>                         sb.append("\t-  waiting on " + printLockInfo(threadInfo.getLockInfo()));
>                         sb.append('\n');
>                         break;
>                     case TIMED_WAITING:
>                         sb.append("\t-  waiting on " + printLockInfo(threadInfo.getLockInfo()));
>                         sb.append('\n');
>                         break;
>                     default:
>                 }
>             }
> 
>             for (MonitorInfo mi : threadInfo.getLockedMonitors()) {
>                 if (mi.getLockedStackDepth() == i) {
>                     sb.append("\t-  locked " + printLockInfo(mi));
>                     sb.append('\n');
>                 }
>             }
>         }
>         if (i < stackTrace.length) {
>             sb.append("\t...");
>             sb.append('\n');
>         }
> 
>         LockInfo[] locks = threadInfo.getLockedSynchronizers();
>         if (locks.length > 0) {
>             sb.append("\n\tNumber of locked synchronizers = " + locks.length);
>             sb.append('\n');
>             for (LockInfo li : locks) {
>                 sb.append("\t- " + printLockInfo(li));
>                 sb.append('\n');
>             }
>         }
>         sb.append('\n');
>         return sb.toString();
>     }
> 
>     private static String printLockInfo(LockInfo li) {
>         String res = li.getClassName() + '@' + Integer.toHexString(li.getIdentityHashCode());
>         // There is no getLock method in current jdk
>         if (li.getStringValue() != null) {
>             return res + " val="" + li.getStringValue() + """;
>         }
>         return res;
>     }
> }
> </details>

This pull request has been closed without being integrated.

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

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

From ihse at openjdk.java.net  Mon Jan 11 09:23:11 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 11 Jan 2021 09:23:11 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v4]
In-Reply-To: <YT7on7W1w9GJRTMfz2KtftKo7yGbVTgZxYcqXv1POBU=.59b49a13-da41-4c93-88c7-1830b87d0b63@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>
 <YT7on7W1w9GJRTMfz2KtftKo7yGbVTgZxYcqXv1POBU=.59b49a13-da41-4c93-88c7-1830b87d0b63@github.com>
Message-ID: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com>

On Mon, 4 Jan 2021 21:20:53 GMT, Phil Race <prr at openjdk.org> wrote:

>> Magnus Ihse Bursie 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:
>> 
>>  - Update comment refering to "make" dir
>>  - Move new symbols to jdk.compiler
>>  - Merge branch 'master' into shuffle-data
>>  - Move macosxicons from share to macosx
>>  - Move to share/data, and move jdwp.spec to java.se
>>  - Update references in test
>>  - Step 2: Update references
>>  - First stage, move actual data files
>
> Marked as reviewed by prr (Reviewer).

This PR is not stale; it's just still waiting for input from @AlanBateman.

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

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

From jlahoda at openjdk.java.net  Mon Jan 11 10:15:06 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 11 Jan 2021 10:15:06 GMT
Subject: Integrated: JDK-8250768: javac should be adapted to changes in JEP 12
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <zy0kk23rJNAEXiQFD_5wie_Yoau103GxbhKq5hUwckA=.fe4136d5-4841-4785-8278-074f9c99a614@github.com>

On Fri, 16 Oct 2020 15:20:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
> 
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769

This pull request has now been integrated.

Changeset: 23548821
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/23548821
Stats:     3802 lines in 133 files changed: 2724 ins; 695 del; 383 mod

8250768: javac should be adapted to changes in JEP 12

Reviewed-by: mcimadamore, erikj, jjg, ihse

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

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

From attila at openjdk.java.net  Mon Jan 11 14:09:01 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Mon, 11 Jan 2021 14:09:01 GMT
Subject: RFR: JDK-8259395 Patching automatic module with additional
 packages re-creates module without "requires java.base" [v3]
In-Reply-To: <xPmjPGTgkdOOuaNrcm9fO0FhBtsUb-L9FGbJ40bDUNo=.4112f09a-b483-4e7d-b57a-be8e208721aa@github.com>
References: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
 <xPmjPGTgkdOOuaNrcm9fO0FhBtsUb-L9FGbJ40bDUNo=.4112f09a-b483-4e7d-b57a-be8e208721aa@github.com>
Message-ID: <il4tZHeQpGludQJR1E4bL4VT6GlUrnYlCIquM2Xzru0=.313848ed-c980-4778-9c7c-5984e81d6ea1@github.com>

On Mon, 11 Jan 2021 05:12:11 GMT, Johannes Kuhn <github.com+652983+DasBrain at openjdk.org> wrote:

>> Simple fix - one line change: https://openjdk.github.io/cr/?repo=jdk&pr=2000&range=00#sdiff-0.
>> 
>> Most of the changes come from an additional test that fails without this fix:
>> 
>>      Error: Unable to load main class somelib.test.TestMain in module somelib
>>     	java.lang.IllegalAccessError: superclass access check failed: class somelib.test.TestMain (in module somelib) cannot access class java.lang.Object (in module java.base) because module java.base does not export java.lang to module somelib
>> 
>> As described in JDK-8259395.
>> You can view the output of the test without patch here: https://github.com/DasBrain/jdk/runs/1668078245
>> 
>> Thanks to @AlanBateman for pointing out the right fix.
>
> Johannes Kuhn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a missing pesky newline.

Marked as reviewed by attila (Reviewer).

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

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

From github.com+652983+dasbrain at openjdk.java.net  Mon Jan 11 14:13:57 2021
From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn)
Date: Mon, 11 Jan 2021 14:13:57 GMT
Subject: RFR: JDK-8259395 Patching automatic module with additional
 packages re-creates module without "requires java.base" [v3]
In-Reply-To: <il4tZHeQpGludQJR1E4bL4VT6GlUrnYlCIquM2Xzru0=.313848ed-c980-4778-9c7c-5984e81d6ea1@github.com>
References: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
 <xPmjPGTgkdOOuaNrcm9fO0FhBtsUb-L9FGbJ40bDUNo=.4112f09a-b483-4e7d-b57a-be8e208721aa@github.com>
 <il4tZHeQpGludQJR1E4bL4VT6GlUrnYlCIquM2Xzru0=.313848ed-c980-4778-9c7c-5984e81d6ea1@github.com>
Message-ID: <FtnsXvDoFKVs4kO4jcovhBbk49VGOpYVZdsFS_lW0N8=.917908d6-62c7-4858-8068-e0873288b115@github.com>

On Mon, 11 Jan 2021 14:06:12 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> Johannes Kuhn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a missing pesky newline.
>
> Marked as reviewed by attila (Reviewer).

Thanks @szegedi for reviewing this.

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

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

From alanb at openjdk.java.net  Mon Jan 11 14:17:06 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 11 Jan 2021 14:17:06 GMT
Subject: RFR: JDK-8259395 Patching automatic module with additional
 packages re-creates module without "requires java.base" [v3]
In-Reply-To: <FtnsXvDoFKVs4kO4jcovhBbk49VGOpYVZdsFS_lW0N8=.917908d6-62c7-4858-8068-e0873288b115@github.com>
References: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
 <xPmjPGTgkdOOuaNrcm9fO0FhBtsUb-L9FGbJ40bDUNo=.4112f09a-b483-4e7d-b57a-be8e208721aa@github.com>
 <il4tZHeQpGludQJR1E4bL4VT6GlUrnYlCIquM2Xzru0=.313848ed-c980-4778-9c7c-5984e81d6ea1@github.com>
 <FtnsXvDoFKVs4kO4jcovhBbk49VGOpYVZdsFS_lW0N8=.917908d6-62c7-4858-8068-e0873288b115@github.com>
Message-ID: <tp2onYs7y3jh2mpZNnKpeOTLQ7zGXDq07pxSb1LFrKU=.055a3225-00da-46ab-9b20-d912e0d017c1@github.com>

On Mon, 11 Jan 2021 14:11:15 GMT, Johannes Kuhn <github.com+652983+DasBrain at openjdk.org> wrote:

>> Marked as reviewed by attila (Reviewer).
>
> Thanks @szegedi for reviewing this.

This issue requires a Reviewer from someone working in this area. Please do not sponsor or integrate until that review has been done.

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

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

From github.com+652983+dasbrain at openjdk.java.net  Mon Jan 11 14:24:57 2021
From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn)
Date: Mon, 11 Jan 2021 14:24:57 GMT
Subject: RFR: JDK-8259395 Patching automatic module with additional
 packages re-creates module without "requires java.base" [v3]
In-Reply-To: <tp2onYs7y3jh2mpZNnKpeOTLQ7zGXDq07pxSb1LFrKU=.055a3225-00da-46ab-9b20-d912e0d017c1@github.com>
References: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
 <xPmjPGTgkdOOuaNrcm9fO0FhBtsUb-L9FGbJ40bDUNo=.4112f09a-b483-4e7d-b57a-be8e208721aa@github.com>
 <il4tZHeQpGludQJR1E4bL4VT6GlUrnYlCIquM2Xzru0=.313848ed-c980-4778-9c7c-5984e81d6ea1@github.com>
 <FtnsXvDoFKVs4kO4jcovhBbk49VGOpYVZdsFS_lW0N8=.917908d6-62c7-4858-8068-e0873288b115@github.com>
 <tp2onYs7y3jh2mpZNnKpeOTLQ7zGXDq07pxSb1LFrKU=.055a3225-00da-46ab-9b20-d912e0d017c1@github.com>
Message-ID: <pB72SpIMCKsU9aW9YTfft_2psI6wIMvg-j-1y9zYzN0=.20e5e82c-36b1-453d-b8fc-1f79c26c7018@github.com>

On Mon, 11 Jan 2021 14:13:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> 
> 
> This issue requires a Reviewer from someone working in this area. Please do not sponsor or integrate until that review has been done.

Ok, increased the number of required reviewers to 2.  
Hope that was the right move, as I don't see any other way to undo /integrate.

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

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

From winterhalter at openjdk.java.net  Mon Jan 11 15:16:58 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Mon, 11 Jan 2021 15:16:58 GMT
Subject: Withdrawn: 8228988: AnnotationParser throws NullPointerException on
 incompatible member type
In-Reply-To: <JE30SMjxGYOwl5toXuiKli58w9oeMb6n8wG2uA_4pl4=.0e965cac-2f8d-4d8d-b8ae-9146f9389578@github.com>
References: <JE30SMjxGYOwl5toXuiKli58w9oeMb6n8wG2uA_4pl4=.0e965cac-2f8d-4d8d-b8ae-9146f9389578@github.com>
Message-ID: <6t9eZfZl84M6H3ouOoy2pa9F0YGhQcOQVjHMECcsoc8=.baecb886-1b37-4158-b5aa-b5597fbaa100@github.com>

On Sun, 18 Oct 2020 22:21:37 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> If an annotation member type is changed in an incompatible manner, the `AnnotationParser` currently throws a `NullPointerException` if:
> 
> - An enumeration-typed member is changed to be an annotation type or a `Class` type.
> - An annotation type is changed to be a non-annotation type.
> 
> This patch creates `AnnotationTypeMismatchExceptionProxy` to give users a better error message and to delay the exception to the time where the annotation member is attempted to be accessed.

This pull request has been closed without being integrated.

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

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

From mcimadamore at openjdk.java.net  Mon Jan 11 16:18:02 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 11 Jan 2021 16:18:02 GMT
Subject: [jdk16] Integrated: 8259028: ClassCastException when using custom
 filesystem with wrapper FileChannel impl
In-Reply-To: <RXdR008wzVvkTM5LjK2tptKRknWJnGI9vuxJev-RYbA=.9ffabb2a-2c0c-4e6f-b871-91ccb25038bb@github.com>
References: <RXdR008wzVvkTM5LjK2tptKRknWJnGI9vuxJev-RYbA=.9ffabb2a-2c0c-4e6f-b871-91ccb25038bb@github.com>
Message-ID: <mrnsDBc30-ucrryJq47Nx61BKNB8aVK6yk_4NHbw188=.80e3ba04-f29d-4f2e-b51a-53b7bd5a9fa8@github.com>

On Wed, 6 Jan 2021 16:10:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch tweaks `MemorySegment::mapFile` so that it will throw `IllegalArgumentException` whenever the path to be mapped is associated with a custom file system provider.
> 
> The check in the implementation is heavily borrowed by what `UnixDomainSocketAddress::of(Path)` does (thanks Alan for the tip!). Not only we have to check if file system is the default one, but also if the default FS belongs to java.base (since that can be overridden).
> 
> The test simply check that paths coming from the (internal) JRT file system are not supported by the factory.

This pull request has now been integrated.

Changeset: d60a937e
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/d60a937e
Stats:     20 lines in 3 files changed: 14 ins; 1 del; 5 mod

8259028: ClassCastException when using custom filesystem with wrapper FileChannel impl

Reviewed-by: chegar, alanb, uschindler

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

PR: https://git.openjdk.java.net/jdk16/pull/90

From aefimov at openjdk.java.net  Mon Jan 11 16:59:55 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Mon, 11 Jan 2021 16:59:55 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base
In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
Message-ID: <ATU6wTDVsNS7sHv3Cz7EMSofyi37vK_s7cjd4fh8rRI=.cc6c3ffc-ece4-4cdd-af23-cb198293c9c0@github.com>

On Sat, 5 Sep 2020 18:55:53 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

Hi @turbanoff,
This PR is ready for integration - `JDK-8258657` has been resolved.
You can proceed with issuing `integrate` bot command. Then I will `sponsor` it.
But before that, I would like to ask if you would like to take on board the changes to `HttpClientImpl`? Alternatively, I can follow it up separately and reapply the backed-out change under different bugID.

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

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

From naoto at openjdk.java.net  Mon Jan 11 17:00:05 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 11 Jan 2021 17:00:05 GMT
Subject: RFR: 8259528: Broken Link for [java.text.Normalizer.Form]
Message-ID: <nddeXPFmkCqMcztMijwUplpN1dRb7gUoBLB3xLdLeuc=.bcb11949-4686-43de-b844-f5aeb8ff1eb8@github.com>

Please review this simple doc fix.

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

Commit messages:
 - 8259528: Broken Link for [java.text.Normalizer.Form]

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

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

From lancea at openjdk.java.net  Mon Jan 11 17:06:54 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 11 Jan 2021 17:06:54 GMT
Subject: RFR: 8259528: Broken Link for [java.text.Normalizer.Form]
In-Reply-To: <nddeXPFmkCqMcztMijwUplpN1dRb7gUoBLB3xLdLeuc=.bcb11949-4686-43de-b844-f5aeb8ff1eb8@github.com>
References: <nddeXPFmkCqMcztMijwUplpN1dRb7gUoBLB3xLdLeuc=.bcb11949-4686-43de-b844-f5aeb8ff1eb8@github.com>
Message-ID: <KmPaPRuNGrzdPdRspVQHW645N1Dt_lxnIdx7_a6hXgs=.d1d28ce7-9c6d-4893-9096-a6686a403d51@github.com>

On Mon, 11 Jan 2021 16:54:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this simple doc fix.

Marked as reviewed by lancea (Reviewer).

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Jan 11 17:14:55 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 11 Jan 2021 17:14:55 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base
In-Reply-To: <ATU6wTDVsNS7sHv3Cz7EMSofyi37vK_s7cjd4fh8rRI=.cc6c3ffc-ece4-4cdd-af23-cb198293c9c0@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ATU6wTDVsNS7sHv3Cz7EMSofyi37vK_s7cjd4fh8rRI=.cc6c3ffc-ece4-4cdd-af23-cb198293c9c0@github.com>
Message-ID: <bMHh1BwKaTYbdmAQPLR6LJUgRtff7l3qY8-4R94iQj8=.a02498a0-be70-41a6-85b1-340e41d4393a@github.com>

On Mon, 11 Jan 2021 16:57:00 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>
> Hi @turbanoff,
> This PR is ready for integration - `JDK-8258657` has been resolved.
> You can proceed with issuing `integrate` bot command. Then I will `sponsor` it.
> But before that, I would like to ask if you would like to take on board the changes to `HttpClientImpl`? Alternatively, I can follow it up separately and reapply the backed-out change under different bugID.

@AlekseiEfimov `HttpClientImpl` is not in `java.base` module. So I think it's better to not touch it under this PR.

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

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

From suprtycn at gmail.com  Mon Jan 11 18:05:02 2021
From: suprtycn at gmail.com (Phil Smith)
Date: Mon, 11 Jan 2021 10:05:02 -0800
Subject: TreeMap in JDK15 deviates from spec
Message-ID: <CAPRgzFrk5uGzVEJBo+R_BLf_dyUPfPbY0g4j+WKUUQyjYvKmTw@mail.gmail.com>

Hello, I submitted bug report 9068554 recently, but I consider this a
pretty big issue and I'd like for this not to get lost in triage.

With JDK-8176894, a specialized implementation for computeIfAbsent was
added to TreeMap, however it doesn't handle null values correctly.
Spec states a mapping to null is equivalent to no mapping being
present, however code will `return t.value;` without checking that
value. The interface default, for reference, looks like `if ((v =
get(key)) == null)`.

A simple repro follows

TreeMap treemap = new TreeMap();
treemap.put("a", null);
System.out.println(treemap.computeIfAbsent("a", key -> "default"));
System.out.println(treemap.get("a"));

HashMap hashmap = new HashMap();
hashmap.put("a", null);
System.out.println(hashmap.computeIfAbsent("a", key -> "default"));
System.out.println(hashmap.get("a"));

Phil

From valeriep at openjdk.java.net  Mon Jan 11 18:15:58 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 11 Jan 2021 18:15:58 GMT
Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires
 SunJCE's classes [v2]
In-Reply-To: <AT4umlZ1DhQNj2RkUXyIXqmIGCBTPeEcj56e3iX8F-g=.1f3459e5-c480-41bb-bf54-eb50335936aa@github.com>
References: <u0MKmmnw4k2MnkDD-a26NsLCRk1NEtbf9MY4MHSPa6Y=.9d02a25d-9eb8-4ed2-88c8-9d239be0f7df@github.com>
 <AT4umlZ1DhQNj2RkUXyIXqmIGCBTPeEcj56e3iX8F-g=.1f3459e5-c480-41bb-bf54-eb50335936aa@github.com>
Message-ID: <r4VrVytoyCRMJynAxgDQ-KJP0H_ai7zJpPmGLxaVDF4=.1b065393-7d6a-4c2a-8838-d61cb0924049@github.com>

On Fri, 8 Jan 2021 21:30:14 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> As described in JDK-8259319 [1], this fix proposal is to set proper access permissions so the SunPKCS11 provider can create instances of SunJCE classes when a Security Manager is installed and the fallback scheme is used.
>> 
>> No regressions found in jdk/sun/security/pkcs11 tests category.
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8259319
>
> Martin Balao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Limit P11Util::getProvider privileged access to the required 'accessClassInPackage' RuntimePermission only.
>  - New line character inserted at the end of IllegalPackageAccess.java test file

Changes look good.

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

Marked as reviewed by valeriep (Reviewer).

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

From joehw at openjdk.java.net  Mon Jan 11 18:28:57 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 11 Jan 2021 18:28:57 GMT
Subject: RFR: 8259528: Broken Link for [java.text.Normalizer.Form]
In-Reply-To: <nddeXPFmkCqMcztMijwUplpN1dRb7gUoBLB3xLdLeuc=.bcb11949-4686-43de-b844-f5aeb8ff1eb8@github.com>
References: <nddeXPFmkCqMcztMijwUplpN1dRb7gUoBLB3xLdLeuc=.bcb11949-4686-43de-b844-f5aeb8ff1eb8@github.com>
Message-ID: <EIIzpbLBUQr2J116k7YeAnOPfmecD1nz6aGkpvSs7G0=.9076460f-6388-4af4-9c14-a5ee51e31bc6@github.com>

On Mon, 11 Jan 2021 16:54:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this simple doc fix.

Oops, forgot to submit the review ;-)

src/java.base/share/classes/java/text/Normalizer.java line 48:

> 46:  * The {@code normalize} method supports the standard normalization forms
> 47:  * described in
> 48:  * <a href="https://www.unicode.org/reports/tr15/">

This links to the latest version. Will the Normalizer always keep up with version changes? Or is it a specific version with which it complies (e.g. the latest version 13, previous 12), or is the version change irrelevant to this class?

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

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

From openjdk at icemanx.nl  Mon Jan 11 19:15:31 2021
From: openjdk at icemanx.nl (Rob Spoor)
Date: Mon, 11 Jan 2021 20:15:31 +0100
Subject: TreeMap in JDK15 deviates from spec
In-Reply-To: <CAPRgzFrk5uGzVEJBo+R_BLf_dyUPfPbY0g4j+WKUUQyjYvKmTw@mail.gmail.com>
References: <CAPRgzFrk5uGzVEJBo+R_BLf_dyUPfPbY0g4j+WKUUQyjYvKmTw@mail.gmail.com>
Message-ID: <fa8bc914-3b3f-1da3-1a33-3fb1a642174d@icemanx.nl>

This is a regression, because Java 11 shows "default" twice for the 
TreeMap, whereas Java 15 shows "null" twice.


On 11/01/2021 19:05, Phil Smith wrote:
> Hello, I submitted bug report 9068554 recently, but I consider this a
> pretty big issue and I'd like for this not to get lost in triage.
> 
> With JDK-8176894, a specialized implementation for computeIfAbsent was
> added to TreeMap, however it doesn't handle null values correctly.
> Spec states a mapping to null is equivalent to no mapping being
> present, however code will `return t.value;` without checking that
> value. The interface default, for reference, looks like `if ((v =
> get(key)) == null)`.
> 
> A simple repro follows
> 
> TreeMap treemap = new TreeMap();
> treemap.put("a", null);
> System.out.println(treemap.computeIfAbsent("a", key -> "default"));
> System.out.println(treemap.get("a"));
> 
> HashMap hashmap = new HashMap();
> hashmap.put("a", null);
> System.out.println(hashmap.computeIfAbsent("a", key -> "default"));
> System.out.println(hashmap.get("a"));
> 
> Phil

From iris at openjdk.java.net  Mon Jan 11 19:16:57 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 11 Jan 2021 19:16:57 GMT
Subject: RFR: 8259528: Broken Link for [java.text.Normalizer.Form]
In-Reply-To: <nddeXPFmkCqMcztMijwUplpN1dRb7gUoBLB3xLdLeuc=.bcb11949-4686-43de-b844-f5aeb8ff1eb8@github.com>
References: <nddeXPFmkCqMcztMijwUplpN1dRb7gUoBLB3xLdLeuc=.bcb11949-4686-43de-b844-f5aeb8ff1eb8@github.com>
Message-ID: <FVxLJSm57NLHLXogfTltem2OyXRs0IyfH3fUJDaOfp8=.13fd456f-1bd7-41fb-bbe6-a19e0d515b6b@github.com>

On Mon, 11 Jan 2021 16:54:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this simple doc fix.

Marked as reviewed by iris (Reviewer).

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

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

From naoto at openjdk.java.net  Mon Jan 11 19:30:04 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 11 Jan 2021 19:30:04 GMT
Subject: RFR: 8259528: Broken Link for [java.text.Normalizer.Form]
In-Reply-To: <EIIzpbLBUQr2J116k7YeAnOPfmecD1nz6aGkpvSs7G0=.9076460f-6388-4af4-9c14-a5ee51e31bc6@github.com>
References: <nddeXPFmkCqMcztMijwUplpN1dRb7gUoBLB3xLdLeuc=.bcb11949-4686-43de-b844-f5aeb8ff1eb8@github.com>
 <EIIzpbLBUQr2J116k7YeAnOPfmecD1nz6aGkpvSs7G0=.9076460f-6388-4af4-9c14-a5ee51e31bc6@github.com>
Message-ID: <bCldKFldq4n8V1UBl2h3ctxCcdNlR8IWIBa2l6zHAp0=.7c9ae98a-365c-4a91-8735-a4e687c50530@github.com>

On Mon, 11 Jan 2021 17:35:58 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Please review this simple doc fix.
>
> src/java.base/share/classes/java/text/Normalizer.java line 48:
> 
>> 46:  * The {@code normalize} method supports the standard normalization forms
>> 47:  * described in
>> 48:  * <a href="https://www.unicode.org/reports/tr15/">
> 
> This links to the latest version. Will the Normalizer always keep up with version changes? Or is it a specific version with which it complies (e.g. the latest version 13, previous 12), or is the version change irrelevant to this class?

Normalizer (namely the table) is updated as part of the Unicode upgrade, so it should point to the latest. I believe the current one pointing to a specific revision is simply an editorial error.

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

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

From joehw at openjdk.java.net  Mon Jan 11 19:37:03 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 11 Jan 2021 19:37:03 GMT
Subject: RFR: 8259528: Broken Link for [java.text.Normalizer.Form]
In-Reply-To: <nddeXPFmkCqMcztMijwUplpN1dRb7gUoBLB3xLdLeuc=.bcb11949-4686-43de-b844-f5aeb8ff1eb8@github.com>
References: <nddeXPFmkCqMcztMijwUplpN1dRb7gUoBLB3xLdLeuc=.bcb11949-4686-43de-b844-f5aeb8ff1eb8@github.com>
Message-ID: <faB8BQ4PO-o_9zLPeEZ6TKFdr_r15UejXi3MGHPEW0k=.6d18da78-926c-43aa-ad59-e5d46e1ed469@github.com>

On Mon, 11 Jan 2021 16:54:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this simple doc fix.

Marked as reviewed by joehw (Reviewer).

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

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

From mullan at openjdk.java.net  Mon Jan 11 20:01:59 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 11 Jan 2021 20:01:59 GMT
Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires
 SunJCE's classes [v2]
In-Reply-To: <AT4umlZ1DhQNj2RkUXyIXqmIGCBTPeEcj56e3iX8F-g=.1f3459e5-c480-41bb-bf54-eb50335936aa@github.com>
References: <u0MKmmnw4k2MnkDD-a26NsLCRk1NEtbf9MY4MHSPa6Y=.9d02a25d-9eb8-4ed2-88c8-9d239be0f7df@github.com>
 <AT4umlZ1DhQNj2RkUXyIXqmIGCBTPeEcj56e3iX8F-g=.1f3459e5-c480-41bb-bf54-eb50335936aa@github.com>
Message-ID: <JWBBUcw2JANkTGOI9AX0LEt3AokdNf8alwX9aKAy3Zc=.33aea2d7-80a1-46c5-a1d0-74a0dc714e4c@github.com>

On Fri, 8 Jan 2021 21:30:14 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> As described in JDK-8259319 [1], this fix proposal is to set proper access permissions so the SunPKCS11 provider can create instances of SunJCE classes when a Security Manager is installed and the fallback scheme is used.
>> 
>> No regressions found in jdk/sun/security/pkcs11 tests category.
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8259319
>
> Martin Balao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Limit P11Util::getProvider privileged access to the required 'accessClassInPackage' RuntimePermission only.
>  - New line character inserted at the end of IllegalPackageAccess.java test file

Marked as reviewed by mullan (Reviewer).

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

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

From naoto at openjdk.java.net  Mon Jan 11 22:05:55 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 11 Jan 2021 22:05:55 GMT
Subject: Integrated: 8259528: Broken Link for [java.text.Normalizer.Form]
In-Reply-To: <nddeXPFmkCqMcztMijwUplpN1dRb7gUoBLB3xLdLeuc=.bcb11949-4686-43de-b844-f5aeb8ff1eb8@github.com>
References: <nddeXPFmkCqMcztMijwUplpN1dRb7gUoBLB3xLdLeuc=.bcb11949-4686-43de-b844-f5aeb8ff1eb8@github.com>
Message-ID: <OyVT9VZnriR-t-z1jkQ1J3139EYToe-WU4j-LmzUP5w=.5c9f9bb3-267f-41da-9ed7-43a87507bb05@github.com>

On Mon, 11 Jan 2021 16:54:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this simple doc fix.

This pull request has now been integrated.

Changeset: cd73939b
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cd73939b
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8259528: Broken Link for [java.text.Normalizer.Form]

Reviewed-by: lancea, joehw, iris

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

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

From jwilhelm at openjdk.java.net  Mon Jan 11 22:10:14 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 11 Jan 2021 22:10:14 GMT
Subject: RFR: Merge jdk16
Message-ID: <puz-WDoJfDxb8F14PsmiARZzYuRXqexRZMCMReqae-0=.1fa3cb70-fa3c-4953-9448-f64b91dcd7fd@github.com>

Forwardport JDK 16 -> JDK 17

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

Commit messages:
 - Merge
 - 8253996: Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing
 - 8259028: ClassCastException when using custom filesystem with wrapper FileChannel impl
 - 8259043: More Zero architectures need linkage with libatomic
 - 8259429: Update reference to README.md
 - 8259014: (so) ServerSocketChannel.bind(UnixDomainSocketAddress)/SocketChannel.bind(UnixDomainSocketAddress) will have unknown user and group owner (win)

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2040&range=00.0
 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2040&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/2040/files
  Stats: 140 lines in 12 files changed: 117 ins; 2 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2040.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2040/head:pull/2040

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

From smarks at openjdk.java.net  Mon Jan 11 23:20:13 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Mon, 11 Jan 2021 23:20:13 GMT
Subject: [jdk16] RFR: 8259298: broken link in Stream::toList spec
Message-ID: <KH0HIOOJAynBCzqN3Cp-mdYKJRc7aPVPOx3isGOmUnE=.c32fac9f-ee53-4ab9-a4a3-716a429a95f3@github.com>

Just fixing a broken link.

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

Commit messages:
 - 8259298: broken link in Stream::toList spec

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

PR: https://git.openjdk.java.net/jdk16/pull/106

From bchristi at openjdk.java.net  Mon Jan 11 23:26:59 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Mon, 11 Jan 2021 23:26:59 GMT
Subject: [jdk16] RFR: 8259298: broken link in Stream::toList spec
In-Reply-To: <KH0HIOOJAynBCzqN3Cp-mdYKJRc7aPVPOx3isGOmUnE=.c32fac9f-ee53-4ab9-a4a3-716a429a95f3@github.com>
References: <KH0HIOOJAynBCzqN3Cp-mdYKJRc7aPVPOx3isGOmUnE=.c32fac9f-ee53-4ab9-a4a3-716a429a95f3@github.com>
Message-ID: <Mp799C36DRKV9M2gVPi2-gtapyZZ98ecqdf5rHJLyfI=.e10f7889-6f8c-4cfe-96ff-efa43ec0bb34@github.com>

On Mon, 11 Jan 2021 23:15:07 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Just fixing a broken link.

Marked as reviewed by bchristi (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/106

From iris at openjdk.java.net  Mon Jan 11 23:31:59 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 11 Jan 2021 23:31:59 GMT
Subject: [jdk16] RFR: 8259298: broken link in Stream::toList spec
In-Reply-To: <KH0HIOOJAynBCzqN3Cp-mdYKJRc7aPVPOx3isGOmUnE=.c32fac9f-ee53-4ab9-a4a3-716a429a95f3@github.com>
References: <KH0HIOOJAynBCzqN3Cp-mdYKJRc7aPVPOx3isGOmUnE=.c32fac9f-ee53-4ab9-a4a3-716a429a95f3@github.com>
Message-ID: <g3nSIDAf1eOfxXkzqqnOF-OBoyblV9iKDwRPggNjanA=.a24b350e-f3ad-4ad7-b8b2-2beb3f90f6d6@github.com>

On Mon, 11 Jan 2021 23:15:07 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Just fixing a broken link.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/106

From lancea at openjdk.java.net  Mon Jan 11 23:31:59 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 11 Jan 2021 23:31:59 GMT
Subject: [jdk16] RFR: 8259298: broken link in Stream::toList spec
In-Reply-To: <KH0HIOOJAynBCzqN3Cp-mdYKJRc7aPVPOx3isGOmUnE=.c32fac9f-ee53-4ab9-a4a3-716a429a95f3@github.com>
References: <KH0HIOOJAynBCzqN3Cp-mdYKJRc7aPVPOx3isGOmUnE=.c32fac9f-ee53-4ab9-a4a3-716a429a95f3@github.com>
Message-ID: <QhzWyWzzR04OmHEkT9bvMjYWT_CRZ3KBKoGisoTevyE=.8f5e1aa3-9ae6-465b-969b-4fd3bed7a693@github.com>

On Mon, 11 Jan 2021 23:15:07 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Just fixing a broken link.

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/106

From naoto at openjdk.java.net  Mon Jan 11 23:42:04 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 11 Jan 2021 23:42:04 GMT
Subject: [jdk16] RFR: 8259298: broken link in Stream::toList spec
In-Reply-To: <KH0HIOOJAynBCzqN3Cp-mdYKJRc7aPVPOx3isGOmUnE=.c32fac9f-ee53-4ab9-a4a3-716a429a95f3@github.com>
References: <KH0HIOOJAynBCzqN3Cp-mdYKJRc7aPVPOx3isGOmUnE=.c32fac9f-ee53-4ab9-a4a3-716a429a95f3@github.com>
Message-ID: <sxf28_CRS03AlEHpu3XBLMJ2alzErOUu1NETtf4oroU=.ee728fea-1e5d-41c9-b1f7-8a382a560730@github.com>

On Mon, 11 Jan 2021 23:15:07 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Just fixing a broken link.

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/106

From aefimov at openjdk.java.net  Mon Jan 11 23:47:07 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Mon, 11 Jan 2021 23:47:07 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base
In-Reply-To: <AerlTMOZX29koszPtGYArb_6xjd2wjmRA8zhJhyzmAI=.08b971df-9c15-4d46-944d-b2bd08e5cdf8@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ATU6wTDVsNS7sHv3Cz7EMSofyi37vK_s7cjd4fh8rRI=.cc6c3ffc-ece4-4cdd-af23-cb198293c9c0@github.com>
 <bMHh1BwKaTYbdmAQPLR6LJUgRtff7l3qY8-4R94iQj8=.a02498a0-be70-41a6-85b1-340e41d4393a@github.com>
 <AerlTMOZX29koszPtGYArb_6xjd2wjmRA8zhJhyzmAI=.08b971df-9c15-4d46-944d-b2bd08e5cdf8@github.com>
Message-ID: <1sPtWhqRwT66UsTxWsfUtV05qkEufrEf4wmoKww3sdI=.f6cb56c4-3417-4b5e-ace3-4467013bb0cc@github.com>

On Mon, 11 Jan 2021 23:29:53 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> @AlekseiEfimov `HttpClientImpl` is not in `java.base` module. So I think it's better to not touch it under this PR.
>
> To double check that docs build will be stable after integration the following actions have been performed:
> - The pull request branch was locally synced-up with the latest changes from `master` (`JDK-8258657` is part of them)
> - Verified that local  `docs-reference-api-javadoc` build completes successfully

sponsor

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

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

From aefimov at openjdk.java.net  Mon Jan 11 23:47:07 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Mon, 11 Jan 2021 23:47:07 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base
In-Reply-To: <bMHh1BwKaTYbdmAQPLR6LJUgRtff7l3qY8-4R94iQj8=.a02498a0-be70-41a6-85b1-340e41d4393a@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ATU6wTDVsNS7sHv3Cz7EMSofyi37vK_s7cjd4fh8rRI=.cc6c3ffc-ece4-4cdd-af23-cb198293c9c0@github.com>
 <bMHh1BwKaTYbdmAQPLR6LJUgRtff7l3qY8-4R94iQj8=.a02498a0-be70-41a6-85b1-340e41d4393a@github.com>
Message-ID: <AerlTMOZX29koszPtGYArb_6xjd2wjmRA8zhJhyzmAI=.08b971df-9c15-4d46-944d-b2bd08e5cdf8@github.com>

On Mon, 11 Jan 2021 17:12:24 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Hi @turbanoff,
>> This PR is ready for integration - `JDK-8258657` has been resolved.
>> You can proceed with issuing `integrate` bot command. Then I will `sponsor` it.
>> But before that, I would like to ask if you would like to take on board the changes to `HttpClientImpl`? Alternatively, I can follow it up separately and reapply the backed-out change under different bugID.
>
> @AlekseiEfimov `HttpClientImpl` is not in `java.base` module. So I think it's better to not touch it under this PR.

To double check that docs build will be stable after integration the following actions have been performed:
- The pull request branch was locally synced-up with the latest changes from `master` (`JDK-8258657` is part of them)
- Verified that local  `docs-reference-api-javadoc` build completes successfully

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Jan 11 23:47:08 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 11 Jan 2021 23:47:08 GMT
Subject: Integrated: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base
In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
Message-ID: <DBeZIYQZh5XFkbxNiqJVAVDEKiWi2G2xhwzE-GVhFaQ=.36706ba8-6654-4942-9ef5-510f3f7d11e8@github.com>

On Sat, 5 Sep 2020 18:55:53 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

This pull request has now been integrated.

Changeset: 022bc9f0
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/022bc9f0
Stats:     82 lines in 22 files changed: 1 ins; 13 del; 68 mod

8258422: Cleanup unnecessary null comparison before instanceof check in java.base

Reviewed-by: chegar, aefimov

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

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

From jwilhelm at openjdk.java.net  Tue Jan 12 00:59:20 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 12 Jan 2021 00:59:20 GMT
Subject: RFR: Merge jdk16 [v2]
In-Reply-To: <puz-WDoJfDxb8F14PsmiARZzYuRXqexRZMCMReqae-0=.1fa3cb70-fa3c-4953-9448-f64b91dcd7fd@github.com>
References: <puz-WDoJfDxb8F14PsmiARZzYuRXqexRZMCMReqae-0=.1fa3cb70-fa3c-4953-9448-f64b91dcd7fd@github.com>
Message-ID: <ncsIT8L7wP2FB8E1hXdn4kf9SCDNPwwzJxUW5F6OAeg=.ab6af386-ed70-47c5-acac-cb3c41928663@github.com>

> Forwardport JDK 16 -> JDK 17

Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:

  Merge

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2040/files
  - new: https://git.openjdk.java.net/jdk/pull/2040/files/e55da33b..69dad8ed

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

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

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

From jwilhelm at openjdk.java.net  Tue Jan 12 01:10:59 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 12 Jan 2021 01:10:59 GMT
Subject: Integrated: Merge jdk16
In-Reply-To: <puz-WDoJfDxb8F14PsmiARZzYuRXqexRZMCMReqae-0=.1fa3cb70-fa3c-4953-9448-f64b91dcd7fd@github.com>
References: <puz-WDoJfDxb8F14PsmiARZzYuRXqexRZMCMReqae-0=.1fa3cb70-fa3c-4953-9448-f64b91dcd7fd@github.com>
Message-ID: <D5Zt2DnTVy1p54aids2HeMuXTor4ubsgD56B5Mq7q-8=.ffac5c11-9979-46dc-b78e-9f4ba2c85b39@github.com>

On Mon, 11 Jan 2021 22:04:16 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: b378f54d
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b378f54d
Stats:     139 lines in 12 files changed: 116 ins; 2 del; 21 mod

Merge

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

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

From hchao at openjdk.java.net  Tue Jan 12 03:39:22 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 12 Jan 2021 03:39:22 GMT
Subject: RFR: 8259401: Add checking to jarsigner to warn weak algorithms used
 in =?UTF-8?B?c2nigKY=?=
Message-ID: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com>

The jarsigner tool currently provides warning associated with the signer?s cert when it uses weak algorithms, but not for the CA certs. This change is to process the signer?s cert chain to warn if CA certs use weak algorithms.

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

Commit messages:
 - 8259401: Add checking to jarsigner to warn weak algorithms used in signer?s cert chain

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

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

From github.com+1059453+fleshgrinder at openjdk.java.net  Tue Jan 12 07:29:00 2021
From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger)
Date: Tue, 12 Jan 2021 07:29:00 GMT
Subject: RFR: 5023614: UUID needs methods to get most/leastSigBits and
 write to DataOutput
In-Reply-To: <CA6Gy6J6gCP0wTeKjVqi3VOqYM7SgfNiyKmxy8rZHrQ=.1a135fdb-d012-47ec-bd06-5a14110e62bd@github.com>
References: <2jx_KKaEEiEbvuAH398iD_noYamG-_50NkL4nCIQwXE=.5da5bc1d-4cf2-4a10-90be-5dfdaaba9e0e@github.com>
 <CA6Gy6J6gCP0wTeKjVqi3VOqYM7SgfNiyKmxy8rZHrQ=.1a135fdb-d012-47ec-bd06-5a14110e62bd@github.com>
Message-ID: <bvYibvHJbQdR6mHuXKT0CzqPjSBnvp1lIG54Os2mfX0=.e9da7cd5-1e3c-4a0c-b2e0-688bcaba5180@github.com>

On Mon, 14 Dec 2020 20:18:01 GMT, Roger Riggs <rriggs at openjdk.org> 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.
>
> Requested feedback on the API addition/modifications:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072530.html

Active

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

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

From herrick at openjdk.java.net  Tue Jan 12 14:14:55 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 12 Jan 2021 14:14:55 GMT
Subject: Withdrawn: JDK-8223322: Improve concurrency in jpackage instances
In-Reply-To: <kLf7uN9jJH7HeAAsR7egERJdwg85lP_N6SwYrBhnM9w=.3cd2410b-40d0-4a4b-a004-f9ab5931519a@github.com>
References: <kLf7uN9jJH7HeAAsR7egERJdwg85lP_N6SwYrBhnM9w=.3cd2410b-40d0-4a4b-a004-f9ab5931519a@github.com>
Message-ID: <lnxX-iIEIs12GmgfWuGbrlaPiRCnMOZhuqbo1zNhUV0=.3c8eecc3-9665-402b-90c2-82f92d485464@github.com>

On Thu, 17 Dec 2020 20:46:50 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> Remove all non final static variables in jpackage java code (using InheritableThreadLocal for Logger and Argument instances) and remove sychronization in JPackageToolProvider.

This pull request has been closed without being integrated.

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

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

From sgehwolf at openjdk.java.net  Tue Jan 12 14:31:55 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 12 Jan 2021 14:31:55 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection
In-Reply-To: <m1iurC4l1M904NY7lj5eVIB8jgCfBLR2sh8XrQzhJUM=.c2c5c01f-c29a-4b22-922b-e56472e951ec@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
 <Ynmw17EfEzNeUK5w2ABmHkXqqXo98GTcYTnZFGoAYIk=.1079ee11-c9e7-443f-b74b-d94838206a2a@github.com>
 <eFFokFwfdmu0YTyAhvPJ7xBFo0ypjHw3MyC_9-aTS6g=.80ad5876-3ae3-4ca3-96b5-08db53ed6627@github.com>
 <COWzygAauFzmvgYYP6DVjIg0MH6EDyIMx0ZzeTRHol0=.8a01079b-6e40-4b1b-bb75-e693f89d8871@github.com>
 <iT7Ltrm52E9skv98tAKIYPB1ZCaXw8ep-YSegjEnhxc=.68635047-f51c-4c60-9731-0da103e56a39@github.com>
 <m1iurC4l1M904NY7lj5eVIB8jgCfBLR2sh8XrQzhJUM=.c2c5c01f-c29a-4b22-922b-e56472e951ec@github.com>
Message-ID: <Mat51HIuUYISDvMtuz4R7LJ2R1aBeGASWCyBWAXFlAI=.f3329041-9c29-4b4b-ba66-163233764fb9@github.com>

On Tue, 15 Dec 2020 12:57:12 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> @bobvandette Please review when you've got some cycles to spare. Much appreciated!
>
> Ping? Anyone?

Anybody willing to review this?

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

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

From mcimadamore at openjdk.java.net  Tue Jan 12 15:33:11 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 12 Jan 2021 15:33:11 GMT
Subject: [jdk16] RFR: 8259634: MemorySegment::asByteBuffer does not respect
 spatial bounds
Message-ID: <Y3fAYuwsp99cUieNclfez8Vg2Jt-ossS8AZDSTWbsfk=.a6d23f8f-f054-4e99-a739-82f548a379a1@github.com>

The byte buffers created from heap segments do not honor the javadoc - which says that the resulting buffer size should be equal to MemorySegment::byteSize, and that the buffer position should be zero.

The issue is that the NIO routine we have added to create heap buffers is using the wrong constructor, which doesn't do what we need. The fix is to simply use the proper, more complete constructor.

I've also re-enabled an unrelated test which was missing the @Test annotation.

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

Commit messages:
 - Fix loic to turn segments into buffers

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

PR: https://git.openjdk.java.net/jdk16/pull/109

From mcimadamore at openjdk.java.net  Tue Jan 12 15:53:11 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 12 Jan 2021 15:53:11 GMT
Subject: [jdk16] RFR: 8259636: Check for buffer backed by shared segment kicks
 in in unexpected places
Message-ID: <Z37jHHCVvUCGS8UDYH1lpd5Zwb3pOAOyZo2JRTERKeY=.5590d0ec-067e-4913-83b6-712fcd519d10@github.com>

When support for shared segment was added, we decided to disable support for buffers derived from shared segment in certain async operations, as there's currently no way to make sure that the memory won't be reclaimed while the IO operation is still taking place.

After looking at the code, it seemed like the best place to put the restriction would be sun.nio.ch.DirectBuffer::address() method, since this method is used in a lot of places just before jumping into some piece of JNI code.

While I still stand by that decision, the Netty team has discovered that this decision also affected operations such as creating slices from byte buffers derived from shared segment - this is caused by the fact that one direct buffer constructor (the one for views and slices) is calling the dreaded DirectBuffer::address method.

The fix is simple: just avoid the method call - which is very easy to do in the case of the buffer constructor: in fact this method just returns the value of the `address` field inside the `Buffer` class, so we can always cast to `Buffer` and then access `address` field from there.

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

Commit messages:
 - Tweak direct buffer slice constructor not to use DirectBuffer::address

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

PR: https://git.openjdk.java.net/jdk16/pull/110

From sundar at openjdk.java.net  Tue Jan 12 16:04:01 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Tue, 12 Jan 2021 16:04:01 GMT
Subject: [jdk16] RFR: 8259636: Check for buffer backed by shared segment
 kicks in in unexpected places
In-Reply-To: <Z37jHHCVvUCGS8UDYH1lpd5Zwb3pOAOyZo2JRTERKeY=.5590d0ec-067e-4913-83b6-712fcd519d10@github.com>
References: <Z37jHHCVvUCGS8UDYH1lpd5Zwb3pOAOyZo2JRTERKeY=.5590d0ec-067e-4913-83b6-712fcd519d10@github.com>
Message-ID: <xCErSUqknxXtegCsVN5tL6qPN6yKzUxAHaed398xrBo=.e6b319d5-51f9-4d75-9b11-464f72b856e7@github.com>

On Tue, 12 Jan 2021 15:48:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> When support for shared segment was added, we decided to disable support for buffers derived from shared segment in certain async operations, as there's currently no way to make sure that the memory won't be reclaimed while the IO operation is still taking place.
> 
> After looking at the code, it seemed like the best place to put the restriction would be sun.nio.ch.DirectBuffer::address() method, since this method is used in a lot of places just before jumping into some piece of JNI code.
> 
> While I still stand by that decision, the Netty team has discovered that this decision also affected operations such as creating slices from byte buffers derived from shared segment - this is caused by the fact that one direct buffer constructor (the one for views and slices) is calling the dreaded DirectBuffer::address method.
> 
> The fix is simple: just avoid the method call - which is very easy to do in the case of the buffer constructor: in fact this method just returns the value of the `address` field inside the `Buffer` class, so we can always cast to `Buffer` and then access `address` field from there.

Marked as reviewed by sundar (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/110

From alanb at openjdk.java.net  Tue Jan 12 16:16:02 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 12 Jan 2021 16:16:02 GMT
Subject: [jdk16] RFR: 8259634: MemorySegment::asByteBuffer does not
 respect spatial bounds
In-Reply-To: <Y3fAYuwsp99cUieNclfez8Vg2Jt-ossS8AZDSTWbsfk=.a6d23f8f-f054-4e99-a739-82f548a379a1@github.com>
References: <Y3fAYuwsp99cUieNclfez8Vg2Jt-ossS8AZDSTWbsfk=.a6d23f8f-f054-4e99-a739-82f548a379a1@github.com>
Message-ID: <qw81WG8qZoS0bZOzPhBvpuomdKKrcZxtth-rebOhni0=.a145416f-ebe0-4caf-abd7-5fe8c7a45aba@github.com>

On Tue, 12 Jan 2021 15:28:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The byte buffers created from heap segments do not honor the javadoc - which says that the resulting buffer size should be equal to MemorySegment::byteSize, and that the buffer position should be zero.
> 
> The issue is that the NIO routine we have added to create heap buffers is using the wrong constructor, which doesn't do what we need. The fix is to simply use the proper, more complete constructor.
> 
> I've also re-enabled an unrelated test which was missing the @Test annotation.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/109

From some-java-user-99206970363698485155 at vodafonemail.de  Tue Jan 12 16:22:51 2021
From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de)
Date: Tue, 12 Jan 2021 17:22:51 +0100 (CET)
Subject: Is SharedSecrets thread-safe?
In-Reply-To: <68044bb3-b7e2-a4b3-e89c-03c5d35b6dc9@gmail.com>
References: <938640011.238938.1609249350345@mail.vodafone.de>
 <99d009fe-8901-d107-0779-c8965dfb257b@j-kuhn.de>
 <CAMOCf+j05BGap5C_VjRi+nm5FHVwdJ4bmwejEL1pHf1Jro5yxA@mail.gmail.com>
 <1927632433.243197.1609284763289@mail.vodafone.de>
 <9863a935-29ab-4426-2aa1-75ef0808de41@oracle.com>
 <CAMOCf+gogQti=Hfp3+GSD=+=qrsddaSf1mxosgbWEHONHFxk1A@mail.gmail.com>
 <0de44a07-cbf3-9924-c667-2e624728e84e@gmail.com>
 <1114179516.261393.1609435545716@mail.vodafone.de>
 <68044bb3-b7e2-a4b3-e89c-03c5d35b6dc9@gmail.com>
Message-ID: <533527099.371923.1610468571685@mail.vodafone.de>

Hello Peter,
feel free to consider these issues one at a time, or not at all, if you don't think that it is
worth it.
However, please note that I will unsubscribe from this mailing list in the next days again due
to the high degree of activity.
(Related: https://mail.openjdk.java.net/pipermail/discuss/2020-December/005674.html)

Kind regards

> Peter Levart <peter.levart at gmail.com> hat am 4. Januar 2021 um 22:48 geschrieben:
> 
> 
> Hello 99206970363698485155,
> 
> 
> Thanks for these pointers. I would prefer to untangle those knots one at 
> a time, if you don't mind, since some of them touch other parts of code 
> while this change to SharedSecrets is pretty straightforward and localized.
> 
> 
> Regards, Peter
> 
> 
> On 12/31/20 6:25 PM, some-java-user-99206970363698485155 at vodafonemail.de 
> wrote:
> > Hello Peter,
> > the changes look good, however there might be more to consider:
> >
> > - `jdk.internal.access.SharedSecrets.getJavaLangRefAccess()`
> >    Might be good to add a comment there or for `java.lang.ref.Reference` that it is (hopefully?)
> >    initialized during JVM start-up. Similar to the comment for `AccessibleObject` which states
> >    that it is initialized in "initPhase1".
> >    Currently without special knowledge about JVM start-up, it is not obvious that this construct
> >    is safe.
> >
> > - `java.io.Console.cons`
> >    This is pretty brittle. It is currently only thread-safe because the only accessor is
> >    `System.console()` which has its own synchronization. However, I doubt that the author was aware
> >    that `Console.cons` on its own is not thread-safe.
> >    In general, why is there lazy initialization twice? Once in `System.console()` and then in the
> >    accessor for `Console.cons`. In my opinion *only* `java.io.Console` should have the lazy
> >    initialization logic (with proper synchronization!) and make sure that only one `Console` instance
> >    exists.
> >
> > - `jdk.internal.access.JavaIOAccess.charset()`
> >    The implementation of this one is extremely brittle. While it documents that the `Password` class
> >    calling it will make sure that `System.console()` has been called before, in that `Password` class
> >    there is not such notice, so it could easily happen that someone breaks this at a later point.
> >    Additionally the field `Console.cs` it accesses is not `final`, making it even more brittle.
> >
> >    In my opinion there should be two changes:
> >    1. Change `JavaIOAccess.charset()` -> `charset(Console)`, which then accesses the charset from that
> >       Console argument.
> >       This enforces that the user of the access already has the Console initialized and indirectly
> >       establishes the happens-before relationship for `Console.cs`.
> >    2. The Console class should have the following fields `final`:
> >       readLock, writeLock, reader, out, pw, formatter, cs
> >       For `cs` this would merely require introducing a local variable.
> >
> >    In general `sun.security.util.Password.convertToBytes(char[])` is problematic because it makes
> >    passwords unportable when one OS uses a different terminal encoding than another.
> >    The cleaner backward compatible solution might be to simply block all non-ASCII chars (i.e. throw
> >    exception for them)?
> >    This would break for all existing users which used non-ASCII chars or where their terminal has an
> >    encoding not based on ASCII, but these users might already have different problems due to the
> >    existing implementation.
> >
> > - `jdk.internal.access.SharedSecrets.setJavaAWTAccess(JavaAWTAccess)`
> >    Might have to establish a happens-before relationship for `getJavaAWTAccess()` because caller
> >    appears to expect a `JavaAWTAccess` in case respective class has been loaded.
> >
> >    On a side note here: The implementation of that access appears to contain redundant code:
> >    https://github.com/openjdk/jdk/blob/8435f0daf2413a4c17578dd288e093fe006b3880/src/java.desktop/share/classes/sun/awt/AppContext.java#L866
> >    The null check there makes no sense because `ecx` is always null at that point.
> >
> > - `jdk.internal.access.SharedSecrets.setJavaAWTFontAccess(JavaAWTFontAccess)`
> >    This seems to be rather brittle as well because its callers check whether the access has already
> >    been initialized.
> >    Additionally this seems to be more complicated than it has to be: It appears to be simpler to have
> >    `SharedSecrets` initialize the access by initializing only `NumericShaper` (or `TextAttribute`,
> >    ultimately does not matter which class from that package is used) when `getJavaAWTFontAccess()` is
> >    called. The performance penalty (if any) is likely negligible.
> >
> > - `com.sun.jmx.mbeanserver.JavaBeansAccessor`
> >    Since the static initializer of that class is loading `Introspector` (which sets access object)
> >    anyways it might be saner to have this initialization logic in `SharedSecrets` instead.
> >
> > Kind regards
> >
> >> Peter Levart <peter.levart at gmail.com> hat am 31. Dezember 2020 um 11:07 geschrieben:
> >>
> >>
> >>
> >> On 12/31/20 2:30 AM, Hans Boehm wrote:
> >>> It sounds as though this would be correct if
> >>>
> >>> if (static_field == null) {
> >>>     initialize();
> >>> }
> >>> return static_field;
> >>> ```
> >>>
> >>> were rewritten as
> >>>
> >>> Foo my_local_copy = static_field;
> >>> if (my_copy == null) {
> >>>      initialize();
> >>>      my_local_copy = static_field;
> >>> }
> >>> return my_local_copy;
> >>>
> >>> That would prevent the redundant read of static_field unless this thread
> >>> did the initialization, in which case the original null would no longer be
> >>> visible to the second read.
> >>>
> >>> Hans
> >>
> >> I agree. The initialize() part is triggering some class initialization
> >> where concurrent attempts do establish a HB edge so the 2nd read of
> >> static_field after initialize() is ordered properly and can't read null.
> >>
> >> I created a JIRA ticket here:
> >> https://bugs.openjdk.java.net/browse/JDK-8259021
> >>
> >> And prepared a PR here: https://github.com/openjdk/jdk/pull/1914
> >>
> >>
> >> Happy new year,
> >>
> >> Peter
> >>
> >>
> >>> On Tue, Dec 29, 2020 at 4:55 PM Claes Redestad <claes.redestad at oracle.com>
> >>> wrote:
> >>>
> >>>> Hans' assessment seems about right in the generic case he's describing.
> >>>>
> >>>> But consider:
> >>>>
> >>>> 1. There is no concurrent setting of anything here - it's done in a
> >>>> static initializer which will happen exactly once by the thread
> >>>> initializing the class ($ 12.2.4 item 9).
> >>>>
> >>>> 2. While there is a data race on the access of the fields in
> >>>> SharedSecrets, all of the Access instances are stateless. This means the
> >>>> race is benign in the sense that when reading the field only a null or
> >>>> a safely published instance can be observed.
> >>>>
> >>>> I wouldn't swear there's a strict guarantee a null can never be returned
> >>>> from a SharedSecrets accessor though. Perhaps that's something that
> >>>> could be hardened.
> >>>>
> >>>> /Claes
> >>>>
> >>>> On 2020-12-30 00:32, some-java-user-99206970363698485155 at vodafonemail.de
> >>>> wrote:
> >>>>> That would also be my understanding of the current situation, though
> >>>> this contradicts what
> >>>>> Claes wrote.
> >>>>> Maybe the JVM behaves in a way which does not allow reordering, but the
> >>>> JLS definitely seems
> >>>>> to allow it. Section ? 12.2.4 [0] only mentions that for the class to be
> >>>> initialized there
> >>>>> has to exist a lock LC (or at least the happens-before relationship),
> >>>> but there is no
> >>>>> "freeze the world" or anything similar which would force a
> >>>> happens-before relationship
> >>>>> for the code in `SharedSecrets`.
> >>>>>
> >>>>> Maybe most of the `SharedSecrets` methods are thread-safe (albeit
> >>>> extremely brittle) because
> >>>>> the classes to which the accessor objects belong to have previously
> >>>> already been loaded
> >>>>> before `SharedSecrets` is used, therefore having already established a
> >>>> happens-before
> >>>>> relationship.
> >>>>> However, this is definitely not the case for all of the methods as shown
> >>>> by the following
> >>>>> example:
> >>>>> ```
> >>>>> CookieHandler.setDefault(new CookieHandler() {
> >>>>>        @Override
> >>>>>        public void put(URI uri, Map<String, List<String>> responseHeaders)
> >>>> throws IOException { }
> >>>>>        @Override
> >>>>>        public Map<String, List<String>> get(URI uri, Map<String,
> >>>> List<String>> requestHeaders) throws IOException {
> >>>>>            return Collections.emptyMap();
> >>>>>        }
> >>>>> });
> >>>>>
> >>>>> // Any site which uses cookies (i.e. Set-Cookie or Set-Cookie2 header)
> >>>>> URL url = new URL("https://oracle.com");
> >>>>> url.openConnection().getHeaderFields();
> >>>>> ```
> >>>>>
> >>>>> Running this code with `openjdk 15 2020-09-15` shows that the call to
> >>>>> `SharedSecrets.getJavaNetHttpCookieAccess()` is made before the class
> >>>> `HttpCookie` has
> >>>>> been accessed and initialized. Therefore merely running this code in two
> >>>> separate threads
> >>>>> (both having been started before the code is executed, since
> >>>> `Thread.start()` establishes
> >>>>> a happens-before relationship) should be enough to render that
> >>>> `SharedSecrets` method
> >>>>> non-thread-safe.
> >>>>>
> >>>>> Kind regards
> >>>>>
> >>>>>
> >>>>> [0]
> >>>> https://docs.oracle.com/javase/specs/jls/se15/html/jls-12.html#jls-12.4.2
> >>>>>> Hans Boehm <hboehm at google.com> hat am 29. Dezember 2020 um 18:53
> >>>> geschrieben:
> >>>>>> If static_field is not volatile, and set concurrently, then the first
> >>>> read of static_field may return non-null and the second null, without
> >>>> initialize() even being executed. The Java memory model does not prevent
> >>>> reordering of non-volatile reads from the same field (for good reason).
> >>>>>> Even if initialize() is executed and performs a volatile read, this
> >>>> reasoning doesn't hold. The initial static_field read may be delayed past
> >>>> the volatile read inside the conditional and hence, at least theoretically,
> >>>> past the second read. Control dependencies don't order reads, either in
> >>>> Java, or in modern weakly-ordered architectures with branch prediction.
> >>>> This doesn't matter if initialize() sets static_field.
> >>>>>> This all assumes that having two threads call initialize() is OK.
> >>>>>>
> >>>>>> Java code with data races is extremely tricky and rarely correct.
> >>>>>>
> >>>>>> Hans

From alanb at openjdk.java.net  Tue Jan 12 16:25:57 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 12 Jan 2021 16:25:57 GMT
Subject: [jdk16] RFR: 8259636: Check for buffer backed by shared segment
 kicks in in unexpected places
In-Reply-To: <Z37jHHCVvUCGS8UDYH1lpd5Zwb3pOAOyZo2JRTERKeY=.5590d0ec-067e-4913-83b6-712fcd519d10@github.com>
References: <Z37jHHCVvUCGS8UDYH1lpd5Zwb3pOAOyZo2JRTERKeY=.5590d0ec-067e-4913-83b6-712fcd519d10@github.com>
Message-ID: <yvO0Tr10S3g9Ne6iJloA66unoHwRH680uepD_4RWjDM=.7a2c37d6-9f1f-40ea-accc-106647b43f3b@github.com>

On Tue, 12 Jan 2021 15:48:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> When support for shared segment was added, we decided to disable support for buffers derived from shared segment in certain async operations, as there's currently no way to make sure that the memory won't be reclaimed while the IO operation is still taking place.
> 
> After looking at the code, it seemed like the best place to put the restriction would be sun.nio.ch.DirectBuffer::address() method, since this method is used in a lot of places just before jumping into some piece of JNI code.
> 
> While I still stand by that decision, the Netty team has discovered that this decision also affected operations such as creating slices from byte buffers derived from shared segment - this is caused by the fact that one direct buffer constructor (the one for views and slices) is calling the dreaded DirectBuffer::address method.
> 
> The fix is simple: just avoid the method call - which is very easy to do in the case of the buffer constructor: in fact this method just returns the value of the `address` field inside the `Buffer` class, so we can always cast to `Buffer` and then access `address` field from there.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/110

From dfuchs at openjdk.java.net  Tue Jan 12 16:55:01 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 12 Jan 2021 16:55:01 GMT
Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with
 jaxp.library.SimpleHttpServer [v6]
In-Reply-To: <isR-HAF6xahbZLAGrIwyyStcQWtrOml8EXg3cFEIngc=.cbe23f3b-21a3-4028-8278-a153dbbb03d1@github.com>
References: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
 <isR-HAF6xahbZLAGrIwyyStcQWtrOml8EXg3cFEIngc=.cbe23f3b-21a3-4028-8278-a153dbbb03d1@github.com>
Message-ID: <XV9kxPEm_BUq4Br3y-ANnGCGTPx_VltT6fl-0Ox94A4=.e7c9c1ff-3806-44ae-8844-cf3aa0b3538a@github.com>

On Wed, 6 Jan 2021 16:26:10 GMT, Mahendra Chhipa <github.com+34924738+mahendrachhipa at openjdk.org> wrote:

>> jaxp.library.SimpleHttpServer
>> https://bugs.openjdk.java.net/browse/JDK-8212035
>
> Mahendra Chhipa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Implemented the review comments
>  - Merge branch 'master' into JDK-8212035
>  - Implemented the Review comments.
>  - Implemented the review comments
>  - Merge branch 'JDK-8212035' of https://github.com/mahendrachhipa/jdk into JDK-8212035
>  - Implemnted the review comments.
>  - Implemnted the review comments.
>  - Implemented the review comments.
>  - JDK-8212035 merge jdk.test.lib.util.SimpleHttpServer with
>    jaxp.library.SimpleHttpServer
>    https://bugs.openjdk.java.net/browse/JDK-8212035

Approved provided that tier2 tests are passing.

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

Marked as reviewed by dfuchs (Reviewer).

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

From alanb at openjdk.java.net  Tue Jan 12 16:56:58 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 12 Jan 2021 16:56:58 GMT
Subject: RFR: 8226810: Failed to launch JVM because of
 NullPointerException occured on System.props
In-Reply-To: <Q2lnBjXf9-4gabtOTD331KM3xrkqFJ6x5lkxNikHDQk=.d307c11b-1392-452a-8bf2-e8fdc4d6839a@github.com>
References: <Q2lnBjXf9-4gabtOTD331KM3xrkqFJ6x5lkxNikHDQk=.d307c11b-1392-452a-8bf2-e8fdc4d6839a@github.com>
Message-ID: <iyJ2Jv7pm4Dq6vxc97jK7GpfleteURsfU-ljmAF7Ezo=.25527605-11b7-4be3-94a9-e7ef5c2c8123@github.com>

On Tue, 12 Jan 2021 16:26:27 GMT, Evan Whelan <ewhelan at openjdk.org> wrote:

> Hi,
> 
> Please review this small change which enables the GB18030 charset to be built into java.base 
> 
> Thanks

Including GB18030 in java.base rather than jdk.charsets on Windows is fine. It does increase the size of java.base but that is less of a concern now than it used to be.

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

Marked as reviewed by alanb (Reviewer).

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

From chegar at openjdk.java.net  Tue Jan 12 17:08:59 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 12 Jan 2021 17:08:59 GMT
Subject: [jdk16] RFR: 8259636: Check for buffer backed by shared segment
 kicks in in unexpected places
In-Reply-To: <Z37jHHCVvUCGS8UDYH1lpd5Zwb3pOAOyZo2JRTERKeY=.5590d0ec-067e-4913-83b6-712fcd519d10@github.com>
References: <Z37jHHCVvUCGS8UDYH1lpd5Zwb3pOAOyZo2JRTERKeY=.5590d0ec-067e-4913-83b6-712fcd519d10@github.com>
Message-ID: <dEIDA6qz5QhIzYaXs65-0W9F3kHSR9D6Rt--K5dGSS4=.842d5aca-baea-4f6c-9294-0dc8dc69fa6a@github.com>

On Tue, 12 Jan 2021 15:48:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> When support for shared segment was added, we decided to disable support for buffers derived from shared segment in certain async operations, as there's currently no way to make sure that the memory won't be reclaimed while the IO operation is still taking place.
> 
> After looking at the code, it seemed like the best place to put the restriction would be sun.nio.ch.DirectBuffer::address() method, since this method is used in a lot of places just before jumping into some piece of JNI code.
> 
> While I still stand by that decision, the Netty team has discovered that this decision also affected operations such as creating slices from byte buffers derived from shared segment - this is caused by the fact that one direct buffer constructor (the one for views and slices) is calling the dreaded DirectBuffer::address method.
> 
> The fix is simple: just avoid the method call - which is very easy to do in the case of the buffer constructor: in fact this method just returns the value of the `address` field inside the `Buffer` class, so we can always cast to `Buffer` and then access `address` field from there.

Marked as reviewed by chegar (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/110

From chegar at openjdk.java.net  Tue Jan 12 17:04:57 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 12 Jan 2021 17:04:57 GMT
Subject: [jdk16] RFR: 8259634: MemorySegment::asByteBuffer does not
 respect spatial bounds
In-Reply-To: <Y3fAYuwsp99cUieNclfez8Vg2Jt-ossS8AZDSTWbsfk=.a6d23f8f-f054-4e99-a739-82f548a379a1@github.com>
References: <Y3fAYuwsp99cUieNclfez8Vg2Jt-ossS8AZDSTWbsfk=.a6d23f8f-f054-4e99-a739-82f548a379a1@github.com>
Message-ID: <JxtwhJNFuwWMRbg9Cy7ipW1lI2ahCZszacY-8bGVg0o=.709356ca-5827-44a0-981a-5498d3d593d0@github.com>

On Tue, 12 Jan 2021 15:28:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The byte buffers created from heap segments do not honor the javadoc - which says that the resulting buffer size should be equal to MemorySegment::byteSize, and that the buffer position should be zero.
> 
> The issue is that the NIO routine we have added to create heap buffers is using the wrong constructor, which doesn't do what we need. The fix is to simply use the proper, more complete constructor.
> 
> I've also re-enabled an unrelated test which was missing the @Test annotation.

Marked as reviewed by chegar (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/109

From mcimadamore at openjdk.java.net  Tue Jan 12 17:12:00 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 12 Jan 2021 17:12:00 GMT
Subject: [jdk16] Integrated: 8259634: MemorySegment::asByteBuffer does not
 respect spatial bounds
In-Reply-To: <Y3fAYuwsp99cUieNclfez8Vg2Jt-ossS8AZDSTWbsfk=.a6d23f8f-f054-4e99-a739-82f548a379a1@github.com>
References: <Y3fAYuwsp99cUieNclfez8Vg2Jt-ossS8AZDSTWbsfk=.a6d23f8f-f054-4e99-a739-82f548a379a1@github.com>
Message-ID: <K0JYcz_jl88ZazlaBosq-Xh_rRBqwFKqYL71gSNolkI=.d479b8f4-4f5d-4fee-9408-0751bb7d2478@github.com>

On Tue, 12 Jan 2021 15:28:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The byte buffers created from heap segments do not honor the javadoc - which says that the resulting buffer size should be equal to MemorySegment::byteSize, and that the buffer position should be zero.
> 
> The issue is that the NIO routine we have added to create heap buffers is using the wrong constructor, which doesn't do what we need. The fix is to simply use the proper, more complete constructor.
> 
> I've also re-enabled an unrelated test which was missing the @Test annotation.

This pull request has now been integrated.

Changeset: b03880e3
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/b03880e3
Stats:     30 lines in 2 files changed: 28 ins; 0 del; 2 mod

8259634: MemorySegment::asByteBuffer does not respect spatial bounds

Reviewed-by: alanb, chegar

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

PR: https://git.openjdk.java.net/jdk16/pull/109

From smarks at openjdk.java.net  Tue Jan 12 17:08:02 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 12 Jan 2021 17:08:02 GMT
Subject: [jdk16] Integrated: 8259298: broken link in Stream::toList spec
In-Reply-To: <KH0HIOOJAynBCzqN3Cp-mdYKJRc7aPVPOx3isGOmUnE=.c32fac9f-ee53-4ab9-a4a3-716a429a95f3@github.com>
References: <KH0HIOOJAynBCzqN3Cp-mdYKJRc7aPVPOx3isGOmUnE=.c32fac9f-ee53-4ab9-a4a3-716a429a95f3@github.com>
Message-ID: <h6G0OIinlYSjlRNd-qVepp0VRdJoh_S_mE7CCm3venk=.4058fc24-d5d0-4b63-ab6d-cd0c07993f5d@github.com>

On Mon, 11 Jan 2021 23:15:07 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Just fixing a broken link.

This pull request has now been integrated.

Changeset: 8a81cf15
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/8a81cf15
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8259298: broken link in Stream::toList spec

Reviewed-by: bchristi, iris, lancea, naoto

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

PR: https://git.openjdk.java.net/jdk16/pull/106

From mcimadamore at openjdk.java.net  Tue Jan 12 17:50:09 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 12 Jan 2021 17:50:09 GMT
Subject: [jdk16] RFR: 8259636: Check for buffer backed by shared segment
 kicks in in unexpected places [v2]
In-Reply-To: <Z37jHHCVvUCGS8UDYH1lpd5Zwb3pOAOyZo2JRTERKeY=.5590d0ec-067e-4913-83b6-712fcd519d10@github.com>
References: <Z37jHHCVvUCGS8UDYH1lpd5Zwb3pOAOyZo2JRTERKeY=.5590d0ec-067e-4913-83b6-712fcd519d10@github.com>
Message-ID: <CHsJhpPmuN2EYliQqqPQ2MXwPrr7Cnu9nW3f8-UpfCU=.60a2fdf0-fc10-4c50-9b47-e5282add0ca6@github.com>

> When support for shared segment was added, we decided to disable support for buffers derived from shared segment in certain async operations, as there's currently no way to make sure that the memory won't be reclaimed while the IO operation is still taking place.
> 
> After looking at the code, it seemed like the best place to put the restriction would be sun.nio.ch.DirectBuffer::address() method, since this method is used in a lot of places just before jumping into some piece of JNI code.
> 
> While I still stand by that decision, the Netty team has discovered that this decision also affected operations such as creating slices from byte buffers derived from shared segment - this is caused by the fact that one direct buffer constructor (the one for views and slices) is calling the dreaded DirectBuffer::address method.
> 
> The fix is simple: just avoid the method call - which is very easy to do in the case of the buffer constructor: in fact this method just returns the value of the `address` field inside the `Buffer` class, so we can always cast to `Buffer` and then access `address` field from there.

Maurizio Cimadamore 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 buffer_addr
 - Tweak direct buffer slice constructor not to use DirectBuffer::address

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

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

PR: https://git.openjdk.java.net/jdk16/pull/110

From naoto at openjdk.java.net  Tue Jan 12 17:54:55 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 12 Jan 2021 17:54:55 GMT
Subject: RFR: 8226810: Failed to launch JVM because of
 NullPointerException occured on System.props
In-Reply-To: <Q2lnBjXf9-4gabtOTD331KM3xrkqFJ6x5lkxNikHDQk=.d307c11b-1392-452a-8bf2-e8fdc4d6839a@github.com>
References: <Q2lnBjXf9-4gabtOTD331KM3xrkqFJ6x5lkxNikHDQk=.d307c11b-1392-452a-8bf2-e8fdc4d6839a@github.com>
Message-ID: <XQSYzokWlKJCDKkHe--DxzDOFilMN5ZJ0GQ7-OXqEL0=.be5bec81-c97b-4643-b697-5723125c18e1@github.com>

On Tue, 12 Jan 2021 16:26:27 GMT, Evan Whelan <ewhelan at openjdk.org> wrote:

> Hi,
> 
> Please review this small change which enables the GB18030 charset to be built into java.base 
> 
> Thanks

Looks fine.

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

Marked as reviewed by naoto (Reviewer).

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

From joehw at openjdk.java.net  Tue Jan 12 18:53:05 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 12 Jan 2021 18:53:05 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline
Message-ID: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>

Please review a patch to add an explicit control over whether a newline should be added after the XML header. This is done by adding a DOM LSSerializer property "jdk-is-standalone" and System property "jdk.xml.isStandalone". 

This change addresses an incompatibility introduced during 7u4 as an update to Xalan 2.7.1.

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

Commit messages:
 - fix test, remove whitespace
 - 8249867: xml declaration is not followed by a newline

Changes: https://git.openjdk.java.net/jdk/pull/2041/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2041&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8249867
  Stats: 242 lines in 4 files changed: 193 ins; 1 del; 48 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2041.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2041/head:pull/2041

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

From jvernee at openjdk.java.net  Tue Jan 12 19:21:08 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 12 Jan 2021 19:21:08 GMT
Subject: RFR: 8255531: MethodHandles::permuteArguments throws NPE when
 duplicating dropped arguments
Message-ID: <jjesjsHhraVtdE1gJGmOtJmO0Q-ICo5NhoLSWVA4RHg=.4d60e3b6-7d23-4a1b-8f34-b3fdb2329617@github.com>

Hi,

This small patch fixes the NPE in the following case:

    MethodHandle mh = MethodHandles.empty(MethodType.methodType(void.class, int.class, int.class));
    MethodHandles.permuteArguments(mh, MethodType.methodType(void.class, int.class), 0, 0);
    
If a parameter name was changed by a lambda form edit, `LambdaForm::endEdit` will try to sort the names that fall into the old range of parameter names (starting from `firstChanged` and up to `arity` in the code) to make sure that non-parameter names (`exprs`) properly appear after parameter names. But, if a parameter was dropped, and there are no non-paramter names, a `null` will fall into the range that is being sorted, and the call to `name.isParam()` in the sorting algorithm will result in an NPE.

We can just add a `name != null` check there, since `null` is definitely not a parameter. However, we still need to do the loop in order to get an accurate `exprp` value, which is later used to adjust the `arity` after sorting (there are other ways to get there that don't involve copying the extra `null`, but they are more convoluted, so I elected to go for this solution).

Thanks,
Jorn

Testing: tier1-tier2

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

Commit messages:
 - Avoid NPEs in permuteArguments in cases where parameters are dropped from LambdaForms that don't have any other names (e.g. empty)

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

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

From github.com+34924738+mahendrachhipa at openjdk.java.net  Tue Jan 12 19:28:56 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Tue, 12 Jan 2021 19:28:56 GMT
Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with
 jaxp.library.SimpleHttpServer [v6]
In-Reply-To: <XV9kxPEm_BUq4Br3y-ANnGCGTPx_VltT6fl-0Ox94A4=.e7c9c1ff-3806-44ae-8844-cf3aa0b3538a@github.com>
References: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
 <isR-HAF6xahbZLAGrIwyyStcQWtrOml8EXg3cFEIngc=.cbe23f3b-21a3-4028-8278-a153dbbb03d1@github.com>
 <XV9kxPEm_BUq4Br3y-ANnGCGTPx_VltT6fl-0Ox94A4=.e7c9c1ff-3806-44ae-8844-cf3aa0b3538a@github.com>
Message-ID: <zCdhTGOwlzn8sd1nV4nubm3sDF-5JT4qAThNi2YQFcg=.da4e10bb-99d5-4b9e-b894-cda63a2cd6d8@github.com>

On Tue, 12 Jan 2021 16:52:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Approved provided that tier2 tests are passing.

All tier2 tests related to changes are passing. Here is the Mach5 result link:
https://mach5.us.oracle.com/mdash/jobs/mahendrachhipa-jdk-20210112-1759-17354032?search=result.status%3APASSED

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

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

From ewhelan at openjdk.java.net  Tue Jan 12 20:43:56 2021
From: ewhelan at openjdk.java.net (Evan Whelan)
Date: Tue, 12 Jan 2021 20:43:56 GMT
Subject: Integrated: 8226810: Failed to launch JVM because of
 NullPointerException occured on System.props
In-Reply-To: <Q2lnBjXf9-4gabtOTD331KM3xrkqFJ6x5lkxNikHDQk=.d307c11b-1392-452a-8bf2-e8fdc4d6839a@github.com>
References: <Q2lnBjXf9-4gabtOTD331KM3xrkqFJ6x5lkxNikHDQk=.d307c11b-1392-452a-8bf2-e8fdc4d6839a@github.com>
Message-ID: <_sVuvLZZf-hKgwpT624RTYuFyK10K6_-qixODalaSqs=.91781b85-f772-4106-b923-d4f4302beb97@github.com>

On Tue, 12 Jan 2021 16:26:27 GMT, Evan Whelan <ewhelan at openjdk.org> wrote:

> Hi,
> 
> Please review this small change which enables the GB18030 charset to be built into java.base 
> 
> Thanks

This pull request has now been integrated.

Changeset: 5f7ccce0
Author:    Evan Whelan <ewhelan at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5f7ccce0
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8226810: Failed to launch JVM because of NullPointerException occured on System.props

Reviewed-by: alanb, naoto

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

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

From mcimadamore at openjdk.java.net  Tue Jan 12 21:58:15 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 12 Jan 2021 21:58:15 GMT
Subject: [jdk16] Integrated: 8259636: Check for buffer backed by shared
 segment kicks in in unexpected places
In-Reply-To: <Z37jHHCVvUCGS8UDYH1lpd5Zwb3pOAOyZo2JRTERKeY=.5590d0ec-067e-4913-83b6-712fcd519d10@github.com>
References: <Z37jHHCVvUCGS8UDYH1lpd5Zwb3pOAOyZo2JRTERKeY=.5590d0ec-067e-4913-83b6-712fcd519d10@github.com>
Message-ID: <qvyn86BbrJSLgYxDQLgt77yIdzAKJiF3AZqUVHSBlMc=.9fa7aed6-b893-4f98-a354-13c1b1ba5109@github.com>

On Tue, 12 Jan 2021 15:48:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> When support for shared segment was added, we decided to disable support for buffers derived from shared segment in certain async operations, as there's currently no way to make sure that the memory won't be reclaimed while the IO operation is still taking place.
> 
> After looking at the code, it seemed like the best place to put the restriction would be sun.nio.ch.DirectBuffer::address() method, since this method is used in a lot of places just before jumping into some piece of JNI code.
> 
> While I still stand by that decision, the Netty team has discovered that this decision also affected operations such as creating slices from byte buffers derived from shared segment - this is caused by the fact that one direct buffer constructor (the one for views and slices) is calling the dreaded DirectBuffer::address method.
> 
> The fix is simple: just avoid the method call - which is very easy to do in the case of the buffer constructor: in fact this method just returns the value of the `address` field inside the `Buffer` class, so we can always cast to `Buffer` and then access `address` field from there.

This pull request has now been integrated.

Changeset: 17b4db31
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/17b4db31
Stats:     11 lines in 2 files changed: 9 ins; 1 del; 1 mod

8259636: Check for buffer backed by shared segment kicks in in unexpected places

Reviewed-by: sundar, alanb, chegar

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

PR: https://git.openjdk.java.net/jdk16/pull/110

From rriggs at openjdk.java.net  Tue Jan 12 21:58:19 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 12 Jan 2021 21:58:19 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline
In-Reply-To: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
Message-ID: <-xzrzdRLkZK7xTknu85L2PHSfEVFVd3DD5UjYlh26gE=.a9651f07-22c9-49d6-a523-ed2060c6d1d9@github.com>

On Tue, 12 Jan 2021 01:24:38 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Please review a patch to add an explicit control over whether a newline should be added after the XML header. This is done by adding a DOM LSSerializer property "jdk-is-standalone" and System property "jdk.xml.isStandalone". 
> 
> This change addresses an incompatibility introduced during 7u4 as an update to Xalan 2.7.1.

When setting the fDOMConfigProperties is the difference between simple values of "yes" and "no" and the values of DOMConstants.DOM3_EXPLICIT_TRUE/FALSE significant?

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

Marked as reviewed by rriggs (Reviewer).

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

From joehw at openjdk.java.net  Tue Jan 12 23:27:00 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 12 Jan 2021 23:27:00 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline
In-Reply-To: <-xzrzdRLkZK7xTknu85L2PHSfEVFVd3DD5UjYlh26gE=.a9651f07-22c9-49d6-a523-ed2060c6d1d9@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
 <-xzrzdRLkZK7xTknu85L2PHSfEVFVd3DD5UjYlh26gE=.a9651f07-22c9-49d6-a523-ed2060c6d1d9@github.com>
Message-ID: <lS6vCnff3UE33wtf1NICSU7kb6XnjDnaFzEUeF9ULt0=.eea17e4b-71c5-4ec7-9c33-d805c1c4d5ac@github.com>

On Tue, 12 Jan 2021 21:25:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Please review a patch to add an explicit control over whether a newline should be added after the XML header. This is done by adding a DOM LSSerializer property "jdk-is-standalone" and System property "jdk.xml.isStandalone". 
>> 
>> This change addresses an incompatibility introduced during 7u4 as an update to Xalan 2.7.1.
>
> When setting the fDOMConfigProperties is the difference between simple values of "yes" and "no" and the values of DOMConstants.DOM3_EXPLICIT_TRUE/FALSE significant?

The DOMConfigProperties differentiate "Explicit" values from the default ones. DOM3_EXPLICIT_TRUE/FALSE has a string form: explicit:yes/explicit:no, while the default ones default:yes/default:no. In some cases (for some parameters), default values are handled differently from the explicit ones. 

In this case, it's not significant for the new property as to how it was processed. I merely followed the existing practice and mechanism to align with the existing parameters.

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

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

From mbalao at openjdk.java.net  Tue Jan 12 23:47:57 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Tue, 12 Jan 2021 23:47:57 GMT
Subject: Integrated: 8259319: Illegal package access when SunPKCS11 requires
 SunJCE's classes
In-Reply-To: <u0MKmmnw4k2MnkDD-a26NsLCRk1NEtbf9MY4MHSPa6Y=.9d02a25d-9eb8-4ed2-88c8-9d239be0f7df@github.com>
References: <u0MKmmnw4k2MnkDD-a26NsLCRk1NEtbf9MY4MHSPa6Y=.9d02a25d-9eb8-4ed2-88c8-9d239be0f7df@github.com>
Message-ID: <xdxZr_oSdnj-geBjJrn20nJvcMvXcQo_-p-_3U06BDM=.aef82d46-05ca-4fb3-8cd5-37712a9d2cf9@github.com>

On Wed, 6 Jan 2021 15:33:59 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> As described in JDK-8259319 [1], this fix proposal is to set proper access permissions so the SunPKCS11 provider can create instances of SunJCE classes when a Security Manager is installed and the fallback scheme is used.
> 
> No regressions found in jdk/sun/security/pkcs11 tests category.
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8259319

This pull request has now been integrated.

Changeset: 4be21734
Author:    Martin Balao <mbalao at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4be21734
Stats:     122 lines in 4 files changed: 115 ins; 0 del; 7 mod

8259319: Illegal package access when SunPKCS11 requires SunJCE's classes

Reviewed-by: valeriep, mullan

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

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

From naoto at openjdk.java.net  Tue Jan 12 23:58:55 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 12 Jan 2021 23:58:55 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline
In-Reply-To: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
Message-ID: <glT6znK3oRplIZKfSwuTiKaVICyaceK_g0lMTsnAht4=.bd429fc9-2410-467c-8665-78165693b355@github.com>

On Tue, 12 Jan 2021 01:24:38 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Please review a patch to add an explicit control over whether a newline should be added after the XML header. This is done by adding a DOM LSSerializer property "jdk-is-standalone" and System property "jdk.xml.isStandalone". 
> 
> This change addresses an incompatibility introduced during 7u4 as an update to Xalan 2.7.1.

src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOMConstants.java line 131:

> 129: 
> 130:     // Corresponding System property
> 131:     public static final String SP_IS_STANDALONE = "jdk.xml.isStandalone";

Should this system property key be described somewhere in the javadoc, as an Oracle implSpec? Otherwise, how the user would know this switch?

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

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

From joehw at openjdk.java.net  Wed Jan 13 00:20:57 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 13 Jan 2021 00:20:57 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline
In-Reply-To: <glT6znK3oRplIZKfSwuTiKaVICyaceK_g0lMTsnAht4=.bd429fc9-2410-467c-8665-78165693b355@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
 <glT6znK3oRplIZKfSwuTiKaVICyaceK_g0lMTsnAht4=.bd429fc9-2410-467c-8665-78165693b355@github.com>
Message-ID: <9eJmi5bwG6atZ4coN_PGUYQhepmvvhyc8R7cs0ZzYjs=.5e532a5d-be3d-49a5-a09f-ce920de8d366@github.com>

On Tue, 12 Jan 2021 23:56:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review a patch to add an explicit control over whether a newline should be added after the XML header. This is done by adding a DOM LSSerializer property "jdk-is-standalone" and System property "jdk.xml.isStandalone". 
>> 
>> This change addresses an incompatibility introduced during 7u4 as an update to Xalan 2.7.1.
>
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOMConstants.java line 131:
> 
>> 129: 
>> 130:     // Corresponding System property
>> 131:     public static final String SP_IS_STANDALONE = "jdk.xml.isStandalone";
> 
> Should this system property key be described somewhere in the javadoc, as an Oracle implSpec? Otherwise, how the user would know this switch?

So far as with the current practice, we would document JDK specific properties in the Release Notes (refer to the Release Note sub-task for this particular property). We also created tutorials for the ones that are within a major topic (e.g. security). Plus, even if we'd want to add an implSpec, we wouldn't be able to since the DOM's license is quite restrictive.

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

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

From valeriep at openjdk.java.net  Wed Jan 13 00:59:55 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 13 Jan 2021 00:59:55 GMT
Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests
In-Reply-To: <uf-mqauyRYR8pTAR30tTSd3wBoJlBWQZNBppVZlEGac=.4e00ca14-4a17-4a67-886e-af16c742f282@github.com>
References: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
 <Pn3d8r5Xx1SOhCSiU-aXvab87-uq1Llbv0xngYxUxMU=.bf269dd2-c111-4f13-b908-53b04d882d9a@github.com>
 <-U8jAG-h-jY8A4fC0qLCt8VK3hKfblzH-MHp-k7cppA=.f604d5fe-a835-49a2-aec9-d9283275603e@github.com>
 <lRiAsnEUYx-SVegGg-5x0VzYzPadDDhw5fZjY5guIs0=.17d2bdf5-aa18-4282-9c42-a654f2a672ff@github.com>
 <CaAWIqQ65gRTYNby5Zy0j8vj2F3m-wikrkxYKw1ojYk=.d44dccc0-0f0b-4517-96e9-44976bf99fb5@github.com>
 <GDqNO-QP0nohRA2aAVxzMrRLiZg7WGiVSG-n-OQobx4=.8c191619-e4ae-43d8-bbde-11b5ac6375d9@github.com>
 <uf-mqauyRYR8pTAR30tTSd3wBoJlBWQZNBppVZlEGac=.4e00ca14-4a17-4a67-886e-af16c742f282@github.com>
Message-ID: <9GYqxzH-YJDTOakTpUv85VZmAmLKS_J7ZnNJhiIs9rk=.289e67b2-077b-469e-b0d7-533db1b36e62@github.com>

On Thu, 7 Jan 2021 18:50:05 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Removing the UUID clone cache and running the microbenchmark along with the changes in #1933:
>> 
>> Benchmark                                                  (size)   Mode  Cnt    Score    Error   Units
>> UUIDBench.fromType3Bytes                                    20000  thrpt   12    2.182 ?  0.090  ops/us
>> UUIDBench.fromType3Bytes:?gc.alloc.rate                     20000  thrpt   12  439.020 ? 18.241  MB/sec
>> UUIDBench.fromType3Bytes:?gc.alloc.rate.norm                20000  thrpt   12  264.022 ?  0.003    B/op
>> 
>> The goal now is if to simplify the digest code and compare alternatives.
>
> I've run various tests and concluded that the `VarHandle`ized code is matching or improving upon the `Unsafe`-riddled code in `ByteArrayAccess`. I then went ahead and consolidated to use similar code pattern in `ByteArrayAccess` for consistency, which amounts to a good cleanup.
> 
> With MD5 intrinsics disabled, I get this baseline:
> 
> Benchmark                                                  (size)   Mode  Cnt    Score    Error   Units
> UUIDBench.fromType3Bytes                                    20000  thrpt   12    1.245 ?  0.077  ops/us
> UUIDBench.fromType3Bytes:?gc.alloc.rate.norm                20000  thrpt   12  488.042 ?  0.004    B/op
> 
> With the current patch here (not including #1933): 
> Benchmark                                                  (size)   Mode  Cnt    Score    Error   Units
> UUIDBench.fromType3Bytes                                    20000  thrpt   12    1.431 ?  0.106  ops/us
> UUIDBench.fromType3Bytes:?gc.alloc.rate.norm                20000  thrpt   12  408.035 ?  0.006    B/op
> 
> If I isolate the `ByteArrayAccess` changes I'm getting performance neutral or slightly better numbers compared to baseline for these tests:
> 
> Benchmark                                                  (size)   Mode  Cnt    Score    Error   Units
> UUIDBench.fromType3Bytes                                    20000  thrpt   12    1.317 ?  0.092  ops/us
> UUIDBench.fromType3Bytes:?gc.alloc.rate.norm                20000  thrpt   12  488.042 ?  0.004    B/op

Thanks for the performance enhancement, I will take a look.

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

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

From naoto at openjdk.java.net  Wed Jan 13 01:33:04 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 13 Jan 2021 01:33:04 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline
In-Reply-To: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
Message-ID: <iCwYYT1Tv80pMuluvN5unFhxL781l6TZvHVnUOSSEgQ=.7615a9c1-24d0-4237-b013-be3bec417cf5@github.com>

On Tue, 12 Jan 2021 01:24:38 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Please review a patch to add an explicit control over whether a newline should be added after the XML header. This is done by adding a DOM LSSerializer property "jdk-is-standalone" and System property "jdk.xml.isStandalone". 
> 
> This change addresses an incompatibility introduced during 7u4 as an update to Xalan 2.7.1.

Marked as reviewed by naoto (Reviewer).

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

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

From david.holmes at oracle.com  Wed Jan 13 01:33:36 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 13 Jan 2021 11:33:36 +1000
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection
In-Reply-To: <Mat51HIuUYISDvMtuz4R7LJ2R1aBeGASWCyBWAXFlAI=.f3329041-9c29-4b4b-ba66-163233764fb9@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
 <Ynmw17EfEzNeUK5w2ABmHkXqqXo98GTcYTnZFGoAYIk=.1079ee11-c9e7-443f-b74b-d94838206a2a@github.com>
 <eFFokFwfdmu0YTyAhvPJ7xBFo0ypjHw3MyC_9-aTS6g=.80ad5876-3ae3-4ca3-96b5-08db53ed6627@github.com>
 <COWzygAauFzmvgYYP6DVjIg0MH6EDyIMx0ZzeTRHol0=.8a01079b-6e40-4b1b-bb75-e693f89d8871@github.com>
 <iT7Ltrm52E9skv98tAKIYPB1ZCaXw8ep-YSegjEnhxc=.68635047-f51c-4c60-9731-0da103e56a39@github.com>
 <m1iurC4l1M904NY7lj5eVIB8jgCfBLR2sh8XrQzhJUM=.c2c5c01f-c29a-4b22-922b-e56472e951ec@github.com>
 <Mat51HIuUYISDvMtuz4R7LJ2R1aBeGASWCyBWAXFlAI=.f3329041-9c29-4b4b-ba66-163233764fb9@github.com>
Message-ID: <e08c9981-40e0-ba90-04ca-a2e01d82da67@oracle.com>

Hi Severin,

On 13/01/2021 12:31 am, Severin Gehwolf wrote:
> On Tue, 15 Dec 2020 12:57:12 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:
> 
>>> @bobvandette Please review when you've got some cycles to spare. Much appreciated!
>>
>> Ping? Anyone?
> 
> Anybody willing to review this?

FYI Bob retired at the end of last year.

I don't know who currently has working knowledge of Cgroups on the 
core-libs and serviceability mailing lists.

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1393
> 

From naoto at openjdk.java.net  Wed Jan 13 01:33:05 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 13 Jan 2021 01:33:05 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline
In-Reply-To: <9eJmi5bwG6atZ4coN_PGUYQhepmvvhyc8R7cs0ZzYjs=.5e532a5d-be3d-49a5-a09f-ce920de8d366@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
 <glT6znK3oRplIZKfSwuTiKaVICyaceK_g0lMTsnAht4=.bd429fc9-2410-467c-8665-78165693b355@github.com>
 <9eJmi5bwG6atZ4coN_PGUYQhepmvvhyc8R7cs0ZzYjs=.5e532a5d-be3d-49a5-a09f-ce920de8d366@github.com>
Message-ID: <EdbnG2QowebSsPgmyNj4uC-ubm8UJFAxfLjMr2DH3eE=.89744e64-f1e2-4709-a445-4d7d9d35b735@github.com>

On Wed, 13 Jan 2021 00:17:57 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOMConstants.java line 131:
>> 
>>> 129: 
>>> 130:     // Corresponding System property
>>> 131:     public static final String SP_IS_STANDALONE = "jdk.xml.isStandalone";
>> 
>> Should this system property key be described somewhere in the javadoc, as an Oracle implSpec? Otherwise, how the user would know this switch?
>
> So far as with the current practice, we would document JDK specific properties in the Release Notes (refer to the Release Note sub-task for this particular property). We also created tutorials for the ones that are within a major topic (e.g. security). Plus, even if we'd want to add an implSpec, we wouldn't be able to since the DOM's license is quite restrictive.

OK. Thanks for the explanation.

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

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

From sgehwolf at redhat.com  Wed Jan 13 09:56:45 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 13 Jan 2021 10:56:45 +0100
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface
 files for version detection
In-Reply-To: <e08c9981-40e0-ba90-04ca-a2e01d82da67@oracle.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
 <Ynmw17EfEzNeUK5w2ABmHkXqqXo98GTcYTnZFGoAYIk=.1079ee11-c9e7-443f-b74b-d94838206a2a@github.com>
 <eFFokFwfdmu0YTyAhvPJ7xBFo0ypjHw3MyC_9-aTS6g=.80ad5876-3ae3-4ca3-96b5-08db53ed6627@github.com>
 <COWzygAauFzmvgYYP6DVjIg0MH6EDyIMx0ZzeTRHol0=.8a01079b-6e40-4b1b-bb75-e693f89d8871@github.com>
 <iT7Ltrm52E9skv98tAKIYPB1ZCaXw8ep-YSegjEnhxc=.68635047-f51c-4c60-9731-0da103e56a39@github.com>
 <m1iurC4l1M904NY7lj5eVIB8jgCfBLR2sh8XrQzhJUM=.c2c5c01f-c29a-4b22-922b-e56472e951ec@github.com>
 <Mat51HIuUYISDvMtuz4R7LJ2R1aBeGASWCyBWAXFlAI=.f3329041-9c29-4b4b-ba66-163233764fb9@github.com>
 <e08c9981-40e0-ba90-04ca-a2e01d82da67@oracle.com>
Message-ID: <d6e1394594d7b9f84131b89d67b84ec6ae253832.camel@redhat.com>

Hi David,

On Wed, 2021-01-13 at 11:33 +1000, David Holmes wrote:
Hi Severin,

On 13/01/2021 12:31 am, Severin Gehwolf wrote:
> On Tue, 15 Dec 2020 12:57:12 GMT, Severin Gehwolf
> <sgehwolf at openjdk.org> wrote:
> 
> > > @bobvandette Please review when you've got some cycles to spare.
> > > Much appreciated!
> > 
> > Ping? Anyone?
> 
> Anybody willing to review this?

FYI Bob retired at the end of last year.

I don't know who currently has working knowledge of Cgroups on the 
core-libs and serviceability mailing lists.

Yes, thanks.

That seems to be my problem, actually. I can't review it myself :-/

Cheers,
Severin


From dfuchs at openjdk.java.net  Wed Jan 13 11:19:56 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 13 Jan 2021 11:19:56 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline
In-Reply-To: <EdbnG2QowebSsPgmyNj4uC-ubm8UJFAxfLjMr2DH3eE=.89744e64-f1e2-4709-a445-4d7d9d35b735@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
 <glT6znK3oRplIZKfSwuTiKaVICyaceK_g0lMTsnAht4=.bd429fc9-2410-467c-8665-78165693b355@github.com>
 <9eJmi5bwG6atZ4coN_PGUYQhepmvvhyc8R7cs0ZzYjs=.5e532a5d-be3d-49a5-a09f-ce920de8d366@github.com>
 <EdbnG2QowebSsPgmyNj4uC-ubm8UJFAxfLjMr2DH3eE=.89744e64-f1e2-4709-a445-4d7d9d35b735@github.com>
Message-ID: <omaSeWu1aI9q3j8CZ5fkrsmvThWMr6lHinUgQ2lC9iQ=.f05b9c5e-182c-40cc-b2b2-5834f0db033d@github.com>

On Wed, 13 Jan 2021 01:30:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> So far as with the current practice, we would document JDK specific properties in the Release Notes (refer to the Release Note sub-task for this particular property). We also created tutorials for the ones that are within a major topic (e.g. security). Plus, even if we'd want to add an implSpec, we wouldn't be able to since the DOM's license is quite restrictive.
>
> OK. Thanks for the explanation.

Note: If such properties needed to be documented - they could also be documented as JDK implementation specific properties in the module-info file. This is what we have started doing for some of the properties supported by JNDI providers, for instance.

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

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

From tvaleev at openjdk.java.net  Wed Jan 13 12:50:09 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Wed, 13 Jan 2021 12:50:09 GMT
Subject: RFR: 8259622: TreeMap.computeIfAbsent deviates from spec
Message-ID: <kltUEUk_zHC1CS9hSlLJdbhr9uMKqMpEMx5FOLz1Y3M=.104e4a8d-2cdc-428b-9922-4222003e9131@github.com>

Handle TreeMap::computeIfAbsent when previous mapping with null value existed (in this case spec requires to overwrite the existing mapping)

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

Commit messages:
 - 8259622: TreeMap.computeIfAbsent deviates from spec

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

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

From sgehwolf at openjdk.java.net  Wed Jan 13 13:49:27 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 13 Jan 2021 13:49:27 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection [v3]
In-Reply-To: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
Message-ID: <NGeQ8dP-lzmsMfelY9VAqTLIMneJav0p7dAqw41pMnM=.f082865a-1926-42f4-b4dc-2e21145fbae0@github.com>

> This is an enhancement which solves two issues:
> 
> 1. Multiple reads of relevant cgroup interface files. Now interface files are only read once per file (just like Hotspot).
> 2. Proxies creation of the impl specific subsystem via `determineType()` as before, but now reads all relevant interface files: `/proc/cgroups`, `/proc/self/mountinfo` and `/proc/self/cgroup`. Once read it passes the parsed information to the impl specific subsystem classes for instantiation. This allows for more flexibility of testing as interface files can be mocked and, thus, more cases can be tested that way without having access to these specific systems. For example, proper regression tests for JDK-8217766 and JDK-8253435 have been added now with this in place.
> 
> * [x] Tested on Linux x86_64 on cgroups v1 and cgroups v2. Container tests pass.

Severin Gehwolf 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:

 - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics
 - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics
 - 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1393/files
  - new: https://git.openjdk.java.net/jdk/pull/1393/files/fd55ffd7..0ece5f22

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

  Stats: 53075 lines in 1681 files changed: 24628 ins; 14727 del; 13720 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1393.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1393/head:pull/1393

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

From github.com+34924738+mahendrachhipa at openjdk.java.net  Wed Jan 13 15:56:07 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Wed, 13 Jan 2021 15:56:07 GMT
Subject: Integrated: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer
 with jaxp.library.SimpleHttpServer
In-Reply-To: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
References: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
Message-ID: <Fq1m6kW19zyz0Vlht6vDVXxxPtkIzJA-_SUUNsKAtCw=.34798960-b163-466e-ad40-fbcfbaf4f420@github.com>

On Fri, 4 Dec 2020 19:44:33 GMT, Mahendra Chhipa <github.com+34924738+mahendrachhipa at openjdk.org> wrote:

> jaxp.library.SimpleHttpServer
> https://bugs.openjdk.java.net/browse/JDK-8212035

This pull request has now been integrated.

Changeset: 5df2a949
Author:    Mahendra Chhipa <mahendra.chhipa at oracle.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5df2a949
Stats:     651 lines in 17 files changed: 227 ins; 321 del; 103 mod

8212035: merge jdk.test.lib.util.SimpleHttpServer with jaxp.library.SimpleHttpServer

Reviewed-by: dfuchs

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

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

From daniel.fuchs at oracle.com  Wed Jan 13 16:50:37 2021
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 13 Jan 2021 16:50:37 +0000
Subject: Difference in encoding semantics of URI returned by File.toURI
 and Path.toUri representing the same file
In-Reply-To: <3cd8d31d-1640-a855-4ba2-bf05be8adfe0@gmail.com>
References: <3cd8d31d-1640-a855-4ba2-bf05be8adfe0@gmail.com>
Message-ID: <08edf854-6414-800f-4fa4-2f06d234e6a6@oracle.com>

Hi Jaikiran,

java.net.URI doesn't require encoding non ascii characters, but
calling URI.toASCIIString() will ensure that they get encoded.

The two URIs, with non ASCII characters encoded or not encoded,
should be equivalent.

On 18/12/2020 04:50, Jaikiran Pai wrote:
> 
> URI from Paths.get().toUri() API /private/tmp/delme/foob?r ---> 
> file:///private/tmp/delme/fooba%CC%83r/

This looks like what you would obtain by calling URI.toASCIIString(),
except it's not exactly the same:

URI.create("file:///private/tmp/delme/foob?r/").toASCIIString()
---> file:///private/tmp/delme/foob%C3%A3r/

One form ("%C3%A3") is the UTF-8 encoding of the "?" unicode
character (U+00E3);
The other form ("a%80%83") is the combination of lower case "a"
followed by the combining "~" character ("a" + U+0303) which is another
way of encoding the "?" glyph in Unicode.

This is because URI.toASCIIString() uses NFC before encoding the UTF-8
sequence representing "?". Obviously Path.toURI() does not do that.
It's not clear to me whether NFC should be applied - or what would be
the consequences of applying NFC there (or not).

Both encodings seems to be working - if you feed the encoded string
to new URL(string).openConnection();

> URI from File.toPath().toUri() API /private/tmp/delme/foob?r ---> 
> file:///private/tmp/delme/fooba%CC%83r/
> URI from File.toURI() API /private/tmp/delme/foob?r ---> 
> file:/private/tmp/delme/foob?r/

best regards,

-- daniel

From herrick at openjdk.java.net  Wed Jan 13 16:51:15 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 13 Jan 2021 16:51:15 GMT
Subject: RFR: JDK-8258755: jpackage: Invalid 32-bit exe when building app-image
Message-ID: <s7PJA74O7GtTqPkaLzHQ033a9vlKG2ZfX6HCdgKmNZQ=.6cda02fc-bd7d-4d2b-ab1b-b3d7c5641b05@github.com>

JDK-8258755: jpackage: Invalid 32-bit exe when building app-image

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

Commit messages:
 - JDK-8258755: jpackage: Invalid 32-bit exe when building app-image
 - JDK-8258755: jpackage: Invalid 32-bit exe when building app-image
 -     JDK-8258755: jpackage: Invalid 32-bit exe when building app-image

Changes: https://git.openjdk.java.net/jdk/pull/2030/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2030&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258755
  Stats: 14 lines in 3 files changed: 10 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2030.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2030/head:pull/2030

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

From asemenyuk at openjdk.java.net  Wed Jan 13 16:51:16 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 13 Jan 2021 16:51:16 GMT
Subject: RFR: JDK-8258755: jpackage: Invalid 32-bit exe when building
 app-image
In-Reply-To: <s7PJA74O7GtTqPkaLzHQ033a9vlKG2ZfX6HCdgKmNZQ=.6cda02fc-bd7d-4d2b-ab1b-b3d7c5641b05@github.com>
References: <s7PJA74O7GtTqPkaLzHQ033a9vlKG2ZfX6HCdgKmNZQ=.6cda02fc-bd7d-4d2b-ab1b-b3d7c5641b05@github.com>
Message-ID: <_vPbBn7SHTG2l1Jv9TSeC2Fm00furNuODerHQURKhLA=.e2f64fd7-205a-497e-abd7-ffa2369591d2@github.com>

On Mon, 11 Jan 2021 17:42:21 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8258755: jpackage: Invalid 32-bit exe when building app-image

Changes requested by asemenyuk (Committer).

src/jdk.jpackage/share/native/applauncher/JvmLauncher.h line 37:

> 35: #define LAUNCH_FUNC "JLI_Launch"
> 36: #endif
> 37: 

I'd move this define in JvmLauncher.cpp. There is no need to make it visible outside of JvmLauncher implementation.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/Platform.java line 127:

> 125:         return is64b;
> 126:     }
> 127: 

This function makes sense only on Windows platform. Why not add it to Windows-specific class, e.g. WixSourcesBuilder?

The value should not be based on arch of OS, but on arch of JDK. msi installer produced by jpackage from 32bit JDK (in case somebody would build 32bit OpenJDK) would contain 32bit Java runtime regardless on 64bit or 32bit Windows it will be executed. I'd use `sun.arch.data.model` instead of `os.arch`

src/jdk.jpackage/share/classes/jdk/jpackage/internal/Platform.java line 127:

> 125:         return is64b;
> 126:     }
> 127: 

This is Windows specific thing. There is no point to keep it in shared code. I'd suggest to move this function in WixSourcesBuilder class.

I think it is not correct to check for arch of the OS where jpackage runs. Jpackage from 32bit JDK (if somebody would build 32bit OpenJDK) would bake in 32bit Java runtime in app image regardless Windows is 64bit or 32bit. So the arch of installer is determined by arch of Java runtime baked in the app image. For simplicity we can assume that arch of Java runtime is the same as the arch of jpackage (this might not be the case for external Java runtime case though, but let's leave this possibility aside as it is not supported anyways). If so, checking of `sun.arch.data.model` system property would be better alternative to `os.arch`.

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

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

From herrick at openjdk.java.net  Wed Jan 13 16:51:16 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 13 Jan 2021 16:51:16 GMT
Subject: RFR: JDK-8258755: jpackage: Invalid 32-bit exe when building
 app-image
In-Reply-To: <s7PJA74O7GtTqPkaLzHQ033a9vlKG2ZfX6HCdgKmNZQ=.6cda02fc-bd7d-4d2b-ab1b-b3d7c5641b05@github.com>
References: <s7PJA74O7GtTqPkaLzHQ033a9vlKG2ZfX6HCdgKmNZQ=.6cda02fc-bd7d-4d2b-ab1b-b3d7c5641b05@github.com>
Message-ID: <LkXN8EjRcHHY9J6HnUe3CfMXyGJygdl7L1L7u5heggM=.2e9fe799-225e-4ef2-8a8c-b474903d3a94@github.com>

On Mon, 11 Jan 2021 17:42:21 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8258755: jpackage: Invalid 32-bit exe when building app-image

JDK-8258755: jpackage: Invalid 32-bit exe when building app-image

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

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

From herrick at openjdk.java.net  Wed Jan 13 16:51:17 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 13 Jan 2021 16:51:17 GMT
Subject: RFR: JDK-8258755: jpackage: Invalid 32-bit exe when building
 app-image
In-Reply-To: <_vPbBn7SHTG2l1Jv9TSeC2Fm00furNuODerHQURKhLA=.e2f64fd7-205a-497e-abd7-ffa2369591d2@github.com>
References: <s7PJA74O7GtTqPkaLzHQ033a9vlKG2ZfX6HCdgKmNZQ=.6cda02fc-bd7d-4d2b-ab1b-b3d7c5641b05@github.com>
 <_vPbBn7SHTG2l1Jv9TSeC2Fm00furNuODerHQURKhLA=.e2f64fd7-205a-497e-abd7-ffa2369591d2@github.com>
Message-ID: <h7e9EFxJEKlU6DTlJxHkbSbABWh3BNqZaqTB17N3qd4=.1b601ac9-1530-4f07-9fe6-a1d8bf33ff77@github.com>

On Tue, 12 Jan 2021 20:49:52 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> JDK-8258755: jpackage: Invalid 32-bit exe when building app-image
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Platform.java line 127:
> 
>> 125:         return is64b;
>> 126:     }
>> 127: 
> 
> This function makes sense only on Windows platform. Why not add it to Windows-specific class, e.g. WixSourcesBuilder?
> 
> The value should not be based on arch of OS, but on arch of JDK. msi installer produced by jpackage from 32bit JDK (in case somebody would build 32bit OpenJDK) would contain 32bit Java runtime regardless on 64bit or 32bit Windows it will be executed. I'd use `sun.arch.data.model` instead of `os.arch`

Done.

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

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

From almatvee at openjdk.java.net  Wed Jan 13 16:51:17 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Wed, 13 Jan 2021 16:51:17 GMT
Subject: RFR: JDK-8258755: jpackage: Invalid 32-bit exe when building
 app-image
In-Reply-To: <s7PJA74O7GtTqPkaLzHQ033a9vlKG2ZfX6HCdgKmNZQ=.6cda02fc-bd7d-4d2b-ab1b-b3d7c5641b05@github.com>
References: <s7PJA74O7GtTqPkaLzHQ033a9vlKG2ZfX6HCdgKmNZQ=.6cda02fc-bd7d-4d2b-ab1b-b3d7c5641b05@github.com>
Message-ID: <eVjjndxz32ATuDpM22V44k2BsIM7LRT8HL2WexeLW7c=.188ff483-7f33-4e80-91d9-21af2b448fdd@github.com>

On Mon, 11 Jan 2021 17:42:21 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8258755: jpackage: Invalid 32-bit exe when building app-image

src/jdk.jpackage/share/native/applauncher/JvmLauncher.cpp line 37:

> 35: 
> 36: #if defined(_WIN32) && !defined(_WIN64)
> 37: #define LAUNCH_FUNC "_JLI_Launch at 56"

Why JLI_Launch does not work for 32-bit? Do you know why @56 is being used?

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

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

From herrick at openjdk.java.net  Wed Jan 13 16:51:18 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 13 Jan 2021 16:51:18 GMT
Subject: RFR: JDK-8258755: jpackage: Invalid 32-bit exe when building
 app-image
In-Reply-To: <eVjjndxz32ATuDpM22V44k2BsIM7LRT8HL2WexeLW7c=.188ff483-7f33-4e80-91d9-21af2b448fdd@github.com>
References: <s7PJA74O7GtTqPkaLzHQ033a9vlKG2ZfX6HCdgKmNZQ=.6cda02fc-bd7d-4d2b-ab1b-b3d7c5641b05@github.com>
 <eVjjndxz32ATuDpM22V44k2BsIM7LRT8HL2WexeLW7c=.188ff483-7f33-4e80-91d9-21af2b448fdd@github.com>
Message-ID: <50lSKcF2xyD_GIMp2W5EE33SWfDNQZEpT7wKMMfIphI=.7ef21e56-c8ae-4123-8bd1-138611b4a91d@github.com>

On Tue, 12 Jan 2021 22:38:38 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> JDK-8258755: jpackage: Invalid 32-bit exe when building app-image
>
> src/jdk.jpackage/share/native/applauncher/JvmLauncher.cpp line 37:
> 
>> 35: 
>> 36: #if defined(_WIN32) && !defined(_WIN64)
>> 37: #define LAUNCH_FUNC "_JLI_Launch at 56"
> 
> Why JLI_Launch does not work for 32-bit? Do you know why @56 is being used?

not so much that is doesn't work, but that it doesn't exist,
The 32 bit version of jli.dll does not have a "JLI_LAUNCH" entry point, but does have a "_JLI_Launch at 56" which works perfectly well.

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

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

From asemenyuk at openjdk.java.net  Wed Jan 13 16:51:19 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 13 Jan 2021 16:51:19 GMT
Subject: RFR: JDK-8258755: jpackage: Invalid 32-bit exe when building
 app-image
In-Reply-To: <_vPbBn7SHTG2l1Jv9TSeC2Fm00furNuODerHQURKhLA=.e2f64fd7-205a-497e-abd7-ffa2369591d2@github.com>
References: <s7PJA74O7GtTqPkaLzHQ033a9vlKG2ZfX6HCdgKmNZQ=.6cda02fc-bd7d-4d2b-ab1b-b3d7c5641b05@github.com>
 <_vPbBn7SHTG2l1Jv9TSeC2Fm00furNuODerHQURKhLA=.e2f64fd7-205a-497e-abd7-ffa2369591d2@github.com>
Message-ID: <aSS18j-3qwuTEmV9eOpz_vpuB4FjMBFrZ55gbLxgYcU=.f9d479fd-eb29-4050-9872-b5a7ec6b194e@github.com>

On Wed, 13 Jan 2021 01:32:51 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> JDK-8258755: jpackage: Invalid 32-bit exe when building app-image
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Platform.java line 127:
> 
>> 125:         return is64b;
>> 126:     }
>> 127: 
> 
> This is Windows specific thing. There is no point to keep it in shared code. I'd suggest to move this function in WixSourcesBuilder class.
> 
> I think it is not correct to check for arch of the OS where jpackage runs. Jpackage from 32bit JDK (if somebody would build 32bit OpenJDK) would bake in 32bit Java runtime in app image regardless Windows is 64bit or 32bit. So the arch of installer is determined by arch of Java runtime baked in the app image. For simplicity we can assume that arch of Java runtime is the same as the arch of jpackage (this might not be the case for external Java runtime case though, but let's leave this possibility aside as it is not supported anyways). If so, checking of `sun.arch.data.model` system property would be better alternative to `os.arch`.

Sorry, I left this comment earlier, but it was lost.

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

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

From herrick at openjdk.java.net  Wed Jan 13 16:51:19 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 13 Jan 2021 16:51:19 GMT
Subject: RFR: JDK-8258755: jpackage: Invalid 32-bit exe when building
 app-image
In-Reply-To: <aSS18j-3qwuTEmV9eOpz_vpuB4FjMBFrZ55gbLxgYcU=.f9d479fd-eb29-4050-9872-b5a7ec6b194e@github.com>
References: <s7PJA74O7GtTqPkaLzHQ033a9vlKG2ZfX6HCdgKmNZQ=.6cda02fc-bd7d-4d2b-ab1b-b3d7c5641b05@github.com>
 <_vPbBn7SHTG2l1Jv9TSeC2Fm00furNuODerHQURKhLA=.e2f64fd7-205a-497e-abd7-ffa2369591d2@github.com>
 <aSS18j-3qwuTEmV9eOpz_vpuB4FjMBFrZ55gbLxgYcU=.f9d479fd-eb29-4050-9872-b5a7ec6b194e@github.com>
Message-ID: <bGLi5zGpQSMEABoPvLv5eEGBL1EGl2MpazsMuXfqO2A=.52bfbc4d-be82-45d4-b03f-7736c2f66880@github.com>

On Wed, 13 Jan 2021 01:37:40 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Platform.java line 127:
>> 
>>> 125:         return is64b;
>>> 126:     }
>>> 127: 
>> 
>> This is Windows specific thing. There is no point to keep it in shared code. I'd suggest to move this function in WixSourcesBuilder class.
>> 
>> I think it is not correct to check for arch of the OS where jpackage runs. Jpackage from 32bit JDK (if somebody would build 32bit OpenJDK) would bake in 32bit Java runtime in app image regardless Windows is 64bit or 32bit. So the arch of installer is determined by arch of Java runtime baked in the app image. For simplicity we can assume that arch of Java runtime is the same as the arch of jpackage (this might not be the case for external Java runtime case though, but let's leave this possibility aside as it is not supported anyways). If so, checking of `sun.arch.data.model` system property would be better alternative to `os.arch`.
>
> Sorry, I left this comment earlier, but it was lost.

I agree is better to have the check in windows specific code (not Platform) and will move it.
The "os.arch" System property in 32  java is "x86" regardless of whether running on 64 or 32 bit version of Windows, It reflects the arch of the running JVM (not the arch of the os as the name implies), so checking if system property "os.arch" is "x86" is the same as checking if "sun,arch.data.model" is "32".  Since "os.arch" is the more documented property I think we should continue to use that.

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

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

From herrick at openjdk.java.net  Wed Jan 13 16:51:19 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 13 Jan 2021 16:51:19 GMT
Subject: RFR: JDK-8258755: jpackage: Invalid 32-bit exe when building
 app-image
In-Reply-To: <bGLi5zGpQSMEABoPvLv5eEGBL1EGl2MpazsMuXfqO2A=.52bfbc4d-be82-45d4-b03f-7736c2f66880@github.com>
References: <s7PJA74O7GtTqPkaLzHQ033a9vlKG2ZfX6HCdgKmNZQ=.6cda02fc-bd7d-4d2b-ab1b-b3d7c5641b05@github.com>
 <_vPbBn7SHTG2l1Jv9TSeC2Fm00furNuODerHQURKhLA=.e2f64fd7-205a-497e-abd7-ffa2369591d2@github.com>
 <aSS18j-3qwuTEmV9eOpz_vpuB4FjMBFrZ55gbLxgYcU=.f9d479fd-eb29-4050-9872-b5a7ec6b194e@github.com>
 <bGLi5zGpQSMEABoPvLv5eEGBL1EGl2MpazsMuXfqO2A=.52bfbc4d-be82-45d4-b03f-7736c2f66880@github.com>
Message-ID: <gFB8XGMDyefj7KS9UoNfe-1wpQWwQpjJaD1bBWCptj0=.d3153d84-024c-4fef-93fb-e1716a6bc7dd@github.com>

On Wed, 13 Jan 2021 13:11:12 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> Sorry, I left this comment earlier, but it was lost.
>
> I agree is better to have the check in windows specific code (not Platform) and will move it.
> The "os.arch" System property in 32  java is "x86" regardless of whether running on 64 or 32 bit version of Windows, It reflects the arch of the running JVM (not the arch of the os as the name implies), so checking if system property "os.arch" is "x86" is the same as checking if "sun,arch.data.model" is "32".  Since "os.arch" is the more documented property I think we should continue to use that.

(note:) I do build 32 bit java on windows to test this, I can "make CONF=windows-x86 images", but building installers is not supported and currently building test has problems in hotspot.

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

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

From herrick at openjdk.java.net  Wed Jan 13 16:52:10 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 13 Jan 2021 16:52:10 GMT
Subject: RFR:     JDK-8259062: Remove MacAppStoreBundler
Message-ID: <iAhpVYi8-wmDzRrnQjaUnPuFWuRI1NSwrlqi0LQVrPk=.f97b81e8-d7c9-4c09-9589-682c2c0afa1c@github.com>

JDK-8259062: Remove MacAppStoreBundler

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

Commit messages:
 - JDK-8259062: Remove MacAppStoreBundler
 -     JDK-8259062: Remove MacAppStoreBundler

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

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

From asemenyuk at openjdk.java.net  Wed Jan 13 16:52:11 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 13 Jan 2021 16:52:11 GMT
Subject: RFR:     JDK-8259062: Remove MacAppStoreBundler
In-Reply-To: <iAhpVYi8-wmDzRrnQjaUnPuFWuRI1NSwrlqi0LQVrPk=.f97b81e8-d7c9-4c09-9589-682c2c0afa1c@github.com>
References: <iAhpVYi8-wmDzRrnQjaUnPuFWuRI1NSwrlqi0LQVrPk=.f97b81e8-d7c9-4c09-9589-682c2c0afa1c@github.com>
Message-ID: <IZs35WRLZGuktDakLKS6I9KWNuzIMMi4qtKe6cv2jFU=.204d61f5-5d06-44e7-b5b9-7c0c9b3a5401@github.com>

On Wed, 6 Jan 2021 15:52:07 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8259062: Remove MacAppStoreBundler

Marked as reviewed by asemenyuk (Committer).

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

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

From herrick at openjdk.java.net  Wed Jan 13 16:52:16 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 13 Jan 2021 16:52:16 GMT
Subject: RFR: JDK-8259238: Clean up Log.java and remove usage of non-final
 static variables.
Message-ID: <gBD8pSjYTSaDX-I-1shActJPeKRSQlGkbmcuDydyqmY=.8e901e78-b133-48bb-8987-c0c77b99e77c@github.com>

JDK-8259238: Clean up Log.java and remove usage of non-final static variables.

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

Commit messages:
 - JDK-8259238: Clean up Log.java and remove usage of non-final static variables.

Changes: https://git.openjdk.java.net/jdk/pull/1977/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1977&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259238
  Stats: 79 lines in 3 files changed: 12 ins; 49 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1977.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1977/head:pull/1977

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

From asemenyuk at openjdk.java.net  Wed Jan 13 16:52:16 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 13 Jan 2021 16:52:16 GMT
Subject: RFR: JDK-8259238: Clean up Log.java and remove usage of non-final
 static variables.
In-Reply-To: <gBD8pSjYTSaDX-I-1shActJPeKRSQlGkbmcuDydyqmY=.8e901e78-b133-48bb-8987-c0c77b99e77c@github.com>
References: <gBD8pSjYTSaDX-I-1shActJPeKRSQlGkbmcuDydyqmY=.8e901e78-b133-48bb-8987-c0c77b99e77c@github.com>
Message-ID: <SNe0ryjSCseu4__4_2Vkg097k0TIMT3T2Pu3AOr9S7Q=.fb8e3e4c-d5ef-4b81-af6e-c098b21b424a@github.com>

On Thu, 7 Jan 2021 16:40:26 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8259238: Clean up Log.java and remove usage of non-final static variables.

Marked as reviewed by asemenyuk (Committer).

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

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

From almatvee at openjdk.java.net  Wed Jan 13 16:52:11 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Wed, 13 Jan 2021 16:52:11 GMT
Subject: RFR:     JDK-8259062: Remove MacAppStoreBundler
In-Reply-To: <iAhpVYi8-wmDzRrnQjaUnPuFWuRI1NSwrlqi0LQVrPk=.f97b81e8-d7c9-4c09-9589-682c2c0afa1c@github.com>
References: <iAhpVYi8-wmDzRrnQjaUnPuFWuRI1NSwrlqi0LQVrPk=.f97b81e8-d7c9-4c09-9589-682c2c0afa1c@github.com>
Message-ID: <qGXwnRZRDmP8tXMn3vDLt73s549EA8sRrOdulBnNbik=.6344b209-2ab7-40bb-8c2a-ddb11a0da8a9@github.com>

On Wed, 6 Jan 2021 15:52:07 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8259062: Remove MacAppStoreBundler

Marked as reviewed by almatvee (Committer).

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

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

From almatvee at openjdk.java.net  Wed Jan 13 16:52:17 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Wed, 13 Jan 2021 16:52:17 GMT
Subject: RFR: JDK-8259238: Clean up Log.java and remove usage of non-final
 static variables.
In-Reply-To: <gBD8pSjYTSaDX-I-1shActJPeKRSQlGkbmcuDydyqmY=.8e901e78-b133-48bb-8987-c0c77b99e77c@github.com>
References: <gBD8pSjYTSaDX-I-1shActJPeKRSQlGkbmcuDydyqmY=.8e901e78-b133-48bb-8987-c0c77b99e77c@github.com>
Message-ID: <WxzrOgPhVMKM2_NO4NFaHJpWBA7GlALmOAVXyRP3S2w=.acba8274-73ad-44e7-a81b-e3932a21531b@github.com>

On Thu, 7 Jan 2021 16:40:26 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8259238: Clean up Log.java and remove usage of non-final static variables.

Marked as reviewed by almatvee (Committer).

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

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

From asemenyuk at openjdk.java.net  Wed Jan 13 17:10:04 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 13 Jan 2021 17:10:04 GMT
Subject: RFR: JDK-8258755: jpackage: Invalid 32-bit exe when building
 app-image
In-Reply-To: <s7PJA74O7GtTqPkaLzHQ033a9vlKG2ZfX6HCdgKmNZQ=.6cda02fc-bd7d-4d2b-ab1b-b3d7c5641b05@github.com>
References: <s7PJA74O7GtTqPkaLzHQ033a9vlKG2ZfX6HCdgKmNZQ=.6cda02fc-bd7d-4d2b-ab1b-b3d7c5641b05@github.com>
Message-ID: <Sex4l1qxxkS5g9Wg0Z-8THz6vNqWEnuc0yZaBj08Zdg=.0d0253a2-eeb3-4a88-8183-db5050f0f9e1@github.com>

On Mon, 11 Jan 2021 17:42:21 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8258755: jpackage: Invalid 32-bit exe when building app-image

Marked as reviewed by asemenyuk (Committer).

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

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

From asemenyuk at openjdk.java.net  Wed Jan 13 17:10:05 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 13 Jan 2021 17:10:05 GMT
Subject: RFR: JDK-8258755: jpackage: Invalid 32-bit exe when building
 app-image
In-Reply-To: <gFB8XGMDyefj7KS9UoNfe-1wpQWwQpjJaD1bBWCptj0=.d3153d84-024c-4fef-93fb-e1716a6bc7dd@github.com>
References: <s7PJA74O7GtTqPkaLzHQ033a9vlKG2ZfX6HCdgKmNZQ=.6cda02fc-bd7d-4d2b-ab1b-b3d7c5641b05@github.com>
 <_vPbBn7SHTG2l1Jv9TSeC2Fm00furNuODerHQURKhLA=.e2f64fd7-205a-497e-abd7-ffa2369591d2@github.com>
 <aSS18j-3qwuTEmV9eOpz_vpuB4FjMBFrZ55gbLxgYcU=.f9d479fd-eb29-4050-9872-b5a7ec6b194e@github.com>
 <bGLi5zGpQSMEABoPvLv5eEGBL1EGl2MpazsMuXfqO2A=.52bfbc4d-be82-45d4-b03f-7736c2f66880@github.com>
 <gFB8XGMDyefj7KS9UoNfe-1wpQWwQpjJaD1bBWCptj0=.d3153d84-024c-4fef-93fb-e1716a6bc7dd@github.com>
Message-ID: <TWm77exumi5gnAKSSYuufAG15B31ZO_eXFNLPd-rS7I=.e2760a46-995c-44f8-9a5e-84db438cb447@github.com>

On Wed, 13 Jan 2021 13:14:17 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> I agree is better to have the check in windows specific code (not Platform) and will move it.
>> The "os.arch" System property in 32  java is "x86" regardless of whether running on 64 or 32 bit version of Windows, It reflects the arch of the running JVM (not the arch of the os as the name implies), so checking if system property "os.arch" is "x86" is the same as checking if "sun,arch.data.model" is "32".  Since "os.arch" is the more documented property I think we should continue to use that.
>
> (note:) I do build 32 bit java on windows to test this, I can "make CONF=windows-x86 images", but building installers is not supported and currently building test has problems in hotspot.

Agree on `os.arch`

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

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

From naoto at openjdk.java.net  Wed Jan 13 18:46:17 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 13 Jan 2021 18:46:17 GMT
Subject: RFR: 8258956: Memory Leak in StringCoding on ThreadLocal resultCached
 StringCoding.Result
Message-ID: <-8rLEVPm5yxiYqeirzdzGg2zHEwYtdma1ZWtYrDT7mA=.17c85478-b25e-46b9-b672-a8b9b791e640@github.com>

Please review the fix to this issue. Unused thread local StringCoding.Result is now wrapped with SoftReference, which can be GC'ed as needed. I confirmed it worked as expected with a test case (https://github.com/openjdk/jdk/blob/8b4e1e1cf8f5d753ed901406f73d67b21557fddb/test/jdk/java/lang/StringCoding/ResultCachedGCTest.java), but decided not to include it in this PR. This is because I purposefully chose the size of the byte array and max heap size which is fragile, and could become noise in a regression test run.

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

Commit messages:
 - Removed the test case.
 - 8258956: Memory Leak in StringCoding on ThreadLocal resultCached StringCoding.Result

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

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

From daniel.fuchs at oracle.com  Wed Jan 13 19:11:16 2021
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 13 Jan 2021 19:11:16 +0000
Subject: Difference in encoding semantics of URI returned by File.toURI
 and Path.toUri representing the same file
In-Reply-To: <9B159D6D-8AF4-414C-A86A-ACFD34D67288@gmail.com>
References: <3cd8d31d-1640-a855-4ba2-bf05be8adfe0@gmail.com>
 <08edf854-6414-800f-4fa4-2f06d234e6a6@oracle.com>
 <9B159D6D-8AF4-414C-A86A-ACFD34D67288@gmail.com>
Message-ID: <970649d3-c121-d965-30c1-f09d8755c572@oracle.com>

Hi Sebastian,

On 13/01/2021 18:45, Sebastian Stenzel wrote:
>> [...]
>> It's not clear to me whether NFC should be applied - or what would be
>> the consequences of applying NFC there (or not).
> 
> While I can't answer this question, it may be worth mentioning RFC 3987 which might not be directly applicable but also deals with the representation of non-ASCII data in URIs.
> 
> In section 3 it explicitly asks for NFC-normalization_before_  applying percent-encoding. I can't tell what's the rationale behind this decision but possibly the behaviour of URI.toASCIIString() is in the spirit of these rules.

Yes - I believe URI does the right thing.

I was however musing about changing the behavior of Path.toURI() in
that respect, and whether using NFC or not in Path.toURI() could
potentially prevent Path.of(URI) to find back the same file on the
file system.

best regards,

-- daniel

From darcy at openjdk.java.net  Wed Jan 13 20:00:26 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 13 Jan 2021 20:00:26 GMT
Subject: RFR: JDK-8257086: Clarify differences between {Float,
 Double}.equals and == [v2]
In-Reply-To: <sxbxBYIClZ26dmLvW8fUbnNPybVl_k16wHbBPEDx40o=.86762561-b05f-4814-a57b-e5fc02f58d8f@github.com>
References: <sxbxBYIClZ26dmLvW8fUbnNPybVl_k16wHbBPEDx40o=.86762561-b05f-4814-a57b-e5fc02f58d8f@github.com>
Message-ID: <PpwVvdsr6y1t1zIjS5GkNIyJtffMKpcmwV2WHOUUW-s=.4d049617-96f5-4b0b-967e-b7fd740e1b07@github.com>

> Updates to the specifications of Double.{equals, compareTo} to explain more explicitly why the obvious wrappers around "==" and "<"/"==" are not sufficient for floating-point values.
> 
> Once the wording is worked out, I'll replicate it for the analogous methods on Float.

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 three additional commits since the last revision:

 - Merge branch 'master' into JDK-8257086
 - Fix whitespace
 - Initial work for JDK-8257086.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1699/files
  - new: https://git.openjdk.java.net/jdk/pull/1699/files/15ce6ad8..308b387d

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

  Stats: 77436 lines in 2286 files changed: 42945 ins; 17938 del; 16553 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1699/head:pull/1699

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

From rriggs at openjdk.java.net  Wed Jan 13 21:00:02 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 13 Jan 2021 21:00:02 GMT
Subject: RFR: 8258956: Memory Leak in StringCoding on ThreadLocal
 resultCached StringCoding.Result
In-Reply-To: <-8rLEVPm5yxiYqeirzdzGg2zHEwYtdma1ZWtYrDT7mA=.17c85478-b25e-46b9-b672-a8b9b791e640@github.com>
References: <-8rLEVPm5yxiYqeirzdzGg2zHEwYtdma1ZWtYrDT7mA=.17c85478-b25e-46b9-b672-a8b9b791e640@github.com>
Message-ID: <kRArt_jH4WUS2IHzxYFZ08UYlZdtAMtIU1ZslgKF-yE=.4f07ee73-8b3a-4232-8d24-37199a082701@github.com>

On Wed, 13 Jan 2021 18:41:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to this issue. Unused thread local StringCoding.Result is now wrapped with SoftReference, which can be GC'ed as needed. I confirmed it worked as expected with a test case (https://github.com/openjdk/jdk/blob/8b4e1e1cf8f5d753ed901406f73d67b21557fddb/test/jdk/java/lang/StringCoding/ResultCachedGCTest.java), but decided not to include it in this PR. This is because I purposefully chose the size of the byte array and max heap size which is fragile, and could become noise in a regression test run.

Marked as reviewed by rriggs (Reviewer).

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

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

From stuart.marks at oracle.com  Wed Jan 13 21:52:46 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 13 Jan 2021 13:52:46 -0800
Subject: TreeMap in JDK15 deviates from spec
In-Reply-To: <CAPRgzFrk5uGzVEJBo+R_BLf_dyUPfPbY0g4j+WKUUQyjYvKmTw@mail.gmail.com>
References: <CAPRgzFrk5uGzVEJBo+R_BLf_dyUPfPbY0g4j+WKUUQyjYvKmTw@mail.gmail.com>
Message-ID: <66bd3dc5-190c-5e9f-7afd-7596e56da98a@oracle.com>

Thanks for filing this!

Tagir Valeev picked this up and has filed a PR:

https://git.openjdk.java.net/jdk/pull/2058

s'marks


On 1/11/21 10:05 AM, Phil Smith wrote:
> Hello, I submitted bug report 9068554 recently, but I consider this a
> pretty big issue and I'd like for this not to get lost in triage.
> 
> With JDK-8176894, a specialized implementation for computeIfAbsent was
> added to TreeMap, however it doesn't handle null values correctly.
> Spec states a mapping to null is equivalent to no mapping being
> present, however code will `return t.value;` without checking that
> value. The interface default, for reference, looks like `if ((v =
> get(key)) == null)`.
> 
> A simple repro follows
> 
> TreeMap treemap = new TreeMap();
> treemap.put("a", null);
> System.out.println(treemap.computeIfAbsent("a", key -> "default"));
> System.out.println(treemap.get("a"));
> 
> HashMap hashmap = new HashMap();
> hashmap.put("a", null);
> System.out.println(hashmap.computeIfAbsent("a", key -> "default"));
> System.out.println(hashmap.get("a"));
> 
> Phil
> 

From jwilhelm at openjdk.java.net  Thu Jan 14 01:25:23 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 14 Jan 2021 01:25:23 GMT
Subject: RFR: Merge jdk16
Message-ID: <-aqBh7X3owjZhc7NJ9IadTg_pDoBEcSVULP6D9ZQlwc=.2f9552f6-95ee-4bdd-8591-e2fea0f2ee47@github.com>

Forwardport JDK 16 -> JDK 17

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

Commit messages:
 - Merge
 - 8259719: ProblemList runtime/cds/appcds/jigsaw/modulepath/ModulePathAndCP_JFR.java on Windows
 - 8259720: ProblemList java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java on Windows
 - 8259722: ProblemList two jdk/jfr/startupargs tests on Windows
 - 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference
 - 8259063: Possible deadlock with vtable/itable creation vs concurrent class unloading
 - 8259657: typo in generated HELP page prevents localization
 - 8258272: LoadVectorMaskedNode can't be replaced by zero con
 - 8259560: Zero m68k: "static assertion failed: align" after JDK-8252049
 - 8258985: Parallel WeakProcessor may use too few threads
 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/c7e2174b...64cae854

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2072&range=00.0
 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2072&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/2072/files
  Stats: 991 lines in 48 files changed: 764 ins; 123 del; 104 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2072.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2072/head:pull/2072

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

From jwilhelm at openjdk.java.net  Thu Jan 14 01:33:06 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 14 Jan 2021 01:33:06 GMT
Subject: Integrated: Merge jdk16
In-Reply-To: <-aqBh7X3owjZhc7NJ9IadTg_pDoBEcSVULP6D9ZQlwc=.2f9552f6-95ee-4bdd-8591-e2fea0f2ee47@github.com>
References: <-aqBh7X3owjZhc7NJ9IadTg_pDoBEcSVULP6D9ZQlwc=.2f9552f6-95ee-4bdd-8591-e2fea0f2ee47@github.com>
Message-ID: <p82dsXEA151UnNYF39BzaZih5zQ83U7-B3lppnrTHfk=.6a1b52e8-1a0c-4956-819f-99c79172a356@github.com>

On Thu, 14 Jan 2021 01:20:13 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: 51e14f2e
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/51e14f2e
Stats:     991 lines in 48 files changed: 764 ins; 123 del; 104 mod

Merge

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

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

From almatvee at openjdk.java.net  Thu Jan 14 01:49:03 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 14 Jan 2021 01:49:03 GMT
Subject: RFR: JDK-8258755: jpackage: Invalid 32-bit exe when building
 app-image
In-Reply-To: <s7PJA74O7GtTqPkaLzHQ033a9vlKG2ZfX6HCdgKmNZQ=.6cda02fc-bd7d-4d2b-ab1b-b3d7c5641b05@github.com>
References: <s7PJA74O7GtTqPkaLzHQ033a9vlKG2ZfX6HCdgKmNZQ=.6cda02fc-bd7d-4d2b-ab1b-b3d7c5641b05@github.com>
Message-ID: <iA3lhtSjLo9MI5VrSf9RcV7w-yL_n1C0gQTB5vuKrww=.ca658eef-720d-48ae-a99a-24423d4adea5@github.com>

On Mon, 11 Jan 2021 17:42:21 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8258755: jpackage: Invalid 32-bit exe when building app-image

Marked as reviewed by almatvee (Committer).

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

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

From jnimeh at openjdk.java.net  Thu Jan 14 06:38:15 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 14 Jan 2021 06:38:15 GMT
Subject: RFR: 8253866: Security Libs Terminology Refresh
Message-ID: <em1vZcNQK0XBFktbyJQoH-McK_Scddtv2VyzVSaqbWw=.ddfc9733-b5fd-4905-ac1d-6ec18a6ce94d@github.com>

This is the security libs portion of the effort to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).

Here are the changes covering core libraries code and tests. Terms were changed as follows:

- blacklisted.certs -> blocked.certs (along with supporting make infrastructure and tests)
- master/slave in KRB5 -> primary/replica
- blacklist in other files -> deny list
- whitelist -> allow list

Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources.

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

Commit messages:
 - Merge main branch
 - 8253866: Security Libs Terminology Refresh

Changes: https://git.openjdk.java.net/jdk/pull/2074/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2074&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253866
  Stats: 351 lines in 17 files changed: 152 ins; 150 del; 49 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2074.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2074/head:pull/2074

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

From alanb at openjdk.java.net  Thu Jan 14 08:49:04 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 14 Jan 2021 08:49:04 GMT
Subject: RFR: 8258956: Memory Leak in StringCoding on ThreadLocal
 resultCached StringCoding.Result
In-Reply-To: <-8rLEVPm5yxiYqeirzdzGg2zHEwYtdma1ZWtYrDT7mA=.17c85478-b25e-46b9-b672-a8b9b791e640@github.com>
References: <-8rLEVPm5yxiYqeirzdzGg2zHEwYtdma1ZWtYrDT7mA=.17c85478-b25e-46b9-b672-a8b9b791e640@github.com>
Message-ID: <8_gYVVly8Pr3BYQdHXIDa0CKuu5Jrmx9ysjs5tTrt2g=.31620053-0e93-46bf-9f76-4e317c24da20@github.com>

On Wed, 13 Jan 2021 18:41:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to this issue. Unused thread local StringCoding.Result is now wrapped with SoftReference, which can be GC'ed as needed. I confirmed it worked as expected with a test case (https://github.com/openjdk/jdk/blob/8b4e1e1cf8f5d753ed901406f73d67b21557fddb/test/jdk/java/lang/StringCoding/ResultCachedGCTest.java), but decided not to include it in this PR. This is because I purposefully chose the size of the byte array and max heap size which is fragile, and could become noise in a regression test run.

Marked as reviewed by alanb (Reviewer).

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jan 14 09:57: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, 14 Jan 2021 09:57:24 GMT
Subject: RFR: 8193031: Collections.addAll is likely to perform worse than
 Collection.addAll [v6]
In-Reply-To: <TB3epXzVEKg86PLsoPvHgfKAC2XHrLGCH2ZsuCJw2h4=.c75b4032-abb7-4f95-b19e-65788727f049@github.com>
References: <TB3epXzVEKg86PLsoPvHgfKAC2XHrLGCH2ZsuCJw2h4=.c75b4032-abb7-4f95-b19e-65788727f049@github.com>
Message-ID: <0WzQeLtUpGgJedBUpx8hwXUxPPqwhNTSQ3GCW0wOLkM=.bb0c55ed-c3f2-4c35-84f8-87ee00f0c93b@github.com>

> Hello, I feel like this was previously discussed in https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot find original mail I post this here.
> 
> Currently `Collections.addAll()` is implemented and documented as:
>     /**
>      * ...
>      * The behavior of this convenience method is identical to that of
>      * {@code c.addAll(Arrays.asList(elements))}, but this method is likely
>      * to run significantly faster under most implementations.
>      */
>     @SafeVarargs
>     public static <T> boolean addAll(Collection<? super T> c, T... elements) {
>         boolean result = false;
>         for (T element : elements)
>             result |= c.add(element);
>         return result;
>     }
> 
> But it practice the notation `this method is likely to run significantly faster under most implementations` is completely wrong. When I take this [benchmark](https://github.com/stsypanov/benchmarks/blob/master/benchmark-runners/src/main/java/com/luxoft/logeek/benchmark/collection/CollectionsAddAllVsAddAllBenchmark.java) and run it on JDK 14 I get the following results:
>                                                    (collection)  (size)      Score     Error   Units
> addAll                                                ArrayList      10       37.9 ?     1.9   ns/op
> addAll                                                ArrayList     100       83.8 ?     3.4   ns/op
> addAll                                                ArrayList    1000      678.2 ?    23.0   ns/op
> collectionsAddAll                                     ArrayList      10       50.9 ?     1.1   ns/op
> collectionsAddAll                                     ArrayList     100      751.4 ?    47.4   ns/op
> collectionsAddAll                                     ArrayList    1000     8839.8 ?   710.7   ns/op
> 
> addAll                                                  HashSet      10      128.4 ?     5.9   ns/op
> addAll                                                  HashSet     100     1864.2 ?   102.4   ns/op
> addAll                                                  HashSet    1000    16615.5 ?  1202.6   ns/op
> collectionsAddAll                                       HashSet      10      172.8 ?     6.0   ns/op
> collectionsAddAll                                       HashSet     100     2355.8 ?   195.4   ns/op
> collectionsAddAll                                       HashSet    1000    20364.7 ?  1164.0   ns/op
> 
> addAll                                               ArrayDeque      10       54.0 ?     0.4   ns/op
> addAll                                               ArrayDeque     100      319.7 ?     2.5   ns/op
> addAll                                               ArrayDeque    1000     3176.9 ?    22.2   ns/op
> collectionsAddAll                                    ArrayDeque      10       66.5 ?     1.4   ns/op
> collectionsAddAll                                    ArrayDeque     100      808.1 ?    55.9   ns/op
> collectionsAddAll                                    ArrayDeque    1000     5639.6 ?   240.9   ns/op
> 
> addAll                                     CopyOnWriteArrayList      10       18.0 ?     0.7   ns/op
> addAll                                     CopyOnWriteArrayList     100       39.4 ?     1.7   ns/op
> addAll                                     CopyOnWriteArrayList    1000      371.1 ?    17.0   ns/op
> collectionsAddAll                          CopyOnWriteArrayList      10      251.9 ?    18.4   ns/op
> collectionsAddAll                          CopyOnWriteArrayList     100     3405.9 ?   304.8   ns/op
> collectionsAddAll                          CopyOnWriteArrayList    1000   247496.8 ? 23502.3   ns/op
> 
> addAll                                    ConcurrentLinkedDeque      10       81.4 ?     2.8   ns/op
> addAll                                    ConcurrentLinkedDeque     100      609.1 ?    26.4   ns/op
> addAll                                    ConcurrentLinkedDeque    1000     4494.5 ?   219.3   ns/op
> collectionsAddAll                         ConcurrentLinkedDeque      10      189.8 ?     2.5   ns/op
> collectionsAddAll                         ConcurrentLinkedDeque     100     1660.0 ?    62.0   ns/op
> collectionsAddAll                         ConcurrentLinkedDeque    1000    17649.2 ?   300.9   ns/op
> 
> addAll:?gc.alloc.rate.norm                            ArrayList      10      160.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                            ArrayList     100      880.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                            ArrayList    1000     8080.3 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                 ArrayList      10       80.0 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                 ArrayList     100     1400.2 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                 ArrayList    1000    15025.6 ?     0.1    B/op
> 
> addAll:?gc.alloc.rate.norm                              HashSet      10      464.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                              HashSet     100     5328.5 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                              HashSet    1000    48516.7 ?     0.1    B/op
> collectionsAddAll:?gc.alloc.rate.norm                   HashSet      10      464.0 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                   HashSet     100     5328.5 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                   HashSet    1000    48516.6 ?     0.1    B/op
> 
> addAll:?gc.alloc.rate.norm                           ArrayDeque      10      112.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                           ArrayDeque     100      560.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                           ArrayDeque    1000     4160.5 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                ArrayDeque      10      112.0 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                ArrayDeque     100     1048.1 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                ArrayDeque    1000    14929.4 ?     0.0    B/op
> 
> addAll:?gc.alloc.rate.norm                 CopyOnWriteArrayList      10       88.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                 CopyOnWriteArrayList     100      448.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                 CopyOnWriteArrayList    1000     4048.1 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm      CopyOnWriteArrayList      10      456.0 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm      CopyOnWriteArrayList     100    22057.2 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm      CopyOnWriteArrayList    1000  2020150.3 ?     7.3    B/op
> 
> addAll:?gc.alloc.rate.norm                ConcurrentLinkedDeque      10      312.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                ConcurrentLinkedDeque     100     2472.1 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                ConcurrentLinkedDeque    1000    24073.7 ?     0.1    B/op
> collectionsAddAll:?gc.alloc.rate.norm     ConcurrentLinkedDeque      10      288.0 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm     ConcurrentLinkedDeque     100     2448.3 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm     ConcurrentLinkedDeque    1000    24051.4 ?     0.3    B/op
> There's never a case when `Collections.addAll` is fater - on the contrary `c.addAll(Arrays.asList())` always wins. Pay attention especially to dramatic difference for array-based collection.
> 
> So I propose to reimplement the method by simply delegating to `Arrays.asList` because the spec declares identical behaviour and to remove perfomance notation from JavaDoc.

?????? ??????? 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:

 - 8193031: fix JavaDoc
 - Merge branch 'master' into add-all
 - Merge branch 'master' into add-all
 - 8193031: revert implementation change but keep one for JavaDoc
 - Merge branch 'master' into add-all
 - Merge remote-tracking branch 'origin/add-all' into add-all
 - 8193031: add elements in bulk in Collections.addAll()
 - Merge branch 'master' into add-all
 - 8193031: add elements in bulk in Collections.addAll()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1764/files
  - new: https://git.openjdk.java.net/jdk/pull/1764/files/9d6dcf3d..096c5dee

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

  Stats: 38545 lines in 1376 files changed: 14075 ins; 12033 del; 12437 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1764.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1764/head:pull/1764

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jan 14 09:57: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, 14 Jan 2021 09:57:24 GMT
Subject: RFR: 8193031: Collections.addAll is likely to perform worse than
 Collection.addAll
In-Reply-To: <uXM0w30njrZNn9c68Sn_jjcAnJZGZWZXzoA0wRJcwRM=.6d6408b3-8d28-4272-8bdf-921b9d1ae971@github.com>
References: <TB3epXzVEKg86PLsoPvHgfKAC2XHrLGCH2ZsuCJw2h4=.c75b4032-abb7-4f95-b19e-65788727f049@github.com>
 <X4vHouF0uVTx1XTeRjmqZ0ldcYtqP-Zkf1ujMzvRbtM=.633d7310-3d0b-4296-95ba-7b6829482b43@github.com>
 <HGsYr1kNCPjCwV5bnXUUsSvxHd15C3G99FulbSkpFYE=.18613967-548c-488e-8d12-1e40bcfffa72@github.com>
 <47B7kkUUmzlTIJLb14nPTXYckKtrXTREVZLU2iilSGU=.b1c05f13-aea1-4d90-bc2b-37d2ab6280dd@github.com>
 <MMgyNFF6k3ovq--q8ZWNOUhVxKhs46sTCVYe1ucrYXo=.887bfa14-1c3e-4fc8-86e3-d5a8442277ff@github.com>
 <uXM0w30njrZNn9c68Sn_jjcAnJZGZWZXzoA0wRJcwRM=.6d6408b3-8d28-4272-8bdf-921b9d1ae971@github.com>
Message-ID: <LuTaBYWrMJHFvzn6aji8-hYIYZDhjsgJ2e5wNw1VAk4=.15d885e2-55a3-4fd1-b12e-63181f58fe9f@github.com>

On Fri, 8 Jan 2021 11:39:17 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Hi @stsypanov, 
>> 
>>> The **behavior** of this convenience method is **identical** to that of c.addAll(Arrays.asList(elements))
>> 
>> What about:
>> 
>>> The **behaviour** of this convenience method is **similar** to that of c.addAll(Arrays.asList(elements))
>> 
>> ...since it is not entirely identical. The outcome is usually identical because collections usually adhere to the specification, but we can not claim the behaviour is identical if the target collection does not adhere.
>
> ...but we could employ this method to guarantee more than `c.addAll(Arrays.asList(elements))` does. So what about:
> 
>> The behaviour of this convenience method is similar to that of `c.addAll(Collections.unmodifiableList(Arrays.asList(elements)))`
> 
> This means that the method guarantees that the passed in `elements` array will not be modified even if given collection `c` is not trusted. Speaking of that, perhaps you could try benchmarking such `c.addAll(Collections.unmodifiableList(Arrays.asList(elements)))` and see how it compares. The speed-up you observed from `c.addAll(Arrays.asList(elements))` with some collections was probably a result of them calling .toArray() on the argument collection and incorporating the resulting array into their own data structure in a bulk-copying-way. So `c.addAll(Collections.unmodifiableList(Arrays.asList(elements)))` might have same performance characteristics while guaranteeing same things about argument array. It might be slower when Iterator is employed though because unmodifiableList wrapper wraps Iterator(s) too....

@plevart done. Should I also rename this PR to e.g. 'Fix performance-related notation in Collections.addAll'?

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

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

From plevart at openjdk.java.net  Thu Jan 14 10:21:01 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Thu, 14 Jan 2021 10:21:01 GMT
Subject: RFR: 8193031: Collections.addAll is likely to perform worse than
 Collection.addAll
In-Reply-To: <uXM0w30njrZNn9c68Sn_jjcAnJZGZWZXzoA0wRJcwRM=.6d6408b3-8d28-4272-8bdf-921b9d1ae971@github.com>
References: <TB3epXzVEKg86PLsoPvHgfKAC2XHrLGCH2ZsuCJw2h4=.c75b4032-abb7-4f95-b19e-65788727f049@github.com>
 <X4vHouF0uVTx1XTeRjmqZ0ldcYtqP-Zkf1ujMzvRbtM=.633d7310-3d0b-4296-95ba-7b6829482b43@github.com>
 <HGsYr1kNCPjCwV5bnXUUsSvxHd15C3G99FulbSkpFYE=.18613967-548c-488e-8d12-1e40bcfffa72@github.com>
 <47B7kkUUmzlTIJLb14nPTXYckKtrXTREVZLU2iilSGU=.b1c05f13-aea1-4d90-bc2b-37d2ab6280dd@github.com>
 <MMgyNFF6k3ovq--q8ZWNOUhVxKhs46sTCVYe1ucrYXo=.887bfa14-1c3e-4fc8-86e3-d5a8442277ff@github.com>
 <uXM0w30njrZNn9c68Sn_jjcAnJZGZWZXzoA0wRJcwRM=.6d6408b3-8d28-4272-8bdf-921b9d1ae971@github.com>
Message-ID: <-q_ZidZykX6ZHSA1vFininRYLfOOlwIhkwg3k5-Eg-w=.521d1eb9-a81e-462a-9431-d97e847314e0@github.com>

On Fri, 8 Jan 2021 11:39:17 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Hi @stsypanov, 
>> 
>>> The **behavior** of this convenience method is **identical** to that of c.addAll(Arrays.asList(elements))
>> 
>> What about:
>> 
>>> The **behaviour** of this convenience method is **similar** to that of c.addAll(Arrays.asList(elements))
>> 
>> ...since it is not entirely identical. The outcome is usually identical because collections usually adhere to the specification, but we can not claim the behaviour is identical if the target collection does not adhere.
>
> ...but we could employ this method to guarantee more than `c.addAll(Arrays.asList(elements))` does. So what about:
> 
>> The behaviour of this convenience method is similar to that of `c.addAll(Collections.unmodifiableList(Arrays.asList(elements)))`
> 
> This means that the method guarantees that the passed in `elements` array will not be modified even if given collection `c` is not trusted. Speaking of that, perhaps you could try benchmarking such `c.addAll(Collections.unmodifiableList(Arrays.asList(elements)))` and see how it compares. The speed-up you observed from `c.addAll(Arrays.asList(elements))` with some collections was probably a result of them calling .toArray() on the argument collection and incorporating the resulting array into their own data structure in a bulk-copying-way. So `c.addAll(Collections.unmodifiableList(Arrays.asList(elements)))` might have same performance characteristics while guaranteeing same things about argument array. It might be slower when Iterator is employed though because unmodifiableList wrapper wraps Iterator(s) too....

> @plevart done. Should I also rename this PR to e.g. 'Fix performance-related notation in Collections.addAll'?

I think the title of JIRA ticket has to be the same as that of PR (with JIRA bug number prepended) in order to pass all checks needed for integrating. So If you modify both, it would be fine.

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

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

From erikj at openjdk.java.net  Thu Jan 14 13:48:04 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 14 Jan 2021 13:48:04 GMT
Subject: RFR: 8253866: Security Libs Terminology Refresh
In-Reply-To: <em1vZcNQK0XBFktbyJQoH-McK_Scddtv2VyzVSaqbWw=.ddfc9733-b5fd-4905-ac1d-6ec18a6ce94d@github.com>
References: <em1vZcNQK0XBFktbyJQoH-McK_Scddtv2VyzVSaqbWw=.ddfc9733-b5fd-4905-ac1d-6ec18a6ce94d@github.com>
Message-ID: <E-eRMDByVpTxOo3mMuMhf4Ir8M22Rh8dDbuzGm2KG1E=.3450cad9-c685-4fcc-8260-dcff113cf610@github.com>

On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This is the security libs portion of the effort to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
> 
> Here are the changes covering core libraries code and tests. Terms were changed as follows:
> 
> - blacklisted.certs -> blocked.certs (along with supporting make infrastructure and tests)
> - master/slave in KRB5 -> primary/replica
> - blacklist in other files -> deny list
> - whitelist -> allow list
> 
> Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources.

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

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

From github.com+541734+kezhuw at openjdk.java.net  Thu Jan 14 14:03:13 2021
From: github.com+541734+kezhuw at openjdk.java.net (Kezhu Wang)
Date: Thu, 14 Jan 2021 14:03:13 GMT
Subject: [jdk16] RFR: 8254350: CompletableFuture.get may swallow
 InterruptedException
In-Reply-To: <L79zhBjDueGRUorP18JCLogC0k2Yyxr-FBsUVhI7CkU=.52b3288a-46e0-4d96-9ef8-f4032b5e96c5@github.com>
References: <L79zhBjDueGRUorP18JCLogC0k2Yyxr-FBsUVhI7CkU=.52b3288a-46e0-4d96-9ef8-f4032b5e96c5@github.com>
Message-ID: <AGhZN2K7NWr8eND_9_POKxmH55p0438vq0b42agkMSU=.2564d754-1c00-48fe-bf90-25fc9f5c9cb0@github.com>

On Sun, 13 Dec 2020 03:31:44 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> 8254350: CompletableFuture.get may swallow InterruptedException

@Martin-Buchholz @DougLea @AlanBateman Sorry for rough in.  After change `future.get()` to `future.get(1, TimeUnit.DAYS)`, `SwallowedInterruptedException` failed.

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

PR: https://git.openjdk.java.net/jdk16/pull/17

From ljiang at openjdk.java.net  Thu Jan 14 14:05:11 2021
From: ljiang at openjdk.java.net (Leo Jiang)
Date: Thu, 14 Jan 2021 14:05:11 GMT
Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop
 10
Message-ID: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>

This is the changes for JDK 16 msg drop 10.

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

Commit messages:
 - JDK-8259732: JDK 16 L10n resource file update - msg drop 10

Changes: https://git.openjdk.java.net/jdk16/pull/123/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=123&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259732
  Stats: 215 lines in 30 files changed: 118 ins; 16 del; 81 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/123.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/123/head:pull/123

PR: https://git.openjdk.java.net/jdk16/pull/123

From ljiang at openjdk.java.net  Thu Jan 14 14:13:02 2021
From: ljiang at openjdk.java.net (Leo Jiang)
Date: Thu, 14 Jan 2021 14:13:02 GMT
Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg
 drop 10
In-Reply-To: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
References: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
Message-ID: <FCX2HQfImkF__vutic3srcM1McfxwuYWER_V_y2p-so=.aaace982-47ea-4f6a-b600-33049e81d7b9@github.com>

On Thu, 14 Jan 2021 14:00:00 GMT, Leo Jiang <ljiang at openjdk.org> wrote:

> This is the changes for JDK 16 msg drop 10.

[webrev.tar.gz](https://github.com/openjdk/jdk16/files/5814846/webrev.tar.gz)

Since they're Unicode escape sequences in the l10n resource files, so I attached a human readable webrev, created by `git webrev` and converted. Pls find this to help your review.

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

PR: https://git.openjdk.java.net/jdk16/pull/123

From ljiang at openjdk.java.net  Thu Jan 14 14:27:25 2021
From: ljiang at openjdk.java.net (Leo Jiang)
Date: Thu, 14 Jan 2021 14:27:25 GMT
Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg
 drop 10 [v2]
In-Reply-To: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
References: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
Message-ID: <QceWk9N7q2iV9alfICITS0Sdr8eacuR15Mrihph-doI=.1cee427c-0be1-4cb9-8a77-098696ddd5da@github.com>

> This is the changes for JDK 16 msg drop 10.

Leo Jiang 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:

 - Merge branch 'master' into msgdrop
 - JDK-8259732: JDK 16 L10n resource file update - msg drop 10

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/123/files
  - new: https://git.openjdk.java.net/jdk16/pull/123/files/230117b4..d72f444a

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

  Stats: 718 lines in 32 files changed: 616 ins; 38 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/123.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/123/head:pull/123

PR: https://git.openjdk.java.net/jdk16/pull/123

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jan 14 15:25:25 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, 14 Jan 2021 15:25:25 GMT
Subject: RFR: 8193031: Collections.addAll is likely to perform worse than
 Collection.addAll
In-Reply-To: <-q_ZidZykX6ZHSA1vFininRYLfOOlwIhkwg3k5-Eg-w=.521d1eb9-a81e-462a-9431-d97e847314e0@github.com>
References: <TB3epXzVEKg86PLsoPvHgfKAC2XHrLGCH2ZsuCJw2h4=.c75b4032-abb7-4f95-b19e-65788727f049@github.com>
 <X4vHouF0uVTx1XTeRjmqZ0ldcYtqP-Zkf1ujMzvRbtM=.633d7310-3d0b-4296-95ba-7b6829482b43@github.com>
 <HGsYr1kNCPjCwV5bnXUUsSvxHd15C3G99FulbSkpFYE=.18613967-548c-488e-8d12-1e40bcfffa72@github.com>
 <47B7kkUUmzlTIJLb14nPTXYckKtrXTREVZLU2iilSGU=.b1c05f13-aea1-4d90-bc2b-37d2ab6280dd@github.com>
 <MMgyNFF6k3ovq--q8ZWNOUhVxKhs46sTCVYe1ucrYXo=.887bfa14-1c3e-4fc8-86e3-d5a8442277ff@github.com>
 <uXM0w30njrZNn9c68Sn_jjcAnJZGZWZXzoA0wRJcwRM=.6d6408b3-8d28-4272-8bdf-921b9d1ae971@github.com>
 <-q_ZidZykX6ZHSA1vFininRYLfOOlwIhkwg3k5-Eg-w=.521d1eb9-a81e-462a-9431-d97e847314e0@github.com>
Message-ID: <6adPkzw9bZs5rgBQQY_SRKe0z2guanyQJTczLshUpbs=.97ac831d-fdda-462b-b1e8-ca43ce165fe2@github.com>

On Thu, 14 Jan 2021 10:18:23 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> ...but we could employ this method to guarantee more than `c.addAll(Arrays.asList(elements))` does. So what about:
>> 
>>> The behaviour of this convenience method is similar to that of `c.addAll(Collections.unmodifiableList(Arrays.asList(elements)))`
>> 
>> This means that the method guarantees that the passed in `elements` array will not be modified even if given collection `c` is not trusted. Speaking of that, perhaps you could try benchmarking such `c.addAll(Collections.unmodifiableList(Arrays.asList(elements)))` and see how it compares. The speed-up you observed from `c.addAll(Arrays.asList(elements))` with some collections was probably a result of them calling .toArray() on the argument collection and incorporating the resulting array into their own data structure in a bulk-copying-way. So `c.addAll(Collections.unmodifiableList(Arrays.asList(elements)))` might have same performance characteristics while guaranteeing same things about argument array. It might be slower when Iterator is employed though because unmodifiableList wrapper wraps Iterator(s) too....
>
>> @plevart done. Should I also rename this PR to e.g. 'Fix performance-related notation in Collections.addAll'?
> 
> I think the title of JIRA ticket has to be the same as that of PR (with JIRA bug number prepended) in order to pass all checks needed for integrating. So If you modify both, it would be fine.

I cannot modify JIRA ticket without account there, so let's keep it as is

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jan 14 15:25:25 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, 14 Jan 2021 15:25:25 GMT
Subject: RFR: 8193031: Collections.addAll is likely to perform worse than
 Collection.addAll [v7]
In-Reply-To: <TB3epXzVEKg86PLsoPvHgfKAC2XHrLGCH2ZsuCJw2h4=.c75b4032-abb7-4f95-b19e-65788727f049@github.com>
References: <TB3epXzVEKg86PLsoPvHgfKAC2XHrLGCH2ZsuCJw2h4=.c75b4032-abb7-4f95-b19e-65788727f049@github.com>
Message-ID: <9d7U4WiWGceuNVbh4TRHi7DpKBQNF0mCw_b-RrHb_aE=.fdb7ba7b-1a51-4be0-bbb7-dd47097fc93e@github.com>

> Hello, I feel like this was previously discussed in https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot find original mail I post this here.
> 
> Currently `Collections.addAll()` is implemented and documented as:
>     /**
>      * ...
>      * The behavior of this convenience method is identical to that of
>      * {@code c.addAll(Arrays.asList(elements))}, but this method is likely
>      * to run significantly faster under most implementations.
>      */
>     @SafeVarargs
>     public static <T> boolean addAll(Collection<? super T> c, T... elements) {
>         boolean result = false;
>         for (T element : elements)
>             result |= c.add(element);
>         return result;
>     }
> 
> But it practice the notation `this method is likely to run significantly faster under most implementations` is completely wrong. When I take this [benchmark](https://github.com/stsypanov/benchmarks/blob/master/benchmark-runners/src/main/java/com/luxoft/logeek/benchmark/collection/CollectionsAddAllVsAddAllBenchmark.java) and run it on JDK 14 I get the following results:
>                                                    (collection)  (size)      Score     Error   Units
> addAll                                                ArrayList      10       37.9 ?     1.9   ns/op
> addAll                                                ArrayList     100       83.8 ?     3.4   ns/op
> addAll                                                ArrayList    1000      678.2 ?    23.0   ns/op
> collectionsAddAll                                     ArrayList      10       50.9 ?     1.1   ns/op
> collectionsAddAll                                     ArrayList     100      751.4 ?    47.4   ns/op
> collectionsAddAll                                     ArrayList    1000     8839.8 ?   710.7   ns/op
> 
> addAll                                                  HashSet      10      128.4 ?     5.9   ns/op
> addAll                                                  HashSet     100     1864.2 ?   102.4   ns/op
> addAll                                                  HashSet    1000    16615.5 ?  1202.6   ns/op
> collectionsAddAll                                       HashSet      10      172.8 ?     6.0   ns/op
> collectionsAddAll                                       HashSet     100     2355.8 ?   195.4   ns/op
> collectionsAddAll                                       HashSet    1000    20364.7 ?  1164.0   ns/op
> 
> addAll                                               ArrayDeque      10       54.0 ?     0.4   ns/op
> addAll                                               ArrayDeque     100      319.7 ?     2.5   ns/op
> addAll                                               ArrayDeque    1000     3176.9 ?    22.2   ns/op
> collectionsAddAll                                    ArrayDeque      10       66.5 ?     1.4   ns/op
> collectionsAddAll                                    ArrayDeque     100      808.1 ?    55.9   ns/op
> collectionsAddAll                                    ArrayDeque    1000     5639.6 ?   240.9   ns/op
> 
> addAll                                     CopyOnWriteArrayList      10       18.0 ?     0.7   ns/op
> addAll                                     CopyOnWriteArrayList     100       39.4 ?     1.7   ns/op
> addAll                                     CopyOnWriteArrayList    1000      371.1 ?    17.0   ns/op
> collectionsAddAll                          CopyOnWriteArrayList      10      251.9 ?    18.4   ns/op
> collectionsAddAll                          CopyOnWriteArrayList     100     3405.9 ?   304.8   ns/op
> collectionsAddAll                          CopyOnWriteArrayList    1000   247496.8 ? 23502.3   ns/op
> 
> addAll                                    ConcurrentLinkedDeque      10       81.4 ?     2.8   ns/op
> addAll                                    ConcurrentLinkedDeque     100      609.1 ?    26.4   ns/op
> addAll                                    ConcurrentLinkedDeque    1000     4494.5 ?   219.3   ns/op
> collectionsAddAll                         ConcurrentLinkedDeque      10      189.8 ?     2.5   ns/op
> collectionsAddAll                         ConcurrentLinkedDeque     100     1660.0 ?    62.0   ns/op
> collectionsAddAll                         ConcurrentLinkedDeque    1000    17649.2 ?   300.9   ns/op
> 
> addAll:?gc.alloc.rate.norm                            ArrayList      10      160.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                            ArrayList     100      880.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                            ArrayList    1000     8080.3 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                 ArrayList      10       80.0 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                 ArrayList     100     1400.2 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                 ArrayList    1000    15025.6 ?     0.1    B/op
> 
> addAll:?gc.alloc.rate.norm                              HashSet      10      464.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                              HashSet     100     5328.5 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                              HashSet    1000    48516.7 ?     0.1    B/op
> collectionsAddAll:?gc.alloc.rate.norm                   HashSet      10      464.0 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                   HashSet     100     5328.5 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                   HashSet    1000    48516.6 ?     0.1    B/op
> 
> addAll:?gc.alloc.rate.norm                           ArrayDeque      10      112.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                           ArrayDeque     100      560.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                           ArrayDeque    1000     4160.5 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                ArrayDeque      10      112.0 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                ArrayDeque     100     1048.1 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                ArrayDeque    1000    14929.4 ?     0.0    B/op
> 
> addAll:?gc.alloc.rate.norm                 CopyOnWriteArrayList      10       88.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                 CopyOnWriteArrayList     100      448.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                 CopyOnWriteArrayList    1000     4048.1 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm      CopyOnWriteArrayList      10      456.0 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm      CopyOnWriteArrayList     100    22057.2 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm      CopyOnWriteArrayList    1000  2020150.3 ?     7.3    B/op
> 
> addAll:?gc.alloc.rate.norm                ConcurrentLinkedDeque      10      312.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                ConcurrentLinkedDeque     100     2472.1 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                ConcurrentLinkedDeque    1000    24073.7 ?     0.1    B/op
> collectionsAddAll:?gc.alloc.rate.norm     ConcurrentLinkedDeque      10      288.0 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm     ConcurrentLinkedDeque     100     2448.3 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm     ConcurrentLinkedDeque    1000    24051.4 ?     0.3    B/op
> There's never a case when `Collections.addAll` is fater - on the contrary `c.addAll(Arrays.asList())` always wins. Pay attention especially to dramatic difference for array-based collection.
> 
> So I propose to reimplement the method by simply delegating to `Arrays.asList` because the spec declares identical behaviour and to remove perfomance notation from JavaDoc.

?????? ??????? 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 add-all
 - 8193031: fix JavaDoc
 - Merge branch 'master' into add-all
 - Merge branch 'master' into add-all
 - 8193031: revert implementation change but keep one for JavaDoc
 - Merge branch 'master' into add-all
 - Merge remote-tracking branch 'origin/add-all' into add-all
 - 8193031: add elements in bulk in Collections.addAll()
 - Merge branch 'master' into add-all
 - 8193031: add elements in bulk in Collections.addAll()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1764/files
  - new: https://git.openjdk.java.net/jdk/pull/1764/files/096c5dee..24004928

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

  Stats: 956 lines in 24 files changed: 200 ins; 731 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1764.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1764/head:pull/1764

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

From weijun at openjdk.java.net  Thu Jan 14 15:30:02 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 14 Jan 2021 15:30:02 GMT
Subject: RFR: 8253866: Security Libs Terminology Refresh
In-Reply-To: <em1vZcNQK0XBFktbyJQoH-McK_Scddtv2VyzVSaqbWw=.ddfc9733-b5fd-4905-ac1d-6ec18a6ce94d@github.com>
References: <em1vZcNQK0XBFktbyJQoH-McK_Scddtv2VyzVSaqbWw=.ddfc9733-b5fd-4905-ac1d-6ec18a6ce94d@github.com>
Message-ID: <NM5cdY0TKn4ynMdmGQSLiHGbe4mYdRFQatJluVJXdq8=.df375b09-732d-4e2f-bef3-b06e826463d0@github.com>

On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This is the security libs portion of the effort to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
> 
> Here are the changes covering core libraries code and tests. Terms were changed as follows:
> 
> - blacklisted.certs -> blocked.certs (along with supporting make infrastructure and tests)
> - master/slave in KRB5 -> primary/replica
> - blacklist in other files -> deny list
> - whitelist -> allow list
> 
> Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources.

Code change looks fine to me.

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

Marked as reviewed by weijun (Reviewer).

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

From ljiang at openjdk.java.net  Thu Jan 14 15:38:09 2021
From: ljiang at openjdk.java.net (Leo Jiang)
Date: Thu, 14 Jan 2021 15:38:09 GMT
Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg
 drop 10
In-Reply-To: <FCX2HQfImkF__vutic3srcM1McfxwuYWER_V_y2p-so=.aaace982-47ea-4f6a-b600-33049e81d7b9@github.com>
References: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
 <FCX2HQfImkF__vutic3srcM1McfxwuYWER_V_y2p-so=.aaace982-47ea-4f6a-b600-33049e81d7b9@github.com>
Message-ID: <QQcGq2C1aAOYLUlOr_YOSb8PJgna7OYeWKJuT23UH3Y=.35c72bba-5d48-42c5-8be1-f67d528f3d41@github.com>

On Thu, 14 Jan 2021 14:10:12 GMT, Leo Jiang <ljiang at openjdk.org> wrote:

>> This is the changes for JDK 16 msg drop 10.
>
> [webrev.tar.gz](https://github.com/openjdk/jdk16/files/5814846/webrev.tar.gz)
> 
> Since they're Unicode escape sequences in the l10n resource files, so I attached a human readable webrev, created by `git webrev` and converted. Pls find this to help your review.

@naotoj Would you have time to take a look at this change? Very appreciated!

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

PR: https://git.openjdk.java.net/jdk16/pull/123

From mullan at openjdk.java.net  Thu Jan 14 15:51:04 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 14 Jan 2021 15:51:04 GMT
Subject: RFR: 8253866: Security Libs Terminology Refresh
In-Reply-To: <em1vZcNQK0XBFktbyJQoH-McK_Scddtv2VyzVSaqbWw=.ddfc9733-b5fd-4905-ac1d-6ec18a6ce94d@github.com>
References: <em1vZcNQK0XBFktbyJQoH-McK_Scddtv2VyzVSaqbWw=.ddfc9733-b5fd-4905-ac1d-6ec18a6ce94d@github.com>
Message-ID: <t-WRHez-WCGHMe3O8NAAKqxyeOO7G7uC-m-Yyx010EQ=.62417619-a7e2-4935-b060-4cc164a53984@github.com>

On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This is the security libs portion of the effort to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
> 
> Here are the changes covering core libraries code and tests. Terms were changed as follows:
> 
> - blacklisted.certs -> blocked.certs (along with supporting make infrastructure and tests)
> - master/slave in KRB5 -> primary/replica
> - blacklist in other files -> deny list
> - whitelist -> allow list
> 
> Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources.

Marked as reviewed by mullan (Reviewer).

src/java.base/share/conf/security/java.security line 454:

> 452: #    configuration, but with smaller max_retries and timeout values.
> 453: #    max_retries and timeout are optional numerical parameters (default 1 and
> 454: #    5000, which means once and 5 seconds). Please notes that if any of the

Typo: s/notes/note/

src/java.base/share/conf/security/java.security line 455:

> 453: #    max_retries and timeout are optional numerical parameters (default 1 and
> 454: #    5000, which means once and 5 seconds). Please notes that if any of the
> 455: #    values defined here is more than what is defined in krb5.conf, it will be

Typo: s/is more/are more/

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

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

From jnimeh at openjdk.java.net  Thu Jan 14 16:40:15 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 14 Jan 2021 16:40:15 GMT
Subject: RFR: 8253866: Security Libs Terminology Refresh [v2]
In-Reply-To: <em1vZcNQK0XBFktbyJQoH-McK_Scddtv2VyzVSaqbWw=.ddfc9733-b5fd-4905-ac1d-6ec18a6ce94d@github.com>
References: <em1vZcNQK0XBFktbyJQoH-McK_Scddtv2VyzVSaqbWw=.ddfc9733-b5fd-4905-ac1d-6ec18a6ce94d@github.com>
Message-ID: <ZyAfdic5Tnnvo2KjF7a699q6a0dbr7I5gb-UNXj_Efc=.cbfb6347-c943-4345-9af3-c247b6d27c00@github.com>

> This is the security libs portion of the effort to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
> 
> Here are the changes covering core libraries code and tests. Terms were changed as follows:
> 
> - blacklisted.certs -> blocked.certs (along with supporting make infrastructure and tests)
> - master/slave in KRB5 -> primary/replica
> - blacklist in other files -> deny list
> - whitelist -> allow list
> 
> Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources.

Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:

  Minor grammatical fixes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2074/files
  - new: https://git.openjdk.java.net/jdk/pull/2074/files/9d44a9e1..45492f55

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

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

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

From jnimeh at openjdk.java.net  Thu Jan 14 16:40:17 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 14 Jan 2021 16:40:17 GMT
Subject: RFR: 8253866: Security Libs Terminology Refresh [v2]
In-Reply-To: <t-WRHez-WCGHMe3O8NAAKqxyeOO7G7uC-m-Yyx010EQ=.62417619-a7e2-4935-b060-4cc164a53984@github.com>
References: <em1vZcNQK0XBFktbyJQoH-McK_Scddtv2VyzVSaqbWw=.ddfc9733-b5fd-4905-ac1d-6ec18a6ce94d@github.com>
 <t-WRHez-WCGHMe3O8NAAKqxyeOO7G7uC-m-Yyx010EQ=.62417619-a7e2-4935-b060-4cc164a53984@github.com>
Message-ID: <0T5q-e3tXNFq1QKgKV3YvjgFIhNZG6QpmhnG2_Y3JrA=.2a06de53-02db-4b9b-b58c-5f8220c83a71@github.com>

On Thu, 14 Jan 2021 15:45:43 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor grammatical fixes
>
> src/java.base/share/conf/security/java.security line 455:
> 
>> 453: #    max_retries and timeout are optional numerical parameters (default 1 and
>> 454: #    5000, which means once and 5 seconds). Please notes that if any of the
>> 455: #    values defined here is more than what is defined in krb5.conf, it will be
> 
> Typo: s/is more/are more/

Done.  Good catch.

> src/java.base/share/conf/security/java.security line 454:
> 
>> 452: #    configuration, but with smaller max_retries and timeout values.
>> 453: #    max_retries and timeout are optional numerical parameters (default 1 and
>> 454: #    5000, which means once and 5 seconds). Please notes that if any of the
> 
> Typo: s/notes/note/

fixed

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

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

From jnimeh at openjdk.java.net  Thu Jan 14 16:40:18 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 14 Jan 2021 16:40:18 GMT
Subject: Integrated: 8253866: Security Libs Terminology Refresh
In-Reply-To: <em1vZcNQK0XBFktbyJQoH-McK_Scddtv2VyzVSaqbWw=.ddfc9733-b5fd-4905-ac1d-6ec18a6ce94d@github.com>
References: <em1vZcNQK0XBFktbyJQoH-McK_Scddtv2VyzVSaqbWw=.ddfc9733-b5fd-4905-ac1d-6ec18a6ce94d@github.com>
Message-ID: <Q4LB3BIJjS94hNpmDQwVLI9dSaCxFcGJ2yGZKYt8gyE=.cc8cac15-6c1d-4618-a76d-54e993891b0b@github.com>

On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This is the security libs portion of the effort to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
> 
> Here are the changes covering core libraries code and tests. Terms were changed as follows:
> 
> - blacklisted.certs -> blocked.certs (along with supporting make infrastructure and tests)
> - master/slave in KRB5 -> primary/replica
> - blacklist in other files -> deny list
> - whitelist -> allow list
> 
> Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources.

This pull request has now been integrated.

Changeset: 8554fe6e
Author:    Jamil Nimeh <jnimeh at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8554fe6e
Stats:     351 lines in 17 files changed: 152 ins; 150 del; 49 mod

8253866: Security Libs Terminology Refresh

Reviewed-by: erikj, weijun, mullan

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

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

From naoto at openjdk.java.net  Thu Jan 14 17:02:03 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 14 Jan 2021 17:02:03 GMT
Subject: Integrated: 8258956: Memory Leak in StringCoding on ThreadLocal
 resultCached StringCoding.Result
In-Reply-To: <-8rLEVPm5yxiYqeirzdzGg2zHEwYtdma1ZWtYrDT7mA=.17c85478-b25e-46b9-b672-a8b9b791e640@github.com>
References: <-8rLEVPm5yxiYqeirzdzGg2zHEwYtdma1ZWtYrDT7mA=.17c85478-b25e-46b9-b672-a8b9b791e640@github.com>
Message-ID: <F8-5xV9sfA0GArCNwyfaMuC49KhuVBz1Sn7V1Mp78w8=.ccca1832-073f-474a-8420-4abeb2f5bb0a@github.com>

On Wed, 13 Jan 2021 18:41:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to this issue. Unused thread local StringCoding.Result is now wrapped with SoftReference, which can be GC'ed as needed. I confirmed it worked as expected with a test case (https://github.com/openjdk/jdk/blob/8b4e1e1cf8f5d753ed901406f73d67b21557fddb/test/jdk/java/lang/StringCoding/ResultCachedGCTest.java), but decided not to include it in this PR. This is because I purposefully chose the size of the byte array and max heap size which is fragile, and could become noise in a regression test run.

This pull request has now been integrated.

Changeset: aba3431c
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/aba3431c
Stats:     18 lines in 1 file changed: 9 ins; 0 del; 9 mod

8258956: Memory Leak in StringCoding on ThreadLocal resultCached StringCoding.Result

Reviewed-by: rriggs, alanb

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

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

From naoto at openjdk.java.net  Thu Jan 14 17:22:09 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 14 Jan 2021 17:22:09 GMT
Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg
 drop 10 [v2]
In-Reply-To: <QceWk9N7q2iV9alfICITS0Sdr8eacuR15Mrihph-doI=.1cee427c-0be1-4cb9-8a77-098696ddd5da@github.com>
References: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
 <QceWk9N7q2iV9alfICITS0Sdr8eacuR15Mrihph-doI=.1cee427c-0be1-4cb9-8a77-098696ddd5da@github.com>
Message-ID: <ZkHoKP8fL7uRj0TIiwqYtVch0eyxQGv2JeY-BDgf310=.91ef28d1-d91b-4b37-aa9f-edd81b94f235@github.com>

On Thu, 14 Jan 2021 14:27:25 GMT, Leo Jiang <ljiang at openjdk.org> wrote:

>> This is the changes for JDK 16 msg drop 10.
>
> Leo Jiang 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:
> 
>  - Merge branch 'master' into msgdrop
>  - JDK-8259732: JDK 16 L10n resource file update - msg drop 10

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 518:

> 516: doclet.footer_specified=\
> 517:     The -footer option is no longer supported and will be ignored.\n\
> 518:     It may be removed in a future release.

I believe this is to fix no newline at the end (unrelated to l10n changes). Do we need to change the copyright year for this?

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

PR: https://git.openjdk.java.net/jdk16/pull/123

From martin at openjdk.java.net  Thu Jan 14 18:19:08 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Thu, 14 Jan 2021 18:19:08 GMT
Subject: [jdk16] RFR: 8254350: CompletableFuture.get may swallow
 InterruptedException
In-Reply-To: <AGhZN2K7NWr8eND_9_POKxmH55p0438vq0b42agkMSU=.2564d754-1c00-48fe-bf90-25fc9f5c9cb0@github.com>
References: <L79zhBjDueGRUorP18JCLogC0k2Yyxr-FBsUVhI7CkU=.52b3288a-46e0-4d96-9ef8-f4032b5e96c5@github.com>
 <AGhZN2K7NWr8eND_9_POKxmH55p0438vq0b42agkMSU=.2564d754-1c00-48fe-bf90-25fc9f5c9cb0@github.com>
Message-ID: <n87KiN6oKVCGxknJHXAxm00KpOASVUXit0DRivqW7BQ=.e8539e3f-1b8b-41df-a5f0-5a18fc952328@github.com>

On Thu, 14 Jan 2021 13:59:50 GMT, Kezhu Wang <github.com+541734+kezhuw at openjdk.org> wrote:

>> 8254350: CompletableFuture.get may swallow InterruptedException
>
> @Martin-Buchholz @DougLea @AlanBateman Sorry for rough in.  After change `future.get()` to `future.get(1, TimeUnit.DAYS)`, `SwallowedInterruptedException` failed.

Thanks, Kezhu.  I filed:
https://bugs.openjdk.java.net/browse/JDK-8259796

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

PR: https://git.openjdk.java.net/jdk16/pull/17

From sebastian.stenzel at gmail.com  Wed Jan 13 18:45:29 2021
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Wed, 13 Jan 2021 19:45:29 +0100
Subject: Difference in encoding semantics of URI returned by File.toURI
 and Path.toUri representing the same file
In-Reply-To: <08edf854-6414-800f-4fa4-2f06d234e6a6@oracle.com>
References: <3cd8d31d-1640-a855-4ba2-bf05be8adfe0@gmail.com>
 <08edf854-6414-800f-4fa4-2f06d234e6a6@oracle.com>
Message-ID: <9B159D6D-8AF4-414C-A86A-ACFD34D67288@gmail.com>


> On 13. Jan 2021, at 17:50, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> [...]
> It's not clear to me whether NFC should be applied - or what would be
> the consequences of applying NFC there (or not).


While I can't answer this question, it may be worth mentioning RFC 3987 which might not be directly applicable but also deals with the representation of non-ASCII data in URIs.

In section 3 it explicitly asks for NFC-normalization _before_ applying percent-encoding. I can't tell what's the rationale behind this decision but possibly the behaviour of URI.toASCIIString() is in the spirit of these rules.

From yano-masanori at fujitsu.com  Tue Jan 12 07:31:37 2021
From: yano-masanori at fujitsu.com (yano-masanori at fujitsu.com)
Date: Tue, 12 Jan 2021 07:31:37 +0000
Subject: [PING] RE: 8250678: ModuleDescriptor.Version parsing treats empty
 segments inconsistently
In-Reply-To: <TYCPR01MB582339DC1DD29358237A9268E7DE0@TYCPR01MB5823.jpnprd01.prod.outlook.com>
References: <TYCPR01MB582339DC1DD29358237A9268E7DE0@TYCPR01MB5823.jpnprd01.prod.outlook.com>
Message-ID: <OS0PR01MB5809639A03A4AD021EB1C8CCE7AA0@OS0PR01MB5809.jpnprd01.prod.outlook.com>

Hello,

Please reply if anyone can be a sponsor.

Regards,
Masanori Yano

> -----Original Message-----
> From: Yano, Masanori 
> Sent: Wednesday, December 23, 2020 5:01 PM
> To: 'core-libs-dev at openjdk.java.net' <core-libs-dev at openjdk.java.net>
> Subject: [PING] RE: 8250678: ModuleDescriptor.Version parsing treats empty
> segments inconsistently
> 
> Hello,
> 
> Please reply if anyone can be a sponsor.
> 
> Regards,
> Masanori Yano
> 
> > -----Original Message-----
> > From: Yano, Masanori
> > Sent: Wednesday, November 4, 2020 6:03 PM
> > To: 'core-libs-dev at openjdk.java.net' <core-libs-dev at openjdk.java.net>
> > Subject: 8250678: ModuleDescriptor.Version parsing treats empty
> > segments inconsistently
> >
> > Hello.
> >
> > I would like to contribute for JDK-8250678.
> >
> > The 'parse' method of ModuleDescriptor.Version class behaves
> > incorrectly when the input string contains consecutive delimiters.
> >
> > The 'parse' method treats strings as three sections, but the parsing
> > method differs between the method for the version sections and the ones for others.
> > In version sections, the 'parse' method takes a single character in a
> > loop and determines whether it is a delimiter. In pre and build
> > sections, the parse method takes two characters in a loop and determines whether
> the second character is the delimiter.
> > Therefore, if the string contains a sequence of delimiters in pre or
> > build section, the 'parse' method treats character at the odd-numbered
> > position as a token and the one at even-numbered as a delimiter
> >
> > A string containing consecutive delimiters is an incorrect version
> > string, but this behavior does not follow the API specification.
> > https://download.java.net/java/early_access/jdk16/docs/api/java.base/j
> > ava/lang/
> > module/ModuleDescriptor.Version.html
> >
> > Therefore, I propose to fix the parsing method of the pre section and
> > the build section in the same way as the version.
> >
> > Please sponsor the following change.
> >
> > diff -r bdc20ee1a68d
> > src/java.base/share/classes/java/lang/module/ModuleDescriptor.java
> > --- a/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java
> > 	Fri Sep 04 23:51:26 2020 -0400
> > +++ b/src/java.base/share/classes/java/lang/module/ModuleDescriptor.ja
> > +++ va
> > 	Wed Oct 28 17:06:47 2020 +0900
> > @@ -1053,13 +1053,6 @@
> >
> >              while (i < n) {
> >                  c = v.charAt(i);
> > -                if (c >= '0' && c <= '9')
> > -                    i = takeNumber(v, i, pre);
> > -                else
> > -                    i = takeString(v, i, pre);
> > -                if (i >= n)
> > -                    break;
> > -                c = v.charAt(i);
> >                  if (c == '.' || c == '-') {
> >                      i++;
> >                      continue;
> > @@ -1068,6 +1061,10 @@
> >                      i++;
> >                      break;
> >                  }
> > +                if (c >= '0' && c <= '9')
> > +                    i = takeNumber(v, i, pre);
> > +                else
> > +                    i = takeString(v, i, pre);
> >              }
> >
> >              if (c == '+' && i >= n)
> > @@ -1075,17 +1072,14 @@
> >
> >              while (i < n) {
> >                  c = v.charAt(i);
> > +                if (c == '.' || c == '-' || c == '+') {
> > +                    i++;
> > +                    continue;
> > +                }
> >                  if (c >= '0' && c <= '9')
> >                      i = takeNumber(v, i, build);
> >                  else
> >                      i = takeString(v, i, build);
> > -                if (i >= n)
> > -                    break;
> > -                c = v.charAt(i);
> > -                if (c == '.' || c == '-' || c == '+') {
> > -                    i++;
> > -                    continue;
> > -                }
> >              }
> >
> >              this.version = v;
> > diff -r bdc20ee1a68d test/jdk/java/lang/module/VersionTest.java
> > --- a/test/jdk/java/lang/module/VersionTest.java	Fri Sep 04 23:51:26 2020
> > -0400
> > +++ b/test/jdk/java/lang/module/VersionTest.java	Wed Oct 28 17:06:47
> > 2020 +0900
> > @@ -148,6 +148,8 @@
> >              { "1",             "1.0.0" },
> >              { "1.0",           "1.0.0" },
> >              { "1.0-beta",      "1.0.0-beta" },
> > +            { "1.0-1.1",       "1.0-1..1" },
> > +            { "1.0-1+1",       "1.0-1.+1" },
> >
> >          };
> >      }
> >
> > Regards,
> > Masanori Yano

From abakhtin at openjdk.java.net  Thu Jan 14 19:33:09 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Thu, 14 Jan 2021 19:33:09 GMT
Subject: RFR: 8259707: LDAP channel binding does not work with StartTLS
 extension
Message-ID: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>

Please review a small patch to enable LDAP TLS Channel Binding with StartTLS Extension.
Test from the bug report and jtreg javax/naming tests are passed.

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

Commit messages:
 - 8259707: LDAP channel binding does not work with StartTLS extension

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

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

From plevart at openjdk.java.net  Thu Jan 14 22:42:07 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Thu, 14 Jan 2021 22:42:07 GMT
Subject: RFR: 8193031: Collections.addAll is likely to perform worse than
 Collection.addAll [v7]
In-Reply-To: <9d7U4WiWGceuNVbh4TRHi7DpKBQNF0mCw_b-RrHb_aE=.fdb7ba7b-1a51-4be0-bbb7-dd47097fc93e@github.com>
References: <TB3epXzVEKg86PLsoPvHgfKAC2XHrLGCH2ZsuCJw2h4=.c75b4032-abb7-4f95-b19e-65788727f049@github.com>
 <9d7U4WiWGceuNVbh4TRHi7DpKBQNF0mCw_b-RrHb_aE=.fdb7ba7b-1a51-4be0-bbb7-dd47097fc93e@github.com>
Message-ID: <qkjDRjYRQgfKgiqmlA_7JXs7TMmbPD9wPz3Hkp6eTVA=.9ca4a18c-0b6d-41d7-b77c-5a268f53f744@github.com>

On Thu, 14 Jan 2021 15:25:25 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Hello, I feel like this was previously discussed in https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot find original mail I post this here.
>> 
>> Currently `Collections.addAll()` is implemented and documented as:
>>     /**
>>      * ...
>>      * The behavior of this convenience method is identical to that of
>>      * {@code c.addAll(Arrays.asList(elements))}, but this method is likely
>>      * to run significantly faster under most implementations.
>>      */
>>     @SafeVarargs
>>     public static <T> boolean addAll(Collection<? super T> c, T... elements) {
>>         boolean result = false;
>>         for (T element : elements)
>>             result |= c.add(element);
>>         return result;
>>     }
>> 
>> But it practice the notation `this method is likely to run significantly faster under most implementations` is completely wrong. When I take this [benchmark](https://github.com/stsypanov/benchmarks/blob/master/benchmark-runners/src/main/java/com/luxoft/logeek/benchmark/collection/CollectionsAddAllVsAddAllBenchmark.java) and run it on JDK 14 I get the following results:
>>                                                    (collection)  (size)      Score     Error   Units
>> addAll                                                ArrayList      10       37.9 ?     1.9   ns/op
>> addAll                                                ArrayList     100       83.8 ?     3.4   ns/op
>> addAll                                                ArrayList    1000      678.2 ?    23.0   ns/op
>> collectionsAddAll                                     ArrayList      10       50.9 ?     1.1   ns/op
>> collectionsAddAll                                     ArrayList     100      751.4 ?    47.4   ns/op
>> collectionsAddAll                                     ArrayList    1000     8839.8 ?   710.7   ns/op
>> 
>> addAll                                                  HashSet      10      128.4 ?     5.9   ns/op
>> addAll                                                  HashSet     100     1864.2 ?   102.4   ns/op
>> addAll                                                  HashSet    1000    16615.5 ?  1202.6   ns/op
>> collectionsAddAll                                       HashSet      10      172.8 ?     6.0   ns/op
>> collectionsAddAll                                       HashSet     100     2355.8 ?   195.4   ns/op
>> collectionsAddAll                                       HashSet    1000    20364.7 ?  1164.0   ns/op
>> 
>> addAll                                               ArrayDeque      10       54.0 ?     0.4   ns/op
>> addAll                                               ArrayDeque     100      319.7 ?     2.5   ns/op
>> addAll                                               ArrayDeque    1000     3176.9 ?    22.2   ns/op
>> collectionsAddAll                                    ArrayDeque      10       66.5 ?     1.4   ns/op
>> collectionsAddAll                                    ArrayDeque     100      808.1 ?    55.9   ns/op
>> collectionsAddAll                                    ArrayDeque    1000     5639.6 ?   240.9   ns/op
>> 
>> addAll                                     CopyOnWriteArrayList      10       18.0 ?     0.7   ns/op
>> addAll                                     CopyOnWriteArrayList     100       39.4 ?     1.7   ns/op
>> addAll                                     CopyOnWriteArrayList    1000      371.1 ?    17.0   ns/op
>> collectionsAddAll                          CopyOnWriteArrayList      10      251.9 ?    18.4   ns/op
>> collectionsAddAll                          CopyOnWriteArrayList     100     3405.9 ?   304.8   ns/op
>> collectionsAddAll                          CopyOnWriteArrayList    1000   247496.8 ? 23502.3   ns/op
>> 
>> addAll                                    ConcurrentLinkedDeque      10       81.4 ?     2.8   ns/op
>> addAll                                    ConcurrentLinkedDeque     100      609.1 ?    26.4   ns/op
>> addAll                                    ConcurrentLinkedDeque    1000     4494.5 ?   219.3   ns/op
>> collectionsAddAll                         ConcurrentLinkedDeque      10      189.8 ?     2.5   ns/op
>> collectionsAddAll                         ConcurrentLinkedDeque     100     1660.0 ?    62.0   ns/op
>> collectionsAddAll                         ConcurrentLinkedDeque    1000    17649.2 ?   300.9   ns/op
>> 
>> addAll:?gc.alloc.rate.norm                            ArrayList      10      160.0 ?     0.0    B/op
>> addAll:?gc.alloc.rate.norm                            ArrayList     100      880.0 ?     0.0    B/op
>> addAll:?gc.alloc.rate.norm                            ArrayList    1000     8080.3 ?     0.0    B/op
>> collectionsAddAll:?gc.alloc.rate.norm                 ArrayList      10       80.0 ?     0.0    B/op
>> collectionsAddAll:?gc.alloc.rate.norm                 ArrayList     100     1400.2 ?     0.0    B/op
>> collectionsAddAll:?gc.alloc.rate.norm                 ArrayList    1000    15025.6 ?     0.1    B/op
>> 
>> addAll:?gc.alloc.rate.norm                              HashSet      10      464.0 ?     0.0    B/op
>> addAll:?gc.alloc.rate.norm                              HashSet     100     5328.5 ?     0.0    B/op
>> addAll:?gc.alloc.rate.norm                              HashSet    1000    48516.7 ?     0.1    B/op
>> collectionsAddAll:?gc.alloc.rate.norm                   HashSet      10      464.0 ?     0.0    B/op
>> collectionsAddAll:?gc.alloc.rate.norm                   HashSet     100     5328.5 ?     0.0    B/op
>> collectionsAddAll:?gc.alloc.rate.norm                   HashSet    1000    48516.6 ?     0.1    B/op
>> 
>> addAll:?gc.alloc.rate.norm                           ArrayDeque      10      112.0 ?     0.0    B/op
>> addAll:?gc.alloc.rate.norm                           ArrayDeque     100      560.0 ?     0.0    B/op
>> addAll:?gc.alloc.rate.norm                           ArrayDeque    1000     4160.5 ?     0.0    B/op
>> collectionsAddAll:?gc.alloc.rate.norm                ArrayDeque      10      112.0 ?     0.0    B/op
>> collectionsAddAll:?gc.alloc.rate.norm                ArrayDeque     100     1048.1 ?     0.0    B/op
>> collectionsAddAll:?gc.alloc.rate.norm                ArrayDeque    1000    14929.4 ?     0.0    B/op
>> 
>> addAll:?gc.alloc.rate.norm                 CopyOnWriteArrayList      10       88.0 ?     0.0    B/op
>> addAll:?gc.alloc.rate.norm                 CopyOnWriteArrayList     100      448.0 ?     0.0    B/op
>> addAll:?gc.alloc.rate.norm                 CopyOnWriteArrayList    1000     4048.1 ?     0.0    B/op
>> collectionsAddAll:?gc.alloc.rate.norm      CopyOnWriteArrayList      10      456.0 ?     0.0    B/op
>> collectionsAddAll:?gc.alloc.rate.norm      CopyOnWriteArrayList     100    22057.2 ?     0.0    B/op
>> collectionsAddAll:?gc.alloc.rate.norm      CopyOnWriteArrayList    1000  2020150.3 ?     7.3    B/op
>> 
>> addAll:?gc.alloc.rate.norm                ConcurrentLinkedDeque      10      312.0 ?     0.0    B/op
>> addAll:?gc.alloc.rate.norm                ConcurrentLinkedDeque     100     2472.1 ?     0.0    B/op
>> addAll:?gc.alloc.rate.norm                ConcurrentLinkedDeque    1000    24073.7 ?     0.1    B/op
>> collectionsAddAll:?gc.alloc.rate.norm     ConcurrentLinkedDeque      10      288.0 ?     0.0    B/op
>> collectionsAddAll:?gc.alloc.rate.norm     ConcurrentLinkedDeque     100     2448.3 ?     0.0    B/op
>> collectionsAddAll:?gc.alloc.rate.norm     ConcurrentLinkedDeque    1000    24051.4 ?     0.3    B/op
>> There's never a case when `Collections.addAll` is fater - on the contrary `c.addAll(Arrays.asList())` always wins. Pay attention especially to dramatic difference for array-based collection.
>> 
>> So I propose to reimplement the method by simply delegating to `Arrays.asList` because the spec declares identical behaviour and to remove perfomance notation from JavaDoc.
>
> ?????? ??????? 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 add-all
>  - 8193031: fix JavaDoc
>  - Merge branch 'master' into add-all
>  - Merge branch 'master' into add-all
>  - 8193031: revert implementation change but keep one for JavaDoc
>  - Merge branch 'master' into add-all
>  - Merge remote-tracking branch 'origin/add-all' into add-all
>  - 8193031: add elements in bulk in Collections.addAll()
>  - Merge branch 'master' into add-all
>  - 8193031: add elements in bulk in Collections.addAll()

I think this looks good.

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

Marked as reviewed by plevart (Reviewer).

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

From smarks at openjdk.java.net  Thu Jan 14 23:28:04 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 14 Jan 2021 23:28:04 GMT
Subject: RFR: 8259622: TreeMap.computeIfAbsent deviates from spec
In-Reply-To: <kltUEUk_zHC1CS9hSlLJdbhr9uMKqMpEMx5FOLz1Y3M=.104e4a8d-2cdc-428b-9922-4222003e9131@github.com>
References: <kltUEUk_zHC1CS9hSlLJdbhr9uMKqMpEMx5FOLz1Y3M=.104e4a8d-2cdc-428b-9922-4222003e9131@github.com>
Message-ID: <72AMFnMQBXBsmWZ3xwIviqy22VJbWhsc8kCQS5zM4GM=.7f49af87-670d-4116-a047-9cde97fa04b2@github.com>

On Wed, 13 Jan 2021 09:51:01 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> Handle TreeMap::computeIfAbsent when previous mapping with null value existed (in this case spec requires to overwrite the existing mapping)

Marked as reviewed by smarks (Reviewer).

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

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

From smarks at openjdk.java.net  Thu Jan 14 23:28:05 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 14 Jan 2021 23:28:05 GMT
Subject: RFR: 8259622: TreeMap.computeIfAbsent deviates from spec
In-Reply-To: <72AMFnMQBXBsmWZ3xwIviqy22VJbWhsc8kCQS5zM4GM=.7f49af87-670d-4116-a047-9cde97fa04b2@github.com>
References: <kltUEUk_zHC1CS9hSlLJdbhr9uMKqMpEMx5FOLz1Y3M=.104e4a8d-2cdc-428b-9922-4222003e9131@github.com>
 <72AMFnMQBXBsmWZ3xwIviqy22VJbWhsc8kCQS5zM4GM=.7f49af87-670d-4116-a047-9cde97fa04b2@github.com>
Message-ID: <SDuL8AmktiqBuTQZodC5buDWHnG3AdisiQuZvLbUD5Y=.b3201615-2abe-4f4a-9df6-258d5031e967@github.com>

On Thu, 14 Jan 2021 23:25:22 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Handle TreeMap::computeIfAbsent when previous mapping with null value existed (in this case spec requires to overwrite the existing mapping)
>
> Marked as reviewed by smarks (Reviewer).

Thanks for picking this up. Changes look good. Please update copyright years if you get a chance.

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

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

From ljiang at openjdk.java.net  Fri Jan 15 02:02:11 2021
From: ljiang at openjdk.java.net (Leo Jiang)
Date: Fri, 15 Jan 2021 02:02:11 GMT
Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg
 drop 10 [v2]
In-Reply-To: <ZkHoKP8fL7uRj0TIiwqYtVch0eyxQGv2JeY-BDgf310=.91ef28d1-d91b-4b37-aa9f-edd81b94f235@github.com>
References: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
 <QceWk9N7q2iV9alfICITS0Sdr8eacuR15Mrihph-doI=.1cee427c-0be1-4cb9-8a77-098696ddd5da@github.com>
 <ZkHoKP8fL7uRj0TIiwqYtVch0eyxQGv2JeY-BDgf310=.91ef28d1-d91b-4b37-aa9f-edd81b94f235@github.com>
Message-ID: <1Bb8sf6zFDnQSM5kRQIlrgBNwEpO-IvxsPmN05F0QFs=.13eb3035-71d5-4310-98e5-d9989e51cf60@github.com>

On Thu, 14 Jan 2021 17:19:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Leo Jiang 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:
>> 
>>  - Merge branch 'master' into msgdrop
>>  - JDK-8259732: JDK 16 L10n resource file update - msg drop 10
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 518:
> 
>> 516: doclet.footer_specified=\
>> 517:     The -footer option is no longer supported and will be ignored.\n\
>> 518:     It may be removed in a future release.
> 
> I believe this is to fix no newline at the end (unrelated to l10n changes). Do we need to change the copyright year for this?

Actually I was correcting the L217, changed {) -> {}. But 2 days ago, Jonathan Gibbons fixed it in another commit 6bb6093. I found his fix after running the merge. Looks both of us forgot to update the copyright year. Any suggestion? 
doclet.help.systemProperties.body=\
    The {0} page lists references to system properties.

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

PR: https://git.openjdk.java.net/jdk16/pull/123

From tvaleev at openjdk.java.net  Fri Jan 15 04:04:16 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Fri, 15 Jan 2021 04:04:16 GMT
Subject: RFR: 8259622: TreeMap.computeIfAbsent deviates from spec [v2]
In-Reply-To: <kltUEUk_zHC1CS9hSlLJdbhr9uMKqMpEMx5FOLz1Y3M=.104e4a8d-2cdc-428b-9922-4222003e9131@github.com>
References: <kltUEUk_zHC1CS9hSlLJdbhr9uMKqMpEMx5FOLz1Y3M=.104e4a8d-2cdc-428b-9922-4222003e9131@github.com>
Message-ID: <1meDKwSuYYyrXKlIe5zdmq7L_Uf8dfkvEfor4aQVOZg=.afc8fb52-cce1-40a1-b1ef-48163e84cbd8@github.com>

> Handle TreeMap::computeIfAbsent when previous mapping with null value existed (in this case spec requires to overwrite the existing mapping)

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Copyright year updated

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2058/files
  - new: https://git.openjdk.java.net/jdk/pull/2058/files/8f63db72..906619e1

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

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

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

From tvaleev at openjdk.java.net  Fri Jan 15 04:15:03 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Fri, 15 Jan 2021 04:15:03 GMT
Subject: Integrated: 8259622: TreeMap.computeIfAbsent deviates from spec
In-Reply-To: <kltUEUk_zHC1CS9hSlLJdbhr9uMKqMpEMx5FOLz1Y3M=.104e4a8d-2cdc-428b-9922-4222003e9131@github.com>
References: <kltUEUk_zHC1CS9hSlLJdbhr9uMKqMpEMx5FOLz1Y3M=.104e4a8d-2cdc-428b-9922-4222003e9131@github.com>
Message-ID: <xiz2ArZZTtnBUJ2vJ-1kE99kLlUsfSlXeCTgouPUC2g=.ddca0de3-43f8-45a6-b1f6-c6963aa2754f@github.com>

On Wed, 13 Jan 2021 09:51:01 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> Handle TreeMap::computeIfAbsent when previous mapping with null value existed (in this case spec requires to overwrite the existing mapping)

This pull request has now been integrated.

Changeset: 2c8e337d
Author:    Tagir F. Valeev <tvaleev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2c8e337d
Stats:     26 lines in 2 files changed: 22 ins; 0 del; 4 mod

8259622: TreeMap.computeIfAbsent deviates from spec

Reviewed-by: smarks

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

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

From sundar at openjdk.java.net  Fri Jan 15 05:25:08 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Fri, 15 Jan 2021 05:25:08 GMT
Subject: RFR: 8259814: test/jdk/tools/jlink/plugins/CompressorPluginTest.java
 has compilation issues
Message-ID: <o9dC306S7bJYorAEwiU5WwMl2NSckb908gqcHzXc_iY=.b20f22eb-75b0-45d2-b200-ed535fb9e58c@github.com>

Fixed compilation issues with the test. Test compiles and runs fine locally.

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

Commit messages:
 - 8259814: test/jdk/tools/jlink/plugins/CompressorPluginTest.java has compilation issues

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

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

From github.com+1059453+fleshgrinder at openjdk.java.net  Fri Jan 15 07:18:06 2021
From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger)
Date: Fri, 15 Jan 2021 07:18:06 GMT
Subject: RFR: 6594730: UUID.getVersion() is only meaningful for Leach-Salz
 variant
In-Reply-To: <XpuiVvswA_J3jLetunUIfdkpDDMNTlkwpvySsTZdyGw=.e28d519b-ca8b-4fe6-87ca-55e08d291d75@github.com>
References: <NfEhSpKiiOh0bt2ociNETgE8wpvJDbxna_y5dwKY4_k=.cd887be7-2684-4508-9f04-a706af928f1e@github.com>
 <fT9Tnqqzj_C83M9toCHtt8FXl-pzhvHFpVdjhev0jpQ=.ec5a8244-fc48-4908-ae42-a52d9baedb40@github.com>
 <3-wkodUcgfRa4uO368j9YI94T7pVj0waG5fryDD1rzU=.c709490e-58f0-4a01-8bd5-b516c4be4ab5@github.com>
 <oETxWo27EDHD-O9QJ2EI9t3RuGRtxeVmJ1TX6JI-E34=.efad802f-4b36-42d6-b5a0-330c1cd6eb57@github.com>
 <E1OjJl_zjZi9enH7mvSW4-lmUB5AbS21NJvMXsXHRbk=.124f3484-dff7-4083-af97-3e5efb1dee2b@github.com>
 <XpuiVvswA_J3jLetunUIfdkpDDMNTlkwpvySsTZdyGw=.e28d519b-ca8b-4fe6-87ca-55e08d291d75@github.com>
Message-ID: <usbfTdI6GC5WZrVg-Ievu8YvuRwMa4nodkxR0FQmNxo=.846d01b8-c341-4b8b-81f3-b5107aca733c@github.com>

On Thu, 17 Dec 2020 22:16:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I cannot create CSRs, only members can. Deprecating and switching to another function results in much more work for users overall because it affects all those who use it correctly as well. In other words: 100%
>> 
>> I'm in favor of rejection if that's the way forward.
>> 
>> What's wrong with creating PRs for existing issues? I thought that more contributions is actually the reason OpenJDK came to GitHub. ??
>
> Often an enhancement is created when there's an idea of an improvement but no resources to do the research and develop a justification. That work has to be done when someone has time.  Usually ideas are discussed on one of the many OpenJDK email aliases to validate the idea and the approach before developing the code. See the list of OpenJDK Mail lists for details.
> https://mail.openjdk.java.net/mailman/listinfo
> As for moving to GitHub,  it was in part to make it easier to collaborate on the development but also to move from Mercurial to Git.
> But GitHub does not replace the need for discussion on the Email Lists.

Active

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

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

From alanb at openjdk.java.net  Fri Jan 15 07:40:03 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 15 Jan 2021 07:40:03 GMT
Subject: RFR: 8259814:
 test/jdk/tools/jlink/plugins/CompressorPluginTest.java has compilation issues
In-Reply-To: <o9dC306S7bJYorAEwiU5WwMl2NSckb908gqcHzXc_iY=.b20f22eb-75b0-45d2-b200-ed535fb9e58c@github.com>
References: <o9dC306S7bJYorAEwiU5WwMl2NSckb908gqcHzXc_iY=.b20f22eb-75b0-45d2-b200-ed535fb9e58c@github.com>
Message-ID: <xQOWrDaLqx_khEzqWZNhf7MMEYwRzIUfZdMOnf04vc4=.f28216c6-91d6-4f1e-b27b-2e54c1bcfe1d@github.com>

On Fri, 15 Jan 2021 05:19:44 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Fixed compilation issues with the test. Test compiles and runs fine locally.

Are you going to remove it from the exclude list (test/jdk/ProblemList.txt)? I skimmed through the changes and it looks fine but would like confirmation that it has been run many times on all platforms (some of the jlink tests have taken time to get stable).

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

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

From kravikumar at openjdk.java.net  Fri Jan 15 10:24:24 2021
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Fri, 15 Jan 2021 10:24:24 GMT
Subject: RFR: 8259048: (tz) Upgrade time-zone data to tzdata2020f [v2]
In-Reply-To: <9Vhqq8tJSSFttfpVHRl2YMj8DHXs8IhYajW61wQbMhs=.a9a11b2e-9b08-474c-a1cb-cbfa34b4c0d2@github.com>
References: <9Vhqq8tJSSFttfpVHRl2YMj8DHXs8IhYajW61wQbMhs=.a9a11b2e-9b08-474c-a1cb-cbfa34b4c0d2@github.com>
Message-ID: <YbK8VQOi3ZKu3HgEvk-fovKdLD3p_KbHuwDMoyMYzIc=.508f630f-8a87-4e82-a8c0-03444653d6ec@github.com>

> Hi Guys,
> 
> Please review the integration of tzdata2020e to JDK.
> 
> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-December/000063.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258878
> 
> Most of the changes are about correcting past timestamps and Australia/Currie timezone is removed.
> 
> Regression Tests pass along with JCK.
> 
> Please let me know if the changes are good to push.
> 
> Thanks,
> Kiran

Kiran Sidhartha Ravikumar 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:

 - 8258878: (tz) Upgrade time-zone data to tzdata2020e
 - Merge remote-tracking branch 'origin/master' into JDK-8258878
 - 8258878: (tz) Upgrade time-zone data to tzdata2020e

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1937/files
  - new: https://git.openjdk.java.net/jdk/pull/1937/files/a89ac891..4e18e930

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

  Stats: 46333 lines in 1566 files changed: 19748 ins; 13335 del; 13250 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1937.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1937/head:pull/1937

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

From kravikumar at openjdk.java.net  Fri Jan 15 10:30:04 2021
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Fri, 15 Jan 2021 10:30:04 GMT
Subject: RFR: 8259048: (tz) Upgrade time-zone data to tzdata2020f [v2]
In-Reply-To: <7r3wdiUnqGu6e_8opiRMohNAHmpacTreFd9w16bizpw=.39cb08c2-1a7d-4ced-a425-0062c0d9f181@github.com>
References: <9Vhqq8tJSSFttfpVHRl2YMj8DHXs8IhYajW61wQbMhs=.a9a11b2e-9b08-474c-a1cb-cbfa34b4c0d2@github.com>
 <7r3wdiUnqGu6e_8opiRMohNAHmpacTreFd9w16bizpw=.39cb08c2-1a7d-4ced-a425-0062c0d9f181@github.com>
Message-ID: <-dU_rmFohK04hI4Be9v_Xa8sVd_0EAO9DSF4nVBJRnw=.2aaf5f59-4971-4299-81c6-fd7d5c7e59a9@github.com>

On Mon, 4 Jan 2021 18:40:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Looks good.
> IIUC, 2020f is already out, and the 2020e-2020f diff does not seem to include any data change. Would you change this PR to incorporate 2020f?

Hi @naotoj ,

I have updated the VERSION and PR title to incorporate tzdata2020f, please let me know if the changes are good to push.

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

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

From tludwig at vmware.com  Fri Jan 15 10:51:42 2021
From: tludwig at vmware.com (Tommy Ludwig)
Date: Fri, 15 Jan 2021 10:51:42 +0000
Subject: Monitoring wrapped ThreadPoolExecutor returned from Executors
In-Reply-To: <347c5e67-69b4-9bd5-89ba-34efbfcb5baa@cs.oswego.edu>
References: <BYAPR05MB65998619D6784F8FB6E13700DFD00@BYAPR05MB6599.namprd05.prod.outlook.com>
 <fa7f2656-c249-688f-5215-626a2250b22c@cs.oswego.edu>
 <SN7PR18MB40165BE278DEA37BB110363483AF9@SN7PR18MB4016.namprd18.prod.outlook.com>
 <347c5e67-69b4-9bd5-89ba-34efbfcb5baa@cs.oswego.edu>
Message-ID: <BC58DB1E-C5E9-430C-8409-2452CB6579A1@vmware.com>

Parsing the delegate toString would be a usable workaround for the time being for Micrometer, assuming the format is stable across JDK versions. It's better than no alternative, which is where I think we are currently at for the wrapped cases.

?On 2021/01/09 1:24, "Doug Lea" <dl at cs.oswego.edu> wrote:

    On 1/7/21 12:57 PM, Jason Mehrens wrote:
    > Hi Doug,
    >
    > What are your thoughts on promoting monitoring methods from TPE and or FJP to AbstractExecutorService?  The default implementations could just return -1.  An example precedent is OperatingSystemMXBean::getSystemLoadAverage.  The Executors.DelegatedExecutorService could then be modified to extend AbstractExecutorService and forward the new methods and the existing AES::taskFor calls when the wrapped Executor is also an AbstractExecutorService.  The return types of the Executors.newXXX would remain the same.

    Maybe. But for now, here's a cheap trick that might be tolerable: Add to 
    DelegatedExecutorService:

    public String toString() { return e.toString(); }

    The juc executors (ThreadPoolExecutor and ForkJoinPool that could be 
    wrapped here) both print pool size, active threads, queued tasks, and 
    completed tasks. It would require not-very-pleasant string parsing in 
    monitoring tools, but this might be good enough for Micrometer and others?


    >
    > I suppose the tradeoff is that adding any new default method to ExecutorService and or new methods to AbstractExecutorService could break 3rd party code.
    >
    > Jason
    >
    > ________________________________________
    > From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of Doug Lea <dl at cs.oswego.edu>
    > Sent: Thursday, January 7, 2021 7:09 AM
    > To: core-libs-dev at openjdk.java.net
    > Subject: Re: Monitoring wrapped ThreadPoolExecutor returned from Executors
    >
    > On 1/5/21 10:11 PM, Tommy Ludwig wrote:
    >> In the Micrometer project, we provide metrics instrumentation of `ExectorService`s. For `ThreadPoolExecutor`s, we track the number of completed tasks, active tasks, thread pool sizes, task queue size and remaining capacity via methods from `ThreadPoolExecutor`. We are currently using a brittle reflection hack[1] to do this for the wrapped `ThreadPoolExecutor` returned from `Executors` methods `newSingleThreadExecutor` and `newSingleThreadScheduledExecutor`. With the introduction of JEP-396 in JDK 16, our reflection hack throws an InaccessibleObjectException by default.
    >>
    >> I am not seeing a proper way to get at the methods we use for the metrics (e.g. `ThreadPoolExecutor::getCompletedTaskCount`) in this case. Is there a way that I am missing?
    > There's no guarantee that newSingleThreadExecutor returns a restricted
    > view of a ThreadPoolExecutor, so there can't be a guaranteed way of
    > accessing it,
    >
    > But I'm sympathetic to the idea that under the current implementation
    > (which is unlikely to change anytime soon), the stats are available, and
    > should be available to monitoring tools. But none of the ways to do this
    > are very attractive: Creating a MonitorableExecutorService interface and
    > returning that? Making the internal view class public with a protected
    > getExecutor method?
    >
    >



From alanb at openjdk.java.net  Fri Jan 15 15:01:09 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 15 Jan 2021 15:01:09 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v4]
In-Reply-To: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>
 <YT7on7W1w9GJRTMfz2KtftKo7yGbVTgZxYcqXv1POBU=.59b49a13-da41-4c93-88c7-1830b87d0b63@github.com>
 <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com>
Message-ID: <ABB2Pleoo1GTfmn0SdjrztH_u6VrfPRseLfMIrYhMdg=.a576b5bc-b25b-43ee-b5d3-394bce1415ca@github.com>

On Mon, 11 Jan 2021 09:20:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Marked as reviewed by prr (Reviewer).
>
> This PR is not stale; it's just still waiting for input from @AlanBateman.

@magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang?

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

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

From redestad at openjdk.java.net  Fri Jan 15 15:09:13 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 15 Jan 2021 15:09:13 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding
Message-ID: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>

The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.

This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.

Microbenchmark results:
Baseline

Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op

Patched:
Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op

Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.

Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.

Testing: tier1-4

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

Commit messages:
 - Remove unused imports
 - Merge branch 'master' into sc_tl_exp
 - Fix charset names in micro settings
 - Refactor charset lookups to ensure expected exceptions are thrown on null, foo etc
 - Cleanup includes etc
 - Cleanups, minor improvements
 - More micro fixes
 - resolve merge
 - Fix micro
 - Add simple StringDecode micro
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/707bce08...f14826b1

Changes: https://git.openjdk.java.net/jdk/pull/2102/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2102&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259842
  Stats: 1170 lines in 4 files changed: 592 ins; 543 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2102.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2102/head:pull/2102

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

From some-java-user-99206970363698485155 at vodafonemail.de  Fri Jan 15 15:29:21 2021
From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de)
Date: Fri, 15 Jan 2021 16:29:21 +0100 (CET)
Subject: RFR: 6594730: UUID.getVersion() is only meaningful for
 Leach-Salz variant
In-Reply-To: <usbfTdI6GC5WZrVg-Ievu8YvuRwMa4nodkxR0FQmNxo=.846d01b8-c341-4b8b-81f3-b5107aca733c@github.com>
References: <NfEhSpKiiOh0bt2ociNETgE8wpvJDbxna_y5dwKY4_k=.cd887be7-2684-4508-9f04-a706af928f1e@github.com>
 <fT9Tnqqzj_C83M9toCHtt8FXl-pzhvHFpVdjhev0jpQ=.ec5a8244-fc48-4908-ae42-a52d9baedb40@github.com>
 <3-wkodUcgfRa4uO368j9YI94T7pVj0waG5fryDD1rzU=.c709490e-58f0-4a01-8bd5-b516c4be4ab5@github.com>
 <oETxWo27EDHD-O9QJ2EI9t3RuGRtxeVmJ1TX6JI-E34=.efad802f-4b36-42d6-b5a0-330c1cd6eb57@github.com>
 <E1OjJl_zjZi9enH7mvSW4-lmUB5AbS21NJvMXsXHRbk=.124f3484-dff7-4083-af97-3e5efb1dee2b@github.com>
 <XpuiVvswA_J3jLetunUIfdkpDDMNTlkwpvySsTZdyGw=.e28d519b-ca8b-4fe6-87ca-55e08d291d75@github.com>
 <usbfTdI6GC5WZrVg-Ievu8YvuRwMa4nodkxR0FQmNxo=.846d01b8-c341-4b8b-81f3-b5107aca733c@github.com>
Message-ID: <505987923.399783.1610724561114@mail.vodafone.de>

The following probably does not matter much because I am not an OpenJDK contributor, but personally
I think throwing an UnsupportedOperationException is reasonable:
  1. It is consistent with the other methods which also only work for one specific variant
  2. Code which calls UUID.version() on a non-variant 2 UUID is obviously already functionally broken;
     I don't think maintaining backward compatibility here adds any value

Regarding the pull request, I would recommend the following changes:
  1. Replace `&nbsp;` with a normal space, that should work as well and is easier to read
  2. Add a sentence to the method description (and not only to the `@throws` tag), that this method
     is only meaningful for variant 2 UUIDs, see for example the documentation for `timestamp()` for
     how this sentence should look like to be consistent:
     https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/UUID.html#timestamp()

Kind regards

From Alan.Bateman at oracle.com  Fri Jan 15 15:35:09 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 15 Jan 2021 15:35:09 +0000
Subject: Monitoring wrapped ThreadPoolExecutor returned from Executors
In-Reply-To: <BC58DB1E-C5E9-430C-8409-2452CB6579A1@vmware.com>
References: <BYAPR05MB65998619D6784F8FB6E13700DFD00@BYAPR05MB6599.namprd05.prod.outlook.com>
 <fa7f2656-c249-688f-5215-626a2250b22c@cs.oswego.edu>
 <SN7PR18MB40165BE278DEA37BB110363483AF9@SN7PR18MB4016.namprd18.prod.outlook.com>
 <347c5e67-69b4-9bd5-89ba-34efbfcb5baa@cs.oswego.edu>
 <BC58DB1E-C5E9-430C-8409-2452CB6579A1@vmware.com>
Message-ID: <4e006235-618c-f7fe-8596-bec68c0f54c2@oracle.com>

On 15/01/2021 10:51, Tommy Ludwig wrote:
> Parsing the delegate toString would be a usable workaround for the time being for Micrometer, assuming the format is stable across JDK versions. It's better than no alternative, which is where I think we are currently at for the wrapped cases.
As a temporary workaround you can use --add-opens to open 
java.base/java.util.concurrent. That will keep existing hacks working 
until you have something better.

Given the importance of specific thread pools in some applications then 
there may be merit exploring a management interface 
(PlatformManagedObject) that would exposes some stats. This could allow 
both local and remote tooling to monitor/sample the stats of interesting 
thread pools.

-Alan


From some-java-user-99206970363698485155 at vodafonemail.de  Fri Jan 15 15:53:14 2021
From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de)
Date: Fri, 15 Jan 2021 16:53:14 +0100 (CET)
Subject: RFR: 6594730: UUID.getVersion() is only meaningful for
 Leach-Salz variant
In-Reply-To: <505987923.399783.1610724561114@mail.vodafone.de>
References: <NfEhSpKiiOh0bt2ociNETgE8wpvJDbxna_y5dwKY4_k=.cd887be7-2684-4508-9f04-a706af928f1e@github.com>
 <fT9Tnqqzj_C83M9toCHtt8FXl-pzhvHFpVdjhev0jpQ=.ec5a8244-fc48-4908-ae42-a52d9baedb40@github.com>
 <3-wkodUcgfRa4uO368j9YI94T7pVj0waG5fryDD1rzU=.c709490e-58f0-4a01-8bd5-b516c4be4ab5@github.com>
 <oETxWo27EDHD-O9QJ2EI9t3RuGRtxeVmJ1TX6JI-E34=.efad802f-4b36-42d6-b5a0-330c1cd6eb57@github.com>
 <E1OjJl_zjZi9enH7mvSW4-lmUB5AbS21NJvMXsXHRbk=.124f3484-dff7-4083-af97-3e5efb1dee2b@github.com>
 <XpuiVvswA_J3jLetunUIfdkpDDMNTlkwpvySsTZdyGw=.e28d519b-ca8b-4fe6-87ca-55e08d291d75@github.com>
 <usbfTdI6GC5WZrVg-Ievu8YvuRwMa4nodkxR0FQmNxo=.846d01b8-c341-4b8b-81f3-b5107aca733c@github.com>
 <505987923.399783.1610724561114@mail.vodafone.de>
Message-ID: <1848166151.399932.1610725994230@mail.vodafone.de>

>   1. Replace ` ` with a normal space, that should work as well and is easier to read
Looks like my e-mail client was so kind and replaced the HTML character reference. It should have said:
"Replace `& nbsp ;` with a normal space, ..."

Additionally, if you want to search for projects using UUID.version() you can use the following
CodeQL query:
https://lgtm.com/query/283083268427438766/

You can (in addition to the example projects), specify custom projects to scan as well, see
https://lgtm.com/help/lgtm/project-lists.

Kind regards

From rriggs at openjdk.java.net  Fri Jan 15 16:53:01 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 15 Jan 2021 16:53:01 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding
In-Reply-To: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
Message-ID: <RyCTOVjgM1OozoFu-b9h4xCWtBBDvtgKh0q06XAj4C8=.834872da-a05c-46ae-bbb0-a56568181da4@github.com>

On Fri, 15 Jan 2021 14:33:19 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.
> 
> This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.
> 
> Microbenchmark results:
> Baseline
> 
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
> decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op
> 
> Patched:
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
> decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op
> 
> Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.
> 
> Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.
> 
> Testing: tier1-4

Interesting, I was/am in the middle of converting Result to be a Valhalla primitive class to reduce the memory pressure and had written some new jmh tests too.
And to reduce the dependency on ThreadLocals.

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

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

From naoto at openjdk.java.net  Fri Jan 15 17:18:10 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 15 Jan 2021 17:18:10 GMT
Subject: RFR: 8259048: (tz) Upgrade time-zone data to tzdata2020f [v2]
In-Reply-To: <YbK8VQOi3ZKu3HgEvk-fovKdLD3p_KbHuwDMoyMYzIc=.508f630f-8a87-4e82-a8c0-03444653d6ec@github.com>
References: <9Vhqq8tJSSFttfpVHRl2YMj8DHXs8IhYajW61wQbMhs=.a9a11b2e-9b08-474c-a1cb-cbfa34b4c0d2@github.com>
 <YbK8VQOi3ZKu3HgEvk-fovKdLD3p_KbHuwDMoyMYzIc=.508f630f-8a87-4e82-a8c0-03444653d6ec@github.com>
Message-ID: <89CktvFP3WHDhz2e7k3d67LWLV4wq7Oj1HBMwuKmxtI=.0333efae-92ec-448f-91c2-60f827f4e4b6@github.com>

On Fri, 15 Jan 2021 10:24:24 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

>> Hi Guys,
>> 
>> Updating the summary as tzdata2020f is available and includes tzdata2020e changes also.
>> 
>> Please review the integration of tzdata2020f to JDK.
>> 
>> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-December/000064.html
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8259048
>> 
>> tzdata2020e - Most of the changes are about correcting past timestamps and Australia/Currie timezone is removed.
>> tzdata2020f - No changes to the data since 2020e.
>> 
>> Regression Tests pass along with JCK.
>> 
>> Please let me know if the changes are good to push.
>> 
>> Thanks,
>> Kiran
>
> Kiran Sidhartha Ravikumar 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:
> 
>  - 8258878: (tz) Upgrade time-zone data to tzdata2020e
>  - Merge remote-tracking branch 'origin/master' into JDK-8258878
>  - 8258878: (tz) Upgrade time-zone data to tzdata2020e

Marked as reviewed by naoto (Reviewer).

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

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

From plevart at openjdk.java.net  Fri Jan 15 17:41:07 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 15 Jan 2021 17:41:07 GMT
Subject: RFR: 8193031: Collections.addAll is likely to perform worse than
 Collection.addAll [v7]
In-Reply-To: <qkjDRjYRQgfKgiqmlA_7JXs7TMmbPD9wPz3Hkp6eTVA=.9ca4a18c-0b6d-41d7-b77c-5a268f53f744@github.com>
References: <TB3epXzVEKg86PLsoPvHgfKAC2XHrLGCH2ZsuCJw2h4=.c75b4032-abb7-4f95-b19e-65788727f049@github.com>
 <9d7U4WiWGceuNVbh4TRHi7DpKBQNF0mCw_b-RrHb_aE=.fdb7ba7b-1a51-4be0-bbb7-dd47097fc93e@github.com>
 <qkjDRjYRQgfKgiqmlA_7JXs7TMmbPD9wPz3Hkp6eTVA=.9ca4a18c-0b6d-41d7-b77c-5a268f53f744@github.com>
Message-ID: <GFR9Gl10pLhYzmNvyP6K72bi5Mf7k6lf1IEgSq8uhnY=.40306649-8ce7-4db0-b293-b7fcc3e2489e@github.com>

On Thu, 14 Jan 2021 22:38:53 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> ?????? ??????? 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 add-all
>>  - 8193031: fix JavaDoc
>>  - Merge branch 'master' into add-all
>>  - Merge branch 'master' into add-all
>>  - 8193031: revert implementation change but keep one for JavaDoc
>>  - Merge branch 'master' into add-all
>>  - Merge remote-tracking branch 'origin/add-all' into add-all
>>  - 8193031: add elements in bulk in Collections.addAll()
>>  - Merge branch 'master' into add-all
>>  - 8193031: add elements in bulk in Collections.addAll()
>
> I think this looks good.

Hearing no objections, I'll sponsor this for Sergei.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Fri Jan 15 17:41: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, 15 Jan 2021 17:41:08 GMT
Subject: Integrated: 8193031: Collections.addAll is likely to perform worse
 than Collection.addAll
In-Reply-To: <TB3epXzVEKg86PLsoPvHgfKAC2XHrLGCH2ZsuCJw2h4=.c75b4032-abb7-4f95-b19e-65788727f049@github.com>
References: <TB3epXzVEKg86PLsoPvHgfKAC2XHrLGCH2ZsuCJw2h4=.c75b4032-abb7-4f95-b19e-65788727f049@github.com>
Message-ID: <OWJhGPhAIagsCno6uJ_lvINZM56cT2o0x2YBphXcYCw=.4a46d966-48e4-4d73-9e79-3dfa55408b85@github.com>

On Mon, 14 Dec 2020 12:13:23 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> Hello, I feel like this was previously discussed in https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot find original mail I post this here.
> 
> Currently `Collections.addAll()` is implemented and documented as:
>     /**
>      * ...
>      * The behavior of this convenience method is identical to that of
>      * {@code c.addAll(Arrays.asList(elements))}, but this method is likely
>      * to run significantly faster under most implementations.
>      */
>     @SafeVarargs
>     public static <T> boolean addAll(Collection<? super T> c, T... elements) {
>         boolean result = false;
>         for (T element : elements)
>             result |= c.add(element);
>         return result;
>     }
> 
> But it practice the notation `this method is likely to run significantly faster under most implementations` is completely wrong. When I take this [benchmark](https://github.com/stsypanov/benchmarks/blob/master/benchmark-runners/src/main/java/com/luxoft/logeek/benchmark/collection/CollectionsAddAllVsAddAllBenchmark.java) and run it on JDK 14 I get the following results:
>                                                    (collection)  (size)      Score     Error   Units
> addAll                                                ArrayList      10       37.9 ?     1.9   ns/op
> addAll                                                ArrayList     100       83.8 ?     3.4   ns/op
> addAll                                                ArrayList    1000      678.2 ?    23.0   ns/op
> collectionsAddAll                                     ArrayList      10       50.9 ?     1.1   ns/op
> collectionsAddAll                                     ArrayList     100      751.4 ?    47.4   ns/op
> collectionsAddAll                                     ArrayList    1000     8839.8 ?   710.7   ns/op
> 
> addAll                                                  HashSet      10      128.4 ?     5.9   ns/op
> addAll                                                  HashSet     100     1864.2 ?   102.4   ns/op
> addAll                                                  HashSet    1000    16615.5 ?  1202.6   ns/op
> collectionsAddAll                                       HashSet      10      172.8 ?     6.0   ns/op
> collectionsAddAll                                       HashSet     100     2355.8 ?   195.4   ns/op
> collectionsAddAll                                       HashSet    1000    20364.7 ?  1164.0   ns/op
> 
> addAll                                               ArrayDeque      10       54.0 ?     0.4   ns/op
> addAll                                               ArrayDeque     100      319.7 ?     2.5   ns/op
> addAll                                               ArrayDeque    1000     3176.9 ?    22.2   ns/op
> collectionsAddAll                                    ArrayDeque      10       66.5 ?     1.4   ns/op
> collectionsAddAll                                    ArrayDeque     100      808.1 ?    55.9   ns/op
> collectionsAddAll                                    ArrayDeque    1000     5639.6 ?   240.9   ns/op
> 
> addAll                                     CopyOnWriteArrayList      10       18.0 ?     0.7   ns/op
> addAll                                     CopyOnWriteArrayList     100       39.4 ?     1.7   ns/op
> addAll                                     CopyOnWriteArrayList    1000      371.1 ?    17.0   ns/op
> collectionsAddAll                          CopyOnWriteArrayList      10      251.9 ?    18.4   ns/op
> collectionsAddAll                          CopyOnWriteArrayList     100     3405.9 ?   304.8   ns/op
> collectionsAddAll                          CopyOnWriteArrayList    1000   247496.8 ? 23502.3   ns/op
> 
> addAll                                    ConcurrentLinkedDeque      10       81.4 ?     2.8   ns/op
> addAll                                    ConcurrentLinkedDeque     100      609.1 ?    26.4   ns/op
> addAll                                    ConcurrentLinkedDeque    1000     4494.5 ?   219.3   ns/op
> collectionsAddAll                         ConcurrentLinkedDeque      10      189.8 ?     2.5   ns/op
> collectionsAddAll                         ConcurrentLinkedDeque     100     1660.0 ?    62.0   ns/op
> collectionsAddAll                         ConcurrentLinkedDeque    1000    17649.2 ?   300.9   ns/op
> 
> addAll:?gc.alloc.rate.norm                            ArrayList      10      160.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                            ArrayList     100      880.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                            ArrayList    1000     8080.3 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                 ArrayList      10       80.0 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                 ArrayList     100     1400.2 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                 ArrayList    1000    15025.6 ?     0.1    B/op
> 
> addAll:?gc.alloc.rate.norm                              HashSet      10      464.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                              HashSet     100     5328.5 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                              HashSet    1000    48516.7 ?     0.1    B/op
> collectionsAddAll:?gc.alloc.rate.norm                   HashSet      10      464.0 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                   HashSet     100     5328.5 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                   HashSet    1000    48516.6 ?     0.1    B/op
> 
> addAll:?gc.alloc.rate.norm                           ArrayDeque      10      112.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                           ArrayDeque     100      560.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                           ArrayDeque    1000     4160.5 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                ArrayDeque      10      112.0 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                ArrayDeque     100     1048.1 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm                ArrayDeque    1000    14929.4 ?     0.0    B/op
> 
> addAll:?gc.alloc.rate.norm                 CopyOnWriteArrayList      10       88.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                 CopyOnWriteArrayList     100      448.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                 CopyOnWriteArrayList    1000     4048.1 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm      CopyOnWriteArrayList      10      456.0 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm      CopyOnWriteArrayList     100    22057.2 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm      CopyOnWriteArrayList    1000  2020150.3 ?     7.3    B/op
> 
> addAll:?gc.alloc.rate.norm                ConcurrentLinkedDeque      10      312.0 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                ConcurrentLinkedDeque     100     2472.1 ?     0.0    B/op
> addAll:?gc.alloc.rate.norm                ConcurrentLinkedDeque    1000    24073.7 ?     0.1    B/op
> collectionsAddAll:?gc.alloc.rate.norm     ConcurrentLinkedDeque      10      288.0 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm     ConcurrentLinkedDeque     100     2448.3 ?     0.0    B/op
> collectionsAddAll:?gc.alloc.rate.norm     ConcurrentLinkedDeque    1000    24051.4 ?     0.3    B/op
> There's never a case when `Collections.addAll` is fater - on the contrary `c.addAll(Arrays.asList())` always wins. Pay attention especially to dramatic difference for array-based collection.
> 
> So I propose to reimplement the method by simply delegating to `Arrays.asList` because the spec declares identical behaviour and to remove perfomance notation from JavaDoc.

This pull request has now been integrated.

Changeset: 27a39c8d
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Peter Levart <plevart at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/27a39c8d
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8193031: Collections.addAll is likely to perform worse than Collection.addAll

Reviewed-by: plevart

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

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

From redestad at openjdk.java.net  Fri Jan 15 18:07:03 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 15 Jan 2021 18:07:03 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding
In-Reply-To: <RyCTOVjgM1OozoFu-b9h4xCWtBBDvtgKh0q06XAj4C8=.834872da-a05c-46ae-bbb0-a56568181da4@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
 <RyCTOVjgM1OozoFu-b9h4xCWtBBDvtgKh0q06XAj4C8=.834872da-a05c-46ae-bbb0-a56568181da4@github.com>
Message-ID: <rOvg2RWEC-W4GW2S0Ah9G82WcZ9CbTpLw6N4DdvO3yQ=.ab864e8d-af3f-4798-99c8-eb33139d8bc0@github.com>

On Fri, 15 Jan 2021 16:49:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Interesting, I was/am in the middle of converting Result to be a Valhalla primitive class to reduce the memory pressure and had written some new jmh tests too.
> And to reduce the dependency on ThreadLocals.

Ok, I expect that would end up at similar performance while retaining the separation of concerns. But this way we're not dependent on valhalla to get rid of the TLs.

I'd be happy to add more JMH tests here. I expected this area to already have some, but it seems all the micros added during the work on compact strings work in JDK 9 are unaccounted for.

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

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

From mark.reinhold at oracle.com  Fri Jan 15 18:27:09 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 15 Jan 2021 10:27:09 -0800
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
 <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
 <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>
Message-ID: <20210115102709.538599954@eggemoggin.niobe.net>

2020/12/4 6:08:13 -0800, erikj at openjdk.java.net:
> On Fri, 4 Dec 2020 12:30:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:
>>> And I can certainly move jdwp.spec to java.base instead. That's the
>>> reason I need input on this: All I know is that is definitely not
>>> the responsibility of the Build Group to maintain that document, and
>>> I made my best guess at where to place it.
>> 
>>> And I can certainly move jdwp.spec to java.base instead.
>> 
>> If jdwp.spec has to move to the src tree then src/java.se is probably
>> the most suitable home because Java SE specifies JDWP as an optional
>> interface. So nothing to do with java.base and the build will need to
>> continue to generate the sources for the front-end (jdk.jdi) and
>> back-end (jdk.jdwp.agent) as they implement the protocol.
> 
> My understanding of JEPs is that they should be viewed as living
> documents. In this case, I think it's perfectly valid to update JEP
> 201 with additional source code layout. Both for this and for the
> other missing dirs.

Feature JEPs are living documents until such time as they are delivered.
In this case it would not be appropriate to update JEP 201, which is as
much about the transition from the old source-code layout as it is about
the new layout as of 2014.

At this point, and given that we?d already gone beyond JEP 201 prior to
this change (with `man` and `lib` subdirectories), what?d make the most
sense is a new informational JEP that documents the source-code layout.
Informational JEPs can, within reason, be updated over time.

- Mark

From ihse at openjdk.java.net  Fri Jan 15 18:30:07 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 15 Jan 2021 18:30:07 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v4]
In-Reply-To: <ABB2Pleoo1GTfmn0SdjrztH_u6VrfPRseLfMIrYhMdg=.a576b5bc-b25b-43ee-b5d3-394bce1415ca@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>
 <YT7on7W1w9GJRTMfz2KtftKo7yGbVTgZxYcqXv1POBU=.59b49a13-da41-4c93-88c7-1830b87d0b63@github.com>
 <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com>
 <ABB2Pleoo1GTfmn0SdjrztH_u6VrfPRseLfMIrYhMdg=.a576b5bc-b25b-43ee-b5d3-394bce1415ca@github.com>
Message-ID: <mPNUm7AkV0tIzHSYB15g2W4pJpA_F3xYeZUoyEqmrB0=.3a8bfe9e-9f23-4bad-94bc-fd4d4d599f25@github.com>

On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR is not stale; it's just still waiting for input from @AlanBateman.
>
> @magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang?

@AlanBateman That sounds like an excellent idea. I'll update the PR first thing next week. :)

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

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

From naoto at openjdk.java.net  Fri Jan 15 19:17:05 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 15 Jan 2021 19:17:05 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding
In-Reply-To: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
Message-ID: <s6nULeiTJ3PmS4nJFxQmRlbVBXl_YjdCN-bZLJ1ufIo=.75c4ba1f-f8a1-429a-b0ca-bdb111dafa8d@github.com>

On Fri, 15 Jan 2021 14:33:19 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.
> 
> This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.
> 
> Microbenchmark results:
> Baseline
> 
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
> decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op
> 
> Patched:
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
> decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op
> 
> Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.
> 
> Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.
> 
> Testing: tier1-4

Nit: copyright year in System.java is 2021.

src/java.base/share/classes/java/lang/String.java line 544:

> 542:             return;
> 543:         }
> 544:         if (charset == UTF_8) {

The constructor is getting big. Might be better to keep the original private methods (decodeASCII/Latin1/UTF8) for readability.

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

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

From kravikumar at openjdk.java.net  Fri Jan 15 19:17:05 2021
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Fri, 15 Jan 2021 19:17:05 GMT
Subject: Integrated: 8259048: (tz) Upgrade time-zone data to tzdata2020f
In-Reply-To: <9Vhqq8tJSSFttfpVHRl2YMj8DHXs8IhYajW61wQbMhs=.a9a11b2e-9b08-474c-a1cb-cbfa34b4c0d2@github.com>
References: <9Vhqq8tJSSFttfpVHRl2YMj8DHXs8IhYajW61wQbMhs=.a9a11b2e-9b08-474c-a1cb-cbfa34b4c0d2@github.com>
Message-ID: <9-cUVxsUMwAGMUydVcrhj_B0F3lPuZpDboW-7fgiNEg=.220a1b3f-0bd9-4938-9551-68e458a45505@github.com>

On Mon, 4 Jan 2021 18:11:05 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Updating the summary as tzdata2020f is available and includes tzdata2020e changes also.
> 
> Please review the integration of tzdata2020f to JDK.
> 
> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-December/000064.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8259048
> 
> tzdata2020e - Most of the changes are about correcting past timestamps and Australia/Currie timezone is removed.
> tzdata2020f - No changes to the data since 2020e.
> 
> Regression Tests pass along with JCK.
> 
> Please let me know if the changes are good to push.
> 
> Thanks,
> Kiran

This pull request has now been integrated.

Changeset: fe84ecd5
Author:    Kiran Sidhartha Ravikumar <kravikumar at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fe84ecd5
Stats:     729 lines in 10 files changed: 578 ins; 19 del; 132 mod

8259048: (tz) Upgrade time-zone data to tzdata2020f

Reviewed-by: naoto, erikj

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

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

From redestad at openjdk.java.net  Fri Jan 15 20:08:06 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 15 Jan 2021 20:08:06 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding
In-Reply-To: <s6nULeiTJ3PmS4nJFxQmRlbVBXl_YjdCN-bZLJ1ufIo=.75c4ba1f-f8a1-429a-b0ca-bdb111dafa8d@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
 <s6nULeiTJ3PmS4nJFxQmRlbVBXl_YjdCN-bZLJ1ufIo=.75c4ba1f-f8a1-429a-b0ca-bdb111dafa8d@github.com>
Message-ID: <wob_j0sx49tz1e8XWJChBrjFTN8FUIrvjl8Xv-LHppg=.1507cab7-6905-4a63-a5e1-2b6766f816b1@github.com>

On Fri, 15 Jan 2021 19:11:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.
>> 
>> This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.
>> 
>> Microbenchmark results:
>> Baseline
>> 
>> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
>> decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
>> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
>> decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
>> decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
>> decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
>> decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
>> decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
>> decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
>> decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
>> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op
>> 
>> Patched:
>> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
>> decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
>> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
>> decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
>> decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
>> decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
>> decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
>> decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
>> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op
>> 
>> Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.
>> 
>> Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.
>> 
>> Testing: tier1-4
>
> src/java.base/share/classes/java/lang/String.java line 544:
> 
>> 542:             return;
>> 543:         }
>> 544:         if (charset == UTF_8) {
> 
> The constructor is getting big. Might be better to keep the original private methods (decodeASCII/Latin1/UTF8) for readability.

Since we're calculating two final values, that split was what necessitated a `Result` object. Until valhalla I don't think there's a way to get rid of the performance cost here without putting the bulk of the logic into the constructor.

Refactoring out some of the logic to utility methods could be a performance neutral way to cut down the complexity, though. E.g.:
                                 char c = (char)((b1 << 12) ^
                                                (b2 <<  6) ^
                                                (b3 ^
                                                 (((byte) 0xE0 << 12) ^
                                                  ((byte) 0x80 <<  6) ^
                                                  ((byte) 0x80 <<  0))));
                                if (Character.isSurrogate(c)) {
                                    putChar(dst, dp++, REPL);
                                } else {
                                    putChar(dst, dp++, c);
                                }
could be reasonably factored out and reduced to something like:
                                putChar(dst, dp++, StringCoding.decode3(b1, b2, b3));
I've refrained from refurbishing too much, though.

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

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

From rriggs at openjdk.java.net  Fri Jan 15 20:19:04 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 15 Jan 2021 20:19:04 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding
In-Reply-To: <wob_j0sx49tz1e8XWJChBrjFTN8FUIrvjl8Xv-LHppg=.1507cab7-6905-4a63-a5e1-2b6766f816b1@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
 <s6nULeiTJ3PmS4nJFxQmRlbVBXl_YjdCN-bZLJ1ufIo=.75c4ba1f-f8a1-429a-b0ca-bdb111dafa8d@github.com>
 <wob_j0sx49tz1e8XWJChBrjFTN8FUIrvjl8Xv-LHppg=.1507cab7-6905-4a63-a5e1-2b6766f816b1@github.com>
Message-ID: <HB4-K8YSdHth-L8w9NMlPZKd8rIjqC6q0qNn_HM9qb0=.f71d4d90-65f2-4ef3-bc8d-91cb39e90aa2@github.com>

On Fri, 15 Jan 2021 20:05:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 544:
>> 
>>> 542:             return;
>>> 543:         }
>>> 544:         if (charset == UTF_8) {
>> 
>> The constructor is getting big. Might be better to keep the original private methods (decodeASCII/Latin1/UTF8) for readability.
>
> Since we're calculating two final values, that split was what necessitated a `Result` object. Until valhalla I don't think there's a way to get rid of the performance cost here without putting the bulk of the logic into the constructor.
> 
> Refactoring out some of the logic to utility methods could be a performance neutral way to cut down the complexity, though. E.g.:
>                                  char c = (char)((b1 << 12) ^
>                                                 (b2 <<  6) ^
>                                                 (b3 ^
>                                                  (((byte) 0xE0 << 12) ^
>                                                   ((byte) 0x80 <<  6) ^
>                                                   ((byte) 0x80 <<  0))));
>                                 if (Character.isSurrogate(c)) {
>                                     putChar(dst, dp++, REPL);
>                                 } else {
>                                     putChar(dst, dp++, c);
>                                 }
> could be reasonably factored out and reduced to something like:
>                                 putChar(dst, dp++, StringCoding.decode3(b1, b2, b3));
> I've refrained from refurbishing too much, though.

I don't think you need to inline quite so much.  Once the determination has been made about whether the result is Latin1 or UTF16 it calls separate methods anyway.  For example, after calling hasNegatives() it is known what coding is needed.
Then call out to a method returns the byte array.

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

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

From rriggs at openjdk.java.net  Fri Jan 15 20:19:04 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 15 Jan 2021 20:19:04 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding
In-Reply-To: <HB4-K8YSdHth-L8w9NMlPZKd8rIjqC6q0qNn_HM9qb0=.f71d4d90-65f2-4ef3-bc8d-91cb39e90aa2@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
 <s6nULeiTJ3PmS4nJFxQmRlbVBXl_YjdCN-bZLJ1ufIo=.75c4ba1f-f8a1-429a-b0ca-bdb111dafa8d@github.com>
 <wob_j0sx49tz1e8XWJChBrjFTN8FUIrvjl8Xv-LHppg=.1507cab7-6905-4a63-a5e1-2b6766f816b1@github.com>
 <HB4-K8YSdHth-L8w9NMlPZKd8rIjqC6q0qNn_HM9qb0=.f71d4d90-65f2-4ef3-bc8d-91cb39e90aa2@github.com>
Message-ID: <HiH5P5QgW68Y2c6k9dUfpy9B8xhQzK9DPrdX-HfiDmg=.9b67bb51-6826-4328-b91c-d61bd1c2c812@github.com>

On Fri, 15 Jan 2021 20:14:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Since we're calculating two final values, that split was what necessitated a `Result` object. Until valhalla I don't think there's a way to get rid of the performance cost here without putting the bulk of the logic into the constructor.
>> 
>> Refactoring out some of the logic to utility methods could be a performance neutral way to cut down the complexity, though. E.g.:
>>                                  char c = (char)((b1 << 12) ^
>>                                                 (b2 <<  6) ^
>>                                                 (b3 ^
>>                                                  (((byte) 0xE0 << 12) ^
>>                                                   ((byte) 0x80 <<  6) ^
>>                                                   ((byte) 0x80 <<  0))));
>>                                 if (Character.isSurrogate(c)) {
>>                                     putChar(dst, dp++, REPL);
>>                                 } else {
>>                                     putChar(dst, dp++, c);
>>                                 }
>> could be reasonably factored out and reduced to something like:
>>                                 putChar(dst, dp++, StringCoding.decode3(b1, b2, b3));
>> I've refrained from refurbishing too much, though.
>
> I don't think you need to inline quite so much.  Once the determination has been made about whether the result is Latin1 or UTF16 it calls separate methods anyway.  For example, after calling hasNegatives() it is known what coding is needed.
> Then call out to a method returns the byte array.

(Also, every email is very long because it includes the performance data; next time please put the performance data in a separate comment, not the PR).

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

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

From plevart at openjdk.java.net  Fri Jan 15 21:42:03 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 15 Jan 2021 21:42:03 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding
In-Reply-To: <s6nULeiTJ3PmS4nJFxQmRlbVBXl_YjdCN-bZLJ1ufIo=.75c4ba1f-f8a1-429a-b0ca-bdb111dafa8d@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
 <s6nULeiTJ3PmS4nJFxQmRlbVBXl_YjdCN-bZLJ1ufIo=.75c4ba1f-f8a1-429a-b0ca-bdb111dafa8d@github.com>
Message-ID: <iDOZpWzvi1sJ6dAJst00IXQtlWHKhVfbbhuPln1dh_Y=.4baaf7b1-da39-4096-8d56-e8f2834c1f8b@github.com>

On Fri, 15 Jan 2021 19:14:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.
>> 
>> This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.
>> 
>> Microbenchmark results:
>> Baseline
>> 
>> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
>> decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
>> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
>> decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
>> decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
>> decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
>> decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
>> decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
>> decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
>> decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
>> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op
>> 
>> Patched:
>> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
>> decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
>> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
>> decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
>> decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
>> decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
>> decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
>> decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
>> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op
>> 
>> Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.
>> 
>> Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.
>> 
>> Testing: tier1-4
>
> Nit: copyright year in System.java is 2021.

Hi Claes,
This is quite an undertaking in re-factoring!
I think that decoding logic that you produced can still be kept in StringCoding class though. The private constructor that you created for UTF-8 decoding is unnecessary. The logic can be kept in a static method and then the String instance constructed in it from the value and coder. The only public constructor that remains is then the one taking a Charset parameter. I took your code and moved it back to StringCoding while for the mentioned constructor I tried the following trick which could work (I haven't tested yet with JMH): if you pass an instance of newly constructed object down to a method that is inlined into the caller and that method does not pass that object to any other methods, JIT will eliminate the heap allocation, so I suspect that you can pass results from the called method back in that object and still avoid allocation...

https://github.com/plevart/jdk/commit/691600e3789a4c2b52fae921be87d0d7affa6f0f

WDYT?

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

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

From redestad at openjdk.java.net  Fri Jan 15 22:00:23 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 15 Jan 2021 22:00:23 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v2]
In-Reply-To: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
Message-ID: <V9lgPNGUgKWEvaR5rmJNG2P8jf1XXUNpUEWZRFg0ec8=.799a96ab-23ad-49cb-87bf-8bbe2fb7431e@github.com>

> The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.
> 
> This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.
> 
> Microbenchmark results:
> Baseline
> 
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
> decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op
> 
> Patched:
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
> decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op
> 
> Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.
> 
> Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.
> 
> Testing: tier1-4

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Outline much of the decode logic back into StringCoding

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2102/files
  - new: https://git.openjdk.java.net/jdk/pull/2102/files/f14826b1..c8899e15

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

  Stats: 315 lines in 2 files changed: 137 ins; 172 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2102.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2102/head:pull/2102

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

From redestad at openjdk.java.net  Fri Jan 15 23:08:20 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 15 Jan 2021 23:08:20 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v2]
In-Reply-To: <iDOZpWzvi1sJ6dAJst00IXQtlWHKhVfbbhuPln1dh_Y=.4baaf7b1-da39-4096-8d56-e8f2834c1f8b@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
 <s6nULeiTJ3PmS4nJFxQmRlbVBXl_YjdCN-bZLJ1ufIo=.75c4ba1f-f8a1-429a-b0ca-bdb111dafa8d@github.com>
 <iDOZpWzvi1sJ6dAJst00IXQtlWHKhVfbbhuPln1dh_Y=.4baaf7b1-da39-4096-8d56-e8f2834c1f8b@github.com>
Message-ID: <QGK3SH3c-2jklIZKNvoQXPjcQiJUvsrBRomiAM5B3yU=.adf46ff6-360f-44da-8d75-712099c28bde@github.com>

On Fri, 15 Jan 2021 21:39:00 GMT, Peter Levart <plevart at openjdk.org> wrote:

> WDYT?

I get that the approach I took got a bit messy, but I've just spent some time cleaning it up. Please have a look at the latest, which outlines much of the logic and consolidates the replace/throw logic in the UTF8 decode paths. I've checked it does not regress on the micro, and I think the overall state of the code now isn't much messier than the original code.

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

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

From valeriep at openjdk.java.net  Fri Jan 15 23:09:12 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 15 Jan 2021 23:09:12 GMT
Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests
In-Reply-To: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
References: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
Message-ID: <kVFRkvncmgSycRVAeayOOxrhXymcfwVVWcdxOnUg_KQ=.435b6227-9fee-4044-a3eb-2645fcc8080d@github.com>

On Sun, 20 Dec 2020 20:27:03 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration
> - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization.
> - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence.
> 
> Baseline:
>                               (digesterName)  (length)    Cnt     Score      Error   Units
> MessageDigests.digest                                MD5        16     15  2714.307 ?   21.133  ops/ms
> MessageDigests.digest                                MD5      1024     15   318.087 ?    0.637  ops/ms
> MessageDigests.digest                              SHA-1        16     15  1387.266 ?   40.932  ops/ms
> MessageDigests.digest                              SHA-1      1024     15   109.273 ?    0.149  ops/ms
> MessageDigests.digest                            SHA-256        16     15   995.566 ?   21.186  ops/ms
> MessageDigests.digest                            SHA-256      1024     15    89.104 ?    0.079  ops/ms
> MessageDigests.digest                            SHA-512        16     15   803.030 ?   15.722  ops/ms
> MessageDigests.digest                            SHA-512      1024     15   115.611 ?    0.234  ops/ms
> MessageDigests.getAndDigest                          MD5        16     15  2190.367 ?   97.037  ops/ms
> MessageDigests.getAndDigest                          MD5      1024     15   302.903 ?    1.809  ops/ms
> MessageDigests.getAndDigest                        SHA-1        16     15  1262.656 ?   43.751  ops/ms
> MessageDigests.getAndDigest                        SHA-1      1024     15   104.889 ?    3.554  ops/ms
> MessageDigests.getAndDigest                      SHA-256        16     15   914.541 ?   55.621  ops/ms
> MessageDigests.getAndDigest                      SHA-256      1024     15    85.708 ?    1.394  ops/ms
> MessageDigests.getAndDigest                      SHA-512        16     15   737.719 ?   53.671  ops/ms
> MessageDigests.getAndDigest                      SHA-512      1024     15   112.307 ?    1.950  ops/ms
> 
> GC:
> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   312.011 ?    0.005    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.020 ?    0.006    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   544.019 ?    0.016    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15  1056.037 ?    0.003    B/op
> 
> Target:
> Benchmark                                 (digesterName)  (length)    Cnt     Score      Error   Units
> MessageDigests.digest                                MD5        16     15  3134.462 ?   43.685  ops/ms
> MessageDigests.digest                                MD5      1024     15   323.667 ?    0.633  ops/ms
> MessageDigests.digest                              SHA-1        16     15  1418.742 ?   38.223  ops/ms
> MessageDigests.digest                              SHA-1      1024     15   110.178 ?    0.788  ops/ms
> MessageDigests.digest                            SHA-256        16     15  1037.949 ?   21.214  ops/ms
> MessageDigests.digest                            SHA-256      1024     15    89.671 ?    0.228  ops/ms
> MessageDigests.digest                            SHA-512        16     15   812.028 ?   39.489  ops/ms
> MessageDigests.digest                            SHA-512      1024     15   116.738 ?    0.249  ops/ms
> MessageDigests.getAndDigest                          MD5        16     15  2314.379 ?  229.294  ops/ms
> MessageDigests.getAndDigest                          MD5      1024     15   307.835 ?    5.730  ops/ms
> MessageDigests.getAndDigest                        SHA-1        16     15  1326.887 ?   63.263  ops/ms
> MessageDigests.getAndDigest                        SHA-1      1024     15   106.611 ?    2.292  ops/ms
> MessageDigests.getAndDigest                      SHA-256        16     15   961.589 ?   82.052  ops/ms
> MessageDigests.getAndDigest                      SHA-256      1024     15    88.646 ?    0.194  ops/ms
> MessageDigests.getAndDigest                      SHA-512        16     15   775.417 ?   56.775  ops/ms
> MessageDigests.getAndDigest                      SHA-512      1024     15   112.904 ?    2.014  ops/ms
> 
> GC
> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   232.009 ?    0.006    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.021 ?    0.001    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   272.012 ?    0.015    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15   400.017 ?    0.019    B/op
> 
> For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW.
> 
> For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test.
> 
> I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show.

src/java.base/share/classes/sun/security/provider/ByteArrayAccess.java line 214:


Why do we remove the index checking from all methods? Isn't it safer to check here in case the caller didn't? Or is it such checking is already implemented inside the the various methods of VarHandle?

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

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

From redestad at openjdk.java.net  Fri Jan 15 23:24:07 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 15 Jan 2021 23:24:07 GMT
Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests
In-Reply-To: <kVFRkvncmgSycRVAeayOOxrhXymcfwVVWcdxOnUg_KQ=.435b6227-9fee-4044-a3eb-2645fcc8080d@github.com>
References: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
 <kVFRkvncmgSycRVAeayOOxrhXymcfwVVWcdxOnUg_KQ=.435b6227-9fee-4044-a3eb-2645fcc8080d@github.com>
Message-ID: <d86GDrVwaw01uEB4ix4P5glIZ1M9MaZebniCkk5C9Yc=.30d604f5-9796-492f-88da-e52319c8efde@github.com>

On Fri, 15 Jan 2021 22:54:32 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration
>> - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization.
>> - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence.
>> 
>> Baseline:
>>                               (digesterName)  (length)    Cnt     Score      Error   Units
>> MessageDigests.digest                                MD5        16     15  2714.307 ?   21.133  ops/ms
>> MessageDigests.digest                                MD5      1024     15   318.087 ?    0.637  ops/ms
>> MessageDigests.digest                              SHA-1        16     15  1387.266 ?   40.932  ops/ms
>> MessageDigests.digest                              SHA-1      1024     15   109.273 ?    0.149  ops/ms
>> MessageDigests.digest                            SHA-256        16     15   995.566 ?   21.186  ops/ms
>> MessageDigests.digest                            SHA-256      1024     15    89.104 ?    0.079  ops/ms
>> MessageDigests.digest                            SHA-512        16     15   803.030 ?   15.722  ops/ms
>> MessageDigests.digest                            SHA-512      1024     15   115.611 ?    0.234  ops/ms
>> MessageDigests.getAndDigest                          MD5        16     15  2190.367 ?   97.037  ops/ms
>> MessageDigests.getAndDigest                          MD5      1024     15   302.903 ?    1.809  ops/ms
>> MessageDigests.getAndDigest                        SHA-1        16     15  1262.656 ?   43.751  ops/ms
>> MessageDigests.getAndDigest                        SHA-1      1024     15   104.889 ?    3.554  ops/ms
>> MessageDigests.getAndDigest                      SHA-256        16     15   914.541 ?   55.621  ops/ms
>> MessageDigests.getAndDigest                      SHA-256      1024     15    85.708 ?    1.394  ops/ms
>> MessageDigests.getAndDigest                      SHA-512        16     15   737.719 ?   53.671  ops/ms
>> MessageDigests.getAndDigest                      SHA-512      1024     15   112.307 ?    1.950  ops/ms
>> 
>> GC:
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   312.011 ?    0.005    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.020 ?    0.006    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   544.019 ?    0.016    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15  1056.037 ?    0.003    B/op
>> 
>> Target:
>> Benchmark                                 (digesterName)  (length)    Cnt     Score      Error   Units
>> MessageDigests.digest                                MD5        16     15  3134.462 ?   43.685  ops/ms
>> MessageDigests.digest                                MD5      1024     15   323.667 ?    0.633  ops/ms
>> MessageDigests.digest                              SHA-1        16     15  1418.742 ?   38.223  ops/ms
>> MessageDigests.digest                              SHA-1      1024     15   110.178 ?    0.788  ops/ms
>> MessageDigests.digest                            SHA-256        16     15  1037.949 ?   21.214  ops/ms
>> MessageDigests.digest                            SHA-256      1024     15    89.671 ?    0.228  ops/ms
>> MessageDigests.digest                            SHA-512        16     15   812.028 ?   39.489  ops/ms
>> MessageDigests.digest                            SHA-512      1024     15   116.738 ?    0.249  ops/ms
>> MessageDigests.getAndDigest                          MD5        16     15  2314.379 ?  229.294  ops/ms
>> MessageDigests.getAndDigest                          MD5      1024     15   307.835 ?    5.730  ops/ms
>> MessageDigests.getAndDigest                        SHA-1        16     15  1326.887 ?   63.263  ops/ms
>> MessageDigests.getAndDigest                        SHA-1      1024     15   106.611 ?    2.292  ops/ms
>> MessageDigests.getAndDigest                      SHA-256        16     15   961.589 ?   82.052  ops/ms
>> MessageDigests.getAndDigest                      SHA-256      1024     15    88.646 ?    0.194  ops/ms
>> MessageDigests.getAndDigest                      SHA-512        16     15   775.417 ?   56.775  ops/ms
>> MessageDigests.getAndDigest                      SHA-512      1024     15   112.904 ?    2.014  ops/ms
>> 
>> GC
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   232.009 ?    0.006    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.021 ?    0.001    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   272.012 ?    0.015    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15   400.017 ?    0.019    B/op
>> 
>> For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW.
>> 
>> For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test.
>> 
>> I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show.
>
> src/java.base/share/classes/sun/security/provider/ByteArrayAccess.java line 214:
> 
> 
> Why do we remove the index checking from all methods? Isn't it safer to check here in case the caller didn't? Or is it such checking is already implemented inside the the various methods of VarHandle?

Yes, IOOBE checking is done by the VarHandle methods, while the Unsafe API is unsafe and needs careful precondition checking. It doesn't seem to matter for performance (interpreted code sees some benefit by the removal).

With the current usage an IOOBE is probably not observable, but there's a test that reflects into ByteArrayAccess and verifies exceptions are thrown as expected on faulty inputs.

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

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

From valeriep at openjdk.java.net  Fri Jan 15 23:24:09 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 15 Jan 2021 23:24:09 GMT
Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests
In-Reply-To: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
References: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
Message-ID: <D-XsiRc8zJJ_yaG8jDjbyiwJ1Bh346VvLYNXcGxaq04=.80e4a06f-415f-4fd6-8262-054cff01fda2@github.com>

On Sun, 20 Dec 2020 20:27:03 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration
> - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization.
> - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence.
> 
> Baseline:
>                               (digesterName)  (length)    Cnt     Score      Error   Units
> MessageDigests.digest                                MD5        16     15  2714.307 ?   21.133  ops/ms
> MessageDigests.digest                                MD5      1024     15   318.087 ?    0.637  ops/ms
> MessageDigests.digest                              SHA-1        16     15  1387.266 ?   40.932  ops/ms
> MessageDigests.digest                              SHA-1      1024     15   109.273 ?    0.149  ops/ms
> MessageDigests.digest                            SHA-256        16     15   995.566 ?   21.186  ops/ms
> MessageDigests.digest                            SHA-256      1024     15    89.104 ?    0.079  ops/ms
> MessageDigests.digest                            SHA-512        16     15   803.030 ?   15.722  ops/ms
> MessageDigests.digest                            SHA-512      1024     15   115.611 ?    0.234  ops/ms
> MessageDigests.getAndDigest                          MD5        16     15  2190.367 ?   97.037  ops/ms
> MessageDigests.getAndDigest                          MD5      1024     15   302.903 ?    1.809  ops/ms
> MessageDigests.getAndDigest                        SHA-1        16     15  1262.656 ?   43.751  ops/ms
> MessageDigests.getAndDigest                        SHA-1      1024     15   104.889 ?    3.554  ops/ms
> MessageDigests.getAndDigest                      SHA-256        16     15   914.541 ?   55.621  ops/ms
> MessageDigests.getAndDigest                      SHA-256      1024     15    85.708 ?    1.394  ops/ms
> MessageDigests.getAndDigest                      SHA-512        16     15   737.719 ?   53.671  ops/ms
> MessageDigests.getAndDigest                      SHA-512      1024     15   112.307 ?    1.950  ops/ms
> 
> GC:
> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   312.011 ?    0.005    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.020 ?    0.006    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   544.019 ?    0.016    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15  1056.037 ?    0.003    B/op
> 
> Target:
> Benchmark                                 (digesterName)  (length)    Cnt     Score      Error   Units
> MessageDigests.digest                                MD5        16     15  3134.462 ?   43.685  ops/ms
> MessageDigests.digest                                MD5      1024     15   323.667 ?    0.633  ops/ms
> MessageDigests.digest                              SHA-1        16     15  1418.742 ?   38.223  ops/ms
> MessageDigests.digest                              SHA-1      1024     15   110.178 ?    0.788  ops/ms
> MessageDigests.digest                            SHA-256        16     15  1037.949 ?   21.214  ops/ms
> MessageDigests.digest                            SHA-256      1024     15    89.671 ?    0.228  ops/ms
> MessageDigests.digest                            SHA-512        16     15   812.028 ?   39.489  ops/ms
> MessageDigests.digest                            SHA-512      1024     15   116.738 ?    0.249  ops/ms
> MessageDigests.getAndDigest                          MD5        16     15  2314.379 ?  229.294  ops/ms
> MessageDigests.getAndDigest                          MD5      1024     15   307.835 ?    5.730  ops/ms
> MessageDigests.getAndDigest                        SHA-1        16     15  1326.887 ?   63.263  ops/ms
> MessageDigests.getAndDigest                        SHA-1      1024     15   106.611 ?    2.292  ops/ms
> MessageDigests.getAndDigest                      SHA-256        16     15   961.589 ?   82.052  ops/ms
> MessageDigests.getAndDigest                      SHA-256      1024     15    88.646 ?    0.194  ops/ms
> MessageDigests.getAndDigest                      SHA-512        16     15   775.417 ?   56.775  ops/ms
> MessageDigests.getAndDigest                      SHA-512      1024     15   112.904 ?    2.014  ops/ms
> 
> GC
> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   232.009 ?    0.006    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.021 ?    0.001    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   272.012 ?    0.015    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15   400.017 ?    0.019    B/op
> 
> For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW.
> 
> For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test.
> 
> I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show.

test/micro/org/openjdk/bench/java/util/UUIDBench.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved.

nit: other files should also have this 2021 update. It seems most of them are not updated and still uses 2020.

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

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

From redestad at openjdk.java.net  Fri Jan 15 23:36:35 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 15 Jan 2021 23:36:35 GMT
Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests [v2]
In-Reply-To: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
References: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
Message-ID: <0P4s8RVq7nJd-ZOK8o1RRnrNTQbf_sw1mk6q4dHpOI8=.14574584-f50a-4ce0-8d55-2dfb3bdf0fa0@github.com>

> - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration
> - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization.
> - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence.
> 
> Baseline:
>                               (digesterName)  (length)    Cnt     Score      Error   Units
> MessageDigests.digest                                MD5        16     15  2714.307 ?   21.133  ops/ms
> MessageDigests.digest                                MD5      1024     15   318.087 ?    0.637  ops/ms
> MessageDigests.digest                              SHA-1        16     15  1387.266 ?   40.932  ops/ms
> MessageDigests.digest                              SHA-1      1024     15   109.273 ?    0.149  ops/ms
> MessageDigests.digest                            SHA-256        16     15   995.566 ?   21.186  ops/ms
> MessageDigests.digest                            SHA-256      1024     15    89.104 ?    0.079  ops/ms
> MessageDigests.digest                            SHA-512        16     15   803.030 ?   15.722  ops/ms
> MessageDigests.digest                            SHA-512      1024     15   115.611 ?    0.234  ops/ms
> MessageDigests.getAndDigest                          MD5        16     15  2190.367 ?   97.037  ops/ms
> MessageDigests.getAndDigest                          MD5      1024     15   302.903 ?    1.809  ops/ms
> MessageDigests.getAndDigest                        SHA-1        16     15  1262.656 ?   43.751  ops/ms
> MessageDigests.getAndDigest                        SHA-1      1024     15   104.889 ?    3.554  ops/ms
> MessageDigests.getAndDigest                      SHA-256        16     15   914.541 ?   55.621  ops/ms
> MessageDigests.getAndDigest                      SHA-256      1024     15    85.708 ?    1.394  ops/ms
> MessageDigests.getAndDigest                      SHA-512        16     15   737.719 ?   53.671  ops/ms
> MessageDigests.getAndDigest                      SHA-512      1024     15   112.307 ?    1.950  ops/ms
> 
> GC:
> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   312.011 ?    0.005    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.020 ?    0.006    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   544.019 ?    0.016    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15  1056.037 ?    0.003    B/op
> 
> Target:
> Benchmark                                 (digesterName)  (length)    Cnt     Score      Error   Units
> MessageDigests.digest                                MD5        16     15  3134.462 ?   43.685  ops/ms
> MessageDigests.digest                                MD5      1024     15   323.667 ?    0.633  ops/ms
> MessageDigests.digest                              SHA-1        16     15  1418.742 ?   38.223  ops/ms
> MessageDigests.digest                              SHA-1      1024     15   110.178 ?    0.788  ops/ms
> MessageDigests.digest                            SHA-256        16     15  1037.949 ?   21.214  ops/ms
> MessageDigests.digest                            SHA-256      1024     15    89.671 ?    0.228  ops/ms
> MessageDigests.digest                            SHA-512        16     15   812.028 ?   39.489  ops/ms
> MessageDigests.digest                            SHA-512      1024     15   116.738 ?    0.249  ops/ms
> MessageDigests.getAndDigest                          MD5        16     15  2314.379 ?  229.294  ops/ms
> MessageDigests.getAndDigest                          MD5      1024     15   307.835 ?    5.730  ops/ms
> MessageDigests.getAndDigest                        SHA-1        16     15  1326.887 ?   63.263  ops/ms
> MessageDigests.getAndDigest                        SHA-1      1024     15   106.611 ?    2.292  ops/ms
> MessageDigests.getAndDigest                      SHA-256        16     15   961.589 ?   82.052  ops/ms
> MessageDigests.getAndDigest                      SHA-256      1024     15    88.646 ?    0.194  ops/ms
> MessageDigests.getAndDigest                      SHA-512        16     15   775.417 ?   56.775  ops/ms
> MessageDigests.getAndDigest                      SHA-512      1024     15   112.904 ?    2.014  ops/ms
> 
> GC
> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   232.009 ?    0.006    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.021 ?    0.001    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   272.012 ?    0.015    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15   400.017 ?    0.019    B/op
> 
> For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW.
> 
> For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test.
> 
> I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show.

Claes Redestad 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:

 - Copyrights
 - Merge branch 'master' into improve_md5
 - Remove unused Unsafe import
 - Harmonize MD4 impl, remove now-redundant checks from ByteArrayAccess (VHs do bounds checks, most of which will be optimized away)
 - Merge branch 'master' into improve_md5
 - Apply allocation avoiding optimizations to all SHA versions sharing structural similarities with MD5
 - Remove unused reverseBytes imports
 - Copyrights
 - Fix copy-paste error
 - Various fixes (IDE stopped IDEing..)
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/03e99844...cafa3e49

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1855/files
  - new: https://git.openjdk.java.net/jdk/pull/1855/files/e1c943c5..cafa3e49

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

  Stats: 28760 lines in 1103 files changed: 16020 ins; 7214 del; 5526 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1855.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1855/head:pull/1855

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

From redestad at openjdk.java.net  Fri Jan 15 23:36:42 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 15 Jan 2021 23:36:42 GMT
Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests [v2]
In-Reply-To: <D-XsiRc8zJJ_yaG8jDjbyiwJ1Bh346VvLYNXcGxaq04=.80e4a06f-415f-4fd6-8262-054cff01fda2@github.com>
References: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
 <D-XsiRc8zJJ_yaG8jDjbyiwJ1Bh346VvLYNXcGxaq04=.80e4a06f-415f-4fd6-8262-054cff01fda2@github.com>
Message-ID: <AwvKTywE7P-WyiAOp3ONcvaxpYR_krfbnWdVkWssARo=.a9de88fe-ef55-45d5-8be2-3bb9316ea86b@github.com>

On Fri, 15 Jan 2021 23:21:00 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Claes Redestad 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:
>> 
>>  - Copyrights
>>  - Merge branch 'master' into improve_md5
>>  - Remove unused Unsafe import
>>  - Harmonize MD4 impl, remove now-redundant checks from ByteArrayAccess (VHs do bounds checks, most of which will be optimized away)
>>  - Merge branch 'master' into improve_md5
>>  - Apply allocation avoiding optimizations to all SHA versions sharing structural similarities with MD5
>>  - Remove unused reverseBytes imports
>>  - Copyrights
>>  - Fix copy-paste error
>>  - Various fixes (IDE stopped IDEing..)
>>  - ... and 10 more: https://git.openjdk.java.net/jdk/compare/6e03c8d3...cafa3e49
>
> test/micro/org/openjdk/bench/java/util/UUIDBench.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved.
> 
> nit: other files should also have this 2021 update. It seems most of them are not updated and still uses 2020.

fixed

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

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

From redestad at openjdk.java.net  Fri Jan 15 23:41:15 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 15 Jan 2021 23:41:15 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v3]
In-Reply-To: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
Message-ID: <291yL3H0wE24b9TaquMzokQfS1ysoQtuNh1OAgVonJw=.d458f007-88cf-4606-bdc6-0aab02e714d1@github.com>

> The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.
> 
> This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.
> 
> Microbenchmark results:
> Baseline
> 
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
> decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op
> 
> Patched:
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
> decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op
> 
> Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.
> 
> Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.
> 
> Testing: tier1-4

Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Copyrights
 - Merge branch 'master' into sc_tl_exp
 - Outline much of the decode logic back into StringCoding
 - Remove unused imports
 - Merge branch 'master' into sc_tl_exp
 - Fix charset names in micro settings
 - Refactor charset lookups to ensure expected exceptions are thrown on null, foo etc
 - Cleanup includes etc
 - Cleanups, minor improvements
 - More micro fixes
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/d63388c0...f328f451

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

Changes: https://git.openjdk.java.net/jdk/pull/2102/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2102&range=02
  Stats: 1027 lines in 4 files changed: 472 ins; 458 del; 97 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2102.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2102/head:pull/2102

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

From amenkov at openjdk.java.net  Fri Jan 15 23:57:08 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 15 Jan 2021 23:57:08 GMT
Subject: RFR: 8258917: NativeMemoryTracking is handled by launcher
 inconsistenly
In-Reply-To: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
References: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
Message-ID: <wfu8p85sMIDSbCfIAtrCumFSYmGkigKHX63Urh5iz40=.04824d85-8e2d-44e1-83dd-da1d261d1406@github.com>

On Fri, 15 Jan 2021 23:50:16 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix adds NMT handling for non-java launchers

Added serviceability as serviceability tools use launcher functionality

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

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

From amenkov at openjdk.java.net  Fri Jan 15 23:57:08 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 15 Jan 2021 23:57:08 GMT
Subject: RFR: 8258917: NativeMemoryTracking is handled by launcher
 inconsistenly
Message-ID: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>

The fix adds NMT handling for non-java launchers

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

Commit messages:
 - Handle NMT for non-java launchers

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

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

From valeriep at openjdk.java.net  Sat Jan 16 00:25:19 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Sat, 16 Jan 2021 00:25:19 GMT
Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests [v2]
In-Reply-To: <0P4s8RVq7nJd-ZOK8o1RRnrNTQbf_sw1mk6q4dHpOI8=.14574584-f50a-4ce0-8d55-2dfb3bdf0fa0@github.com>
References: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
 <0P4s8RVq7nJd-ZOK8o1RRnrNTQbf_sw1mk6q4dHpOI8=.14574584-f50a-4ce0-8d55-2dfb3bdf0fa0@github.com>
Message-ID: <hHKidKpZOXFUbYtK5tL_KNcvkZJkBz-rUr1iGT_2CiY=.1dcf3152-fccf-4697-877b-ccc7c16f4b8e@github.com>

On Fri, 15 Jan 2021 23:36:35 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration
>> - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization.
>> - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence.
>> 
>> Baseline:
>>                               (digesterName)  (length)    Cnt     Score      Error   Units
>> MessageDigests.digest                                MD5        16     15  2714.307 ?   21.133  ops/ms
>> MessageDigests.digest                                MD5      1024     15   318.087 ?    0.637  ops/ms
>> MessageDigests.digest                              SHA-1        16     15  1387.266 ?   40.932  ops/ms
>> MessageDigests.digest                              SHA-1      1024     15   109.273 ?    0.149  ops/ms
>> MessageDigests.digest                            SHA-256        16     15   995.566 ?   21.186  ops/ms
>> MessageDigests.digest                            SHA-256      1024     15    89.104 ?    0.079  ops/ms
>> MessageDigests.digest                            SHA-512        16     15   803.030 ?   15.722  ops/ms
>> MessageDigests.digest                            SHA-512      1024     15   115.611 ?    0.234  ops/ms
>> MessageDigests.getAndDigest                          MD5        16     15  2190.367 ?   97.037  ops/ms
>> MessageDigests.getAndDigest                          MD5      1024     15   302.903 ?    1.809  ops/ms
>> MessageDigests.getAndDigest                        SHA-1        16     15  1262.656 ?   43.751  ops/ms
>> MessageDigests.getAndDigest                        SHA-1      1024     15   104.889 ?    3.554  ops/ms
>> MessageDigests.getAndDigest                      SHA-256        16     15   914.541 ?   55.621  ops/ms
>> MessageDigests.getAndDigest                      SHA-256      1024     15    85.708 ?    1.394  ops/ms
>> MessageDigests.getAndDigest                      SHA-512        16     15   737.719 ?   53.671  ops/ms
>> MessageDigests.getAndDigest                      SHA-512      1024     15   112.307 ?    1.950  ops/ms
>> 
>> GC:
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   312.011 ?    0.005    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.020 ?    0.006    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   544.019 ?    0.016    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15  1056.037 ?    0.003    B/op
>> 
>> Target:
>> Benchmark                                 (digesterName)  (length)    Cnt     Score      Error   Units
>> MessageDigests.digest                                MD5        16     15  3134.462 ?   43.685  ops/ms
>> MessageDigests.digest                                MD5      1024     15   323.667 ?    0.633  ops/ms
>> MessageDigests.digest                              SHA-1        16     15  1418.742 ?   38.223  ops/ms
>> MessageDigests.digest                              SHA-1      1024     15   110.178 ?    0.788  ops/ms
>> MessageDigests.digest                            SHA-256        16     15  1037.949 ?   21.214  ops/ms
>> MessageDigests.digest                            SHA-256      1024     15    89.671 ?    0.228  ops/ms
>> MessageDigests.digest                            SHA-512        16     15   812.028 ?   39.489  ops/ms
>> MessageDigests.digest                            SHA-512      1024     15   116.738 ?    0.249  ops/ms
>> MessageDigests.getAndDigest                          MD5        16     15  2314.379 ?  229.294  ops/ms
>> MessageDigests.getAndDigest                          MD5      1024     15   307.835 ?    5.730  ops/ms
>> MessageDigests.getAndDigest                        SHA-1        16     15  1326.887 ?   63.263  ops/ms
>> MessageDigests.getAndDigest                        SHA-1      1024     15   106.611 ?    2.292  ops/ms
>> MessageDigests.getAndDigest                      SHA-256        16     15   961.589 ?   82.052  ops/ms
>> MessageDigests.getAndDigest                      SHA-256      1024     15    88.646 ?    0.194  ops/ms
>> MessageDigests.getAndDigest                      SHA-512        16     15   775.417 ?   56.775  ops/ms
>> MessageDigests.getAndDigest                      SHA-512      1024     15   112.904 ?    2.014  ops/ms
>> 
>> GC
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   232.009 ?    0.006    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.021 ?    0.001    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   272.012 ?    0.015    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15   400.017 ?    0.019    B/op
>> 
>> For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW.
>> 
>> For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test.
>> 
>> I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show.
>
> Claes Redestad 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:
> 
>  - Copyrights
>  - Merge branch 'master' into improve_md5
>  - Remove unused Unsafe import
>  - Harmonize MD4 impl, remove now-redundant checks from ByteArrayAccess (VHs do bounds checks, most of which will be optimized away)
>  - Merge branch 'master' into improve_md5
>  - Apply allocation avoiding optimizations to all SHA versions sharing structural similarities with MD5
>  - Remove unused reverseBytes imports
>  - Copyrights
>  - Fix copy-paste error
>  - Various fixes (IDE stopped IDEing..)
>  - ... and 10 more: https://git.openjdk.java.net/jdk/compare/18f8493b...cafa3e49

Changes look good. Thanks.

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

Marked as reviewed by valeriep (Reviewer).

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

From plevart at openjdk.java.net  Sat Jan 16 00:28:06 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Sat, 16 Jan 2021 00:28:06 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v3]
In-Reply-To: <QGK3SH3c-2jklIZKNvoQXPjcQiJUvsrBRomiAM5B3yU=.adf46ff6-360f-44da-8d75-712099c28bde@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
 <s6nULeiTJ3PmS4nJFxQmRlbVBXl_YjdCN-bZLJ1ufIo=.75c4ba1f-f8a1-429a-b0ca-bdb111dafa8d@github.com>
 <iDOZpWzvi1sJ6dAJst00IXQtlWHKhVfbbhuPln1dh_Y=.4baaf7b1-da39-4096-8d56-e8f2834c1f8b@github.com>
 <QGK3SH3c-2jklIZKNvoQXPjcQiJUvsrBRomiAM5B3yU=.adf46ff6-360f-44da-8d75-712099c28bde@github.com>
Message-ID: <C2hp5Q-E126C9B42C922L6cO7vQRNlBBpsFf7f5euew=.31cdc7e7-c5e7-4432-8f3e-a44b92ff5ea6@github.com>

On Fri, 15 Jan 2021 22:03:31 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Hi Claes,
>> This is quite an undertaking in re-factoring!
>> I think that decoding logic that you produced can still be kept in StringCoding class though. The private constructor that you created for UTF-8 decoding is unnecessary. The logic can be kept in a static method and then the String instance constructed in it from the value and coder. The only public constructor that remains is then the one taking a Charset parameter. I took your code and moved it back to StringCoding while for the mentioned constructor I tried the following trick which could work (I haven't tested yet with JMH): if you pass an instance of newly constructed object down to a method that is inlined into the caller and that method does not pass that object to any other methods, JIT will eliminate the heap allocation, so I suspect that you can pass results from the called method back in that object and still avoid allocation...
>> 
>> https://github.com/plevart/jdk/commit/691600e3789a4c2b52fae921be87d0d7affa6f0f
>> 
>> WDYT?
>
>> WDYT?
> 
> I get that the approach I took got a bit messy, but I've just spent some time cleaning it up. Please have a look at the latest, which outlines much of the logic and consolidates the replace/throw logic in the UTF8 decode paths. I've checked it does not regress on the micro, and I think the overall state of the code now isn't much messier than the original code.

Some common logic is now extracted into methods. That's good. But much of the decoding logic still remains in String. I still think all of static methods can be moved to StringCoding directly as they are now while the private UTF-8 decoding constructor can be replaced with static method and moved to StringCoding. The only problem might be the public String constructor taking Charset parameter. But even here, passing a newly constructed mutable object to the method can be used to return multiple values from the method while relying on JIT to eliminate object allocation.
Do you think this code belongs more to String than to StringCoding?

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

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

From naoto at openjdk.java.net  Sat Jan 16 00:51:09 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Sat, 16 Jan 2021 00:51:09 GMT
Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg
 drop 10 [v2]
In-Reply-To: <1Bb8sf6zFDnQSM5kRQIlrgBNwEpO-IvxsPmN05F0QFs=.13eb3035-71d5-4310-98e5-d9989e51cf60@github.com>
References: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
 <QceWk9N7q2iV9alfICITS0Sdr8eacuR15Mrihph-doI=.1cee427c-0be1-4cb9-8a77-098696ddd5da@github.com>
 <ZkHoKP8fL7uRj0TIiwqYtVch0eyxQGv2JeY-BDgf310=.91ef28d1-d91b-4b37-aa9f-edd81b94f235@github.com>
 <1Bb8sf6zFDnQSM5kRQIlrgBNwEpO-IvxsPmN05F0QFs=.13eb3035-71d5-4310-98e5-d9989e51cf60@github.com>
Message-ID: <F3h1x-ZgNClOKHsAunvSztkl9XxmH7cP9YPZoz_O08I=.2d76925f-b12f-49c0-9631-94e663df59e3@github.com>

On Fri, 15 Jan 2021 01:59:07 GMT, Leo Jiang <ljiang at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 518:
>> 
>>> 516: doclet.footer_specified=\
>>> 517:     The -footer option is no longer supported and will be ignored.\n\
>>> 518:     It may be removed in a future release.
>> 
>> I believe this is to fix no newline at the end (unrelated to l10n changes). Do we need to change the copyright year for this?
>
> Actually I was correcting the L217, changed {) -> {}. But 2 days ago, Jonathan Gibbons fixed it in another commit 6bb6093. I found his fix after running the merge. Looks both of us forgot to update the copyright year. Any suggestion? 
> doclet.help.systemProperties.body=\
>     The {0} page lists references to system properties.

I believe your PR still contains the fix to add the newline at the end of the file (at L518). So I think you can simply change the copyright year in `standard.properties` file.

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

PR: https://git.openjdk.java.net/jdk16/pull/123

From kizune at openjdk.java.net  Sat Jan 16 01:02:04 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 16 Jan 2021 01:02:04 GMT
Subject: RFR:     JDK-8259062: Remove MacAppStoreBundler
In-Reply-To: <iAhpVYi8-wmDzRrnQjaUnPuFWuRI1NSwrlqi0LQVrPk=.f97b81e8-d7c9-4c09-9589-682c2c0afa1c@github.com>
References: <iAhpVYi8-wmDzRrnQjaUnPuFWuRI1NSwrlqi0LQVrPk=.f97b81e8-d7c9-4c09-9589-682c2c0afa1c@github.com>
Message-ID: <-MH9cKljPBVTfSX_n5Mxb9c06Aml3aVKMlaclEqg07E=.eb37f9cf-1f5e-4b2f-9d5d-a1eccd74e276@github.com>

On Wed, 6 Jan 2021 15:52:07 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8259062: Remove MacAppStoreBundler

Marked as reviewed by kizune (Reviewer).

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

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

From kizune at openjdk.java.net  Sat Jan 16 01:02:06 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 16 Jan 2021 01:02:06 GMT
Subject: RFR: JDK-8259238: Clean up Log.java and remove usage of non-final
 static variables.
In-Reply-To: <gBD8pSjYTSaDX-I-1shActJPeKRSQlGkbmcuDydyqmY=.8e901e78-b133-48bb-8987-c0c77b99e77c@github.com>
References: <gBD8pSjYTSaDX-I-1shActJPeKRSQlGkbmcuDydyqmY=.8e901e78-b133-48bb-8987-c0c77b99e77c@github.com>
Message-ID: <v4q_Uu69ut3WApy_1VXlyJCtCSFUEAKwBbMjUKeIR8g=.660bb0fe-84b6-4332-9d7c-3dff6411d083@github.com>

On Thu, 7 Jan 2021 16:40:26 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8259238: Clean up Log.java and remove usage of non-final static variables.

Marked as reviewed by kizune (Reviewer).

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

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

From kizune at openjdk.java.net  Sat Jan 16 01:03:10 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 16 Jan 2021 01:03:10 GMT
Subject: RFR: JDK-8258755: jpackage: Invalid 32-bit exe when building
 app-image
In-Reply-To: <s7PJA74O7GtTqPkaLzHQ033a9vlKG2ZfX6HCdgKmNZQ=.6cda02fc-bd7d-4d2b-ab1b-b3d7c5641b05@github.com>
References: <s7PJA74O7GtTqPkaLzHQ033a9vlKG2ZfX6HCdgKmNZQ=.6cda02fc-bd7d-4d2b-ab1b-b3d7c5641b05@github.com>
Message-ID: <uJoBdu-NjzsEMqFpt5qchS44eo4wTTONeHCuj9zKZZw=.8d2ddf4f-bcdf-4a7b-9058-49b23254014b@github.com>

On Mon, 11 Jan 2021 17:42:21 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8258755: jpackage: Invalid 32-bit exe when building app-image

Marked as reviewed by kizune (Reviewer).

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

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

From redestad at openjdk.java.net  Sat Jan 16 02:08:30 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sat, 16 Jan 2021 02:08:30 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v4]
In-Reply-To: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
Message-ID: <daeMK_5LQhzT8rspeaELwPbd9irSVQKx_PAIsqGgpAw=.c403da4a-868c-4230-8b8c-c1258e43f818@github.com>

> The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.
> 
> This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.
> 
> Microbenchmark results:
> Baseline
> 
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
> decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op
> 
> Patched:
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
> decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op
> 
> Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.
> 
> Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.
> 
> Testing: tier1-4

Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:

 - Add missing import (who needs IDEs?)
 - Further simplifications

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2102/files
  - new: https://git.openjdk.java.net/jdk/pull/2102/files/f328f451..4c8eacd1

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

  Stats: 153 lines in 2 files changed: 62 ins; 85 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2102.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2102/head:pull/2102

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

From redestad at openjdk.java.net  Sat Jan 16 02:08:30 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sat, 16 Jan 2021 02:08:30 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v4]
In-Reply-To: <C2hp5Q-E126C9B42C922L6cO7vQRNlBBpsFf7f5euew=.31cdc7e7-c5e7-4432-8f3e-a44b92ff5ea6@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
 <s6nULeiTJ3PmS4nJFxQmRlbVBXl_YjdCN-bZLJ1ufIo=.75c4ba1f-f8a1-429a-b0ca-bdb111dafa8d@github.com>
 <iDOZpWzvi1sJ6dAJst00IXQtlWHKhVfbbhuPln1dh_Y=.4baaf7b1-da39-4096-8d56-e8f2834c1f8b@github.com>
 <QGK3SH3c-2jklIZKNvoQXPjcQiJUvsrBRomiAM5B3yU=.adf46ff6-360f-44da-8d75-712099c28bde@github.com>
 <C2hp5Q-E126C9B42C922L6cO7vQRNlBBpsFf7f5euew=.31cdc7e7-c5e7-4432-8f3e-a44b92ff5ea6@github.com>
Message-ID: <5hl3I02WFDVBW77UXh0zILkJnWOZSnkX5nvW5u73WIQ=.b75c3ff5-1223-4d91-9068-9520680f6423@github.com>

On Sat, 16 Jan 2021 00:25:24 GMT, Peter Levart <plevart at openjdk.org> wrote:

> Do you think this code belongs more to String than to StringCoding?

I consider StringCoding an implementation detail of String, so I'm not sure there's (much) value in maintaining the separation of concern if it is cause for a performance loss. While encapsulating and separating concerns is a fine purpose I think the main purpose served by StringCoding is to resolve some bootstrap issues: String is one of the first classes to be loaded and eagerly pulling in dependencies like ThreadLocal and Charsets before bootstrapping leads to all manner of hard to decipher issues (yes - I've tried :-)).

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

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

From zgu at openjdk.java.net  Sat Jan 16 02:08:19 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Sat, 16 Jan 2021 02:08:19 GMT
Subject: RFR: 8258917: NativeMemoryTracking is handled by launcher
 inconsistenly
In-Reply-To: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
References: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
Message-ID: <EKFgLliCJCwNCLJ_TYIOv_r2TT_oQq8siMx7r1M8eik=.196452af-e97c-4452-9299-37be7b5036dd@github.com>

On Fri, 15 Jan 2021 23:50:16 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix adds NMT handling for non-java launchers

Looks good

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

Marked as reviewed by zgu (Reviewer).

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

From eirbjo at gmail.com  Sat Jan 16 09:53:29 2021
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 16 Jan 2021 10:53:29 +0100
Subject: JDK-8242959 residual cleanup: Move encoding checks into ZipCoder
Message-ID: <CA+pBWhs3SWuEO-dcRBepdSprLahqAqYzc2mHcfDqVXxjKX+Ptg@mail.gmail.com>

Hi,

The following is purely a code cleanup/refactoring proposal for ZipFile
internals:

ZipFile.Source.initCEN currently checks that each entry name is encoded
using bytes valid in the entry's encoding:

if (zc.isUTF8() || (flag & USE_UTF8) != 0) {
          checkUTF8(cen, pos + CENHDR, nlen);
} else {
           checkEncoding(zc, cen, pos + CENHDR, nlen);
}

I find this unnecessarily complicated for a couple of reasons:

1: The if repeats flag checking logic which already exists in zipCoderForPos
2: checkUTF and checkEncoding are encoding-specific methods and as such
would have a better home in ZipCoder

As a cleanup, I propose that we move checkEncoding into ZipCoder and make
checkUTF an override of checkEncoding in UTF8ZipCoder.

Here's a patch which implements the proposal. Sponsors are welcome :-)

diff --git a/src/java.base/share/classes/java/util/zip/ZipCoder.java
b/src/java.base/share/classes/java/util/zip/ZipCoder.java
index 13012aab0f6..cb1ab256891 100644
--- a/src/java.base/share/classes/java/util/zip/ZipCoder.java
+++ b/src/java.base/share/classes/java/util/zip/ZipCoder.java
@@ -54,6 +54,14 @@ class ZipCoder {
         return new ZipCoder(charset);
     }

+    void checkEncoding(byte[] a, int pos, int nlen) throws ZipException {
+        try {
+            toString(a, pos, nlen);
+        } catch(Exception e) {
+            throw new ZipException("invalid CEN header (bad entry name)");
+        }
+    }
+
     String toString(byte[] ba, int off, int length) {
         try {
             return decoder().decode(ByteBuffer.wrap(ba, off,
length)).toString();
@@ -203,6 +211,25 @@ class ZipCoder {
             return true;
         }

+        @Override
+        void checkEncoding(byte[] a, int pos, int len) throws ZipException
{
+            try {
+                int end = pos + len;
+                while (pos < end) {
+                    // ASCII fast-path: When checking that a range of
bytes is
+                    // valid UTF-8, we can avoid some allocation by
skipping
+                    // past bytes in the 0-127 range
+                    if (a[pos] < 0) {
+                        ZipCoder.toStringUTF8(a, pos, end - pos);
+                        break;
+                    }
+                    pos++;
+                }
+            } catch(Exception e) {
+                throw new ZipException("invalid CEN header (bad entry
name)");
+            }
+        }
+
         @Override
         String toString(byte[] ba, int off, int length) {
             return JLA.newStringUTF8NoRepl(ba, off, length);
diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java
b/src/java.base/share/classes/java/util/zip/ZipFile.java
index 4c53855abfe..07edc06999b 100644
--- a/src/java.base/share/classes/java/util/zip/ZipFile.java
+++ b/src/java.base/share/classes/java/util/zip/ZipFile.java
@@ -1309,31 +1309,6 @@ public class ZipFile implements ZipConstants,
Closeable {
             }
         }

-        private static final void checkUTF8(byte[] a, int pos, int len)
throws ZipException {
-            try {
-                int end = pos + len;
-                while (pos < end) {
-                    // ASCII fast-path: When checking that a range of
bytes is
-                    // valid UTF-8, we can avoid some allocation by
skipping
-                    // past bytes in the 0-127 range
-                    if (a[pos] < 0) {
-                        ZipCoder.toStringUTF8(a, pos, end - pos);
-                        break;
-                    }
-                    pos++;
-                }
-            } catch(Exception e) {
-                zerror("invalid CEN header (bad entry name)");
-            }
-        }
-
-        private final void checkEncoding(ZipCoder zc, byte[] a, int pos,
int nlen) throws ZipException {
-            try {
-                zc.toString(a, pos, nlen);
-            } catch(Exception e) {
-                zerror("invalid CEN header (bad entry name)");
-            }
-        }

         private static class End {
             int  centot;     // 4 bytes
@@ -1520,13 +1495,10 @@ public class ZipFile implements ZipConstants,
Closeable {
                     zerror("invalid CEN header (bad compression method: "
+ method + ")");
                 if (entryPos + nlen > limit)
                     zerror("invalid CEN header (bad header size)");
-                if (zc.isUTF8() || (flag & USE_UTF8) != 0) {
-                    checkUTF8(cen, pos + CENHDR, nlen);
-                } else {
-                    checkEncoding(zc, cen, pos + CENHDR, nlen);
-                }
+                ZipCoder zcp = zipCoderForPos(pos);
+                zcp.checkEncoding(cen, pos + CENHDR, nlen);
                 // Record the CEN offset and the name hash in our hash
cell.
-                hash = zipCoderForPos(pos).normalizedHash(cen, entryPos,
nlen);
+                hash = zcp.normalizedHash(cen, entryPos, nlen);
                 hsh = (hash & 0x7fffffff) % tablelen;
                 next = table[hsh];
                 table[hsh] = idx;

From eirbjo at gmail.com  Sat Jan 16 10:30:53 2021
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 16 Jan 2021 11:30:53 +0100
Subject: JDK-8242959 residual cleanup: Move encoding checks into ZipCoder
In-Reply-To: <CA+pBWhs3SWuEO-dcRBepdSprLahqAqYzc2mHcfDqVXxjKX+Ptg@mail.gmail.com>
References: <CA+pBWhs3SWuEO-dcRBepdSprLahqAqYzc2mHcfDqVXxjKX+Ptg@mail.gmail.com>
Message-ID: <CA+pBWhtrvzbRsE4-we=EZk3W0PZtw=-k66GrxeA+FcAKK-nq0A@mail.gmail.com>

> The following is purely a code cleanup/refactoring proposal for ZipFile
> internals:
>


> Here's a patch which implements the proposal. Sponsors are welcome :-)
>

I commited the proposal to a branch on my fork:
https://github.com/eirbjo/jdk/commit/be26f48f94b5eb8e9566a66e0509be998f34977f

Give me a hint if I should create a PR for this (not totally up to speed
with the current Skara process for such small changes)

Cheers,
Eirik.

From herrick at openjdk.java.net  Sat Jan 16 14:40:35 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Sat, 16 Jan 2021 14:40:35 GMT
Subject: Integrated: JDK-8259238: Clean up Log.java and remove usage of
 non-final static variables.
In-Reply-To: <gBD8pSjYTSaDX-I-1shActJPeKRSQlGkbmcuDydyqmY=.8e901e78-b133-48bb-8987-c0c77b99e77c@github.com>
References: <gBD8pSjYTSaDX-I-1shActJPeKRSQlGkbmcuDydyqmY=.8e901e78-b133-48bb-8987-c0c77b99e77c@github.com>
Message-ID: <1g-KkOTAAFxKKLElZ5kOtIW05wrTRmuHMAkqKBo1ipY=.a87c8d51-3445-43c9-b923-df2ddc0c8813@github.com>

On Thu, 7 Jan 2021 16:40:26 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8259238: Clean up Log.java and remove usage of non-final static variables.

This pull request has now been integrated.

Changeset: c3bdbf9d
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c3bdbf9d
Stats:     79 lines in 3 files changed: 12 ins; 49 del; 18 mod

8259238: Clean up Log.java and remove usage of non-final static variables.

Reviewed-by: asemenyuk, almatvee, kizune

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

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

From herrick at openjdk.java.net  Sat Jan 16 14:42:07 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Sat, 16 Jan 2021 14:42:07 GMT
Subject: Integrated: JDK-8258755: jpackage: Invalid 32-bit exe when building
 app-image
In-Reply-To: <s7PJA74O7GtTqPkaLzHQ033a9vlKG2ZfX6HCdgKmNZQ=.6cda02fc-bd7d-4d2b-ab1b-b3d7c5641b05@github.com>
References: <s7PJA74O7GtTqPkaLzHQ033a9vlKG2ZfX6HCdgKmNZQ=.6cda02fc-bd7d-4d2b-ab1b-b3d7c5641b05@github.com>
Message-ID: <0D-cTShnKoDKfN47AloOV2cKiWidP9VlOiU8rgP9z5s=.2e41d535-5c7b-492b-ac07-2d6bc70e75a0@github.com>

On Mon, 11 Jan 2021 17:42:21 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8258755: jpackage: Invalid 32-bit exe when building app-image

This pull request has now been integrated.

Changeset: da4cf05d
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/da4cf05d
Stats:     14 lines in 3 files changed: 10 ins; 0 del; 4 mod

8258755: jpackage: Invalid 32-bit exe when building app-image

Reviewed-by: asemenyuk, almatvee, kizune

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

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

From herrick at openjdk.java.net  Sat Jan 16 14:41:09 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Sat, 16 Jan 2021 14:41:09 GMT
Subject: Integrated:     JDK-8259062: Remove MacAppStoreBundler
In-Reply-To: <iAhpVYi8-wmDzRrnQjaUnPuFWuRI1NSwrlqi0LQVrPk=.f97b81e8-d7c9-4c09-9589-682c2c0afa1c@github.com>
References: <iAhpVYi8-wmDzRrnQjaUnPuFWuRI1NSwrlqi0LQVrPk=.f97b81e8-d7c9-4c09-9589-682c2c0afa1c@github.com>
Message-ID: <QBEhvYpkD0Z7cxDbdHZ2x2qLjQPlrQni89rDN6JgDN0=.323cb4f3-2bff-4a69-b0fa-e5496277e787@github.com>

On Wed, 6 Jan 2021 15:52:07 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8259062: Remove MacAppStoreBundler

This pull request has now been integrated.

Changeset: 6d6a23e3
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6d6a23e3
Stats:     265 lines in 2 files changed: 0 ins; 265 del; 0 mod

8259062: Remove MacAppStoreBundler

Reviewed-by: asemenyuk, almatvee, kizune

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

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

From claes.redestad at oracle.com  Sat Jan 16 16:58:30 2021
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 16 Jan 2021 17:58:30 +0100
Subject: JDK-8242959 residual cleanup: Move encoding checks into ZipCoder
In-Reply-To: <CA+pBWhtrvzbRsE4-we=EZk3W0PZtw=-k66GrxeA+FcAKK-nq0A@mail.gmail.com>
References: <CA+pBWhs3SWuEO-dcRBepdSprLahqAqYzc2mHcfDqVXxjKX+Ptg@mail.gmail.com>
 <CA+pBWhtrvzbRsE4-we=EZk3W0PZtw=-k66GrxeA+FcAKK-nq0A@mail.gmail.com>
Message-ID: <f1eed395-8c40-bae1-c6b0-730a55ac10cd@oracle.com>

Hi Eirik,

seems fine to me. I've created 
https://bugs.openjdk.java.net/browse/JDK-8259867 for this - so go ahead 
and create a PR using that. The bots
should guide you through the process. Let me know if there are any issues.

Thanks!

/Claes

On 2021-01-16 11:30, Eirik Bj?rsn?s wrote:
>> The following is purely a code cleanup/refactoring proposal for ZipFile
>> internals:
>>
> 
> 
>> Here's a patch which implements the proposal. Sponsors are welcome :-)
>>
> 
> I commited the proposal to a branch on my fork:
> https://github.com/eirbjo/jdk/commit/be26f48f94b5eb8e9566a66e0509be998f34977f
> 
> Give me a hint if I should create a PR for this (not totally up to speed
> with the current Skara process for such small changes)
> 
> Cheers,
> Eirik.
> 

From info at j-kuhn.de  Sat Jan 16 18:07:06 2021
From: info at j-kuhn.de (Johannes Kuhn)
Date: Sat, 16 Jan 2021 19:07:06 +0100
Subject: A Bug involving MethodHandles, Nestmates, Reflection and
 @CallerSensitive
In-Reply-To: <fa773926-c2cb-3359-d6a9-0bdd1a803756@j-kuhn.de>
References: <5d39710a-ab78-4953-3f9f-86fd1b34b5d9@j-kuhn.de>
 <8b92389c-1c02-785e-7d33-6ae8a30d2a1c@oracle.com>
 <54ee3c75-3533-15eb-cba0-c13e6e2cc73b@oracle.com>
 <d66cdf65-579d-bb2f-566e-e2201cd0ebcc@j-kuhn.de>
 <1b21c701-d266-c99d-80cd-ec7a423a1cd2@oracle.com>
 <ef05a376-0a7e-b579-a0fe-4086dccdd0fd@j-kuhn.de>
 <3f160ca4-1822-d4f6-148a-ddd30a7d737a@oracle.com>
 <fa773926-c2cb-3359-d6a9-0bdd1a803756@j-kuhn.de>
Message-ID: <10b12cda-02bd-5375-72b3-8867852e3e3a@j-kuhn.de>

After digging though the JBS, I found this comment from John Rose[1].

I like the general idea, but I don't think it's necessary to use a 
native method as stub. Instead it could be written like this:

class Class {
   @CallerSensitive
   @ForceInline
   public static Class<?> forName(String name) {
       return forName(name, Reflection.getCallerClass());
   }
   private static Class<?> forName(String name, Class<?> caller) {
       // original implementation
   }
}

By doing this, binding to the caller could be done by returning a 
MethodHandle that actually calls the private method - with the lookup 
class injected as argument (MethodHandles.insertArguments).

Problem are methods that could be virtually invoked 
(getContextClassLoader). Therefore it might be useful to keep the old 
binding logic around. It also reduces the number of places where this 
change has to be done - it's only required for the 
hyper- at CallerSensitive methods.

I will try to write a prototype that demonstrates that this approach is 
feasible.

- Johannes

[1]: 
https://bugs.openjdk.java.net/browse/JDK-8020968?focusedCommentId=13611844&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13611844

On 09-Dec-20 21:09, Johannes Kuhn wrote:
> On 09-Dec-20 19:44, Mandy Chung wrote:
>>
>>
>> On 12/8/20 6:02 PM, Johannes Kuhn wrote:
>>> There are a lot of things to consider when trying to fix JDK-8013527.
>>
>> Exactly in particular security implication!? What is clear is that the 
>> expected lookup class should not be the injected class.?? The key 
>> message here is that we can't fix JDK-8257874 until we fix JDK-8013527 
>> unfortunately.
>>
>> Mandy
>>
> Yeah, if JDK-8013527 is fixed it might fix JDK-8257874 as a byproduct.
> If Lookup.lookup() can determine the original caller, then 
> Field.set*/Method.invoke could do the same.
> Special care has to be taken that no other class could spoof such an 
> injected invoker.
> 
> Too complicated for me :). JDK-8013527 needs a sound design to approach 
> fixing it IMHO.
> 
> - Johannes
> 

From plevart at openjdk.java.net  Sun Jan 17 09:06:49 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Sun, 17 Jan 2021 09:06:49 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v4]
In-Reply-To: <5hl3I02WFDVBW77UXh0zILkJnWOZSnkX5nvW5u73WIQ=.b75c3ff5-1223-4d91-9068-9520680f6423@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
 <s6nULeiTJ3PmS4nJFxQmRlbVBXl_YjdCN-bZLJ1ufIo=.75c4ba1f-f8a1-429a-b0ca-bdb111dafa8d@github.com>
 <iDOZpWzvi1sJ6dAJst00IXQtlWHKhVfbbhuPln1dh_Y=.4baaf7b1-da39-4096-8d56-e8f2834c1f8b@github.com>
 <QGK3SH3c-2jklIZKNvoQXPjcQiJUvsrBRomiAM5B3yU=.adf46ff6-360f-44da-8d75-712099c28bde@github.com>
 <C2hp5Q-E126C9B42C922L6cO7vQRNlBBpsFf7f5euew=.31cdc7e7-c5e7-4432-8f3e-a44b92ff5ea6@github.com>
 <5hl3I02WFDVBW77UXh0zILkJnWOZSnkX5nvW5u73WIQ=.b75c3ff5-1223-4d91-9068-9520680f6423@github.com>
Message-ID: <7W_055nIb2Do90tTNSnZJrFZOWmTF9mfarsmLbHhCtc=.6bf9e989-017f-4410-be49-c0dd33119cc4@github.com>

On Sat, 16 Jan 2021 01:02:20 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Some common logic is now extracted into methods. That's good. But much of the decoding logic still remains in String. I still think all of static methods can be moved to StringCoding directly as they are now while the private UTF-8 decoding constructor can be replaced with static method and moved to StringCoding. The only problem might be the public String constructor taking Charset parameter. But even here, passing a newly constructed mutable object to the method can be used to return multiple values from the method while relying on JIT to eliminate object allocation.
>> Do you think this code belongs more to String than to StringCoding?
>
>> Do you think this code belongs more to String than to StringCoding?
> 
> I consider StringCoding an implementation detail of String, so I'm not sure there's (much) value in maintaining the separation of concern if it is cause for a performance loss. While encapsulating and separating concerns is a fine purpose I think the main purpose served by StringCoding is to resolve some bootstrap issues: String is one of the first classes to be loaded and eagerly pulling in dependencies like ThreadLocal and Charsets before bootstrapping leads to all manner of hard to decipher issues (yes - I've tried :-)).

This looks much better now. Maybe just one small suggestion: `java.lang.StringCoding#lookupCharset` is used in two places and in both places the same exception handling/rethrowing logic is wrapped around the invocation. So you could move that logic into the lookupCharset method which would simplify call sites. You could even get rid of String.lookupCharset method that way.

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

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

From plevart at openjdk.java.net  Sun Jan 17 09:24:33 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Sun, 17 Jan 2021 09:24:33 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v4]
In-Reply-To: <7W_055nIb2Do90tTNSnZJrFZOWmTF9mfarsmLbHhCtc=.6bf9e989-017f-4410-be49-c0dd33119cc4@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
 <s6nULeiTJ3PmS4nJFxQmRlbVBXl_YjdCN-bZLJ1ufIo=.75c4ba1f-f8a1-429a-b0ca-bdb111dafa8d@github.com>
 <iDOZpWzvi1sJ6dAJst00IXQtlWHKhVfbbhuPln1dh_Y=.4baaf7b1-da39-4096-8d56-e8f2834c1f8b@github.com>
 <QGK3SH3c-2jklIZKNvoQXPjcQiJUvsrBRomiAM5B3yU=.adf46ff6-360f-44da-8d75-712099c28bde@github.com>
 <C2hp5Q-E126C9B42C922L6cO7vQRNlBBpsFf7f5euew=.31cdc7e7-c5e7-4432-8f3e-a44b92ff5ea6@github.com>
 <5hl3I02WFDVBW77UXh0zILkJnWOZSnkX5nvW5u73WIQ=.b75c3ff5-1223-4d91-9068-9520680f6423@github.com>
 <7W_055nIb2Do90tTNSnZJrFZOWmTF9mfarsmLbHhCtc=.6bf9e989-017f-4410-be49-c0dd33119cc4@github.com>
Message-ID: <KSv_TELEL1yl7tdRYfTOnvFl4FyjgakNTEGL0E86mlY=.1f4324e6-5cef-448b-bf5b-494fb5d91df2@github.com>

On Sun, 17 Jan 2021 09:03:30 GMT, Peter Levart <plevart at openjdk.org> wrote:

>>> Do you think this code belongs more to String than to StringCoding?
>> 
>> I consider StringCoding an implementation detail of String, so I'm not sure there's (much) value in maintaining the separation of concern if it is cause for a performance loss. While encapsulating and separating concerns is a fine purpose I think the main purpose served by StringCoding is to resolve some bootstrap issues: String is one of the first classes to be loaded and eagerly pulling in dependencies like ThreadLocal and Charsets before bootstrapping leads to all manner of hard to decipher issues (yes - I've tried :-)).
>
> This looks much better now. Maybe just one small suggestion: `java.lang.StringCoding#lookupCharset` is used in two places and in both places the same exception handling/rethrowing logic is wrapped around the invocation. So you could move that logic into the lookupCharset method which would simplify call sites. You could even get rid of String.lookupCharset method that way.

When you combine the logic of String.lookupCharset:

    private static Charset lookupCharset(String charsetName)
            throws UnsupportedEncodingException {
        Objects.requireNonNull(charsetName);
        try {
            Charset cs = StringCoding.lookupCharset(charsetName);
            if (cs == null) {
                throw new UnsupportedEncodingException(charsetName);
            }
            return cs;
        } catch (IllegalCharsetNameException ics) {
            throw new UnsupportedEncodingException(charsetName);
        }
    }

... and StringCoding.lookupCharset:

    static Charset lookupCharset(String csn) {
        if (Charset.isSupported(csn)) {
            try {
                return Charset.forName(csn);
            } catch (UnsupportedCharsetException x) {
                throw new Error(x);
            }
        }
        return null;
    }


...you get this:

    private static Charset lookupCharset(String charsetName)
            throws UnsupportedEncodingException {
        Objects.requireNonNull(charsetName);
        try {
            Charset cs;
            inner: {
                if (Charset.isSupported(charsetName)) {
                    try {
                        cs = Charset.forName(charsetName);
                        break inner;
                    } catch (UnsupportedCharsetException x) {
                        throw new Error(x);
                    }
                }
                cs = null;
            }
            if (cs == null) {
                throw new UnsupportedEncodingException(charsetName);
            }
            return cs;
        } catch (IllegalCharsetNameException ics) {
            throw new UnsupportedEncodingException(charsetName);
        }
    }


...and that can be simplified to this:

    static Charset lookupCharset(String csn) throws UnsupportedEncodingException {
        Objects.requireNonNull(csn);
        try {
            return Charset.forName(csn);
        } catch (UnsupportedCharsetException | IllegalCharsetNameException x) {
            throw new UnsupportedEncodingException(csn);
        }
    }

which has an additional benefit that it only performs one lookup (Charset.forName) instead of two (Charset.isSupported & Charset.forName)...

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

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

From redestad at openjdk.java.net  Sun Jan 17 12:07:03 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sun, 17 Jan 2021 12:07:03 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v5]
In-Reply-To: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
Message-ID: <Gn-j8usIKLp6BMy56qojQ-C-rB-Z1NlChj8Dpu1vfJM=.fe918b60-d8ce-4f51-a10b-d93e4b8cb7d9@github.com>

> The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.
> 
> This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.
> 
> Microbenchmark results:
> Baseline
> 
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
> decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op
> 
> Patched:
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
> decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op
> 
> Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.
> 
> Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.
> 
> Testing: tier1-4

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Simplify lookupCharset

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2102/files
  - new: https://git.openjdk.java.net/jdk/pull/2102/files/4c8eacd1..790e7463

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

  Stats: 46 lines in 2 files changed: 3 ins; 26 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2102.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2102/head:pull/2102

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

From redestad at openjdk.java.net  Sun Jan 17 12:18:49 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sun, 17 Jan 2021 12:18:49 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v5]
In-Reply-To: <KSv_TELEL1yl7tdRYfTOnvFl4FyjgakNTEGL0E86mlY=.1f4324e6-5cef-448b-bf5b-494fb5d91df2@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
 <s6nULeiTJ3PmS4nJFxQmRlbVBXl_YjdCN-bZLJ1ufIo=.75c4ba1f-f8a1-429a-b0ca-bdb111dafa8d@github.com>
 <iDOZpWzvi1sJ6dAJst00IXQtlWHKhVfbbhuPln1dh_Y=.4baaf7b1-da39-4096-8d56-e8f2834c1f8b@github.com>
 <QGK3SH3c-2jklIZKNvoQXPjcQiJUvsrBRomiAM5B3yU=.adf46ff6-360f-44da-8d75-712099c28bde@github.com>
 <C2hp5Q-E126C9B42C922L6cO7vQRNlBBpsFf7f5euew=.31cdc7e7-c5e7-4432-8f3e-a44b92ff5ea6@github.com>
 <5hl3I02WFDVBW77UXh0zILkJnWOZSnkX5nvW5u73WIQ=.b75c3ff5-1223-4d91-9068-9520680f6423@github.com>
 <7W_055nIb2Do90tTNSnZJrFZOWmTF9mfarsmLbHhCtc=.6bf9e989-017f-4410-be49-c0dd33119cc4@github.com>
 <KSv_TELEL1yl7tdRYfTOnvFl4FyjgakNTEGL0E86mlY=.1f4324e6-5cef-448b-bf5b-494fb5d91df2@github.com>
Message-ID: <xg3RbMiMSd-bGkHUvMcnxlhEdmSQWId2t5o0I-biqm0=.37131602-a501-4a84-8280-9175975da513@github.com>

On Sun, 17 Jan 2021 09:21:27 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> This looks much better now. Maybe just one small suggestion: `java.lang.StringCoding#lookupCharset` is used in two places and in both places the same exception handling/rethrowing logic is wrapped around the invocation. So you could move that logic into the lookupCharset method which would simplify call sites. You could even get rid of String.lookupCharset method that way.
>
> When you combine the logic of String.lookupCharset:
> 
>     private static Charset lookupCharset(String charsetName)
>             throws UnsupportedEncodingException {
>         Objects.requireNonNull(charsetName);
>         try {
>             Charset cs = StringCoding.lookupCharset(charsetName);
>             if (cs == null) {
>                 throw new UnsupportedEncodingException(charsetName);
>             }
>             return cs;
>         } catch (IllegalCharsetNameException ics) {
>             throw new UnsupportedEncodingException(charsetName);
>         }
>     }
> 
> ... and StringCoding.lookupCharset:
> 
>     static Charset lookupCharset(String csn) {
>         if (Charset.isSupported(csn)) {
>             try {
>                 return Charset.forName(csn);
>             } catch (UnsupportedCharsetException x) {
>                 throw new Error(x);
>             }
>         }
>         return null;
>     }
> 
> 
> ...you get this:
> 
>     private static Charset lookupCharset(String charsetName)
>             throws UnsupportedEncodingException {
>         Objects.requireNonNull(charsetName);
>         try {
>             Charset cs;
>             inner: {
>                 if (Charset.isSupported(charsetName)) {
>                     try {
>                         cs = Charset.forName(charsetName);
>                         break inner;
>                     } catch (UnsupportedCharsetException x) {
>                         throw new Error(x);
>                     }
>                 }
>                 cs = null;
>             }
>             if (cs == null) {
>                 throw new UnsupportedEncodingException(charsetName);
>             }
>             return cs;
>         } catch (IllegalCharsetNameException ics) {
>             throw new UnsupportedEncodingException(charsetName);
>         }
>     }
> 
> 
> ...and that can be simplified to this:
> 
>     static Charset lookupCharset(String csn) throws UnsupportedEncodingException {
>         Objects.requireNonNull(csn);
>         try {
>             return Charset.forName(csn);
>         } catch (UnsupportedCharsetException | IllegalCharsetNameException x) {
>             throw new UnsupportedEncodingException(csn);
>         }
>     }
> 
> which has an additional benefit that it only performs one lookup (Charset.forName) instead of two (Charset.isSupported & Charset.forName)...

@plevart: I simplified the lookup logic based on your suggestion. Removed some unreachable paths in and simplified  `StringCoding.encode(String, byte, byte[])` as a result.

Simplifying to one lookup speeds up `decodeCharsetName` cases a notch:
before:
decodeCharsetName          UTF-8  avgt   15  370.337 ? 22.199  ns/op
after:
decodeCharsetName          UTF-8  avgt   15  335.971 ? 15.894  ns/op

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

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

From dholmes at openjdk.java.net  Sun Jan 17 12:58:43 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 17 Jan 2021 12:58:43 GMT
Subject: RFR: 8258917: NativeMemoryTracking is handled by launcher
 inconsistenly
In-Reply-To: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
References: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
Message-ID: <UE_59PhMZObtAkkTyP8iu9Sox2_pmCGNBTgSxTR2FLY=.24370d98-09b0-4f6f-8587-9cb6f3a55363@github.com>

On Fri, 15 Jan 2021 23:50:16 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix adds NMT handling for non-java launchers

Alex,

This approach results in two scans of the argument list in the IsJavaArgs case. I don't know if we care about startup in the non-Java launchers, but this will likely affect it.

David

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

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

From david.holmes at oracle.com  Sun Jan 17 13:03:26 2021
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 17 Jan 2021 23:03:26 +1000
Subject: RFR: 8258917: NativeMemoryTracking is handled by launcher
 inconsistenly
In-Reply-To: <UE_59PhMZObtAkkTyP8iu9Sox2_pmCGNBTgSxTR2FLY=.24370d98-09b0-4f6f-8587-9cb6f3a55363@github.com>
References: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
 <UE_59PhMZObtAkkTyP8iu9Sox2_pmCGNBTgSxTR2FLY=.24370d98-09b0-4f6f-8587-9cb6f3a55363@github.com>
Message-ID: <63357faa-2671-1b6f-8986-0b114f762a78@oracle.com>

On 17/01/2021 10:58 pm, David Holmes wrote:
> On Fri, 15 Jan 2021 23:50:16 GMT, Alex Menkov <amenkov at openjdk.org> wrote:
> 
>> The fix adds NMT handling for non-java launchers
> 
> Alex,
> 
> This approach results in two scans of the argument list in the IsJavaArgs case. I don't know if we care about startup in the non-Java launchers, but this will likely affect it.

Also, I'm not sure the scanning logic in SetJvmEnvironment is valid for 
the IsJavaArgs case. It states:

/*
  * Since this must be a VM flag we stop processing once we see
  * an argument the launcher would not have processed beyond (such
  * as -version or -h), or an argument that indicates the following
  * arguments are for the application (i.e. the main class name, or
  * the -jar argument).
  */

but the argument rules for other commands are different.

David

> David
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2106
> 

From plevart at openjdk.java.net  Sun Jan 17 14:59:52 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Sun, 17 Jan 2021 14:59:52 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v5]
In-Reply-To: <Gn-j8usIKLp6BMy56qojQ-C-rB-Z1NlChj8Dpu1vfJM=.fe918b60-d8ce-4f51-a10b-d93e4b8cb7d9@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
 <Gn-j8usIKLp6BMy56qojQ-C-rB-Z1NlChj8Dpu1vfJM=.fe918b60-d8ce-4f51-a10b-d93e4b8cb7d9@github.com>
Message-ID: <0Xh3NpY1mxrmojHLHIxUnhjW5pLsZJ61aQ80qqFIef4=.d508eb80-3b6c-436b-89c3-17a27cf99076@github.com>

On Sun, 17 Jan 2021 12:07:03 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.
>> 
>> This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.
>> 
>> Microbenchmark results:
>> Baseline
>> 
>> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
>> decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
>> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
>> decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
>> decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
>> decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
>> decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
>> decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
>> decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
>> decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
>> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op
>> 
>> Patched:
>> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
>> decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
>> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
>> decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
>> decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
>> decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
>> decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
>> decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
>> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op
>> 
>> Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.
>> 
>> Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.
>> 
>> Testing: tier1-4
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify lookupCharset

This looks good.
Are you planning to do similar things for encoding too?

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

Marked as reviewed by plevart (Reviewer).

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

From plevart at openjdk.java.net  Sun Jan 17 15:55:33 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Sun, 17 Jan 2021 15:55:33 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v5]
In-Reply-To: <0Xh3NpY1mxrmojHLHIxUnhjW5pLsZJ61aQ80qqFIef4=.d508eb80-3b6c-436b-89c3-17a27cf99076@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
 <Gn-j8usIKLp6BMy56qojQ-C-rB-Z1NlChj8Dpu1vfJM=.fe918b60-d8ce-4f51-a10b-d93e4b8cb7d9@github.com>
 <0Xh3NpY1mxrmojHLHIxUnhjW5pLsZJ61aQ80qqFIef4=.d508eb80-3b6c-436b-89c3-17a27cf99076@github.com>
Message-ID: <H9530gHCeT3bH1zU8Q65hEP1bLEsEgHOKwhImFeLeZU=.27b26dac-d7c2-4cc2-ba05-32f632f1ebed@github.com>

On Sun, 17 Jan 2021 14:56:40 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify lookupCharset
>
> This looks good.
> Are you planning to do similar things for encoding too?

I already approved the changes and they are OK. Maybe for a followup: just noticing after the fact that logic for `newStringUTF8NoRepl(....)` vs. `new String(...., StringCoding.UTF_8)` differ in handling unmappabale characters, which is by the spec, but also the constructor contains special handling of input that only contains non-negative bytes:

        if (charset == UTF_8) {
            if (COMPACT_STRINGS && !StringCoding.hasNegatives(bytes, offset, length)) {
                this.value = Arrays.copyOfRange(bytes, offset, offset + length);
                this.coder = LATIN1;
                return;

...while `newStringUTF8NoRepl(....)` does not contain this optimization. I guess ZipCoder could benefit from that optimization too since paths are mostly ASCII only. So WDYT of this additional simplification/consolidation of UTF-8 decoding:

https://github.com/plevart/jdk/commit/0b8b12c998e4ed451588442205ebe8f7423db7d8

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

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

From info at j-kuhn.de  Sun Jan 17 17:02:01 2021
From: info at j-kuhn.de (Johannes Kuhn)
Date: Sun, 17 Jan 2021 18:02:01 +0100
Subject: Trying to fix JDK-8013527 - 1st Prototype
Message-ID: <f77c559a-4125-b56b-803b-2de6b5e9c7a6@j-kuhn.de>

JDK-8013527[1] has somehow become the umbrella bug for "Using 
MethodHandles to call caller sensitive methods leads to interesting 
results".

To recap: A caller sensitive method knows about who called it, and can 
behave differently when called from an other context.
Examples are: Class.forName, MethodHandles.lookup, Method.invoke...

A MethodHandle on the other hand should not be caller sensitive.
To archive this, a MethodHandle will "bind" the lookup class as caller 
for caller sensitive methods.

This is currently done by injecting a hidden class (InjectedInvoker" 
that acts as a trampoline for calling caller sensitive methods.

This injected invoker shares many properties of the original caller:
Same ClassLoader, same Module, same Package, same ProtectionDomain, but 
it's not the same class or a nestmate of it.

For caller sensitive methods that do look at more than just the injected 
invoker, this leads to "unexpected" results when called through a 
MethodHandle:

* MethodHandles.lookup() returns a full privileged lookup for the 
injected invoker.
* jlr.Field.get*/set*, jlr.Constructor.newInstance, jlr.Method.invoke 
may fail with an IllegalAccessException if the target is private. See 
JDK-8257874[2].

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

After reading one of John Rose's comments[3], I thought that this might 
be a way to solve this general problem.

So I implemented some of it here[4].

The basic idea is that there is a private overload of the caller 
sensitive method which accepts the caller as a tailing argument.

The good news:
* tier1 Tests pass.
* ((Lookup) lookup.findStatic(MethodHandles.class, "lookup", 
MethodType.methodType(Lookup.class)).invokeExact()).lookupClass() == 
lookup.lookupClass();
* JDK-8257874 can't be reproduced with Field.* or Constructor.
* Performance is likely better. (InjectedInvoker collects all arguments 
into an Object[].)

The bad news:
* If you use a MethodHandle to call Method.invoke for a caller sensitive 
method, then you can still observe the injected invoker.

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

Moving forward, there are 3 ways:
1. Do nothing. Won't fix any bug.
2. Use the current prototype, and accept Method.invoke is odd when 
calling it through a MethodHandle.
3. Go all in:
   * Require **every** caller sensitive method to have a private overload.
   * Method.invoke will also use that private overload.

The problems with the 3rd approach are:
   * What about methods that can be called virtually? 
(Thread.getContextClassLoader())
   * Requires a few changes to MethodAccessor. Maybe implementing 
JDK-6824466[5] first?
   * What about methods that do stack walks?

I have to think more about the problems listed above - but maybe you 
have some input that could help me on that.

- Johannes


[1]: https://bugs.openjdk.java.net/browse/JDK-8013527
[2]: https://bugs.openjdk.java.net/browse/JDK-8257874
[3]: 
https://bugs.openjdk.java.net/browse/JDK-8020968?focusedCommentId=13611844&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13611844
[4]: https://github.com/openjdk/jdk/pull/2117/files
[5]: https://bugs.openjdk.java.net/browse/JDK-6824466

From kustos at gmx.net  Sun Jan 17 17:48:04 2021
From: kustos at gmx.net (Philippe Marschall)
Date: Sun, 17 Jan 2021 18:48:04 +0100
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer)
In-Reply-To: <FhXV1UKPiHE7wey3jjBBJjQzLpKZPhe5aD4sGKneMz0=.16c382e1-b55c-4d63-8538-4e68adfca109@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <4qIH_bGcy898jYpAfO_Ahwpv63-gDAcA-XEQX-O30pg=.8ad77702-353c-4c6b-8010-1b89f729c691@github.com>
 <FhXV1UKPiHE7wey3jjBBJjQzLpKZPhe5aD4sGKneMz0=.16c382e1-b55c-4d63-8538-4e68adfca109@github.com>
Message-ID: <addf994f-ee6a-c9f7-535e-50f1dce454f7@gmx.net>



On 05.01.21 01:53, Brian Burkhalter wrote:
> On Thu, 31 Dec 2020 10:11:58 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:
> ...
>
> How does the performance of `InputStreamReader.read(CharBuffer)` compare for the case where only the change to `Reader` is made versus if all your proposed changes are applied?

I left the delegating one in InputStreamReader in but removed all
changes in StreamDecoder. Performance looks pretty good:

on-heap CharBuffer
- Throughput is a slightly lower than with the changes but close and
still better than before.
- Allocation rate is drastically reduced and comparable to the results
with the changes except for small buffer sizes (128 bytes).

off-heap CharBuffer
- Relative throughput depends on the buffer size. For small buffers (128
bytes) throughput is a bit lower than master but increases with buffer
size. For 1 KB buffers it is about even, for 1 MB buffers it is better.
Throughput is a lot better than with the StreamDecoder changes without
intermediate allocation, there we lose about one half to two thirds of
throughput.
- Allocation rate stays high (1.5 - 3 GB/s) and only drops with large
buffer sizes (1 MB) to 20 - 30 MB/s. The StreamDecoder changes cause the
allocation rate to drop to almost zero.

To be honest backing out of the StreamDecoder changes looks like a good
comprise to me to reduce the risk while still improving throughput and
reducing allocation rate, especially in the on-heap path.

Looking a bit further I wonder if CharArrayReader and StringReader
should implement #read(CharBuffer) as well and call CharBuffer#put
directly. And maybe even #transferTo(Writer).


Cheers
Philippe

From martin at openjdk.java.net  Sun Jan 17 18:43:55 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sun, 17 Jan 2021 18:43:55 GMT
Subject: [jdk16] RFR: 8259796: timed CompletableFuture.get may swallow
 InterruptedException
Message-ID: <upVu9OHkTffhtfvPrngQeLxwklUoxJNUGWMbnZvtAhA=.9ca40e17-fb47-4f22-ba77-43ae248c8ceb@github.com>

8259796: timed CompletableFuture.get may swallow InterruptedException

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

Commit messages:
 - JDK-8259796

Changes: https://git.openjdk.java.net/jdk16/pull/126/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=126&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259796
  Stats: 87 lines in 2 files changed: 28 ins; 26 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/126/head:pull/126

PR: https://git.openjdk.java.net/jdk16/pull/126

From dl at openjdk.java.net  Sun Jan 17 18:54:41 2021
From: dl at openjdk.java.net (Doug Lea)
Date: Sun, 17 Jan 2021 18:54:41 GMT
Subject: [jdk16] RFR: 8259796: timed CompletableFuture.get may swallow
 InterruptedException
In-Reply-To: <upVu9OHkTffhtfvPrngQeLxwklUoxJNUGWMbnZvtAhA=.9ca40e17-fb47-4f22-ba77-43ae248c8ceb@github.com>
References: <upVu9OHkTffhtfvPrngQeLxwklUoxJNUGWMbnZvtAhA=.9ca40e17-fb47-4f22-ba77-43ae248c8ceb@github.com>
Message-ID: <rKLw9iFV9jEz598JIzlEtufC7BohhhOSiTZCLYtCpwU=.215500fc-4bc1-454d-8d8d-754745cc1bb8@github.com>

On Sun, 17 Jan 2021 18:39:55 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> 8259796: timed CompletableFuture.get may swallow InterruptedException

Marked as reviewed by dl (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/126

From martin at openjdk.java.net  Sun Jan 17 20:30:47 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sun, 17 Jan 2021 20:30:47 GMT
Subject: RFR: 8252412: [macos11] File-based loading of dynamic libraries
 deprecated
Message-ID: <JKwrbNjv57HU-WVqocbD9Z7X27cPVFczIFOOKlzpOQ4=.cb6d6cb8-afe7-486e-ba3b-e41ba8ad47cf@github.com>

8252412: [macos11] File-based loading of dynamic libraries deprecated

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

Commit messages:
 - JDK-8252412: [macos11] File-based loading of dynamic libraries deprecated

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

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

From redestad at openjdk.java.net  Sun Jan 17 22:42:53 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sun, 17 Jan 2021 22:42:53 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v6]
In-Reply-To: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
Message-ID: <9RDwEg_7nXh2l2-ZS5LtPG5vg6FhCUthuRO6pcoM0Xc=.7ab4077c-0263-48ea-ac01-fd2a34d17b95@github.com>

> The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.
> 
> This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.
> 
> Microbenchmark results:
> Baseline
> 
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
> decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op
> 
> Patched:
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
> decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op
> 
> Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.
> 
> Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.
> 
> Testing: tier1-4

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  ASCII fast-path missing for UTF-8 NoRepl methods

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2102/files
  - new: https://git.openjdk.java.net/jdk/pull/2102/files/790e7463..e870b3bb

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

  Stats: 65 lines in 1 file changed: 25 ins; 20 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2102.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2102/head:pull/2102

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

From redestad at openjdk.java.net  Sun Jan 17 22:42:54 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sun, 17 Jan 2021 22:42:54 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v5]
In-Reply-To: <H9530gHCeT3bH1zU8Q65hEP1bLEsEgHOKwhImFeLeZU=.27b26dac-d7c2-4cc2-ba05-32f632f1ebed@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
 <Gn-j8usIKLp6BMy56qojQ-C-rB-Z1NlChj8Dpu1vfJM=.fe918b60-d8ce-4f51-a10b-d93e4b8cb7d9@github.com>
 <0Xh3NpY1mxrmojHLHIxUnhjW5pLsZJ61aQ80qqFIef4=.d508eb80-3b6c-436b-89c3-17a27cf99076@github.com>
 <H9530gHCeT3bH1zU8Q65hEP1bLEsEgHOKwhImFeLeZU=.27b26dac-d7c2-4cc2-ba05-32f632f1ebed@github.com>
Message-ID: <PuKHdtFbIcnP9sxE-0RZrvO6sCKRcRRSQaRCxbqZWho=.f63c9d78-ebb8-4686-a22b-8c8db9987eee@github.com>

On Sun, 17 Jan 2021 15:51:58 GMT, Peter Levart <plevart at openjdk.org> wrote:

> `newStringUTF8NoRepl(....)` does not contain this optimization.

Good catch: this optimization was in the original code for `newStringNoRepl` but not `newStringUTF8NoRepl`. I'll put it back to avoid a regression, but this time into `newStringUTF8NoRepl` so that both paths get the optimization.

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

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

From ljiang at openjdk.java.net  Mon Jan 18 05:52:57 2021
From: ljiang at openjdk.java.net (Leo Jiang)
Date: Mon, 18 Jan 2021 05:52:57 GMT
Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg
 drop 10 [v3]
In-Reply-To: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
References: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
Message-ID: <VR1_KkzLukMWQ9XA_kj1FBe43uAJDkK85cOZjB60vvU=.d08b1f75-a587-4cb5-9a63-46243a4126b9@github.com>

> This is the changes for JDK 16 msg drop 10.

Leo Jiang has updated the pull request incrementally with one additional commit since the last revision:

  fix the missing copyright year for standard.properties

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/123/files
  - new: https://git.openjdk.java.net/jdk16/pull/123/files/d72f444a..9c7574e2

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

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

PR: https://git.openjdk.java.net/jdk16/pull/123

From ljiang at openjdk.java.net  Mon Jan 18 05:52:57 2021
From: ljiang at openjdk.java.net (Leo Jiang)
Date: Mon, 18 Jan 2021 05:52:57 GMT
Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg
 drop 10 [v2]
In-Reply-To: <F3h1x-ZgNClOKHsAunvSztkl9XxmH7cP9YPZoz_O08I=.2d76925f-b12f-49c0-9631-94e663df59e3@github.com>
References: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
 <QceWk9N7q2iV9alfICITS0Sdr8eacuR15Mrihph-doI=.1cee427c-0be1-4cb9-8a77-098696ddd5da@github.com>
 <ZkHoKP8fL7uRj0TIiwqYtVch0eyxQGv2JeY-BDgf310=.91ef28d1-d91b-4b37-aa9f-edd81b94f235@github.com>
 <1Bb8sf6zFDnQSM5kRQIlrgBNwEpO-IvxsPmN05F0QFs=.13eb3035-71d5-4310-98e5-d9989e51cf60@github.com>
 <F3h1x-ZgNClOKHsAunvSztkl9XxmH7cP9YPZoz_O08I=.2d76925f-b12f-49c0-9631-94e663df59e3@github.com>
Message-ID: <GwheKm_jhEEkNScvPOWJL_eye7kQD7VXk6gLUi09JKQ=.8e7a23d0-f978-4734-99c3-e6f611f380e9@github.com>

On Sat, 16 Jan 2021 00:48:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Actually I was correcting the L217, changed {) -> {}. But 2 days ago, Jonathan Gibbons fixed it in another commit 6bb6093. I found his fix after running the merge. Looks both of us forgot to update the copyright year. Any suggestion? 
>> doclet.help.systemProperties.body=\
>>     The {0} page lists references to system properties.
>
> I believe your PR still contains the fix to add the newline at the end of the file (at L518). So I think you can simply change the copyright year in `standard.properties` file.

Thx! Fixed the copyright year for this file.

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

PR: https://git.openjdk.java.net/jdk16/pull/123

From github.com+471021+marschall at openjdk.java.net  Mon Jan 18 07:09:55 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Mon, 18 Jan 2021 07:09:55 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v4]
In-Reply-To: <tEZQI1hwWbNe6n5aZmAJYWN2xpTqwntGtNNVTIsjQ5Q=.82cbeddb-8468-4b4f-a770-a25b9c5f5acf@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <E8UILDsjWetV8n_CS6BsLUpAS9YNOyFup_zlV0uXaNY=.7df5871c-da6d-41e8-a0a5-c39503e50297@github.com>
 <tEZQI1hwWbNe6n5aZmAJYWN2xpTqwntGtNNVTIsjQ5Q=.82cbeddb-8468-4b4f-a770-a25b9c5f5acf@github.com>
Message-ID: <37Kl80k2O6NjyqhlmduaOoRL12IJAd-4b1oBRFgZSGc=.272f8b3a-77d8-4471-96bd-2acf17600298@github.com>

On Sun, 10 Jan 2021 01:59:18 GMT, Brett Okken <github.com+2996845+bokken at openjdk.org> wrote:

>> Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add unit tests
>>   
>>   - add unit test for Reader#read(CharBuffer)
>>   - add unit test for InputStreamReader#reader(CharBuffer)
>>   - test with both on-heap and off-heap buffers
>
> src/java.base/share/classes/java/io/Reader.java line 198:
> 
>> 196:         } else {
>> 197:             int remaining = target.remaining();
>> 198:             char cbuf[] = new char[Math.min(remaining, TRANSFER_BUFFER_SIZE)];
> 
> Would there be value in making this a (lazily created) member variable? That would allow a single instance to be reused. It seems likely that, if one call is made with a direct CharBuffer, subsequent calls will also be made with direct instances (probably same instance?).

I am not sure. It would help to reduce the allocation rate when reading a large amount of data into a small direct CharBuffer. I don't know how common that is. We would introduce an instance variable for one path in one method.

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

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

From plevart at openjdk.java.net  Mon Jan 18 08:57:43 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Mon, 18 Jan 2021 08:57:43 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v4]
In-Reply-To: <E8UILDsjWetV8n_CS6BsLUpAS9YNOyFup_zlV0uXaNY=.7df5871c-da6d-41e8-a0a5-c39503e50297@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <E8UILDsjWetV8n_CS6BsLUpAS9YNOyFup_zlV0uXaNY=.7df5871c-da6d-41e8-a0a5-c39503e50297@github.com>
Message-ID: <66uDvXvRZ0UyNV93dFYWuQ-xp7GM-eVjCxsP-Aa0fMY=.46a98be7-25d9-4091-8db2-5b25beb5a9b1@github.com>

On Sat, 9 Jan 2021 23:06:22 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Implement three optimiztations for Reader.read(CharBuffer)
>> 
>> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
>> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
>> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
>
> Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add unit tests
>   
>   - add unit test for Reader#read(CharBuffer)
>   - add unit test for InputStreamReader#reader(CharBuffer)
>   - test with both on-heap and off-heap buffers

src/java.base/share/classes/java/io/Reader.java line 207:

> 205:                         target.put(cbuf, 0, n);
> 206:                         nread += n;
> 207:                         remaining -= n;

Wouldn't there be a possibility for target.put(cbuf, 0, n) to throw BufferOverflowException ?
For example:
- there's room (remaining) for TRANSFER_BUFFER_SIZE + 1 characters in target
- cbuff is sized to TRANSFER_BUFFER_SIZE
- 1st iteration of do loop transfers TRANSFER_BUFFER_SIZE charasters (remaining == 1)
- 2nd iteration reads > 1 (up to TRANSFER_BUFFER_SIZE) characters
- target.put throws BufferOverflowException

You have to limit the amount read in each iteration to be Math.min(remaining, cbuf.length)

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

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

From redestad at openjdk.java.net  Mon Jan 18 09:26:07 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 18 Jan 2021 09:26:07 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v7]
In-Reply-To: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
Message-ID: <gQ0oYc4HZ8xGckOI1z0gIyPciGhc35j7eomAl97fiZY=.1301b699-a513-4322-9e7c-17de21f5e6b2@github.com>

> The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.
> 
> This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.
> 
> Microbenchmark results:
> Baseline
> 
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
> decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op
> 
> Patched:
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
> decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op
> 
> Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.
> 
> Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.
> 
> Testing: tier1-4

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Harmonize empty string checking in newString methods

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2102/files
  - new: https://git.openjdk.java.net/jdk/pull/2102/files/e870b3bb..ba279a7e

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

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

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

From martin at openjdk.java.net  Mon Jan 18 11:03:06 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Mon, 18 Jan 2021 11:03:06 GMT
Subject: RFR: 8252412: [macos11] system dynamic libraries removed from
 filesystem [v2]
In-Reply-To: <JKwrbNjv57HU-WVqocbD9Z7X27cPVFczIFOOKlzpOQ4=.cb6d6cb8-afe7-486e-ba3b-e41ba8ad47cf@github.com>
References: <JKwrbNjv57HU-WVqocbD9Z7X27cPVFczIFOOKlzpOQ4=.cb6d6cb8-afe7-486e-ba3b-e41ba8ad47cf@github.com>
Message-ID: <5u4w-g-wpqqVp3GHPon_vNOhT2Mq0lAowl74fFZwCms=.fc5d8f4c-7e4a-47a4-ad10-02dbe281f16f@github.com>

> 8252412: [macos11] system dynamic libraries removed from filesystem

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. The pull request contains one new commit since the last revision:

  JDK-8252412: [macos11] system dynamic libraries removed from filesystem

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2119/files
  - new: https://git.openjdk.java.net/jdk/pull/2119/files/578329f0..85fdffde

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

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

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

From redestad at openjdk.java.net  Mon Jan 18 12:16:00 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 18 Jan 2021 12:16:00 GMT
Subject: RFR: 8259911: byteArrayViewVarHandle should throw
 ArrayIndexOutOfBoundsException
Message-ID: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com>

Change `MethodHandles.byteArrayViewVarHandle` to throw `ArrayIndexOutOfBoundsException` rather than the more generic `IndexArrayOutOfBoundsException`. This feels more natural, and reduces the risk for subtle behavioral mismatch when migrating code from arrays/Unsafe to VHs. 

CSR: [JDK-8259912](https://bugs.openjdk.java.net/browse/JDK-8259912)

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

Commit messages:
 - byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException

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

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

From redestad at openjdk.java.net  Mon Jan 18 12:58:20 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 18 Jan 2021 12:58:20 GMT
Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests [v3]
In-Reply-To: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
References: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
Message-ID: <h6aP24Btn2X7hVXHCoa9tJor4VDpQ1nHx9Mv4HZowEw=.5c31294c-c9ad-43ba-ae25-7a99be6a6748@github.com>

> - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration
> - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization.
> - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence.
> 
> Baseline:
>                               (digesterName)  (length)    Cnt     Score      Error   Units
> MessageDigests.digest                                MD5        16     15  2714.307 ?   21.133  ops/ms
> MessageDigests.digest                                MD5      1024     15   318.087 ?    0.637  ops/ms
> MessageDigests.digest                              SHA-1        16     15  1387.266 ?   40.932  ops/ms
> MessageDigests.digest                              SHA-1      1024     15   109.273 ?    0.149  ops/ms
> MessageDigests.digest                            SHA-256        16     15   995.566 ?   21.186  ops/ms
> MessageDigests.digest                            SHA-256      1024     15    89.104 ?    0.079  ops/ms
> MessageDigests.digest                            SHA-512        16     15   803.030 ?   15.722  ops/ms
> MessageDigests.digest                            SHA-512      1024     15   115.611 ?    0.234  ops/ms
> MessageDigests.getAndDigest                          MD5        16     15  2190.367 ?   97.037  ops/ms
> MessageDigests.getAndDigest                          MD5      1024     15   302.903 ?    1.809  ops/ms
> MessageDigests.getAndDigest                        SHA-1        16     15  1262.656 ?   43.751  ops/ms
> MessageDigests.getAndDigest                        SHA-1      1024     15   104.889 ?    3.554  ops/ms
> MessageDigests.getAndDigest                      SHA-256        16     15   914.541 ?   55.621  ops/ms
> MessageDigests.getAndDigest                      SHA-256      1024     15    85.708 ?    1.394  ops/ms
> MessageDigests.getAndDigest                      SHA-512        16     15   737.719 ?   53.671  ops/ms
> MessageDigests.getAndDigest                      SHA-512      1024     15   112.307 ?    1.950  ops/ms
> 
> GC:
> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   312.011 ?    0.005    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.020 ?    0.006    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   544.019 ?    0.016    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15  1056.037 ?    0.003    B/op
> 
> Target:
> Benchmark                                 (digesterName)  (length)    Cnt     Score      Error   Units
> MessageDigests.digest                                MD5        16     15  3134.462 ?   43.685  ops/ms
> MessageDigests.digest                                MD5      1024     15   323.667 ?    0.633  ops/ms
> MessageDigests.digest                              SHA-1        16     15  1418.742 ?   38.223  ops/ms
> MessageDigests.digest                              SHA-1      1024     15   110.178 ?    0.788  ops/ms
> MessageDigests.digest                            SHA-256        16     15  1037.949 ?   21.214  ops/ms
> MessageDigests.digest                            SHA-256      1024     15    89.671 ?    0.228  ops/ms
> MessageDigests.digest                            SHA-512        16     15   812.028 ?   39.489  ops/ms
> MessageDigests.digest                            SHA-512      1024     15   116.738 ?    0.249  ops/ms
> MessageDigests.getAndDigest                          MD5        16     15  2314.379 ?  229.294  ops/ms
> MessageDigests.getAndDigest                          MD5      1024     15   307.835 ?    5.730  ops/ms
> MessageDigests.getAndDigest                        SHA-1        16     15  1326.887 ?   63.263  ops/ms
> MessageDigests.getAndDigest                        SHA-1      1024     15   106.611 ?    2.292  ops/ms
> MessageDigests.getAndDigest                      SHA-256        16     15   961.589 ?   82.052  ops/ms
> MessageDigests.getAndDigest                      SHA-256      1024     15    88.646 ?    0.194  ops/ms
> MessageDigests.getAndDigest                      SHA-512        16     15   775.417 ?   56.775  ops/ms
> MessageDigests.getAndDigest                      SHA-512      1024     15   112.904 ?    2.014  ops/ms
> 
> GC
> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   232.009 ?    0.006    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.021 ?    0.001    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   272.012 ?    0.015    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15   400.017 ?    0.019    B/op
> 
> For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW.
> 
> For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test.
> 
> I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show.

Claes Redestad 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 22 additional commits since the last revision:

 - Adjust to keep reflection-driven tests from failing
 - Merge branch 'master' into improve_md5
 - Copyrights
 - Merge branch 'master' into improve_md5
 - Remove unused Unsafe import
 - Harmonize MD4 impl, remove now-redundant checks from ByteArrayAccess (VHs do bounds checks, most of which will be optimized away)
 - Merge branch 'master' into improve_md5
 - Apply allocation avoiding optimizations to all SHA versions sharing structural similarities with MD5
 - Remove unused reverseBytes imports
 - Copyrights
 - ... and 12 more: https://git.openjdk.java.net/jdk/compare/25fa448d...fdd2d19e

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1855/files
  - new: https://git.openjdk.java.net/jdk/pull/1855/files/cafa3e49..fdd2d19e

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

  Stats: 11783 lines in 75 files changed: 1309 ins; 9196 del; 1278 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1855.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1855/head:pull/1855

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

From magnus.ihse.bursie at oracle.com  Mon Jan 18 13:21:07 2021
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 18 Jan 2021 14:21:07 +0100
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <20210115102709.538599954@eggemoggin.niobe.net>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
 <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
 <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>
 <20210115102709.538599954@eggemoggin.niobe.net>
Message-ID: <0219364d-3926-2b7b-4cb5-90f698eeb706@oracle.com>

On 2021-01-15 19:27, mark.reinhold at oracle.com wrote:
> Feature JEPs are living documents until such time as they are delivered.
> In this case it would not be appropriate to update JEP 201, which is as
> much about the transition from the old source-code layout as it is about
> the new layout as of 2014.
>
> At this point, and given that we?d already gone beyond JEP 201 prior to
> this change (with `man` and `lib` subdirectories), what?d make the most
> sense is a new informational JEP that documents the source-code layout.
> Informational JEPs can, within reason, be updated over time.
So I take it I need to create a new informational JEP. :-) Fine, I can 
do that. I assume I mostly need to extract the parts of JEP 201 that 
describes the (then "new") layout, update wording to show that this is a 
description of the current layout, and add the new additions.

It'll be a very short JEP, but in this case, that's probably a virtue.

/Magnus

From redestad at openjdk.java.net  Mon Jan 18 13:39:04 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 18 Jan 2021 13:39:04 GMT
Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests [v4]
In-Reply-To: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
References: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
Message-ID: <Fgyp3R-dyor_O80NO9PyMFy-_hy1WxbtBr-M6uGloP8=.f9fbf907-8419-41b7-b028-4adaa610e69d@github.com>

> - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration
> - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization.
> - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence.
> 
> Baseline:
>                               (digesterName)  (length)    Cnt     Score      Error   Units
> MessageDigests.digest                                MD5        16     15  2714.307 ?   21.133  ops/ms
> MessageDigests.digest                                MD5      1024     15   318.087 ?    0.637  ops/ms
> MessageDigests.digest                              SHA-1        16     15  1387.266 ?   40.932  ops/ms
> MessageDigests.digest                              SHA-1      1024     15   109.273 ?    0.149  ops/ms
> MessageDigests.digest                            SHA-256        16     15   995.566 ?   21.186  ops/ms
> MessageDigests.digest                            SHA-256      1024     15    89.104 ?    0.079  ops/ms
> MessageDigests.digest                            SHA-512        16     15   803.030 ?   15.722  ops/ms
> MessageDigests.digest                            SHA-512      1024     15   115.611 ?    0.234  ops/ms
> MessageDigests.getAndDigest                          MD5        16     15  2190.367 ?   97.037  ops/ms
> MessageDigests.getAndDigest                          MD5      1024     15   302.903 ?    1.809  ops/ms
> MessageDigests.getAndDigest                        SHA-1        16     15  1262.656 ?   43.751  ops/ms
> MessageDigests.getAndDigest                        SHA-1      1024     15   104.889 ?    3.554  ops/ms
> MessageDigests.getAndDigest                      SHA-256        16     15   914.541 ?   55.621  ops/ms
> MessageDigests.getAndDigest                      SHA-256      1024     15    85.708 ?    1.394  ops/ms
> MessageDigests.getAndDigest                      SHA-512        16     15   737.719 ?   53.671  ops/ms
> MessageDigests.getAndDigest                      SHA-512      1024     15   112.307 ?    1.950  ops/ms
> 
> GC:
> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   312.011 ?    0.005    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.020 ?    0.006    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   544.019 ?    0.016    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15  1056.037 ?    0.003    B/op
> 
> Target:
> Benchmark                                 (digesterName)  (length)    Cnt     Score      Error   Units
> MessageDigests.digest                                MD5        16     15  3134.462 ?   43.685  ops/ms
> MessageDigests.digest                                MD5      1024     15   323.667 ?    0.633  ops/ms
> MessageDigests.digest                              SHA-1        16     15  1418.742 ?   38.223  ops/ms
> MessageDigests.digest                              SHA-1      1024     15   110.178 ?    0.788  ops/ms
> MessageDigests.digest                            SHA-256        16     15  1037.949 ?   21.214  ops/ms
> MessageDigests.digest                            SHA-256      1024     15    89.671 ?    0.228  ops/ms
> MessageDigests.digest                            SHA-512        16     15   812.028 ?   39.489  ops/ms
> MessageDigests.digest                            SHA-512      1024     15   116.738 ?    0.249  ops/ms
> MessageDigests.getAndDigest                          MD5        16     15  2314.379 ?  229.294  ops/ms
> MessageDigests.getAndDigest                          MD5      1024     15   307.835 ?    5.730  ops/ms
> MessageDigests.getAndDigest                        SHA-1        16     15  1326.887 ?   63.263  ops/ms
> MessageDigests.getAndDigest                        SHA-1      1024     15   106.611 ?    2.292  ops/ms
> MessageDigests.getAndDigest                      SHA-256        16     15   961.589 ?   82.052  ops/ms
> MessageDigests.getAndDigest                      SHA-256      1024     15    88.646 ?    0.194  ops/ms
> MessageDigests.getAndDigest                      SHA-512        16     15   775.417 ?   56.775  ops/ms
> MessageDigests.getAndDigest                      SHA-512      1024     15   112.904 ?    2.014  ops/ms
> 
> GC
> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   232.009 ?    0.006    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.021 ?    0.001    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   272.012 ?    0.015    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15   400.017 ?    0.019    B/op
> 
> For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW.
> 
> For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test.
> 
> I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1855/files
  - new: https://git.openjdk.java.net/jdk/pull/1855/files/fdd2d19e..4c2798aa

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

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

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

From jiefu at openjdk.java.net  Mon Jan 18 13:39:58 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 18 Jan 2021 13:39:58 GMT
Subject: RFR: 8259925: [Vector API] Unreasonable IndexOutOfBoundsException
 message when length < vlen
Message-ID: <IXlGGauVhUjxPJXm8CjZ0Eo4-ySUttJ_EqYpxiW7p8E=.32dc9082-78ad-4407-a6a2-3652dfef8a4c@github.com>

Hi all,

For this reproducer:

import jdk.incubator.vector.ByteVector;
import jdk.incubator.vector.VectorSpecies;

public class Test {
    static final VectorSpecies<Byte> SPECIES_128 = ByteVector.SPECIES_128;
    static byte[] a = new byte[8];
    static byte[] b = new byte[8];

    public static void main(String[] args) {
        ByteVector av = ByteVector.fromArray(SPECIES_128, a, 0);
        av.intoArray(b, 0);
        System.out.println("b: " + b[0]);
    }
}

The following IndexOutOfBoundsException message (length -7) is unreasonable.

Exception in thread "main" java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length -7

It might be better to fix it like this.

Exception in thread "main" java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0

Thanks.
Best regards,
Jie

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

Commit messages:
 - 8259925: [Vector API] Unreasonable IndexOutOfBoundsException message when length < vlen

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

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

From ihse at openjdk.java.net  Mon Jan 18 13:47:20 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 18 Jan 2021 13:47:20 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v5]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <VOISxSWArxxc_b4jkanMxAHICUEnv3wmh7yub1so5yg=.f062b37b-e0ef-4362-be5f-f73f170f3438@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Move characterdata templates to share/classes/java/lang.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/68b252b5..c4894348

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

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

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

From ihse at openjdk.java.net  Mon Jan 18 13:49:49 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 18 Jan 2021 13:49:49 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v4]
In-Reply-To: <ABB2Pleoo1GTfmn0SdjrztH_u6VrfPRseLfMIrYhMdg=.a576b5bc-b25b-43ee-b5d3-394bce1415ca@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>
 <YT7on7W1w9GJRTMfz2KtftKo7yGbVTgZxYcqXv1POBU=.59b49a13-da41-4c93-88c7-1830b87d0b63@github.com>
 <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com>
 <ABB2Pleoo1GTfmn0SdjrztH_u6VrfPRseLfMIrYhMdg=.a576b5bc-b25b-43ee-b5d3-394bce1415ca@github.com>
Message-ID: <JqU9ob7JdM95DwwPcGJTrFB-r1b8QTl5Y8GijSHLoCc=.829f75d9-a1de-47db-8b58-f4fe2d312a2a@github.com>

On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR is not stale; it's just still waiting for input from @AlanBateman.
>
> @magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang?

@AlanBateman When I moved the charset templates, I found this gold nugget:

# Copy two Java files that need no preprocessing.
$(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java: $(CHARACTERDATA_TEMPLATES)/%.java.template
	$(call LogInfo, Generating $(@F))
	$(call install-file)

GENSRC_CHARACTERDATA += $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataUndefined.java \
    $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataPrivateUse.java

What this means is that we have two "template" files that are just compiled as java files, but only after being copied to gensrc. :-) That definitely needs cleaning up, but this PR is large enough as it is, so I will not do it now.

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

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

From kbarrett at openjdk.java.net  Mon Jan 18 15:36:13 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 18 Jan 2021 15:36:13 GMT
Subject: RFR: 8132984: incorrect type for Reference.discovered [v2]
In-Reply-To: <xbEchOYCSxsfs7NxI3XoI7pKuD2X2jjicmZv2vRSoug=.ac0c74b8-c8a3-427d-90fa-279a2090bc83@github.com>
References: <xbEchOYCSxsfs7NxI3XoI7pKuD2X2jjicmZv2vRSoug=.ac0c74b8-c8a3-427d-90fa-279a2090bc83@github.com>
Message-ID: <SW7h5Om_ALVfM1EeG5YLe8laLVJE9WOKXFUYnrl8bYk=.52cb3240-c679-45a9-93c0-161f811f91c5@github.com>

> Please review this change which fixes the type of the private
> Reference.discovered field.  It was Reference<T>, but that's wrong because
> it can be any Reference object.
> 
> I've changed it to Reference<?> and let that flow through, updating some
> other variables that were previously somewhat incorrectly typed (usually
> with an Object type parameter). The interesting change is to the
> ReferenceQueue.enqueue parameter, which is now also Reference<?>.
> 
> This ultimately end up with a provably safe and correct, but uncheckable,
> cast in ReferenceQueue.enqueue.
> 
> An alternative might be to use a raw type for the discovered field, but I
> think that ends up with more @SuppressWarnings of various flavors.  I think
> the unbounded wildcard approach is clearer and cleaner.
> 
> Note that all of the pending list handling, including the discovered field,
> could be moved into a non-public, non-generic, sealed(?) base class of
> Reference<T>.  The pending list handling has nothing to do with the generic
> parameter T.
> 
> Testing:
> mach5 tier1 and tier4 (tier4 is where vmTestbase_vm_gc_ref tests are run)

Kim Barrett 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:

 - update copyrights
 - Merge branch 'master' into fix_discovered_type
 - Use unbounded wildcard placeholders and final safe but unchecked cast

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1897/files
  - new: https://git.openjdk.java.net/jdk/pull/1897/files/ff250a19..80415b71

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

  Stats: 62902 lines in 1944 files changed: 22288 ins; 24876 del; 15738 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1897.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1897/head:pull/1897

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

From jlaskey at openjdk.java.net  Mon Jan 18 16:38:09 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 18 Jan 2021 16:38:09 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v13]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <noMoxUotuEBOVhhM3YGKiO_WyXecLL9omRGuD_6Gb1U=.b6ced45b-8383-414f-8b4a-9959f201c643@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

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

 - Merge branch 'master' into 8248862
 - Correct range used by nextBytes
 - Merge branch 'master' into 8248862
 - Use annotation for properties. Add getDefault().
 - Merge branch 'master' into 8248862
 - Introduce RandomGeneratorProperties annotation
 - Merge branch 'master' into 8248862
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Added coverage testing
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Cleanups from Chris H.
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Propagate exception
 - ... and 30 more: https://git.openjdk.java.net/jdk/compare/061ffc47...772abef6

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

Changes: https://git.openjdk.java.net/jdk/pull/1292/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=12
  Stats: 13205 lines in 26 files changed: 11043 ins; 2046 del; 116 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

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

From jlaskey at openjdk.java.net  Mon Jan 18 16:45:00 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 18 Jan 2021 16:45:00 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v14]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <E0-BDWvabmEyn-UQgb52JyxyoUlezyKlmvJNm81f6dw=.eb3d6e3f-5581-4152-9a6d-d6634c100e0e@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update package info to credit LMX algorithm

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/772abef6..38369702

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

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

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

From plevart at openjdk.java.net  Mon Jan 18 17:28:57 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Mon, 18 Jan 2021 17:28:57 GMT
Subject: RFR: 8132984: incorrect type for Reference.discovered
In-Reply-To: <xbEchOYCSxsfs7NxI3XoI7pKuD2X2jjicmZv2vRSoug=.ac0c74b8-c8a3-427d-90fa-279a2090bc83@github.com>
References: <xbEchOYCSxsfs7NxI3XoI7pKuD2X2jjicmZv2vRSoug=.ac0c74b8-c8a3-427d-90fa-279a2090bc83@github.com>
Message-ID: <u56V6ruBJOLsx0sO3qvY0m3tyBFY1uAkWKLj7wyBxhE=.6689cd37-3e5c-49d3-b388-fc45ba12b34a@github.com>

On Sat, 26 Dec 2020 03:25:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change which fixes the type of the private
> Reference.discovered field.  It was Reference<T>, but that's wrong because
> it can be any Reference object.
> 
> I've changed it to Reference<?> and let that flow through, updating some
> other variables that were previously somewhat incorrectly typed (usually
> with an Object type parameter). The interesting change is to the
> ReferenceQueue.enqueue parameter, which is now also Reference<?>.
> 
> This ultimately end up with a provably safe and correct, but uncheckable,
> cast in ReferenceQueue.enqueue.
> 
> An alternative might be to use a raw type for the discovered field, but I
> think that ends up with more @SuppressWarnings of various flavors.  I think
> the unbounded wildcard approach is clearer and cleaner.
> 
> Note that all of the pending list handling, including the discovered field,
> could be moved into a non-public, non-generic, sealed(?) base class of
> Reference<T>.  The pending list handling has nothing to do with the generic
> parameter T.
> 
> Testing:
> mach5 tier1 and tier4 (tier4 is where vmTestbase_vm_gc_ref tests are run)

Hi Kim,

If you introduce a private method in Reference:

    private void enqueueFromPending() {
        var q = queue;
        if (q != ReferenceQueue.NULL) q.enqueue(this);
    }

...and use it Reference.processPendingReferences while loop like this:

            if (ref instanceof Cleaner) {
                ...
            } else {
                ref.enqueueFromPending();
            }

Then you can keep the signature of `ReferenceQueue.enqueue(Reference<? extends T> r)` and no unchecked casts are needed there.

But what you have is OK and much better than what was before.

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

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

From plevart at openjdk.java.net  Mon Jan 18 17:35:39 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Mon, 18 Jan 2021 17:35:39 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v7]
In-Reply-To: <gQ0oYc4HZ8xGckOI1z0gIyPciGhc35j7eomAl97fiZY=.1301b699-a513-4322-9e7c-17de21f5e6b2@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
 <gQ0oYc4HZ8xGckOI1z0gIyPciGhc35j7eomAl97fiZY=.1301b699-a513-4322-9e7c-17de21f5e6b2@github.com>
Message-ID: <S1mW_NV9Z_7iVoEenKL_Y2SHYP9CdpkJ5gEvAQZfjPw=.6a6c24ce-40f6-43f8-9d25-a457217354df@github.com>

On Mon, 18 Jan 2021 09:26:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.
>> 
>> This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.
>> 
>> Microbenchmark results:
>> Baseline
>> 
>> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
>> decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
>> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
>> decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
>> decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
>> decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
>> decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
>> decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
>> decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
>> decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
>> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op
>> 
>> Patched:
>> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
>> decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
>> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
>> decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
>> decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
>> decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
>> decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
>> decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
>> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op
>> 
>> Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.
>> 
>> Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.
>> 
>> Testing: tier1-4
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Harmonize empty string checking in newString methods

This looks good, Claes.

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

Marked as reviewed by plevart (Reviewer).

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

From eirbjo at gmail.com  Mon Jan 18 18:34:16 2021
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 18 Jan 2021 19:34:16 +0100
Subject: Performance regression in BuiltinClassLoader?
Message-ID: <CA+pBWhvBH7wdYMb5TK6N3fxPj4sqgFgKOz1VB7Tnk_UiA6rZow@mail.gmail.com>

Hello,

I've been looking into ZipFile again with the aim to speed up typical
enterprise classloading / resource lookups.

To test the performance impact of my changes, I made a benchmark which
creates an EnterpriseClassLoader (subclass of URLClassLoader) with the jar
files in Spring Petclinic (89 jars with ~30k entries total).

(This is intentionally implemented using a plain main method with no JMH or
warmup since I want to measure a representative cold application startup)

The benchmark measures the time needed to call getResource 30K times, once
for each entry name.

Using 15.0.1, this completes in ~1700 ms
Using 17 master, it completes in 12851 ms

If I run the benchmark from the classpath instead of as a module, the
result is even worse:

15: 1724 ms
17: 21885 ms

If also measure GC collections and times, and get the following:

15:
Collections: 4
Collection time: 12 ms

17:
Collections: 24
Collection time: 44 ms

(However, a JHM with -prof gc indicates that both 17 and 15 allocate
~5.6Kb/getResource after warmup, so not convinced this needs to be
allocation related)

The EnterpriseClassLoader is a bit clever in that it can perform lookups
using different strategies: Regular parent-first, self-only, or use the
bootstrap / platform system classloaders directly.

Here are the results on 17 using each strategy (benchmark on class path):

PARENT_DELEGATION: 23111 ms
SELF_ONLY: 428 ms
BOOTSTRAP: 8131 ms
PLATFORM: 15149 ms
SYSTEM: 20628 ms

Here are the same results on 15:

PARENT_DELEGATION: 1691 ms
SELF_ONLY: 393 ms
BOOTSTRAP: 579 ms
PLATFORM: 908 ms
SYSTEM: 1368 ms

Note that the delegation chain is Enterprise -> System -> Platform ->
Bootstrap.

Interesting to note that URLClassLoader itself does not seem to regress
much when only looking up its own resources, while delegating up the chain
does.

Has there been any significant work in class loading / resource lookup
since 15.0.1 that could help explain this regression?

Eirik.

From afarley at openjdk.java.net  Mon Jan 18 18:32:56 2021
From: afarley at openjdk.java.net (Adam Farley)
Date: Mon, 18 Jan 2021 18:32:56 GMT
Subject: RFR: 8259942: Enable customizations in CompileJavaModules.gmk and
 Main.gmk
Message-ID: <lGcSs585GzMeSgmtT4URd8HyXS3DASDnA7Eqh2MiwDI=.4a837643-c62f-4244-87d8-17797a4b2427@github.com>

Ensure make files look on the include path or in PHASE_MAKEDIRS for
customizations.

Change also adds a tidy-up that improves readability.

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

Commit messages:
 - 8259942: Enable customizations in CompileJavaModules.gmk and Main.gmk

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

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

From eirbjo at gmail.com  Mon Jan 18 18:37:13 2021
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 18 Jan 2021 19:37:13 +0100
Subject: Performance regression in BuiltinClassLoader?
In-Reply-To: <CA+pBWhvBH7wdYMb5TK6N3fxPj4sqgFgKOz1VB7Tnk_UiA6rZow@mail.gmail.com>
References: <CA+pBWhvBH7wdYMb5TK6N3fxPj4sqgFgKOz1VB7Tnk_UiA6rZow@mail.gmail.com>
Message-ID: <CA+pBWhuSDA0FEzEmvrod_4cjtPTvuxcEGQKWk22MZb4x0KjqCA@mail.gmail.com>

For reference, here's the EnterpriseClassloader benchmark I made.

It assumes you have the jar files from Spring Petclinic in BOOT-INF/lib
(but any large collection of jars should work).

public class ZIPBenchmark {

    public static void main(String[] args) {

        final File libDir = new File("BOOT-INF/lib/");

        final Strategy strategy = Strategy.valueOf(args[0]);

        EnterpriseClassLoader classLoader =
EnterpriseClassLoader.create(libDir, strategy);

        final List<String> names = classLoader.getNames();


        long gcTimeBefore = 0;
        long gcCountBefore = 0;
        for (GarbageCollectorMXBean bean :
ManagementFactory.getGarbageCollectorMXBeans()) {
            gcCountBefore += bean.getCollectionCount();
            gcTimeBefore += bean.getCollectionTime();
        }


        long before = System.nanoTime();



        for (String name : names) {
            classLoader.getResource(name);
        }

        long gcTimeAfter  = 0;
        long gcCountAfter = 0;
        for (GarbageCollectorMXBean bean :
ManagementFactory.getGarbageCollectorMXBeans()) {
            gcCountAfter += bean.getCollectionCount();
            gcTimeAfter += bean.getCollectionTime();
        }

        final long time = System.nanoTime() - before;

        System.out.printf("%s: took %s ms\n", strategy,
TimeUnit.NANOSECONDS.toMillis(time));
        System.out.printf("Collections: %s\n", gcCountAfter-gcCountBefore);
        System.out.printf("Collection time: %s ms\n",
gcTimeAfter-gcTimeBefore);

    }



    public enum Strategy {
        SELF_ONLY, BOOTSTRAP, PLATFORM, SYSTEM, PARENT_DELEGATION
    }


    private static class EnterpriseClassLoader extends URLClassLoader {
        private final List<String> names;

        private final Strategy lookupStrategy;

        public EnterpriseClassLoader(URL[] urls, List<String> names,
Strategy strategy) {
            super(urls, strategy == Strategy.BOOTSTRAP ? null :
ClassLoader.getSystemClassLoader());
            this.names = names;
            this.lookupStrategy = strategy;
        }

        public static EnterpriseClassLoader create(File libDir, Strategy
strategy) {
            final File[] jarFiles = libDir.listFiles(f ->
f.getName().endsWith(".jar"));

            final URL[] urls = Stream.of(jarFiles)
                    .map(File::toURI).map(EnterpriseClassLoader::toURL)
                    .toArray(URL[]::new);

            List<String> names = Stream.of(jarFiles)
                    .flatMap(EnterpriseClassLoader::entryNameStream)
                    .collect(Collectors.toList());

            return new EnterpriseClassLoader(urls, names, strategy);
        }

        @Override
        public URL getResource(String name) {
            if(lookupStrategy == Strategy.BOOTSTRAP) {
                return super.getResource(name);
            } else if (lookupStrategy == Strategy.PLATFORM) {
                return
ClassLoader.getPlatformClassLoader().getResource(name);
            } else if (lookupStrategy == Strategy.SYSTEM) {
                return ClassLoader.getSystemClassLoader().getResource(name);
            } else if(lookupStrategy == Strategy.PARENT_DELEGATION) {
                return super.getResource(name);
            } else if(lookupStrategy == Strategy.SELF_ONLY) {
                return super.findResource(name);
            } else {
                throw new IllegalStateException("Unknown strategy");
            }
        }

        @Override
        public URL findResource(String name) {
            if(lookupStrategy == Strategy.BOOTSTRAP) {
                return null;
            } else {
                return super.findResource(name);
            }
        }

        private static Stream<String> entryNameStream(File url) {
            List<String> names;
            try (JarFile file = new JarFile(url)) {

                names = file.stream()
                        .map(ZipEntry::getName)
                        .filter(name -> name.endsWith(".class"))
                        .collect(Collectors.toList());

            } catch (IOException e) {
                throw new RuntimeException(e);
            }
            return names.stream();
        }

        private static URL toURL(URI uri) {
            try {
                return uri.toURL();
            } catch (MalformedURLException e) {
                throw new RuntimeException(e);
            }
        }
        public List<String> getNames() {
            return names;
        }

    }


}

On Mon, Jan 18, 2021 at 7:34 PM Eirik Bj?rsn?s <eirbjo at gmail.com> wrote:

>
> Hello,
>
> I've been looking into ZipFile again with the aim to speed up typical
> enterprise classloading / resource lookups.
>
> To test the performance impact of my changes, I made a benchmark which
> creates an EnterpriseClassLoader (subclass of URLClassLoader) with the jar
> files in Spring Petclinic (89 jars with ~30k entries total).
>
> (This is intentionally implemented using a plain main method with no JMH
> or warmup since I want to measure a representative cold application startup)
>
> The benchmark measures the time needed to call getResource 30K times, once
> for each entry name.
>
> Using 15.0.1, this completes in ~1700 ms
> Using 17 master, it completes in 12851 ms
>
> If I run the benchmark from the classpath instead of as a module, the
> result is even worse:
>
> 15: 1724 ms
> 17: 21885 ms
>
> If also measure GC collections and times, and get the following:
>
> 15:
> Collections: 4
> Collection time: 12 ms
>
> 17:
> Collections: 24
> Collection time: 44 ms
>
> (However, a JHM with -prof gc indicates that both 17 and 15 allocate
> ~5.6Kb/getResource after warmup, so not convinced this needs to be
> allocation related)
>
> The EnterpriseClassLoader is a bit clever in that it can perform lookups
> using different strategies: Regular parent-first, self-only, or use the
> bootstrap / platform system classloaders directly.
>
> Here are the results on 17 using each strategy (benchmark on class path):
>
> PARENT_DELEGATION: 23111 ms
> SELF_ONLY: 428 ms
> BOOTSTRAP: 8131 ms
> PLATFORM: 15149 ms
> SYSTEM: 20628 ms
>
> Here are the same results on 15:
>
> PARENT_DELEGATION: 1691 ms
> SELF_ONLY: 393 ms
> BOOTSTRAP: 579 ms
> PLATFORM: 908 ms
> SYSTEM: 1368 ms
>
> Note that the delegation chain is Enterprise -> System -> Platform ->
> Bootstrap.
>
> Interesting to note that URLClassLoader itself does not seem to regress
> much when only looking up its own resources, while delegating up the chain
> does.
>
> Has there been any significant work in class loading / resource lookup
> since 15.0.1 that could help explain this regression?
>
> Eirik.
>
>
>

From eirbjo at gmail.com  Mon Jan 18 18:59:55 2021
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 18 Jan 2021 19:59:55 +0100
Subject: Performance regression in BuiltinClassLoader?
In-Reply-To: <CA+pBWhvBH7wdYMb5TK6N3fxPj4sqgFgKOz1VB7Tnk_UiA6rZow@mail.gmail.com>
References: <CA+pBWhvBH7wdYMb5TK6N3fxPj4sqgFgKOz1VB7Tnk_UiA6rZow@mail.gmail.com>
Message-ID: <CA+pBWhsxLfe4cQ_5NZGOCqxjm6OJ-=Mxy3Yqo+rshTKWET0=3w@mail.gmail.com>

I also measured the actual startup time of Spring Petclinic to assess
real-life impact. Although there is some variance from run to run, it does
seem to regress:

15: Typical startup time 7500 - 7800 ms
17: Typical startup time: 8100 - 8700 ms

Eirik.

On Mon, Jan 18, 2021 at 7:34 PM Eirik Bj?rsn?s <eirbjo at gmail.com> wrote:

>
> Hello,
>
> I've been looking into ZipFile again with the aim to speed up typical
> enterprise classloading / resource lookups.
>
> To test the performance impact of my changes, I made a benchmark which
> creates an EnterpriseClassLoader (subclass of URLClassLoader) with the jar
> files in Spring Petclinic (89 jars with ~30k entries total).
>
> (This is intentionally implemented using a plain main method with no JMH
> or warmup since I want to measure a representative cold application startup)
>
> The benchmark measures the time needed to call getResource 30K times, once
> for each entry name.
>
> Using 15.0.1, this completes in ~1700 ms
> Using 17 master, it completes in 12851 ms
>
> If I run the benchmark from the classpath instead of as a module, the
> result is even worse:
>
> 15: 1724 ms
> 17: 21885 ms
>
> If also measure GC collections and times, and get the following:
>
> 15:
> Collections: 4
> Collection time: 12 ms
>
> 17:
> Collections: 24
> Collection time: 44 ms
>
> (However, a JHM with -prof gc indicates that both 17 and 15 allocate
> ~5.6Kb/getResource after warmup, so not convinced this needs to be
> allocation related)
>
> The EnterpriseClassLoader is a bit clever in that it can perform lookups
> using different strategies: Regular parent-first, self-only, or use the
> bootstrap / platform system classloaders directly.
>
> Here are the results on 17 using each strategy (benchmark on class path):
>
> PARENT_DELEGATION: 23111 ms
> SELF_ONLY: 428 ms
> BOOTSTRAP: 8131 ms
> PLATFORM: 15149 ms
> SYSTEM: 20628 ms
>
> Here are the same results on 15:
>
> PARENT_DELEGATION: 1691 ms
> SELF_ONLY: 393 ms
> BOOTSTRAP: 579 ms
> PLATFORM: 908 ms
> SYSTEM: 1368 ms
>
> Note that the delegation chain is Enterprise -> System -> Platform ->
> Bootstrap.
>
> Interesting to note that URLClassLoader itself does not seem to regress
> much when only looking up its own resources, while delegating up the chain
> does.
>
> Has there been any significant work in class loading / resource lookup
> since 15.0.1 that could help explain this regression?
>
> Eirik.
>
>
>

From eirbjo at gmail.com  Mon Jan 18 19:24:50 2021
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 18 Jan 2021 20:24:50 +0100
Subject: Performance regression in BuiltinClassLoader?
In-Reply-To: <CA+pBWhsxLfe4cQ_5NZGOCqxjm6OJ-=Mxy3Yqo+rshTKWET0=3w@mail.gmail.com>
References: <CA+pBWhvBH7wdYMb5TK6N3fxPj4sqgFgKOz1VB7Tnk_UiA6rZow@mail.gmail.com>
 <CA+pBWhsxLfe4cQ_5NZGOCqxjm6OJ-=Mxy3Yqo+rshTKWET0=3w@mail.gmail.com>
Message-ID: <CA+pBWhvWkH3E-+97XYP2_XOK=6p=iKmNKCmsA29zpKUmPc-K_A@mail.gmail.com>

For good measure, I did a JFR recording which revealed that
ExplodedModuleReader was doing file stat in 263 of 277 native method
samples.

Which lie explains all this, since the 15 I used was not shipped with
exploded jmods..

How do I build OpenJDK with packaged modules?

Cheers,
Eirik.

On Mon, Jan 18, 2021 at 7:59 PM Eirik Bj?rsn?s <eirbjo at gmail.com> wrote:

>
> I also measured the actual startup time of Spring Petclinic to assess
> real-life impact. Although there is some variance from run to run, it does
> seem to regress:
>
> 15: Typical startup time 7500 - 7800 ms
> 17: Typical startup time: 8100 - 8700 ms
>
> Eirik.
>
> On Mon, Jan 18, 2021 at 7:34 PM Eirik Bj?rsn?s <eirbjo at gmail.com> wrote:
>
>>
>> Hello,
>>
>> I've been looking into ZipFile again with the aim to speed up typical
>> enterprise classloading / resource lookups.
>>
>> To test the performance impact of my changes, I made a benchmark which
>> creates an EnterpriseClassLoader (subclass of URLClassLoader) with the jar
>> files in Spring Petclinic (89 jars with ~30k entries total).
>>
>> (This is intentionally implemented using a plain main method with no JMH
>> or warmup since I want to measure a representative cold application startup)
>>
>> The benchmark measures the time needed to call getResource 30K times,
>> once for each entry name.
>>
>> Using 15.0.1, this completes in ~1700 ms
>> Using 17 master, it completes in 12851 ms
>>
>> If I run the benchmark from the classpath instead of as a module, the
>> result is even worse:
>>
>> 15: 1724 ms
>> 17: 21885 ms
>>
>> If also measure GC collections and times, and get the following:
>>
>> 15:
>> Collections: 4
>> Collection time: 12 ms
>>
>> 17:
>> Collections: 24
>> Collection time: 44 ms
>>
>> (However, a JHM with -prof gc indicates that both 17 and 15 allocate
>> ~5.6Kb/getResource after warmup, so not convinced this needs to be
>> allocation related)
>>
>> The EnterpriseClassLoader is a bit clever in that it can perform lookups
>> using different strategies: Regular parent-first, self-only, or use the
>> bootstrap / platform system classloaders directly.
>>
>> Here are the results on 17 using each strategy (benchmark on class path):
>>
>> PARENT_DELEGATION: 23111 ms
>> SELF_ONLY: 428 ms
>> BOOTSTRAP: 8131 ms
>> PLATFORM: 15149 ms
>> SYSTEM: 20628 ms
>>
>> Here are the same results on 15:
>>
>> PARENT_DELEGATION: 1691 ms
>> SELF_ONLY: 393 ms
>> BOOTSTRAP: 579 ms
>> PLATFORM: 908 ms
>> SYSTEM: 1368 ms
>>
>> Note that the delegation chain is Enterprise -> System -> Platform ->
>> Bootstrap.
>>
>> Interesting to note that URLClassLoader itself does not seem to regress
>> much when only looking up its own resources, while delegating up the chain
>> does.
>>
>> Has there been any significant work in class loading / resource lookup
>> since 15.0.1 that could help explain this regression?
>>
>> Eirik.
>>
>>
>>

From Alan.Bateman at oracle.com  Mon Jan 18 19:31:29 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 18 Jan 2021 19:31:29 +0000
Subject: Performance regression in BuiltinClassLoader?
In-Reply-To: <CA+pBWhvWkH3E-+97XYP2_XOK=6p=iKmNKCmsA29zpKUmPc-K_A@mail.gmail.com>
References: <CA+pBWhvBH7wdYMb5TK6N3fxPj4sqgFgKOz1VB7Tnk_UiA6rZow@mail.gmail.com>
 <CA+pBWhsxLfe4cQ_5NZGOCqxjm6OJ-=Mxy3Yqo+rshTKWET0=3w@mail.gmail.com>
 <CA+pBWhvWkH3E-+97XYP2_XOK=6p=iKmNKCmsA29zpKUmPc-K_A@mail.gmail.com>
Message-ID: <fc7a9385-24aa-c86c-e3a7-e59276131972@oracle.com>

On 18/01/2021 19:24, Eirik Bj?rsn?s wrote:
> For good measure, I did a JFR recording which revealed that
> ExplodedModuleReader was doing file stat in 263 of 277 native method
> samples.
>
> Which lie explains all this, since the 15 I used was not shipped with
> exploded jmods..
>
> How do I build OpenJDK with packaged modules?
>
Have you done "make images"? You should see images/jdk in your build output.

-Alan

From eirbjo at gmail.com  Mon Jan 18 19:35:54 2021
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 18 Jan 2021 20:35:54 +0100
Subject: Performance regression in BuiltinClassLoader?
In-Reply-To: <fc7a9385-24aa-c86c-e3a7-e59276131972@oracle.com>
References: <CA+pBWhvBH7wdYMb5TK6N3fxPj4sqgFgKOz1VB7Tnk_UiA6rZow@mail.gmail.com>
 <CA+pBWhsxLfe4cQ_5NZGOCqxjm6OJ-=Mxy3Yqo+rshTKWET0=3w@mail.gmail.com>
 <CA+pBWhvWkH3E-+97XYP2_XOK=6p=iKmNKCmsA29zpKUmPc-K_A@mail.gmail.com>
 <fc7a9385-24aa-c86c-e3a7-e59276131972@oracle.com>
Message-ID: <CA+pBWhvwhk5vvr9X0eZ2t-CFG_ODxjTS864060i1GD5TQnLVoQ@mail.gmail.com>

Alan,

I have been using "make images" all along. This
produces build/macosx-x86_64-server-release/jdk/modules with unpacked
modules.

I'm a bit confused since "make help" seems to indicate that "make jdk"
should create unpacked modules, while "make images" should perhaps not? Or
did I misunderstand?

Eirik.



On Mon, Jan 18, 2021 at 8:31 PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 18/01/2021 19:24, Eirik Bj?rsn?s wrote:
> > For good measure, I did a JFR recording which revealed that
> > ExplodedModuleReader was doing file stat in 263 of 277 native method
> > samples.
> >
> > Which lie explains all this, since the 15 I used was not shipped with
> > exploded jmods..
> >
> > How do I build OpenJDK with packaged modules?
> >
> Have you done "make images"? You should see images/jdk in your build
> output.
>
> -Alan
>

From kim.barrett at oracle.com  Mon Jan 18 19:51:27 2021
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 18 Jan 2021 14:51:27 -0500
Subject: RFR: 8132984: incorrect type for Reference.discovered
In-Reply-To: <u56V6ruBJOLsx0sO3qvY0m3tyBFY1uAkWKLj7wyBxhE=.6689cd37-3e5c-49d3-b388-fc45ba12b34a@github.com>
References: <xbEchOYCSxsfs7NxI3XoI7pKuD2X2jjicmZv2vRSoug=.ac0c74b8-c8a3-427d-90fa-279a2090bc83@github.com>
 <u56V6ruBJOLsx0sO3qvY0m3tyBFY1uAkWKLj7wyBxhE=.6689cd37-3e5c-49d3-b388-fc45ba12b34a@github.com>
Message-ID: <91745301-A3ED-4C8B-B47E-C0EAAAE816F4@oracle.com>

> On Jan 18, 2021, at 12:28 PM, Peter Levart <plevart at openjdk.java.net> wrote:
> If you introduce a private method in Reference:
> 
>    private void enqueueFromPending() {
>        var q = queue;
>        if (q != ReferenceQueue.NULL) q.enqueue(this);
>    }
> 
> ...and use it Reference.processPendingReferences while loop like this:
> 
>            if (ref instanceof Cleaner) {
>                ...
>            } else {
>                ref.enqueueFromPending();
>            }
> 
> Then you can keep the signature of `ReferenceQueue.enqueue(Reference<? extends T> r)` and no unchecked casts are needed there.

Nice!  And this reverts all changes to ReferenceQueue.java

> But what you have is OK and much better than what was before.

Thanks, but I?m going to take your improvement.  I?ll update the PR once I?ve re-run some tests.


From Alan.Bateman at oracle.com  Mon Jan 18 19:53:05 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 18 Jan 2021 19:53:05 +0000
Subject: Performance regression in BuiltinClassLoader?
In-Reply-To: <CA+pBWhvwhk5vvr9X0eZ2t-CFG_ODxjTS864060i1GD5TQnLVoQ@mail.gmail.com>
References: <CA+pBWhvBH7wdYMb5TK6N3fxPj4sqgFgKOz1VB7Tnk_UiA6rZow@mail.gmail.com>
 <CA+pBWhsxLfe4cQ_5NZGOCqxjm6OJ-=Mxy3Yqo+rshTKWET0=3w@mail.gmail.com>
 <CA+pBWhvWkH3E-+97XYP2_XOK=6p=iKmNKCmsA29zpKUmPc-K_A@mail.gmail.com>
 <fc7a9385-24aa-c86c-e3a7-e59276131972@oracle.com>
 <CA+pBWhvwhk5vvr9X0eZ2t-CFG_ODxjTS864060i1GD5TQnLVoQ@mail.gmail.com>
Message-ID: <9bc7df81-e06a-8565-c59e-824cc0bbe874@oracle.com>

On 18/01/2021 19:35, Eirik Bj?rsn?s wrote:
>
> Alan,
>
> I have been using "make images" all along. This 
> produces?build/macosx-x86_64-server-release/jdk/modules with unpacked 
> modules.
>
build/macosx-x86_64-server-release/jdk is an "exploded image". Think of 
it as an intermediate build or step in the build. If you are doing "make 
images" then you should been an images build in 
build/macosx-x86_64-server-release/images/jdk.

-Alan.

From eirbjo at gmail.com  Mon Jan 18 19:53:17 2021
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 18 Jan 2021 20:53:17 +0100
Subject: Performance regression in BuiltinClassLoader?
In-Reply-To: <CA+pBWhvwhk5vvr9X0eZ2t-CFG_ODxjTS864060i1GD5TQnLVoQ@mail.gmail.com>
References: <CA+pBWhvBH7wdYMb5TK6N3fxPj4sqgFgKOz1VB7Tnk_UiA6rZow@mail.gmail.com>
 <CA+pBWhsxLfe4cQ_5NZGOCqxjm6OJ-=Mxy3Yqo+rshTKWET0=3w@mail.gmail.com>
 <CA+pBWhvWkH3E-+97XYP2_XOK=6p=iKmNKCmsA29zpKUmPc-K_A@mail.gmail.com>
 <fc7a9385-24aa-c86c-e3a7-e59276131972@oracle.com>
 <CA+pBWhvwhk5vvr9X0eZ2t-CFG_ODxjTS864060i1GD5TQnLVoQ@mail.gmail.com>
Message-ID: <CA+pBWhtnva58JL-jq1qkfm3vjL1RqD1wpfzv0eMTLpVOEPZwCA@mail.gmail.com>

Alan,

Apologies for wasting everyone's time (my own included, although I learned
a lot!)

I found images/jdk, and with that there is no regression.

Back to square one :-)

Thanks,
Eirik.


On Mon, Jan 18, 2021 at 8:35 PM Eirik Bj?rsn?s <eirbjo at gmail.com> wrote:

>
> Alan,
>
> I have been using "make images" all along. This
> produces build/macosx-x86_64-server-release/jdk/modules with unpacked
> modules.
>
> I'm a bit confused since "make help" seems to indicate that "make jdk"
> should create unpacked modules, while "make images" should perhaps not? Or
> did I misunderstand?
>
> Eirik.
>
>
>
> On Mon, Jan 18, 2021 at 8:31 PM Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 18/01/2021 19:24, Eirik Bj?rsn?s wrote:
>> > For good measure, I did a JFR recording which revealed that
>> > ExplodedModuleReader was doing file stat in 263 of 277 native method
>> > samples.
>> >
>> > Which lie explains all this, since the 15 I used was not shipped with
>> > exploded jmods..
>> >
>> > How do I build OpenJDK with packaged modules?
>> >
>> Have you done "make images"? You should see images/jdk in your build
>> output.
>>
>> -Alan
>>
>

From claes.redestad at oracle.com  Mon Jan 18 20:04:48 2021
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 18 Jan 2021 21:04:48 +0100
Subject: Performance regression in BuiltinClassLoader?
In-Reply-To: <CA+pBWhtnva58JL-jq1qkfm3vjL1RqD1wpfzv0eMTLpVOEPZwCA@mail.gmail.com>
References: <CA+pBWhvBH7wdYMb5TK6N3fxPj4sqgFgKOz1VB7Tnk_UiA6rZow@mail.gmail.com>
 <CA+pBWhsxLfe4cQ_5NZGOCqxjm6OJ-=Mxy3Yqo+rshTKWET0=3w@mail.gmail.com>
 <CA+pBWhvWkH3E-+97XYP2_XOK=6p=iKmNKCmsA29zpKUmPc-K_A@mail.gmail.com>
 <fc7a9385-24aa-c86c-e3a7-e59276131972@oracle.com>
 <CA+pBWhvwhk5vvr9X0eZ2t-CFG_ODxjTS864060i1GD5TQnLVoQ@mail.gmail.com>
 <CA+pBWhtnva58JL-jq1qkfm3vjL1RqD1wpfzv0eMTLpVOEPZwCA@mail.gmail.com>
Message-ID: <551a7cd6-0bba-5dbc-6f5f-21aa2b0e92c8@oracle.com>

No problem :-)

I've been advocating for renaming the <build>/jdk intermediary into
something that would make it perfectly obvious to newcomers that _this
is not it_, but I keep getting shot down. Short name convenient!

/Claes

On 2021-01-18 20:53, Eirik Bj?rsn?s wrote:
> Alan,
> 
> Apologies for wasting everyone's time (my own included, although I learned
> a lot!)
> 
> I found images/jdk, and with that there is no regression.
> 
> Back to square one :-)
> 
> Thanks,
> Eirik.
> 
> 
> On Mon, Jan 18, 2021 at 8:35 PM Eirik Bj?rsn?s <eirbjo at gmail.com> wrote:
> 
>>
>> Alan,
>>
>> I have been using "make images" all along. This
>> produces build/macosx-x86_64-server-release/jdk/modules with unpacked
>> modules.
>>
>> I'm a bit confused since "make help" seems to indicate that "make jdk"
>> should create unpacked modules, while "make images" should perhaps not? Or
>> did I misunderstand?
>>
>> Eirik.
>>
>>
>>
>> On Mon, Jan 18, 2021 at 8:31 PM Alan Bateman <Alan.Bateman at oracle.com>
>> wrote:
>>
>>> On 18/01/2021 19:24, Eirik Bj?rsn?s wrote:
>>>> For good measure, I did a JFR recording which revealed that
>>>> ExplodedModuleReader was doing file stat in 263 of 277 native method
>>>> samples.
>>>>
>>>> Which lie explains all this, since the 15 I used was not shipped with
>>>> exploded jmods..
>>>>
>>>> How do I build OpenJDK with packaged modules?
>>>>
>>> Have you done "make images"? You should see images/jdk in your build
>>> output.
>>>
>>> -Alan
>>>
>>

From mandy.chung at oracle.com  Mon Jan 18 21:52:21 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 18 Jan 2021 13:52:21 -0800
Subject: A Bug involving MethodHandles, Nestmates, Reflection and
 @CallerSensitive
In-Reply-To: <10b12cda-02bd-5375-72b3-8867852e3e3a@j-kuhn.de>
References: <5d39710a-ab78-4953-3f9f-86fd1b34b5d9@j-kuhn.de>
 <8b92389c-1c02-785e-7d33-6ae8a30d2a1c@oracle.com>
 <54ee3c75-3533-15eb-cba0-c13e6e2cc73b@oracle.com>
 <d66cdf65-579d-bb2f-566e-e2201cd0ebcc@j-kuhn.de>
 <1b21c701-d266-c99d-80cd-ec7a423a1cd2@oracle.com>
 <ef05a376-0a7e-b579-a0fe-4086dccdd0fd@j-kuhn.de>
 <3f160ca4-1822-d4f6-148a-ddd30a7d737a@oracle.com>
 <fa773926-c2cb-3359-d6a9-0bdd1a803756@j-kuhn.de>
 <10b12cda-02bd-5375-72b3-8867852e3e3a@j-kuhn.de>
Message-ID: <e4d18273-7e4c-602b-4037-45219004d379@oracle.com>

Hi Johannes,

There has been a couple of the prototypes regarding @CS methods (Alan 
did one and I did another) in the context of JDK-6824466. There are lots 
of security consideration regarding @CS methods. You are welcome to go 
deeper in that area.? If you are looking for starter bugs to fix, that 
won't be a quick patch.

I also came up with a patch for JDK-8013527 when working on 
JDK-6824466.? It's buried in 
https://github.com/openjdk/jdk/compare/master...mlchung:method-invoke. I 
will extract that fix and post a PR on my proposed fix.

Mandy

On 1/16/21 10:07 AM, Johannes Kuhn wrote:
> After digging though the JBS, I found this comment from John Rose[1].
>
> I like the general idea, but I don't think it's necessary to use a 
> native method as stub. Instead it could be written like this:
>
> class Class {
> ? @CallerSensitive
> ? @ForceInline
> ? public static Class<?> forName(String name) {
> ????? return forName(name, Reflection.getCallerClass());
> ? }
> ? private static Class<?> forName(String name, Class<?> caller) {
> ????? // original implementation
> ? }
> }
>
> By doing this, binding to the caller could be done by returning a 
> MethodHandle that actually calls the private method - with the lookup 
> class injected as argument (MethodHandles.insertArguments).
>
> Problem are methods that could be virtually invoked 
> (getContextClassLoader). Therefore it might be useful to keep the old 
> binding logic around. It also reduces the number of places where this 
> change has to be done - it's only required for the 
> hyper- at CallerSensitive methods.
>
> I will try to write a prototype that demonstrates that this approach 
> is feasible.
>
> - Johannes
>
> [1]: 
> https://bugs.openjdk.java.net/browse/JDK-8020968?focusedCommentId=13611844&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13611844
>
> On 09-Dec-20 21:09, Johannes Kuhn wrote:
>> On 09-Dec-20 19:44, Mandy Chung wrote:
>>>
>>>
>>> On 12/8/20 6:02 PM, Johannes Kuhn wrote:
>>>> There are a lot of things to consider when trying to fix JDK-8013527.
>>>
>>> Exactly in particular security implication!? What is clear is that 
>>> the expected lookup class should not be the injected class.?? The 
>>> key message here is that we can't fix JDK-8257874 until we fix 
>>> JDK-8013527 unfortunately.
>>>
>>> Mandy
>>>
>> Yeah, if JDK-8013527 is fixed it might fix JDK-8257874 as a byproduct.
>> If Lookup.lookup() can determine the original caller, then 
>> Field.set*/Method.invoke could do the same.
>> Special care has to be taken that no other class could spoof such an 
>> injected invoker.
>>
>> Too complicated for me :). JDK-8013527 needs a sound design to 
>> approach fixing it IMHO.
>>
>> - Johannes
>>


From info at j-kuhn.de  Mon Jan 18 23:13:05 2021
From: info at j-kuhn.de (Johannes Kuhn)
Date: Tue, 19 Jan 2021 00:13:05 +0100
Subject: A Bug involving MethodHandles, Nestmates, Reflection and
 @CallerSensitive
In-Reply-To: <e4d18273-7e4c-602b-4037-45219004d379@oracle.com>
References: <5d39710a-ab78-4953-3f9f-86fd1b34b5d9@j-kuhn.de>
 <8b92389c-1c02-785e-7d33-6ae8a30d2a1c@oracle.com>
 <54ee3c75-3533-15eb-cba0-c13e6e2cc73b@oracle.com>
 <d66cdf65-579d-bb2f-566e-e2201cd0ebcc@j-kuhn.de>
 <1b21c701-d266-c99d-80cd-ec7a423a1cd2@oracle.com>
 <ef05a376-0a7e-b579-a0fe-4086dccdd0fd@j-kuhn.de>
 <3f160ca4-1822-d4f6-148a-ddd30a7d737a@oracle.com>
 <fa773926-c2cb-3359-d6a9-0bdd1a803756@j-kuhn.de>
 <10b12cda-02bd-5375-72b3-8867852e3e3a@j-kuhn.de>
 <e4d18273-7e4c-602b-4037-45219004d379@oracle.com>
Message-ID: <f6abac93-40fb-da5b-f1b0-b19bbbef6d4d@j-kuhn.de>

Thanks Mandy.

Yes, @CS is a complicated beast.
I also implemented a part of JDK-6824466 for my "proxies should use 
hidden classes prototype". (Only for the "constructor for 
serialization", as hidden classes can't be mentioned in the constant pool.)

For the @CS method that can be called virtually - 
Thread.getContextClassLoader, I thought about those two interfaces:

interface GetCCLClassLoader {ClassLoader getContextClassLoader(); }
interface GetCCLObject {Object getContextClassLoader(); }

Insight: If a class extends Thread and implements GetCCLObject, javac 
will add a bridge method - which is the caller now. Have to think more 
about what this actually means.

The entire topic is very complex - but my current believe is that 
JDK-6824466 is a basic building block for a lot of other work in that 
area. It also has quite a few prototypes that have been developed 
independently - suggesting that it is indeed a basic building block.

I did a quick look though your prototype, one question I could not 
answer was "what prevents me from naming my hidden class 
Something$$InjectedInvoker?".

I will try to dig deeper into that, sure. I don't think that there will 
be any fully satisfying solution in the next months. And then I have to 
convince people that those changes don't expose any security issues - 
which will be quite hard.

But if you have some starter bugs that I could fix, let me know, might 
help to get some reputation and familiarity with the entire process.

Thank you for your time listening to my ideas, I appreciate it :).

- Johannes

On 18-Jan-21 22:52, Mandy Chung wrote:
> Hi Johannes,
> 
> There has been a couple of the prototypes regarding @CS methods (Alan 
> did one and I did another) in the context of JDK-6824466. There are lots 
> of security consideration regarding @CS methods. You are welcome to go 
> deeper in that area.? If you are looking for starter bugs to fix, that 
> won't be a quick patch.
> 
> I also came up with a patch for JDK-8013527 when working on 
> JDK-6824466.? It's buried in 
> https://github.com/openjdk/jdk/compare/master...mlchung:method-invoke. I 
> will extract that fix and post a PR on my proposed fix.
> 
> Mandy
> 
> On 1/16/21 10:07 AM, Johannes Kuhn wrote:
>> After digging though the JBS, I found this comment from John Rose[1].
>>
>> I like the general idea, but I don't think it's necessary to use a 
>> native method as stub. Instead it could be written like this:
>>
>> class Class {
>> ? @CallerSensitive
>> ? @ForceInline
>> ? public static Class<?> forName(String name) {
>> ????? return forName(name, Reflection.getCallerClass());
>> ? }
>> ? private static Class<?> forName(String name, Class<?> caller) {
>> ????? // original implementation
>> ? }
>> }
>>
>> By doing this, binding to the caller could be done by returning a 
>> MethodHandle that actually calls the private method - with the lookup 
>> class injected as argument (MethodHandles.insertArguments).
>>
>> Problem are methods that could be virtually invoked 
>> (getContextClassLoader). Therefore it might be useful to keep the old 
>> binding logic around. It also reduces the number of places where this 
>> change has to be done - it's only required for the 
>> hyper- at CallerSensitive methods.
>>
>> I will try to write a prototype that demonstrates that this approach 
>> is feasible.
>>
>> - Johannes
>>
>> [1]: 
>> https://bugs.openjdk.java.net/browse/JDK-8020968?focusedCommentId=13611844&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13611844
>>
>> On 09-Dec-20 21:09, Johannes Kuhn wrote:
>>> On 09-Dec-20 19:44, Mandy Chung wrote:
>>>>
>>>>
>>>> On 12/8/20 6:02 PM, Johannes Kuhn wrote:
>>>>> There are a lot of things to consider when trying to fix JDK-8013527.
>>>>
>>>> Exactly in particular security implication!? What is clear is that 
>>>> the expected lookup class should not be the injected class.?? The 
>>>> key message here is that we can't fix JDK-8257874 until we fix 
>>>> JDK-8013527 unfortunately.
>>>>
>>>> Mandy
>>>>
>>> Yeah, if JDK-8013527 is fixed it might fix JDK-8257874 as a byproduct.
>>> If Lookup.lookup() can determine the original caller, then 
>>> Field.set*/Method.invoke could do the same.
>>> Special care has to be taken that no other class could spoof such an 
>>> injected invoker.
>>>
>>> Too complicated for me :). JDK-8013527 needs a sound design to 
>>> approach fixing it IMHO.
>>>
>>> - Johannes
>>>
> 

From kbarrett at openjdk.java.net  Mon Jan 18 23:42:08 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 18 Jan 2021 23:42:08 GMT
Subject: RFR: 8132984: incorrect type for Reference.discovered [v3]
In-Reply-To: <xbEchOYCSxsfs7NxI3XoI7pKuD2X2jjicmZv2vRSoug=.ac0c74b8-c8a3-427d-90fa-279a2090bc83@github.com>
References: <xbEchOYCSxsfs7NxI3XoI7pKuD2X2jjicmZv2vRSoug=.ac0c74b8-c8a3-427d-90fa-279a2090bc83@github.com>
Message-ID: <Cf8itXVgcKjoQT9-HfxfRpAB6hlMdSryCMAR4W0hrbo=.59f2ed8b-7562-487e-a8fa-a04595729244@github.com>

> Please review this change which fixes the type of the private
> Reference.discovered field.  It was Reference<T>, but that's wrong because
> it can be any Reference object.
> 
> I've changed it to Reference<?> and let that flow through, updating some
> other variables that were previously somewhat incorrectly typed (usually
> with an Object type parameter). The interesting change is to the
> ReferenceQueue.enqueue parameter, which is now also Reference<?>.
> 
> This ultimately end up with a provably safe and correct, but uncheckable,
> cast in ReferenceQueue.enqueue.
> 
> An alternative might be to use a raw type for the discovered field, but I
> think that ends up with more @SuppressWarnings of various flavors.  I think
> the unbounded wildcard approach is clearer and cleaner.
> 
> Note that all of the pending list handling, including the discovered field,
> could be moved into a non-public, non-generic, sealed(?) base class of
> Reference<T>.  The pending list handling has nothing to do with the generic
> parameter T.
> 
> Testing:
> mach5 tier1 and tier4 (tier4 is where vmTestbase_vm_gc_ref tests are run)

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  plevart improvement

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1897/files
  - new: https://git.openjdk.java.net/jdk/pull/1897/files/80415b71..b95f5140

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

  Stats: 23 lines in 2 files changed: 10 ins; 9 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1897.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1897/head:pull/1897

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

From redestad at openjdk.java.net  Tue Jan 19 00:51:09 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Jan 2021 00:51:09 GMT
Subject: RFR: 8259947: Optimize UnixPath.encode
Message-ID: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>

This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.

This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.

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

Commit messages:
 - Add micro. To properly examine cost of toPath() needs a new File due caching - use FileOpen as a baseline
 - Optimize UnixPath.encode

Changes: https://git.openjdk.java.net/jdk/pull/2135/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2135&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259947
  Stats: 138 lines in 6 files changed: 79 ins; 45 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2135/head:pull/2135

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

From redestad at openjdk.java.net  Tue Jan 19 00:51:09 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Jan 2021 00:51:09 GMT
Subject: RFR: 8259947: Optimize UnixPath.encode
In-Reply-To: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
Message-ID: <tflq5p_kkFyt6IYz9AOsTehPOFVccnr-5yl8DZ0S2oI=.51ec7acd-1e05-4f9a-9e82-f842a98a8c5e@github.com>

On Tue, 19 Jan 2021 00:35:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
> 
> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.

Microbenchmark results, baseline:
Benchmark                 Mode  Cnt     Score    Error  Units
FileToPath.mix            avgt   15  1669.996 ? 76.308  ns/op
FileToPath.normalized     avgt   15   349.300 ? 16.851  ns/op
FileToPath.notNormalized  avgt   15   553.013 ? 28.736  ns/op
FileToPath.trailingSlash  avgt   15   415.107 ? 18.322  ns/op

Target:
Benchmark                 Mode  Cnt    Score    Error  Units
FileToPath.mix            avgt   15  887.191 ? 34.167  ns/op
FileToPath.normalized     avgt   15  132.653 ?  2.907  ns/op
FileToPath.notNormalized  avgt   15  333.678 ? 17.665  ns/op
FileToPath.trailingSlash  avgt   15  192.272 ?  7.644  ns/op

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

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

From github.com+300291+eirbjo at openjdk.java.net  Tue Jan 19 01:14:00 2021
From: github.com+300291+eirbjo at openjdk.java.net (eirbjo)
Date: Tue, 19 Jan 2021 01:14:00 GMT
Subject: RFR: 8259867: Move encoding checks into ZipCoder
Message-ID: <8tz8k1IbdDwe_z4GM4b5jiwUO6gSplgbisbbmOlQJJY=.e33630d7-338c-4921-bb89-add904e18ad4@github.com>

ZipFile.Source.initCEN verifies that entry names are encoding into bytes valid in the entry's encoding. It does so by calling encoding-specific checking methods, so it also needs to determine which check method to call for each entry.

By moving the encoding-variant checks into ZipCoder, initCEN can instead simply call ZipCoder.checkEncoding. This makes the code easier to follow and also removes a duplication of flag checking logic found in zipCoderForPos.

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

Commit messages:
 - 8242959: Move name encoding checks to ZipCoder (cleanup)

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

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

From martin at openjdk.java.net  Tue Jan 19 02:50:54 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Tue, 19 Jan 2021 02:50:54 GMT
Subject: [jdk16] RFR: 8259796: timed CompletableFuture.get may swallow
 InterruptedException [v2]
In-Reply-To: <upVu9OHkTffhtfvPrngQeLxwklUoxJNUGWMbnZvtAhA=.9ca40e17-fb47-4f22-ba77-43ae248c8ceb@github.com>
References: <upVu9OHkTffhtfvPrngQeLxwklUoxJNUGWMbnZvtAhA=.9ca40e17-fb47-4f22-ba77-43ae248c8ceb@github.com>
Message-ID: <fGoyT9m-sRtS7vVELHWwxH8-iD7vmtNDt6rAI_MRpDU=.d8de7dec-d181-435b-b6f0-117be904a2dd@github.com>

> 8259796: timed CompletableFuture.get may swallow InterruptedException

Martin Buchholz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  JDK-8259796

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

Changes: https://git.openjdk.java.net/jdk16/pull/126/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=126&range=01
  Stats: 88 lines in 2 files changed: 29 ins; 26 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/126/head:pull/126

PR: https://git.openjdk.java.net/jdk16/pull/126

From martin at openjdk.java.net  Tue Jan 19 02:55:44 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Tue, 19 Jan 2021 02:55:44 GMT
Subject: [jdk16] RFR: 8259796: timed CompletableFuture.get may swallow
 InterruptedException [v2]
In-Reply-To: <rKLw9iFV9jEz598JIzlEtufC7BohhhOSiTZCLYtCpwU=.215500fc-4bc1-454d-8d8d-754745cc1bb8@github.com>
References: <upVu9OHkTffhtfvPrngQeLxwklUoxJNUGWMbnZvtAhA=.9ca40e17-fb47-4f22-ba77-43ae248c8ceb@github.com>
 <rKLw9iFV9jEz598JIzlEtufC7BohhhOSiTZCLYtCpwU=.215500fc-4bc1-454d-8d8d-754745cc1bb8@github.com>
Message-ID: <J_fzEeaNK-kMwI3317NNm1h0_DebWgpjb1sFeTMq-7w=.69a0fcea-c61e-48ab-a3aa-e2fe4be8e639@github.com>

On Sun, 17 Jan 2021 18:52:04 GMT, Doug Lea <dl at openjdk.org> wrote:

>> Martin Buchholz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   JDK-8259796
>
> Marked as reviewed by dl (Reviewer).

we additionally tweaked timedGet with slightly cleaner code.

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

PR: https://git.openjdk.java.net/jdk16/pull/126

From thomas.stuefe at gmail.com  Tue Jan 19 05:48:35 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 19 Jan 2021 06:48:35 +0100
Subject: Performance regression in BuiltinClassLoader?
In-Reply-To: <551a7cd6-0bba-5dbc-6f5f-21aa2b0e92c8@oracle.com>
References: <CA+pBWhvBH7wdYMb5TK6N3fxPj4sqgFgKOz1VB7Tnk_UiA6rZow@mail.gmail.com>
 <CA+pBWhsxLfe4cQ_5NZGOCqxjm6OJ-=Mxy3Yqo+rshTKWET0=3w@mail.gmail.com>
 <CA+pBWhvWkH3E-+97XYP2_XOK=6p=iKmNKCmsA29zpKUmPc-K_A@mail.gmail.com>
 <fc7a9385-24aa-c86c-e3a7-e59276131972@oracle.com>
 <CA+pBWhvwhk5vvr9X0eZ2t-CFG_ODxjTS864060i1GD5TQnLVoQ@mail.gmail.com>
 <CA+pBWhtnva58JL-jq1qkfm3vjL1RqD1wpfzv0eMTLpVOEPZwCA@mail.gmail.com>
 <551a7cd6-0bba-5dbc-6f5f-21aa2b0e92c8@oracle.com>
Message-ID: <CAA-vtUxa5KDck2Vta=Z=5YPTpCbDCEqVn8hd5S=nH8vYc7k4UA@mail.gmail.com>

Renaming that thing would make sense. It tripped me up too when I was new
to OpenJDK.

..Thomas

On Mon, Jan 18, 2021 at 9:07 PM Claes Redestad <claes.redestad at oracle.com>
wrote:

> No problem :-)
>
> I've been advocating for renaming the <build>/jdk intermediary into
> something that would make it perfectly obvious to newcomers that _this
> is not it_, but I keep getting shot down. Short name convenient!
>
> /Claes
>
> On 2021-01-18 20:53, Eirik Bj?rsn?s wrote:
> > Alan,
> >
> > Apologies for wasting everyone's time (my own included, although I
> learned
> > a lot!)
> >
> > I found images/jdk, and with that there is no regression.
> >
> > Back to square one :-)
> >
> > Thanks,
> > Eirik.
> >
> >
> > On Mon, Jan 18, 2021 at 8:35 PM Eirik Bj?rsn?s <eirbjo at gmail.com> wrote:
> >
> >>
> >> Alan,
> >>
> >> I have been using "make images" all along. This
> >> produces build/macosx-x86_64-server-release/jdk/modules with unpacked
> >> modules.
> >>
> >> I'm a bit confused since "make help" seems to indicate that "make jdk"
> >> should create unpacked modules, while "make images" should perhaps not?
> Or
> >> did I misunderstand?
> >>
> >> Eirik.
> >>
> >>
> >>
> >> On Mon, Jan 18, 2021 at 8:31 PM Alan Bateman <Alan.Bateman at oracle.com>
> >> wrote:
> >>
> >>> On 18/01/2021 19:24, Eirik Bj?rsn?s wrote:
> >>>> For good measure, I did a JFR recording which revealed that
> >>>> ExplodedModuleReader was doing file stat in 263 of 277 native method
> >>>> samples.
> >>>>
> >>>> Which lie explains all this, since the 15 I used was not shipped with
> >>>> exploded jmods..
> >>>>
> >>>> How do I build OpenJDK with packaged modules?
> >>>>
> >>> Have you done "make images"? You should see images/jdk in your build
> >>> output.
> >>>
> >>> -Alan
> >>>
> >>
>

From github.com+471021+marschall at openjdk.java.net  Tue Jan 19 07:25:51 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Tue, 19 Jan 2021 07:25:51 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v4]
In-Reply-To: <66uDvXvRZ0UyNV93dFYWuQ-xp7GM-eVjCxsP-Aa0fMY=.46a98be7-25d9-4091-8db2-5b25beb5a9b1@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <E8UILDsjWetV8n_CS6BsLUpAS9YNOyFup_zlV0uXaNY=.7df5871c-da6d-41e8-a0a5-c39503e50297@github.com>
 <66uDvXvRZ0UyNV93dFYWuQ-xp7GM-eVjCxsP-Aa0fMY=.46a98be7-25d9-4091-8db2-5b25beb5a9b1@github.com>
Message-ID: <TujK1flvtJ144KxV3OE5JgwAbQ6X4GRS8EWuskcE_A0=.786a8094-0066-4012-abfb-dc0f97b0f9f8@github.com>

On Mon, 18 Jan 2021 07:47:30 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add unit tests
>>   
>>   - add unit test for Reader#read(CharBuffer)
>>   - add unit test for InputStreamReader#reader(CharBuffer)
>>   - test with both on-heap and off-heap buffers
>
> src/java.base/share/classes/java/io/Reader.java line 207:
> 
>> 205:                         target.put(cbuf, 0, n);
>> 206:                         nread += n;
>> 207:                         remaining -= n;
> 
> Wouldn't there be a possibility for target.put(cbuf, 0, n) to throw BufferOverflowException ?
> For example:
> - there's room (remaining) for TRANSFER_BUFFER_SIZE + 1 characters in target
> - cbuff is sized to TRANSFER_BUFFER_SIZE
> - 1st iteration of do loop transfers TRANSFER_BUFFER_SIZE charasters (remaining == 1)
> - 2nd iteration reads > 1 (up to TRANSFER_BUFFER_SIZE) characters
> - target.put throws BufferOverflowException
> 
> You have to limit the amount read in each iteration to be Math.min(remaining, cbuf.length)

You're correct. I need to expand the unit tests.

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

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

From redestad at openjdk.java.net  Tue Jan 19 08:10:45 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Jan 2021 08:10:45 GMT
Subject: RFR: 8259867: Move encoding checks into ZipCoder
In-Reply-To: <8tz8k1IbdDwe_z4GM4b5jiwUO6gSplgbisbbmOlQJJY=.e33630d7-338c-4921-bb89-add904e18ad4@github.com>
References: <8tz8k1IbdDwe_z4GM4b5jiwUO6gSplgbisbbmOlQJJY=.e33630d7-338c-4921-bb89-add904e18ad4@github.com>
Message-ID: <u3xmgjGU0ORK-ijy9_pLFxIkiysgRCGg0UJ9zz03aKA=.8b6d5674-5fe5-463d-a763-c1eecccdf089@github.com>

On Sat, 16 Jan 2021 17:49:38 GMT, eirbjo <github.com+300291+eirbjo at openjdk.org> wrote:

> ZipFile.Source.initCEN verifies that entry names are encoding into bytes valid in the entry's encoding. It does so by calling encoding-specific checking methods, so it also needs to determine which check method to call for each entry.
> 
> By moving the encoding-variant checks into ZipCoder, initCEN can instead simply call ZipCoder.checkEncoding. This makes the code easier to follow and also removes a duplication of flag checking logic found in zipCoderForPos.

Welcome back! 

Patch looks good to me. I'll sponsor it after allowing some time for other reviewers to have a look.

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

Marked as reviewed by redestad (Reviewer).

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

From claes.redestad at oracle.com  Tue Jan 19 08:47:48 2021
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 19 Jan 2021 09:47:48 +0100
Subject: Performance regression in BuiltinClassLoader?
In-Reply-To: <CAA-vtUxa5KDck2Vta=Z=5YPTpCbDCEqVn8hd5S=nH8vYc7k4UA@mail.gmail.com>
References: <CA+pBWhvBH7wdYMb5TK6N3fxPj4sqgFgKOz1VB7Tnk_UiA6rZow@mail.gmail.com>
 <CA+pBWhsxLfe4cQ_5NZGOCqxjm6OJ-=Mxy3Yqo+rshTKWET0=3w@mail.gmail.com>
 <CA+pBWhvWkH3E-+97XYP2_XOK=6p=iKmNKCmsA29zpKUmPc-K_A@mail.gmail.com>
 <fc7a9385-24aa-c86c-e3a7-e59276131972@oracle.com>
 <CA+pBWhvwhk5vvr9X0eZ2t-CFG_ODxjTS864060i1GD5TQnLVoQ@mail.gmail.com>
 <CA+pBWhtnva58JL-jq1qkfm3vjL1RqD1wpfzv0eMTLpVOEPZwCA@mail.gmail.com>
 <551a7cd6-0bba-5dbc-6f5f-21aa2b0e92c8@oracle.com>
 <CAA-vtUxa5KDck2Vta=Z=5YPTpCbDCEqVn8hd5S=nH8vYc7k4UA@mail.gmail.com>
Message-ID: <d59bee1d-03b3-fe10-751d-4cc9759a23fb@oracle.com>

Since it's the exploded jdk build, why not `make ejb`?!

Only half joking: it's short and easy to remember for those who prefer
just building the exploded image - while not setting up trip wires for
newcomers and the unwary.

/Claes

On 2021-01-19 06:48, Thomas St?fe wrote:
> Renaming that thing would make sense. It tripped me up too when I was 
> new to OpenJDK.
> 
> ..Thomas
> 
> On Mon, Jan 18, 2021 at 9:07 PM Claes Redestad 
> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
> 
>     No problem :-)
> 
>     I've been advocating for renaming the <build>/jdk intermediary into
>     something that would make it perfectly obvious to newcomers that _this
>     is not it_, but I keep getting shot down. Short name convenient!
> 
>     /Claes
> 
>     On 2021-01-18 20:53, Eirik Bj?rsn?s wrote:
>      > Alan,
>      >
>      > Apologies for wasting everyone's time (my own included, although
>     I learned
>      > a lot!)
>      >
>      > I found images/jdk, and with that there is no regression.
>      >
>      > Back to square one :-)
>      >
>      > Thanks,
>      > Eirik.
>      >
>      >
>      > On Mon, Jan 18, 2021 at 8:35 PM Eirik Bj?rsn?s <eirbjo at gmail.com
>     <mailto:eirbjo at gmail.com>> wrote:
>      >
>      >>
>      >> Alan,
>      >>
>      >> I have been using "make images" all along. This
>      >> produces build/macosx-x86_64-server-release/jdk/modules with
>     unpacked
>      >> modules.
>      >>
>      >> I'm a bit confused since "make help" seems to indicate that
>     "make jdk"
>      >> should create unpacked modules, while "make images" should
>     perhaps not? Or
>      >> did I misunderstand?
>      >>
>      >> Eirik.
>      >>
>      >>
>      >>
>      >> On Mon, Jan 18, 2021 at 8:31 PM Alan Bateman
>     <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>>
>      >> wrote:
>      >>
>      >>> On 18/01/2021 19:24, Eirik Bj?rsn?s wrote:
>      >>>> For good measure, I did a JFR recording which revealed that
>      >>>> ExplodedModuleReader was doing file stat in 263 of 277 native
>     method
>      >>>> samples.
>      >>>>
>      >>>> Which lie explains all this, since the 15 I used was not
>     shipped with
>      >>>> exploded jmods..
>      >>>>
>      >>>> How do I build OpenJDK with packaged modules?
>      >>>>
>      >>> Have you done "make images"? You should see images/jdk in your
>     build
>      >>> output.
>      >>>
>      >>> -Alan
>      >>>
>      >>
> 

From rkennke at openjdk.java.net  Tue Jan 19 09:33:51 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 19 Jan 2021 09:33:51 GMT
Subject: RFR: 8132984: incorrect type for Reference.discovered [v3]
In-Reply-To: <Cf8itXVgcKjoQT9-HfxfRpAB6hlMdSryCMAR4W0hrbo=.59f2ed8b-7562-487e-a8fa-a04595729244@github.com>
References: <xbEchOYCSxsfs7NxI3XoI7pKuD2X2jjicmZv2vRSoug=.ac0c74b8-c8a3-427d-90fa-279a2090bc83@github.com>
 <Cf8itXVgcKjoQT9-HfxfRpAB6hlMdSryCMAR4W0hrbo=.59f2ed8b-7562-487e-a8fa-a04595729244@github.com>
Message-ID: <rc_LDfVJ9Twl4IDKp5aJrCdQSGP9xtKE_AFaZ6xFWj4=.de01bf57-2917-453a-99d5-4c06e245d990@github.com>

On Mon, 18 Jan 2021 23:42:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change which fixes the type of the private
>> Reference.discovered field.  It was Reference<T>, but that's wrong because
>> it can be any Reference object.
>> 
>> I've changed it to Reference<?> and let that flow through, updating some
>> other variables that were previously somewhat incorrectly typed (usually
>> with an Object type parameter). The interesting change is to the
>> ReferenceQueue.enqueue parameter, which is now also Reference<?>.
>> 
>> This ultimately end up with a provably safe and correct, but uncheckable,
>> cast in ReferenceQueue.enqueue.
>> 
>> An alternative might be to use a raw type for the discovered field, but I
>> think that ends up with more @SuppressWarnings of various flavors.  I think
>> the unbounded wildcard approach is clearer and cleaner.
>> 
>> Note that all of the pending list handling, including the discovered field,
>> could be moved into a non-public, non-generic, sealed(?) base class of
>> Reference<T>.  The pending list handling has nothing to do with the generic
>> parameter T.
>> 
>> Testing:
>> mach5 tier1 and tier4 (tier4 is where vmTestbase_vm_gc_ref tests are run)
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   plevart improvement

Looks good to me!

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

Marked as reviewed by rkennke (Reviewer).

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

From chegar at openjdk.java.net  Tue Jan 19 09:43:49 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 19 Jan 2021 09:43:49 GMT
Subject: RFR: 8259947: Optimize UnixPath.encode
In-Reply-To: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
Message-ID: <pm5cTuqLJMmimY2Cts0Z5Us6OnG93_klR-K_GtJyCLw=.4924ce46-d0f7-4eaa-bfad-8388f0957ec0@github.com>

On Tue, 19 Jan 2021 00:35:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
> 
> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.

I think that this looks good ( I had a similar thought when looking through this code recently, for a separate issue ).

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

Marked as reviewed by chegar (Reviewer).

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

From shade at openjdk.java.net  Tue Jan 19 10:49:51 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 19 Jan 2021 10:49:51 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation
In-Reply-To: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
Message-ID: <RyEqdGAvWz7AUu97qVlZ0PCHtW_r4bWEJxZlprVoW2k=.625a8a67-cf9c-4a80-9684-2d6b574d9db1@github.com>

On Tue, 19 Jan 2021 00:35:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
> 
> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.

Changes requested by shade (Reviewer).

test/micro/org/openjdk/bench/java/io/FileToPath.java line 53:

> 51:         bh.consume(new File(normalFile).toPath());
> 52:         bh.consume(new File(trailingSlash).toPath());
> 53:         bh.consume(new File(root).toPath());

No singular test for `new File(root)`, but here it is in the `mix` anyway? What would probably be not comparable.

test/micro/org/openjdk/bench/java/io/FileToPath.java line 46:

> 44:     public String root = "/";
> 45:     public String trailingSlash = "/test/dir/file/name.txt/";
> 46:     public String notNormalizedFile = "/test/dir/file//name.txt";

Can be `private`, I think. As long as those are not `static final`...

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

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

From plevart at openjdk.java.net  Tue Jan 19 11:17:51 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Tue, 19 Jan 2021 11:17:51 GMT
Subject: RFR: 8132984: incorrect type for Reference.discovered [v3]
In-Reply-To: <Cf8itXVgcKjoQT9-HfxfRpAB6hlMdSryCMAR4W0hrbo=.59f2ed8b-7562-487e-a8fa-a04595729244@github.com>
References: <xbEchOYCSxsfs7NxI3XoI7pKuD2X2jjicmZv2vRSoug=.ac0c74b8-c8a3-427d-90fa-279a2090bc83@github.com>
 <Cf8itXVgcKjoQT9-HfxfRpAB6hlMdSryCMAR4W0hrbo=.59f2ed8b-7562-487e-a8fa-a04595729244@github.com>
Message-ID: <6MPZGfv4zZaBmdOvybDbZYARAZMeY1bTcgAqzFsZZ7k=.85fab081-c8fd-4143-89d9-b11cad5774e7@github.com>

On Mon, 18 Jan 2021 23:42:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change which fixes the type of the private
>> Reference.discovered field.  It was Reference<T>, but that's wrong because
>> it can be any Reference object.
>> 
>> I've changed it to Reference<?> and let that flow through, updating some
>> other variables that were previously somewhat incorrectly typed (usually
>> with an Object type parameter). The interesting change is to the
>> ReferenceQueue.enqueue parameter, which is now also Reference<?>.
>> 
>> This ultimately end up with a provably safe and correct, but uncheckable,
>> cast in ReferenceQueue.enqueue.
>> 
>> An alternative might be to use a raw type for the discovered field, but I
>> think that ends up with more @SuppressWarnings of various flavors.  I think
>> the unbounded wildcard approach is clearer and cleaner.
>> 
>> Note that all of the pending list handling, including the discovered field,
>> could be moved into a non-public, non-generic, sealed(?) base class of
>> Reference<T>.  The pending list handling has nothing to do with the generic
>> parameter T.
>> 
>> Testing:
>> mach5 tier1 and tier4 (tier4 is where vmTestbase_vm_gc_ref tests are run)
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   plevart improvement

This looks good.

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

Marked as reviewed by plevart (Reviewer).

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

From redestad at openjdk.java.net  Tue Jan 19 11:38:52 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Jan 2021 11:38:52 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation
In-Reply-To: <RyEqdGAvWz7AUu97qVlZ0PCHtW_r4bWEJxZlprVoW2k=.625a8a67-cf9c-4a80-9684-2d6b574d9db1@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
 <RyEqdGAvWz7AUu97qVlZ0PCHtW_r4bWEJxZlprVoW2k=.625a8a67-cf9c-4a80-9684-2d6b574d9db1@github.com>
Message-ID: <8GiNtg22GuKwPVCJIb6WWSMIH-eoxKt_pqutmgyFHwQ=.8407fccf-7a4a-47e4-815c-b76d64dad098@github.com>

On Tue, 19 Jan 2021 10:46:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
>> 
>> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.
>
> test/micro/org/openjdk/bench/java/io/FileToPath.java line 46:
> 
>> 44:     public String root = "/";
>> 45:     public String trailingSlash = "/test/dir/file/name.txt/";
>> 46:     public String notNormalizedFile = "/test/dir/file//name.txt";
> 
> Can be `private`, I think. As long as those are not `static final`...

Agree this can be cleaned up.

The micro was derived/copied from the `FileOpen` micro in the same package, so comments apply to a pre-existing micro. I'll refactor this to be a subclass inside that micro and clean up both.

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

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

From redestad at openjdk.java.net  Tue Jan 19 12:02:13 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Jan 2021 12:02:13 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v2]
In-Reply-To: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
Message-ID: <CS9fXniQ8jR33MsMwEMhKfBwZKEVHEV30iAL-6oD8eY=.56996ab9-e651-4f33-88a6-2313995910a2@github.com>

> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
> 
> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Fold ToPath into FileOpen, add root benchmarks to keep mix comparable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2135/files
  - new: https://git.openjdk.java.net/jdk/pull/2135/files/27a55ee0..18c3105b

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

  Stats: 128 lines in 2 files changed: 50 ins; 72 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2135/head:pull/2135

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

From alanb at openjdk.java.net  Tue Jan 19 12:16:41 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 19 Jan 2021 12:16:41 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v2]
In-Reply-To: <CS9fXniQ8jR33MsMwEMhKfBwZKEVHEV30iAL-6oD8eY=.56996ab9-e651-4f33-88a6-2313995910a2@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
 <CS9fXniQ8jR33MsMwEMhKfBwZKEVHEV30iAL-6oD8eY=.56996ab9-e651-4f33-88a6-2313995910a2@github.com>
Message-ID: <oyHwLSs6BIqyMxzejkoWiYmQvn60soG8f05Y_ih7ri0=.ba00e5b8-df4a-46b0-a1ab-b111090b7484@github.com>

On Tue, 19 Jan 2021 12:02:13 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
>> 
>> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fold ToPath into FileOpen, add root benchmarks to keep mix comparable

src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 118:

> 116:         try {
> 117:             return JLA.getBytesNoRepl(input, Util.jnuEncoding());
> 118:         } catch (CharacterCodingException cce) {

The encode method pre-dates JLA.getBytesNoRepl and the recent optimisations so this is a good cleanup.

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

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

From alanb at openjdk.java.net  Tue Jan 19 12:13:51 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 19 Jan 2021 12:13:51 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v2]
In-Reply-To: <CS9fXniQ8jR33MsMwEMhKfBwZKEVHEV30iAL-6oD8eY=.56996ab9-e651-4f33-88a6-2313995910a2@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
 <CS9fXniQ8jR33MsMwEMhKfBwZKEVHEV30iAL-6oD8eY=.56996ab9-e651-4f33-88a6-2313995910a2@github.com>
Message-ID: <6Xl4r1XwRIaAo-NW3vrTyzfmh5wW_w0uNphsZseTxSE=.1412df8d-065e-44a8-ab0d-b7f9f6cc8eba@github.com>

On Tue, 19 Jan 2021 12:02:13 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
>> 
>> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fold ToPath into FileOpen, add root benchmarks to keep mix comparable

src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 112:

> 110:     private static final jdk.internal.access.JavaLangAccess JLA =
> 111:             jdk.internal.access.SharedSecrets.getJavaLangAccess();
> 112: 

Can you move this to the top, before the instance fields? Also let's import the jdk.internal.acces classes rather than using fully qualified names. That will keep it consistent with the existing code in this area.

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

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

From redestad at openjdk.java.net  Tue Jan 19 12:26:08 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Jan 2021 12:26:08 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v3]
In-Reply-To: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
Message-ID: <1s1c4bBy5zRlzjUrdJ3Bbly4nb3Q3EpbWJ6ruZenqcY=.3642563d-f891-4f65-8193-8e8b2190a151@github.com>

> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
> 
> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Move JLA to top, add imports

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2135/files
  - new: https://git.openjdk.java.net/jdk/pull/2135/files/18c3105b..b023c0a5

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

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

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

From lancea at openjdk.java.net  Tue Jan 19 12:22:52 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 19 Jan 2021 12:22:52 GMT
Subject: RFR: 8259867: Move encoding checks into ZipCoder
In-Reply-To: <8tz8k1IbdDwe_z4GM4b5jiwUO6gSplgbisbbmOlQJJY=.e33630d7-338c-4921-bb89-add904e18ad4@github.com>
References: <8tz8k1IbdDwe_z4GM4b5jiwUO6gSplgbisbbmOlQJJY=.e33630d7-338c-4921-bb89-add904e18ad4@github.com>
Message-ID: <vs_LBXmPCQB8qG-egiJPkoaMuNx24nx75LFDE4CGO3k=.0ea9e776-e6cf-4f1e-b30d-38a75f130c14@github.com>

On Sat, 16 Jan 2021 17:49:38 GMT, eirbjo <github.com+300291+eirbjo at openjdk.org> wrote:

> ZipFile.Source.initCEN verifies that entry names are encoding into bytes valid in the entry's encoding. It does so by calling encoding-specific checking methods, so it also needs to determine which check method to call for each entry.
> 
> By moving the encoding-variant checks into ZipCoder, initCEN can instead simply call ZipCoder.checkEncoding. This makes the code easier to follow and also removes a duplication of flag checking logic found in zipCoderForPos.

The change looks good to me as well

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

Marked as reviewed by lancea (Reviewer).

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

From alanb at openjdk.java.net  Tue Jan 19 13:05:50 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 19 Jan 2021 13:05:50 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v3]
In-Reply-To: <1s1c4bBy5zRlzjUrdJ3Bbly4nb3Q3EpbWJ6ruZenqcY=.3642563d-f891-4f65-8193-8e8b2190a151@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
 <1s1c4bBy5zRlzjUrdJ3Bbly4nb3Q3EpbWJ6ruZenqcY=.3642563d-f891-4f65-8193-8e8b2190a151@github.com>
Message-ID: <HDpY17yT1Wu3CAnYVxHDN8VSmWiKsBAPN2bo_I-8quc=.2b939a7b-dca2-42f8-ab1f-ff71027d4488@github.com>

On Tue, 19 Jan 2021 12:26:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
>> 
>> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move JLA to top, add imports

Marked as reviewed by alanb (Reviewer).

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

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

From alanb at openjdk.java.net  Tue Jan 19 14:32:45 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 19 Jan 2021 14:32:45 GMT
Subject: [jdk16] RFR: 8259796: timed CompletableFuture.get may swallow
 InterruptedException [v2]
In-Reply-To: <fGoyT9m-sRtS7vVELHWwxH8-iD7vmtNDt6rAI_MRpDU=.d8de7dec-d181-435b-b6f0-117be904a2dd@github.com>
References: <upVu9OHkTffhtfvPrngQeLxwklUoxJNUGWMbnZvtAhA=.9ca40e17-fb47-4f22-ba77-43ae248c8ceb@github.com>
 <fGoyT9m-sRtS7vVELHWwxH8-iD7vmtNDt6rAI_MRpDU=.d8de7dec-d181-435b-b6f0-117be904a2dd@github.com>
Message-ID: <G4kH7JG28s4yDfjgp77LaEtT85kbZG7phBv4mf3DV5U=.de823b2a-8419-4967-9d99-33eb9ff2098b@github.com>

On Tue, 19 Jan 2021 02:50:54 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> 8259796: timed CompletableFuture.get may swallow InterruptedException
>
> Martin Buchholz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   JDK-8259796

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/126

From alanb at openjdk.java.net  Tue Jan 19 16:17:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 19 Jan 2021 16:17:40 GMT
Subject: RFR: JDK-8259395 Patching automatic module with additional
 packages re-creates module without "requires java.base" [v3]
In-Reply-To: <pB72SpIMCKsU9aW9YTfft_2psI6wIMvg-j-1y9zYzN0=.20e5e82c-36b1-453d-b8fc-1f79c26c7018@github.com>
References: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
 <xPmjPGTgkdOOuaNrcm9fO0FhBtsUb-L9FGbJ40bDUNo=.4112f09a-b483-4e7d-b57a-be8e208721aa@github.com>
 <il4tZHeQpGludQJR1E4bL4VT6GlUrnYlCIquM2Xzru0=.313848ed-c980-4778-9c7c-5984e81d6ea1@github.com>
 <FtnsXvDoFKVs4kO4jcovhBbk49VGOpYVZdsFS_lW0N8=.917908d6-62c7-4858-8068-e0873288b115@github.com>
 <tp2onYs7y3jh2mpZNnKpeOTLQ7zGXDq07pxSb1LFrKU=.055a3225-00da-46ab-9b20-d912e0d017c1@github.com>
 <pB72SpIMCKsU9aW9YTfft_2psI6wIMvg-j-1y9zYzN0=.20e5e82c-36b1-453d-b8fc-1f79c26c7018@github.com>
Message-ID: <ak44W6IV6an9Zm4lxsOFcqV1qO4YXDctpgMrz9cfJHA=.e767d207-e37d-406d-86cf-afded1d33e42@github.com>

On Mon, 11 Jan 2021 14:22:20 GMT, Johannes Kuhn <github.com+652983+DasBrain at openjdk.org> wrote:

>> This issue requires a Reviewer from someone working in this area. Please do not sponsor or integrate until that review has been done.
>
>> 
>> 
>> This issue requires a Reviewer from someone working in this area. Please do not sponsor or integrate until that review has been done.
> 
> Ok, increased the number of required reviewers to 2.  
> Hope that was the right move, as I don't see any other way to undo /integrate.

Finally getting back to this. The update to ModulePatcher.java is good. Test coverage needs discussion. There are four scenarios where test coverage is lacking:

1. automatic module on the module path, patched to override or augment classes/resources
2. automatic module on the module path, patched to add new packages
3. automatic module as the initial module, patched to override or augment classes/resources
4. automatic module as the initial module, patched to add new packages

The patch adds automatic/PatchTest.java so it's adding test coverage for 4. We should probably rename it to leave room for the other tests, or else create it so that additional test coverage can be added. I assume the test was copied from another test as there are a few left overs, e.g. `@modules java.script` but the test does not use this module. I don't want to expand the scope of this PR too much but I think we should at least cover 3 and 4 in the test.

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

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

From rriggs at openjdk.java.net  Tue Jan 19 16:18:50 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 19 Jan 2021 16:18:50 GMT
Subject: RFR: 8132984: incorrect type for Reference.discovered [v3]
In-Reply-To: <Cf8itXVgcKjoQT9-HfxfRpAB6hlMdSryCMAR4W0hrbo=.59f2ed8b-7562-487e-a8fa-a04595729244@github.com>
References: <xbEchOYCSxsfs7NxI3XoI7pKuD2X2jjicmZv2vRSoug=.ac0c74b8-c8a3-427d-90fa-279a2090bc83@github.com>
 <Cf8itXVgcKjoQT9-HfxfRpAB6hlMdSryCMAR4W0hrbo=.59f2ed8b-7562-487e-a8fa-a04595729244@github.com>
Message-ID: <iOk3tCBce8EySCJ8BgbRWo_VHuQA8nNvjPHGNy_ETJ4=.9e063add-5f9b-4989-94b4-13f5b2270f36@github.com>

On Mon, 18 Jan 2021 23:42:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change which fixes the type of the private
>> Reference.discovered field.  It was Reference<T>, but that's wrong because
>> it can be any Reference object.
>> 
>> I've changed it to Reference<?> and let that flow through, updating some
>> other variables that were previously somewhat incorrectly typed (usually
>> with an Object type parameter). The interesting change is to the
>> ReferenceQueue.enqueue parameter, which is now also Reference<?>.
>> 
>> This ultimately end up with a provably safe and correct, but uncheckable,
>> cast in ReferenceQueue.enqueue.
>> 
>> An alternative might be to use a raw type for the discovered field, but I
>> think that ends up with more @SuppressWarnings of various flavors.  I think
>> the unbounded wildcard approach is clearer and cleaner.
>> 
>> Note that all of the pending list handling, including the discovered field,
>> could be moved into a non-public, non-generic, sealed(?) base class of
>> Reference<T>.  The pending list handling has nothing to do with the generic
>> parameter T.
>> 
>> Testing:
>> mach5 tier1 and tier4 (tier4 is where vmTestbase_vm_gc_ref tests are run)
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   plevart improvement

Marked as reviewed by rriggs (Reviewer).

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

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

From rriggs at openjdk.java.net  Tue Jan 19 16:48:50 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 19 Jan 2021 16:48:50 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v7]
In-Reply-To: <gQ0oYc4HZ8xGckOI1z0gIyPciGhc35j7eomAl97fiZY=.1301b699-a513-4322-9e7c-17de21f5e6b2@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
 <gQ0oYc4HZ8xGckOI1z0gIyPciGhc35j7eomAl97fiZY=.1301b699-a513-4322-9e7c-17de21f5e6b2@github.com>
Message-ID: <5ZRdIyOoVWw2aIrC1muuUuSv2G2lqzryAb2EaDIt1q4=.d84e68ad-ffcc-46fe-8cf3-a50942fc0d96@github.com>

On Mon, 18 Jan 2021 09:26:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.
>> 
>> This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.
>> 
>> Microbenchmark results:
>> Baseline
>> 
>> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
>> decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
>> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
>> decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
>> decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
>> decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
>> decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
>> decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
>> decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
>> decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
>> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op
>> 
>> Patched:
>> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
>> decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
>> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
>> decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
>> decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
>> decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
>> decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
>> decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
>> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op
>> 
>> Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.
>> 
>> Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.
>> 
>> Testing: tier1-4
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Harmonize empty string checking in newString methods

The large number of package exposed methods in StringCoding is ugly and makes the code harder to maintain.
Can the code duplication of UTF8 in the String constructors be reduced?
It would be cleaner to move all of the remaining StringCoding methods into String and make them private again. Reading the code now requires quite a bit of cross referencing and the invariants are hard to verify.

src/java.base/share/classes/java/lang/StringCoding.java line 424:

> 422: 
> 423:     static int decodeUTF8_UTF16(byte[] bytes, int offset, int sl, byte[] dst, int dp, boolean doReplace) {
> 424:         while (offset < sl) {

The renaming of sp -> offset seems unmotivated and breaks the symmetry with dp.

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

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

From naoto at openjdk.java.net  Tue Jan 19 16:55:46 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 19 Jan 2021 16:55:46 GMT
Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg
 drop 10 [v3]
In-Reply-To: <VR1_KkzLukMWQ9XA_kj1FBe43uAJDkK85cOZjB60vvU=.d08b1f75-a587-4cb5-9a63-46243a4126b9@github.com>
References: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
 <VR1_KkzLukMWQ9XA_kj1FBe43uAJDkK85cOZjB60vvU=.d08b1f75-a587-4cb5-9a63-46243a4126b9@github.com>
Message-ID: <ZW3t1ah5vc0nMrrtyC7SvWQdVXwtu7BY4-Z9Nc2hk98=.f5a22fa9-b0f6-4c8f-86e9-dbd93c2fa09f@github.com>

On Mon, 18 Jan 2021 05:52:57 GMT, Leo Jiang <ljiang at openjdk.org> wrote:

>> This is the changes for JDK 16 msg drop 10.
>
> Leo Jiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix the missing copyright year for standard.properties

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/123

From martin.doerr at sap.com  Tue Jan 19 17:43:57 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 19 Jan 2021 17:43:57 +0000
Subject: [11u] RFR: 7146776: deadlock between URLStreamHandler.getHostAddress
 and file.Handler.openconnection
Message-ID: <AM4PR02MB305714EC3174E696DB79D9D09AA30@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi,

JDK-7146776 is backported to 11.0.11-oracle. I'd like to backport it for parity.
Change doesn't apply cleanly because of Copyright year changes and a minor difference in a hunk which gets removed by this change:
11u Code contains host.equals(""), patch wants to remove host.isEmpty() from URLStreamHandler.java.

Bug:
https://bugs.openjdk.java.net/browse/JDK-7146776

Original change:
https://git.openjdk.java.net/jdk/commit/db9c114d

11u backport:
http://cr.openjdk.java.net/~mdoerr/7146776_windows_deadlock_11u/webrev.00/

Please review.

Best regards,
Martin


From mchung at openjdk.java.net  Tue Jan 19 17:59:49 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 19 Jan 2021 17:59:49 GMT
Subject: RFR: 8132984: incorrect type for Reference.discovered [v3]
In-Reply-To: <Cf8itXVgcKjoQT9-HfxfRpAB6hlMdSryCMAR4W0hrbo=.59f2ed8b-7562-487e-a8fa-a04595729244@github.com>
References: <xbEchOYCSxsfs7NxI3XoI7pKuD2X2jjicmZv2vRSoug=.ac0c74b8-c8a3-427d-90fa-279a2090bc83@github.com>
 <Cf8itXVgcKjoQT9-HfxfRpAB6hlMdSryCMAR4W0hrbo=.59f2ed8b-7562-487e-a8fa-a04595729244@github.com>
Message-ID: <oqbjIjs5qOFLJo8gy7bniV8FC5CAbNyBElspajhrq3w=.730e3e86-09f3-4273-ab0f-365c74f1696b@github.com>

On Mon, 18 Jan 2021 23:42:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change which fixes the type of the private
>> Reference.discovered field.  It was Reference<T>, but that's wrong because
>> it can be any Reference object.
>> 
>> I've changed it to Reference<?> and let that flow through, updating some
>> other variables that were previously somewhat incorrectly typed (usually
>> with an Object type parameter). The interesting change is to the
>> ReferenceQueue.enqueue parameter, which is now also Reference<?>.
>> 
>> This ultimately end up with a provably safe and correct, but uncheckable,
>> cast in ReferenceQueue.enqueue.
>> 
>> An alternative might be to use a raw type for the discovered field, but I
>> think that ends up with more @SuppressWarnings of various flavors.  I think
>> the unbounded wildcard approach is clearer and cleaner.
>> 
>> Note that all of the pending list handling, including the discovered field,
>> could be moved into a non-public, non-generic, sealed(?) base class of
>> Reference<T>.  The pending list handling has nothing to do with the generic
>> parameter T.
>> 
>> Testing:
>> mach5 tier1 and tier4 (tier4 is where vmTestbase_vm_gc_ref tests are run)
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   plevart improvement

Looks good.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1897

From martin at openjdk.java.net  Tue Jan 19 18:43:46 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Tue, 19 Jan 2021 18:43:46 GMT
Subject: [jdk16] Integrated: 8259796: timed CompletableFuture.get may swallow
 InterruptedException
In-Reply-To: <upVu9OHkTffhtfvPrngQeLxwklUoxJNUGWMbnZvtAhA=.9ca40e17-fb47-4f22-ba77-43ae248c8ceb@github.com>
References: <upVu9OHkTffhtfvPrngQeLxwklUoxJNUGWMbnZvtAhA=.9ca40e17-fb47-4f22-ba77-43ae248c8ceb@github.com>
Message-ID: <CeTC7Wb2IfUirPZtB4hK9ReLSkFJvaWPX780i5h4HtA=.a7579aa1-00d4-4adf-a9cd-78853cf43fbd@github.com>

On Sun, 17 Jan 2021 18:39:55 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> 8259796: timed CompletableFuture.get may swallow InterruptedException

This pull request has now been integrated.

Changeset: f7b96d34
Author:    Martin Buchholz <martin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/f7b96d34
Stats:     88 lines in 2 files changed: 29 ins; 26 del; 33 mod

8259796: timed CompletableFuture.get may swallow InterruptedException

Reviewed-by: dl, alanb

-------------

PR: https://git.openjdk.java.net/jdk16/pull/126

From kbarrett at openjdk.java.net  Tue Jan 19 18:59:52 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 19 Jan 2021 18:59:52 GMT
Subject: RFR: 8132984: incorrect type for Reference.discovered [v3]
In-Reply-To: <6MPZGfv4zZaBmdOvybDbZYARAZMeY1bTcgAqzFsZZ7k=.85fab081-c8fd-4143-89d9-b11cad5774e7@github.com>
References: <xbEchOYCSxsfs7NxI3XoI7pKuD2X2jjicmZv2vRSoug=.ac0c74b8-c8a3-427d-90fa-279a2090bc83@github.com>
 <Cf8itXVgcKjoQT9-HfxfRpAB6hlMdSryCMAR4W0hrbo=.59f2ed8b-7562-487e-a8fa-a04595729244@github.com>
 <6MPZGfv4zZaBmdOvybDbZYARAZMeY1bTcgAqzFsZZ7k=.85fab081-c8fd-4143-89d9-b11cad5774e7@github.com>
Message-ID: <fM_3y_mRhfDr_iTDg5WGH8jxxpN_B-lypjwTRJ-vG90=.521875e7-aa5c-4e48-8858-d269023d119c@github.com>

On Tue, 19 Jan 2021 11:15:17 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   plevart improvement
>
> This looks good.

Thanks @plevart , @rkennke , @RogerRiggs , and @mlchung for reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1897

From kbarrett at openjdk.java.net  Tue Jan 19 19:18:14 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 19 Jan 2021 19:18:14 GMT
Subject: RFR: 8132984: incorrect type for Reference.discovered [v4]
In-Reply-To: <xbEchOYCSxsfs7NxI3XoI7pKuD2X2jjicmZv2vRSoug=.ac0c74b8-c8a3-427d-90fa-279a2090bc83@github.com>
References: <xbEchOYCSxsfs7NxI3XoI7pKuD2X2jjicmZv2vRSoug=.ac0c74b8-c8a3-427d-90fa-279a2090bc83@github.com>
Message-ID: <b5Q7R1BcZEoq-oVQFJJc-EJkprN2vdkvvNTjZT6fySQ=.2ab8bb39-90be-4fa1-90e1-22e6a7172a7b@github.com>

> Please review this change which fixes the type of the private
> Reference.discovered field.  It was Reference<T>, but that's wrong because
> it can be any Reference object.
> 
> I've changed it to Reference<?> and let that flow through, updating some
> other variables that were previously somewhat incorrectly typed (usually
> with an Object type parameter). The interesting change is to the
> ReferenceQueue.enqueue parameter, which is now also Reference<?>.
> 
> This ultimately end up with a provably safe and correct, but uncheckable,
> cast in ReferenceQueue.enqueue.
> 
> An alternative might be to use a raw type for the discovered field, but I
> think that ends up with more @SuppressWarnings of various flavors.  I think
> the unbounded wildcard approach is clearer and cleaner.
> 
> Note that all of the pending list handling, including the discovered field,
> could be moved into a non-public, non-generic, sealed(?) base class of
> Reference<T>.  The pending list handling has nothing to do with the generic
> parameter T.
> 
> Testing:
> mach5 tier1 and tier4 (tier4 is where vmTestbase_vm_gc_ref tests are run)

Kim Barrett 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 fix_discovered_type
 - plevart improvement
 - update copyrights
 - Merge branch 'master' into fix_discovered_type
 - Use unbounded wildcard placeholders and final safe but unchecked cast

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1897/files
  - new: https://git.openjdk.java.net/jdk/pull/1897/files/b95f5140..cd66bff1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1897&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1897&range=02-03

  Stats: 3433 lines in 92 files changed: 381 ins; 2791 del; 261 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1897.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1897/head:pull/1897

PR: https://git.openjdk.java.net/jdk/pull/1897

From kbarrett at openjdk.java.net  Tue Jan 19 19:18:15 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 19 Jan 2021 19:18:15 GMT
Subject: Integrated: 8132984: incorrect type for Reference.discovered
In-Reply-To: <xbEchOYCSxsfs7NxI3XoI7pKuD2X2jjicmZv2vRSoug=.ac0c74b8-c8a3-427d-90fa-279a2090bc83@github.com>
References: <xbEchOYCSxsfs7NxI3XoI7pKuD2X2jjicmZv2vRSoug=.ac0c74b8-c8a3-427d-90fa-279a2090bc83@github.com>
Message-ID: <8ACb-BOJlu6Ikddsp_UNOnuMgp8CBZD0alzcGhSrnOE=.dcc900c9-9a94-40eb-be43-31e52b5a5aa2@github.com>

On Sat, 26 Dec 2020 03:25:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change which fixes the type of the private
> Reference.discovered field.  It was Reference<T>, but that's wrong because
> it can be any Reference object.
> 
> I've changed it to Reference<?> and let that flow through, updating some
> other variables that were previously somewhat incorrectly typed (usually
> with an Object type parameter). The interesting change is to the
> ReferenceQueue.enqueue parameter, which is now also Reference<?>.
> 
> This ultimately end up with a provably safe and correct, but uncheckable,
> cast in ReferenceQueue.enqueue.
> 
> An alternative might be to use a raw type for the discovered field, but I
> think that ends up with more @SuppressWarnings of various flavors.  I think
> the unbounded wildcard approach is clearer and cleaner.
> 
> Note that all of the pending list handling, including the discovered field,
> could be moved into a non-public, non-generic, sealed(?) base class of
> Reference<T>.  The pending list handling has nothing to do with the generic
> parameter T.
> 
> Testing:
> mach5 tier1 and tier4 (tier4 is where vmTestbase_vm_gc_ref tests are run)

This pull request has now been integrated.

Changeset: 33dcc00c
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/33dcc00c
Stats:     17 lines in 1 file changed: 10 ins; 1 del; 6 mod

8132984: incorrect type for Reference.discovered

Use unbounded wildcard placeholders, plus a new helper to get back to the Reference<T> domain.

Reviewed-by: rkennke, plevart, rriggs, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/1897

From vitalyd at gmail.com  Tue Jan 19 19:19:59 2021
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 19 Jan 2021 14:19:59 -0500
Subject: IllegalStateException in CharsetDecoder when inspecting JarFile
 contents on Java 15
Message-ID: <CAHjP37HJgdyLL7QxO=cSu-TqaFL65pmSAB_uXaODUnkHadsjCA@mail.gmail.com>

Hi all,

I observed the following stacktrace when inspecting a JarFile's contents
using a parallel stream (i.e. FJ pool):

Exception in thread "main" java.lang.IllegalStateException:
java.lang.IllegalStateException: Current state = CODING_END, new state =
FLUSHED

              at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)

              at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:64)

              at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

              at
java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:500)

              at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:481)

              at
java.base/java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:600)

              at
java.base/java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:678)

              at
java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:737)

              at
java.base/java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:159)

              at
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:173)

              at
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)

              at
java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)

              at
java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:575)

              at <stripped>.ClassVersions.conflicts(ClassVersions.java:703)

              at <stripped>.ClassVersions.check(ClassVersions.java:743)

              at <stripped>.ClassVersions.main(ClassVersions.java:839)

Caused by: java.lang.IllegalStateException: Current state = CODING_END, new
state = FLUSHED

              at
java.base/java.nio.charset.CharsetDecoder.throwIllegalStateException(CharsetDecoder.java:998)

              at
java.base/java.nio.charset.CharsetDecoder.flush(CharsetDecoder.java:681)

              at
java.base/java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:810)

              at
java.base/java.util.zip.ZipCoder.normalizedHashDecode(ZipCoder.java:136)

              at
java.base/java.util.zip.ZipCoder$UTF8ZipCoder.normalizedHash(ZipCoder.java:228)

              at
java.base/java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1527)

              at
java.base/java.util.zip.ZipFile$Source.<init>(ZipFile.java:1249)

              at
java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1211)

              at
java.base/java.util.zip.ZipFile$CleanableResource.<init>(ZipFile.java:701)

              at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:240)

              at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:171)

              at java.base/java.util.jar.JarFile.<init>(JarFile.java:347)

              at java.base/java.util.jar.JarFile.<init>(JarFile.java:318)

              at java.base/java.util.jar.JarFile.<init>(JarFile.java:284)

              at <stripped>.ClassVersions.lookupJar(ClassVersions.java:665)

              at
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)

              at
java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)

              at
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)

              at
java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)

              at
java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)

              at
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)

              at
java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)

              at
java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)

              at
java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)

              at
java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1016)

              at
java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1665)

              at
java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1598)

              at
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)


(Note: I stripped off some package names to protect the innocent).


While investigating this a bit, I noticed some code that looks a bit
suspect.  Namely:

   - ZipCoder has a singleton UTF8ZipCoder
   <https://github.com/openjdk/jdk/blob/05bcd67e6501f3824020edd1ab036c87888fa229/src/java.base/share/classes/java/util/zip/ZipCoder.java#L48>
   instance it uses for UTF8 decoding.
   - Source.get() creates a new Source
   <https://github.com/openjdk/jdk/blob/05bcd67e6501f3824020edd1ab036c87888fa229/src/java.base/share/classes/java/util/zip/ZipFile.java#L1225>
   instance outside of any synchronization

The links above are to tip, but I think this code is the same in Java 15.

It seems possible that multiple threads can end up in Source.get(), new up
a Source, and proceed to use the decoder of UTF8ZipCoder racily.  Per my
understanding (and CharsetDecoder javadoc), CharsetDecoders are not
threadsafe.

Any thoughts? Did I miss anything that would suggest the stacktrace above
is due to something else entirely?

Thanks

From mchung at openjdk.java.net  Tue Jan 19 19:45:55 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 19 Jan 2021 19:45:55 GMT
Subject: RFR: 8259911: byteArrayViewVarHandle should throw
 ArrayIndexOutOfBoundsException
In-Reply-To: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com>
References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com>
Message-ID: <m7HPpbiNt-o8XJS-EDDGsT2V4cH3UAs6Sm57Dmh2hPE=.ad3c7d7c-d473-4c5c-a626-6db46aa00a8b@github.com>

On Mon, 18 Jan 2021 12:09:23 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Change `MethodHandles.byteArrayViewVarHandle` to throw `ArrayIndexOutOfBoundsException` rather than the more generic `IndexArrayOutOfBoundsException`. This feels more natural, and reduces the risk for subtle behavioral mismatch when migrating code from arrays/Unsafe to VHs. 
> 
> CSR: [JDK-8259912](https://bugs.openjdk.java.net/browse/JDK-8259912)

The change to AIOOBE is reasonable.    Have you considered making this just as an implementation change and leave the spec as is?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2124

From mullan at openjdk.java.net  Tue Jan 19 20:26:50 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 19 Jan 2021 20:26:50 GMT
Subject: RFR: 8259707: LDAP channel binding does not work with StartTLS
 extension
In-Reply-To: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
References: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
Message-ID: <ufGH_BKloK8RlVDYOchBYFMHGLdVLIHcSmvGnNp8U5w=.9a2f9de0-a2c5-4031-be42-7daa9145258b@github.com>

On Thu, 14 Jan 2021 19:28:27 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS Extension.
> Test from the bug report and jtreg javax/naming tests are passed.

Can you add a test for this or is it too hard? There are existing tests for StartTLS in the security/infra area -- could they be enhanced to test this case?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2085

From redestad at openjdk.java.net  Tue Jan 19 20:33:49 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Jan 2021 20:33:49 GMT
Subject: RFR: 8259911: byteArrayViewVarHandle should throw
 ArrayIndexOutOfBoundsException
In-Reply-To: <m7HPpbiNt-o8XJS-EDDGsT2V4cH3UAs6Sm57Dmh2hPE=.ad3c7d7c-d473-4c5c-a626-6db46aa00a8b@github.com>
References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com>
 <m7HPpbiNt-o8XJS-EDDGsT2V4cH3UAs6Sm57Dmh2hPE=.ad3c7d7c-d473-4c5c-a626-6db46aa00a8b@github.com>
Message-ID: <nIC8N4izer4jmVMPxp-QgH7D3iv683xfolDk9pVwPuQ=.44998dec-701d-474f-817a-09b76061a313@github.com>

On Tue, 19 Jan 2021 19:42:38 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The change to AIOOBE is reasonable. Have you considered making this just as an implementation change and leave the spec as is?

What would be the benefits? AFAICT the CSR is still needed since it's a small behavioral change, and updating the spec helps communicate that change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2124

From mandy.chung at oracle.com  Tue Jan 19 20:45:33 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 19 Jan 2021 12:45:33 -0800
Subject: RFR: 8259911: byteArrayViewVarHandle should throw
 ArrayIndexOutOfBoundsException
In-Reply-To: <nIC8N4izer4jmVMPxp-QgH7D3iv683xfolDk9pVwPuQ=.44998dec-701d-474f-817a-09b76061a313@github.com>
References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com>
 <m7HPpbiNt-o8XJS-EDDGsT2V4cH3UAs6Sm57Dmh2hPE=.ad3c7d7c-d473-4c5c-a626-6db46aa00a8b@github.com>
 <nIC8N4izer4jmVMPxp-QgH7D3iv683xfolDk9pVwPuQ=.44998dec-701d-474f-817a-09b76061a313@github.com>
Message-ID: <a597002b-aa4d-51a2-4c66-be4a17019ec9@oracle.com>



On 1/19/21 12:33 PM, Claes Redestad wrote:
> On Tue, 19 Jan 2021 19:42:38 GMT, Mandy Chung <mchung at openjdk.org> wrote:
>
>> The change to AIOOBE is reasonable. Have you considered making this just as an implementation change and leave the spec as is?
> What would be the benefits? AFAICT the CSR is still needed since it's a small behavioral change, and updating the spec helps communicate that change.
>

There is no behavioral change since AIIOBE is a subtype of OOBE.? No 
spec change and so no CSR is needed.

Mandy

From claes.redestad at oracle.com  Tue Jan 19 20:46:57 2021
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 19 Jan 2021 21:46:57 +0100
Subject: IllegalStateException in CharsetDecoder when inspecting JarFile
 contents on Java 15
In-Reply-To: <CAHjP37HJgdyLL7QxO=cSu-TqaFL65pmSAB_uXaODUnkHadsjCA@mail.gmail.com>
References: <CAHjP37HJgdyLL7QxO=cSu-TqaFL65pmSAB_uXaODUnkHadsjCA@mail.gmail.com>
Message-ID: <af2b80bf-0861-a994-789f-f7235a4029d5@oracle.com>

Hi,

yes, this seems like a bug introduced by JDK-8243469 where the 
previously thread-safe UTF8ZipCoder is now using a thread-unsafe decoder 
to calculate the normalized hash. I'll file a bug and take a look.

/Claes

On 2021-01-19 20:19, Vitaly Davidovich wrote:
> Hi all,
>
> I observed the following stacktrace when inspecting a JarFile's contents
> using a parallel stream (i.e. FJ pool):
>
> Exception in thread "main" java.lang.IllegalStateException:
> java.lang.IllegalStateException: Current state = CODING_END, new state =
> FLUSHED
>
>                at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>
>                at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:64)
>
>                at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
>                at
> java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:500)
>
>                at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:481)
>
>                at
> java.base/java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:600)
>
>                at
> java.base/java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:678)
>
>                at
> java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:737)
>
>                at
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:159)
>
>                at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:173)
>
>                at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
>
>                at
> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
>
>                at
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:575)
>
>                at <stripped>.ClassVersions.conflicts(ClassVersions.java:703)
>
>                at <stripped>.ClassVersions.check(ClassVersions.java:743)
>
>                at <stripped>.ClassVersions.main(ClassVersions.java:839)
>
> Caused by: java.lang.IllegalStateException: Current state = CODING_END, new
> state = FLUSHED
>
>                at
> java.base/java.nio.charset.CharsetDecoder.throwIllegalStateException(CharsetDecoder.java:998)
>
>                at
> java.base/java.nio.charset.CharsetDecoder.flush(CharsetDecoder.java:681)
>
>                at
> java.base/java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:810)
>
>                at
> java.base/java.util.zip.ZipCoder.normalizedHashDecode(ZipCoder.java:136)
>
>                at
> java.base/java.util.zip.ZipCoder$UTF8ZipCoder.normalizedHash(ZipCoder.java:228)
>
>                at
> java.base/java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1527)
>
>                at
> java.base/java.util.zip.ZipFile$Source.<init>(ZipFile.java:1249)
>
>                at
> java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1211)
>
>                at
> java.base/java.util.zip.ZipFile$CleanableResource.<init>(ZipFile.java:701)
>
>                at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:240)
>
>                at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:171)
>
>                at java.base/java.util.jar.JarFile.<init>(JarFile.java:347)
>
>                at java.base/java.util.jar.JarFile.<init>(JarFile.java:318)
>
>                at java.base/java.util.jar.JarFile.<init>(JarFile.java:284)
>
>                at <stripped>.ClassVersions.lookupJar(ClassVersions.java:665)
>
>                at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>
>                at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
>
>                at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>
>                at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
>
>                at
> java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
>
>                at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>
>                at
> java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
>
>                at
> java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)
>
>                at
> java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
>
>                at
> java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1016)
>
>                at
> java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1665)
>
>                at
> java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1598)
>
>                at
> java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
>
>
> (Note: I stripped off some package names to protect the innocent).
>
>
> While investigating this a bit, I noticed some code that looks a bit
> suspect.  Namely:
>
>     - ZipCoder has a singleton UTF8ZipCoder
>     <https://github.com/openjdk/jdk/blob/05bcd67e6501f3824020edd1ab036c87888fa229/src/java.base/share/classes/java/util/zip/ZipCoder.java#L48>
>     instance it uses for UTF8 decoding.
>     - Source.get() creates a new Source
>     <https://github.com/openjdk/jdk/blob/05bcd67e6501f3824020edd1ab036c87888fa229/src/java.base/share/classes/java/util/zip/ZipFile.java#L1225>
>     instance outside of any synchronization
>
> The links above are to tip, but I think this code is the same in Java 15.
>
> It seems possible that multiple threads can end up in Source.get(), new up
> a Source, and proceed to use the decoder of UTF8ZipCoder racily.  Per my
> understanding (and CharsetDecoder javadoc), CharsetDecoders are not
> threadsafe.
>
> Any thoughts? Did I miss anything that would suggest the stacktrace above
> is due to something else entirely?
>
> Thanks

From redestad at openjdk.java.net  Tue Jan 19 21:02:50 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Jan 2021 21:02:50 GMT
Subject: RFR: 8259911: byteArrayViewVarHandle should throw
 ArrayIndexOutOfBoundsException
In-Reply-To: <nIC8N4izer4jmVMPxp-QgH7D3iv683xfolDk9pVwPuQ=.44998dec-701d-474f-817a-09b76061a313@github.com>
References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com>
 <m7HPpbiNt-o8XJS-EDDGsT2V4cH3UAs6Sm57Dmh2hPE=.ad3c7d7c-d473-4c5c-a626-6db46aa00a8b@github.com>
 <nIC8N4izer4jmVMPxp-QgH7D3iv683xfolDk9pVwPuQ=.44998dec-701d-474f-817a-09b76061a313@github.com>
Message-ID: <-XDe9bewjmDiiXLXhMk-dSK7xveyopFdNn8r0-599bk=.d2a712cd-d338-47d8-aaaa-f8fb58bd34b8@github.com>

On Tue, 19 Jan 2021 20:30:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> The change to AIOOBE is reasonable.    Have you considered making this just as an implementation change and leave the spec as is?
>
>> The change to AIOOBE is reasonable. Have you considered making this just as an implementation change and leave the spec as is?
> 
> What would be the benefits? AFAICT the CSR is still needed since it's a small behavioral change, and updating the spec helps communicate that change.

I agree the change is allowable within the current spec. The behavior change is observable, though, and however unlikely there might be code that relies on exact class of the exception being thrown.

So while perhaps not strictly needed, the spec change makes sense coming from the other way: If I have some array-based code then that will be throwing AIOOBE on OOBs. But the `byteArrayViewVarHandle` code is specified to throw IOOBE, so a developer picking it up would have to catch and rewrap exceptions or accept the compatibility risk. Harmonizing to specify AIOOBE improves the migration story. Case in point is #1855 which require changes to some tests that are expecting AIOOBE.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2124

From mchung at openjdk.java.net  Tue Jan 19 21:31:53 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 19 Jan 2021 21:31:53 GMT
Subject: RFR: 8259911: byteArrayViewVarHandle should throw
 ArrayIndexOutOfBoundsException
In-Reply-To: <-XDe9bewjmDiiXLXhMk-dSK7xveyopFdNn8r0-599bk=.d2a712cd-d338-47d8-aaaa-f8fb58bd34b8@github.com>
References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com>
 <m7HPpbiNt-o8XJS-EDDGsT2V4cH3UAs6Sm57Dmh2hPE=.ad3c7d7c-d473-4c5c-a626-6db46aa00a8b@github.com>
 <nIC8N4izer4jmVMPxp-QgH7D3iv683xfolDk9pVwPuQ=.44998dec-701d-474f-817a-09b76061a313@github.com>
 <-XDe9bewjmDiiXLXhMk-dSK7xveyopFdNn8r0-599bk=.d2a712cd-d338-47d8-aaaa-f8fb58bd34b8@github.com>
Message-ID: <FZx04R-GCksX8rhyyWnT_YuaIVqx4q5oQ3eHUO0q9A0=.a6706018-a4af-48f0-ba47-84b96203bdb0@github.com>

On Tue, 19 Jan 2021 20:59:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> I agree the change is allowable within the current spec. The behavior change is observable, though, and however unlikely there might be code that relies on exact class of the exception being thrown.
> So while perhaps not strictly needed, the spec change makes sense coming from the other way: If I have some array-based code then that will be throwing AIOOBE on OOBs. But the `byteArrayViewVarHandle` code is specified to throw IOOBE, so a developer picking it up would have to catch and rewrap exceptions or accept the compatibility risk. Harmonizing to specify AIOOBE improves the migration story.

I don't think there is any migration story.   The exception type is an improved clarity.   The spec change is very minor and I'm okay with or without the spec change. 

> Case in point is #1855 which require changes to some tests that are expecting AIOOBE.

Yes, that's what I was about to ask too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2124

From psandoz at openjdk.java.net  Tue Jan 19 21:43:51 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 19 Jan 2021 21:43:51 GMT
Subject: RFR: 8259925: [Vector API] Unreasonable IndexOutOfBoundsException
 message when length < vlen
In-Reply-To: <IXlGGauVhUjxPJXm8CjZ0Eo4-ySUttJ_EqYpxiW7p8E=.32dc9082-78ad-4407-a6a2-3652dfef8a4c@github.com>
References: <IXlGGauVhUjxPJXm8CjZ0Eo4-ySUttJ_EqYpxiW7p8E=.32dc9082-78ad-4407-a6a2-3652dfef8a4c@github.com>
Message-ID: <LzL6761_WZOicSWpwUGbYjnnWKlqQPSLtMqLKp5Q_ls=.343834be-ef22-4bc1-91c5-c8388627f6f5@github.com>

On Mon, 18 Jan 2021 13:32:24 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> For this reproducer:
> 
> import jdk.incubator.vector.ByteVector;
> import jdk.incubator.vector.VectorSpecies;
> 
> public class Test {
>     static final VectorSpecies<Byte> SPECIES_128 = ByteVector.SPECIES_128;
>     static byte[] a = new byte[8];
>     static byte[] b = new byte[8];
> 
>     public static void main(String[] args) {
>         ByteVector av = ByteVector.fromArray(SPECIES_128, a, 0);
>         av.intoArray(b, 0);
>         System.out.println("b: " + b[0]);
>     }
> }
> 
> The following IndexOutOfBoundsException message (length -7) is unreasonable.
> 
> Exception in thread "main" java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length -7
> 
> It might be better to fix it like this.
> 
> Exception in thread "main" java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
> 
> Thanks.
> Best regards,
> Jie

That change may cause performance issues. I would recommend leaving as is for now even through the error message is not great. Bounds checking is quite sensitive and WIP. Notice that we also have an option to call `Objects.checkFromIndexSize` which expresses the intent more accurately, but that is currently less optimal (at least it was when i last checked since it is non an intrinsic).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2127

From jwilhelm at openjdk.java.net  Tue Jan 19 21:55:08 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 19 Jan 2021 21:55:08 GMT
Subject: RFR: Merge jdk16
Message-ID: <PKoHrV_rHcteYddpS-yR-joRcLw549blz6MxvukoqTc=.20058584-34dd-492c-a678-08fd97d4d83e@github.com>

Forwardport JDK 16 -> JDK 17

-------------

Commit messages:
 - Merge
 - 8259796: timed CompletableFuture.get may swallow InterruptedException

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2151&range=00.0
 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2151&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/2151/files
  Stats: 88 lines in 2 files changed: 29 ins; 26 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2151.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2151/head:pull/2151

PR: https://git.openjdk.java.net/jdk/pull/2151

From claes.redestad at oracle.com  Tue Jan 19 21:58:06 2021
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 19 Jan 2021 22:58:06 +0100
Subject: IllegalStateException in CharsetDecoder when inspecting JarFile
 contents on Java 15
In-Reply-To: <af2b80bf-0861-a994-789f-f7235a4029d5@oracle.com>
References: <CAHjP37HJgdyLL7QxO=cSu-TqaFL65pmSAB_uXaODUnkHadsjCA@mail.gmail.com>
 <af2b80bf-0861-a994-789f-f7235a4029d5@oracle.com>
Message-ID: <92cf1c9a-18e4-859f-4421-f0c049c33c68@oracle.com>

Filed: https://bugs.openjdk.java.net/browse/JDK-8260010

I have a potential fix ready, just trying to distill a minimal test case.

/Claes

On 2021-01-19 21:46, Claes Redestad wrote:
> Hi,
>
> yes, this seems like a bug introduced by JDK-8243469 where the 
> previously thread-safe UTF8ZipCoder is now using a thread-unsafe 
> decoder to calculate the normalized hash. I'll file a bug and take a 
> look.
>
> /Claes
>
> On 2021-01-19 20:19, Vitaly Davidovich wrote:
>> Hi all,
>>
>> I observed the following stacktrace when inspecting a JarFile's contents
>> using a parallel stream (i.e. FJ pool):
>>
>> Exception in thread "main" java.lang.IllegalStateException:
>> java.lang.IllegalStateException: Current state = CODING_END, new state =
>> FLUSHED
>>
>> ?????????????? at
>> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
>>
>> Method)
>>
>> ?????????????? at
>> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:64) 
>>
>>
>> ?????????????? at
>> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) 
>>
>>
>> ?????????????? at
>> java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:500) 
>>
>>
>> ?????????????? at
>> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:481) 
>>
>>
>> ?????????????? at
>> java.base/java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:600) 
>>
>>
>> ?????????????? at
>> java.base/java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:678) 
>>
>>
>> ?????????????? at
>> java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:737) 
>>
>>
>> ?????????????? at
>> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:159) 
>>
>>
>> ?????????????? at
>> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:173) 
>>
>>
>> ?????????????? at
>> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233) 
>>
>>
>> ?????????????? at
>> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497) 
>>
>>
>> ?????????????? at
>> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:575) 
>>
>>
>> ?????????????? at 
>> <stripped>.ClassVersions.conflicts(ClassVersions.java:703)
>>
>> ?????????????? at <stripped>.ClassVersions.check(ClassVersions.java:743)
>>
>> ?????????????? at <stripped>.ClassVersions.main(ClassVersions.java:839)
>>
>> Caused by: java.lang.IllegalStateException: Current state = 
>> CODING_END, new
>> state = FLUSHED
>>
>> ?????????????? at
>> java.base/java.nio.charset.CharsetDecoder.throwIllegalStateException(CharsetDecoder.java:998) 
>>
>>
>> ?????????????? at
>> java.base/java.nio.charset.CharsetDecoder.flush(CharsetDecoder.java:681)
>>
>> ?????????????? at
>> java.base/java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:810) 
>>
>>
>> ?????????????? at
>> java.base/java.util.zip.ZipCoder.normalizedHashDecode(ZipCoder.java:136)
>>
>> ?????????????? at
>> java.base/java.util.zip.ZipCoder$UTF8ZipCoder.normalizedHash(ZipCoder.java:228) 
>>
>>
>> ?????????????? at
>> java.base/java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1527)
>>
>> ?????????????? at
>> java.base/java.util.zip.ZipFile$Source.<init>(ZipFile.java:1249)
>>
>> ?????????????? at
>> java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1211)
>>
>> ?????????????? at
>> java.base/java.util.zip.ZipFile$CleanableResource.<init>(ZipFile.java:701) 
>>
>>
>> ?????????????? at 
>> java.base/java.util.zip.ZipFile.<init>(ZipFile.java:240)
>>
>> ?????????????? at 
>> java.base/java.util.zip.ZipFile.<init>(ZipFile.java:171)
>>
>> ?????????????? at 
>> java.base/java.util.jar.JarFile.<init>(JarFile.java:347)
>>
>> ?????????????? at 
>> java.base/java.util.jar.JarFile.<init>(JarFile.java:318)
>>
>> ?????????????? at 
>> java.base/java.util.jar.JarFile.<init>(JarFile.java:284)
>>
>> ?????????????? at 
>> <stripped>.ClassVersions.lookupJar(ClassVersions.java:665)
>>
>> ?????????????? at
>> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) 
>>
>>
>> ?????????????? at
>> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177) 
>>
>>
>> ?????????????? at
>> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) 
>>
>>
>> ?????????????? at
>> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177) 
>>
>>
>> ?????????????? at
>> java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) 
>>
>>
>> ?????????????? at
>> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) 
>>
>>
>> ?????????????? at
>> java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290) 
>>
>>
>> ?????????????? at
>> java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746) 
>>
>>
>> ?????????????? at
>> java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) 
>>
>>
>> ?????????????? at
>> java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1016) 
>>
>>
>> ?????????????? at
>> java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1665)
>>
>> ?????????????? at
>> java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1598) 
>>
>>
>> ?????????????? at
>> java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183) 
>>
>>
>>
>> (Note: I stripped off some package names to protect the innocent).
>>
>>
>> While investigating this a bit, I noticed some code that looks a bit
>> suspect.? Namely:
>>
>> ??? - ZipCoder has a singleton UTF8ZipCoder
>> <https://github.com/openjdk/jdk/blob/05bcd67e6501f3824020edd1ab036c87888fa229/src/java.base/share/classes/java/util/zip/ZipCoder.java#L48>
>> ??? instance it uses for UTF8 decoding.
>> ??? - Source.get() creates a new Source
>> <https://github.com/openjdk/jdk/blob/05bcd67e6501f3824020edd1ab036c87888fa229/src/java.base/share/classes/java/util/zip/ZipFile.java#L1225>
>> ??? instance outside of any synchronization
>>
>> The links above are to tip, but I think this code is the same in Java 
>> 15.
>>
>> It seems possible that multiple threads can end up in Source.get(), 
>> new up
>> a Source, and proceed to use the decoder of UTF8ZipCoder racily.? Per my
>> understanding (and CharsetDecoder javadoc), CharsetDecoders are not
>> threadsafe.
>>
>> Any thoughts? Did I miss anything that would suggest the stacktrace 
>> above
>> is due to something else entirely?
>>
>> Thanks

From vitalyd at gmail.com  Tue Jan 19 22:08:43 2021
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 19 Jan 2021 17:08:43 -0500
Subject: IllegalStateException in CharsetDecoder when inspecting JarFile
 contents on Java 15
In-Reply-To: <92cf1c9a-18e4-859f-4421-f0c049c33c68@oracle.com>
References: <CAHjP37HJgdyLL7QxO=cSu-TqaFL65pmSAB_uXaODUnkHadsjCA@mail.gmail.com>
 <af2b80bf-0861-a994-789f-f7235a4029d5@oracle.com>
 <92cf1c9a-18e4-859f-4421-f0c049c33c68@oracle.com>
Message-ID: <CAHjP37GffOhnNW0yEnZYCQdiVFzKksjf026QGV0PNB2jdkdg0A@mail.gmail.com>

Hi Claes,

You?re fast! :) Thanks for the bug report and working on a fix.

Best,

Vitaly

On Tue, Jan 19, 2021 at 5:00 PM Claes Redestad <claes.redestad at oracle.com>
wrote:

> Filed: https://bugs.openjdk.java.net/browse/JDK-8260010
>
> I have a potential fix ready, just trying to distill a minimal test case.
>
> /Claes
>
> On 2021-01-19 21:46, Claes Redestad wrote:
> > Hi,
> >
> > yes, this seems like a bug introduced by JDK-8243469 where the
> > previously thread-safe UTF8ZipCoder is now using a thread-unsafe
> > decoder to calculate the normalized hash. I'll file a bug and take a
> > look.
> >
> > /Claes
> >
> > On 2021-01-19 20:19, Vitaly Davidovich wrote:
> >> Hi all,
> >>
> >> I observed the following stacktrace when inspecting a JarFile's contents
> >> using a parallel stream (i.e. FJ pool):
> >>
> >> Exception in thread "main" java.lang.IllegalStateException:
> >> java.lang.IllegalStateException: Current state = CODING_END, new state =
> >> FLUSHED
> >>
> >>                at
> >>
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>
> >>
> >> Method)
> >>
> >>                at
> >>
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:64)
>
> >>
> >>
> >>                at
> >>
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
> >>
> >>
> >>                at
> >>
> java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:500)
>
> >>
> >>
> >>                at
> >>
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:481)
> >>
> >>
> >>                at
> >>
> java.base/java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:600)
>
> >>
> >>
> >>                at
> >>
> java.base/java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:678)
>
> >>
> >>
> >>                at
> >>
> java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:737)
> >>
> >>
> >>                at
> >>
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:159)
>
> >>
> >>
> >>                at
> >>
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:173)
>
> >>
> >>
> >>                at
> >>
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
>
> >>
> >>
> >>                at
> >>
> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
>
> >>
> >>
> >>                at
> >>
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:575)
>
> >>
> >>
> >>                at
> >> <stripped>.ClassVersions.conflicts(ClassVersions.java:703)
> >>
> >>                at <stripped>.ClassVersions.check(ClassVersions.java:743)
> >>
> >>                at <stripped>.ClassVersions.main(ClassVersions.java:839)
> >>
> >> Caused by: java.lang.IllegalStateException: Current state =
> >> CODING_END, new
> >> state = FLUSHED
> >>
> >>                at
> >>
> java.base/java.nio.charset.CharsetDecoder.throwIllegalStateException(CharsetDecoder.java:998)
>
> >>
> >>
> >>                at
> >> java.base/java.nio.charset.CharsetDecoder.flush(CharsetDecoder.java:681)
> >>
> >>                at
> >>
> java.base/java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:810)
> >>
> >>
> >>                at
> >> java.base/java.util.zip.ZipCoder.normalizedHashDecode(ZipCoder.java:136)
> >>
> >>                at
> >>
> java.base/java.util.zip.ZipCoder$UTF8ZipCoder.normalizedHash(ZipCoder.java:228)
>
> >>
> >>
> >>                at
> >> java.base/java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1527)
> >>
> >>                at
> >> java.base/java.util.zip.ZipFile$Source.<init>(ZipFile.java:1249)
> >>
> >>                at
> >> java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1211)
> >>
> >>                at
> >>
> java.base/java.util.zip.ZipFile$CleanableResource.<init>(ZipFile.java:701)
> >>
> >>
> >>                at
> >> java.base/java.util.zip.ZipFile.<init>(ZipFile.java:240)
> >>
> >>                at
> >> java.base/java.util.zip.ZipFile.<init>(ZipFile.java:171)
> >>
> >>                at
> >> java.base/java.util.jar.JarFile.<init>(JarFile.java:347)
> >>
> >>                at
> >> java.base/java.util.jar.JarFile.<init>(JarFile.java:318)
> >>
> >>                at
> >> java.base/java.util.jar.JarFile.<init>(JarFile.java:284)
> >>
> >>                at
> >> <stripped>.ClassVersions.lookupJar(ClassVersions.java:665)
> >>
> >>                at
> >>
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>
> >>
> >>
> >>                at
> >>
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
>
> >>
> >>
> >>                at
> >>
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>
> >>
> >>
> >>                at
> >>
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
>
> >>
> >>
> >>                at
> >>
> java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
>
> >>
> >>
> >>                at
> >>
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>
> >>
> >>
> >>                at
> >>
> java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
>
> >>
> >>
> >>                at
> >>
> java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)
>
> >>
> >>
> >>                at
> >>
> java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
> >>
> >>
> >>                at
> >>
> java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1016)
>
> >>
> >>
> >>                at
> >> java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1665)
> >>
> >>                at
> >>
> java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1598)
>
> >>
> >>
> >>                at
> >>
> java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
>
> >>
> >>
> >>
> >> (Note: I stripped off some package names to protect the innocent).
> >>
> >>
> >> While investigating this a bit, I noticed some code that looks a bit
> >> suspect.  Namely:
> >>
> >>     - ZipCoder has a singleton UTF8ZipCoder
> >> <
> https://github.com/openjdk/jdk/blob/05bcd67e6501f3824020edd1ab036c87888fa229/src/java.base/share/classes/java/util/zip/ZipCoder.java#L48
> >
> >>     instance it uses for UTF8 decoding.
> >>     - Source.get() creates a new Source
> >> <
> https://github.com/openjdk/jdk/blob/05bcd67e6501f3824020edd1ab036c87888fa229/src/java.base/share/classes/java/util/zip/ZipFile.java#L1225
> >
> >>     instance outside of any synchronization
> >>
> >> The links above are to tip, but I think this code is the same in Java
> >> 15.
> >>
> >> It seems possible that multiple threads can end up in Source.get(),
> >> new up
> >> a Source, and proceed to use the decoder of UTF8ZipCoder racily.  Per my
> >> understanding (and CharsetDecoder javadoc), CharsetDecoders are not
> >> threadsafe.
> >>
> >> Any thoughts? Did I miss anything that would suggest the stacktrace
> >> above
> >> is due to something else entirely?
> >>
> >> Thanks
>
-- 
Sent from my phone

From valeriep at openjdk.java.net  Tue Jan 19 22:29:44 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 19 Jan 2021 22:29:44 GMT
Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests [v4]
In-Reply-To: <Fgyp3R-dyor_O80NO9PyMFy-_hy1WxbtBr-M6uGloP8=.f9fbf907-8419-41b7-b028-4adaa610e69d@github.com>
References: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
 <Fgyp3R-dyor_O80NO9PyMFy-_hy1WxbtBr-M6uGloP8=.f9fbf907-8419-41b7-b028-4adaa610e69d@github.com>
Message-ID: <ozg9Szotmd2lsDBbNi3-p1VkspaV6B1UWxdHzvXwqCc=.948fb49a-f896-4326-af8b-4bdc3cd77ddc@github.com>

On Mon, 18 Jan 2021 13:39:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration
>> - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization.
>> - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence.
>> 
>> Baseline:
>>                               (digesterName)  (length)    Cnt     Score      Error   Units
>> MessageDigests.digest                                MD5        16     15  2714.307 ?   21.133  ops/ms
>> MessageDigests.digest                                MD5      1024     15   318.087 ?    0.637  ops/ms
>> MessageDigests.digest                              SHA-1        16     15  1387.266 ?   40.932  ops/ms
>> MessageDigests.digest                              SHA-1      1024     15   109.273 ?    0.149  ops/ms
>> MessageDigests.digest                            SHA-256        16     15   995.566 ?   21.186  ops/ms
>> MessageDigests.digest                            SHA-256      1024     15    89.104 ?    0.079  ops/ms
>> MessageDigests.digest                            SHA-512        16     15   803.030 ?   15.722  ops/ms
>> MessageDigests.digest                            SHA-512      1024     15   115.611 ?    0.234  ops/ms
>> MessageDigests.getAndDigest                          MD5        16     15  2190.367 ?   97.037  ops/ms
>> MessageDigests.getAndDigest                          MD5      1024     15   302.903 ?    1.809  ops/ms
>> MessageDigests.getAndDigest                        SHA-1        16     15  1262.656 ?   43.751  ops/ms
>> MessageDigests.getAndDigest                        SHA-1      1024     15   104.889 ?    3.554  ops/ms
>> MessageDigests.getAndDigest                      SHA-256        16     15   914.541 ?   55.621  ops/ms
>> MessageDigests.getAndDigest                      SHA-256      1024     15    85.708 ?    1.394  ops/ms
>> MessageDigests.getAndDigest                      SHA-512        16     15   737.719 ?   53.671  ops/ms
>> MessageDigests.getAndDigest                      SHA-512      1024     15   112.307 ?    1.950  ops/ms
>> 
>> GC:
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   312.011 ?    0.005    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.020 ?    0.006    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   544.019 ?    0.016    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15  1056.037 ?    0.003    B/op
>> 
>> Target:
>> Benchmark                                 (digesterName)  (length)    Cnt     Score      Error   Units
>> MessageDigests.digest                                MD5        16     15  3134.462 ?   43.685  ops/ms
>> MessageDigests.digest                                MD5      1024     15   323.667 ?    0.633  ops/ms
>> MessageDigests.digest                              SHA-1        16     15  1418.742 ?   38.223  ops/ms
>> MessageDigests.digest                              SHA-1      1024     15   110.178 ?    0.788  ops/ms
>> MessageDigests.digest                            SHA-256        16     15  1037.949 ?   21.214  ops/ms
>> MessageDigests.digest                            SHA-256      1024     15    89.671 ?    0.228  ops/ms
>> MessageDigests.digest                            SHA-512        16     15   812.028 ?   39.489  ops/ms
>> MessageDigests.digest                            SHA-512      1024     15   116.738 ?    0.249  ops/ms
>> MessageDigests.getAndDigest                          MD5        16     15  2314.379 ?  229.294  ops/ms
>> MessageDigests.getAndDigest                          MD5      1024     15   307.835 ?    5.730  ops/ms
>> MessageDigests.getAndDigest                        SHA-1        16     15  1326.887 ?   63.263  ops/ms
>> MessageDigests.getAndDigest                        SHA-1      1024     15   106.611 ?    2.292  ops/ms
>> MessageDigests.getAndDigest                      SHA-256        16     15   961.589 ?   82.052  ops/ms
>> MessageDigests.getAndDigest                      SHA-256      1024     15    88.646 ?    0.194  ops/ms
>> MessageDigests.getAndDigest                      SHA-512        16     15   775.417 ?   56.775  ops/ms
>> MessageDigests.getAndDigest                      SHA-512      1024     15   112.904 ?    2.014  ops/ms
>> 
>> GC
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   232.009 ?    0.006    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.021 ?    0.001    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   272.012 ?    0.015    B/op
>> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15   400.017 ?    0.019    B/op
>> 
>> For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW.
>> 
>> For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test.
>> 
>> I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused code

Marked as reviewed by valeriep (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1855

From jwilhelm at openjdk.java.net  Tue Jan 19 22:52:53 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 19 Jan 2021 22:52:53 GMT
Subject: Integrated: Merge jdk16
In-Reply-To: <PKoHrV_rHcteYddpS-yR-joRcLw549blz6MxvukoqTc=.20058584-34dd-492c-a678-08fd97d4d83e@github.com>
References: <PKoHrV_rHcteYddpS-yR-joRcLw549blz6MxvukoqTc=.20058584-34dd-492c-a678-08fd97d4d83e@github.com>
Message-ID: <_-eSlD3cqpqxbmWsLF6Yic7iy6FZF2fmt5l69beqhpw=.8f96ec1c-2435-43c1-a4ec-6147f6060281@github.com>

On Tue, 19 Jan 2021 21:48:55 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: cf25383d
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cf25383d
Stats:     88 lines in 2 files changed: 29 ins; 26 del; 33 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/2151

From amenkov at openjdk.java.net  Tue Jan 19 23:02:54 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 19 Jan 2021 23:02:54 GMT
Subject: RFR: 8258917: NativeMemoryTracking is handled by launcher
 inconsistenly [v2]
In-Reply-To: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
References: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
Message-ID: <1ojc6R4Tkg2oSXjEb7Y2nrvb-fcoZICYVckWdkcQ3FA=.f6ad204e-ff50-4669-a17e-8bf037e0d18f@github.com>

> The fix adds NMT handling for non-java launchers

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  Non-lava launchers should process all "-J" arguments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2106/files
  - new: https://git.openjdk.java.net/jdk/pull/2106/files/53e876e9..69c63609

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2106&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2106&range=00-01

  Stats: 16 lines in 2 files changed: 8 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2106.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2106/head:pull/2106

PR: https://git.openjdk.java.net/jdk/pull/2106

From github.com+652983+dasbrain at openjdk.java.net  Tue Jan 19 23:06:22 2021
From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn)
Date: Tue, 19 Jan 2021 23:06:22 GMT
Subject: RFR: JDK-8259395 Patching automatic module with additional
 packages re-creates module without "requires java.base" [v3]
In-Reply-To: <ak44W6IV6an9Zm4lxsOFcqV1qO4YXDctpgMrz9cfJHA=.e767d207-e37d-406d-86cf-afded1d33e42@github.com>
References: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
 <xPmjPGTgkdOOuaNrcm9fO0FhBtsUb-L9FGbJ40bDUNo=.4112f09a-b483-4e7d-b57a-be8e208721aa@github.com>
 <il4tZHeQpGludQJR1E4bL4VT6GlUrnYlCIquM2Xzru0=.313848ed-c980-4778-9c7c-5984e81d6ea1@github.com>
 <FtnsXvDoFKVs4kO4jcovhBbk49VGOpYVZdsFS_lW0N8=.917908d6-62c7-4858-8068-e0873288b115@github.com>
 <tp2onYs7y3jh2mpZNnKpeOTLQ7zGXDq07pxSb1LFrKU=.055a3225-00da-46ab-9b20-d912e0d017c1@github.com>
 <pB72SpIMCKsU9aW9YTfft_2psI6wIMvg-j-1y9zYzN0=.20e5e82c-36b1-453d-b8fc-1f79c26c7018@github.com>
 <ak44W6IV6an9Zm4lxsOFcqV1qO4YXDctpgMrz9cfJHA=.e767d207-e37d-406d-86cf-afded1d33e42@github.com>
Message-ID: <2-9rehwJTSSdpfImnQy9g4d2PM9ZxKy7BisMbVOlKNg=.96018b56-239e-4e43-ad5e-7bc11cdf3856@github.com>

On Tue, 19 Jan 2021 16:14:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> 
>>> 
>>> This issue requires a Reviewer from someone working in this area. Please do not sponsor or integrate until that review has been done.
>> 
>> Ok, increased the number of required reviewers to 2.  
>> Hope that was the right move, as I don't see any other way to undo /integrate.
>
> Finally getting back to this. The update to ModulePatcher.java is good. Test coverage needs discussion. There are four scenarios where test coverage is lacking:
> 
> 1. automatic module on the module path, patched to override or augment classes/resources
> 2. automatic module on the module path, patched to add new packages
> 3. automatic module as the initial module, patched to override or augment classes/resources
> 4. automatic module as the initial module, patched to add new packages
> 
> The patch adds automatic/PatchTest.java so it's adding test coverage for 4. We should probably rename it to leave room for the other tests, or else create it so that additional test coverage can be added. I assume the test was copied from another test as there are a few left overs, e.g. `@modules java.script` but the test does not use this module. I don't want to expand the scope of this PR too much but I think we should at least cover 3 and 4 in the test.

Thanks @AlanBateman, I now implemented a few more tests.  
They should cover all four cases you described.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2000

From github.com+652983+dasbrain at openjdk.java.net  Tue Jan 19 23:06:20 2021
From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn)
Date: Tue, 19 Jan 2021 23:06:20 GMT
Subject: RFR: JDK-8259395 Patching automatic module with additional
 packages re-creates module without "requires java.base" [v4]
In-Reply-To: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
References: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
Message-ID: <A3Vx0UILhaiUcd_-1ulQWB_7313TS1NvvW0tPDaaXC0=.0cf70b24-6e7f-406a-a53c-6ac873f51967@github.com>

> Simple fix - one line change: https://openjdk.github.io/cr/?repo=jdk&pr=2000&range=00#sdiff-0.
> 
> Most of the changes come from an additional test that fails without this fix:
> 
>      Error: Unable to load main class somelib.test.TestMain in module somelib
>     	java.lang.IllegalAccessError: superclass access check failed: class somelib.test.TestMain (in module somelib) cannot access class java.lang.Object (in module java.base) because module java.base does not export java.lang to module somelib
> 
> As described in JDK-8259395.
> You can view the output of the test without patch here: https://github.com/DasBrain/jdk/runs/1668078245
> 
> Thanks to @AlanBateman for pointing out the right fix.

Johannes Kuhn has updated the pull request incrementally with one additional commit since the last revision:

  Implement more tests.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2000/files
  - new: https://git.openjdk.java.net/jdk/pull/2000/files/7c2ed088..fc3b2ac0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2000&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2000&range=02-03

  Stats: 388 lines in 10 files changed: 316 ins; 54 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2000.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2000/head:pull/2000

PR: https://git.openjdk.java.net/jdk/pull/2000

From amenkov at openjdk.java.net  Tue Jan 19 23:06:52 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 19 Jan 2021 23:06:52 GMT
Subject: RFR: 8258917: NativeMemoryTracking is handled by launcher
 inconsistenly [v2]
In-Reply-To: <UE_59PhMZObtAkkTyP8iu9Sox2_pmCGNBTgSxTR2FLY=.24370d98-09b0-4f6f-8587-9cb6f3a55363@github.com>
References: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
 <UE_59PhMZObtAkkTyP8iu9Sox2_pmCGNBTgSxTR2FLY=.24370d98-09b0-4f6f-8587-9cb6f3a55363@github.com>
Message-ID: <9Jz7QM4wmtqtmc9xlnd4yBfW1fcEky2CJrMhMZjbIVo=.2eaa7cbf-d5e0-460e-9f02-d57768e79dbf@github.com>

On Sun, 17 Jan 2021 12:55:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Non-lava launchers should process all "-J" arguments
>
> Alex,
> 
> This approach results in two scans of the argument list in the IsJavaArgs case. I don't know if we care about startup in the non-Java launchers, but this will likely affect it.
> 
> David

@dholmes-ora 

> Also, I'm not sure the scanning logic in SetJvmEnvironment is valid for
> the IsJavaArgs case. It states:
> 
> /*
> * Since this must be a VM flag we stop processing once we see
> * an argument the launcher would not have processed beyond (such
> * as -version or -h), or an argument that indicates the following
> * arguments are for the application (i.e. the main class name, or
> * the -jar argument).
> */
> 
> but the argument rules for other commands are different.

yes, you are right.
TranslateApplicationArgs translates all "-J" args.
I updated the fix.
For non-java launchers we don't need to scan java args as we know they don't contain -J-XX:NativeMemoryTracking

-------------

PR: https://git.openjdk.java.net/jdk/pull/2106

From github.com+652983+dasbrain at openjdk.java.net  Tue Jan 19 23:12:02 2021
From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn)
Date: Tue, 19 Jan 2021 23:12:02 GMT
Subject: RFR: JDK-8259395 Patching automatic module with additional
 packages re-creates module without "requires java.base" [v5]
In-Reply-To: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
References: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
Message-ID: <7QFhztqPN4Z3ZI2qvxDG9PRJKMxGWxM4h1azimX3CKQ=.4eb110b1-1dc7-4a7f-8017-716131d13545@github.com>

> Simple fix - one line change: https://openjdk.github.io/cr/?repo=jdk&pr=2000&range=00#sdiff-0.
> 
> Most of the changes come from an additional test that fails without this fix:
> 
>      Error: Unable to load main class somelib.test.TestMain in module somelib
>     	java.lang.IllegalAccessError: superclass access check failed: class somelib.test.TestMain (in module somelib) cannot access class java.lang.Object (in module java.base) because module java.base does not export java.lang to module somelib
> 
> As described in JDK-8259395.
> You can view the output of the test without patch here: https://github.com/DasBrain/jdk/runs/1668078245
> 
> Thanks to @AlanBateman for pointing out the right fix.

Johannes Kuhn has updated the pull request incrementally with one additional commit since the last revision:

  Fix comment, and missing newline in module-info.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2000/files
  - new: https://git.openjdk.java.net/jdk/pull/2000/files/fc3b2ac0..15a057d9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2000&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2000&range=03-04

  Stats: 7 lines in 5 files changed: 0 ins; 2 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2000.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2000/head:pull/2000

PR: https://git.openjdk.java.net/jdk/pull/2000

From amenkov at openjdk.java.net  Tue Jan 19 23:16:50 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 19 Jan 2021 23:16:50 GMT
Subject: RFR: 8258917: NativeMemoryTracking is handled by launcher
 inconsistenly [v2]
In-Reply-To: <UE_59PhMZObtAkkTyP8iu9Sox2_pmCGNBTgSxTR2FLY=.24370d98-09b0-4f6f-8587-9cb6f3a55363@github.com>
References: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
 <UE_59PhMZObtAkkTyP8iu9Sox2_pmCGNBTgSxTR2FLY=.24370d98-09b0-4f6f-8587-9cb6f3a55363@github.com>
Message-ID: <tMJQkbN3YGm6dlODxwW4xUJvrc9k5ty1rtFXtS1Xn0Q=.f9b7a04f-ecc4-4e81-b3d8-c76952556539@github.com>

On Sun, 17 Jan 2021 12:55:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Non-lava launchers should process all "-J" arguments
>
> Alex,
> 
> This approach results in two scans of the argument list in the IsJavaArgs case. I don't know if we care about startup in the non-Java launchers, but this will likely affect it.
> 
> David

@dholmes-ora 

> This approach results in two scans of the argument list in the IsJavaArgs case. I don't know if we care about startup in the non-Java launchers, but this will likely affect it.

The impact is minimal (cycle through args, check if it starts from the string).
As far as I see to avoid extra scans JLI_Launch code needs to be reordered:
CreateExecutionEnvironment();
if (IsJavaArgs()) {
    TranslateApplicationArgs(jargc, jargv, &argc, &argv);
}
ParseArguments(&argc, &argv, &mode, &what, &ret, jrepath);
LoadJavaVM();

And handle NMT arg in ParseArguments

But this change would be much more risky.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2106

From dholmes at openjdk.java.net  Tue Jan 19 23:20:46 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 19 Jan 2021 23:20:46 GMT
Subject: RFR: 8258917: NativeMemoryTracking is handled by launcher
 inconsistenly [v2]
In-Reply-To: <1ojc6R4Tkg2oSXjEb7Y2nrvb-fcoZICYVckWdkcQ3FA=.f6ad204e-ff50-4669-a17e-8bf037e0d18f@github.com>
References: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
 <1ojc6R4Tkg2oSXjEb7Y2nrvb-fcoZICYVckWdkcQ3FA=.f6ad204e-ff50-4669-a17e-8bf037e0d18f@github.com>
Message-ID: <9YSxbXm9PS0nI-nLOCayqUooZDOpuIz50AeuiHwGT04=.53a3951a-b5aa-4e17-804c-9588fb1ce801@github.com>

On Tue, 19 Jan 2021 23:02:54 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix adds NMT handling for non-java launchers
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Non-lava launchers should process all "-J" arguments

Hi Alex,

I think this is functionally correct now - though the comment you added is confusing to me (see below).

However I remain concerned that this requires processing the arg list twice for non-Java launchers. Is that a startup issue we should be concerned about?

Thanks,
David

src/java.base/share/native/libjli/java.c line 821:

> 819:          *   the -jar argument).
> 820:          * Non-java launchers:
> 821:          *   All "-J" arguments are translated to VM args (see TranslateApplicationArgs).

What do you mean by this? The -J args are not "translated" here but later in TranslateApplicationArgs.

For non-Java launchers AFAICS you have to process the entire argv array because you don't know where they may appear in general. So to me the comment should be:

* Other launchers (IsJavaArgs())
*   All arguments have to be scanned to see if it is a -J argument

-------------

PR: https://git.openjdk.java.net/jdk/pull/2106

From amenkov at openjdk.java.net  Wed Jan 20 01:47:54 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 20 Jan 2021 01:47:54 GMT
Subject: RFR: 8258917: NativeMemoryTracking is handled by launcher
 inconsistenly [v3]
In-Reply-To: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
References: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
Message-ID: <Bs9EErmySj3EJ0myZdK55gJCEPorfMJIPwUCm-vhhyE=.8afc2742-b240-4eea-8ec1-9d44e7ae6e6f@github.com>

> The fix adds NMT handling for non-java launchers

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  Updated comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2106/files
  - new: https://git.openjdk.java.net/jdk/pull/2106/files/69c63609..dd6f9617

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2106&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2106&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2106.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2106/head:pull/2106

PR: https://git.openjdk.java.net/jdk/pull/2106

From amenkov at openjdk.java.net  Wed Jan 20 01:47:55 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 20 Jan 2021 01:47:55 GMT
Subject: RFR: 8258917: NativeMemoryTracking is handled by launcher
 inconsistenly [v2]
In-Reply-To: <9YSxbXm9PS0nI-nLOCayqUooZDOpuIz50AeuiHwGT04=.53a3951a-b5aa-4e17-804c-9588fb1ce801@github.com>
References: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
 <1ojc6R4Tkg2oSXjEb7Y2nrvb-fcoZICYVckWdkcQ3FA=.f6ad204e-ff50-4669-a17e-8bf037e0d18f@github.com>
 <9YSxbXm9PS0nI-nLOCayqUooZDOpuIz50AeuiHwGT04=.53a3951a-b5aa-4e17-804c-9588fb1ce801@github.com>
Message-ID: <-STJkd8IWoyAlEMa8eXTq87Zx4W-rX49GEtgMTtzz7A=.90936ec1-a1b4-401a-903c-86c6da7df44f@github.com>

On Tue, 19 Jan 2021 23:16:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

> What do you mean by this? The -J args are not "translated" here but later in TranslateApplicationArgs.

I meant that they are translated in TranslateApplicationArgs. Looks like it's not clear. Updated the comment as you suggested.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2106

From eirbjo at gmail.com  Wed Jan 20 01:52:46 2021
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Wed, 20 Jan 2021 02:52:46 +0100
Subject: Reduce allocation in sun.net.www.protocol.jar.Handler.parseURL
Message-ID: <CA+pBWhv2e5ewfmOTzwvdO0su3oc5rmU_9Q5FaY_A69z9w02cBw@mail.gmail.com>

Hello,

sun.net.www.protocol.jar.Handler.parseURL unconditionally calls
String.substring twice on the spec string, even when
ParseUtil.canonizeString later determines that no canonization was required.

By letting canonizeString do the substring calls, but only when it
determines that it is needed, we can remove some unnecessary String and
byte[] allocations.

Patch:

https://github.com/eirbjo/jdk/commit/87da9032d7fb622f5d466f43faded4de672ebdda

JMH micro:

@Benchmark
public void initURL(Blackhole blackhole) throws MalformedURLException {
    blackhole.consume(new URL(new URL("jar:file:/spring-aop.jar!/"),
"org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.class"));
}

It shows a performance win for the patch in terms of throughput and bytes /
operation:

Baseline:

Benchmark                                               Mode  Cnt
 Score       Error   Units
ZipBenchmark.initURL                                   thrpt   25
 1673457.129 ? 22857.945   ops/s
ZipBenchmark.initURL:?gc.alloc.rate                    thrpt   25
1410.227 ?    19.283  MB/sec
ZipBenchmark.initURL:?gc.alloc.rate.norm               thrpt   25
 928.080 ?     0.005    B/op
ZipBenchmark.initURL:?gc.churn.G1_Eden_Space           thrpt   25
1412.557 ?    22.575  MB/sec
ZipBenchmark.initURL:?gc.churn.G1_Eden_Space.norm      thrpt   25
 929.589 ?     5.756    B/op
ZipBenchmark.initURL:?gc.churn.G1_Survivor_Space       thrpt   25
 0.006 ?     0.002  MB/sec
ZipBenchmark.initURL:?gc.churn.G1_Survivor_Space.norm  thrpt   25
 0.004 ?     0.001    B/op
ZipBenchmark.initURL:?gc.count                         thrpt   25
1441.000              counts
ZipBenchmark.initURL:?gc.time                          thrpt   25
 961.000                  ms

After:

Benchmark                                               Mode  Cnt
 Score       Error   Units
ZipBenchmark.initURL                                   thrpt   25
 1831971.983 ? 35705.091   ops/s
ZipBenchmark.initURL:?gc.alloc.rate                    thrpt   25
1011.389 ?    19.689  MB/sec
ZipBenchmark.initURL:?gc.alloc.rate.norm               thrpt   25
 608.061 ?     0.001    B/op
ZipBenchmark.initURL:?gc.churn.G1_Eden_Space           thrpt   25
1011.746 ?    20.583  MB/sec
ZipBenchmark.initURL:?gc.churn.G1_Eden_Space.norm      thrpt   25
 608.275 ?     3.609    B/op
ZipBenchmark.initURL:?gc.churn.G1_Survivor_Space       thrpt   25
 0.007 ?     0.001  MB/sec
ZipBenchmark.initURL:?gc.churn.G1_Survivor_Space.norm  thrpt   25
 0.004 ?     0.001    B/op
ZipBenchmark.initURL:?gc.count                         thrpt   25
1197.000              counts
ZipBenchmark.initURL:?gc.time                          thrpt   25
 760.000                  ms

Thanks,
Eirik.

From eirbjo at gmail.com  Wed Jan 20 02:57:05 2021
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Wed, 20 Jan 2021 03:57:05 +0100
Subject: Reduce allocation in sun.net.www.protocol.jar.Handler.parseURL
In-Reply-To: <CA+pBWhv2e5ewfmOTzwvdO0su3oc5rmU_9Q5FaY_A69z9w02cBw@mail.gmail.com>
References: <CA+pBWhv2e5ewfmOTzwvdO0su3oc5rmU_9Q5FaY_A69z9w02cBw@mail.gmail.com>
Message-ID: <CA+pBWhspYiOqwh1r2FsKxjxTmWOtweeeBKzVfjx8TDmCo5CBQQ@mail.gmail.com>

>
>
> By letting canonizeString do the substring calls, but only when it
> determines that it is needed, we can remove some unnecessary String and
> byte[] allocations.
>

While English is not my mother tongue, I'm thinking we could maybe let the
Vatican deal with canonizations and rename this to the more appropriate
"canonicalizeString"?

Eirik.

From abakhtin at openjdk.java.net  Wed Jan 20 07:23:46 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Wed, 20 Jan 2021 07:23:46 GMT
Subject: RFR: 8259707: LDAP channel binding does not work with StartTLS
 extension
In-Reply-To: <ufGH_BKloK8RlVDYOchBYFMHGLdVLIHcSmvGnNp8U5w=.9a2f9de0-a2c5-4031-be42-7daa9145258b@github.com>
References: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
 <ufGH_BKloK8RlVDYOchBYFMHGLdVLIHcSmvGnNp8U5w=.9a2f9de0-a2c5-4031-be42-7daa9145258b@github.com>
Message-ID: <jpZtdTb4qq99DE1xTKaNoLhPknv60_3qKMmT2VBIsIA=.c0983ef5-2188-429a-9a8d-d7f20a99b029@github.com>

On Tue, 19 Jan 2021 20:24:21 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS Extension.
>> Test from the bug report and jtreg javax/naming tests are passed.
>
> Can you add a test for this or is it too hard? There are existing tests for StartTLS in the security/infra area -- could they be enhanced to test this case?

Unfortunately, I can not find any LDAP StartTLS Extended Operation regression tests. security/infra area contains RevocationChecker tests. They can not be used for this scenario.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2085

From jiefu at openjdk.java.net  Wed Jan 20 09:39:10 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 20 Jan 2021 09:39:10 GMT
Subject: RFR: 8259925: [Vector API] Unreasonable IndexOutOfBoundsException
 message when length < vlen [v2]
In-Reply-To: <IXlGGauVhUjxPJXm8CjZ0Eo4-ySUttJ_EqYpxiW7p8E=.32dc9082-78ad-4407-a6a2-3652dfef8a4c@github.com>
References: <IXlGGauVhUjxPJXm8CjZ0Eo4-ySUttJ_EqYpxiW7p8E=.32dc9082-78ad-4407-a6a2-3652dfef8a4c@github.com>
Message-ID: <r3LcmA7Rb0Ig0loWdxWLc3EXSdFIma3D_QaN4fIU1Pc=.643e2834-5b96-4af8-aef3-7d283d2afcdd@github.com>

> Hi all,
> 
> For this reproducer:
> 
> import jdk.incubator.vector.ByteVector;
> import jdk.incubator.vector.VectorSpecies;
> 
> public class Test {
>     static final VectorSpecies<Byte> SPECIES_128 = ByteVector.SPECIES_128;
>     static byte[] a = new byte[8];
>     static byte[] b = new byte[8];
> 
>     public static void main(String[] args) {
>         ByteVector av = ByteVector.fromArray(SPECIES_128, a, 0);
>         av.intoArray(b, 0);
>         System.out.println("b: " + b[0]);
>     }
> }
> 
> The following IndexOutOfBoundsException message (length -7) is unreasonable.
> 
> Exception in thread "main" java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length -7
> 
> It might be better to fix it like this.
> 
> Exception in thread "main" java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
> 
> Thanks.
> Best regards,
> Jie

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Fix the performance issue

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2127/files
  - new: https://git.openjdk.java.net/jdk/pull/2127/files/ca39b482..3fd8b316

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2127&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2127&range=00-01

  Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2127/head:pull/2127

PR: https://git.openjdk.java.net/jdk/pull/2127

From jiefu at openjdk.java.net  Wed Jan 20 09:39:10 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 20 Jan 2021 09:39:10 GMT
Subject: RFR: 8259925: [Vector API] Unreasonable IndexOutOfBoundsException
 message when length < vlen
In-Reply-To: <LzL6761_WZOicSWpwUGbYjnnWKlqQPSLtMqLKp5Q_ls=.343834be-ef22-4bc1-91c5-c8388627f6f5@github.com>
References: <IXlGGauVhUjxPJXm8CjZ0Eo4-ySUttJ_EqYpxiW7p8E=.32dc9082-78ad-4407-a6a2-3652dfef8a4c@github.com>
 <LzL6761_WZOicSWpwUGbYjnnWKlqQPSLtMqLKp5Q_ls=.343834be-ef22-4bc1-91c5-c8388627f6f5@github.com>
Message-ID: <ZAH7vzOKC5VPi7V6ElL55VxQsgA4AAuVUOH4v8u4QfY=.4cb1b26e-6c19-4083-8495-2d046efa3ddd@github.com>

On Tue, 19 Jan 2021 21:40:24 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Hi all,
>> 
>> For this reproducer:
>> 
>> import jdk.incubator.vector.ByteVector;
>> import jdk.incubator.vector.VectorSpecies;
>> 
>> public class Test {
>>     static final VectorSpecies<Byte> SPECIES_128 = ByteVector.SPECIES_128;
>>     static byte[] a = new byte[8];
>>     static byte[] b = new byte[8];
>> 
>>     public static void main(String[] args) {
>>         ByteVector av = ByteVector.fromArray(SPECIES_128, a, 0);
>>         av.intoArray(b, 0);
>>         System.out.println("b: " + b[0]);
>>     }
>> }
>> 
>> The following IndexOutOfBoundsException message (length -7) is unreasonable.
>> 
>> Exception in thread "main" java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length -7
>> 
>> It might be better to fix it like this.
>> 
>> Exception in thread "main" java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> That change may cause performance issues. I would recommend leaving as is for now even through the error message is not great. Bounds checking is quite sensitive and WIP. Notice that we also have an option to call `Objects.checkFromIndexSize` which expresses the intent more accurately, but that is currently less optimal (at least it was when i last checked since it is non an intrinsic).

Thanks @PaulSandoz for your review and comments.

Updated:
 - The performance issue has been fixed since there is no more operation for common cases.
 - The readability of OOB exception msg has been improved by following the style of Objects.checkFromIndexSize.
 - Less code generated (several blocks of code were optimized out for the Test::test method below).

import jdk.incubator.vector.ByteVector;
import jdk.incubator.vector.VectorSpecies;

public class Test {
    static final VectorSpecies<Byte> SPECIES_128 = ByteVector.SPECIES_128;
    static byte[] a = new byte[88];
    static byte[] b = new byte[88];

    public static void test() {
        ByteVector av = ByteVector.fromArray(SPECIES_128, a, 0);
        av.intoArray(b, 0);
    }

    public static void main(String[] args) {
        for (int i = 0; i < 100000; i++) {
            test();
        }
        System.out.println("b: " + b[0]);
    }
}

What do you think of it?
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2127

From claes.redestad at oracle.com  Wed Jan 20 11:57:28 2021
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 20 Jan 2021 12:57:28 +0100
Subject: Reduce allocation in sun.net.www.protocol.jar.Handler.parseURL
In-Reply-To: <CA+pBWhv2e5ewfmOTzwvdO0su3oc5rmU_9Q5FaY_A69z9w02cBw@mail.gmail.com>
References: <CA+pBWhv2e5ewfmOTzwvdO0su3oc5rmU_9Q5FaY_A69z9w02cBw@mail.gmail.com>
Message-ID: <a12d1d6f-717f-5d61-a039-68db8d6aa42c@oracle.com>

Hi,

looks reasonable. I'll file an RFE.

- canonize -> canonicalize seem like an appropriate change of terms :-)

- the bangSlash parameter could perhaps be better named from, since 
bangSlash is not a concept known to ParseUtil. Or move the util methods 
to the Handler, since it's the only caller anyway

- calling file.length() twice: maybe let len = file.length() and replace 
len == 0 with from >= len?

Thanks!

/Claes

On 2021-01-20 02:52, Eirik Bj?rsn?s wrote:
> Hello,
>
> sun.net.www.protocol.jar.Handler.parseURL unconditionally calls
> String.substring twice on the spec string, even when
> ParseUtil.canonizeString later determines that no canonization was required.
>
> By letting canonizeString do the substring calls, but only when it
> determines that it is needed, we can remove some unnecessary String and
> byte[] allocations.
>
> Patch:
>
> https://github.com/eirbjo/jdk/commit/87da9032d7fb622f5d466f43faded4de672ebdda
>
> JMH micro:
>
> @Benchmark
> public void initURL(Blackhole blackhole) throws MalformedURLException {
>      blackhole.consume(new URL(new URL("jar:file:/spring-aop.jar!/"),
> "org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.class"));
> }
>
> It shows a performance win for the patch in terms of throughput and bytes /
> operation:
>
> Baseline:
>
> Benchmark                                               Mode  Cnt
>   Score       Error   Units
> ZipBenchmark.initURL                                   thrpt   25
>   1673457.129 ? 22857.945   ops/s
> ZipBenchmark.initURL:?gc.alloc.rate                    thrpt   25
> 1410.227 ?    19.283  MB/sec
> ZipBenchmark.initURL:?gc.alloc.rate.norm               thrpt   25
>   928.080 ?     0.005    B/op
> ZipBenchmark.initURL:?gc.churn.G1_Eden_Space           thrpt   25
> 1412.557 ?    22.575  MB/sec
> ZipBenchmark.initURL:?gc.churn.G1_Eden_Space.norm      thrpt   25
>   929.589 ?     5.756    B/op
> ZipBenchmark.initURL:?gc.churn.G1_Survivor_Space       thrpt   25
>   0.006 ?     0.002  MB/sec
> ZipBenchmark.initURL:?gc.churn.G1_Survivor_Space.norm  thrpt   25
>   0.004 ?     0.001    B/op
> ZipBenchmark.initURL:?gc.count                         thrpt   25
> 1441.000              counts
> ZipBenchmark.initURL:?gc.time                          thrpt   25
>   961.000                  ms
>
> After:
>
> Benchmark                                               Mode  Cnt
>   Score       Error   Units
> ZipBenchmark.initURL                                   thrpt   25
>   1831971.983 ? 35705.091   ops/s
> ZipBenchmark.initURL:?gc.alloc.rate                    thrpt   25
> 1011.389 ?    19.689  MB/sec
> ZipBenchmark.initURL:?gc.alloc.rate.norm               thrpt   25
>   608.061 ?     0.001    B/op
> ZipBenchmark.initURL:?gc.churn.G1_Eden_Space           thrpt   25
> 1011.746 ?    20.583  MB/sec
> ZipBenchmark.initURL:?gc.churn.G1_Eden_Space.norm      thrpt   25
>   608.275 ?     3.609    B/op
> ZipBenchmark.initURL:?gc.churn.G1_Survivor_Space       thrpt   25
>   0.007 ?     0.001  MB/sec
> ZipBenchmark.initURL:?gc.churn.G1_Survivor_Space.norm  thrpt   25
>   0.004 ?     0.001    B/op
> ZipBenchmark.initURL:?gc.count                         thrpt   25
> 1197.000              counts
> ZipBenchmark.initURL:?gc.time                          thrpt   25
>   760.000                  ms
>
> Thanks,
> Eirik.

From Alan.Bateman at oracle.com  Wed Jan 20 12:02:29 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 20 Jan 2021 12:02:29 +0000
Subject: Reduce allocation in sun.net.www.protocol.jar.Handler.parseURL
In-Reply-To: <a12d1d6f-717f-5d61-a039-68db8d6aa42c@oracle.com>
References: <CA+pBWhv2e5ewfmOTzwvdO0su3oc5rmU_9Q5FaY_A69z9w02cBw@mail.gmail.com>
 <a12d1d6f-717f-5d61-a039-68db8d6aa42c@oracle.com>
Message-ID: <afae83ff-b6b2-eae6-2f4f-f9786f9b2a62@oracle.com>

On 20/01/2021 11:57, Claes Redestad wrote:
> Hi,
>
> looks reasonable. I'll file an RFE.
>
> - canonize -> canonicalize seem like an appropriate change of terms :-)
>
> - the bangSlash parameter could perhaps be better named from, since 
> bangSlash is not a concept known to ParseUtil. Or move the util 
> methods to the Handler, since it's the only caller anyway
>
> - calling file.length() twice: maybe let len = file.length() and 
> replace len == 0 with from >= len?

I suspect some refactoring is needed as some of this code in ParseUtil 
is not general purpose and should probably move to the jar URL handler. 
A discussion for net-dev when there is a patch to discuss.

-Alan

From github.com+300291+eirbjo at openjdk.java.net  Wed Jan 20 12:05:00 2021
From: github.com+300291+eirbjo at openjdk.java.net (eirbjo)
Date: Wed, 20 Jan 2021 12:05:00 GMT
Subject: Integrated: 8259867: Move encoding checks into ZipCoder
In-Reply-To: <8tz8k1IbdDwe_z4GM4b5jiwUO6gSplgbisbbmOlQJJY=.e33630d7-338c-4921-bb89-add904e18ad4@github.com>
References: <8tz8k1IbdDwe_z4GM4b5jiwUO6gSplgbisbbmOlQJJY=.e33630d7-338c-4921-bb89-add904e18ad4@github.com>
Message-ID: <koWKQ4Y6eB6GlZ4nSf2ANn3PsqnNietpJex3SxhJRRw=.dc4f30d4-a980-4ee8-9561-a88dd44e2399@github.com>

On Sat, 16 Jan 2021 17:49:38 GMT, eirbjo <github.com+300291+eirbjo at openjdk.org> wrote:

> ZipFile.Source.initCEN verifies that entry names are encoding into bytes valid in the entry's encoding. It does so by calling encoding-specific checking methods, so it also needs to determine which check method to call for each entry.
> 
> By moving the encoding-variant checks into ZipCoder, initCEN can instead simply call ZipCoder.checkEncoding. This makes the code easier to follow and also removes a duplication of flag checking logic found in zipCoderForPos.

This pull request has now been integrated.

Changeset: 05294802
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/05294802
Stats:     58 lines in 2 files changed: 27 ins; 28 del; 3 mod

8259867: Move encoding checks into ZipCoder

Reviewed-by: redestad, lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/2110

From claes.redestad at oracle.com  Wed Jan 20 12:12:01 2021
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 20 Jan 2021 13:12:01 +0100
Subject: Reduce allocation in sun.net.www.protocol.jar.Handler.parseURL
In-Reply-To: <afae83ff-b6b2-eae6-2f4f-f9786f9b2a62@oracle.com>
References: <CA+pBWhv2e5ewfmOTzwvdO0su3oc5rmU_9Q5FaY_A69z9w02cBw@mail.gmail.com>
 <a12d1d6f-717f-5d61-a039-68db8d6aa42c@oracle.com>
 <afae83ff-b6b2-eae6-2f4f-f9786f9b2a62@oracle.com>
Message-ID: <d4685684-a467-e41d-9559-46ddc78b6127@oracle.com>


On 2021-01-20 13:02, Alan Bateman wrote:
> On 20/01/2021 11:57, Claes Redestad wrote:
>> Hi,
>>
>> looks reasonable. I'll file an RFE.
>>
>> - canonize -> canonicalize seem like an appropriate change of terms :-)
>>
>> - the bangSlash parameter could perhaps be better named from, since 
>> bangSlash is not a concept known to ParseUtil. Or move the util 
>> methods to the Handler, since it's the only caller anyway
>>
>> - calling file.length() twice: maybe let len = file.length() and 
>> replace len == 0 with from >= len?
>
> I suspect some refactoring is needed as some of this code in ParseUtil 
> is not general purpose and should probably move to the jar URL 
> handler. A discussion for net-dev when there is a patch to discuss.

Filed https://bugs.openjdk.java.net/browse/JDK-8260043 for this.

(Eirik: once you submit a PR the review should happen automatically on 
the right mailing list.)

/Claes


From jvernee at openjdk.java.net  Wed Jan 20 12:25:47 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 20 Jan 2021 12:25:47 GMT
Subject: RFR: 8259911: byteArrayViewVarHandle should throw
 ArrayIndexOutOfBoundsException
In-Reply-To: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com>
References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com>
Message-ID: <nAQgw4iJ5GmIDDUgxabTfc5KJtXIRuGZgemr4lhFKZs=.a19164d1-efd9-4e13-8743-8b674adc637d@github.com>

On Mon, 18 Jan 2021 12:09:23 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Change `MethodHandles.byteArrayViewVarHandle` to throw `ArrayIndexOutOfBoundsException` rather than the more generic `IndexArrayOutOfBoundsException`. This feels more natural, and reduces the risk for subtle behavioral mismatch when migrating code from arrays/Unsafe to VHs. 
> 
> CSR: [JDK-8259912](https://bugs.openjdk.java.net/browse/JDK-8259912)

Marked as reviewed by jvernee (Committer).

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4374:

> 4372:      * <p>
> 4373:      * Access of bytes at a given index will result in an
> 4374:      * {@code ArrayIndexOutOfBoundsException} if the index is less than {@code 0}

Should the copyright year of this file also be updated?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2124

From redestad at openjdk.java.net  Wed Jan 20 12:28:54 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 20 Jan 2021 12:28:54 GMT
Subject: RFR: 8260010: UTF8ZipCoder not thread-safe since JDK-8243469
Message-ID: <FKSENm_67dbi0lH2yK-FCIuNIZfV6IRqLF3NY9voueI=.c4ccd8bb-417c-4fcc-bc74-80f3800cc8db@github.com>

This patch resolves a thread-safety issue where the singleton UTF8ZipCoder is erroneously using a shared CharsetDecoder when the fast-path fails. It needs to go via JLA.newStringUTF8NoRepl like before JDK-8243469

This should resolve a rare issue when doing a lot of jar scanning in parallel on jar/zip files (with at least some non-ASCII entries), but I've not managed to create a test that reliably reproduce the issue.

-------------

Commit messages:
 - UTF8ZipCoder.normalizedHash not thread-safe

Changes: https://git.openjdk.java.net/jdk/pull/2163/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2163&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260010
  Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2163.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2163/head:pull/2163

PR: https://git.openjdk.java.net/jdk/pull/2163

From github.com+300291+eirbjo at openjdk.java.net  Wed Jan 20 12:55:58 2021
From: github.com+300291+eirbjo at openjdk.java.net (eirbjo)
Date: Wed, 20 Jan 2021 12:55:58 GMT
Subject: RFR: 8260010: UTF8ZipCoder not thread-safe since JDK-8243469
In-Reply-To: <FKSENm_67dbi0lH2yK-FCIuNIZfV6IRqLF3NY9voueI=.c4ccd8bb-417c-4fcc-bc74-80f3800cc8db@github.com>
References: <FKSENm_67dbi0lH2yK-FCIuNIZfV6IRqLF3NY9voueI=.c4ccd8bb-417c-4fcc-bc74-80f3800cc8db@github.com>
Message-ID: <e0J7rn4nA8eQmWP7KSfjnHhqhlAyAfNFdBbKkI9Ji9k=.32d0e524-afb2-474c-bb0c-47b5aaa18b8e@github.com>

On Wed, 20 Jan 2021 12:21:21 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch resolves a thread-safety issue where the singleton UTF8ZipCoder is erroneously using a shared CharsetDecoder when the fast-path fails. It needs to go via JLA.newStringUTF8NoRepl like before JDK-8243469
> 
> This should resolve a rare issue when doing a lot of jar scanning in parallel on jar/zip files (with at least some non-ASCII entries), but I've not managed to create a test that reliably reproduce the issue.

src/java.base/share/classes/java/util/zip/ZipCoder.java line 229:

> 227:                     // Non-ASCII, fall back to decoding a String
> 228:                     String s = JLA.newStringUTF8NoRepl(a, end - len, end);
> 229:                     h = s.hashCode();

Would it be possible to call normalizedHash(String name) here?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2163

From redestad at openjdk.java.net  Wed Jan 20 13:03:04 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 20 Jan 2021 13:03:04 GMT
Subject: RFR: 8260010: UTF8ZipCoder not thread-safe since JDK-8243469 [v2]
In-Reply-To: <FKSENm_67dbi0lH2yK-FCIuNIZfV6IRqLF3NY9voueI=.c4ccd8bb-417c-4fcc-bc74-80f3800cc8db@github.com>
References: <FKSENm_67dbi0lH2yK-FCIuNIZfV6IRqLF3NY9voueI=.c4ccd8bb-417c-4fcc-bc74-80f3800cc8db@github.com>
Message-ID: <EbxMC08ZpJA25vRnl4-NW17RhDeE7LCJqdsEH1IYTHs=.267953ef-4cc7-4407-9e97-22450b65e57f@github.com>

> This patch resolves a thread-safety issue where the singleton UTF8ZipCoder is erroneously using a shared CharsetDecoder when the fast-path fails. It needs to go via JLA.newStringUTF8NoRepl like before JDK-8243469
> 
> This should resolve a rare issue when doing a lot of jar scanning in parallel on jar/zip files (with at least some non-ASCII entries), but I've not managed to create a test that reliably reproduce the issue.

Claes Redestad has updated the pull request incrementally with three additional commits since the last revision:

 - Reuse normalizedHash(String)
 - copyright
 - Don't use No Replace variant to calculate hash, more fixes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2163/files
  - new: https://git.openjdk.java.net/jdk/pull/2163/files/4eeb06ea..dd7ef567

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2163&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2163&range=00-01

  Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2163.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2163/head:pull/2163

PR: https://git.openjdk.java.net/jdk/pull/2163

From redestad at openjdk.java.net  Wed Jan 20 13:03:05 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 20 Jan 2021 13:03:05 GMT
Subject: RFR: 8260010: UTF8ZipCoder not thread-safe since JDK-8243469 [v2]
In-Reply-To: <e0J7rn4nA8eQmWP7KSfjnHhqhlAyAfNFdBbKkI9Ji9k=.32d0e524-afb2-474c-bb0c-47b5aaa18b8e@github.com>
References: <FKSENm_67dbi0lH2yK-FCIuNIZfV6IRqLF3NY9voueI=.c4ccd8bb-417c-4fcc-bc74-80f3800cc8db@github.com>
 <e0J7rn4nA8eQmWP7KSfjnHhqhlAyAfNFdBbKkI9Ji9k=.32d0e524-afb2-474c-bb0c-47b5aaa18b8e@github.com>
Message-ID: <TY5dgQWKkMp27oekOE19FAHk67r2hDCVoi58PB7fQx0=.0431775d-afbb-46de-b53e-792425aa045b@github.com>

On Wed, 20 Jan 2021 12:52:30 GMT, eirbjo <github.com+300291+eirbjo at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Reuse normalizedHash(String)
>>  - copyright
>>  - Don't use No Replace variant to calculate hash, more fixes
>
> src/java.base/share/classes/java/util/zip/ZipCoder.java line 229:
> 
>> 227:                     // Non-ASCII, fall back to decoding a String
>> 228:                     String s = JLA.newStringUTF8NoRepl(a, end - len, end);
>> 229:                     h = s.hashCode();
> 
> Would it be possible to call normalizedHash(String name) here?

Yes, updated. (The PR was supposed to be a draft until now since I was fixing up some testing issues with my first stab at this.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/2163

From redestad at openjdk.java.net  Wed Jan 20 13:31:58 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 20 Jan 2021 13:31:58 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v3]
In-Reply-To: <RyEqdGAvWz7AUu97qVlZ0PCHtW_r4bWEJxZlprVoW2k=.625a8a67-cf9c-4a80-9684-2d6b574d9db1@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
 <RyEqdGAvWz7AUu97qVlZ0PCHtW_r4bWEJxZlprVoW2k=.625a8a67-cf9c-4a80-9684-2d6b574d9db1@github.com>
Message-ID: <T4msQBKUKtwBZl7IsHKlMJuatDWbQeGR4fTBAHDjSyM=.6073e41f-6fbb-4683-8eba-e83a0af8cbde@github.com>

On Tue, 19 Jan 2021 10:46:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move JLA to top, add imports
>
> test/micro/org/openjdk/bench/java/io/FileToPath.java line 46:
> 
>> 44:     public String root = "/";
>> 45:     public String trailingSlash = "/test/dir/file/name.txt/";
>> 46:     public String notNormalizedFile = "/test/dir/file//name.txt";
> 
> Can be `private`, I think. As long as those are not `static final`...

@shipilev - are you OK with the updated micro?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2135

From ljiang at openjdk.java.net  Wed Jan 20 14:01:48 2021
From: ljiang at openjdk.java.net (Leo Jiang)
Date: Wed, 20 Jan 2021 14:01:48 GMT
Subject: [jdk16] Integrated: JDK-8259732: JDK 16 L10n resource file update -
 msg drop 10
In-Reply-To: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
References: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
Message-ID: <PsjsxJ4kew4pjTts5SUpHNnJecCD6WeOjLF2KThGY6w=.e649b3eb-5863-4b6f-b557-5b7f1ae2471a@github.com>

On Thu, 14 Jan 2021 14:00:00 GMT, Leo Jiang <ljiang at openjdk.org> wrote:

> This is the changes for JDK 16 msg drop 10.

This pull request has now been integrated.

Changeset: 01205109
Author:    Leo Jiang <ljiang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/01205109
Stats:     215 lines in 30 files changed: 118 ins; 16 del; 81 mod

8259732: JDK 16 L10n resource file update - msg drop 10

Reviewed-by: naoto

-------------

PR: https://git.openjdk.java.net/jdk16/pull/123

From mullan at openjdk.java.net  Wed Jan 20 14:03:50 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 20 Jan 2021 14:03:50 GMT
Subject: RFR: 8259707: LDAP channel binding does not work with StartTLS
 extension
In-Reply-To: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
References: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
Message-ID: <Ftr0mjO4_Vh2beMZeCBxQbZKrqT80ykIUho74XKlLNs=.59a754a8-e0c2-49a1-a2d7-b56288bac4fe@github.com>

On Thu, 14 Jan 2021 19:28:27 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS Extension.
> Test from the bug report and jtreg javax/naming tests are passed.

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2085

From mullan at openjdk.java.net  Wed Jan 20 14:03:50 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 20 Jan 2021 14:03:50 GMT
Subject: RFR: 8259707: LDAP channel binding does not work with StartTLS
 extension
In-Reply-To: <jpZtdTb4qq99DE1xTKaNoLhPknv60_3qKMmT2VBIsIA=.c0983ef5-2188-429a-9a8d-d7f20a99b029@github.com>
References: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
 <ufGH_BKloK8RlVDYOchBYFMHGLdVLIHcSmvGnNp8U5w=.9a2f9de0-a2c5-4031-be42-7daa9145258b@github.com>
 <jpZtdTb4qq99DE1xTKaNoLhPknv60_3qKMmT2VBIsIA=.c0983ef5-2188-429a-9a8d-d7f20a99b029@github.com>
Message-ID: <h3U0-5fuuri5VMrRGwfkb3gFBzQzmYfRWneQo4dWI_8=.2846221f-b081-47da-9efc-2db833135b35@github.com>

On Wed, 20 Jan 2021 07:21:22 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Unfortunately, I can not find any LDAP StartTLS Extended Operation regression tests. security/infra area contains RevocationChecker tests. They can not be used for this scenario.

Ok, please add a noreg-hard label to the bug.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2085

From shade at openjdk.java.net  Wed Jan 20 14:08:57 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 20 Jan 2021 14:08:57 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v3]
In-Reply-To: <1s1c4bBy5zRlzjUrdJ3Bbly4nb3Q3EpbWJ6ruZenqcY=.3642563d-f891-4f65-8193-8e8b2190a151@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
 <1s1c4bBy5zRlzjUrdJ3Bbly4nb3Q3EpbWJ6ruZenqcY=.3642563d-f891-4f65-8193-8e8b2190a151@github.com>
Message-ID: <eJ2clS1kO43xmTzOx6FzfHixIRAh3Z8pwmMQtrQSHMg=.e0cc2751-fec7-444e-ac94-630e096bb7a4@github.com>

On Tue, 19 Jan 2021 12:26:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
>> 
>> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move JLA to top, add imports

test/micro/org/openjdk/bench/java/io/FileOpen.java line 103:

> 101:     @Warmup(time=2, iterations=5)
> 102:     @Measurement(time=3, iterations=5)
> 103:     @Fork(value=2, jvmArgs="-Xmx1g")

I thought this can be inherited from the enclosing benchmark.

test/micro/org/openjdk/bench/java/io/FileOpen.java line 104:

> 102:     @Measurement(time=3, iterations=5)
> 103:     @Fork(value=2, jvmArgs="-Xmx1g")
> 104:     public static class ToPath {

Do we really have to nest this test? It seems to gain nothing per se: the annotations and fields are still pretty much duplicated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2135

From abakhtin at openjdk.java.net  Wed Jan 20 14:22:39 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Wed, 20 Jan 2021 14:22:39 GMT
Subject: RFR: 8259707: LDAP channel binding does not work with StartTLS
 extension
In-Reply-To: <Ftr0mjO4_Vh2beMZeCBxQbZKrqT80ykIUho74XKlLNs=.59a754a8-e0c2-49a1-a2d7-b56288bac4fe@github.com>
References: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
 <Ftr0mjO4_Vh2beMZeCBxQbZKrqT80ykIUho74XKlLNs=.59a754a8-e0c2-49a1-a2d7-b56288bac4fe@github.com>
Message-ID: <piPe7ITFgENhF_pkvmLnbnT9av-TZOkRp0gjzBR6PoI=.c3f38f5a-7d3d-48bd-aaad-19c8140eafca@github.com>

On Wed, 20 Jan 2021 14:01:45 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS Extension.
>> Test from the bug report and jtreg javax/naming tests are passed.
>
> Marked as reviewed by mullan (Reviewer).

Sean, Thank you for review

-------------

PR: https://git.openjdk.java.net/jdk/pull/2085

From dfuchs at openjdk.java.net  Wed Jan 20 14:44:50 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 20 Jan 2021 14:44:50 GMT
Subject: RFR: 8259707: LDAP channel binding does not work with StartTLS
 extension
In-Reply-To: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
References: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
Message-ID: <v55huk47FW0WqOBmncu96V-SNJb2pn7TBBCKGJrnHZE=.2b66413d-b432-4a54-9948-3116d46a9438@github.com>

On Thu, 14 Jan 2021 19:28:27 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS Extension.
> Test from the bug report and jtreg javax/naming tests are passed.

That look reasonable to me. But what would happen if at some point after performing some LDAP operations, you called StartTLSResponse::close and then after some more time you tried to again create a StartTLSRequest on the same context? Would that work - or would you be using a possibly obsolete channel binding obtained from the first upgrade?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2085

From redestad at openjdk.java.net  Wed Jan 20 15:11:16 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 20 Jan 2021 15:11:16 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v4]
In-Reply-To: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
Message-ID: <R6INRC1aTHZPpVvEzPkCwCM6myPkNlBn4S0aO9aAZEw=.8de2a474-78d2-44cc-871b-2f51854e7b46@github.com>

> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
> 
> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.

Claes Redestad 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 unix_encode
 - Move FileOpen.ToPath micros into top class
 - Move JLA to top, add imports
 - Fold ToPath into FileOpen, add root benchmarks to keep mix comparable
 - Add micro. To properly examine cost of toPath() needs a new File due caching - use FileOpen as a baseline
 - Optimize UnixPath.encode

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2135/files
  - new: https://git.openjdk.java.net/jdk/pull/2135/files/b023c0a5..98c76192

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2135&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2135&range=02-03

  Stats: 3891 lines in 128 files changed: 671 ins; 2864 del; 356 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2135/head:pull/2135

PR: https://git.openjdk.java.net/jdk/pull/2135

From shade at openjdk.java.net  Wed Jan 20 15:11:20 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 20 Jan 2021 15:11:20 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v4]
In-Reply-To: <R6INRC1aTHZPpVvEzPkCwCM6myPkNlBn4S0aO9aAZEw=.8de2a474-78d2-44cc-871b-2f51854e7b46@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
 <R6INRC1aTHZPpVvEzPkCwCM6myPkNlBn4S0aO9aAZEw=.8de2a474-78d2-44cc-871b-2f51854e7b46@github.com>
Message-ID: <7w5Qzm2c0-0Xfh_CXDqTw68oMgJ9fbiwNs9DuPRTQD4=.3b77841e-e04a-4612-845b-7600a42d83f0@github.com>

On Wed, 20 Jan 2021 15:08:22 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
>> 
>> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.
>
> Claes Redestad 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 unix_encode
>  - Move FileOpen.ToPath micros into top class
>  - Move JLA to top, add imports
>  - Fold ToPath into FileOpen, add root benchmarks to keep mix comparable
>  - Add micro. To properly examine cost of toPath() needs a new File due caching - use FileOpen as a baseline
>  - Optimize UnixPath.encode

Marked as reviewed by shade (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2135

From aefimov at openjdk.java.net  Wed Jan 20 15:11:51 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 20 Jan 2021 15:11:51 GMT
Subject: RFR: 8259707: LDAP channel binding does not work with StartTLS
 extension
In-Reply-To: <v55huk47FW0WqOBmncu96V-SNJb2pn7TBBCKGJrnHZE=.2b66413d-b432-4a54-9948-3116d46a9438@github.com>
References: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
 <v55huk47FW0WqOBmncu96V-SNJb2pn7TBBCKGJrnHZE=.2b66413d-b432-4a54-9948-3116d46a9438@github.com>
Message-ID: <frtTVdnU2xxVW4Y_v1sAMWS4c65OTDj13E5bOqjOhrw=.30cd7f30-3ab9-4ecd-b333-86392e4e700c@github.com>

On Wed, 20 Jan 2021 14:41:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS Extension.
>> Test from the bug report and jtreg javax/naming tests are passed.
>
> That look reasonable to me. But what would happen if at some point after performing some LDAP operations, you called StartTLSResponse::close and then after some more time you tried to again create a StartTLSRequest on the same context? Would that work - or would you be using a possibly obsolete channel binding obtained from the first upgrade?

The change looks valid to me too.
I believe Daniel question could be illustrated with the following change to `CBwithTLS` reproducer attached to the bug report:
--- CBwithTLS_Original.java	2021-01-20 14:56:09.620844903 +0000
+++ CBwithTLS.java	2021-01-20 15:01:47.253982227 +0000
@@ -45,7 +45,7 @@
         System.out.println(ctxt.getAttributes("", new String[]{"defaultNamingContext"}).get("defaultNamingContext").get());
 
         // Switch to TLS
-
+        for (int i=0; i<2; i++) {
         StartTlsResponse tls = (StartTlsResponse) ctxt.extendedOperation(new StartTlsRequest());
         tls.negotiate();
 
@@ -64,6 +64,9 @@
         lc.login();
 
         Subject.doAs(lc.getSubject(), (PrivilegedAction<Void>) CBwithTLS::run);
+            lc.logout();
+            tls.close();
+        }
     }
 
     private static Void run() {

-------------

PR: https://git.openjdk.java.net/jdk/pull/2085

From redestad at openjdk.java.net  Wed Jan 20 15:17:55 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 20 Jan 2021 15:17:55 GMT
Subject: Integrated: 8259947: (fs) Optimize UnixPath.encode implementation
In-Reply-To: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
Message-ID: <ISRsFJtKLYH-AeLWLMReHwX2ZPzQXFk8TXO3X2B10BU=.6f6d1d16-f81f-4774-8db6-d13b3a027226@github.com>

On Tue, 19 Jan 2021 00:35:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
> 
> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.

This pull request has now been integrated.

Changeset: 5891509d
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5891509d
Stats:     107 lines in 6 files changed: 40 ins; 43 del; 24 mod

8259947: (fs) Optimize UnixPath.encode implementation

Reviewed-by: chegar, shade, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/2135

From redestad at openjdk.java.net  Wed Jan 20 15:17:54 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 20 Jan 2021 15:17:54 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v3]
In-Reply-To: <eJ2clS1kO43xmTzOx6FzfHixIRAh3Z8pwmMQtrQSHMg=.e0cc2751-fec7-444e-ac94-630e096bb7a4@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
 <1s1c4bBy5zRlzjUrdJ3Bbly4nb3Q3EpbWJ6ruZenqcY=.3642563d-f891-4f65-8193-8e8b2190a151@github.com>
 <eJ2clS1kO43xmTzOx6FzfHixIRAh3Z8pwmMQtrQSHMg=.e0cc2751-fec7-444e-ac94-630e096bb7a4@github.com>
Message-ID: <KaojPYXcXRZlWfrnhvEVxS7rh64o2sDG5vh60l4oY6s=.623e6598-b186-47be-b75b-d26a5d4ac614@github.com>

On Wed, 20 Jan 2021 13:33:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move JLA to top, add imports
>
> test/micro/org/openjdk/bench/java/io/FileOpen.java line 103:
> 
>> 101:     @Warmup(time=2, iterations=5)
>> 102:     @Measurement(time=3, iterations=5)
>> 103:     @Fork(value=2, jvmArgs="-Xmx1g")
> 
> I thought this can be inherited from the enclosing benchmark.

Maybe it's only @State that doesn't inherit.

> test/micro/org/openjdk/bench/java/io/FileOpen.java line 104:
> 
>> 102:     @Measurement(time=3, iterations=5)
>> 103:     @Fork(value=2, jvmArgs="-Xmx1g")
>> 104:     public static class ToPath {
> 
> Do we really have to nest this test? It seems to gain nothing per se: the annotations and fields are still pretty much duplicated.

Yeah, no. Nesting was to pre-emptively decouple the micros, but it makes sense to squash them into one for now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2135

From eirbjo at gmail.com  Wed Jan 20 15:30:20 2021
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Wed, 20 Jan 2021 16:30:20 +0100
Subject: Reduce allocation in sun.net.www.protocol.jar.Handler.parseURL
In-Reply-To: <afae83ff-b6b2-eae6-2f4f-f9786f9b2a62@oracle.com>
References: <CA+pBWhv2e5ewfmOTzwvdO0su3oc5rmU_9Q5FaY_A69z9w02cBw@mail.gmail.com>
 <a12d1d6f-717f-5d61-a039-68db8d6aa42c@oracle.com>
 <afae83ff-b6b2-eae6-2f4f-f9786f9b2a62@oracle.com>
Message-ID: <CA+pBWhsg4MWMyDXjcwsq20e4m-=tgEUSC4qmzsU=DLXMRg-mAQ@mail.gmail.com>

>
> I suspect some refactoring is needed as some of this code in ParseUtil
> is not general purpose and should probably move to the jar URL handler.
> A discussion for net-dev when there is a patch to discuss.
>

https://github.com/openjdk/jdk/pull/2167

This moves the utility methods into Handler (does that cover "some
refactoring is needed", Alan?) and also includes cleanups suggested by
Claes.

Eirik.

From abakhtin at openjdk.java.net  Wed Jan 20 15:37:51 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Wed, 20 Jan 2021 15:37:51 GMT
Subject: RFR: 8259707: LDAP channel binding does not work with StartTLS
 extension
In-Reply-To: <frtTVdnU2xxVW4Y_v1sAMWS4c65OTDj13E5bOqjOhrw=.30cd7f30-3ab9-4ecd-b333-86392e4e700c@github.com>
References: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
 <v55huk47FW0WqOBmncu96V-SNJb2pn7TBBCKGJrnHZE=.2b66413d-b432-4a54-9948-3116d46a9438@github.com>
 <frtTVdnU2xxVW4Y_v1sAMWS4c65OTDj13E5bOqjOhrw=.30cd7f30-3ab9-4ecd-b333-86392e4e700c@github.com>
Message-ID: <DxSCzjhMQ4czi5yIpVGo-vs3dQnFcq_8-WqdC60VMsY=.1dc15b37-cdaf-49c5-b6f1-d26bba81c6bf@github.com>

On Wed, 20 Jan 2021 15:08:56 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> That look reasonable to me. But what would happen if at some point after performing some LDAP operations, you called StartTLSResponse::close and then after some more time you tried to again create a StartTLSRequest on the same context? Would that work - or would you be using a possibly obsolete channel binding obtained from the first upgrade?
>
> The change looks valid to me too.
> I believe Daniel question could be illustrated with the following change to `CBwithTLS` reproducer attached to the bug report:
> --- CBwithTLS_Original.java	2021-01-20 14:56:09.620844903 +0000
> +++ CBwithTLS.java	2021-01-20 15:01:47.253982227 +0000
> @@ -45,7 +45,7 @@
>          System.out.println(ctxt.getAttributes("", new String[]{"defaultNamingContext"}).get("defaultNamingContext").get());
>  
>          // Switch to TLS
> -
> +        for (int i=0; i<2; i++) {
>          StartTlsResponse tls = (StartTlsResponse) ctxt.extendedOperation(new StartTlsRequest());
>          tls.negotiate();
>  
> @@ -64,6 +64,9 @@
>          lc.login();
>  
>          Subject.doAs(lc.getSubject(), (PrivilegedAction<Void>) CBwithTLS::run);
> +            lc.logout();
> +            tls.close();
> +        }
>      }
>  
>      private static Void run() {

New ChannelBinding Data will be recreated for every TLS connection and provided to SASL Client in the new environment properties set (cloned from the original). 
LdapSasl.java lines 133 - 136:
                        TlsChannelBinding tlsCB =
                                TlsChannelBinding.create(cert);
                        envProps = (Hashtable<String, Object>) env.clone();
                        envProps.put(TlsChannelBinding.CHANNEL_BINDING, tlsCB.getData());

-------------

PR: https://git.openjdk.java.net/jdk/pull/2085

From dfuchs at openjdk.java.net  Wed Jan 20 16:01:00 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 20 Jan 2021 16:01:00 GMT
Subject: RFR: 8259707: LDAP channel binding does not work with StartTLS
 extension
In-Reply-To: <DxSCzjhMQ4czi5yIpVGo-vs3dQnFcq_8-WqdC60VMsY=.1dc15b37-cdaf-49c5-b6f1-d26bba81c6bf@github.com>
References: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
 <v55huk47FW0WqOBmncu96V-SNJb2pn7TBBCKGJrnHZE=.2b66413d-b432-4a54-9948-3116d46a9438@github.com>
 <frtTVdnU2xxVW4Y_v1sAMWS4c65OTDj13E5bOqjOhrw=.30cd7f30-3ab9-4ecd-b333-86392e4e700c@github.com>
 <DxSCzjhMQ4czi5yIpVGo-vs3dQnFcq_8-WqdC60VMsY=.1dc15b37-cdaf-49c5-b6f1-d26bba81c6bf@github.com>
Message-ID: <tOqkvV4MYs8baP-TmZWwiTQK8hk60qYOtzeEjYR6mLc=.f2e4d6e2-edf4-40cb-a790-da7a02781d56@github.com>

On Wed, 20 Jan 2021 15:34:24 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> New ChannelBinding Data will be recreated for every TLS connection and provided to SASL Client in the new environment properties set (cloned from the original).
> LdapSasl.java lines 133 - 136:
> 
> ```
>                         TlsChannelBinding tlsCB =
>                                 TlsChannelBinding.create(cert);
>                         envProps = (Hashtable<String, Object>) env.clone();

Hi Alexey, 

Aleksei and I have concern because this code uses a `cert` that is obtained from a CompletableFuture, and the completable future  can be completed only once. The second time around - you will therefore find the same `cert` that was set when the first StartTLSResponse was negotiated. This may - or may not matter - depending on whether the `cert` certificate returned by the server the second time around should be the same - or not.
Could you test this scenario?
It may be that it's a niche scenario that makes no sense or that we don't want to support - I'm not sure how STARTTLS is used in the wild. Do you have any insights on this?

best regards,

-- daniel

-------------

PR: https://git.openjdk.java.net/jdk/pull/2085

From github.com+34924738+mahendrachhipa at openjdk.java.net  Wed Jan 20 17:33:16 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Wed, 20 Jan 2021 17:33:16 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
Message-ID: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>

https://bugs.openjdk.java.net/browse/JDK-8183372

-------------

Commit messages:
 - JDK-8183372 : Refactor java/lang/Class shell tests to java

Changes: https://git.openjdk.java.net/jdk/pull/2170/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8183372
  Stats: 296 lines in 4 files changed: 137 ins; 115 del; 44 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2170.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2170/head:pull/2170

PR: https://git.openjdk.java.net/jdk/pull/2170

From github.com+652983+dasbrain at openjdk.java.net  Wed Jan 20 18:35:10 2021
From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn)
Date: Wed, 20 Jan 2021 18:35:10 GMT
Subject: RFR: 8259922 MethodHandles.collectArguments does not follow its
 documentation
Message-ID: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com>

Add explicit range check to `MethodHandles.collectArgumentsCheck`.  
Added test case that exercises all cases.

This is a behavioral change, from throwing an unspecified exception to throwing an IllegalArgumentException, as specified.  
No spec change needed, as the IllegalArgumentException is already specified to be thrown in those cases.

Feel free to suggest a better place for the tests.

-------------

Commit messages:
 - Fix tailing whitespace in in MethodHandles.java
 - Fix copyright yeahr in MethodHandles.java
 - Fix JDK-8259922
 - Fix JDK-8259922.

Changes: https://git.openjdk.java.net/jdk/pull/2171/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2171&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259922
  Stats: 100 lines in 2 files changed: 99 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2171.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2171/head:pull/2171

PR: https://git.openjdk.java.net/jdk/pull/2171

From redestad at openjdk.java.net  Wed Jan 20 18:47:18 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 20 Jan 2021 18:47:18 GMT
Subject: RFR: 8259911: byteArrayViewVarHandle should throw
 ArrayIndexOutOfBoundsException [v2]
In-Reply-To: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com>
References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com>
Message-ID: <PK6TM40-JKVYxxGeKJtkALtUANLcu1OKnlP14HERkkM=.51316541-6f99-4453-bdf3-1e1251176c89@github.com>

> Change `MethodHandles.byteArrayViewVarHandle` to throw `ArrayIndexOutOfBoundsException` rather than the more generic `IndexArrayOutOfBoundsException`. This feels more natural, and reduces the risk for subtle behavioral mismatch when migrating code from arrays/Unsafe to VHs. 
> 
> CSR: [JDK-8259912](https://bugs.openjdk.java.net/browse/JDK-8259912)

Claes Redestad 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:

 - Update VarHandles tests to check for AIOOBE specifically when appropriate
 - Copyrights
 - Merge branch 'master' into vh_aioobe
 - byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2124/files
  - new: https://git.openjdk.java.net/jdk/pull/2124/files/42c9460c..9259ee3a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2124&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2124&range=00-01

  Stats: 4494 lines in 166 files changed: 725 ins; 2890 del; 879 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2124.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2124/head:pull/2124

PR: https://git.openjdk.java.net/jdk/pull/2124

From mchung at openjdk.java.net  Wed Jan 20 18:52:00 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 20 Jan 2021 18:52:00 GMT
Subject: RFR: 8259911: byteArrayViewVarHandle should throw
 ArrayIndexOutOfBoundsException [v2]
In-Reply-To: <PK6TM40-JKVYxxGeKJtkALtUANLcu1OKnlP14HERkkM=.51316541-6f99-4453-bdf3-1e1251176c89@github.com>
References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com>
 <PK6TM40-JKVYxxGeKJtkALtUANLcu1OKnlP14HERkkM=.51316541-6f99-4453-bdf3-1e1251176c89@github.com>
Message-ID: <dBJR7SMKNOaRnJTIDBUouXm2DUfrf_UB0pa10x1tIyo=.3f305e0b-6f7a-4301-b362-61b43c719ab6@github.com>

On Wed, 20 Jan 2021 18:47:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Change `MethodHandles.byteArrayViewVarHandle` to throw `ArrayIndexOutOfBoundsException` rather than the more generic `IndexArrayOutOfBoundsException`. This feels more natural, and reduces the risk for subtle behavioral mismatch when migrating code from arrays/Unsafe to VHs. 
>> 
>> CSR: [JDK-8259912](https://bugs.openjdk.java.net/browse/JDK-8259912)
>
> Claes Redestad 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:
> 
>  - Update VarHandles tests to check for AIOOBE specifically when appropriate
>  - Copyrights
>  - Merge branch 'master' into vh_aioobe
>  - byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException

Looks good.  Thanks for updating the test.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2124

From psandoz at openjdk.java.net  Wed Jan 20 19:33:50 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 20 Jan 2021 19:33:50 GMT
Subject: RFR: 8259925: [Vector API] Unreasonable IndexOutOfBoundsException
 message when length < vlen
In-Reply-To: <ZAH7vzOKC5VPi7V6ElL55VxQsgA4AAuVUOH4v8u4QfY=.4cb1b26e-6c19-4083-8495-2d046efa3ddd@github.com>
References: <IXlGGauVhUjxPJXm8CjZ0Eo4-ySUttJ_EqYpxiW7p8E=.32dc9082-78ad-4407-a6a2-3652dfef8a4c@github.com>
 <LzL6761_WZOicSWpwUGbYjnnWKlqQPSLtMqLKp5Q_ls=.343834be-ef22-4bc1-91c5-c8388627f6f5@github.com>
 <ZAH7vzOKC5VPi7V6ElL55VxQsgA4AAuVUOH4v8u4QfY=.4cb1b26e-6c19-4083-8495-2d046efa3ddd@github.com>
Message-ID: <wc6FWksUAR7mY0S_XQox0UgcR9DwpOswrqNRpAZrnDI=.e7327508-a423-4c35-854e-02a55c0aa971@github.com>

On Wed, 20 Jan 2021 09:33:43 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> That change may cause performance issues. I would recommend leaving as is for now even through the error message is not great. Bounds checking is quite sensitive and WIP. Notice that we also have an option to call `Objects.checkFromIndexSize` which expresses the intent more accurately, but that is currently less optimal (at least it was when i last checked since it is non an intrinsic).
>
> Thanks @PaulSandoz for your review and comments.
> 
> Updated:
>  - The performance issue has been fixed since there is no more operation for common cases.
>  - The readability of OOB exception msg has been improved by following the style of Objects.checkFromIndexSize.
>  - Less code generated (several blocks of code were optimized out for the Test::test method below).
> 
> import jdk.incubator.vector.ByteVector;
> import jdk.incubator.vector.VectorSpecies;
> 
> public class Test {
>     static final VectorSpecies<Byte> SPECIES_128 = ByteVector.SPECIES_128;
>     static byte[] a = new byte[88];
>     static byte[] b = new byte[88];
> 
>     public static void test() {
>         ByteVector av = ByteVector.fromArray(SPECIES_128, a, 0);
>         av.intoArray(b, 0);
>     }
> 
>     public static void main(String[] args) {
>         for (int i = 0; i < 100000; i++) {
>             test();
>         }
>         System.out.println("b: " + b[0]);
>     }
> }
> 
> What do you think of it?
> Thanks.

Unfortunately it is still problematic because you have replaced the intrinsic check (that performed by `Object.checksIndex`, or more specifically [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/util/Preconditions.java#L261)).

Further, you have replaced the bounds check options, in place for experimentation. We are not ready yet to collapse our options, further analysis is required as bounds checks can be very sensitive in C2.

I would be open to you adding a third case, so that you can analyze the performance without perturbing the default behavior. I suspect the correct fix is to make intrinsic `Objects.checkFromIndexSize` in a similar manner to `Object.checksIndex`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2127

From lancea at openjdk.java.net  Wed Jan 20 19:51:55 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 20 Jan 2021 19:51:55 GMT
Subject: RFR: 8260010: UTF8ZipCoder not thread-safe since JDK-8243469 [v2]
In-Reply-To: <EbxMC08ZpJA25vRnl4-NW17RhDeE7LCJqdsEH1IYTHs=.267953ef-4cc7-4407-9e97-22450b65e57f@github.com>
References: <FKSENm_67dbi0lH2yK-FCIuNIZfV6IRqLF3NY9voueI=.c4ccd8bb-417c-4fcc-bc74-80f3800cc8db@github.com>
 <EbxMC08ZpJA25vRnl4-NW17RhDeE7LCJqdsEH1IYTHs=.267953ef-4cc7-4407-9e97-22450b65e57f@github.com>
Message-ID: <q95iqbBw5PvJrt0FKLWQL_FvuZOQtGYTryUVZPHPViE=.d2640cd9-da1a-4a53-9be9-3a8d088c95f4@github.com>

On Wed, 20 Jan 2021 13:03:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch resolves a thread-safety issue where the singleton UTF8ZipCoder is erroneously using a shared CharsetDecoder when the fast-path fails. It needs to go via JLA.newStringUTF8NoRepl like before JDK-8243469
>> 
>> This should resolve a rare issue when doing a lot of jar scanning in parallel on jar/zip files (with at least some non-ASCII entries), but I've not managed to create a test that reliably reproduce the issue.
>
> Claes Redestad has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Reuse normalizedHash(String)
>  - copyright
>  - Don't use No Replace variant to calculate hash, more fixes

I think the changes look OK.

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2163

From bpb at openjdk.java.net  Wed Jan 20 23:07:02 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 20 Jan 2021 23:07:02 GMT
Subject: RFR: 8259943: FileDescriptor.close0 does not handle EINTR
Message-ID: <8Svc34lGaB1DE4J_4yHgouxc6pnd4sSaHa3lzfRVy4s=.37995476-c5a3-476c-9a0b-2c98af07e47f@github.com>

Please review this small change to handle `EINTR` from `close()` in `fileDescriptorClose()`. The function `handleGetLength()` is also changed to handle `EINTR` from `fstat64()` to match other uses of `fstat64()` in the file.

-------------

Commit messages:
 - 8259943: FileDescriptor.close0 does not handle EINTR

Changes: https://git.openjdk.java.net/jdk/pull/2173/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2173&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259943
  Stats: 10 lines in 1 file changed: 6 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2173.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2173/head:pull/2173

PR: https://git.openjdk.java.net/jdk/pull/2173

From redestad at openjdk.java.net  Wed Jan 20 23:22:54 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 20 Jan 2021 23:22:54 GMT
Subject: RFR: 8255531: MethodHandles::permuteArguments throws NPE when
 duplicating dropped arguments
In-Reply-To: <jjesjsHhraVtdE1gJGmOtJmO0Q-ICo5NhoLSWVA4RHg=.4d60e3b6-7d23-4a1b-8f34-b3fdb2329617@github.com>
References: <jjesjsHhraVtdE1gJGmOtJmO0Q-ICo5NhoLSWVA4RHg=.4d60e3b6-7d23-4a1b-8f34-b3fdb2329617@github.com>
Message-ID: <gA04yS-EdU3HhRK6RsvMxaaOyci-Wfurr3U1XhWY3wQ=.5459a261-1c71-4695-92f6-05f679c733cb@github.com>

On Tue, 12 Jan 2021 16:58:45 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi,
> 
> This small patch fixes the NPE in the following case:
> 
>     MethodHandle mh = MethodHandles.empty(MethodType.methodType(void.class, int.class, int.class));
>     MethodHandles.permuteArguments(mh, MethodType.methodType(void.class, int.class), 0, 0);
>     
> If a parameter name was changed by a lambda form edit, `LambdaForm::endEdit` will try to sort the names that fall into the old range of parameter names (starting from `firstChanged` and up to `arity` in the code) to make sure that non-parameter names (`exprs`) properly appear after parameter names. But, if a parameter was dropped, and there are no non-paramter names, a `null` will fall into the range that is being sorted, and the call to `name.isParam()` in the sorting algorithm will result in an NPE.
> 
> We can just add a `name != null` check there, since `null` is definitely not a parameter. However, we still need to do the loop in order to get an accurate `exprp` value, which is later used to adjust the `arity` after sorting (there are other ways to get there that don't involve copying the extra `null`, but they are more convoluted, so I elected to go for this solution).
> 
> Thanks,
> Jorn
> 
> Testing: tier1-tier2

LGTM.

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2054

From redestad at openjdk.java.net  Wed Jan 20 23:45:49 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 20 Jan 2021 23:45:49 GMT
Subject: Integrated: 8259911: byteArrayViewVarHandle should throw
 ArrayIndexOutOfBoundsException
In-Reply-To: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com>
References: <0dFqAp7SUPjtQx30PZVkyCknlNbmQyVorikIsnFgqm4=.41a09ef3-3b45-4829-b51e-dd08d6feb850@github.com>
Message-ID: <fqDIGqhOEvQeVlEaFWd94iUjCq_bdWze1oOjCnUQFt4=.12c9807e-9fc8-4062-bbac-6c1324783156@github.com>

On Mon, 18 Jan 2021 12:09:23 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Change `MethodHandles.byteArrayViewVarHandle` to throw `ArrayIndexOutOfBoundsException` rather than the more generic `IndexArrayOutOfBoundsException`. This feels more natural, and reduces the risk for subtle behavioral mismatch when migrating code from arrays/Unsafe to VHs. 
> 
> CSR: [JDK-8259912](https://bugs.openjdk.java.net/browse/JDK-8259912)

This pull request has now been integrated.

Changeset: 27cc62a5
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/27cc62a5
Stats:     534 lines in 30 files changed: 13 ins; 0 del; 521 mod

8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException

Reviewed-by: jvernee, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/2124

From redestad at openjdk.java.net  Wed Jan 20 23:45:57 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 20 Jan 2021 23:45:57 GMT
Subject: Integrated: 8260010: UTF8ZipCoder not thread-safe since JDK-8243469
In-Reply-To: <FKSENm_67dbi0lH2yK-FCIuNIZfV6IRqLF3NY9voueI=.c4ccd8bb-417c-4fcc-bc74-80f3800cc8db@github.com>
References: <FKSENm_67dbi0lH2yK-FCIuNIZfV6IRqLF3NY9voueI=.c4ccd8bb-417c-4fcc-bc74-80f3800cc8db@github.com>
Message-ID: <S9RvFgsN5nDvc8VVGZLmhuh03vPyzpr4ajNrS4ws1-g=.96ac1dc6-715b-4cf6-80cf-c3e7513d0010@github.com>

On Wed, 20 Jan 2021 12:21:21 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch resolves a thread-safety issue where the singleton UTF8ZipCoder is erroneously using a shared CharsetDecoder when the fast-path fails. It needs to go via creating a new String like before JDK-8243469
> 
> This should resolve a rare issue when doing a lot of jar scanning in parallel on jar/zip files (with at least some non-ASCII entries), but I've not managed to create a test that reliably reproduce the issue.

This pull request has now been integrated.

Changeset: 1f47de5f
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1f47de5f
Stats:     9 lines in 1 file changed: 6 ins; 0 del; 3 mod

8260010: UTF8ZipCoder not thread-safe since JDK-8243469

Reviewed-by: lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/2163

From redestad at openjdk.java.net  Wed Jan 20 23:48:55 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 20 Jan 2021 23:48:55 GMT
Subject: Integrated: 8259498: Reduce overhead of MD5 and SHA digests
In-Reply-To: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
References: <Wxdm3AssB0FQ9lEP8NuGdfPNioiQlTQV2-GQ9o4RIHw=.4e8ca1fd-ebde-41e1-89a3-6cc7fa2b7f27@github.com>
Message-ID: <oR0fLYS6ZgScUh9YuVsbsViyhWQGztxlHlb6k14t-pM=.28f511b1-8cd0-4b89-a74d-329cf6830bf4@github.com>

On Sun, 20 Dec 2020 20:27:03 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration
> - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization.
> - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence.
> 
> Baseline:
>                               (digesterName)  (length)    Cnt     Score      Error   Units
> MessageDigests.digest                                MD5        16     15  2714.307 ?   21.133  ops/ms
> MessageDigests.digest                                MD5      1024     15   318.087 ?    0.637  ops/ms
> MessageDigests.digest                              SHA-1        16     15  1387.266 ?   40.932  ops/ms
> MessageDigests.digest                              SHA-1      1024     15   109.273 ?    0.149  ops/ms
> MessageDigests.digest                            SHA-256        16     15   995.566 ?   21.186  ops/ms
> MessageDigests.digest                            SHA-256      1024     15    89.104 ?    0.079  ops/ms
> MessageDigests.digest                            SHA-512        16     15   803.030 ?   15.722  ops/ms
> MessageDigests.digest                            SHA-512      1024     15   115.611 ?    0.234  ops/ms
> MessageDigests.getAndDigest                          MD5        16     15  2190.367 ?   97.037  ops/ms
> MessageDigests.getAndDigest                          MD5      1024     15   302.903 ?    1.809  ops/ms
> MessageDigests.getAndDigest                        SHA-1        16     15  1262.656 ?   43.751  ops/ms
> MessageDigests.getAndDigest                        SHA-1      1024     15   104.889 ?    3.554  ops/ms
> MessageDigests.getAndDigest                      SHA-256        16     15   914.541 ?   55.621  ops/ms
> MessageDigests.getAndDigest                      SHA-256      1024     15    85.708 ?    1.394  ops/ms
> MessageDigests.getAndDigest                      SHA-512        16     15   737.719 ?   53.671  ops/ms
> MessageDigests.getAndDigest                      SHA-512      1024     15   112.307 ?    1.950  ops/ms
> 
> GC:
> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   312.011 ?    0.005    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.020 ?    0.006    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   544.019 ?    0.016    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15  1056.037 ?    0.003    B/op
> 
> Target:
> Benchmark                                 (digesterName)  (length)    Cnt     Score      Error   Units
> MessageDigests.digest                                MD5        16     15  3134.462 ?   43.685  ops/ms
> MessageDigests.digest                                MD5      1024     15   323.667 ?    0.633  ops/ms
> MessageDigests.digest                              SHA-1        16     15  1418.742 ?   38.223  ops/ms
> MessageDigests.digest                              SHA-1      1024     15   110.178 ?    0.788  ops/ms
> MessageDigests.digest                            SHA-256        16     15  1037.949 ?   21.214  ops/ms
> MessageDigests.digest                            SHA-256      1024     15    89.671 ?    0.228  ops/ms
> MessageDigests.digest                            SHA-512        16     15   812.028 ?   39.489  ops/ms
> MessageDigests.digest                            SHA-512      1024     15   116.738 ?    0.249  ops/ms
> MessageDigests.getAndDigest                          MD5        16     15  2314.379 ?  229.294  ops/ms
> MessageDigests.getAndDigest                          MD5      1024     15   307.835 ?    5.730  ops/ms
> MessageDigests.getAndDigest                        SHA-1        16     15  1326.887 ?   63.263  ops/ms
> MessageDigests.getAndDigest                        SHA-1      1024     15   106.611 ?    2.292  ops/ms
> MessageDigests.getAndDigest                      SHA-256        16     15   961.589 ?   82.052  ops/ms
> MessageDigests.getAndDigest                      SHA-256      1024     15    88.646 ?    0.194  ops/ms
> MessageDigests.getAndDigest                      SHA-512        16     15   775.417 ?   56.775  ops/ms
> MessageDigests.getAndDigest                      SHA-512      1024     15   112.904 ?    2.014  ops/ms
> 
> GC
> MessageDigests.getAndDigest:?gc.alloc.rate.norm      MD5        16     15   232.009 ?    0.006    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm    SHA-1        16     15   584.021 ?    0.001    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-256        16     15   272.012 ?    0.015    B/op
> MessageDigests.getAndDigest:?gc.alloc.rate.norm  SHA-512        16     15   400.017 ?    0.019    B/op
> 
> For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW.
> 
> For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test.
> 
> I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show.

This pull request has now been integrated.

Changeset: 35c9da70
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/35c9da70
Stats:     655 lines in 8 files changed: 79 ins; 350 del; 226 mod

8259498: Reduce overhead of MD5 and SHA digests

Reviewed-by: valeriep

-------------

PR: https://git.openjdk.java.net/jdk/pull/1855

From naoto at openjdk.java.net  Wed Jan 20 23:58:56 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 20 Jan 2021 23:58:56 GMT
Subject: RFR: 8259943: FileDescriptor.close0 does not handle EINTR
In-Reply-To: <8Svc34lGaB1DE4J_4yHgouxc6pnd4sSaHa3lzfRVy4s=.37995476-c5a3-476c-9a0b-2c98af07e47f@github.com>
References: <8Svc34lGaB1DE4J_4yHgouxc6pnd4sSaHa3lzfRVy4s=.37995476-c5a3-476c-9a0b-2c98af07e47f@github.com>
Message-ID: <3lHxp3RbKiSy_JqiMq4jPtZteHetEXkW9wB-5xwfsUo=.787ddf65-c05a-4876-9fbf-54dbd088def4@github.com>

On Wed, 20 Jan 2021 23:01:19 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this small change to handle `EINTR` from `close()` in `fileDescriptorClose()`. The function `handleGetLength()` is also changed to handle `EINTR` from `fstat64()` to match other uses of `fstat64()` in the file.

Looks good, Brian.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2173

From jwilhelm at openjdk.java.net  Thu Jan 21 04:41:15 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 21 Jan 2021 04:41:15 GMT
Subject: RFR: Merge jdk16
Message-ID: <NN4thzbqhjubg5TRbiID80k6v0JGR5OY0Dqgz1uGyAI=.814e8aac-06b7-4e64-8072-426e852e1998@github.com>

Forwardport JDK 16 -> JDK 17

-------------

Commit messages:
 - Merge
 - 8259757: add a regression test for 8259353 and 8259601
 - 8259732: JDK 16 L10n resource file update - msg drop 10

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2176&range=00.0
 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2176&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/2176/files
  Stats: 296 lines in 31 files changed: 200 ins; 16 del; 80 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2176.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2176/head:pull/2176

PR: https://git.openjdk.java.net/jdk/pull/2176

From bchristi at openjdk.java.net  Thu Jan 21 05:21:54 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Thu, 21 Jan 2021 05:21:54 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
In-Reply-To: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
Message-ID: <ZcUGBjirPn92xFn2-zW7YnQUWjyKMrlAapqGqiG75eI=.2c5a5e0d-8687-4f92-b735-55b0d470c1ef@github.com>

On Wed, 20 Jan 2021 17:27:43 GMT, Mahendra Chhipa <github.com+34924738+mahendrachhipa at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8183372

Can this be done all in `EnclosingClassTest.java`, without a new `RunEnclosingClassTest.java`?

Adding the `@BeforeClass` and `@AfterClass` methods to what's there, you may just need to 
change the `test()` calls to use reflection - something along the lines of: 

> test(`Class.forName("EnclosingClass").getDeclaredConstructor().newInstance());`

-------------

PR: https://git.openjdk.java.net/jdk/pull/2170

From jwilhelm at openjdk.java.net  Thu Jan 21 05:26:59 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 21 Jan 2021 05:26:59 GMT
Subject: Integrated: Merge jdk16
In-Reply-To: <NN4thzbqhjubg5TRbiID80k6v0JGR5OY0Dqgz1uGyAI=.814e8aac-06b7-4e64-8072-426e852e1998@github.com>
References: <NN4thzbqhjubg5TRbiID80k6v0JGR5OY0Dqgz1uGyAI=.814e8aac-06b7-4e64-8072-426e852e1998@github.com>
Message-ID: <9sHQ5RFKu7eMA2dnKWQ9ZWXPzT_HnSJdXDZ2j4kX8to=.69bf5258-7371-4404-a1af-b54febf7cad7@github.com>

On Thu, 21 Jan 2021 04:33:47 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: 133bcb09
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/133bcb09
Stats:     296 lines in 31 files changed: 200 ins; 16 del; 80 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/2176

From alanb at openjdk.java.net  Thu Jan 21 07:35:57 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 21 Jan 2021 07:35:57 GMT
Subject: RFR: 8259943: FileDescriptor.close0 does not handle EINTR
In-Reply-To: <8Svc34lGaB1DE4J_4yHgouxc6pnd4sSaHa3lzfRVy4s=.37995476-c5a3-476c-9a0b-2c98af07e47f@github.com>
References: <8Svc34lGaB1DE4J_4yHgouxc6pnd4sSaHa3lzfRVy4s=.37995476-c5a3-476c-9a0b-2c98af07e47f@github.com>
Message-ID: <N5a_952VDHLtaHUkMJVWxeSZV11hNIKXBNG7rbDEbqc=.90993611-f052-497e-a0e9-63a7ee7db4d9@github.com>

On Wed, 20 Jan 2021 23:01:19 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this small change to handle `EINTR` from `close()` in `fileDescriptorClose()`. The function `handleGetLength()` is also changed to handle `EINTR` from `fstat64()` to match other uses of `fstat64()` in the file.

src/java.base/unix/native/libjava/io_util_md.c line 167:

> 165:     } else {
> 166:         int result;
> 167:         RESTARTABLE(close(fd), result);

close is not restartable (except AIX apparently). This means you have to explicitly handle EINTR, see UnixNativeDispatcher.close0 for an example.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2173

From jiefu at openjdk.java.net  Thu Jan 21 09:37:53 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 21 Jan 2021 09:37:53 GMT
Subject: RFR: 8259925: [Vector API] Unreasonable IndexOutOfBoundsException
 message when length < vlen
In-Reply-To: <wc6FWksUAR7mY0S_XQox0UgcR9DwpOswrqNRpAZrnDI=.e7327508-a423-4c35-854e-02a55c0aa971@github.com>
References: <IXlGGauVhUjxPJXm8CjZ0Eo4-ySUttJ_EqYpxiW7p8E=.32dc9082-78ad-4407-a6a2-3652dfef8a4c@github.com>
 <LzL6761_WZOicSWpwUGbYjnnWKlqQPSLtMqLKp5Q_ls=.343834be-ef22-4bc1-91c5-c8388627f6f5@github.com>
 <ZAH7vzOKC5VPi7V6ElL55VxQsgA4AAuVUOH4v8u4QfY=.4cb1b26e-6c19-4083-8495-2d046efa3ddd@github.com>
 <wc6FWksUAR7mY0S_XQox0UgcR9DwpOswrqNRpAZrnDI=.e7327508-a423-4c35-854e-02a55c0aa971@github.com>
Message-ID: <7fzq6Na3zlPQIp8-ZRytFFDHLU58CaWon0tNEzww4yc=.e4e11ac0-4906-4da0-af83-c3ac8de1f957@github.com>

On Wed, 20 Jan 2021 19:30:41 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Unfortunately it is still problematic because you have replaced the intrinsic check (that performed by `Object.checksIndex`, or more specifically [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/util/Preconditions.java#L261)).
> 
> Further, you have replaced the bounds check options, in place for experimentation. We are not ready yet to collapse our options, further analysis is required as bounds checks can be very sensitive in C2.
> 
> I would be open to you adding a third case, so that you can analyze the performance without perturbing the default behavior. I suspect the correct fix is to make intrinsic `Objects.checkFromIndexSize` in a similar manner to `Object.checksIndex`.

Hi @PaulSandoz ,

Thanks for your kind review and comments.

To be honest, I didn't get your first point.
As for the example above, the intrinsified Objects.checkIndex seems to generate more code than inlined if-statements.
So I'm confused why it's a problem to replace the intrinsic check.
Did you mean an intrinsic is always (or for most cases) better than non-intrinc or inlined if-statements?
And why?

Could you please make it more clearer to us?
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2127

From redestad at openjdk.java.net  Thu Jan 21 11:42:15 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 21 Jan 2021 11:42:15 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v8]
In-Reply-To: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
Message-ID: <0mh3Pl8iin-nxi7UA9g6bb28ZXakR_1uqbORAArOizo=.666e13b4-beeb-4ef3-83d9-98579a00b148@github.com>

> The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.
> 
> This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.
> 
> Microbenchmark results:
> Baseline
> 
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
> decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op
> 
> Patched:
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
> decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op
> 
> Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.
> 
> Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.
> 
> Testing: tier1-4

Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - More cleanups, make all things private that can be
 - Merge branch 'master' into sc_tl_exp
 - More privates
 - Harmonize empty string checking in newString methods
 - ASCII fast-path missing for UTF-8 NoRepl methods
 - Simplify lookupCharset
 - Add missing import (who needs IDEs?)
 - Further simplifications
 - Copyrights
 - Merge branch 'master' into sc_tl_exp
 - ... and 14 more: https://git.openjdk.java.net/jdk/compare/7f7166db...869bc109

-------------

Changes: https://git.openjdk.java.net/jdk/pull/2102/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2102&range=07
  Stats: 998 lines in 4 files changed: 437 ins; 469 del; 92 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2102.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2102/head:pull/2102

PR: https://git.openjdk.java.net/jdk/pull/2102

From abakhtin at openjdk.java.net  Thu Jan 21 13:13:38 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Thu, 21 Jan 2021 13:13:38 GMT
Subject: RFR: 8259707: LDAP channel binding does not work with StartTLS
 extension [v2]
In-Reply-To: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
References: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
Message-ID: <yqYPXVDpaOucFt4jUd1GvQ4XOboKRqMAxxD-d0WLmjQ=.20706e4a-6512-4b2a-82a4-e487fc72876b@github.com>

> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS Extension.
> Test from the bug report and jtreg javax/naming tests are passed.

Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:

  separate tlsHandshakeCompleted for every StartTLS connection

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2085/files
  - new: https://git.openjdk.java.net/jdk/pull/2085/files/d2f470e7..30a29e07

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2085&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2085&range=00-01

  Stats: 71 lines in 2 files changed: 37 ins; 25 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2085.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2085/head:pull/2085

PR: https://git.openjdk.java.net/jdk/pull/2085

From abakhtin at openjdk.java.net  Thu Jan 21 13:25:25 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Thu, 21 Jan 2021 13:25:25 GMT
Subject: RFR: 8259707: LDAP channel binding does not work with StartTLS
 extension [v2]
In-Reply-To: <tOqkvV4MYs8baP-TmZWwiTQK8hk60qYOtzeEjYR6mLc=.f2e4d6e2-edf4-40cb-a790-da7a02781d56@github.com>
References: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
 <v55huk47FW0WqOBmncu96V-SNJb2pn7TBBCKGJrnHZE=.2b66413d-b432-4a54-9948-3116d46a9438@github.com>
 <frtTVdnU2xxVW4Y_v1sAMWS4c65OTDj13E5bOqjOhrw=.30cd7f30-3ab9-4ecd-b333-86392e4e700c@github.com>
 <DxSCzjhMQ4czi5yIpVGo-vs3dQnFcq_8-WqdC60VMsY=.1dc15b37-cdaf-49c5-b6f1-d26bba81c6bf@github.com>
 <tOqkvV4MYs8baP-TmZWwiTQK8hk60qYOtzeEjYR6mLc=.f2e4d6e2-edf4-40cb-a790-da7a02781d56@github.com>
Message-ID: <18kXNpZ9mq5oDwLqBbrN40zLmcJBk9fQQ5xdW0xukkE=.e23476e6-af33-402d-a826-432ea4a125ec@github.com>

On Wed, 20 Jan 2021 15:54:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> New ChannelBinding Data will be recreated for every TLS connection and provided to SASL Client in the new environment properties set (cloned from the original). 
>> LdapSasl.java lines 133 - 136:
>>                         TlsChannelBinding tlsCB =
>>                                 TlsChannelBinding.create(cert);
>>                         envProps = (Hashtable<String, Object>) env.clone();
>>                         envProps.put(TlsChannelBinding.CHANNEL_BINDING, tlsCB.getData());
>
>> New ChannelBinding Data will be recreated for every TLS connection and provided to SASL Client in the new environment properties set (cloned from the original).
>> LdapSasl.java lines 133 - 136:
>> 
>> ```
>>                         TlsChannelBinding tlsCB =
>>                                 TlsChannelBinding.create(cert);
>>                         envProps = (Hashtable<String, Object>) env.clone();
> 
> Hi Alexey, 
> 
> Aleksei and I have concern because this code uses a `cert` that is obtained from a CompletableFuture, and the completable future  can be completed only once. The second time around - you will therefore find the same `cert` that was set when the first StartTLSResponse was negotiated. This may - or may not matter - depending on whether the `cert` certificate returned by the server the second time around should be the same - or not.
> Could you test this scenario?
> It may be that it's a niche scenario that makes no sense or that we don't want to support - I'm not sure how STARTTLS is used in the wild. Do you have any insights on this?
> 
> best regards,
> 
> -- daniel

Hi Daniel, Aleksei,

You are right, the second StartTLS request works incorrectly because of a single CompletableFuture. I do not know if several StartTLS sessions are used in the wild, but there are no such restrictions in the spec. I have updated the review to create new CompletableFuture for each TLS session. Updated test, suggested by Aleksei is passed. I have verified that the Channel Binding data is created on the base of a new cert object every TLS session.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2085

From psandoz at openjdk.java.net  Thu Jan 21 16:56:51 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 21 Jan 2021 16:56:51 GMT
Subject: RFR: 8259925: [Vector API] Unreasonable IndexOutOfBoundsException
 message when length < vlen
In-Reply-To: <7fzq6Na3zlPQIp8-ZRytFFDHLU58CaWon0tNEzww4yc=.e4e11ac0-4906-4da0-af83-c3ac8de1f957@github.com>
References: <IXlGGauVhUjxPJXm8CjZ0Eo4-ySUttJ_EqYpxiW7p8E=.32dc9082-78ad-4407-a6a2-3652dfef8a4c@github.com>
 <LzL6761_WZOicSWpwUGbYjnnWKlqQPSLtMqLKp5Q_ls=.343834be-ef22-4bc1-91c5-c8388627f6f5@github.com>
 <ZAH7vzOKC5VPi7V6ElL55VxQsgA4AAuVUOH4v8u4QfY=.4cb1b26e-6c19-4083-8495-2d046efa3ddd@github.com>
 <wc6FWksUAR7mY0S_XQox0UgcR9DwpOswrqNRpAZrnDI=.e7327508-a423-4c35-854e-02a55c0aa971@github.com>
 <7fzq6Na3zlPQIp8-ZRytFFDHLU58CaWon0tNEzww4yc=.e4e11ac0-4906-4da0-af83-c3ac8de1f957@github.com>
Message-ID: <oGnSUOfY151JLoMo2ITtc6FRLOQ-210RjUl-nGnhBgo=.36a91aa9-de48-4818-aea7-a9ba99a506e5@github.com>

On Thu, 21 Jan 2021 09:35:01 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Unfortunately it is still problematic because you have replaced the intrinsic check (that performed by `Object.checksIndex`, or more specifically [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/util/Preconditions.java#L261)).
>> 
>> Further, you have replaced the bounds check options, in place for experimentation. We are not ready yet to collapse our options, further analysis is required as bounds checks can be very sensitive in C2.
>> 
>> I would be open to you adding a third case, so that you can analyze the performance without perturbing the default behavior. I suspect the correct fix is to make intrinsic `Objects.checkFromIndexSize` in a similar manner to `Object.checksIndex`.
>
>> Unfortunately it is still problematic because you have replaced the intrinsic check (that performed by `Object.checksIndex`, or more specifically [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/util/Preconditions.java#L261)).
>> 
>> Further, you have replaced the bounds check options, in place for experimentation. We are not ready yet to collapse our options, further analysis is required as bounds checks can be very sensitive in C2.
>> 
>> I would be open to you adding a third case, so that you can analyze the performance without perturbing the default behavior. I suspect the correct fix is to make intrinsic `Objects.checkFromIndexSize` in a similar manner to `Object.checksIndex`.
> 
> Hi @PaulSandoz ,
> 
> Thanks for your kind review and comments.
> 
> To be honest, I didn't get your first point.
> As for the example above, the intrinsified Objects.checkIndex seems to generate more code than inlined if-statements.
> So I'm confused why it's a problem to replace the intrinsic check.
> Did you mean an intrinsic is always (or for most cases) better than non-intrinc or inlined if-statements?
> And why?
> 
> Could you please make it more clearer to us?
> Thanks.

The intrinsic enables C2 to more reliably elide bounds checks. I don't know the exact details but at a high-level it transforms signed values into unsigned values (and therefore the signed comparisons become unsigned comparisons), which helps C2 remove checks when there is a dominating check of, for example, an upper loop bound.

You say "the intrinsified Objects.checkIndex seems to generate more code than inlined if-statements". Can you present some examples of Java code and the corresponding C2 generated assembler where this happens?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2127

From aefimov at openjdk.java.net  Thu Jan 21 18:27:41 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Thu, 21 Jan 2021 18:27:41 GMT
Subject: RFR: 8259707: LDAP channel binding does not work with StartTLS
 extension [v2]
In-Reply-To: <yqYPXVDpaOucFt4jUd1GvQ4XOboKRqMAxxD-d0WLmjQ=.20706e4a-6512-4b2a-82a4-e487fc72876b@github.com>
References: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
 <yqYPXVDpaOucFt4jUd1GvQ4XOboKRqMAxxD-d0WLmjQ=.20706e4a-6512-4b2a-82a4-e487fc72876b@github.com>
Message-ID: <8bqFOxDyzziFEmmJgOgHLlauGeL6-oFV4gPKYWrZbMQ=.aa42780a-8c6e-43a1-8ee0-c0a0df607a45@github.com>

On Thu, 21 Jan 2021 13:13:38 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS Extension.
>> Test from the bug report and jtreg javax/naming tests are passed.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   separate tlsHandshakeCompleted for every StartTLS connection

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 1034:

> 1032:     }
> 1033: 
> 1034:     private HandshakeListener tlsHandshakeListener;

I believe that `volatile` modifier should be added here. And it could be beneficial for future maintainers to have here a comment block with a brief description of when `tlsHandshakeListener` is used.

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 1059:

> 1057:     private class HandshakeListener implements HandshakeCompletedListener {
> 1058: 
> 1059:         private CompletableFuture<X509Certificate> tlsHandshakeCompleted =

`tlsHandshakeCompleted` could be made `final`

-------------

PR: https://git.openjdk.java.net/jdk/pull/2085

From bpb at openjdk.java.net  Thu Jan 21 18:28:17 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 21 Jan 2021 18:28:17 GMT
Subject: RFR: 8259943: FileDescriptor.close0 does not handle EINTR
In-Reply-To: <N5a_952VDHLtaHUkMJVWxeSZV11hNIKXBNG7rbDEbqc=.90993611-f052-497e-a0e9-63a7ee7db4d9@github.com>
References: <8Svc34lGaB1DE4J_4yHgouxc6pnd4sSaHa3lzfRVy4s=.37995476-c5a3-476c-9a0b-2c98af07e47f@github.com>
 <N5a_952VDHLtaHUkMJVWxeSZV11hNIKXBNG7rbDEbqc=.90993611-f052-497e-a0e9-63a7ee7db4d9@github.com>
Message-ID: <6C9GSl9aHxu1HldFVW64W6agmrptFjaxQIMCgdLpqPA=.07a9bdbc-b687-4bb7-b429-b7208b9456f0@github.com>

On Thu, 21 Jan 2021 07:32:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this small change to handle `EINTR` from `close()` in `fileDescriptorClose()`. The function `handleGetLength()` is also changed to handle `EINTR` from `fstat64()` to match other uses of `fstat64()` in the file.
>
> src/java.base/unix/native/libjava/io_util_md.c line 167:
> 
>> 165:     } else {
>> 166:         int result;
>> 167:         RESTARTABLE(close(fd), result);
> 
> close is not restartable (except AIX apparently). This means you have to explicitly handle EINTR, see UnixNativeDispatcher.close0 for an example.

I had it that way before creating the PR; will revert.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2173

From bpb at openjdk.java.net  Thu Jan 21 18:56:59 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 21 Jan 2021 18:56:59 GMT
Subject: RFR: 8259943: FileDescriptor.close0 does not handle EINTR [v2]
In-Reply-To: <8Svc34lGaB1DE4J_4yHgouxc6pnd4sSaHa3lzfRVy4s=.37995476-c5a3-476c-9a0b-2c98af07e47f@github.com>
References: <8Svc34lGaB1DE4J_4yHgouxc6pnd4sSaHa3lzfRVy4s=.37995476-c5a3-476c-9a0b-2c98af07e47f@github.com>
Message-ID: <QWbAF0xetP1b_4QSVjOhahZtIAOOejFiQKG1VDSBznA=.f1c46b58-9800-419d-94a0-f502abe52053@github.com>

> Please review this small change to handle `EINTR` from `close()` in `fileDescriptorClose()`. The function `handleGetLength()` is also changed to handle `EINTR` from `fstat64()` to match other uses of `fstat64()` in the file.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8259943: Suppress RESTARTABLE for non-AIX.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2173/files
  - new: https://git.openjdk.java.net/jdk/pull/2173/files/047dac0b..d351118a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2173&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2173&range=00-01

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2173.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2173/head:pull/2173

PR: https://git.openjdk.java.net/jdk/pull/2173

From alanb at openjdk.java.net  Thu Jan 21 19:06:10 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 21 Jan 2021 19:06:10 GMT
Subject: RFR: 8259943: FileDescriptor.close0 does not handle EINTR [v2]
In-Reply-To: <QWbAF0xetP1b_4QSVjOhahZtIAOOejFiQKG1VDSBznA=.f1c46b58-9800-419d-94a0-f502abe52053@github.com>
References: <8Svc34lGaB1DE4J_4yHgouxc6pnd4sSaHa3lzfRVy4s=.37995476-c5a3-476c-9a0b-2c98af07e47f@github.com>
 <QWbAF0xetP1b_4QSVjOhahZtIAOOejFiQKG1VDSBznA=.f1c46b58-9800-419d-94a0-f502abe52053@github.com>
Message-ID: <o7SsddYHpeiD4_t3B4OJE1y7wzxaoGNyvtEEOY1M6Qo=.c4a1ac27-6780-4010-90f2-f2575b435a39@github.com>

On Thu, 21 Jan 2021 18:56:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please review this small change to handle `EINTR` from `close()` in `fileDescriptorClose()`. The function `handleGetLength()` is also changed to handle `EINTR` from `fstat64()` to match other uses of `fstat64()` in the file.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8259943: Suppress RESTARTABLE for non-AIX.

src/java.base/unix/native/libjava/io_util_md.c line 173:

> 171:         result = close(fd);
> 172: #endif
> 173:         if (result == -1) {

This needs to be `if (result == -1 && errno != EINTR)`

-------------

PR: https://git.openjdk.java.net/jdk/pull/2173

From brian.burkhalter at oracle.com  Thu Jan 21 19:07:03 2021
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 21 Jan 2021 11:07:03 -0800
Subject: RFR: 8259943: FileDescriptor.close0 does not handle EINTR [v2]
In-Reply-To: <o7SsddYHpeiD4_t3B4OJE1y7wzxaoGNyvtEEOY1M6Qo=.c4a1ac27-6780-4010-90f2-f2575b435a39@github.com>
References: <8Svc34lGaB1DE4J_4yHgouxc6pnd4sSaHa3lzfRVy4s=.37995476-c5a3-476c-9a0b-2c98af07e47f@github.com>
 <QWbAF0xetP1b_4QSVjOhahZtIAOOejFiQKG1VDSBznA=.f1c46b58-9800-419d-94a0-f502abe52053@github.com>
 <o7SsddYHpeiD4_t3B4OJE1y7wzxaoGNyvtEEOY1M6Qo=.c4a1ac27-6780-4010-90f2-f2575b435a39@github.com>
Message-ID: <87384C03-0023-4D39-AB06-5079F19CCB8A@oracle.com>



> On Jan 21, 2021, at 11:06 AM, Alan Bateman <alanb at openjdk.java.net> wrote:
> 
> On Thu, 21 Jan 2021 18:56:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:
> 
>>> Please review this small change to handle `EINTR` from `close()` in `fileDescriptorClose()`. The function `handleGetLength()` is also changed to handle `EINTR` from `fstat64()` to match other uses of `fstat64()` in the file.
>> 
>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>  8259943: Suppress RESTARTABLE for non-AIX.
> 
> src/java.base/unix/native/libjava/io_util_md.c line 173:
> 
>> 171:         result = close(fd);
>> 172: #endif
>> 173:         if (result == -1) {
> 
> This needs to be `if (result == -1 && errno != EINTR)`

Yes I already caught and fixed that gaff.

> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2173


From bpb at openjdk.java.net  Thu Jan 21 19:16:45 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 21 Jan 2021 19:16:45 GMT
Subject: RFR: 8259943: FileDescriptor.close0 does not handle EINTR [v3]
In-Reply-To: <8Svc34lGaB1DE4J_4yHgouxc6pnd4sSaHa3lzfRVy4s=.37995476-c5a3-476c-9a0b-2c98af07e47f@github.com>
References: <8Svc34lGaB1DE4J_4yHgouxc6pnd4sSaHa3lzfRVy4s=.37995476-c5a3-476c-9a0b-2c98af07e47f@github.com>
Message-ID: <FcWGjehWsP94J9kjxpLthbYqUcObyUU0rYTz8lcJDgo=.0ac7b4a6-e684-4519-831f-e5556a6cfa64@github.com>

> Please review this small change to handle `EINTR` from `close()` in `fileDescriptorClose()`. The function `handleGetLength()` is also changed to handle `EINTR` from `fstat64()` to match other uses of `fstat64()` in the file.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8259943: Added unintentionally omitted EINTR check.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2173/files
  - new: https://git.openjdk.java.net/jdk/pull/2173/files/d351118a..45a5d188

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2173&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2173&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2173.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2173/head:pull/2173

PR: https://git.openjdk.java.net/jdk/pull/2173

From alanb at openjdk.java.net  Thu Jan 21 19:16:45 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 21 Jan 2021 19:16:45 GMT
Subject: RFR: 8259943: FileDescriptor.close0 does not handle EINTR [v3]
In-Reply-To: <FcWGjehWsP94J9kjxpLthbYqUcObyUU0rYTz8lcJDgo=.0ac7b4a6-e684-4519-831f-e5556a6cfa64@github.com>
References: <8Svc34lGaB1DE4J_4yHgouxc6pnd4sSaHa3lzfRVy4s=.37995476-c5a3-476c-9a0b-2c98af07e47f@github.com>
 <FcWGjehWsP94J9kjxpLthbYqUcObyUU0rYTz8lcJDgo=.0ac7b4a6-e684-4519-831f-e5556a6cfa64@github.com>
Message-ID: <spkbNOJlZoxiMWJr9jYW3WGe-EtuHmera9nSwV_XCvQ=.505f8e62-f960-4d33-9bd6-5dd16f561ae0@github.com>

On Thu, 21 Jan 2021 19:12:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please review this small change to handle `EINTR` from `close()` in `fileDescriptorClose()`. The function `handleGetLength()` is also changed to handle `EINTR` from `fstat64()` to match other uses of `fstat64()` in the file.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8259943: Added unintentionally omitted EINTR check.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2173

From bpb at openjdk.java.net  Thu Jan 21 19:16:46 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 21 Jan 2021 19:16:46 GMT
Subject: RFR: 8259943: FileDescriptor.close0 does not handle EINTR [v2]
In-Reply-To: <o7SsddYHpeiD4_t3B4OJE1y7wzxaoGNyvtEEOY1M6Qo=.c4a1ac27-6780-4010-90f2-f2575b435a39@github.com>
References: <8Svc34lGaB1DE4J_4yHgouxc6pnd4sSaHa3lzfRVy4s=.37995476-c5a3-476c-9a0b-2c98af07e47f@github.com>
 <QWbAF0xetP1b_4QSVjOhahZtIAOOejFiQKG1VDSBznA=.f1c46b58-9800-419d-94a0-f502abe52053@github.com>
 <o7SsddYHpeiD4_t3B4OJE1y7wzxaoGNyvtEEOY1M6Qo=.c4a1ac27-6780-4010-90f2-f2575b435a39@github.com>
Message-ID: <dNImQyslckhdI8uurvk7eXM6J54hagEs-N91KQSYMO0=.fbb4fd72-46ad-481f-b014-76808ad693b4@github.com>

On Thu, 21 Jan 2021 18:58:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8259943: Suppress RESTARTABLE for non-AIX.
>
> src/java.base/unix/native/libjava/io_util_md.c line 173:
> 
>> 171:         result = close(fd);
>> 172: #endif
>> 173:         if (result == -1) {
> 
> This needs to be `if (result == -1 && errno != EINTR)`

Yes, I already caught and fixed that gaffe.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2173

From redestad at openjdk.java.net  Thu Jan 21 19:56:36 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 21 Jan 2021 19:56:36 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v9]
In-Reply-To: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
Message-ID: <Ft2su8ScaXmS3zSbxJ-VHPrNDTct0C66EAW9K9Cpbnw=.bb664596-00e7-4864-8380-d6e82a84f5b0@github.com>

> The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.
> 
> This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.
> 
> Microbenchmark results:
> Baseline
> 
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
> decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op
> 
> Patched:
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
> decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op
> 
> Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.
> 
> Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.
> 
> Testing: tier1-4

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Move most of the encode/decode code to String, remove StringEncoder and the ThreadLocal encoder facility.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2102/files
  - new: https://git.openjdk.java.net/jdk/pull/2102/files/869bc109..a45b761d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2102&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2102&range=07-08

  Stats: 1355 lines in 4 files changed: 639 ins; 688 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2102.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2102/head:pull/2102

PR: https://git.openjdk.java.net/jdk/pull/2102

From abakhtin at openjdk.java.net  Thu Jan 21 19:57:04 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Thu, 21 Jan 2021 19:57:04 GMT
Subject: RFR: 8259707: LDAP channel binding does not work with StartTLS
 extension [v3]
In-Reply-To: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
References: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
Message-ID: <RS7sqOZdQNl4TA7DX7uuR0tczwqohihtzuq1kOrSiYU=.761cbafa-382d-44e7-a27b-4eba96e7f437@github.com>

> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS Extension.
> Test from the bug report and jtreg javax/naming tests are passed.

Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:

  Add comments and volatile modifier for tlsHandshakeListener

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2085/files
  - new: https://git.openjdk.java.net/jdk/pull/2085/files/30a29e07..e3bf8c36

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2085&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2085&range=01-02

  Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2085.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2085/head:pull/2085

PR: https://git.openjdk.java.net/jdk/pull/2085

From abakhtin at openjdk.java.net  Thu Jan 21 19:57:06 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Thu, 21 Jan 2021 19:57:06 GMT
Subject: RFR: 8259707: LDAP channel binding does not work with StartTLS
 extension [v2]
In-Reply-To: <8bqFOxDyzziFEmmJgOgHLlauGeL6-oFV4gPKYWrZbMQ=.aa42780a-8c6e-43a1-8ee0-c0a0df607a45@github.com>
References: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
 <yqYPXVDpaOucFt4jUd1GvQ4XOboKRqMAxxD-d0WLmjQ=.20706e4a-6512-4b2a-82a4-e487fc72876b@github.com>
 <8bqFOxDyzziFEmmJgOgHLlauGeL6-oFV4gPKYWrZbMQ=.aa42780a-8c6e-43a1-8ee0-c0a0df607a45@github.com>
Message-ID: <2CkKMhqwLkH6GAebWpRidXWf_9DnjG7o7prlJ10V-D4=.cf3c1bc9-2d6b-47d5-85cf-89c30fff48e5@github.com>

On Thu, 21 Jan 2021 18:19:10 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   separate tlsHandshakeCompleted for every StartTLS connection
>
> src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 1034:
> 
>> 1032:     }
>> 1033: 
>> 1034:     private HandshakeListener tlsHandshakeListener;
> 
> I believe that `volatile` modifier should be added here. And it could be beneficial for future maintainers to have here a comment block with a brief description of when `tlsHandshakeListener` is used.

Agree. Added comments and volatile modifier.

> src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 1059:
> 
>> 1057:     private class HandshakeListener implements HandshakeCompletedListener {
>> 1058: 
>> 1059:         private CompletableFuture<X509Certificate> tlsHandshakeCompleted =
> 
> `tlsHandshakeCompleted` could be made `final`

Thank you. Made it final

-------------

PR: https://git.openjdk.java.net/jdk/pull/2085

From redestad at openjdk.java.net  Thu Jan 21 20:28:11 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 21 Jan 2021 20:28:11 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v10]
In-Reply-To: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
Message-ID: <WdF2lWJPBHX0tn_LWuCiTn0As5SvbJq3i2dHBAzuTRI=.cab023e1-5340-4eee-ab49-aa48d6e970c2@github.com>

> The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.
> 
> This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.
> 
> Microbenchmark results:
> Baseline
> 
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
> decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op
> 
> Patched:
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
> decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op
> 
> Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.
> 
> Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.
> 
> Testing: tier1-4

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Simplify getBytes -> encode

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2102/files
  - new: https://git.openjdk.java.net/jdk/pull/2102/files/a45b761d..6808d4db

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2102&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2102&range=08-09

  Stats: 21 lines in 1 file changed: 6 ins; 13 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2102.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2102/head:pull/2102

PR: https://git.openjdk.java.net/jdk/pull/2102

From redestad at openjdk.java.net  Thu Jan 21 20:48:33 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 21 Jan 2021 20:48:33 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v11]
In-Reply-To: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
Message-ID: <VtYGy4WCnWMXlZ50ojpfszWmkegeAnCI1tjTTNB-QQM=.1f6ff90b-a758-4f7e-bd92-bcd752d4db8e@github.com>

> The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.
> 
> This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.
> 
> Microbenchmark results:
> Baseline
> 
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
> decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op
> 
> Patched:
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
> decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op
> 
> Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.
> 
> Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.
> 
> Testing: tier1-4

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Reduce code duplication in getBytes/getBytesNoRepl

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2102/files
  - new: https://git.openjdk.java.net/jdk/pull/2102/files/6808d4db..2143cb3e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2102&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2102&range=09-10

  Stats: 167 lines in 1 file changed: 66 ins; 93 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2102.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2102/head:pull/2102

PR: https://git.openjdk.java.net/jdk/pull/2102

From bpb at openjdk.java.net  Thu Jan 21 21:59:46 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 21 Jan 2021 21:59:46 GMT
Subject: Integrated: 8259943: FileDescriptor.close0 does not handle EINTR
In-Reply-To: <8Svc34lGaB1DE4J_4yHgouxc6pnd4sSaHa3lzfRVy4s=.37995476-c5a3-476c-9a0b-2c98af07e47f@github.com>
References: <8Svc34lGaB1DE4J_4yHgouxc6pnd4sSaHa3lzfRVy4s=.37995476-c5a3-476c-9a0b-2c98af07e47f@github.com>
Message-ID: <h9-aTCvjFQPp2_XsKZ2JjgxfKd-E-aaUgkQcMiiIubc=.15da9a43-872f-4b8a-a252-eeeb2511c1d7@github.com>

On Wed, 20 Jan 2021 23:01:19 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this small change to handle `EINTR` from `close()` in `fileDescriptorClose()`. The function `handleGetLength()` is also changed to handle `EINTR` from `fstat64()` to match other uses of `fstat64()` in the file.

This pull request has now been integrated.

Changeset: 2f47c39a
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2f47c39a
Stats:     15 lines in 1 file changed: 11 ins; 0 del; 4 mod

8259943: FileDescriptor.close0 does not handle EINTR

Reviewed-by: naoto, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/2173

From rriggs at openjdk.java.net  Thu Jan 21 22:27:53 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 21 Jan 2021 22:27:53 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v11]
In-Reply-To: <VtYGy4WCnWMXlZ50ojpfszWmkegeAnCI1tjTTNB-QQM=.1f6ff90b-a758-4f7e-bd92-bcd752d4db8e@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
 <VtYGy4WCnWMXlZ50ojpfszWmkegeAnCI1tjTTNB-QQM=.1f6ff90b-a758-4f7e-bd92-bcd752d4db8e@github.com>
Message-ID: <ojlbPGC07Fu-SBtnETfuy3F7zYSNb_hH4Hn26Q9clu0=.1e8b417c-ce2e-42dd-9f84-5a0ba363670b@github.com>

On Thu, 21 Jan 2021 20:48:33 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.
>> 
>> This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.
>> 
>> Microbenchmark results:
>> Baseline
>> 
>> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
>> decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
>> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
>> decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
>> decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
>> decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
>> decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
>> decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
>> decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
>> decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
>> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op
>> 
>> Patched:
>> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
>> decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
>> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
>> decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
>> decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
>> decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
>> decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
>> decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
>> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op
>> 
>> Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.
>> 
>> Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.
>> 
>> Testing: tier1-4
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce code duplication in getBytes/getBytesNoRepl

This looks very good. Thanks for the extra refactoring and consolidating of code.

src/java.base/share/classes/java/lang/StringCoding.java line 42:

> 40:     static final Charset ISO_8859_1 = sun.nio.cs.ISO_8859_1.INSTANCE;
> 41:     static final Charset US_ASCII = sun.nio.cs.US_ASCII.INSTANCE;
> 42:     static final Charset UTF_8 = sun.nio.cs.UTF_8.INSTANCE;

These could move to String also, if there is a benefit them being local.
Otherwise, the uses in String could refer directly to the INSTANCEs in the sun.nio.cs... classes.

src/java.base/share/classes/java/lang/StringCoding.java line 49:

> 47:      *  @param msg  message to print
> 48:      */
> 49:     private static native void err(String msg);

A separate cleanup could remove this unused method and the corresponding native code in StringCoding.c.

src/java.base/share/classes/java/lang/StringCoding.java line 64:

> 62:     public static int implEncodeISOArray(byte[] sa, int sp,
> 63:                                           byte[] da, int dp, int len) {
> 64:         int i = 0;

As a separate cleanup... 
If there isn't any value to these intrinsics being in StringCoder, they could also move to String
with the corresponding intrinsic references.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2102

From naoto at openjdk.java.net  Thu Jan 21 22:47:53 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 21 Jan 2021 22:47:53 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v11]
In-Reply-To: <VtYGy4WCnWMXlZ50ojpfszWmkegeAnCI1tjTTNB-QQM=.1f6ff90b-a758-4f7e-bd92-bcd752d4db8e@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
 <VtYGy4WCnWMXlZ50ojpfszWmkegeAnCI1tjTTNB-QQM=.1f6ff90b-a758-4f7e-bd92-bcd752d4db8e@github.com>
Message-ID: <-KNNjtDLxm4Lbkl-gYz5X4bA6Z8r_eyYl1_WmW1GC5I=.aacfeca1-6ee7-4299-a3dd-8d990c499ada@github.com>

On Thu, 21 Jan 2021 20:48:33 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.
>> 
>> This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.
>> 
>> Microbenchmark results:
>> Baseline
>> 
>> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
>> decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
>> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
>> decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
>> decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
>> decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
>> decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
>> decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
>> decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
>> decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
>> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op
>> 
>> Patched:
>> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
>> decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
>> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
>> decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
>> decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
>> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
>> decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
>> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
>> decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
>> decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
>> decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
>> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
>> decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
>> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op
>> 
>> Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.
>> 
>> Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.
>> 
>> Testing: tier1-4
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce code duplication in getBytes/getBytesNoRepl

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2102

From mchung at openjdk.java.net  Thu Jan 21 23:10:34 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 21 Jan 2021 23:10:34 GMT
Subject: RFR: 8259922 MethodHandles.collectArguments does not follow its
 documentation
In-Reply-To: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com>
References: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com>
Message-ID: <sv8j2NtBYgCXbCy_ITK88S8xSyEC6L40UGX-v9DdZ8Q=.c6482ff9-4514-401c-a59e-e7ae97562e4f@github.com>

On Wed, 20 Jan 2021 18:29:00 GMT, Johannes Kuhn <github.com+652983+DasBrain at openjdk.org> wrote:

> Add explicit range check to `MethodHandles.collectArgumentsCheck`.  
> Added test case that exercises all cases.
> 
> This is a behavioral change, from throwing an unspecified exception to throwing an IllegalArgumentException, as specified.  
> No spec change needed, as the IllegalArgumentException is already specified to be thrown in those cases.
> 
> Feel free to suggest a better place for the tests.

Thanks for fixing this.  I can sponsor this for you.

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 5753:

> 5751:         if (pos < 0 || pos > targetType.parameterCount() ||
> 5752:                 // a filter with void return is fine at pos == targetType.parameterCount();
> 5753:                 (rtype != void.class && pos >= targetType.parameterCount())) {

Nit: adding `rtype == void.class` may make it clearer than the comment as that matches what `@throws` describes

Suggestion:

        if (pos < 0 || (rtype == void.class && pos > targetType.parameterCount()) ||
                             (rtype != void.class && pos >= targetType.parameterCount())) {

test/jdk/java/lang/invoke/8259922/TestMethodHandlesCollectArgs.java line 37:

> 35: import static org.testng.Assert.*;
> 36: 
> 37: public class TestMethodHandlesCollectArgs {

I suggest to rename this test in `test/jdk/java/lang/invoke/MethodHandlesCollectArgsTest.java` matching existing convention and `CollectArgsTest.java` is also fine with me.  The bug ID is already in @bug and I find the directory with bug ID adds noise.

test/jdk/java/lang/invoke/8259922/TestMethodHandlesCollectArgs.java line 51:

> 49:             // expected - pass
> 50:         }
> 51:     }

This can be simplified:

@Test(expected = IllegalArgumentException.class)
public void nonVoidIllegalPos() {
    MethodHandles.collectArguments(TARGET, 2, FILTER_INT);
}

Same applies to other negative test cases.   I suggest to put all negative test cases in a data provider and test them in one single `@Test` like this:
`@Test(dataProvider="illegalPos", expected = IllegalArgumentException.class)`

with the index and filter as the method argument.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2171

From redestad at openjdk.java.net  Thu Jan 21 23:20:57 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 21 Jan 2021 23:20:57 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v12]
In-Reply-To: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
Message-ID: <PrkI2wIs5loeIVz1TpSe07V6ZSGjvI0pDThEhO-MLQU=.1e6419fb-b0a5-438d-8cfe-60bd1e0abc29@github.com>

> The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.
> 
> This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.
> 
> Microbenchmark results:
> Baseline
> 
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
> decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op
> 
> Patched:
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
> decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op
> 
> Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.
> 
> Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.
> 
> Testing: tier1-4

Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:

 - Logic error in exception handling in encodeWithEncoder
 - Remove StringCoding Charset constants

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2102/files
  - new: https://git.openjdk.java.net/jdk/pull/2102/files/2143cb3e..14928bfd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2102&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2102&range=10-11

  Stats: 24 lines in 2 files changed: 0 ins; 7 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2102.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2102/head:pull/2102

PR: https://git.openjdk.java.net/jdk/pull/2102

From github.com+652983+dasbrain at openjdk.java.net  Thu Jan 21 23:25:42 2021
From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn)
Date: Thu, 21 Jan 2021 23:25:42 GMT
Subject: RFR: 8259922 MethodHandles.collectArguments does not follow its
 documentation
In-Reply-To: <sv8j2NtBYgCXbCy_ITK88S8xSyEC6L40UGX-v9DdZ8Q=.c6482ff9-4514-401c-a59e-e7ae97562e4f@github.com>
References: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com>
 <sv8j2NtBYgCXbCy_ITK88S8xSyEC6L40UGX-v9DdZ8Q=.c6482ff9-4514-401c-a59e-e7ae97562e4f@github.com>
Message-ID: <OfMEUrmUfq2g2F8N0O3gxCzuyvA0flqjXl0rbwQIi5Y=.7af47a7f-4872-483b-8ec8-5c85913f95bf@github.com>

On Thu, 21 Jan 2021 22:54:56 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Add explicit range check to `MethodHandles.collectArgumentsCheck`.  
>> Added test case that exercises all cases.
>> 
>> This is a behavioral change, from throwing an unspecified exception to throwing an IllegalArgumentException, as specified.  
>> No spec change needed, as the IllegalArgumentException is already specified to be thrown in those cases.
>> 
>> Feel free to suggest a better place for the tests.
>
> test/jdk/java/lang/invoke/8259922/TestMethodHandlesCollectArgs.java line 37:
> 
>> 35: import static org.testng.Assert.*;
>> 36: 
>> 37: public class TestMethodHandlesCollectArgs {
> 
> I suggest to rename this test in `test/jdk/java/lang/invoke/MethodHandlesCollectArgsTest.java` matching existing convention and `CollectArgsTest.java` is also fine with me.  The bug ID is already in @bug and I find the directory with bug ID adds noise.

Yeah, still learning where to put tests.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2171

From jiefu at openjdk.java.net  Thu Jan 21 23:40:28 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 21 Jan 2021 23:40:28 GMT
Subject: RFR: 8259925: [Vector API] Unreasonable IndexOutOfBoundsException
 message when length < vlen
In-Reply-To: <oGnSUOfY151JLoMo2ITtc6FRLOQ-210RjUl-nGnhBgo=.36a91aa9-de48-4818-aea7-a9ba99a506e5@github.com>
References: <IXlGGauVhUjxPJXm8CjZ0Eo4-ySUttJ_EqYpxiW7p8E=.32dc9082-78ad-4407-a6a2-3652dfef8a4c@github.com>
 <LzL6761_WZOicSWpwUGbYjnnWKlqQPSLtMqLKp5Q_ls=.343834be-ef22-4bc1-91c5-c8388627f6f5@github.com>
 <ZAH7vzOKC5VPi7V6ElL55VxQsgA4AAuVUOH4v8u4QfY=.4cb1b26e-6c19-4083-8495-2d046efa3ddd@github.com>
 <wc6FWksUAR7mY0S_XQox0UgcR9DwpOswrqNRpAZrnDI=.e7327508-a423-4c35-854e-02a55c0aa971@github.com>
 <7fzq6Na3zlPQIp8-ZRytFFDHLU58CaWon0tNEzww4yc=.e4e11ac0-4906-4da0-af83-c3ac8de1f957@github.com>
 <oGnSUOfY151JLoMo2ITtc6FRLOQ-210RjUl-nGnhBgo=.36a91aa9-de48-4818-aea7-a9ba99a506e5@github.com>
Message-ID: <za5-vrdk_-u3XpzdXSLFiFaYGjMy6F-7WndK3EZZvK8=.976412cb-a359-415b-8f31-4b0ad5e58cf7@github.com>

On Thu, 21 Jan 2021 16:54:36 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> The intrinsic enables C2 to more reliably elide bounds checks. I don't know the exact details but at a high-level it transforms signed values into unsigned values (and therefore the signed comparisons become unsigned comparisons), which helps C2 remove checks when there is a dominating check of, for example, an upper loop bound.

OK.
Now I can understand what you are worrying about.
Thanks for your clarification.

> You say "the intrinsified Objects.checkIndex seems to generate more code than inlined if-statements". Can you present some examples of Java code and the corresponding C2 generated assembler where this happens?

Will do it later.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2127

From github.com+652983+dasbrain at openjdk.java.net  Fri Jan 22 00:33:16 2021
From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn)
Date: Fri, 22 Jan 2021 00:33:16 GMT
Subject: RFR: 8259922 MethodHandles.collectArguments does not follow its
 documentation [v2]
In-Reply-To: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com>
References: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com>
Message-ID: <9b-7_CwHqXw-s72aTwKSO9wSwm9wP-vUG4bGtjIad3w=.69638c8d-8d29-4f5c-bad7-f1643944c17f@github.com>

> Add explicit range check to `MethodHandles.collectArgumentsCheck`.  
> Added test case that exercises all cases.
> 
> This is a behavioral change, from throwing an unspecified exception to throwing an IllegalArgumentException, as specified.  
> No spec change needed, as the IllegalArgumentException is already specified to be thrown in those cases.
> 
> Feel free to suggest a better place for the tests.

Johannes Kuhn has updated the pull request incrementally with one additional commit since the last revision:

  Implement suggestions by Mandy Chung.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2171/files
  - new: https://git.openjdk.java.net/jdk/pull/2171/files/4f74e2df..f01fefaa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2171&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2171&range=00-01

  Stats: 179 lines in 3 files changed: 82 ins; 95 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2171.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2171/head:pull/2171

PR: https://git.openjdk.java.net/jdk/pull/2171

From mchung at openjdk.java.net  Fri Jan 22 00:47:49 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 22 Jan 2021 00:47:49 GMT
Subject: RFR: 8259922 MethodHandles.collectArguments does not follow its
 documentation [v2]
In-Reply-To: <9b-7_CwHqXw-s72aTwKSO9wSwm9wP-vUG4bGtjIad3w=.69638c8d-8d29-4f5c-bad7-f1643944c17f@github.com>
References: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com>
 <9b-7_CwHqXw-s72aTwKSO9wSwm9wP-vUG4bGtjIad3w=.69638c8d-8d29-4f5c-bad7-f1643944c17f@github.com>
Message-ID: <R7aAtOJzFrI6oSr1ljZRzw-j7vdN7xuNVAGLc5aECF0=.c88b38ae-0349-4523-9542-9bff473e0fa7@github.com>

On Fri, 22 Jan 2021 00:33:16 GMT, Johannes Kuhn <github.com+652983+DasBrain at openjdk.org> wrote:

>> Add explicit range check to `MethodHandles.collectArgumentsCheck`.  
>> Added test case that exercises all cases.
>> 
>> This is a behavioral change, from throwing an unspecified exception to throwing an IllegalArgumentException, as specified.  
>> No spec change needed, as the IllegalArgumentException is already specified to be thrown in those cases.
>> 
>> Feel free to suggest a better place for the tests.
>
> Johannes Kuhn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement suggestions by Mandy Chung.

Looks good.  What tests have you ran?

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2171

From github.com+652983+dasbrain at openjdk.java.net  Fri Jan 22 00:54:15 2021
From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn)
Date: Fri, 22 Jan 2021 00:54:15 GMT
Subject: RFR: 8259922 MethodHandles.collectArguments does not follow its
 documentation [v2]
In-Reply-To: <R7aAtOJzFrI6oSr1ljZRzw-j7vdN7xuNVAGLc5aECF0=.c88b38ae-0349-4523-9542-9bff473e0fa7@github.com>
References: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com>
 <9b-7_CwHqXw-s72aTwKSO9wSwm9wP-vUG4bGtjIad3w=.69638c8d-8d29-4f5c-bad7-f1643944c17f@github.com>
 <R7aAtOJzFrI6oSr1ljZRzw-j7vdN7xuNVAGLc5aECF0=.c88b38ae-0349-4523-9542-9bff473e0fa7@github.com>
Message-ID: <c58E9tqyRVTLl1flHCCEoaVKa3KKkfmItBgYrSHE5-M=.fdb81f12-e0e2-45c0-935d-d8571a2091ec@github.com>

On Fri, 22 Jan 2021 00:44:12 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Johannes Kuhn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement suggestions by Mandy Chung.
>
> Looks good.  What tests have you ran?

On the latest commit, only my own test.  
On the previous commit (4f74e2d) I did run the full tier1.

Currently a full test tier1 run on my machine and github actions is in progress.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2171

From mli at openjdk.java.net  Fri Jan 22 03:07:15 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 22 Jan 2021 03:07:15 GMT
Subject: RFR: JDK-8260273: DataOutputStream writeChars optimization
Message-ID: <ve8NNCTjABCKaUb0ZcpBC2InXNxFSdi88k_zSdLIk6M=.14e89b4a-492e-4b68-bd3e-ab22f2d73ea4@github.com>

this is minor optimization following JDK-8254078.
based on my tests with jmh, it has better performance when apply following patch:

diff --git a/src/java.base/share/classes/java/io/DataOutputStream.java b/src/java.base/share/classes/java/io/DataOutputStream.java
index 9a9a687403c..4ea497fc7c0 100644
--- a/src/java.base/share/classes/java/io/DataOutputStream.java
+++ b/src/java.base/share/classes/java/io/DataOutputStream.java
@@ -300,8 +300,9 @@ public class DataOutputStream extends FilterOutputStream implements DataOutput {
         int len = s.length();
         for (int i = 0 ; i < len ; i++) {
             int v = s.charAt(i);
- out.write((v >>> 8) & 0xFF);
- out.write((v >>> 0) & 0xFF);
+ writeBuffer[0] = (byte)(v >>> 8);
+ writeBuffer[1] = (byte)(v >>> 0);
+ out.write(writeBuffer, 0, 2);
         }
         incCount(len * 2);
     }

Basically, it has better performance when apply above patch:

// without writeChars optimization patch, (-XX:-UseBiasedLocking)
Benchmark (basicType) (size) Mode Cnt Score Error Units
DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 115.208 ? 0.327 us/op
DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 276.795 ? 0.449 us/op
DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 12356.969 ? 22.427 us/op

// with writeChars optimization patch, (-XX:-UseBiasedLocking)
Benchmark (basicType) (size) Mode Cnt Score Error Units
DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 133.706 ? 0.274 us/op
DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 130.979 ? 0.155 us/op
DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 6814.272 ? 52.770 us/op


// without writeChars optimization patch, (-XX:+UseBiasedLocking)
Benchmark (basicType) (size) Mode Cnt Score Error Units
DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 130.367 ? 8.759 us/op
DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 37.559 ? 0.059 us/op
DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 12385.030 ? 376.560 us/op

// with writeChars optimization patch, (-XX:+UseBiasedLocking)
Benchmark (basicType) (size) Mode Cnt Score Error Units
DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 45.494 ? 7.018 us/op
DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 33.015 ? 0.349 us/op
DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 6845.549 ? 38.712 us/op

-------------

Commit messages:
 - JDK-8260273: DataOutputStream writeChars optimization

Changes: https://git.openjdk.java.net/jdk/pull/2190/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2190&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260273
  Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2190.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2190/head:pull/2190

PR: https://git.openjdk.java.net/jdk/pull/2190

From github.com+652983+dasbrain at openjdk.java.net  Fri Jan 22 03:26:44 2021
From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn)
Date: Fri, 22 Jan 2021 03:26:44 GMT
Subject: RFR: 8259922 MethodHandles.collectArguments does not throw IAE if
 pos is outside the arity range [v2]
In-Reply-To: <c58E9tqyRVTLl1flHCCEoaVKa3KKkfmItBgYrSHE5-M=.fdb81f12-e0e2-45c0-935d-d8571a2091ec@github.com>
References: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com>
 <9b-7_CwHqXw-s72aTwKSO9wSwm9wP-vUG4bGtjIad3w=.69638c8d-8d29-4f5c-bad7-f1643944c17f@github.com>
 <R7aAtOJzFrI6oSr1ljZRzw-j7vdN7xuNVAGLc5aECF0=.c88b38ae-0349-4523-9542-9bff473e0fa7@github.com>
 <c58E9tqyRVTLl1flHCCEoaVKa3KKkfmItBgYrSHE5-M=.fdb81f12-e0e2-45c0-935d-d8571a2091ec@github.com>
Message-ID: <VFKpfLaCYcZF_6Tp_XUdg_QeD6UBNJmQKW98iJtNfsQ=.c15ae6e6-e94f-4bc8-be85-d58f181d0e89@github.com>

On Fri, 22 Jan 2021 00:48:51 GMT, Johannes Kuhn <github.com+652983+DasBrain at openjdk.org> wrote:

>> Looks good.  What tests have you ran?
>
> On the latest commit, only my own test.  
> On the previous commit (4f74e2d) I did run the full tier1.
> 
> Currently a full test tier1 run on my machine and github actions is in progress.

Tests did run successfully on my machine (win 64) and github actions.
Let me know if there should be additional tests that I should run.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2171

From smarks at openjdk.java.net  Fri Jan 22 05:54:20 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 22 Jan 2021 05:54:20 GMT
Subject: RFR: 8246788: ZoneRules invariants can be broken
Message-ID: <kZbfHIUgpUmMbulGDG3FUrAc188KfDkfGv_Y21csUOg=.7208b820-e948-4c07-905a-7db91f199383@github.com>

Tighten up argument checking in constructor.

-------------

Commit messages:
 - 8246788: ZoneRules invariants can be broken

Changes: https://git.openjdk.java.net/jdk/pull/2191/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2191&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8246788
  Stats: 90 lines in 2 files changed: 87 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2191.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2191/head:pull/2191

PR: https://git.openjdk.java.net/jdk/pull/2191

From aefimov at openjdk.java.net  Fri Jan 22 11:25:43 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Fri, 22 Jan 2021 11:25:43 GMT
Subject: RFR: 8259707: LDAP channel binding does not work with StartTLS
 extension [v3]
In-Reply-To: <RS7sqOZdQNl4TA7DX7uuR0tczwqohihtzuq1kOrSiYU=.761cbafa-382d-44e7-a27b-4eba96e7f437@github.com>
References: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
 <RS7sqOZdQNl4TA7DX7uuR0tczwqohihtzuq1kOrSiYU=.761cbafa-382d-44e7-a27b-4eba96e7f437@github.com>
Message-ID: <XYtx6R21QUO6_EKuzFUC0r2bGbAr78v-jfkZLxSKhwg=.9fdb97a8-7aa6-4c48-9e99-64391f31d222@github.com>

On Thu, 21 Jan 2021 19:57:04 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS Extension.
>> Test from the bug report and jtreg javax/naming tests are passed.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments and volatile modifier for tlsHandshakeListener

Hi Alexey,
The latest changes look good to me.
Thanks for handling a case of sequential StartTLS requests on one LDAP context and running the modified test. I've also checked that existing LDAP tests shows no failures with the proposed changed.
You might also want to update last modification years to `2021` in both files.

-------------

Marked as reviewed by aefimov (Committer).

PR: https://git.openjdk.java.net/jdk/pull/2085

From redestad at openjdk.java.net  Fri Jan 22 11:30:57 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 22 Jan 2021 11:30:57 GMT
Subject: RFR: 8259842: Remove Result cache from StringCoding [v11]
In-Reply-To: <-KNNjtDLxm4Lbkl-gYz5X4bA6Z8r_eyYl1_WmW1GC5I=.aacfeca1-6ee7-4299-a3dd-8d990c499ada@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
 <VtYGy4WCnWMXlZ50ojpfszWmkegeAnCI1tjTTNB-QQM=.1f6ff90b-a758-4f7e-bd92-bcd752d4db8e@github.com>
 <-KNNjtDLxm4Lbkl-gYz5X4bA6Z8r_eyYl1_WmW1GC5I=.aacfeca1-6ee7-4299-a3dd-8d990c499ada@github.com>
Message-ID: <_2dHxs5Jp9XjiEpVUClHspx5fi5ZJMfxW7kl6Q2SV9Q=.0b4879b7-edd2-4885-90be-414353034582@github.com>

On Thu, 21 Jan 2021 22:43:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reduce code duplication in getBytes/getBytesNoRepl
>
> Marked as reviewed by naoto (Reviewer).

Passed testing tiers 1-4

-------------

PR: https://git.openjdk.java.net/jdk/pull/2102

From redestad at openjdk.java.net  Fri Jan 22 11:31:00 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 22 Jan 2021 11:31:00 GMT
Subject: Integrated: 8259842: Remove Result cache from StringCoding
In-Reply-To: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
References: <Mf3GSueZkjIaqrHsSvtJEF0yajZVMtpHuMqCkbDsgJs=.cc22e227-f602-4f1d-9b21-8f4f890a20a6@github.com>
Message-ID: <WG87QndR1XkkeHrckziE-_gOOvBXcLiKw4ei4cbJztg=.da1033df-eb13-464d-9b8b-92143701348f@github.com>

On Fri, 15 Jan 2021 14:33:19 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`.
> 
> This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache.
> 
> Microbenchmark results:
> Baseline
> 
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  193.043 ?  8.207   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  164.580 ?  6.514   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  328.370 ? 18.420   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  328.870 ? 20.056   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  232.020 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  193.603 ? 12.305   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  209.454 ?  9.040   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  188.234 ?  7.533   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  399.463 ? 12.437   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.003    B/op
> decodeCharsetName                                           MS932  avgt   15  358.839 ? 15.385   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.017 ?  0.003    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  162.570 ?  7.090   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  316.081 ? 11.101   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.002    B/op
> 
> Patched:
> Benchmark                                           (charsetName)  Mode  Cnt    Score    Error   Units
> decodeCharset                                            US-ASCII  avgt   15  159.153 ?  6.082   ns/op
> decodeCharset:?gc.alloc.rate.norm                        US-ASCII  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                          ISO-8859-1  avgt   15  134.433 ?  6.203   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-1  avgt   15  112.009 ?  0.001    B/op
> decodeCharset                                               UTF-8  avgt   15  297.234 ? 21.654   ns/op
> decodeCharset:?gc.alloc.rate.norm                           UTF-8  avgt   15  224.019 ?  0.002    B/op
> decodeCharset                                               MS932  avgt   15  311.583 ? 16.445   ns/op
> decodeCharset:?gc.alloc.rate.norm                           MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharset                                          ISO-8859-6  avgt   15  156.216 ?  6.522   ns/op
> decodeCharset:?gc.alloc.rate.norm                      ISO-8859-6  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                        US-ASCII  avgt   15  180.752 ?  9.411   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                    US-ASCII  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                      ISO-8859-1  avgt   15  156.170 ?  8.003   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-1  avgt   15  112.010 ?  0.001    B/op
> decodeCharsetName                                           UTF-8  avgt   15  370.337 ? 22.199   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       UTF-8  avgt   15  224.019 ?  0.001    B/op
> decodeCharsetName                                           MS932  avgt   15  312.589 ? 15.067   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                       MS932  avgt   15  208.018 ?  0.002    B/op
> decodeCharsetName                                      ISO-8859-6  avgt   15  173.205 ?  9.647   ns/op
> decodeCharsetName:?gc.alloc.rate.norm                  ISO-8859-6  avgt   15  112.009 ?  0.001    B/op
> decodeDefault                                                 N/A  avgt   15  303.459 ? 16.452   ns/op
> decodeDefault:?gc.alloc.rate.norm                             N/A  avgt   15  224.019 ?  0.001    B/op
> 
> Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board.
> 
> Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that.
> 
> Testing: tier1-4

This pull request has now been integrated.

Changeset: 58ceb254
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/58ceb254
Stats:     2093 lines in 5 files changed: 971 ins; 1093 del; 29 mod

8259842: Remove Result cache from StringCoding

Reviewed-by: naoto, plevart, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/2102

From jiefu at openjdk.java.net  Fri Jan 22 13:00:40 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 22 Jan 2021 13:00:40 GMT
Subject: RFR: 8259925: [Vector API] Unreasonable IndexOutOfBoundsException
 message when length < vlen
In-Reply-To: <oGnSUOfY151JLoMo2ITtc6FRLOQ-210RjUl-nGnhBgo=.36a91aa9-de48-4818-aea7-a9ba99a506e5@github.com>
References: <IXlGGauVhUjxPJXm8CjZ0Eo4-ySUttJ_EqYpxiW7p8E=.32dc9082-78ad-4407-a6a2-3652dfef8a4c@github.com>
 <LzL6761_WZOicSWpwUGbYjnnWKlqQPSLtMqLKp5Q_ls=.343834be-ef22-4bc1-91c5-c8388627f6f5@github.com>
 <ZAH7vzOKC5VPi7V6ElL55VxQsgA4AAuVUOH4v8u4QfY=.4cb1b26e-6c19-4083-8495-2d046efa3ddd@github.com>
 <wc6FWksUAR7mY0S_XQox0UgcR9DwpOswrqNRpAZrnDI=.e7327508-a423-4c35-854e-02a55c0aa971@github.com>
 <7fzq6Na3zlPQIp8-ZRytFFDHLU58CaWon0tNEzww4yc=.e4e11ac0-4906-4da0-af83-c3ac8de1f957@github.com>
 <oGnSUOfY151JLoMo2ITtc6FRLOQ-210RjUl-nGnhBgo=.36a91aa9-de48-4818-aea7-a9ba99a506e5@github.com>
Message-ID: <hI6Lt8iLHheDuPluyGPnxUPNSXMpe6XbRWZU3l6jxBQ=.e911e7b8-a465-467a-9cde-d1e96cb1c4be@github.com>

On Thu, 21 Jan 2021 16:54:36 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>>> Unfortunately it is still problematic because you have replaced the intrinsic check (that performed by `Object.checksIndex`, or more specifically [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/util/Preconditions.java#L261)).
>>> 
>>> Further, you have replaced the bounds check options, in place for experimentation. We are not ready yet to collapse our options, further analysis is required as bounds checks can be very sensitive in C2.
>>> 
>>> I would be open to you adding a third case, so that you can analyze the performance without perturbing the default behavior. I suspect the correct fix is to make intrinsic `Objects.checkFromIndexSize` in a similar manner to `Object.checksIndex`.
>> 
>> Hi @PaulSandoz ,
>> 
>> Thanks for your kind review and comments.
>> 
>> To be honest, I didn't get your first point.
>> As for the example above, the intrinsified Objects.checkIndex seems to generate more code than inlined if-statements.
>> So I'm confused why it's a problem to replace the intrinsic check.
>> Did you mean an intrinsic is always (or for most cases) better than non-intrinc or inlined if-statements?
>> And why?
>> 
>> Could you please make it more clearer to us?
>> Thanks.
>
> The intrinsic enables C2 to more reliably elide bounds checks. I don't know the exact details but at a high-level it transforms signed values into unsigned values (and therefore the signed comparisons become unsigned comparisons), which helps C2 remove checks when there is a dominating check of, for example, an upper loop bound.
> 
> You say "the intrinsified Objects.checkIndex seems to generate more code than inlined if-statements". Can you present some examples of Java code and the corresponding C2 generated assembler where this happens?

Hi @PaulSandoz ,

I will show you the assembly code next week since it is already Friday night now.

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2127

From abakhtin at openjdk.java.net  Fri Jan 22 14:42:10 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 22 Jan 2021 14:42:10 GMT
Subject: RFR: 8259707: LDAP channel binding does not work with StartTLS
 extension [v4]
In-Reply-To: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
References: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
Message-ID: <WZtwqQ5ZuAYnvma_rB1OnqPWOqhpZsP1Ill18-1WHaU=.a839644c-9884-461f-a426-d7844f9f8a03@github.com>

> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS Extension.
> Test from the bug report and jtreg javax/naming tests are passed.

Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2085/files
  - new: https://git.openjdk.java.net/jdk/pull/2085/files/e3bf8c36..40447456

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2085&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2085&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2085.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2085/head:pull/2085

PR: https://git.openjdk.java.net/jdk/pull/2085

From rriggs at openjdk.java.net  Fri Jan 22 14:44:38 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 22 Jan 2021 14:44:38 GMT
Subject: RFR: 8246788: ZoneRules invariants can be broken
In-Reply-To: <kZbfHIUgpUmMbulGDG3FUrAc188KfDkfGv_Y21csUOg=.7208b820-e948-4c07-905a-7db91f199383@github.com>
References: <kZbfHIUgpUmMbulGDG3FUrAc188KfDkfGv_Y21csUOg=.7208b820-e948-4c07-905a-7db91f199383@github.com>
Message-ID: <gNzR-Dgw0nc-LH0ccTTorNa86NiGb7uKsK8AAclc9kE=.9da20868-a7fa-4a3b-a8c5-1f3d799c8749@github.com>

On Fri, 22 Jan 2021 05:39:55 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Tighten up argument checking in constructor.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2191

From dfuchs at openjdk.java.net  Fri Jan 22 14:50:56 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 22 Jan 2021 14:50:56 GMT
Subject: RFR: 8246788: ZoneRules invariants can be broken
In-Reply-To: <kZbfHIUgpUmMbulGDG3FUrAc188KfDkfGv_Y21csUOg=.7208b820-e948-4c07-905a-7db91f199383@github.com>
References: <kZbfHIUgpUmMbulGDG3FUrAc188KfDkfGv_Y21csUOg=.7208b820-e948-4c07-905a-7db91f199383@github.com>
Message-ID: <ihP-QLU5Ia8o-VXMUAgC7RRWBE-FBkcpSkcpTlR_LyE=.dd726c5e-62f3-4efa-a1ee-fb78777e307e@github.com>

On Fri, 22 Jan 2021 05:39:55 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Tighten up argument checking in constructor.

src/java.base/share/classes/java/time/zone/ZoneRules.java line 263:

> 261:         // last rules
> 262:         Object[] temp = lastRules.toArray();
> 263:         ZoneOffsetTransitionRule[] rulesArray = Arrays.copyOf(temp, temp.length, ZoneOffsetTransitionRule[].class);

LGTM. Could be replaced by:

ZoneOffsetTransitionRule[] rulesArray = (ZoneOffsetTransitionRule[])lastRules.toArray(new ZoneOffsetTransitionRule[0]).clone();

if you wanted - but what you currently have is good for me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2191

From rriggs at openjdk.java.net  Fri Jan 22 14:51:47 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 22 Jan 2021 14:51:47 GMT
Subject: RFR: JDK-8260273: DataOutputStream writeChars optimization
In-Reply-To: <ve8NNCTjABCKaUb0ZcpBC2InXNxFSdi88k_zSdLIk6M=.14e89b4a-492e-4b68-bd3e-ab22f2d73ea4@github.com>
References: <ve8NNCTjABCKaUb0ZcpBC2InXNxFSdi88k_zSdLIk6M=.14e89b4a-492e-4b68-bd3e-ab22f2d73ea4@github.com>
Message-ID: <93ZeYBXME1tQzh38IPcyDK89mBmWils_poPCX9pUsg8=.45f4725e-660b-420a-9120-ebb6918490ed@github.com>

On Fri, 22 Jan 2021 02:57:36 GMT, Hamlin Li <mli at openjdk.org> wrote:

> this is minor optimization following JDK-8254078.
> based on my tests with jmh, it has better performance when apply following patch:
> 
> diff --git a/src/java.base/share/classes/java/io/DataOutputStream.java b/src/java.base/share/classes/java/io/DataOutputStream.java
> index 9a9a687403c..4ea497fc7c0 100644
> --- a/src/java.base/share/classes/java/io/DataOutputStream.java
> +++ b/src/java.base/share/classes/java/io/DataOutputStream.java
> @@ -300,8 +300,9 @@ public class DataOutputStream extends FilterOutputStream implements DataOutput {
>          int len = s.length();
>          for (int i = 0 ; i < len ; i++) {
>              int v = s.charAt(i);
> - out.write((v >>> 8) & 0xFF);
> - out.write((v >>> 0) & 0xFF);
> + writeBuffer[0] = (byte)(v >>> 8);
> + writeBuffer[1] = (byte)(v >>> 0);
> + out.write(writeBuffer, 0, 2);
>          }
>          incCount(len * 2);
>      }
> 
> Basically, it has better performance when apply above patch:
> 
> // without writeChars optimization patch, (-XX:-UseBiasedLocking)
> Benchmark (basicType) (size) Mode Cnt Score Error Units
> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 115.208 ? 0.327 us/op
> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 276.795 ? 0.449 us/op
> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 12356.969 ? 22.427 us/op
> 
> // with writeChars optimization patch, (-XX:-UseBiasedLocking)
> Benchmark (basicType) (size) Mode Cnt Score Error Units
> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 133.706 ? 0.274 us/op
> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 130.979 ? 0.155 us/op
> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 6814.272 ? 52.770 us/op
> 
> 
> // without writeChars optimization patch, (-XX:+UseBiasedLocking)
> Benchmark (basicType) (size) Mode Cnt Score Error Units
> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 130.367 ? 8.759 us/op
> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 37.559 ? 0.059 us/op
> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 12385.030 ? 376.560 us/op
> 
> // with writeChars optimization patch, (-XX:+UseBiasedLocking)
> Benchmark (basicType) (size) Mode Cnt Score Error Units
> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 45.494 ? 7.018 us/op
> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 33.015 ? 0.349 us/op
> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 6845.549 ? 38.712 us/op

Thanks, this should have been included in the 8254078.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2190

From aefimov at openjdk.java.net  Fri Jan 22 15:42:40 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Fri, 22 Jan 2021 15:42:40 GMT
Subject: RFR: 8259707: LDAP channel binding does not work with StartTLS
 extension [v4]
In-Reply-To: <WZtwqQ5ZuAYnvma_rB1OnqPWOqhpZsP1Ill18-1WHaU=.a839644c-9884-461f-a426-d7844f9f8a03@github.com>
References: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
 <WZtwqQ5ZuAYnvma_rB1OnqPWOqhpZsP1Ill18-1WHaU=.a839644c-9884-461f-a426-d7844f9f8a03@github.com>
Message-ID: <nnVzbaBwy1Mqkn5Zb0XtSBbUnHN-9pf3w5DVTd3IaYU=.42162b09-d494-41a4-bca7-4353fbb2cd49@github.com>

On Fri, 22 Jan 2021 14:42:10 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS Extension.
>> Test from the bug report and jtreg javax/naming tests are passed.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Marked as reviewed by aefimov (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2085

From bpb at openjdk.java.net  Fri Jan 22 16:23:38 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 22 Jan 2021 16:23:38 GMT
Subject: RFR: JDK-8260273: DataOutputStream writeChars optimization
In-Reply-To: <ve8NNCTjABCKaUb0ZcpBC2InXNxFSdi88k_zSdLIk6M=.14e89b4a-492e-4b68-bd3e-ab22f2d73ea4@github.com>
References: <ve8NNCTjABCKaUb0ZcpBC2InXNxFSdi88k_zSdLIk6M=.14e89b4a-492e-4b68-bd3e-ab22f2d73ea4@github.com>
Message-ID: <NhHMXUqxld7hWwTzg1R3CeBJAb-EX8vdzBmXfiedGbQ=.46afd6c1-ded5-443e-b89c-2d39fc0cb60e@github.com>

On Fri, 22 Jan 2021 02:57:36 GMT, Hamlin Li <mli at openjdk.org> wrote:

> this is minor optimization following JDK-8254078.
> based on my tests with jmh, it has better performance when apply following patch:
> 
> diff --git a/src/java.base/share/classes/java/io/DataOutputStream.java b/src/java.base/share/classes/java/io/DataOutputStream.java
> index 9a9a687403c..4ea497fc7c0 100644
> --- a/src/java.base/share/classes/java/io/DataOutputStream.java
> +++ b/src/java.base/share/classes/java/io/DataOutputStream.java
> @@ -300,8 +300,9 @@ public class DataOutputStream extends FilterOutputStream implements DataOutput {
>          int len = s.length();
>          for (int i = 0 ; i < len ; i++) {
>              int v = s.charAt(i);
> - out.write((v >>> 8) & 0xFF);
> - out.write((v >>> 0) & 0xFF);
> + writeBuffer[0] = (byte)(v >>> 8);
> + writeBuffer[1] = (byte)(v >>> 0);
> + out.write(writeBuffer, 0, 2);
>          }
>          incCount(len * 2);
>      }
> 
> Basically, it has better performance when apply above patch:
> 
> // without writeChars optimization patch, (-XX:-UseBiasedLocking)
> Benchmark (basicType) (size) Mode Cnt Score Error Units
> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 115.208 ? 0.327 us/op
> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 276.795 ? 0.449 us/op
> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 12356.969 ? 22.427 us/op
> 
> // with writeChars optimization patch, (-XX:-UseBiasedLocking)
> Benchmark (basicType) (size) Mode Cnt Score Error Units
> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 133.706 ? 0.274 us/op
> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 130.979 ? 0.155 us/op
> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 6814.272 ? 52.770 us/op
> 
> 
> // without writeChars optimization patch, (-XX:+UseBiasedLocking)
> Benchmark (basicType) (size) Mode Cnt Score Error Units
> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 130.367 ? 8.759 us/op
> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 37.559 ? 0.059 us/op
> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 12385.030 ? 376.560 us/op
> 
> // with writeChars optimization patch, (-XX:+UseBiasedLocking)
> Benchmark (basicType) (size) Mode Cnt Score Error Units
> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 45.494 ? 7.018 us/op
> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 33.015 ? 0.349 us/op
> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 6845.549 ? 38.712 us/op

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2190

From github.com+34924738+mahendrachhipa at openjdk.java.net  Fri Jan 22 16:52:02 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 22 Jan 2021 16:52:02 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
 [v2]
In-Reply-To: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
Message-ID: <yJcUp9Y_StqxljldFR_wXRA5QsKro5pp3sxqgQWW-js=.6fe3b134-81ee-4925-b951-b60f9e885215@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8183372

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  NonJavaName Tests updated
  Used newInstance() method to create the different EnclosingClasses at runtime

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2170/files
  - new: https://git.openjdk.java.net/jdk/pull/2170/files/a02e66a5..e664bd73

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=00-01

  Stats: 404 lines in 5 files changed: 186 ins; 210 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2170.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2170/head:pull/2170

PR: https://git.openjdk.java.net/jdk/pull/2170

From naoto at openjdk.java.net  Fri Jan 22 16:55:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 22 Jan 2021 16:55:40 GMT
Subject: RFR: 8246788: ZoneRules invariants can be broken
In-Reply-To: <kZbfHIUgpUmMbulGDG3FUrAc188KfDkfGv_Y21csUOg=.7208b820-e948-4c07-905a-7db91f199383@github.com>
References: <kZbfHIUgpUmMbulGDG3FUrAc188KfDkfGv_Y21csUOg=.7208b820-e948-4c07-905a-7db91f199383@github.com>
Message-ID: <jptJhqEz9uK76bFzRkccel5mC1_1v4dWRfz8o9mwRV8=.4d0f1b95-bf71-4953-9d8e-55eb78394227@github.com>

On Fri, 22 Jan 2021 05:39:55 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Tighten up argument checking in constructor.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2191

From github.com+34924738+mahendrachhipa at openjdk.java.net  Fri Jan 22 17:00:46 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 22 Jan 2021 17:00:46 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
In-Reply-To: <ZcUGBjirPn92xFn2-zW7YnQUWjyKMrlAapqGqiG75eI=.2c5a5e0d-8687-4f92-b735-55b0d470c1ef@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
 <ZcUGBjirPn92xFn2-zW7YnQUWjyKMrlAapqGqiG75eI=.2c5a5e0d-8687-4f92-b735-55b0d470c1ef@github.com>
Message-ID: <heoqGKAfGsmu1Dc8c5XgFUDPX1rGd734EA3hBMu-jIE=.c11bf00d-93c1-4c13-88ea-ee6f435b97fb@github.com>

On Thu, 21 Jan 2021 05:19:00 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8183372
>
> Can this be done all in `EnclosingClassTest.java`, without a new `RunEnclosingClassTest.java`?
> 
> Adding the `@BeforeClass` and `@AfterClass` methods to what's there, you may just need to 
> change the `test()` calls to use reflection - something along the lines of: 
> 
>> test(`Class.forName("EnclosingClass").getDeclaredConstructor().newInstance());`

Review comments implemented.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2170

From github.com+592810+efge at openjdk.java.net  Fri Jan 22 17:09:48 2021
From: github.com+592810+efge at openjdk.java.net (Florent Guillaume)
Date: Fri, 22 Jan 2021 17:09:48 GMT
Subject: RFR: 8246788: ZoneRules invariants can be broken
In-Reply-To: <ihP-QLU5Ia8o-VXMUAgC7RRWBE-FBkcpSkcpTlR_LyE=.dd726c5e-62f3-4efa-a1ee-fb78777e307e@github.com>
References: <kZbfHIUgpUmMbulGDG3FUrAc188KfDkfGv_Y21csUOg=.7208b820-e948-4c07-905a-7db91f199383@github.com>
 <ihP-QLU5Ia8o-VXMUAgC7RRWBE-FBkcpSkcpTlR_LyE=.dd726c5e-62f3-4efa-a1ee-fb78777e307e@github.com>
Message-ID: <k8o5ITlsJ_2OD4cZ_TC_2CIm_yiTXfAczsF0qGo_pMo=.fc52a3ae-7016-4c2d-83c9-e4234a3e3df0@github.com>

On Fri, 22 Jan 2021 14:48:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Tighten up argument checking in constructor.
>
> src/java.base/share/classes/java/time/zone/ZoneRules.java line 263:
> 
>> 261:         // last rules
>> 262:         Object[] temp = lastRules.toArray();
>> 263:         ZoneOffsetTransitionRule[] rulesArray = Arrays.copyOf(temp, temp.length, ZoneOffsetTransitionRule[].class);
> 
> LGTM. Could be replaced by:
> 
> ZoneOffsetTransitionRule[] rulesArray = (ZoneOffsetTransitionRule[])lastRules.toArray(new ZoneOffsetTransitionRule[0]).clone();
> 
> if you wanted - but what you currently have is good for me.

Or even maybe `rulesArray = lastRules.toArray(ZoneOffsetTransitionRule[]::new);`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2191

From dfuchs at openjdk.java.net  Fri Jan 22 17:15:40 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 22 Jan 2021 17:15:40 GMT
Subject: RFR: 8246788: ZoneRules invariants can be broken
In-Reply-To: <k8o5ITlsJ_2OD4cZ_TC_2CIm_yiTXfAczsF0qGo_pMo=.fc52a3ae-7016-4c2d-83c9-e4234a3e3df0@github.com>
References: <kZbfHIUgpUmMbulGDG3FUrAc188KfDkfGv_Y21csUOg=.7208b820-e948-4c07-905a-7db91f199383@github.com>
 <ihP-QLU5Ia8o-VXMUAgC7RRWBE-FBkcpSkcpTlR_LyE=.dd726c5e-62f3-4efa-a1ee-fb78777e307e@github.com>
 <k8o5ITlsJ_2OD4cZ_TC_2CIm_yiTXfAczsF0qGo_pMo=.fc52a3ae-7016-4c2d-83c9-e4234a3e3df0@github.com>
Message-ID: <XT93FjleYagN4VXbSrhoKJYkH51Uk09J1KpDv-KTC9c=.03225f28-6f76-4960-a1fc-74d16fb290d6@github.com>

On Fri, 22 Jan 2021 15:00:17 GMT, Florent Guillaume <github.com+592810+efge at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/zone/ZoneRules.java line 263:
>> 
>>> 261:         // last rules
>>> 262:         Object[] temp = lastRules.toArray();
>>> 263:         ZoneOffsetTransitionRule[] rulesArray = Arrays.copyOf(temp, temp.length, ZoneOffsetTransitionRule[].class);
>> 
>> LGTM. Could be replaced by:
>> 
>> ZoneOffsetTransitionRule[] rulesArray = (ZoneOffsetTransitionRule[])lastRules.toArray(new ZoneOffsetTransitionRule[0]).clone();
>> 
>> if you wanted - but what you currently have is good for me.
>
> Or even maybe `rulesArray = lastRules.toArray(ZoneOffsetTransitionRule[]::new);`?

Good point - but that would be:

ZoneOffsetTransitionRule[] rulesArray = lastRules.toArray(ZoneOffsetTransitionRule[]::new).clone();

-------------

PR: https://git.openjdk.java.net/jdk/pull/2191

From github.com+652983+dasbrain at openjdk.java.net  Fri Jan 22 17:21:43 2021
From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn)
Date: Fri, 22 Jan 2021 17:21:43 GMT
Subject: Integrated: 8259922 MethodHandles.collectArguments does not throw IAE
 if pos is outside the arity range
In-Reply-To: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com>
References: <0bWk4Q_5MqIH8tJLCYpdArZJ3frUdv4tnkiRFYiR_yk=.3a5feebf-6511-49fa-811b-5fc4eda11989@github.com>
Message-ID: <APObwQwW3s4kw8IbLh0wbvgntg-7meNalIwZGvZd_9Q=.93befb07-824b-439c-b17c-43afbecf179c@github.com>

On Wed, 20 Jan 2021 18:29:00 GMT, Johannes Kuhn <github.com+652983+DasBrain at openjdk.org> wrote:

> Add explicit range check to `MethodHandles.collectArgumentsCheck`.  
> Added test case that exercises all cases.
> 
> This is a behavioral change, from throwing an unspecified exception to throwing an IllegalArgumentException, as specified.  
> No spec change needed, as the IllegalArgumentException is already specified to be thrown in those cases.
> 
> Feel free to suggest a better place for the tests.

This pull request has now been integrated.

Changeset: bf5e8015
Author:    Johannes Kuhn <info at j-kuhn.de>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bf5e8015
Stats:     86 lines in 2 files changed: 86 ins; 0 del; 0 mod

8259922: MethodHandles.collectArguments does not throw IAE if pos is outside the arity range

Reviewed-by: mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/2171

From dfuchs at openjdk.java.net  Fri Jan 22 18:19:46 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 22 Jan 2021 18:19:46 GMT
Subject: RFR: 8259707: LDAP channel binding does not work with StartTLS
 extension [v4]
In-Reply-To: <WZtwqQ5ZuAYnvma_rB1OnqPWOqhpZsP1Ill18-1WHaU=.a839644c-9884-461f-a426-d7844f9f8a03@github.com>
References: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
 <WZtwqQ5ZuAYnvma_rB1OnqPWOqhpZsP1Ill18-1WHaU=.a839644c-9884-461f-a426-d7844f9f8a03@github.com>
Message-ID: <CDYa_ozUeT2qMP3lt8dCFmsxe0ZRpaR82SJeBZKEMO8=.0fc3288a-95d4-4504-800a-df767a651175@github.com>

On Fri, 22 Jan 2021 14:42:10 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS Extension.
>> Test from the bug report and jtreg javax/naming tests are passed.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

LGTM. Thanks for taking this on!

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2085

From dfuchs at openjdk.java.net  Fri Jan 22 18:24:41 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 22 Jan 2021 18:24:41 GMT
Subject: RFR: 8259707: LDAP channel binding does not work with StartTLS
 extension [v4]
In-Reply-To: <CDYa_ozUeT2qMP3lt8dCFmsxe0ZRpaR82SJeBZKEMO8=.0fc3288a-95d4-4504-800a-df767a651175@github.com>
References: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
 <WZtwqQ5ZuAYnvma_rB1OnqPWOqhpZsP1Ill18-1WHaU=.a839644c-9884-461f-a426-d7844f9f8a03@github.com>
 <CDYa_ozUeT2qMP3lt8dCFmsxe0ZRpaR82SJeBZKEMO8=.0fc3288a-95d4-4504-800a-df767a651175@github.com>
Message-ID: <flPhKUQZIlmUbyQ3T5FZnF0PebE1QuOtVjOfYon-hiY=.00ad16bd-7a42-4cd9-b547-ae2bff93ce9c@github.com>

On Fri, 22 Jan 2021 18:16:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year
>
> LGTM. Thanks for taking this on!

I will sponsor this!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2085

From abakhtin at openjdk.java.net  Fri Jan 22 18:24:42 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 22 Jan 2021 18:24:42 GMT
Subject: Integrated: 8259707: LDAP channel binding does not work with StartTLS
 extension
In-Reply-To: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
References: <rVch8xZKAdsCM-NT7a_VtgpHsARDKUOO3_QS76v0DHE=.a3aca6a4-b0e5-4264-a037-d1c3ce5793e1@github.com>
Message-ID: <lSx3BZ5_1JOTvCbGaQpFdbogqWeKH_5FuVdcG62y9Vc=.6633ffca-647d-42ed-b76d-d012a75e7b7e@github.com>

On Thu, 14 Jan 2021 19:28:27 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS Extension.
> Test from the bug report and jtreg javax/naming tests are passed.

This pull request has now been integrated.

Changeset: 874aef4a
Author:    Alexey Bakhtin <abakhtin at openjdk.org>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/874aef4a
Stats:     74 lines in 2 files changed: 39 ins; 21 del; 14 mod

8259707: LDAP channel binding does not work with StartTLS extension

Reviewed-by: mullan, dfuchs, aefimov

-------------

PR: https://git.openjdk.java.net/jdk/pull/2085

From mchung at openjdk.java.net  Fri Jan 22 18:27:54 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 22 Jan 2021 18:27:54 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
 [v2]
In-Reply-To: <yJcUp9Y_StqxljldFR_wXRA5QsKro5pp3sxqgQWW-js=.6fe3b134-81ee-4925-b951-b60f9e885215@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
 <yJcUp9Y_StqxljldFR_wXRA5QsKro5pp3sxqgQWW-js=.6fe3b134-81ee-4925-b951-b60f9e885215@github.com>
Message-ID: <xBkb4pJvfGw3zc5UEpO2rJLrLo7u-5aUYFjFtjdazqA=.98c049c2-e8f7-456e-b6d8-12cd573a7b4c@github.com>

On Fri, 22 Jan 2021 16:52:02 GMT, Mahendra Chhipa <github.com+34924738+mahendrachhipa at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8183372
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   NonJavaName Tests updated
>   Used newInstance() method to create the different EnclosingClasses at runtime

test/jdk/java/lang/Class/forName/NonJavaNameTest.java line 43:

> 41:  * @run testng/othervm NonJavaNameTest
> 42:  * @summary Verify names that aren't legal Java names are accepted by forName.
> 43:  * @author Joseph D. Darcy

we can drop this `@author` in particular this is a new file.

test/jdk/java/lang/Class/forName/NonJavaNameTest.java line 49:

> 47:     private static final String SRC_DIR = System.getProperty("test.src");
> 48:     private static final String NONJAVA_NAMES_SRC = SRC_DIR + "/classes/";
> 49:     private static final String NONJAVA_NAMES_CLASSES = System.getProperty("test.classes", ".");

I was at first confused with `NON_NAMES_CLASSES` of what it means.    For simplicity and clarity, better to rename these variables:
s/NONJAVA_NAMES_SRC/TEST_SRC/
s/NONJAVA_NAMES_CLASSES/TEST_CLASSES/

test/jdk/java/lang/Class/forName/NonJavaNameTest.java line 96:

> 94: 
> 95:     @AfterClass
> 96:     public void deleteInvalidNameClasses() throws IOException {

jtreg will do the clean up and this is not necessary.

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 95:

> 93:             Files.deleteIfExists(pkg2Dir);
> 94:             Files.deleteIfExists(pkg1File);
> 95:             Files.deleteIfExists(pkg1Dir);

You can consider using `jdk.test.lib.util.FileUtils` test library to remove the entire directory.

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 97:

> 95:             Files.deleteIfExists(pkg1Dir);
> 96:             Files.createDirectories(pkg2Dir);
> 97:         } catch (IOException ex) {

The test should fail when running into any error.    Using the test library will do the retry

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 176:

> 174:     }
> 175: 
> 176:     private void check(final Class<?> c, final Class<?> enc,

I see that you make all parameters in all methods final.   It just adds noise.   Can you leave it out?

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 197:

> 195:                 c.getSimpleName(), annotation.simple(),
> 196:                 c.getCanonicalName(),
> 197:                 annotation.hasCanonical() ? annotation.canonical() : null);

I am guessing this whitespace in line 195-197 is not intentional?  Same for line 203-206?

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 103:

> 101:         createAndWriteEnclosingClasses(enclosingPath, pkg2File, "pkg1.pkg2");
> 102: 
> 103:         String javacPath = JDKToolFinder.getJDKTool("javac");

You can use `jdk.test.lib.compiler.CompilerUtils` test library to compile the file in process.

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 71:

> 69: /*
> 70: * @test
> 71: * @bug 4992173 4992170

this needs `@modules jdk.compiler`

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 141:

> 139:     }
> 140: 
> 141:     private void createAndWriteEnclosingClasses(final Path source, final Path target, final String packagePath) {

s/packagePath/packageName/

no need to declare parameters as `final`

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 147:

> 145:             while ((line = br.readLine()) != null) {
> 146:                 if (line.contains("canonical=\"EnclosingClass")) {
> 147:                     line = line.replaceAll("canonical=\"EnclosingClass", "canonical=\"" + packagePath + ".EnclosingClass");

suggestion: declare `var className = packageName + ".EnclosingClass";`  and replace those occurrance.

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 155:

> 153:                 bw.println(line);
> 154:             }
> 155:         } catch (IOException ex) {

Should not swallow the error and instead, let it propagate and the test should fail.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2170

From smarks at openjdk.java.net  Fri Jan 22 18:54:45 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 22 Jan 2021 18:54:45 GMT
Subject: Integrated: 8246788: ZoneRules invariants can be broken
In-Reply-To: <kZbfHIUgpUmMbulGDG3FUrAc188KfDkfGv_Y21csUOg=.7208b820-e948-4c07-905a-7db91f199383@github.com>
References: <kZbfHIUgpUmMbulGDG3FUrAc188KfDkfGv_Y21csUOg=.7208b820-e948-4c07-905a-7db91f199383@github.com>
Message-ID: <e0QhzFSMo8P7UpHQFkkvpCIh_s8jWK-wFKP8IT6REI4=.9e20dc2d-538f-46f1-ab4d-eef9596348d6@github.com>

On Fri, 22 Jan 2021 05:39:55 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Tighten up argument checking in constructor.

This pull request has now been integrated.

Changeset: a8871776
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a8871776
Stats:     90 lines in 2 files changed: 87 ins; 0 del; 3 mod

8246788: ZoneRules invariants can be broken

Reviewed-by: rriggs, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/2191

From smarks at openjdk.java.net  Fri Jan 22 18:54:42 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 22 Jan 2021 18:54:42 GMT
Subject: RFR: 8246788: ZoneRules invariants can be broken
In-Reply-To: <XT93FjleYagN4VXbSrhoKJYkH51Uk09J1KpDv-KTC9c=.03225f28-6f76-4960-a1fc-74d16fb290d6@github.com>
References: <kZbfHIUgpUmMbulGDG3FUrAc188KfDkfGv_Y21csUOg=.7208b820-e948-4c07-905a-7db91f199383@github.com>
 <ihP-QLU5Ia8o-VXMUAgC7RRWBE-FBkcpSkcpTlR_LyE=.dd726c5e-62f3-4efa-a1ee-fb78777e307e@github.com>
 <k8o5ITlsJ_2OD4cZ_TC_2CIm_yiTXfAczsF0qGo_pMo=.fc52a3ae-7016-4c2d-83c9-e4234a3e3df0@github.com>
 <XT93FjleYagN4VXbSrhoKJYkH51Uk09J1KpDv-KTC9c=.03225f28-6f76-4960-a1fc-74d16fb290d6@github.com>
Message-ID: <XSNlBQ_YKhqSg57-90fAA22VUrW_ETIV82ZZl7qH4v8=.f44f779a-6afc-47c1-85fd-b62fa4c0eb9d@github.com>

On Fri, 22 Jan 2021 17:12:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Or even maybe `rulesArray = lastRules.toArray(ZoneOffsetTransitionRule[]::new);`?
>
> Good point - but that would be:
> 
> ZoneOffsetTransitionRule[] rulesArray = lastRules.toArray(ZoneOffsetTransitionRule[]::new).clone();

Interesting. This last one is more concise, but it's a bit harder to reason about. The lastRules implementation could return an array of a type other than ZOTR[]. If it's unrelated or a supertype, this would result in ClassCastException -- probably not a problem. If it were a subtype of ZOTR[], this would get stored in the object's field. Is this a problem? Turns out it can't happen, since ZOTR is final. While not wrong, I don't think this is the right idiom.

It occurs to me that there should by another overload Arrays.copyOf(array, newType) that changes the type without changing the length. This would let us get rid of the local variable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2191

From jiangli at openjdk.java.net  Fri Jan 22 20:02:48 2021
From: jiangli at openjdk.java.net (Jiangli Zhou)
Date: Fri, 22 Jan 2021 20:02:48 GMT
Subject: RFR: 8252412: [macos11] system dynamic libraries removed from
 filesystem [v2]
In-Reply-To: <5u4w-g-wpqqVp3GHPon_vNOhT2Mq0lAowl74fFZwCms=.fc5d8f4c-7e4a-47a4-ad10-02dbe281f16f@github.com>
References: <JKwrbNjv57HU-WVqocbD9Z7X27cPVFczIFOOKlzpOQ4=.cb6d6cb8-afe7-486e-ba3b-e41ba8ad47cf@github.com>
 <5u4w-g-wpqqVp3GHPon_vNOhT2Mq0lAowl74fFZwCms=.fc5d8f4c-7e4a-47a4-ad10-02dbe281f16f@github.com>
Message-ID: <DJzNKLsnPo75UjoKMWl_dOuuOqvMSbCrC-A_PRgXqlk=.3b87eb37-03c0-40c0-aae5-91d96efb9e0c@github.com>

On Mon, 18 Jan 2021 11:03:06 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> 8252412: [macos11] system dynamic libraries removed from filesystem
>
> 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.

src/java.smartcardio/unix/classes/sun/security/smartcardio/PlatformPCSC.java line 132:

> 130:         // existence of the containing directory instead of the file.
> 131:         lib = PCSC_FRAMEWORK;
> 132:         if (new File(lib).getParentFile().isDirectory()) {

This is outside of my normal area, could you please explain why checking the existence of the containing directory is equivalent to checking the file here? Does it provide the expected behavior on all unix-like platforms or only macos?

Could you please also provide a jtreg test for this change?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2119

From akozlov at openjdk.java.net  Fri Jan 22 20:02:56 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 22 Jan 2021 20:02:56 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port
Message-ID: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>

Please review the implementation of JEP 391: macOS/AArch64 Port.

It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 

Major changes are in:
* src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
* src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
* src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
* src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

-------------

Commit messages:
 - Fix build
 - JDK-8253816: Update after recent changes
 - Rework gtests to always have wx_write
 - Revert gtest changes
 - Fix gtests in debug
 - Merge remote-tracking branch 'upstream/master' into jdk-macos
 - Fix windows_aarch64
 - Use r18_tls instead of r18_reserved
 - JDK-8253742: bsd_aarch64 part
 - JDK-8257882: bsd_aarch64 part
 - ... and 40 more: https://git.openjdk.java.net/jdk/compare/82adfb32...3d4f4c23

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253795
  Stats: 3335 lines in 117 files changed: 3230 ins; 41 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

From martin at openjdk.java.net  Fri Jan 22 20:11:45 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Fri, 22 Jan 2021 20:11:45 GMT
Subject: RFR: 8252412: [macos11] system dynamic libraries removed from
 filesystem [v2]
In-Reply-To: <DJzNKLsnPo75UjoKMWl_dOuuOqvMSbCrC-A_PRgXqlk=.3b87eb37-03c0-40c0-aae5-91d96efb9e0c@github.com>
References: <JKwrbNjv57HU-WVqocbD9Z7X27cPVFczIFOOKlzpOQ4=.cb6d6cb8-afe7-486e-ba3b-e41ba8ad47cf@github.com>
 <5u4w-g-wpqqVp3GHPon_vNOhT2Mq0lAowl74fFZwCms=.fc5d8f4c-7e4a-47a4-ad10-02dbe281f16f@github.com>
 <DJzNKLsnPo75UjoKMWl_dOuuOqvMSbCrC-A_PRgXqlk=.3b87eb37-03c0-40c0-aae5-91d96efb9e0c@github.com>
Message-ID: <y5gwRhWCszu97hM4vAirTEWdwcOisaNUeBozmDyrTbQ=.93353440-7979-4d20-906b-a63a26ce56db@github.com>

On Fri, 22 Jan 2021 19:46:13 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> 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.
>
> src/java.smartcardio/unix/classes/sun/security/smartcardio/PlatformPCSC.java line 132:
> 
>> 130:         // existence of the containing directory instead of the file.
>> 131:         lib = PCSC_FRAMEWORK;
>> 132:         if (new File(lib).getParentFile().isDirectory()) {
> 
> This is outside of my normal area, could you please explain why checking the existence of the containing directory is equivalent to checking the file here? Does it provide the expected behavior on all unix-like platforms or only macos?
> 
> Could you please also provide a jtreg test for this change?

The directory structure is intact - only the file is removed from the filesystem.
More generally, for many frameworks, where there used to be


the file is gone, but 


remains.

I don't think we need a jtreg test, since any functionality associated with PCSC is broken on this platform.  I added label noreg-other

-------------

PR: https://git.openjdk.java.net/jdk/pull/2119

From martinrb at google.com  Fri Jan 22 20:17:55 2021
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 22 Jan 2021 12:17:55 -0800
Subject: RFR: 8252412: [macos11] system dynamic libraries removed from
 filesystem [v2]
In-Reply-To: <y5gwRhWCszu97hM4vAirTEWdwcOisaNUeBozmDyrTbQ=.93353440-7979-4d20-906b-a63a26ce56db@github.com>
References: <JKwrbNjv57HU-WVqocbD9Z7X27cPVFczIFOOKlzpOQ4=.cb6d6cb8-afe7-486e-ba3b-e41ba8ad47cf@github.com>
 <5u4w-g-wpqqVp3GHPon_vNOhT2Mq0lAowl74fFZwCms=.fc5d8f4c-7e4a-47a4-ad10-02dbe281f16f@github.com>
 <DJzNKLsnPo75UjoKMWl_dOuuOqvMSbCrC-A_PRgXqlk=.3b87eb37-03c0-40c0-aae5-91d96efb9e0c@github.com>
 <y5gwRhWCszu97hM4vAirTEWdwcOisaNUeBozmDyrTbQ=.93353440-7979-4d20-906b-a63a26ce56db@github.com>
Message-ID: <CA+kOe0-NpRtJ05pvLDhoKasTHpReX4u774iwSAyFcy1vYeb1Bg@mail.gmail.com>

My github comment was mangled forwarding to core-libs.  I suspect the skara
bidirectional mailing list forwarding bot discards lines with leading "/"
.

Instead the bot should pass on unrecognized github comment commands
unmodified.

On Fri, Jan 22, 2021 at 12:12 PM Martin Buchholz <martin at openjdk.java.net>
wrote:

> On Fri, 22 Jan 2021 19:46:13 GMT, Jiangli Zhou <jiangli at openjdk.org>
> wrote:
>
> >> 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.
> >
> >
> src/java.smartcardio/unix/classes/sun/security/smartcardio/PlatformPCSC.java
> line 132:
> >
> >> 130:         // existence of the containing directory instead of the
> file.
> >> 131:         lib = PCSC_FRAMEWORK;
> >> 132:         if (new File(lib).getParentFile().isDirectory()) {
> >
> > This is outside of my normal area, could you please explain why checking
> the existence of the containing directory is equivalent to checking the
> file here? Does it provide the expected behavior on all unix-like platforms
> or only macos?
> >
> > Could you please also provide a jtreg test for this change?
>
> The directory structure is intact - only the file is removed from the
> filesystem.
> More generally, for many frameworks, where there used to be
>
>
> the file is gone, but
>
>
> remains.
>
> I don't think we need a jtreg test, since any functionality associated
> with PCSC is broken on this platform.  I added label noreg-other
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/2119
>

From bchristi at openjdk.java.net  Fri Jan 22 20:27:40 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 22 Jan 2021 20:27:40 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
In-Reply-To: <heoqGKAfGsmu1Dc8c5XgFUDPX1rGd734EA3hBMu-jIE=.c11bf00d-93c1-4c13-88ea-ee6f435b97fb@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
 <ZcUGBjirPn92xFn2-zW7YnQUWjyKMrlAapqGqiG75eI=.2c5a5e0d-8687-4f92-b735-55b0d470c1ef@github.com>
 <heoqGKAfGsmu1Dc8c5XgFUDPX1rGd734EA3hBMu-jIE=.c11bf00d-93c1-4c13-88ea-ee6f435b97fb@github.com>
Message-ID: <cKTmCgVXtpqnd94dm8zHdQn5jdic-mvMTS0FiohUQ8M=.414f0af4-d125-495c-9998-0a5a1e417936@github.com>

On Fri, 22 Jan 2021 16:57:41 GMT, Mahendra Chhipa <github.com+34924738+mahendrachhipa at openjdk.org> wrote:

>> Can this be done all in `EnclosingClassTest.java`, without a new `RunEnclosingClassTest.java`?
>> 
>> Adding the `@BeforeClass` and `@AfterClass` methods to what's there, you may just need to 
>> change the `test()` calls to use reflection - something along the lines of: 
>> 
>>> test(`Class.forName("EnclosingClass").getDeclaredConstructor().newInstance());`
>
> Review comments implemented.

Can the new code be added to the existing `NonJavaNames.java` instead of adding a new `NonJavaNameTest.java` file?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2170

From erikj at openjdk.java.net  Fri Jan 22 20:27:42 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 22 Jan 2021 20:27:42 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <_l6v7_5ODWCmW5x90hA_Vv0TegGm00YW98ELrJvi65o=.1b2d4f0f-0791-4d4f-bf00-d829738611b5@github.com>

On Fri, 22 Jan 2021 18:49:42 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Build changes in general look good.

make/autoconf/flags-cflags.m4 line 169:

> 167:       WARNINGS_ENABLE_ALL="-Wall -Wextra -Wformat=2 $WARNINGS_ENABLE_ADDITIONAL"
> 168: 
> 169:       DISABLED_WARNINGS="unknown-warning-option unused-parameter unused format-nonliteral"

Globally disabling a warning needs some motivation. Why is this needed? Does it really need to be applied everywhere or is there a specific binary or source file where this is triggered?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From amenkov at openjdk.java.net  Fri Jan 22 21:36:40 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 22 Jan 2021 21:36:40 GMT
Subject: Integrated: 8258917: NativeMemoryTracking is handled by launcher
 inconsistenly
In-Reply-To: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
References: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
Message-ID: <580j1te4Df_kRYGH4Nk2zqjdhu_FaU_fV3dCSIbSf04=.777e57d8-d853-4f0e-9dd5-f5503e59453a@github.com>

On Fri, 15 Jan 2021 23:50:16 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix adds NMT handling for non-java launchers

This pull request has now been integrated.

Changeset: bdc305e1
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bdc305e1
Stats:     30 lines in 2 files changed: 16 ins; 1 del; 13 mod

8258917: NativeMemoryTracking is handled by launcher inconsistenly

Reviewed-by: zgu

-------------

PR: https://git.openjdk.java.net/jdk/pull/2106

From jiangli at openjdk.java.net  Fri Jan 22 22:19:42 2021
From: jiangli at openjdk.java.net (Jiangli Zhou)
Date: Fri, 22 Jan 2021 22:19:42 GMT
Subject: RFR: 8252412: [macos11] system dynamic libraries removed from
 filesystem [v2]
In-Reply-To: <y5gwRhWCszu97hM4vAirTEWdwcOisaNUeBozmDyrTbQ=.93353440-7979-4d20-906b-a63a26ce56db@github.com>
References: <JKwrbNjv57HU-WVqocbD9Z7X27cPVFczIFOOKlzpOQ4=.cb6d6cb8-afe7-486e-ba3b-e41ba8ad47cf@github.com>
 <5u4w-g-wpqqVp3GHPon_vNOhT2Mq0lAowl74fFZwCms=.fc5d8f4c-7e4a-47a4-ad10-02dbe281f16f@github.com>
 <DJzNKLsnPo75UjoKMWl_dOuuOqvMSbCrC-A_PRgXqlk=.3b87eb37-03c0-40c0-aae5-91d96efb9e0c@github.com>
 <y5gwRhWCszu97hM4vAirTEWdwcOisaNUeBozmDyrTbQ=.93353440-7979-4d20-906b-a63a26ce56db@github.com>
Message-ID: <KILBQkEjnboplwxH29WgBf29aTsTug26_DOv_RLR4eo=.03e51adc-78d6-4a33-82ce-5eac2a4844da@github.com>

On Fri, 22 Jan 2021 20:08:48 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> src/java.smartcardio/unix/classes/sun/security/smartcardio/PlatformPCSC.java line 132:
>> 
>>> 130:         // existence of the containing directory instead of the file.
>>> 131:         lib = PCSC_FRAMEWORK;
>>> 132:         if (new File(lib).getParentFile().isDirectory()) {
>> 
>> This is outside of my normal area, could you please explain why checking the existence of the containing directory is equivalent to checking the file here? Does it provide the expected behavior on all unix-like platforms or only macos?
>> 
>> Could you please also provide a jtreg test for this change?
>
> The directory structure is intact - only the file is removed from the filesystem.
> More generally, for many frameworks, where there used to be
> 
> 
> the file is gone, but 
> 
> 
> remains.
> 
> I don't think we need a jtreg test, since any functionality associated with PCSC is broken on this platform.  I added label noreg-other

Ok, I see Java_sun_security_smartcardio_PlatformPCSC_initialize does dlopen using the 'jLibName' (string) obtained from getLibraryName() and throws IOException if dlopen fails. The change seems safe enough.

I'm wondering if you want to check the file first then check the parent directory if the file does not exist. Not sure if that's a little more optimal on older macos, so I'll leave that to you to decide.

For the jtreg test, how about converting Dominik's TestPCSC? As the file is a shared for 'unix' platforms, it feels safer at least with some level of unit test. Could you please give some more contexts about the functionalities associated with PCSC are broken on macos?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2119

From jiangli at openjdk.java.net  Fri Jan 22 22:58:42 2021
From: jiangli at openjdk.java.net (Jiangli Zhou)
Date: Fri, 22 Jan 2021 22:58:42 GMT
Subject: RFR: 8252412: [macos11] system dynamic libraries removed from
 filesystem [v2]
In-Reply-To: <5u4w-g-wpqqVp3GHPon_vNOhT2Mq0lAowl74fFZwCms=.fc5d8f4c-7e4a-47a4-ad10-02dbe281f16f@github.com>
References: <JKwrbNjv57HU-WVqocbD9Z7X27cPVFczIFOOKlzpOQ4=.cb6d6cb8-afe7-486e-ba3b-e41ba8ad47cf@github.com>
 <5u4w-g-wpqqVp3GHPon_vNOhT2Mq0lAowl74fFZwCms=.fc5d8f4c-7e4a-47a4-ad10-02dbe281f16f@github.com>
Message-ID: <vFK9Wh4dxkJ-c9LTIPX6Y0BKd1JDo_r8K8bRTwNpWrY=.48574b7d-b202-42a9-9ae6-4949f65fa024@github.com>

On Mon, 18 Jan 2021 11:03:06 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> 8252412: [macos11] system dynamic libraries removed from filesystem
>
> 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.

Marked as reviewed by jiangli (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2119

From jiangli at openjdk.java.net  Fri Jan 22 22:58:44 2021
From: jiangli at openjdk.java.net (Jiangli Zhou)
Date: Fri, 22 Jan 2021 22:58:44 GMT
Subject: RFR: 8252412: [macos11] system dynamic libraries removed from
 filesystem [v2]
In-Reply-To: <KILBQkEjnboplwxH29WgBf29aTsTug26_DOv_RLR4eo=.03e51adc-78d6-4a33-82ce-5eac2a4844da@github.com>
References: <JKwrbNjv57HU-WVqocbD9Z7X27cPVFczIFOOKlzpOQ4=.cb6d6cb8-afe7-486e-ba3b-e41ba8ad47cf@github.com>
 <5u4w-g-wpqqVp3GHPon_vNOhT2Mq0lAowl74fFZwCms=.fc5d8f4c-7e4a-47a4-ad10-02dbe281f16f@github.com>
 <DJzNKLsnPo75UjoKMWl_dOuuOqvMSbCrC-A_PRgXqlk=.3b87eb37-03c0-40c0-aae5-91d96efb9e0c@github.com>
 <y5gwRhWCszu97hM4vAirTEWdwcOisaNUeBozmDyrTbQ=.93353440-7979-4d20-906b-a63a26ce56db@github.com>
 <KILBQkEjnboplwxH29WgBf29aTsTug26_DOv_RLR4eo=.03e51adc-78d6-4a33-82ce-5eac2a4844da@github.com>
Message-ID: <cr_-Vvm1IjQtLv4CgthrBlp2dVCgBagGgpRgUIs6SQc=.8160549e-6f60-471f-8b79-3ede3a2626f8@github.com>

On Fri, 22 Jan 2021 22:16:28 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> The directory structure is intact - only the file is removed from the filesystem.
>> More generally, for many frameworks, where there used to be
>> 
>> 
>> the file is gone, but 
>> 
>> 
>> remains.
>> 
>> I don't think we need a jtreg test, since any functionality associated with PCSC is broken on this platform.  I added label noreg-other
>
> Ok, I see Java_sun_security_smartcardio_PlatformPCSC_initialize does dlopen using the 'jLibName' (string) obtained from getLibraryName() and throws IOException if dlopen fails. The change seems safe enough.
> 
> I'm wondering if you want to check the file first then check the parent directory if the file does not exist. Not sure if that's a little more optimal on older macos, so I'll leave that to you to decide.
> 
> For the jtreg test, how about converting Dominik's TestPCSC? As the file is a shared for 'unix' platforms, it feels safer at least with some level of unit test. Could you please give some more contexts about the functionalities associated with PCSC are broken on macos?

Martin and I had an off-line chat and Martin convinced me that the existing jtreg tests (such as test/jdk/javax/smartcardio and test/jdk/sun/security/smartcardio are sufficient) to cover the case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2119

From martin at openjdk.java.net  Sat Jan 23 00:03:42 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sat, 23 Jan 2021 00:03:42 GMT
Subject: RFR: 8252412: [macos11] system dynamic libraries removed from
 filesystem [v2]
In-Reply-To: <vFK9Wh4dxkJ-c9LTIPX6Y0BKd1JDo_r8K8bRTwNpWrY=.48574b7d-b202-42a9-9ae6-4949f65fa024@github.com>
References: <JKwrbNjv57HU-WVqocbD9Z7X27cPVFczIFOOKlzpOQ4=.cb6d6cb8-afe7-486e-ba3b-e41ba8ad47cf@github.com>
 <5u4w-g-wpqqVp3GHPon_vNOhT2Mq0lAowl74fFZwCms=.fc5d8f4c-7e4a-47a4-ad10-02dbe281f16f@github.com>
 <vFK9Wh4dxkJ-c9LTIPX6Y0BKd1JDo_r8K8bRTwNpWrY=.48574b7d-b202-42a9-9ae6-4949f65fa024@github.com>
Message-ID: <xPbfyRRh8EjRt3VdXqGAtR_wTbDoHXiTcy8jjqZHX4U=.0b6e86ca-2d1e-4f60-b394-adfd9b2921c0@github.com>

On Fri, 22 Jan 2021 22:56:08 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> 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.
>
> Marked as reviewed by jiangli (Reviewer).

Last call for a reviewer familiar with macos or smartcardio.  In case of crickets I will submit soon.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2119

From valeriep at openjdk.java.net  Sat Jan 23 02:05:40 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Sat, 23 Jan 2021 02:05:40 GMT
Subject: RFR: 8252412: [macos11] system dynamic libraries removed from
 filesystem [v2]
In-Reply-To: <5u4w-g-wpqqVp3GHPon_vNOhT2Mq0lAowl74fFZwCms=.fc5d8f4c-7e4a-47a4-ad10-02dbe281f16f@github.com>
References: <JKwrbNjv57HU-WVqocbD9Z7X27cPVFczIFOOKlzpOQ4=.cb6d6cb8-afe7-486e-ba3b-e41ba8ad47cf@github.com>
 <5u4w-g-wpqqVp3GHPon_vNOhT2Mq0lAowl74fFZwCms=.fc5d8f4c-7e4a-47a4-ad10-02dbe281f16f@github.com>
Message-ID: <N76N1PufjG8S3pHSuvmg9gcVF229JIqtMmtLMMh9TaU=.b6d721f2-30a6-4a54-aaa4-9aa314fb7efb@github.com>

On Mon, 18 Jan 2021 11:03:06 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> 8252412: [macos11] system dynamic libraries removed from filesystem
>
> 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.

Marked as reviewed by valeriep (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2119

From valeriep at openjdk.java.net  Sat Jan 23 02:05:42 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Sat, 23 Jan 2021 02:05:42 GMT
Subject: RFR: 8252412: [macos11] system dynamic libraries removed from
 filesystem [v2]
In-Reply-To: <cr_-Vvm1IjQtLv4CgthrBlp2dVCgBagGgpRgUIs6SQc=.8160549e-6f60-471f-8b79-3ede3a2626f8@github.com>
References: <JKwrbNjv57HU-WVqocbD9Z7X27cPVFczIFOOKlzpOQ4=.cb6d6cb8-afe7-486e-ba3b-e41ba8ad47cf@github.com>
 <5u4w-g-wpqqVp3GHPon_vNOhT2Mq0lAowl74fFZwCms=.fc5d8f4c-7e4a-47a4-ad10-02dbe281f16f@github.com>
 <DJzNKLsnPo75UjoKMWl_dOuuOqvMSbCrC-A_PRgXqlk=.3b87eb37-03c0-40c0-aae5-91d96efb9e0c@github.com>
 <y5gwRhWCszu97hM4vAirTEWdwcOisaNUeBozmDyrTbQ=.93353440-7979-4d20-906b-a63a26ce56db@github.com>
 <KILBQkEjnboplwxH29WgBf29aTsTug26_DOv_RLR4eo=.03e51adc-78d6-4a33-82ce-5eac2a4844da@github.com>
 <cr_-Vvm1IjQtLv4CgthrBlp2dVCgBagGgpRgUIs6SQc=.8160549e-6f60-471f-8b79-3ede3a2626f8@github.com>
Message-ID: <2G_pu3XSRJZwK0_KrSpoI1tTLd3dCDHAU7l7PMLtC7I=.0a62672d-ecba-48af-b47e-6fd5cec2bec3@github.com>

On Fri, 22 Jan 2021 22:55:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Ok, I see Java_sun_security_smartcardio_PlatformPCSC_initialize does dlopen using the 'jLibName' (string) obtained from getLibraryName() and throws IOException if dlopen fails. The change seems safe enough.
>> 
>> I'm wondering if you want to check the file first then check the parent directory if the file does not exist. Not sure if that's a little more optimal on older macos, so I'll leave that to you to decide.
>> 
>> For the jtreg test, how about converting Dominik's TestPCSC? As the file is a shared for 'unix' platforms, it feels safer at least with some level of unit test. Could you please give some more contexts about the functionalities associated with PCSC are broken on macos?
>
> Martin and I had an off-line chat and Martin convinced me that the existing jtreg tests (such as test/jdk/javax/smartcardio and test/jdk/sun/security/smartcardio are sufficient) to cover the case.

Right, existing tests should cover this already since running the test requires that the library must be loaded.
Changes look fine, thanks for fixing this. 
Kind of surprised the existing filtering didn't catch this as security-related changes and send this to security group for review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2119

From mli at openjdk.java.net  Sat Jan 23 04:18:38 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Sat, 23 Jan 2021 04:18:38 GMT
Subject: RFR: JDK-8260273: DataOutputStream writeChars optimization
In-Reply-To: <NhHMXUqxld7hWwTzg1R3CeBJAb-EX8vdzBmXfiedGbQ=.46afd6c1-ded5-443e-b89c-2d39fc0cb60e@github.com>
References: <ve8NNCTjABCKaUb0ZcpBC2InXNxFSdi88k_zSdLIk6M=.14e89b4a-492e-4b68-bd3e-ab22f2d73ea4@github.com>
 <NhHMXUqxld7hWwTzg1R3CeBJAb-EX8vdzBmXfiedGbQ=.46afd6c1-ded5-443e-b89c-2d39fc0cb60e@github.com>
Message-ID: <DGvcB059dg0DVO_Dspc1aeu2isNExOjuRClTVP67lnw=.47c80b31-0fea-4368-bd0f-dbeaa91456a1@github.com>

On Fri, 22 Jan 2021 16:21:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> this is minor optimization following JDK-8254078.
>> based on my tests with jmh, it has better performance when apply following patch:
>> 
>> diff --git a/src/java.base/share/classes/java/io/DataOutputStream.java b/src/java.base/share/classes/java/io/DataOutputStream.java
>> index 9a9a687403c..4ea497fc7c0 100644
>> --- a/src/java.base/share/classes/java/io/DataOutputStream.java
>> +++ b/src/java.base/share/classes/java/io/DataOutputStream.java
>> @@ -300,8 +300,9 @@ public class DataOutputStream extends FilterOutputStream implements DataOutput {
>>          int len = s.length();
>>          for (int i = 0 ; i < len ; i++) {
>>              int v = s.charAt(i);
>> - out.write((v >>> 8) & 0xFF);
>> - out.write((v >>> 0) & 0xFF);
>> + writeBuffer[0] = (byte)(v >>> 8);
>> + writeBuffer[1] = (byte)(v >>> 0);
>> + out.write(writeBuffer, 0, 2);
>>          }
>>          incCount(len * 2);
>>      }
>> 
>> Basically, it has better performance when apply above patch:
>> 
>> // without writeChars optimization patch, (-XX:-UseBiasedLocking)
>> Benchmark (basicType) (size) Mode Cnt Score Error Units
>> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 115.208 ? 0.327 us/op
>> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 276.795 ? 0.449 us/op
>> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 12356.969 ? 22.427 us/op
>> 
>> // with writeChars optimization patch, (-XX:-UseBiasedLocking)
>> Benchmark (basicType) (size) Mode Cnt Score Error Units
>> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 133.706 ? 0.274 us/op
>> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 130.979 ? 0.155 us/op
>> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 6814.272 ? 52.770 us/op
>> 
>> 
>> // without writeChars optimization patch, (-XX:+UseBiasedLocking)
>> Benchmark (basicType) (size) Mode Cnt Score Error Units
>> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 130.367 ? 8.759 us/op
>> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 37.559 ? 0.059 us/op
>> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 12385.030 ? 376.560 us/op
>> 
>> // with writeChars optimization patch, (-XX:+UseBiasedLocking)
>> Benchmark (basicType) (size) Mode Cnt Score Error Units
>> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 45.494 ? 7.018 us/op
>> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 33.015 ? 0.349 us/op
>> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 6845.549 ? 38.712 us/op
>
> Marked as reviewed by bpb (Reviewer).

Hi Roger, Brian, Thanks for reviewing, and long time no see :-).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2190

From alanb at openjdk.java.net  Sat Jan 23 07:55:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 23 Jan 2021 07:55:40 GMT
Subject: RFR: JDK-8260273: DataOutputStream writeChars optimization
In-Reply-To: <ve8NNCTjABCKaUb0ZcpBC2InXNxFSdi88k_zSdLIk6M=.14e89b4a-492e-4b68-bd3e-ab22f2d73ea4@github.com>
References: <ve8NNCTjABCKaUb0ZcpBC2InXNxFSdi88k_zSdLIk6M=.14e89b4a-492e-4b68-bd3e-ab22f2d73ea4@github.com>
Message-ID: <P5LApMTudy5xjbRtlHBbvJrm3SxGZCkFUtlmXWZmlGs=.d87bf028-17c6-4a6d-9274-e48ebc3cf879@github.com>

On Fri, 22 Jan 2021 02:57:36 GMT, Hamlin Li <mli at openjdk.org> wrote:

> this is minor optimization following JDK-8254078.
> based on my tests with jmh, it has better performance when apply following patch:
> 
> diff --git a/src/java.base/share/classes/java/io/DataOutputStream.java b/src/java.base/share/classes/java/io/DataOutputStream.java
> index 9a9a687403c..4ea497fc7c0 100644
> --- a/src/java.base/share/classes/java/io/DataOutputStream.java
> +++ b/src/java.base/share/classes/java/io/DataOutputStream.java
> @@ -300,8 +300,9 @@ public class DataOutputStream extends FilterOutputStream implements DataOutput {
>          int len = s.length();
>          for (int i = 0 ; i < len ; i++) {
>              int v = s.charAt(i);
> - out.write((v >>> 8) & 0xFF);
> - out.write((v >>> 0) & 0xFF);
> + writeBuffer[0] = (byte)(v >>> 8);
> + writeBuffer[1] = (byte)(v >>> 0);
> + out.write(writeBuffer, 0, 2);
>          }
>          incCount(len * 2);
>      }
> 
> Basically, it has better performance when apply above patch:
> 
> // without writeChars optimization patch, (-XX:-UseBiasedLocking)
> Benchmark (basicType) (size) Mode Cnt Score Error Units
> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 115.208 ? 0.327 us/op
> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 276.795 ? 0.449 us/op
> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 12356.969 ? 22.427 us/op
> 
> // with writeChars optimization patch, (-XX:-UseBiasedLocking)
> Benchmark (basicType) (size) Mode Cnt Score Error Units
> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 133.706 ? 0.274 us/op
> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 130.979 ? 0.155 us/op
> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 6814.272 ? 52.770 us/op
> 
> 
> // without writeChars optimization patch, (-XX:+UseBiasedLocking)
> Benchmark (basicType) (size) Mode Cnt Score Error Units
> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 130.367 ? 8.759 us/op
> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 37.559 ? 0.059 us/op
> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 12385.030 ? 376.560 us/op
> 
> // with writeChars optimization patch, (-XX:+UseBiasedLocking)
> Benchmark (basicType) (size) Mode Cnt Score Error Units
> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 45.494 ? 7.018 us/op
> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 33.015 ? 0.349 us/op
> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 6845.549 ? 38.712 us/op

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2190

From alanb at openjdk.java.net  Sat Jan 23 07:57:43 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 23 Jan 2021 07:57:43 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v4]
In-Reply-To: <ABB2Pleoo1GTfmn0SdjrztH_u6VrfPRseLfMIrYhMdg=.a576b5bc-b25b-43ee-b5d3-394bce1415ca@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>
 <YT7on7W1w9GJRTMfz2KtftKo7yGbVTgZxYcqXv1POBU=.59b49a13-da41-4c93-88c7-1830b87d0b63@github.com>
 <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com>
 <ABB2Pleoo1GTfmn0SdjrztH_u6VrfPRseLfMIrYhMdg=.a576b5bc-b25b-43ee-b5d3-394bce1415ca@github.com>
Message-ID: <ad2uU37xBO8wpE-w6Ogj3paBihqfXiKLRJ627VwNgkc=.1d6a7573-d606-4eb1-ba21-5daaf47c485c@github.com>

On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR is not stale; it's just still waiting for input from @AlanBateman.
>
> @magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang?

> @AlanBateman When I moved the charset templates, I found this gold nugget:
> 
> ```
> # Copy two Java files that need no preprocessing.
> $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java: $(CHARACTERDATA_TEMPLATES)/%.java.template
> 	$(call LogInfo, Generating $(@F))
> 	$(call install-file)
> 
> GENSRC_CHARACTERDATA += $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataUndefined.java \
>     $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataPrivateUse.java
> ```
> 
> What this means is that we have two "template" files that are just compiled as java files, but only after being copied to gensrc. :-) That definitely needs cleaning up, but this PR is large enough as it is, so I will not do it now.

Good find, surprised this wasn't spotted before now. We should create a separate issue to rename them and get rid of the copying in the make file.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1611

From aph at openjdk.java.net  Sat Jan 23 11:46:45 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Sat, 23 Jan 2021 11:46:45 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>

On Fri, 22 Jan 2021 18:49:42 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 86:

> 84: 
> 85:   switch (_num_int_args) {
> 86:   case 0:

I don't think you need such a large switch statement. I think this can be expressed as
if (num_int_args <= 6) {
    ldr(as_Register(num_int_args + 1), src);
... etc.

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 43:

> 41: //describe amount of space in bytes occupied by type on native stack
> 42: #ifdef __APPLE__
> 43:     const int nativeByteSpace        = sizeof(jbyte);

I'm not sure these names should be in the global name space, and they're not very descriptive. Something like NativeStack::byteSpace would be better. Then you can use them with a `using namespace NativeStack` declaration.

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 433:

> 431:       store_and_inc(_to, from_obj, nativeShortSpace);
> 432: 
> 433:       _num_int_args++;

Please lift this increment out of the conditional.

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 394:

> 392: 
> 393: class SlowSignatureHandler
> 394:   : public NativeSignatureIterator {

SlowSignatureHandler is turning into a maintenance nightmare. This isn't the fault of this commit so much as some nasty cut-and=paste programming in the code you're editing. It might well be better to rewrite this whole thing to use a table-driven approach, with a table that contains the increment and the size of each native type: then we'd have only a single routine which could pass data of any type, and each OS needs only supply a table of constants.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5272:

> 5270: void MacroAssembler::get_thread(Register dst) {
> 5271:   RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst;
> 5272:   push(saved_regs, sp);

This isn't very nice.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From bschlining at gmail.com  Fri Jan 22 19:31:53 2021
From: bschlining at gmail.com (Brian Schlining)
Date: Fri, 22 Jan 2021 11:31:53 -0800
Subject: bug jpackage in JDK 15
Message-ID: <CAH2-wONu7wpxBmgKL8qx3cB+NWfnNLw-XTqCMLqnUZ2JjuDtkA@mail.gmail.com>

Hi everyone,

I'm running into a bug with jpackage. I have a mac app that builds just
fine using jdk14's jpackage. However, using jdk15's jpackage the built app
doesn't run. The tl;dr is that the built executable from jdk15  throws in
an extra "Contents" directory in one of its paths: e.g.

"[...]/VARS Annotation.app/Contents/Contents/app/VARS Annotation.cfg" #
JDK15
"[...]/VARS Annotation.app/Contents/app/VARS Annotation.cfg" # JDK14

I've put the details for the bug in an issue at
https://github.com/mbari-media-management/vars-annotation/issues/123

--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlining at gmail.com

From mik3hall at gmail.com  Sat Jan 23 12:02:23 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 23 Jan 2021 06:02:23 -0600
Subject: bug jpackage in JDK 15
In-Reply-To: <CAH2-wONu7wpxBmgKL8qx3cB+NWfnNLw-XTqCMLqnUZ2JjuDtkA@mail.gmail.com>
References: <CAH2-wONu7wpxBmgKL8qx3cB+NWfnNLw-XTqCMLqnUZ2JjuDtkA@mail.gmail.com>
Message-ID: <0DF4D073-FAD7-4708-AECE-51BD0720957F@gmail.com>


> 
> "[...]/VARS Annotation.app/Contents/Contents/app/VARS Annotation.cfg" #
> JDK15
> "[...]/VARS Annotation.app/Contents/app/VARS Annotation.cfg" # JDK14
> 

Any chance the embedded blank in the app name is throwing something off?


From mik3hall at gmail.com  Sun Jan 24 01:07:29 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 23 Jan 2021 19:07:29 -0600
Subject: bug jpackage in JDK 15
In-Reply-To: <0DF4D073-FAD7-4708-AECE-51BD0720957F@gmail.com>
References: <CAH2-wONu7wpxBmgKL8qx3cB+NWfnNLw-XTqCMLqnUZ2JjuDtkA@mail.gmail.com>
 <0DF4D073-FAD7-4708-AECE-51BD0720957F@gmail.com>
Message-ID: <C7A06A93-AF65-4379-8D82-445893891E04@gmail.com>



> On Jan 23, 2021, at 6:02 AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
>> 
>> "[...]/VARS Annotation.app/Contents/Contents/app/VARS Annotation.cfg" #
>> JDK15
>> "[...]/VARS Annotation.app/Contents/app/VARS Annotation.cfg" # JDK14
>> 
> 
> Any chance the embedded blank in the app name is throwing something off?
> 



I installed jdk 15 and am not seeing this problem. Including with a embedded blank app name.
	--name BlackJack\ Blastoff \

When I open the built dmg there is an application icon, a drag to indicating arrow, but no application folder icon as the drag target.

Possibly related?

Running [osascript, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack Blastoff-dmg-setup.scpt]
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack Blastoff-dmg-setup.scpt:1112:1334: execution error: Finder got an error: Can?t make class alias file. (-2710)
java.io.IOException: Command [osascript, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack Blastoff-dmg-setup.scpt] exited with 1 code
	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Executor.executeExpectSuccess(Executor.java:75)
	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:167)
	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:135)
	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.buildDMG(MacDmgBundler.java:393)
	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.bundle(MacDmgBundler.java:91)
	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.execute(MacDmgBundler.java:535)
	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:680)
	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:549)
	at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:98)
	at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:52)

Also it seems...
--add-modules java.desktop,java.prefs,java.se \

Is no longer an option?
?help doesn?t show it and I end up with?
java-options=--module-path

In the .cfg






From mik3hall at gmail.com  Sun Jan 24 01:10:27 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 23 Jan 2021 19:10:27 -0600
Subject: bug jpackage in JDK 15
In-Reply-To: <C7A06A93-AF65-4379-8D82-445893891E04@gmail.com>
References: <CAH2-wONu7wpxBmgKL8qx3cB+NWfnNLw-XTqCMLqnUZ2JjuDtkA@mail.gmail.com>
 <0DF4D073-FAD7-4708-AECE-51BD0720957F@gmail.com>
 <C7A06A93-AF65-4379-8D82-445893891E04@gmail.com>
Message-ID: <945C6541-A343-4E33-BE4B-5DBEFD42679B@gmail.com>



> On Jan 23, 2021, at 7:07 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Jan 23, 2021, at 6:02 AM, Michael Hall <mik3hall at gmail.com> wrote:
>> 
>> 
>>> 
>>> "[...]/VARS Annotation.app/Contents/Contents/app/VARS Annotation.cfg" #
>>> JDK15
>>> "[...]/VARS Annotation.app/Contents/app/VARS Annotation.cfg" # JDK14
>>> 
>> 
>> Any chance the embedded blank in the app name is throwing something off?
>> 
> 
> 
> 
> I installed jdk 15 and am not seeing this problem. Including with a embedded blank app name.
> 	--name BlackJack\ Blastoff \
> 

Versions if apply

...jpackage --version
WARNING: Using incubator modules: jdk.incubator.jpackage
15.0.2

macOS Catalina 10.15.7


From mik3hall at gmail.com  Sun Jan 24 01:32:14 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 23 Jan 2021 19:32:14 -0600
Subject: bug jpackage in JDK 15
In-Reply-To: <C7A06A93-AF65-4379-8D82-445893891E04@gmail.com>
References: <CAH2-wONu7wpxBmgKL8qx3cB+NWfnNLw-XTqCMLqnUZ2JjuDtkA@mail.gmail.com>
 <0DF4D073-FAD7-4708-AECE-51BD0720957F@gmail.com>
 <C7A06A93-AF65-4379-8D82-445893891E04@gmail.com>
Message-ID: <D8C993A5-7B83-4B13-BAA5-645B2C62613C@gmail.com>



> On Jan 23, 2021, at 7:07 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> Also it seems...
> --add-modules java.desktop,java.prefs,java.se <http://java.se/> \
> 
> Is no longer an option?
> ?help doesn?t show it and I end up with?
> java-options=--module-path
> 
> In the .cfg

Sorry, checked again and that is still in ?help, probably not passed on to the cfg though?
The empty ?module-path java option is probably unrelated. 



From bschlining at gmail.com  Sun Jan 24 06:46:02 2021
From: bschlining at gmail.com (Brian Schlining)
Date: Sat, 23 Jan 2021 22:46:02 -0800
Subject: bug jpackage in JDK 15
In-Reply-To: <0DF4D073-FAD7-4708-AECE-51BD0720957F@gmail.com>
References: <CAH2-wONu7wpxBmgKL8qx3cB+NWfnNLw-XTqCMLqnUZ2JjuDtkA@mail.gmail.com>
 <0DF4D073-FAD7-4708-AECE-51BD0720957F@gmail.com>
Message-ID: <CAH2-wOPZ9_-Lbt9jAaNZxYa4ROpqVZ0XAc90e+7uXv8BbOJ_AA@mail.gmail.com>

In case it's helpful,I'm using a gradle plugin,
https://badass-jlink-plugin.beryx.org,  to generate the jpackage command.
Here's the full jpackage command that's created and used.:

/Library/Java/JavaVirtualMachines/openjdk.jdk/Contents/Home/bin/jpackage
--type app-image --dest
/Users/brian/workspace/M3/vars-annotation/org.mbari.vars.ui/build/jpackage
--name 'VARS Annotation' --module org.mbari.vars.ui/org.mbari.vars.ui.App
--app-version 1.0.0 --runtime-image
/Users/brian/workspace/M3/vars-annotation/org.mbari.vars.ui/build/image
--java-options -Xms1g --java-options --add-exports --java-options
javafx.base/com.sun.javafx.binding=com.jfoenix --java-options --add-exports
--java-options javafx.base/com.sun.javafx.event=com.jfoenix --java-options
--add-exports --java-options
javafx.controls/com.sun.javafx.scene.control.behavior=com.jfoenix
--java-options --add-exports --java-options
javafx.controls/com.sun.javafx.scene.control=com.jfoenix --java-options
--add-exports --java-options
javafx.graphics/com.sun.javafx.stage=com.jfoenix --java-options --add-opens
--java-options java.base/java.lang.invoke=retrofit2 --java-options
--add-opens --java-options
java.base/java.lang.invoke=vars.annotation.merged.module --java-options
--add-opens --java-options java.base/java.lang.reflect=com.jfoenix
--java-options --add-reads --java-options
vars.annotation.merged.module=org.slf4j --icon 'src/jpackage/macos/VARS
Annotation.icns'

On Sat, Jan 23, 2021 at 4:02 AM Michael Hall <mik3hall at gmail.com> wrote:

>
> >
> > "[...]/VARS Annotation.app/Contents/Contents/app/VARS Annotation.cfg" #
> > JDK15
> > "[...]/VARS Annotation.app/Contents/app/VARS Annotation.cfg" # JDK14
> >
>
> Any chance the embedded blank in the app name is throwing something off?
>
>

-- 
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlining at gmail.com

From mik3hall at gmail.com  Sun Jan 24 13:37:26 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 24 Jan 2021 07:37:26 -0600
Subject: bug jpackage in JDK 15
In-Reply-To: <CAH2-wOPZ9_-Lbt9jAaNZxYa4ROpqVZ0XAc90e+7uXv8BbOJ_AA@mail.gmail.com>
References: <CAH2-wONu7wpxBmgKL8qx3cB+NWfnNLw-XTqCMLqnUZ2JjuDtkA@mail.gmail.com>
 <0DF4D073-FAD7-4708-AECE-51BD0720957F@gmail.com>
 <CAH2-wOPZ9_-Lbt9jAaNZxYa4ROpqVZ0XAc90e+7uXv8BbOJ_AA@mail.gmail.com>
Message-ID: <44985368-4120-4F70-BE32-E811A99DA94B@gmail.com>


--name 'VARS Annotation? 

You are using a name with an embedded blank but that didn?t seem to cause me any problems.

I didn?t recreate, maybe if I get a chance I?ll try to see if anything else in your invocation seems to trigger what you?re seeing.

From mik3hall at gmail.com  Sun Jan 24 14:27:37 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 24 Jan 2021 08:27:37 -0600
Subject: bug jpackage in JDK 15
In-Reply-To: <44985368-4120-4F70-BE32-E811A99DA94B@gmail.com>
References: <CAH2-wONu7wpxBmgKL8qx3cB+NWfnNLw-XTqCMLqnUZ2JjuDtkA@mail.gmail.com>
 <0DF4D073-FAD7-4708-AECE-51BD0720957F@gmail.com>
 <CAH2-wOPZ9_-Lbt9jAaNZxYa4ROpqVZ0XAc90e+7uXv8BbOJ_AA@mail.gmail.com>
 <44985368-4120-4F70-BE32-E811A99DA94B@gmail.com>
Message-ID: <F1713D97-F08E-41A3-956C-D05A1C402818@gmail.com>



> On Jan 24, 2021, at 7:37 AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> --name 'VARS Annotation? 
> 
> You are using a name with an embedded blank but that didn?t seem to cause me any problems.
> 
> I didn?t recreate, maybe if I get a chance I?ll try to see if anything else in your invocation seems to trigger what you?re seeing.

This is about as close to yours as I think I can get and I didn?t recreate, it is how I run mine shell script?

#!/bin/bash

set -e

PACKAGER=`/usr/libexec/java_home`/bin/jpackage

${PACKAGER} --version

echo 'remove prior dist'
rm -rf outputdir
mkdir outputdir

#	--install-dir outputdir \
#   --add-modules java.desktop,java.prefs,java.se \

${PACKAGER} \
	--verbose \
	--type app-image \
	--input ./input \
	--dest outputdir \
	--app-version 1.0.0  \
	--name BlackJack\ Blastoff \
	--main-jar bjb.jar \
	--main-class org.bjb.BlackJackApp \
	--runtime-image /Library/Java/JavaVirtualMachines/jdk-14.jdk/Contents/Home \
	--java-options '-Xmx1024m -XX:+UseG1GC -XX:MaxGCPauseMillis=50  -Dapple.laf.useScreenMenuBar=true -Dcom.apple.mrj.application.apple.menu.about.name=BlackjackBlastoff -Dapple.awt.application.name=Blackjack\ Blastoff' \
	--icon /Users/mjh/HalfPipe/HalfPipe_jpkg/GenericApp.icns
	 
#	--mac-sign \
#	--mac-signing-key-user-name "Michael Hall?

I think is about everything you had except different ?java-options, mine of course excluding your modular related.

ls "outputdir/BlackJack Blastoff.app?

Contents

ls "outputdir/BlackJack Blastoff.app/Contents"
Info.plist	MacOS		PkgInfo		Resources	app		runtime

If you use /usr/libexec/java_home you can get the current jdk and not need to hardcode the path into JavaVirtualMachines. It looks like you only maintain one version of the JDK, the release appeared stripped in your path? This also allows you to run other versions if you want like?

/usr/libexec/java_home -v 14 --exec jpackage --version
WARNING: Using incubator modules: jdk.incubator.jpackage
14.0.2

If of interest to anyone I still haven?t figured out signing. It errored giving some indication that the JDK had already been signed? I posted that sometime back. I keep meaning to look at what there is for testing but haven?t yet. Any thoughts on that would still be appreciated.





From akozlov at openjdk.java.net  Sun Jan 24 15:32:59 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Sun, 24 Jan 2021 15:32:59 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:

 - Address feedback for signature generators
 - Enable -Wformat-nonliteral back

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/3d4f4c23..50b55f66

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=00-01

  Stats: 204 lines in 2 files changed: 20 ins; 138 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Sun Jan 24 15:37:43 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Sun, 24 Jan 2021 15:37:43 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <_l6v7_5ODWCmW5x90hA_Vv0TegGm00YW98ELrJvi65o=.1b2d4f0f-0791-4d4f-bf00-d829738611b5@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <_l6v7_5ODWCmW5x90hA_Vv0TegGm00YW98ELrJvi65o=.1b2d4f0f-0791-4d4f-bf00-d829738611b5@github.com>
Message-ID: <MylmP-IiIBnIAr9adMFRhhr4DBaZQmIM1refrIQMLVE=.0fc0d779-8c56-45ee-9adb-338fdc6ecb70@github.com>

On Fri, 22 Jan 2021 20:18:51 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> make/autoconf/flags-cflags.m4 line 169:
> 
>> 167:       WARNINGS_ENABLE_ALL="-Wall -Wextra -Wformat=2 $WARNINGS_ENABLE_ADDITIONAL"
>> 168: 
>> 169:       DISABLED_WARNINGS="unknown-warning-option unused-parameter unused format-nonliteral"
> 
> Globally disabling a warning needs some motivation. Why is this needed? Does it really need to be applied everywhere or is there a specific binary or source file where this is triggered?

It seems to be a leftover from the past. I tried to revert the line and the build went fine. Thanks for noticing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Sun Jan 24 15:52:44 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Sun, 24 Jan 2021 15:52:44 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
Message-ID: <FIAu02KPkeT8mjt2BKIcVnei38gRk3aoXWTfpIvFhos=.773b9848-15d8-45b5-9669-4df8ca65b2d0@github.com>

On Sat, 23 Jan 2021 11:10:17 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 86:
> 
>> 84: 
>> 85:   switch (_num_int_args) {
>> 86:   case 0:
> 
> I don't think you need such a large switch statement. I think this can be expressed as
> if (num_int_args <= 6) {
>     ldr(as_Register(num_int_args + r1.encoding()), src);
> ... etc.

I like the suggestion. For the defense, new functions were made this way intentionally, to match existing `pass_int`, `pass_long`,.. I take your comment as a blessing to fix all of them. But I feel that refactoring of existing code should go in a separate commit. Especially after `pass_int` used `ldr/str` instead of `ldrw/strw`, which looks wrong. https://github.com/openjdk/jdk/pull/2200/files#diff-1ff58ce70aeea7e9842d34e8d8fd9c94dd91182999d455618b2a171efd8f742cL87-R122

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Sun Jan 24 16:13:42 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Sun, 24 Jan 2021 16:13:42 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
Message-ID: <h9On7_RFadcLwhW15R4Jig9PZ0y9JoMI2diiqXv99eY=.9b814ff7-64cf-496f-a507-0a8f86070c2d@github.com>

On Sat, 23 Jan 2021 11:42:48 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 394:
> 
>> 392: 
>> 393: class SlowSignatureHandler
>> 394:   : public NativeSignatureIterator {
> 
> SlowSignatureHandler is turning into a maintenance nightmare. This isn't the fault of this commit so much as some nasty cut-and-paste programming in the code you're editing. It might well be better to rewrite this whole thing to use a table-driven approach, with a table that contains the increment and the size of each native type: then we'd have only a single routine which could pass data of any type, and each OS needs only supply a table of constants.

Would you like me to do something about it now? The problem is that the functions of SlowSignatureHandler are subtly different, so it will be multiple tables, not sure how many. Such change is another candidate for a separate code enhancement, which I would like not to mix into the JEP implementation (it's already not a small change :)). But if you think it would be a good thing, please let me know. In another case, I'll add this to a queue of follow-up enhancements.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From vkempik at openjdk.java.net  Sun Jan 24 16:32:41 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Sun, 24 Jan 2021 16:32:41 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
Message-ID: <UubbyJKBR24lG2v3vsTotl7bRFQrHWypAM58MRRy5Tc=.15f12745-172c-401e-8966-2e5b7137b9fc@github.com>

On Sat, 23 Jan 2021 11:43:31 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5272:
> 
>> 5270: void MacroAssembler::get_thread(Register dst) {
>> 5271:   RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst;
>> 5272:   push(saved_regs, sp);
> 
> This isn't very nice.

Hello
Why is it not nice ?
linux_aarch64 uses some linux specific tls function _ZN10JavaThread25aarch64_get_thread_helperEv from hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.s
which clobbers only r0 and r1
macos_aarch64 has no such tls code and uses generic C-call to Thread::current();
Hence we  are saving possibly clobbered regs here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From martin at openjdk.java.net  Sun Jan 24 19:31:43 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sun, 24 Jan 2021 19:31:43 GMT
Subject: RFR: 8247373: ArraysSupport.newLength doc, test,
 and exception message [v2]
In-Reply-To: <vduFDk-pM0S_d9tKgHGYnUM2hCowtIGUW0FuQgBzGts=.20b9de69-7985-428a-ae28-645d6699e02d@github.com>
References: <D9oU9mGK5su1atHT64_Hf8f3ZRF2rN1E8pueDRYlOHA=.067ec1c2-4fb9-4b06-82e5-e3243d2e065f@github.com>
 <vduFDk-pM0S_d9tKgHGYnUM2hCowtIGUW0FuQgBzGts=.20b9de69-7985-428a-ae28-645d6699e02d@github.com>
Message-ID: <PokwmHaY1BFHZ6I2Br3ccJuKJfLajZT4abM91cva4wQ=.30002119-4fad-4b16-8e7a-94e352aaeb79@github.com>

On Tue, 8 Dec 2020 06:14:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code:
>> 
>> 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs!
>> 
>> 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length.
>> 
>> Separately, I'll work on retrofitting various call sites around the JDK to use this method.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo, clarify asserts disabled, test prefGrowth==0

Many years ago, when I wrote the unfactored MAX_ARRAY_LENGTH code, I considered refactoring it, but didn't follow through because various implementations had too many small differences .  I'm glad you made it work.

I'm happy to see good tests added.  Testability is a benefit of refactoring.

I'm happy to see the name change to SOFT_MAX_ARRAY_LENGTH - that's a better name.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1617

From martin at openjdk.java.net  Sun Jan 24 19:47:42 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sun, 24 Jan 2021 19:47:42 GMT
Subject: RFR: 8247373: ArraysSupport.newLength doc, test,
 and exception message [v2]
In-Reply-To: <efcrBtYUIYQuIZMr2iaEglQNwL88xoLfWCRKFFMyDV8=.7bc35a91-bba1-4d8f-9c28-847d5162ae71@github.com>
References: <D9oU9mGK5su1atHT64_Hf8f3ZRF2rN1E8pueDRYlOHA=.067ec1c2-4fb9-4b06-82e5-e3243d2e065f@github.com>
 <vduFDk-pM0S_d9tKgHGYnUM2hCowtIGUW0FuQgBzGts=.20b9de69-7985-428a-ae28-645d6699e02d@github.com>
 <efcrBtYUIYQuIZMr2iaEglQNwL88xoLfWCRKFFMyDV8=.7bc35a91-bba1-4d8f-9c28-847d5162ae71@github.com>
Message-ID: <6XEqIAUVNTR9JPHUBgvZktmmqD2ycRbbQmVi5KSVSr8=.f67eb40f-1efc-4634-abab-d7e8e43c5bb1@github.com>

On Wed, 9 Dec 2020 00:32:37 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typo, clarify asserts disabled, test prefGrowth==0
>
> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 616:
> 
>> 614:      * greater than the soft maximum but does not exceed Integer.MAX_VALUE, the minimum
>> 615:      * required length is returned. Otherwise, the minimum required length exceeds
>> 616:      * Integer.MAX_VALUE, which can never be fulfilled, so this method throws OutOfMemoryError.
> 
> I think you can simplify with:
> 
> Suggestion:
> 
>      * If the preferred length exceeds the soft maximum, we use the minimum growth
>      * amount. The minimum required length is determined by adding the minimum growth
>      * amount to the current length. 
>      * If the minimum required length exceeds Integer.MAX_VALUE, then this method 
>      * throws OutOfMemoryError. Otherwise, this method returns the soft maximum or
>      * minimum required length, which ever is greater.
> 
> Then i think it follows that `Math.max` can be used in the implementation.

I agree with Paul's comment of Dec 8.  Especially the s/Since/If/

I would amend with s/which ever/whichever/ but that might be my dialect of North American

-------------

PR: https://git.openjdk.java.net/jdk/pull/1617

From martin at openjdk.java.net  Sun Jan 24 19:50:43 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sun, 24 Jan 2021 19:50:43 GMT
Subject: RFR: 8247373: ArraysSupport.newLength doc, test,
 and exception message [v2]
In-Reply-To: <vduFDk-pM0S_d9tKgHGYnUM2hCowtIGUW0FuQgBzGts=.20b9de69-7985-428a-ae28-645d6699e02d@github.com>
References: <D9oU9mGK5su1atHT64_Hf8f3ZRF2rN1E8pueDRYlOHA=.067ec1c2-4fb9-4b06-82e5-e3243d2e065f@github.com>
 <vduFDk-pM0S_d9tKgHGYnUM2hCowtIGUW0FuQgBzGts=.20b9de69-7985-428a-ae28-645d6699e02d@github.com>
Message-ID: <HYZSqcwM0E-E6gy4n48G8KTU1nYEoegrX8VEz9VhQQU=.1c86b245-33f8-4d64-abda-5903573b3f25@github.com>

On Tue, 8 Dec 2020 06:14:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code:
>> 
>> 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs!
>> 
>> 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length.
>> 
>> Separately, I'll work on retrofitting various call sites around the JDK to use this method.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo, clarify asserts disabled, test prefGrowth==0

src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 631:

> 629:      * @param minGrowth   minimum required growth amount (must be positive)
> 630:      * @param prefGrowth  preferred growth amount
> 631:      * @return the new length of the array

Slightly better seems s/@return the new length of the array/@return the new array length/

-------------

PR: https://git.openjdk.java.net/jdk/pull/1617

From martin at openjdk.java.net  Sun Jan 24 20:04:08 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sun, 24 Jan 2021 20:04:08 GMT
Subject: RFR: 8247373: ArraysSupport.newLength doc, test,
 and exception message [v2]
In-Reply-To: <vduFDk-pM0S_d9tKgHGYnUM2hCowtIGUW0FuQgBzGts=.20b9de69-7985-428a-ae28-645d6699e02d@github.com>
References: <D9oU9mGK5su1atHT64_Hf8f3ZRF2rN1E8pueDRYlOHA=.067ec1c2-4fb9-4b06-82e5-e3243d2e065f@github.com>
 <vduFDk-pM0S_d9tKgHGYnUM2hCowtIGUW0FuQgBzGts=.20b9de69-7985-428a-ae28-645d6699e02d@github.com>
Message-ID: <WTsiKI_rFhHAGhUVmwQyKaLhq1afbwX0GAQxuHWVwVQ=.25911d61-959f-4b07-8179-5f1d08364109@github.com>

On Tue, 8 Dec 2020 06:14:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code:
>> 
>> 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs!
>> 
>> 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length.
>> 
>> Separately, I'll work on retrofitting various call sites around the JDK to use this method.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo, clarify asserts disabled, test prefGrowth==0

src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 643:

> 641:             return prefLength;
> 642:         } else {
> 643:             return hugeLength(oldLength, minGrowth);

Could add a comment like
// outline cold code

-------------

PR: https://git.openjdk.java.net/jdk/pull/1617

From martin at openjdk.java.net  Sun Jan 24 20:07:43 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sun, 24 Jan 2021 20:07:43 GMT
Subject: RFR: 8247373: ArraysSupport.newLength doc, test,
 and exception message [v2]
In-Reply-To: <W8oQznvbcD_xsoJdWvsGT9MQXAoc2guH9SbqB9fv5O0=.8d0b1331-e5a2-40c6-9561-c95bc0a4e971@github.com>
References: <D9oU9mGK5su1atHT64_Hf8f3ZRF2rN1E8pueDRYlOHA=.067ec1c2-4fb9-4b06-82e5-e3243d2e065f@github.com>
 <vBHIVipclM-0h7dBAwnx_ZQnPiICgidhQkEo6-g6Q98=.47da17a6-d869-45b1-bd84-a412e925bb80@github.com>
 <W8oQznvbcD_xsoJdWvsGT9MQXAoc2guH9SbqB9fv5O0=.8d0b1331-e5a2-40c6-9561-c95bc0a4e971@github.com>
Message-ID: <lx1E7Em7J6KSmj2vlLggMd6b0dz7U1tbwRdR80et4gY=.a69bd09e-1b71-40cb-b24a-65a294b82721@github.com>

On Fri, 4 Dec 2020 17:31:20 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 654:
>> 
>>> 652:             return SOFT_MAX_ARRAY_LENGTH;
>>> 653:         } else {
>>> 654:             return minLength;
>> 
>> Isn't this last `else if... then.. else` the same as:
>> `return Math.max(minLength, SOFT_MAX_ARRAY_LENGTH)`
>
> It is, and I considered replacing it, but I felt that it obscured what was going on.

Competing parts of Martin's brain are voting for Roger's and Stuart's versions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1617

From martin at openjdk.java.net  Sun Jan 24 20:16:45 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sun, 24 Jan 2021 20:16:45 GMT
Subject: RFR: 8247373: ArraysSupport.newLength doc, test,
 and exception message [v2]
In-Reply-To: <vduFDk-pM0S_d9tKgHGYnUM2hCowtIGUW0FuQgBzGts=.20b9de69-7985-428a-ae28-645d6699e02d@github.com>
References: <D9oU9mGK5su1atHT64_Hf8f3ZRF2rN1E8pueDRYlOHA=.067ec1c2-4fb9-4b06-82e5-e3243d2e065f@github.com>
 <vduFDk-pM0S_d9tKgHGYnUM2hCowtIGUW0FuQgBzGts=.20b9de69-7985-428a-ae28-645d6699e02d@github.com>
Message-ID: <dyw4QM_3WhlV3CMtkZJZAEF89xJQvk93IwPZYfufgKA=.4211469e-ba99-4d43-a94a-a408b5d5119c@github.com>

On Tue, 8 Dec 2020 06:14:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code:
>> 
>> 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs!
>> 
>> 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length.
>> 
>> Separately, I'll work on retrofitting various call sites around the JDK to use this method.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo, clarify asserts disabled, test prefGrowth==0

Marked as reviewed by martin (Reviewer).

test/jdk/jdk/internal/util/ArraysSupport/NewLength.java line 101:

> 99:             fail("expected OutOfMemoryError, got normal return value of " + r);
> 100:         } catch (OutOfMemoryError oome) {
> 101:             // ok

Instead of an //ok comment, I like to give the exception a name that makes the intent clear.

} catch (IllegalArgumentException success) {}

-------------

PR: https://git.openjdk.java.net/jdk/pull/1617

From martin at openjdk.java.net  Sun Jan 24 20:19:42 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sun, 24 Jan 2021 20:19:42 GMT
Subject: RFR: 8247373: ArraysSupport.newLength doc, test,
 and exception message [v2]
In-Reply-To: <dyw4QM_3WhlV3CMtkZJZAEF89xJQvk93IwPZYfufgKA=.4211469e-ba99-4d43-a94a-a408b5d5119c@github.com>
References: <D9oU9mGK5su1atHT64_Hf8f3ZRF2rN1E8pueDRYlOHA=.067ec1c2-4fb9-4b06-82e5-e3243d2e065f@github.com>
 <vduFDk-pM0S_d9tKgHGYnUM2hCowtIGUW0FuQgBzGts=.20b9de69-7985-428a-ae28-645d6699e02d@github.com>
 <dyw4QM_3WhlV3CMtkZJZAEF89xJQvk93IwPZYfufgKA=.4211469e-ba99-4d43-a94a-a408b5d5119c@github.com>
Message-ID: <MuxHRVSGH7U-7u4vxgeI7AxOWKvli90FkJXW6gS2xyM=.ead15b71-d4c0-4331-b6c5-e5e4fa01917c@github.com>

On Sun, 24 Jan 2021 20:14:04 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typo, clarify asserts disabled, test prefGrowth==0
>
> Marked as reviewed by martin (Reviewer).

The new docs and tests are superb.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1617

From andy.herrick at oracle.com  Sun Jan 24 21:19:15 2021
From: andy.herrick at oracle.com (Andy Herrick)
Date: Sun, 24 Jan 2021 16:19:15 -0500
Subject: bug jpackage in JDK 15
In-Reply-To: <CAH2-wOPZ9_-Lbt9jAaNZxYa4ROpqVZ0XAc90e+7uXv8BbOJ_AA@mail.gmail.com>
References: <CAH2-wONu7wpxBmgKL8qx3cB+NWfnNLw-XTqCMLqnUZ2JjuDtkA@mail.gmail.com>
 <0DF4D073-FAD7-4708-AECE-51BD0720957F@gmail.com>
 <CAH2-wOPZ9_-Lbt9jAaNZxYa4ROpqVZ0XAc90e+7uXv8BbOJ_AA@mail.gmail.com>
Message-ID: <1455c71f-45fb-d078-3dd4-f0439449432c@oracle.com>

Can you try with ea version of JDK16 from 
https://download.java.net/java/early_access/alpine/32/binaries/openjdk-16-ea+32_linux-x64-musl_bin.tar.gz 
<https://download.java.net/java/early_access/alpine/32/binaries/openjdk-16-ea+32_linux-x64-musl_bin.tar.gz> 
?

/Andy

On 1/24/2021 1:46 AM, Brian Schlining wrote:
> In case it's helpful,I'm using a gradle plugin,
> https://badass-jlink-plugin.beryx.org,  to generate the jpackage command.
> Here's the full jpackage command that's created and used.:
>
> /Library/Java/JavaVirtualMachines/openjdk.jdk/Contents/Home/bin/jpackage
> --type app-image --dest
> /Users/brian/workspace/M3/vars-annotation/org.mbari.vars.ui/build/jpackage
> --name 'VARS Annotation' --module org.mbari.vars.ui/org.mbari.vars.ui.App
> --app-version 1.0.0 --runtime-image
> /Users/brian/workspace/M3/vars-annotation/org.mbari.vars.ui/build/image
> --java-options -Xms1g --java-options --add-exports --java-options
> javafx.base/com.sun.javafx.binding=com.jfoenix --java-options --add-exports
> --java-options javafx.base/com.sun.javafx.event=com.jfoenix --java-options
> --add-exports --java-options
> javafx.controls/com.sun.javafx.scene.control.behavior=com.jfoenix
> --java-options --add-exports --java-options
> javafx.controls/com.sun.javafx.scene.control=com.jfoenix --java-options
> --add-exports --java-options
> javafx.graphics/com.sun.javafx.stage=com.jfoenix --java-options --add-opens
> --java-options java.base/java.lang.invoke=retrofit2 --java-options
> --add-opens --java-options
> java.base/java.lang.invoke=vars.annotation.merged.module --java-options
> --add-opens --java-options java.base/java.lang.reflect=com.jfoenix
> --java-options --add-reads --java-options
> vars.annotation.merged.module=org.slf4j --icon 'src/jpackage/macos/VARS
> Annotation.icns'
>
> On Sat, Jan 23, 2021 at 4:02 AM Michael Hall <mik3hall at gmail.com> wrote:
>
>>> "[...]/VARS Annotation.app/Contents/Contents/app/VARS Annotation.cfg" #
>>> JDK15
>>> "[...]/VARS Annotation.app/Contents/app/VARS Annotation.cfg" # JDK14
>>>
>> Any chance the embedded blank in the app name is throwing something off?
>>
>>

From andy.herrick at oracle.com  Sun Jan 24 21:47:16 2021
From: andy.herrick at oracle.com (Andy Herrick)
Date: Sun, 24 Jan 2021 16:47:16 -0500
Subject: bug jpackage in JDK 15
In-Reply-To: <CAH2-wONu7wpxBmgKL8qx3cB+NWfnNLw-XTqCMLqnUZ2JjuDtkA@mail.gmail.com>
References: <CAH2-wONu7wpxBmgKL8qx3cB+NWfnNLw-XTqCMLqnUZ2JjuDtkA@mail.gmail.com>
Message-ID: <117dc4ee-fd7b-d73e-e463-538ff89dc2b4@oracle.com>

I can reproduce with simple app using current JDK17 repository.

I have files bug https://bugs.openjdk.java.net/browse/JDK-8260335 and 
will look into this week

/Andy

On 1/22/2021 2:31 PM, Brian Schlining wrote:
> Hi everyone,
>
> I'm running into a bug with jpackage. I have a mac app that builds just
> fine using jdk14's jpackage. However, using jdk15's jpackage the built app
> doesn't run. The tl;dr is that the built executable from jdk15  throws in
> an extra "Contents" directory in one of its paths: e.g.
>
> "[...]/VARS Annotation.app/Contents/Contents/app/VARS Annotation.cfg" #
> JDK15
> "[...]/VARS Annotation.app/Contents/app/VARS Annotation.cfg" # JDK14
>
> I've put the details for the bug in an issue at
> https://github.com/mbari-media-management/vars-annotation/issues/123
>
> --
> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
> Brian Schlining
> bschlining at gmail.com

From david.holmes at oracle.com  Mon Jan 25 00:27:12 2021
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 25 Jan 2021 10:27:12 +1000
Subject: RFR: 8258917: NativeMemoryTracking is handled by launcher
 inconsistenly [v2]
In-Reply-To: <-STJkd8IWoyAlEMa8eXTq87Zx4W-rX49GEtgMTtzz7A=.90936ec1-a1b4-401a-903c-86c6da7df44f@github.com>
References: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
 <1ojc6R4Tkg2oSXjEb7Y2nrvb-fcoZICYVckWdkcQ3FA=.f6ad204e-ff50-4669-a17e-8bf037e0d18f@github.com>
 <9YSxbXm9PS0nI-nLOCayqUooZDOpuIz50AeuiHwGT04=.53a3951a-b5aa-4e17-804c-9588fb1ce801@github.com>
 <-STJkd8IWoyAlEMa8eXTq87Zx4W-rX49GEtgMTtzz7A=.90936ec1-a1b4-401a-903c-86c6da7df44f@github.com>
Message-ID: <a299ce1f-5ede-0cd4-9c37-a60e59a3bd06@oracle.com>

Alex,

On 20/01/2021 11:47 am, Alex Menkov wrote:
> On Tue, 19 Jan 2021 23:16:30 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> What do you mean by this? The -J args are not "translated" here but later in TranslateApplicationArgs.
> 
> I meant that they are translated in TranslateApplicationArgs. Looks like it's not clear. Updated the comment as you suggested.

You integrated this change but neither Zhengyu nor myself approved the 
final changes. Zhengyu's Review was prior to the logic fix, and my 
comment "this seems functionally correct" was just a comment and we were 
still discussing the overhead aspect of this.

David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2106
> 

From mli at openjdk.java.net  Mon Jan 25 01:08:41 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 25 Jan 2021 01:08:41 GMT
Subject: RFR: JDK-8260273: DataOutputStream writeChars optimization
In-Reply-To: <P5LApMTudy5xjbRtlHBbvJrm3SxGZCkFUtlmXWZmlGs=.d87bf028-17c6-4a6d-9274-e48ebc3cf879@github.com>
References: <ve8NNCTjABCKaUb0ZcpBC2InXNxFSdi88k_zSdLIk6M=.14e89b4a-492e-4b68-bd3e-ab22f2d73ea4@github.com>
 <P5LApMTudy5xjbRtlHBbvJrm3SxGZCkFUtlmXWZmlGs=.d87bf028-17c6-4a6d-9274-e48ebc3cf879@github.com>
Message-ID: <3e0-lNyMM977UM60pRXA_wFBT6Y8CpU_v81O5Szg_uw=.1da2346f-e695-4920-8399-14a8df855a6f@github.com>

On Sat, 23 Jan 2021 07:52:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> this is minor optimization following JDK-8254078.
>> based on my tests with jmh, it has better performance when apply following patch:
>> 
>> diff --git a/src/java.base/share/classes/java/io/DataOutputStream.java b/src/java.base/share/classes/java/io/DataOutputStream.java
>> index 9a9a687403c..4ea497fc7c0 100644
>> --- a/src/java.base/share/classes/java/io/DataOutputStream.java
>> +++ b/src/java.base/share/classes/java/io/DataOutputStream.java
>> @@ -300,8 +300,9 @@ public class DataOutputStream extends FilterOutputStream implements DataOutput {
>>          int len = s.length();
>>          for (int i = 0 ; i < len ; i++) {
>>              int v = s.charAt(i);
>> - out.write((v >>> 8) & 0xFF);
>> - out.write((v >>> 0) & 0xFF);
>> + writeBuffer[0] = (byte)(v >>> 8);
>> + writeBuffer[1] = (byte)(v >>> 0);
>> + out.write(writeBuffer, 0, 2);
>>          }
>>          incCount(len * 2);
>>      }
>> 
>> Basically, it has better performance when apply above patch:
>> 
>> // without writeChars optimization patch, (-XX:-UseBiasedLocking)
>> Benchmark (basicType) (size) Mode Cnt Score Error Units
>> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 115.208 ? 0.327 us/op
>> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 276.795 ? 0.449 us/op
>> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 12356.969 ? 22.427 us/op
>> 
>> // with writeChars optimization patch, (-XX:-UseBiasedLocking)
>> Benchmark (basicType) (size) Mode Cnt Score Error Units
>> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 133.706 ? 0.274 us/op
>> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 130.979 ? 0.155 us/op
>> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 6814.272 ? 52.770 us/op
>> 
>> 
>> // without writeChars optimization patch, (-XX:+UseBiasedLocking)
>> Benchmark (basicType) (size) Mode Cnt Score Error Units
>> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 130.367 ? 8.759 us/op
>> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 37.559 ? 0.059 us/op
>> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 12385.030 ? 376.560 us/op
>> 
>> // with writeChars optimization patch, (-XX:+UseBiasedLocking)
>> Benchmark (basicType) (size) Mode Cnt Score Error Units
>> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 45.494 ? 7.018 us/op
>> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 33.015 ? 0.349 us/op
>> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 6845.549 ? 38.712 us/op
>
> Marked as reviewed by alanb (Reviewer).

Thanks Alan for reviewing. :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/2190

From mli at openjdk.java.net  Mon Jan 25 01:08:43 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 25 Jan 2021 01:08:43 GMT
Subject: Integrated: JDK-8260273: DataOutputStream writeChars optimization
In-Reply-To: <ve8NNCTjABCKaUb0ZcpBC2InXNxFSdi88k_zSdLIk6M=.14e89b4a-492e-4b68-bd3e-ab22f2d73ea4@github.com>
References: <ve8NNCTjABCKaUb0ZcpBC2InXNxFSdi88k_zSdLIk6M=.14e89b4a-492e-4b68-bd3e-ab22f2d73ea4@github.com>
Message-ID: <VVCR-7TS5-9o9Z7Ba7s6VFzUju9DSHtV3T1XbuxOVlc=.0cb4e17a-7843-4fbc-97c2-58e89825e41f@github.com>

On Fri, 22 Jan 2021 02:57:36 GMT, Hamlin Li <mli at openjdk.org> wrote:

> this is minor optimization following JDK-8254078.
> based on my tests with jmh, it has better performance when apply following patch:
> 
> diff --git a/src/java.base/share/classes/java/io/DataOutputStream.java b/src/java.base/share/classes/java/io/DataOutputStream.java
> index 9a9a687403c..4ea497fc7c0 100644
> --- a/src/java.base/share/classes/java/io/DataOutputStream.java
> +++ b/src/java.base/share/classes/java/io/DataOutputStream.java
> @@ -300,8 +300,9 @@ public class DataOutputStream extends FilterOutputStream implements DataOutput {
>          int len = s.length();
>          for (int i = 0 ; i < len ; i++) {
>              int v = s.charAt(i);
> - out.write((v >>> 8) & 0xFF);
> - out.write((v >>> 0) & 0xFF);
> + writeBuffer[0] = (byte)(v >>> 8);
> + writeBuffer[1] = (byte)(v >>> 0);
> + out.write(writeBuffer, 0, 2);
>          }
>          incCount(len * 2);
>      }
> 
> Basically, it has better performance when apply above patch:
> 
> // without writeChars optimization patch, (-XX:-UseBiasedLocking)
> Benchmark (basicType) (size) Mode Cnt Score Error Units
> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 115.208 ? 0.327 us/op
> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 276.795 ? 0.449 us/op
> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 12356.969 ? 22.427 us/op
> 
> // with writeChars optimization patch, (-XX:-UseBiasedLocking)
> Benchmark (basicType) (size) Mode Cnt Score Error Units
> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 133.706 ? 0.274 us/op
> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 130.979 ? 0.155 us/op
> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 6814.272 ? 52.770 us/op
> 
> 
> // without writeChars optimization patch, (-XX:+UseBiasedLocking)
> Benchmark (basicType) (size) Mode Cnt Score Error Units
> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 130.367 ? 8.759 us/op
> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 37.559 ? 0.059 us/op
> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 12385.030 ? 376.560 us/op
> 
> // with writeChars optimization patch, (-XX:+UseBiasedLocking)
> Benchmark (basicType) (size) Mode Cnt Score Error Units
> DataOutputStreamTest.dataOutputStreamOverBufferedFileStream STRING 4096 avgt 6 45.494 ? 7.018 us/op
> DataOutputStreamTest.dataOutputStreamOverByteArray STRING 4096 avgt 6 33.015 ? 0.349 us/op
> DataOutputStreamTest.dataOutputStreamOverRawFileStream STRING 4096 avgt 6 6845.549 ? 38.712 us/op

This pull request has now been integrated.

Changeset: c52c6c66
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c52c6c66
Stats:     4 lines in 2 files changed: 1 ins; 0 del; 3 mod

8260273: DataOutputStream writeChars optimization

Reviewed-by: rriggs, bpb, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/2190

From jdcrowley at gmail.com  Sun Jan 24 14:28:05 2021
From: jdcrowley at gmail.com (John Crowley)
Date: Sun, 24 Jan 2021 09:28:05 -0500
Subject: jpackage problem submitting to Apple Store
Message-ID: <511A88CF-2D6F-4B04-81BE-5BB95B750754@computer.org>

Hi All,

Have been having a problem trying to use jpackage to sign an app and submit it to the Apple Store.

Attached are the following:
? the script which invokes jpackage. Note that the attached ??txt? files show the values for all of the variables.
? the output of this script
? the output of the script running with ?verbose

To try to summarize all of the attached:
Trying to create a signed DiskOrganizer-x.y.z.pkg to upload to the Apple Store.
The problem is with mac-sign and the attempt to load to the Apple Store. Otherwise, have successfully created .app, .pkg, and .dmg versions and they all execute/install as expected on my Mac (except as noted directly below in (4)).
This attempt used the jpackage in JDK 16-ea, build 31. Had essentially the same results using JDK 15.0.1
Not shown in the attached is that if you try to manually start by going to DiskOrganizer/Contents/MacOS and execute ./DiskOrganizer directly, it fails with ? Error opening "/Applications/DiskOrganizer.app/Contents/Contents/app/DiskOrganizer.cfg" file: No such file or directory ? Note the ../Contents/Contents/app? Can fix this after installation by putting in a symlink: ln -s . Contents within the Contents directory.

The last step of the pkg1.sh script invokes xcrun altool ?validate-app to validate, comments on these specific errors:
jpackage generates the Info.plist - some errors from this follow. Tried to make a copy of Info.plist, fix it, and then copy back into the .app, but this then invalidates the signature from ?mac-sign.
Key LSApplicationCategoryType contains Unknown. Probably need a jpackage ?mac-category <type> to allow the user to set this.
Installer package may not include install scripts. No idea where such scripts may be located. There are no scripts in the ./inputs directory. Maybe in the runtime created by jlink?
The following executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true in the entitlements property list: [( "DiskOrganizer-app.pkg/Payload/DiskOrganizer.app/Contents/MacOS/DiskOrganizer", "DiskOrganizer-app.pkg/Payload/DiskOrganizer.app/Contents/runtime/Contents/Home/lib/jspawnhelper"   Probably need an ?mac-entitlements <file> option in order to add this, and any other app-specific entitlements, to the code signing step.
Ensure that it is signed with your "3rd Party Mac Developer Installer" certificate. Don?t understand this - have assumed that the default was to use the Developer ID Application and Developer ID Installer certs (which are in my keychain). Are the "3rd Party ?" certs also needed?
Error in keyPath [product-metadata.product-identifier] ? No idea where this resides. Do you know?   
Error in keyPath [product-metadata.product-version ? Ditto
The lowest minimum system version [none] in the Product Definition Property List ? .. does not equal 10.9 (from the Info.plist). Any idea where this gets set on the Apple side? Is it supposed to be somewhere within the .pkg? Maybe need a ?mac-min-version <x.y.z> keyword?
Cannot find executable file that matches the value of CFBundleExecutable in the nested bundle DiskOrganizer [DiskOrganizer-app.pkg/Payload/DiskOrganizer.app/Contents/app] property list file.) ? No idea what this means. The generated .pkg does in fact install OK on my machine, and /Applications/DiskOrganizer.app launches OK with a double-click.
For Apple Store you have a Version (<key>CFBundleShortVersionString</key>) which would be set by ?app-version and is the version visible to the user. But can also have a <key>CFBundleVersion</key> which is really the build number. This must be 3 numbers separated by periods and must change for each upload to the store. So would be good to be able to set ?app-version 1.0 and ?app-build 1.0.4 (or ?mac-build) to be able to set both values. Otherwise the end user will see things like 1.0.23 (it took 23 uploads to make it through the Apple Store process) - which will be confusing.

Sorry for the length of this email, but have been messing around for well over a week with no success. Also tried using jpackage without the ?mac-sign, running 'codesign' directly, etc. Still have not found the magic wand to make this all work.

Would appreciate any suggestions. Would love to hear "You?re doing it wrong, use this set of jpackage options"! 

Otherwise, suggestions or pointers to any on-line documents that would help would be great. (Have been Googling everything about this, but almost all of the "answers" assume that you are using Xcode and tell you what parameters to set - nothing about the resulting in-the-trenches process that Xcode then executes.)

Thanks,

John Crowley
Charlotte, NC
203-856-2396
j.crowley at computer.org






From mik3hall at gmail.com  Mon Jan 25 02:20:54 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 24 Jan 2021 20:20:54 -0600
Subject: jpackage problem submitting to Apple Store
In-Reply-To: <511A88CF-2D6F-4B04-81BE-5BB95B750754@computer.org>
References: <511A88CF-2D6F-4B04-81BE-5BB95B750754@computer.org>
Message-ID: <7D58F4B7-2D9F-44B3-BA15-AAED28586E91@gmail.com>



> On Jan 24, 2021, at 8:28 AM, John Crowley <jdcrowley at gmail.com> wrote:
> 
> Hi All,
> 
> Have been having a problem trying to use jpackage to sign an app and submit it to the Apple Store.
> 
> Attached are the following:

No attachments that I?m seeing.


From darcy at openjdk.java.net  Mon Jan 25 06:15:51 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 25 Jan 2021 06:15:51 GMT
Subject: RFR: 8260329: Update references to TAOCP to latest edition
Message-ID: <FFtTlMxFEPEmLSI_r3rGeSB4f6_jE19NLnob63StNRc=.9c0c1224-c78a-4616-87ec-7461d736600f@github.com>

Updating and regularizing several references to Knuth's The Art of Computer Programming.

-------------

Commit messages:
 - 8260329

Changes: https://git.openjdk.java.net/jdk/pull/2215/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2215&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260329
  Stats: 11 lines in 2 files changed: 1 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2215.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2215/head:pull/2215

PR: https://git.openjdk.java.net/jdk/pull/2215

From alanb at openjdk.java.net  Mon Jan 25 07:38:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 25 Jan 2021 07:38:40 GMT
Subject: RFR: 8260329: Update references to TAOCP to latest edition
In-Reply-To: <FFtTlMxFEPEmLSI_r3rGeSB4f6_jE19NLnob63StNRc=.9c0c1224-c78a-4616-87ec-7461d736600f@github.com>
References: <FFtTlMxFEPEmLSI_r3rGeSB4f6_jE19NLnob63StNRc=.9c0c1224-c78a-4616-87ec-7461d736600f@github.com>
Message-ID: <TJrWBzPYnjcGOTl39f35BRUCnkYnfTLEbr0temrOemw=.0b80770d-31f1-476d-9f77-fcca4b5553f2@github.com>

On Mon, 25 Jan 2021 06:10:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Updating and regularizing several references to Knuth's The Art of Computer Programming.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2215

From goetz.lindenmaier at sap.com  Mon Jan 25 09:48:33 2021
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 25 Jan 2021 09:48:33 +0000
Subject: [11u] RFR: 7146776: deadlock between
 URLStreamHandler.getHostAddress and file.Handler.openconnection
In-Reply-To: <AM4PR02MB305714EC3174E696DB79D9D09AA30@AM4PR02MB3057.eurprd02.prod.outlook.com>
References: <AM4PR02MB305714EC3174E696DB79D9D09AA30@AM4PR02MB3057.eurprd02.prod.outlook.com>
Message-ID: <AM0PR0202MB344366340AD956FDB8509385ECBD0@AM0PR0202MB3443.eurprd02.prod.outlook.com>

Hi,

Thanks for downporting this, looks good.

Best regards,
  Goetz.

From: Doerr, Martin <martin.doerr at sap.com>
Sent: Tuesday, January 19, 2021 6:44 PM
To: core-libs-dev <core-libs-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Langer, Christoph <christoph.langer at sap.com>
Subject: [11u] RFR: 7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection

Hi,

JDK-7146776 is backported to 11.0.11-oracle. I'd like to backport it for parity.
Change doesn't apply cleanly because of Copyright year changes and a minor difference in a hunk which gets removed by this change:
11u Code contains host.equals(""), patch wants to remove host.isEmpty() from URLStreamHandler.java.

Bug:
https://bugs.openjdk.java.net/browse/JDK-7146776

Original change:
https://git.openjdk.java.net/jdk/commit/db9c114d

11u backport:
http://cr.openjdk.java.net/~mdoerr/7146776_windows_deadlock_11u/webrev.00/

Please review.

Best regards,
Martin


From martin.doerr at sap.com  Mon Jan 25 09:58:05 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 25 Jan 2021 09:58:05 +0000
Subject: [11u] RFR: 7146776: deadlock between
 URLStreamHandler.getHostAddress and file.Handler.openconnection
In-Reply-To: <AM0PR0202MB344366340AD956FDB8509385ECBD0@AM0PR0202MB3443.eurprd02.prod.outlook.com>
References: <AM4PR02MB305714EC3174E696DB79D9D09AA30@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <AM0PR0202MB344366340AD956FDB8509385ECBD0@AM0PR0202MB3443.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB3057CA850ADE75FDF21358D49ABD0@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi G?tz,

thanks for the review!

Best regards,
Martin


From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Sent: Montag, 25. Januar 2021 10:49
To: Doerr, Martin <martin.doerr at sap.com>; core-libs-dev <core-libs-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
Cc: Langer, Christoph <christoph.langer at sap.com>
Subject: RE: [11u] RFR: 7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection

Hi,

Thanks for downporting this, looks good.

Best regards,
  Goetz.

From: Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>
Sent: Tuesday, January 19, 2021 6:44 PM
To: core-libs-dev <core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>>; jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>
Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>>; Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Subject: [11u] RFR: 7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection

Hi,

JDK-7146776 is backported to 11.0.11-oracle. I'd like to backport it for parity.
Change doesn't apply cleanly because of Copyright year changes and a minor difference in a hunk which gets removed by this change:
11u Code contains host.equals(""), patch wants to remove host.isEmpty() from URLStreamHandler.java.

Bug:
https://bugs.openjdk.java.net/browse/JDK-7146776

Original change:
https://git.openjdk.java.net/jdk/commit/db9c114d

11u backport:
http://cr.openjdk.java.net/~mdoerr/7146776_windows_deadlock_11u/webrev.00/

Please review.

Best regards,
Martin


From aph at openjdk.java.net  Mon Jan 25 10:00:41 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 25 Jan 2021 10:00:41 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <h9On7_RFadcLwhW15R4Jig9PZ0y9JoMI2diiqXv99eY=.9b814ff7-64cf-496f-a507-0a8f86070c2d@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
 <h9On7_RFadcLwhW15R4Jig9PZ0y9JoMI2diiqXv99eY=.9b814ff7-64cf-496f-a507-0a8f86070c2d@github.com>
Message-ID: <GUQ9iV90tXzdUOtyjcIJygM7qBCcUtSHVOol8hOK2OE=.7b3ab947-f835-43d4-a852-cde094efbf62@github.com>

On Sun, 24 Jan 2021 16:10:44 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 394:
>> 
>>> 392: 
>>> 393: class SlowSignatureHandler
>>> 394:   : public NativeSignatureIterator {
>> 
>> SlowSignatureHandler is turning into a maintenance nightmare. This isn't the fault of this commit so much as some nasty cut-and-paste programming in the code you're editing. It might well be better to rewrite this whole thing to use a table-driven approach, with a table that contains the increment and the size of each native type: then we'd have only a single routine which could pass data of any type, and each OS needs only supply a table of constants.
>
> Would you like me to do something about it now? The problem is that the functions of SlowSignatureHandler are subtly different, so it will be multiple tables, not sure how many. Such change is another candidate for a separate code enhancement, which I would like not to mix into the JEP implementation (it's already not a small change :)). But if you think it would be a good thing, please let me know. In another case, I'll add this to a queue of follow-up enhancements.

I'm not sure it can wait. This change turns already-messy code into something significantly messier, to the extent that it's not really good enough to go into mainline.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From aph at openjdk.java.net  Mon Jan 25 10:00:43 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 25 Jan 2021 10:00:43 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <UubbyJKBR24lG2v3vsTotl7bRFQrHWypAM58MRRy5Tc=.15f12745-172c-401e-8966-2e5b7137b9fc@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
 <UubbyJKBR24lG2v3vsTotl7bRFQrHWypAM58MRRy5Tc=.15f12745-172c-401e-8966-2e5b7137b9fc@github.com>
Message-ID: <UKJs_0siqUqR9HgIbFpiReb_i9ASyFf8Uwo1rS9ETbM=.495a5d37-0069-4c63-8487-d64f0d14d5b2@github.com>

On Sun, 24 Jan 2021 16:29:31 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5272:
>> 
>>> 5270: void MacroAssembler::get_thread(Register dst) {
>>> 5271:   RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst;
>>> 5272:   push(saved_regs, sp);
>> 
>> This isn't very nice.
>
> Hello
> Why is it not nice ?
> linux_aarch64 uses some linux specific tls function _ZN10JavaThread25aarch64_get_thread_helperEv from hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.s
> which clobbers only r0 and r1
> macos_aarch64 has no such tls code and uses generic C-call to Thread::current();
> Hence we  are saving possibly clobbered regs here.

Surely if you did as Linux does you wouldn't need to clobber all those registers.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From jlahoda at openjdk.java.net  Mon Jan 25 11:59:46 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 25 Jan 2021 11:59:46 GMT
Subject: RFR: 8242456: PreviewFeature.Feature enum removal of TEXT_BLOCKS
Message-ID: <YMZvuKAKkou_KXKbudx_xXDmq4t2I5rdePt_0PeGNdI=.1eafe546-b5ed-4fe4-a124-5dc78ef43bba@github.com>

The enum constant is unused, and can be removed. The class is not an API.

-------------

Commit messages:
 - 8242456: PreviewFeature.Feature enum removal of TEXT_BLOCKS

Changes: https://git.openjdk.java.net/jdk/pull/2218/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2218&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8242456
  Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2218.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2218/head:pull/2218

PR: https://git.openjdk.java.net/jdk/pull/2218

From jlaskey at openjdk.java.net  Mon Jan 25 12:52:45 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 25 Jan 2021 12:52:45 GMT
Subject: RFR: 8242456: PreviewFeature.Feature enum removal of TEXT_BLOCKS
In-Reply-To: <YMZvuKAKkou_KXKbudx_xXDmq4t2I5rdePt_0PeGNdI=.1eafe546-b5ed-4fe4-a124-5dc78ef43bba@github.com>
References: <YMZvuKAKkou_KXKbudx_xXDmq4t2I5rdePt_0PeGNdI=.1eafe546-b5ed-4fe4-a124-5dc78ef43bba@github.com>
Message-ID: <tJFfhlK6bzmgizjubET9qw_tvalLObtBvrrdFpj1dHw=.732b0f29-c02c-405b-a6da-6713323adca5@github.com>

On Mon, 25 Jan 2021 11:55:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The enum constant is unused, and can be removed. The class is not an API.

Marked as reviewed by jlaskey (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2218

From ihse at openjdk.java.net  Mon Jan 25 13:25:53 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 25 Jan 2021 13:25:53 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
Message-ID: <DbmqwFNrfBhdBMARLx4fbTam5Nqjb4nHDfDX9ePhSdw=.1969f025-2b9c-4d36-957c-2ba4718a2fbb@github.com>

On Sun, 24 Jan 2021 15:32:59 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address feedback for signature generators
>  - Enable -Wformat-nonliteral back

Changes requested by ihse (Reviewer).

make/autoconf/jvm-features.m4 line 269:

> 267:     if test "x$OPENJDK_TARGET_OS" != xaix && \
> 268:         !( test "x$OPENJDK_TARGET_OS" = "xmacosx" && \
> 269:         test "x$OPENJDK_TARGET_CPU" = "xaarch64" ) ; then

This test is making my head spin. Can't you just invert it to this structure:

if OS=aix || OS+CPU = mac+aarch64; then
  no
else
 yes
fi

make/autoconf/platform.m4 line 75:

> 73:         ;;
> 74:       esac
> 75:       ;;

This is solved in the wrong place. This code should just use the result from `config.guess/config.sub`. These files are imported from the autoconf project. Unfortunately, they have changed the license to one incompatible with OpenJDK, so we are stuck with an old version. Instead, we have created a "bugfix wrapper" that calls the original `autoconf-config.guess/sub` and fixes up the result, with stuff like this.

make/autoconf/platform.m4 line 273:

> 271:   # Convert the autoconf OS/CPU value to our own data, into the VAR_OS/CPU/LIBC variables.
> 272:   PLATFORM_EXTRACT_VARS_FROM_OS($build_os)
> 273:   PLATFORM_EXTRACT_VARS_FROM_CPU($build_cpu, $build_os)

Fixing the comment above means this change, and the one below, can be reverted.

make/common/NativeCompilation.gmk line 1180:

> 1178:                 # silently fail otherwise.
> 1179:                 ifneq ($(CODESIGN), )
> 1180: 		  $(CODESIGN) -f -s "$(MACOSX_CODESIGN_IDENTITY)" --timestamp --options runtime \

What does -f do, and is it needed for macos-x64 as well?

make/modules/jdk.hotspot.agent/Lib.gmk line 34:

> 32: 
> 33: else ifeq ($(call isTargetOs, macosx), true)
> 34:   SA_CFLAGS := -D_GNU_SOURCE -mno-omit-leaf-frame-pointer \

Is this really proper for macos-x64? I thought we used -Damd64 as a marker for all macos-x64 C/C++ files. (Most files get their flags from the common setup in configure, but SA is a different beast due to historical reasons).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From vkempik at openjdk.java.net  Mon Jan 25 13:33:47 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Mon, 25 Jan 2021 13:33:47 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <DbmqwFNrfBhdBMARLx4fbTam5Nqjb4nHDfDX9ePhSdw=.1969f025-2b9c-4d36-957c-2ba4718a2fbb@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <DbmqwFNrfBhdBMARLx4fbTam5Nqjb4nHDfDX9ePhSdw=.1969f025-2b9c-4d36-957c-2ba4718a2fbb@github.com>
Message-ID: <H0K3sUe4APFRYh0HtLdrFW0q1_pFibrkvTUZlMceV_Y=.0ac40c75-c893-424a-af17-adc558dc6c17@github.com>

On Mon, 25 Jan 2021 13:18:34 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> make/common/NativeCompilation.gmk line 1180:
> 
>> 1178:                 # silently fail otherwise.
>> 1179:                 ifneq ($(CODESIGN), )
>> 1180: 		  $(CODESIGN) -f -s "$(MACOSX_CODESIGN_IDENTITY)" --timestamp --options runtime \
> 
> What does -f do, and is it needed for macos-x64 as well?

-f  - replace signature if it's present, if not  - just sign as usual
macos-aarch64 binaries always have adhoc signature, so need to replace it.

> make/modules/jdk.hotspot.agent/Lib.gmk line 34:
> 
>> 32: 
>> 33: else ifeq ($(call isTargetOs, macosx), true)
>> 34:   SA_CFLAGS := -D_GNU_SOURCE -mno-omit-leaf-frame-pointer \
> 
> Is this really proper for macos-x64? I thought we used -Damd64 as a marker for all macos-x64 C/C++ files. (Most files get their flags from the common setup in configure, but SA is a different beast due to historical reasons).

@luhenry , could you please check this comment, I think SA-agent was MS's job here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From vkempik at openjdk.java.net  Mon Jan 25 14:09:44 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Mon, 25 Jan 2021 14:09:44 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <Zi4wsZF2zVnOW4EcKxOP4784amzXLn0L6T7tEheZACY=.2390e0bf-e710-4347-8695-05ceb1865539@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <DbmqwFNrfBhdBMARLx4fbTam5Nqjb4nHDfDX9ePhSdw=.1969f025-2b9c-4d36-957c-2ba4718a2fbb@github.com>
 <Zi4wsZF2zVnOW4EcKxOP4784amzXLn0L6T7tEheZACY=.2390e0bf-e710-4347-8695-05ceb1865539@github.com>
Message-ID: <T-ElM5TJlF0qgsvySj-SS-BnnQAfEiGCMSIF6lYmAqk=.5a977646-2862-4749-a056-1d8bf1741f5d@github.com>

On Mon, 25 Jan 2021 14:03:40 GMT, Per Liden <pliden at openjdk.org> wrote:

> In `make/autoconf/jvm-features.m4` I notice that you haven't enabled ZGC for macos/aarch64. Is that just an oversight, or is there a reason for that?

because it does not work
processor_id has no "official docs"-friendly implementation, only a hacky one from ios world.

Also ZGC needs additional W^X work.
I believe zgc supports needs to be done in a separate commit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From pliden at openjdk.java.net  Mon Jan 25 14:06:46 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Mon, 25 Jan 2021 14:06:46 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <DbmqwFNrfBhdBMARLx4fbTam5Nqjb4nHDfDX9ePhSdw=.1969f025-2b9c-4d36-957c-2ba4718a2fbb@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <DbmqwFNrfBhdBMARLx4fbTam5Nqjb4nHDfDX9ePhSdw=.1969f025-2b9c-4d36-957c-2ba4718a2fbb@github.com>
Message-ID: <Zi4wsZF2zVnOW4EcKxOP4784amzXLn0L6T7tEheZACY=.2390e0bf-e710-4347-8695-05ceb1865539@github.com>

On Mon, 25 Jan 2021 13:23:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> Changes requested by ihse (Reviewer).

In `make/autoconf/jvm-features.m4` I notice that you haven't enabled ZGC for macos/aarch64. Is that just an oversight, or is there a reason for that?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From mik3hall at gmail.com  Mon Jan 25 14:13:21 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 25 Jan 2021 08:13:21 -0600
Subject: jpackage problem submitting to Apple Store
In-Reply-To: <4C496BFA-8715-4E5B-A0D1-D1C99CD901AD@computer.org>
References: <511A88CF-2D6F-4B04-81BE-5BB95B750754@computer.org>
 <7D58F4B7-2D9F-44B3-BA15-AAED28586E91@gmail.com>
 <4C496BFA-8715-4E5B-A0D1-D1C99CD901AD@computer.org>
Message-ID: <5CE000C3-61FC-42E8-B40B-5B4285A7A1DF@gmail.com>



> On Jan 25, 2021, at 6:36 AM, John Crowley <jdcrowley at gmail.com> wrote:
> 
> As an alternate, a link to Google Drive - https://drive.google.com/drive/folders/1SgLhlovuH2x18gRh-ffhZCHVeXt1AOXo?usp=sharing <https://drive.google.com/drive/folders/1SgLhlovuH2x18gRh-ffhZCHVeXt1AOXo?usp=sharing>
> 

The attachments are there

From coleenp at openjdk.java.net  Mon Jan 25 14:39:49 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 25 Jan 2021 14:39:49 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
Message-ID: <X9wlF4x4NEgbqm4jgkh3npkup8hOt70EBr9HOk_boU0=.2850f987-a8bf-436d-9a8f-f3588f18f0f7@github.com>

On Sun, 24 Jan 2021 15:32:59 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address feedback for signature generators
>  - Enable -Wformat-nonliteral back

src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 87:

> 85:   JavaThread* jt = JavaThread::thread_from_jni_environment(jni_env);
> 86:   DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(jt));;
> 87:   Thread::WXWriteFromExecSetter wx_write;

Is this on every transition to VM from Native?  Would it be better to add to ThreadInVMfromNative like the ResetNoHandleMark is?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From coleenp at openjdk.java.net  Mon Jan 25 14:43:44 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 25 Jan 2021 14:43:44 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
Message-ID: <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com>

On Sun, 24 Jan 2021 15:32:59 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address feedback for signature generators
>  - Enable -Wformat-nonliteral back

src/hotspot/share/runtime/thread.hpp line 915:

> 913:       verify_wx_state(WXExec);
> 914:     }
> 915:   };

Rather than add all this to thread.hpp, can you make a wxVerifier.hpp and just add the class instance as a field in thread.hpp?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From coleenp at openjdk.java.net  Mon Jan 25 14:43:46 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 25 Jan 2021 14:43:46 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com>
Message-ID: <-_A-bf8i3jWY1awmyxwzi3yv4UoJQelRbJrMQVWQGLU=.5103b95d-3ad7-4a70-8d46-60c0eb0a301f@github.com>

On Mon, 25 Jan 2021 14:40:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> src/hotspot/share/runtime/thread.hpp line 915:
> 
>> 913:       verify_wx_state(WXExec);
>> 914:     }
>> 915:   };
> 
> Rather than add all this to thread.hpp, can you make a wxVerifier.hpp and just add the class instance as a field in thread.hpp?

This could be a follow-up RFE.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Mon Jan 25 15:03:44 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 25 Jan 2021 15:03:44 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <X9wlF4x4NEgbqm4jgkh3npkup8hOt70EBr9HOk_boU0=.2850f987-a8bf-436d-9a8f-f3588f18f0f7@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <X9wlF4x4NEgbqm4jgkh3npkup8hOt70EBr9HOk_boU0=.2850f987-a8bf-436d-9a8f-f3588f18f0f7@github.com>
Message-ID: <gh9aHbfKHXKAG3LTBZWitlw6L7p5kxwQC-Xxiyii1Ww=.d56e467d-4135-4785-968c-766c4505eb3c@github.com>

On Mon, 25 Jan 2021 14:36:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 87:
> 
>> 85:   JavaThread* jt = JavaThread::thread_from_jni_environment(jni_env);
>> 86:   DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(jt));;
>> 87:   Thread::WXWriteFromExecSetter wx_write;
> 
> Is this on every transition to VM from Native?  Would it be better to add to ThreadInVMfromNative like the ResetNoHandleMark is?

I've tried to do something like this initially. The idea was to use Write in VM state and Exec in Java and Native states. However, for example, JIT runs in the Native state and needs Write access. So instead, W^X is managed on entry and exit from VM code, in macros like JRT_ENTRY. Unfortunately, not every JVM entry function is defined with an appropriate macro (at least for now), so I had to add explicit W^X state management along with the explicit java thread state, like here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From andy.herrick at oracle.com  Mon Jan 25 15:19:01 2021
From: andy.herrick at oracle.com (Andy Herrick)
Date: Mon, 25 Jan 2021 10:19:01 -0500
Subject: bug jpackage in JDK 15
In-Reply-To: <F1713D97-F08E-41A3-956C-D05A1C402818@gmail.com>
References: <CAH2-wONu7wpxBmgKL8qx3cB+NWfnNLw-XTqCMLqnUZ2JjuDtkA@mail.gmail.com>
 <0DF4D073-FAD7-4708-AECE-51BD0720957F@gmail.com>
 <CAH2-wOPZ9_-Lbt9jAaNZxYa4ROpqVZ0XAc90e+7uXv8BbOJ_AA@mail.gmail.com>
 <44985368-4120-4F70-BE32-E811A99DA94B@gmail.com>
 <F1713D97-F08E-41A3-956C-D05A1C402818@gmail.com>
Message-ID: <ef384a6d-eb8f-b23f-cceb-1f472e1ce03d@oracle.com>


On 1/24/2021 9:27 AM, Michael Hall wrote:
> /usr/libexec/java_home -v 14 --exec jpackage --version
> WARNING: Using incubator modules: jdk.incubator.jpackage
> 14.0.2
>
> If of interest to anyone I still haven?t figured out signing. It errored giving some indication that the JDK had already been signed? I posted that sometime back. I keep meaning to look at what there is for testing but haven?t yet. Any thoughts on that would still be appreciated.

Signing is not likely to work in 14.02 - needs fixes 
includingJDK-8237490 that are only in 15. 
<https://bugs.openjdk.java.net/browse/JDK-8237490>

I would suggest to start from JDK16 EA build from https://jdk.java.net/16/

/Andy


From redestad at openjdk.java.net  Mon Jan 25 15:30:51 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 25 Jan 2021 15:30:51 GMT
Subject: RFR: 8260337: Optimize ImageReader lookup, used by Class.getResource
Message-ID: <zQXTGreWNlfXRT-l_G5Ptd6i_ZQ5XbD7yQj40Kr84Ic=.8dab254e-0aa9-4932-a8bd-0194e25ed68f@github.com>

This patch optimizes the code paths exercised by `String.class.getResource("String.class")` by:

- Adding an ASCII fast-path to methods verifying strings in the jimage, which can then be done allocation-free
- Avoiding the allocation of the `long[8]` attributes when verifying only for the purpose of verifying a path exists
- Using the `JNUA.create` fast-path in `SystemModuleReader` (which should be OK since we just verified the given name is a JRT path)
- Remove a redundant check in `Class::resolveName` and fitting the `StringBuilder` to size

-------------

Commit messages:
 - Remove more redundant checks
 - More cleanups, remove redundant null checks, synchronization
 - Minor cleanup, remove some code duplication
 - Fix offsets to properly find extension-less resources (ModuleReaderTest etc)
 - Merge branch 'master' into jrt_getString
 - Make ImageLocation lookup mostly allocation-free, use JNUA.create in SystemModuleReader, improve Class.resolveName
 - Invert length for non-ASCII case
 - Add working micro, cleanup and fix code
 - Improve jimage string reading

Changes: https://git.openjdk.java.net/jdk/pull/2212/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2212&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260337
  Stats: 387 lines in 8 files changed: 263 ins; 63 del; 61 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2212.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2212/head:pull/2212

PR: https://git.openjdk.java.net/jdk/pull/2212

From redestad at openjdk.java.net  Mon Jan 25 15:30:52 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 25 Jan 2021 15:30:52 GMT
Subject: RFR: 8260337: Optimize ImageReader lookup,
 used by Class.getResource
In-Reply-To: <zQXTGreWNlfXRT-l_G5Ptd6i_ZQ5XbD7yQj40Kr84Ic=.8dab254e-0aa9-4932-a8bd-0194e25ed68f@github.com>
References: <zQXTGreWNlfXRT-l_G5Ptd6i_ZQ5XbD7yQj40Kr84Ic=.8dab254e-0aa9-4932-a8bd-0194e25ed68f@github.com>
Message-ID: <tV6-t30ffCJXteTsEEC6D1rGnR3GgEmMafRZeWyX8FU=.92f527b7-b3e1-4a69-9845-5d2293a8d1c3@github.com>

On Mon, 25 Jan 2021 00:05:52 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch optimizes the code paths exercised by `String.class.getResource("String.class")` by:
> 
> - Adding an ASCII fast-path to methods verifying strings in the jimage, which can then be done allocation-free
> - Avoiding the allocation of the `long[8]` attributes when verifying only for the purpose of verifying a path exists
> - Using the `JNUA.create` fast-path in `SystemModuleReader` (which should be OK since we just verified the given name is a JRT path)
> - Remove a redundant check in `Class::resolveName` and fitting the `StringBuilder` to size

On the provided benchmark we can observe a 2x speed-up and a 70% reduction in allocation.

Baseline:
Benchmark                                                      Mode  Cnt     Score     Error   Units
ClassGetResource.stringClass                                   avgt    5  2885.403 ? 309.787   ns/op
ClassGetResource.stringClass:?gc.alloc.rate.norm               avgt    5  1368.124 ?   0.056    B/op

Patch:
Benchmark                                                      Mode  Cnt     Score     Error   Units
ClassGetResource.stringClass                                   avgt    5  1411.980 ? 155.877   ns/op
ClassGetResource.stringClass:?gc.alloc.rate.norm               avgt    5   408.038 ?   0.043    B/op

-------------

PR: https://git.openjdk.java.net/jdk/pull/2212

From alanb at openjdk.java.net  Mon Jan 25 15:50:44 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 25 Jan 2021 15:50:44 GMT
Subject: RFR: 8260337: Optimize ImageReader lookup,
 used by Class.getResource
In-Reply-To: <zQXTGreWNlfXRT-l_G5Ptd6i_ZQ5XbD7yQj40Kr84Ic=.8dab254e-0aa9-4932-a8bd-0194e25ed68f@github.com>
References: <zQXTGreWNlfXRT-l_G5Ptd6i_ZQ5XbD7yQj40Kr84Ic=.8dab254e-0aa9-4932-a8bd-0194e25ed68f@github.com>
Message-ID: <UOPPOsDdgGNIzssUkSUjkXh2xQf3sURJ8UDR5k8ZMRw=.12615117-b288-4f46-b64e-a88cb4eebf54@github.com>

On Mon, 25 Jan 2021 00:05:52 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch optimizes the code paths exercised by `String.class.getResource("String.class")` by:
> 
> - Adding an ASCII fast-path to methods verifying strings in the jimage, which can then be done allocation-free
> - Avoiding the allocation of the `long[8]` attributes when verifying only for the purpose of verifying a path exists
> - Using the `JNUA.create` fast-path in `SystemModuleReader` (which should be OK since we just verified the given name is a JRT path)
> - Remove a redundant check in `Class::resolveName` and fitting the `StringBuilder` to size

src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 439:

> 437:          * if not found.
> 438:          */
> 439:         private boolean containsLocation(String name) throws IOException {

Can you rename this to containsImageLocation to keep it consistent with findImageLocation? Alternative rename findImageLocation. Also would be better for the description to be "Returns true if the given resource exists, false if not found".

The changes to the jimage code will take time to review, probably should have 2 reviewers.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2212

From burban at openjdk.java.net  Mon Jan 25 16:02:45 2021
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Mon, 25 Jan 2021 16:02:45 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <H0K3sUe4APFRYh0HtLdrFW0q1_pFibrkvTUZlMceV_Y=.0ac40c75-c893-424a-af17-adc558dc6c17@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <DbmqwFNrfBhdBMARLx4fbTam5Nqjb4nHDfDX9ePhSdw=.1969f025-2b9c-4d36-957c-2ba4718a2fbb@github.com>
 <H0K3sUe4APFRYh0HtLdrFW0q1_pFibrkvTUZlMceV_Y=.0ac40c75-c893-424a-af17-adc558dc6c17@github.com>
Message-ID: <IQ1xC4wgzr9t6IQyuHlZGkLgbgCpjbGCquoe6QwF6OA=.20391856-485c-4057-865b-37974b526f10@github.com>

On Mon, 25 Jan 2021 13:30:55 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> make/modules/jdk.hotspot.agent/Lib.gmk line 34:
>> 
>>> 32: 
>>> 33: else ifeq ($(call isTargetOs, macosx), true)
>>> 34:   SA_CFLAGS := -D_GNU_SOURCE -mno-omit-leaf-frame-pointer \
>> 
>> Is this really proper for macos-x64? I thought we used -Damd64 as a marker for all macos-x64 C/C++ files. (Most files get their flags from the common setup in configure, but SA is a different beast due to historical reasons).
>
> @luhenry , could you please check this comment, I think SA-agent was MS's job here.

The target is identified by the header file now:
https://github.com/openjdk/jdk/pull/2200/files#diff-51442e74eeef2163f0f0643df0ae995083f666367e25fba2b527a9a5bc8743a6R35-R41

Do you think there is any problem with this approach?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From redestad at openjdk.java.net  Mon Jan 25 16:09:01 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 25 Jan 2021 16:09:01 GMT
Subject: RFR: 8260337: Optimize ImageReader lookup,
 used by Class.getResource [v2]
In-Reply-To: <zQXTGreWNlfXRT-l_G5Ptd6i_ZQ5XbD7yQj40Kr84Ic=.8dab254e-0aa9-4932-a8bd-0194e25ed68f@github.com>
References: <zQXTGreWNlfXRT-l_G5Ptd6i_ZQ5XbD7yQj40Kr84Ic=.8dab254e-0aa9-4932-a8bd-0194e25ed68f@github.com>
Message-ID: <wiOiXfQx_b4KCY5jbwgez-iMByKK3-SWOKZshzcE-ac=.563935b2-f60a-480a-a883-a3f354de704c@github.com>

> This patch optimizes the code paths exercised by `String.class.getResource("String.class")` by:
> 
> - Adding an ASCII fast-path to methods verifying strings in the jimage, which can then be done allocation-free
> - Avoiding the allocation of the `long[8]` attributes when verifying only for the purpose of verifying a path exists
> - Using the `JNUA.create` fast-path in `SystemModuleReader` (which should be OK since we just verified the given name is a JRT path)
> - Remove a redundant check in `Class::resolveName` and fitting the `StringBuilder` to size

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Copyrights and rename containsLocation

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2212/files
  - new: https://git.openjdk.java.net/jdk/pull/2212/files/ad95b490..096e64b1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2212&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2212&range=00-01

  Stats: 10 lines in 7 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2212.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2212/head:pull/2212

PR: https://git.openjdk.java.net/jdk/pull/2212

From redestad at openjdk.java.net  Mon Jan 25 16:09:02 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 25 Jan 2021 16:09:02 GMT
Subject: RFR: 8260337: Optimize ImageReader lookup,
 used by Class.getResource [v2]
In-Reply-To: <UOPPOsDdgGNIzssUkSUjkXh2xQf3sURJ8UDR5k8ZMRw=.12615117-b288-4f46-b64e-a88cb4eebf54@github.com>
References: <zQXTGreWNlfXRT-l_G5Ptd6i_ZQ5XbD7yQj40Kr84Ic=.8dab254e-0aa9-4932-a8bd-0194e25ed68f@github.com>
 <UOPPOsDdgGNIzssUkSUjkXh2xQf3sURJ8UDR5k8ZMRw=.12615117-b288-4f46-b64e-a88cb4eebf54@github.com>
Message-ID: <-qHJGB6W88E1BuGxKL0n7e6KynJEcMZnQ6PQsM14ugk=.8294b355-84bd-48de-842a-3498dcae6db9@github.com>

On Mon, 25 Jan 2021 15:47:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyrights and rename containsLocation
>
> src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 439:
> 
>> 437:          * if not found.
>> 438:          */
>> 439:         private boolean containsLocation(String name) throws IOException {
> 
> Can you rename this to containsImageLocation to keep it consistent with findImageLocation? Alternative rename findImageLocation. Also would be better for the description to be "Returns true if the given resource exists, false if not found".
> 
> The changes to the jimage code will take time to review, probably should have 2 reviewers.

Done. 

I've looped in @JimLaskey

-------------

PR: https://git.openjdk.java.net/jdk/pull/2212

From aph at openjdk.java.net  Mon Jan 25 17:21:46 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 25 Jan 2021 17:21:46 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <FIAu02KPkeT8mjt2BKIcVnei38gRk3aoXWTfpIvFhos=.773b9848-15d8-45b5-9669-4df8ca65b2d0@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
 <FIAu02KPkeT8mjt2BKIcVnei38gRk3aoXWTfpIvFhos=.773b9848-15d8-45b5-9669-4df8ca65b2d0@github.com>
Message-ID: <0WPkx3i-N0HHqCqrxE_B0Rf2akunbQaWQb7M7Z88BQY=.c582d11a-ba8d-4789-a55b-279e1286ad8d@github.com>

On Sun, 24 Jan 2021 15:50:01 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 86:
>> 
>>> 84: 
>>> 85:   switch (_num_int_args) {
>>> 86:   case 0:
>> 
>> I don't think you need such a large switch statement. I think this can be expressed as
>> if (num_int_args <= 6) {
>>     ldr(as_Register(num_int_args + r1.encoding()), src);
>> ... etc.
>
> I like the suggestion. For the defense, new functions were made this way intentionally, to match existing `pass_int`, `pass_long`,.. I take your comment as a blessing to fix all of them. But I feel that refactoring of existing code should go in a separate commit. Especially after `pass_int` used `ldr/str` instead of `ldrw/strw`, which looks wrong. https://github.com/openjdk/jdk/pull/2200/files#diff-1ff58ce70aeea7e9842d34e8d8fd9c94dd91182999d455618b2a171efd8f742cL87-R122

This is new code, and it should not repeat the mistakes of the past. There's no need to refactor the similar existing code as part of this patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From prr at openjdk.java.net  Mon Jan 25 17:45:47 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 25 Jan 2021 17:45:47 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
Message-ID: <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com>

On Sun, 24 Jan 2021 15:32:59 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address feedback for signature generators
>  - Enable -Wformat-nonliteral back

Changes requested by prr (Reviewer).

src/java.desktop/share/native/libharfbuzz/hb-common.h line 113:

> 111: 
> 112: #define HB_TAG(c1,c2,c3,c4) ((hb_tag_t)((((uint32_t)(c1)&0xFF)<<24)|(((uint32_t)(c2)&0xFF)<<16)|(((uint32_t)(c3)&0xFF)<<8)|((uint32_t)(c4)&0xFF)))
> 113: #define HB_UNTAG(tag)   (char)(((tag)>>24)&0xFF), (char)(((tag)>>16)&0xFF), (char)(((tag)>>8)&0xFF), (char)((tag)&0xFF)

I need a robust explanation of these changes.
They are not mentioned, nor are they in upstream harfbuzz.
Likely these should be pushed to upstream first if there is a reason for them.

src/java.desktop/share/native/libharfbuzz/hb-coretext.cc line 193:

> 191:    * crbug.com/549610 */
> 192:   // 0x00070000 stands for "kCTVersionNumber10_10", see CoreText.h
> 193: #if TARGET_OS_OSX && MAC_OS_X_VERSION_MIN_REQUIRED < __MAC_10_10

I need a robust explanation of these changes.
They are not mentioned, nor are they in upstream harfbuzz.
Likely these should be pushed to upstream first if there is a reason for them.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Mon Jan 25 17:45:47 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 25 Jan 2021 17:45:47 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <UKJs_0siqUqR9HgIbFpiReb_i9ASyFf8Uwo1rS9ETbM=.495a5d37-0069-4c63-8487-d64f0d14d5b2@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
 <UubbyJKBR24lG2v3vsTotl7bRFQrHWypAM58MRRy5Tc=.15f12745-172c-401e-8966-2e5b7137b9fc@github.com>
 <UKJs_0siqUqR9HgIbFpiReb_i9ASyFf8Uwo1rS9ETbM=.495a5d37-0069-4c63-8487-d64f0d14d5b2@github.com>
Message-ID: <rXdOvnIMi32PllNC5mylqYzbQOBSuozgxFGX2eR2i8o=.e8f4e098-d253-431d-b708-1bf410b777ce@github.com>

On Mon, 25 Jan 2021 09:52:00 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Hello
>> Why is it not nice ?
>> linux_aarch64 uses some linux specific tls function _ZN10JavaThread25aarch64_get_thread_helperEv from hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.s
>> which clobbers only r0 and r1
>> macos_aarch64 has no such tls code and uses generic C-call to Thread::current();
>> Hence we  are saving possibly clobbered regs here.
>
> Surely if you did as Linux does you wouldn't need to clobber all those registers.

I see how this can be done, from looking at C example with `__thread`, which involves 
poorly documented relocations and private libc interface invocation.

But now I also wonder how much benefit would we have from this optimization.
`get_thread` is called from few places and all of them are guarded by `#ifdef ASSERT`. The release build is still fine after I removed MacroAssembler::get_thread definition (as a verification).

Callers of get_thread:
* StubAssembler::call_RT
* Runtime1::generate_patching
* StubGenerator::generate_call_stub
* StubGenerator::generate_catch_exception

All of them are heavy-weight functions, nonoptimal get_thread is unlikely to slow them down even in fastdebug.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From bpb at openjdk.java.net  Mon Jan 25 18:09:40 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 25 Jan 2021 18:09:40 GMT
Subject: RFR: 8260329: Update references to TAOCP to latest edition
In-Reply-To: <FFtTlMxFEPEmLSI_r3rGeSB4f6_jE19NLnob63StNRc=.9c0c1224-c78a-4616-87ec-7461d736600f@github.com>
References: <FFtTlMxFEPEmLSI_r3rGeSB4f6_jE19NLnob63StNRc=.9c0c1224-c78a-4616-87ec-7461d736600f@github.com>
Message-ID: <mobqoLrSV3QZjWLxjYwHVEtiQ_Ja3Us4ag1ia5Uz2Ds=.34ad6a77-121e-4981-b047-d061cd196dc6@github.com>

On Mon, 25 Jan 2021 06:10:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Updating and regularizing several references to Knuth's The Art of Computer Programming.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2215

From darcy at openjdk.java.net  Mon Jan 25 19:09:58 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 25 Jan 2021 19:09:58 GMT
Subject: RFR: 8260329: Update references to TAOCP to latest edition [v2]
In-Reply-To: <FFtTlMxFEPEmLSI_r3rGeSB4f6_jE19NLnob63StNRc=.9c0c1224-c78a-4616-87ec-7461d736600f@github.com>
References: <FFtTlMxFEPEmLSI_r3rGeSB4f6_jE19NLnob63StNRc=.9c0c1224-c78a-4616-87ec-7461d736600f@github.com>
Message-ID: <XbOeezijw3mGOi16xXluzPJPfrqvcCx2oCj-f_0elAk=.b94846c1-7cec-4607-bfb5-bda015926a5d@github.com>

> Updating and regularizing several references to Knuth's The Art of Computer Programming.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  8260329

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2215/files
  - new: https://git.openjdk.java.net/jdk/pull/2215/files/11086168..8e334c0d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2215&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2215&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2215.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2215/head:pull/2215

PR: https://git.openjdk.java.net/jdk/pull/2215

From darcy at openjdk.java.net  Mon Jan 25 19:09:58 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 25 Jan 2021 19:09:58 GMT
Subject: Integrated: 8260329: Update references to TAOCP to latest edition
In-Reply-To: <FFtTlMxFEPEmLSI_r3rGeSB4f6_jE19NLnob63StNRc=.9c0c1224-c78a-4616-87ec-7461d736600f@github.com>
References: <FFtTlMxFEPEmLSI_r3rGeSB4f6_jE19NLnob63StNRc=.9c0c1224-c78a-4616-87ec-7461d736600f@github.com>
Message-ID: <j_4cSymdUDC28VAZ0V8-V0bt20LX7dbpv_6IH_R8Rtk=.de276613-ddf8-42a3-8c65-d7d515c89f28@github.com>

On Mon, 25 Jan 2021 06:10:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Updating and regularizing several references to Knuth's The Art of Computer Programming.

This pull request has now been integrated.

Changeset: 73c78c8a
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/73c78c8a
Stats:     12 lines in 2 files changed: 1 ins; 0 del; 11 mod

8260329: Update references to TAOCP to latest edition

Reviewed-by: alanb, bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/2215

From coleenp at openjdk.java.net  Mon Jan 25 19:14:48 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 25 Jan 2021 19:14:48 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <gh9aHbfKHXKAG3LTBZWitlw6L7p5kxwQC-Xxiyii1Ww=.d56e467d-4135-4785-968c-766c4505eb3c@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <X9wlF4x4NEgbqm4jgkh3npkup8hOt70EBr9HOk_boU0=.2850f987-a8bf-436d-9a8f-f3588f18f0f7@github.com>
 <gh9aHbfKHXKAG3LTBZWitlw6L7p5kxwQC-Xxiyii1Ww=.d56e467d-4135-4785-968c-766c4505eb3c@github.com>
Message-ID: <jXnEmEqfBhFsYuuaQSFX09N2_0SdvH05rEhstHxEtIU=.87837f33-2ddc-4667-84db-b2134a916069@github.com>

On Mon, 25 Jan 2021 15:01:25 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 87:
>> 
>>> 85:   JavaThread* jt = JavaThread::thread_from_jni_environment(jni_env);
>>> 86:   DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(jt));;
>>> 87:   Thread::WXWriteFromExecSetter wx_write;
>> 
>> Is this on every transition to VM from Native?  Would it be better to add to ThreadInVMfromNative like the ResetNoHandleMark is?
>
> I've tried to do something like this initially. The idea was to use Write in VM state and Exec in Java and Native states. However, for example, JIT runs in the Native state and needs Write access. So instead, W^X is managed on entry and exit from VM code, in macros like JRT_ENTRY. Unfortunately, not every JVM entry function is defined with an appropriate macro (at least for now), so I had to add explicit W^X state management along with the explicit java thread state, like here.

Yes, that's why I thought it should be added to the classes ThreadInVMfromNative, etc like:
class ThreadInVMfromNative : public ThreadStateTransition {
  ResetNoHandleMark __rnhm;

We can look at it with cleaning up the thread transitions RFE or as a follow-on.  If every line of ThreadInVMfromNative has to have one of these   Thread::WXWriteVerifier __wx_write;     people are going to miss them when adding the former.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From anleonar at redhat.com  Mon Jan 25 19:22:08 2021
From: anleonar at redhat.com (Andrew Leonard)
Date: Mon, 25 Jan 2021 19:22:08 +0000
Subject: Does "strictfp" affect called/intrinsified Math functions?
Message-ID: <CAFFhbGO6PZx3_F-JeSLJf080nyvtBWbcYbF3yk+=Q5WJwupGWQ@mail.gmail.com>

Hi,
Can I just check my understanding is correct, in that the following example
will not actually return a "strictfp" value, because the Math.exp() is not
strictfp and by default is a non-strictfp Intrinsic inline implementation?
Thanks
Andrew

    private strictfp double strictfpMathExp(double input)
    {
      return Math.exp(input);
    }

From github.com+34924738+mahendrachhipa at openjdk.java.net  Mon Jan 25 19:32:48 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Mon, 25 Jan 2021 19:32:48 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
 [v2]
In-Reply-To: <xBkb4pJvfGw3zc5UEpO2rJLrLo7u-5aUYFjFtjdazqA=.98c049c2-e8f7-456e-b6d8-12cd573a7b4c@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
 <yJcUp9Y_StqxljldFR_wXRA5QsKro5pp3sxqgQWW-js=.6fe3b134-81ee-4925-b951-b60f9e885215@github.com>
 <xBkb4pJvfGw3zc5UEpO2rJLrLo7u-5aUYFjFtjdazqA=.98c049c2-e8f7-456e-b6d8-12cd573a7b4c@github.com>
Message-ID: <mhQtSjQCtqyr_kJUMfebxR9yHbGasz_l59NEzGTVZaw=.c7b1a483-63b4-41c8-8d2d-079835fe92b3@github.com>

On Fri, 22 Jan 2021 17:59:33 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   NonJavaName Tests updated
>>   Used newInstance() method to create the different EnclosingClasses at runtime
>
> test/jdk/java/lang/Class/forName/NonJavaNameTest.java line 49:
> 
>> 47:     private static final String SRC_DIR = System.getProperty("test.src");
>> 48:     private static final String NONJAVA_NAMES_SRC = SRC_DIR + "/classes/";
>> 49:     private static final String NONJAVA_NAMES_CLASSES = System.getProperty("test.classes", ".");
> 
> I was at first confused with `NON_NAMES_CLASSES` of what it means.    For simplicity and clarity, better to rename these variables:
> s/NONJAVA_NAMES_SRC/TEST_SRC/
> s/NONJAVA_NAMES_CLASSES/TEST_CLASSES/

Implemented in next patch

> test/jdk/java/lang/Class/forName/NonJavaNameTest.java line 43:
> 
>> 41:  * @run testng/othervm NonJavaNameTest
>> 42:  * @summary Verify names that aren't legal Java names are accepted by forName.
>> 43:  * @author Joseph D. Darcy
> 
> we can drop this `@author` in particular this is a new file.

Now this file is deleted.

> test/jdk/java/lang/Class/forName/NonJavaNameTest.java line 96:
> 
>> 94: 
>> 95:     @AfterClass
>> 96:     public void deleteInvalidNameClasses() throws IOException {
> 
> jtreg will do the clean up and this is not necessary.

Removed in next patch.

> test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 95:
> 
>> 93:             Files.deleteIfExists(pkg2Dir);
>> 94:             Files.deleteIfExists(pkg1File);
>> 95:             Files.deleteIfExists(pkg1Dir);
> 
> You can consider using `jdk.test.lib.util.FileUtils` test library to remove the entire directory.

Using FileUtils in next patch

> test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 97:
> 
>> 95:             Files.deleteIfExists(pkg1Dir);
>> 96:             Files.createDirectories(pkg2Dir);
>> 97:         } catch (IOException ex) {
> 
> The test should fail when running into any error.    Using the test library will do the retry

Thanks, Corrected in next patch.

> test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 197:
> 
>> 195:                 c.getSimpleName(), annotation.simple(),
>> 196:                 c.getCanonicalName(),
>> 197:                 annotation.hasCanonical() ? annotation.canonical() : null);
> 
> I am guessing this whitespace in line 195-197 is not intentional?  Same for line 203-206?

Thanks, Removed in next patch. Trying to keep maximum line length 120.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2170

From github.com+34924738+mahendrachhipa at openjdk.java.net  Mon Jan 25 19:37:52 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Mon, 25 Jan 2021 19:37:52 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
 [v2]
In-Reply-To: <xBkb4pJvfGw3zc5UEpO2rJLrLo7u-5aUYFjFtjdazqA=.98c049c2-e8f7-456e-b6d8-12cd573a7b4c@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
 <yJcUp9Y_StqxljldFR_wXRA5QsKro5pp3sxqgQWW-js=.6fe3b134-81ee-4925-b951-b60f9e885215@github.com>
 <xBkb4pJvfGw3zc5UEpO2rJLrLo7u-5aUYFjFtjdazqA=.98c049c2-e8f7-456e-b6d8-12cd573a7b4c@github.com>
Message-ID: <h50knYdW8dElRBhMDtc8w9WibLcoHY5FKsroXr1NA0g=.a99bb2ad-8f46-415e-b8a8-5ef08baa030a@github.com>

On Fri, 22 Jan 2021 18:16:54 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   NonJavaName Tests updated
>>   Used newInstance() method to create the different EnclosingClasses at runtime
>
> test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 103:
> 
>> 101:         createAndWriteEnclosingClasses(enclosingPath, pkg2File, "pkg1.pkg2");
>> 102: 
>> 103:         String javacPath = JDKToolFinder.getJDKTool("javac");
> 
> You can use `jdk.test.lib.compiler.CompilerUtils` test library to compile the file in process.

I tried to use the CopmilerUtils to compile the file, But this utility is not able to  the dependencies of the class. Example it is not able to find the common.TestMe class while try to compile the EnclosingClass.java.

> test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 141:
> 
>> 139:     }
>> 140: 
>> 141:     private void createAndWriteEnclosingClasses(final Path source, final Path target, final String packagePath) {
> 
> s/packagePath/packageName/
> 
> no need to declare parameters as `final`

Renamed the packagePath to packageName in next patch. To avoid the Checkstyle warning added the final key word with parameters.

> test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 147:
> 
>> 145:             while ((line = br.readLine()) != null) {
>> 146:                 if (line.contains("canonical=\"EnclosingClass")) {
>> 147:                     line = line.replaceAll("canonical=\"EnclosingClass", "canonical=\"" + packagePath + ".EnclosingClass");
> 
> suggestion: declare `var className = packageName + ".EnclosingClass";`  and replace those occurrance.

Thanks. Implemented the comment in next patch.

> test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 155:
> 
>> 153:                 bw.println(line);
>> 154:             }
>> 155:         } catch (IOException ex) {
> 
> Should not swallow the error and instead, let it propagate and the test should fail.

Thanks. Corrected this in next patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2170

From akozlov at openjdk.java.net  Mon Jan 25 19:38:16 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 25 Jan 2021 19:38:16 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:

 - Refactor CDS disabling
 - Redo builsys support for aarch64-darwin

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/50b55f66..0c2cb0a3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=01-02

  Stats: 36 lines in 3 files changed: 12 ins; 15 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

From github.com+34924738+mahendrachhipa at openjdk.java.net  Mon Jan 25 19:40:42 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Mon, 25 Jan 2021 19:40:42 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
 [v2]
In-Reply-To: <xBkb4pJvfGw3zc5UEpO2rJLrLo7u-5aUYFjFtjdazqA=.98c049c2-e8f7-456e-b6d8-12cd573a7b4c@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
 <yJcUp9Y_StqxljldFR_wXRA5QsKro5pp3sxqgQWW-js=.6fe3b134-81ee-4925-b951-b60f9e885215@github.com>
 <xBkb4pJvfGw3zc5UEpO2rJLrLo7u-5aUYFjFtjdazqA=.98c049c2-e8f7-456e-b6d8-12cd573a7b4c@github.com>
Message-ID: <D_Pq6WlUtNFEhTsDD5URbJshM5slyWSklu-4I7r24IE=.60d914f5-1350-43c4-86a5-910a2fadfb7a@github.com>

On Fri, 22 Jan 2021 18:09:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   NonJavaName Tests updated
>>   Used newInstance() method to create the different EnclosingClasses at runtime
>
> test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 176:
> 
>> 174:     }
>> 175: 
>> 176:     private void check(final Class<?> c, final Class<?> enc,
> 
> I see that you make all parameters in all methods final.   It just adds noise.   Can you leave it out?

To avoid the Checkstyle warnings, I added them.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2170

From prr at openjdk.java.net  Mon Jan 25 20:50:57 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 25 Jan 2021 20:50:57 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
Message-ID: <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>

On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor CDS disabling
>  - Redo builsys support for aarch64-darwin

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 573:

> 571:     EXTRA_HEADER_DIRS := $(LIBFONTMANAGER_EXTRA_HEADER_DIRS), \
> 572:     WARNINGS_AS_ERRORS_xlc := false, \
> 573:     DISABLED_WARNINGS_clang := deprecated-declarations, \

I see this added here and in another location. What is deprecated ? You really need to explain these sorts of things.
I've built JDK using Xcode 12.3 and not had any need for this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From github.com+34924738+mahendrachhipa at openjdk.java.net  Mon Jan 25 20:51:06 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Mon, 25 Jan 2021 20:51:06 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
 [v3]
In-Reply-To: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
Message-ID: <fUm4Dayv7nRXfJMPfSN2K1Q9-MAebjdGT5zMNsN_Tno=.f5968959-48ad-4b72-a811-1db0ff08b10c@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8183372

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  Implemented the review comments.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2170/files
  - new: https://git.openjdk.java.net/jdk/pull/2170/files/e664bd73..9517404b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=01-02

  Stats: 226 lines in 3 files changed: 64 ins; 132 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2170.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2170/head:pull/2170

PR: https://git.openjdk.java.net/jdk/pull/2170

From github.com+34924738+mahendrachhipa at openjdk.java.net  Mon Jan 25 20:51:07 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Mon, 25 Jan 2021 20:51:07 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
 [v2]
In-Reply-To: <xBkb4pJvfGw3zc5UEpO2rJLrLo7u-5aUYFjFtjdazqA=.98c049c2-e8f7-456e-b6d8-12cd573a7b4c@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
 <yJcUp9Y_StqxljldFR_wXRA5QsKro5pp3sxqgQWW-js=.6fe3b134-81ee-4925-b951-b60f9e885215@github.com>
 <xBkb4pJvfGw3zc5UEpO2rJLrLo7u-5aUYFjFtjdazqA=.98c049c2-e8f7-456e-b6d8-12cd573a7b4c@github.com>
Message-ID: <zY_K3MoAofaln-xvsXUeZ1dvpl57_ffmH5IjHHWguJE=.bb06505c-514d-4e77-a4ed-156fed98ae65@github.com>

On Fri, 22 Jan 2021 18:17:33 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   NonJavaName Tests updated
>>   Used newInstance() method to create the different EnclosingClasses at runtime
>
> test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 71:
> 
>> 69: /*
>> 70: * @test
>> 71: * @bug 4992173 4992170
> 
> this needs `@modules jdk.compiler`

Thanks. Added in next patch

-------------

PR: https://git.openjdk.java.net/jdk/pull/2170

From joe.darcy at oracle.com  Mon Jan 25 21:20:15 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 25 Jan 2021 13:20:15 -0800
Subject: Does "strictfp" affect called/intrinsified Math functions?
In-Reply-To: <CAFFhbGO6PZx3_F-JeSLJf080nyvtBWbcYbF3yk+=Q5WJwupGWQ@mail.gmail.com>
References: <CAFFhbGO6PZx3_F-JeSLJf080nyvtBWbcYbF3yk+=Q5WJwupGWQ@mail.gmail.com>
Message-ID: <b560e564-b2b9-665a-4aa9-f3486d2a7932@oracle.com>

Hi Andrew,

On 1/25/2021 11:22 AM, Andrew Leonard wrote:
> Hi,
> Can I just check my understanding is correct, in that the following example
> will not actually return a "strictfp" value, because the Math.exp() is not
> strictfp and by default is a non-strictfp Intrinsic inline implementation?
> Thanks
> Andrew
>
>      private strictfp double strictfpMathExp(double input)
>      {
>        return Math.exp(input);
>      }

The short answer is "no" -- strictfp-ness is *not* an aspect of runtime 
semantics that is dynamically inherited through method calls.

Some more detail, let's say Math.exp had a different Java implementation 
than StrictMath.exp (that is specifically allowed by the API spec). 
Declaring the Math.exp method to be strictfp would *not* (necessarily) 
imply that Math.exp behaved exactly the same as StrictMath.exp since the 
exp approximation algorithm could differ between the two implementation 
in ways not changed by strictfp-ness.

Floating-point parameter values are always strict, that is, always 
32-bit float or 64-bit double. Return values are allowed by have wider 
exponent range, as are intermediates used in expressions. However, in 
practice, Java computations in common JVMs has been all-strict for some 
time; will need to get back to JEP 306 
(http://openjdk.java.net/jeps/306) soon!

HTH,

-Joe


From vkempik at openjdk.java.net  Mon Jan 25 21:21:49 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Mon, 25 Jan 2021 21:21:49 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>
Message-ID: <gj_wnThKIfmIY913pDF9UfWDmaEaM5zpeuGnzpflCFs=.c647f0d9-f5c7-45ff-ba62-15887a071b81@github.com>

On Mon, 25 Jan 2021 19:42:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor CDS disabling
>>  - Redo builsys support for aarch64-darwin
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 573:
> 
>> 571:     EXTRA_HEADER_DIRS := $(LIBFONTMANAGER_EXTRA_HEADER_DIRS), \
>> 572:     WARNINGS_AS_ERRORS_xlc := false, \
>> 573:     DISABLED_WARNINGS_clang := deprecated-declarations, \
> 
> I see this added here and in another location. What is deprecated ? You really need to explain these sorts of things.
> I've built JDK using Xcode 12.3 and not had any need for this.

Hello
I believe it was a workaround for issues with xcode 12.2 in early beta days.
Those issues were fixed later in upstream jdk, so most likely we need to remove these workarounds.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From vkempik at openjdk.java.net  Mon Jan 25 21:21:49 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Mon, 25 Jan 2021 21:21:49 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <gj_wnThKIfmIY913pDF9UfWDmaEaM5zpeuGnzpflCFs=.c647f0d9-f5c7-45ff-ba62-15887a071b81@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>
 <gj_wnThKIfmIY913pDF9UfWDmaEaM5zpeuGnzpflCFs=.c647f0d9-f5c7-45ff-ba62-15887a071b81@github.com>
Message-ID: <adeGQ-2g5gzY-ktzTBvkCmImwYyZ9s2J5qvb_mX82wA=.46778120-7b11-4448-b90f-27d6f3cc033a@github.com>

On Mon, 25 Jan 2021 20:54:38 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 573:
>> 
>>> 571:     EXTRA_HEADER_DIRS := $(LIBFONTMANAGER_EXTRA_HEADER_DIRS), \
>>> 572:     WARNINGS_AS_ERRORS_xlc := false, \
>>> 573:     DISABLED_WARNINGS_clang := deprecated-declarations, \
>> 
>> I see this added here and in another location. What is deprecated ? You really need to explain these sorts of things.
>> I've built JDK using Xcode 12.3 and not had any need for this.
>
> Hello
> I believe it was a workaround for issues with xcode 12.2 in early beta days.
> Those issues were fixed later in upstream jdk, so most likely we need to remove these workarounds.

It seems these workarounds are still needed:

jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:300:39: error: 'NSAlphaFirstBitmapFormat' is deprecated: first deprecated in macOS 10.14 [-Werror,-Wdeprecated-declarations]
                        bitmapFormat: NSAlphaFirstBitmapFormat | NSAlphaNonpremultipliedBitmapFormat
                                      ^~~~~~~~~~~~~~~~~~~~~~~~
                                      NSBitmapFormatAlphaFirst

jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:438:34: error: 'NSBorderlessWindowMask' is deprecated: first deprecated in macOS 10.12 [-Werror,-Wdeprecated-declarations]
                      styleMask: NSBorderlessWindowMask
                                 ^~~~~~~~~~~~~~~~~~~~~~
                                 NSWindowStyleMaskBorderless

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From prr at openjdk.java.net  Mon Jan 25 22:24:47 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 25 Jan 2021 22:24:47 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <adeGQ-2g5gzY-ktzTBvkCmImwYyZ9s2J5qvb_mX82wA=.46778120-7b11-4448-b90f-27d6f3cc033a@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>
 <gj_wnThKIfmIY913pDF9UfWDmaEaM5zpeuGnzpflCFs=.c647f0d9-f5c7-45ff-ba62-15887a071b81@github.com>
 <adeGQ-2g5gzY-ktzTBvkCmImwYyZ9s2J5qvb_mX82wA=.46778120-7b11-4448-b90f-27d6f3cc033a@github.com>
Message-ID: <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com>

On Mon, 25 Jan 2021 21:18:59 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> Hello
>> I believe it was a workaround for issues with xcode 12.2 in early beta days.
>> Those issues were fixed later in upstream jdk, so most likely we need to remove these workarounds.
>
> It seems these workarounds are still needed:
> 
> jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:300:39: error: 'NSAlphaFirstBitmapFormat' is deprecated: first deprecated in macOS 10.14 [-Werror,-Wdeprecated-declarations]
>                         bitmapFormat: NSAlphaFirstBitmapFormat | NSAlphaNonpremultipliedBitmapFormat
>                                       ^~~~~~~~~~~~~~~~~~~~~~~~
>                                       NSBitmapFormatAlphaFirst
> 
> jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:438:34: error: 'NSBorderlessWindowMask' is deprecated: first deprecated in macOS 10.12 [-Werror,-Wdeprecated-declarations]
>                       styleMask: NSBorderlessWindowMask
>                                  ^~~~~~~~~~~~~~~~~~~~~~
>                                  NSWindowStyleMaskBorderless

Are you doing something somewhere to change the target version of macOS or SDK ? I had no such problem.
I think we currently target a macOS 10.9 and if you are changing that it would need discussion.
If you are changing it only for Mac ARM that may make more sense .. 

And these appear to be just API churn by Apple
NSAlphaFirstBitmapFormat is replaced by NSBitmapFormatAlphaFirst

https://developer.apple.com/documentation/appkit/nsbitmapformat/nsbitmapformatalphafirst?language=objc

NSBorderlessWindowMask is replaced by NSWindowStyleMask

https://developer.apple.com/documentation/appkit/nswindowstylemask?language=occ

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From vkempik at openjdk.java.net  Mon Jan 25 22:28:46 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Mon, 25 Jan 2021 22:28:46 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>
 <gj_wnThKIfmIY913pDF9UfWDmaEaM5zpeuGnzpflCFs=.c647f0d9-f5c7-45ff-ba62-15887a071b81@github.com>
 <adeGQ-2g5gzY-ktzTBvkCmImwYyZ9s2J5qvb_mX82wA=.46778120-7b11-4448-b90f-27d6f3cc033a@github.com>
 <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com>
Message-ID: <lUUs89xMKCesBvqrcHR1ARJ4tkAapLf3zsw8Q6Xzy8w=.8805912e-8a45-4a45-9855-e3842cbb7d36@github.com>

On Mon, 25 Jan 2021 22:22:06 GMT, Phil Race <prr at openjdk.org> wrote:

>> It seems these workarounds are still needed:
>> 
>> jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:300:39: error: 'NSAlphaFirstBitmapFormat' is deprecated: first deprecated in macOS 10.14 [-Werror,-Wdeprecated-declarations]
>>                         bitmapFormat: NSAlphaFirstBitmapFormat | NSAlphaNonpremultipliedBitmapFormat
>>                                       ^~~~~~~~~~~~~~~~~~~~~~~~
>>                                       NSBitmapFormatAlphaFirst
>> 
>> jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:438:34: error: 'NSBorderlessWindowMask' is deprecated: first deprecated in macOS 10.12 [-Werror,-Wdeprecated-declarations]
>>                       styleMask: NSBorderlessWindowMask
>>                                  ^~~~~~~~~~~~~~~~~~~~~~
>>                                  NSWindowStyleMaskBorderless
>
> Are you doing something somewhere to change the target version of macOS or SDK ? I had no such problem.
> I think we currently target a macOS 10.9 and if you are changing that it would need discussion.
> If you are changing it only for Mac ARM that may make more sense .. 
> 
> And these appear to be just API churn by Apple
> NSAlphaFirstBitmapFormat is replaced by NSBitmapFormatAlphaFirst
> 
> https://developer.apple.com/documentation/appkit/nsbitmapformat/nsbitmapformatalphafirst?language=objc
> 
> NSBorderlessWindowMask is replaced by NSWindowStyleMask
> 
> https://developer.apple.com/documentation/appkit/nswindowstylemask?language=occ

Min_macos version is changed to 11.0 for macos_aarch64

https://github.com/openjdk/jdk/pull/2200/files/0c2cb0a372bf1a8607810d773b53d6959616a816#diff-7cd97cdbeb3053597e5d6659016cdf0f60b2c412bd39934a43817ee0b717b7a7R136

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From prr at openjdk.java.net  Mon Jan 25 22:45:42 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 25 Jan 2021 22:45:42 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <lUUs89xMKCesBvqrcHR1ARJ4tkAapLf3zsw8Q6Xzy8w=.8805912e-8a45-4a45-9855-e3842cbb7d36@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>
 <gj_wnThKIfmIY913pDF9UfWDmaEaM5zpeuGnzpflCFs=.c647f0d9-f5c7-45ff-ba62-15887a071b81@github.com>
 <adeGQ-2g5gzY-ktzTBvkCmImwYyZ9s2J5qvb_mX82wA=.46778120-7b11-4448-b90f-27d6f3cc033a@github.com>
 <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com>
 <lUUs89xMKCesBvqrcHR1ARJ4tkAapLf3zsw8Q6Xzy8w=.8805912e-8a45-4a45-9855-e3842cbb7d36@github.com>
Message-ID: <aCR3VA-Er-eu7C0InGW42leiGLCMFPq9mWsRdxptH0I=.a7a82ee7-398f-488d-a68b-92922b9ca550@github.com>

On Mon, 25 Jan 2021 22:25:48 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> Are you doing something somewhere to change the target version of macOS or SDK ? I had no such problem.
>> I think we currently target a macOS 10.9 and if you are changing that it would need discussion.
>> If you are changing it only for Mac ARM that may make more sense .. 
>> 
>> And these appear to be just API churn by Apple
>> NSAlphaFirstBitmapFormat is replaced by NSBitmapFormatAlphaFirst
>> 
>> https://developer.apple.com/documentation/appkit/nsbitmapformat/nsbitmapformatalphafirst?language=objc
>> 
>> NSBorderlessWindowMask is replaced by NSWindowStyleMask
>> 
>> https://developer.apple.com/documentation/appkit/nswindowstylemask?language=occ
>
> Min_macos version is changed to 11.0 for macos_aarch64
> 
> https://github.com/openjdk/jdk/pull/2200/files/0c2cb0a372bf1a8607810d773b53d6959616a816#diff-7cd97cdbeb3053597e5d6659016cdf0f60b2c412bd39934a43817ee0b717b7a7R136

1) I meant change to NSWindowStyleMaskBorderless from NSBorderlessWindowMask
2) So maybe rather than the deprecation suppression  you could change both constants to the new ones.
Ordinarily I'd say let someone else do that but this looks like a simple obvious change and is dwarfed by all the other changes going on for Mac ARM ...

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From vkempik at openjdk.java.net  Mon Jan 25 22:50:44 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Mon, 25 Jan 2021 22:50:44 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <aCR3VA-Er-eu7C0InGW42leiGLCMFPq9mWsRdxptH0I=.a7a82ee7-398f-488d-a68b-92922b9ca550@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>
 <gj_wnThKIfmIY913pDF9UfWDmaEaM5zpeuGnzpflCFs=.c647f0d9-f5c7-45ff-ba62-15887a071b81@github.com>
 <adeGQ-2g5gzY-ktzTBvkCmImwYyZ9s2J5qvb_mX82wA=.46778120-7b11-4448-b90f-27d6f3cc033a@github.com>
 <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com>
 <lUUs89xMKCesBvqrcHR1ARJ4tkAapLf3zsw8Q6Xzy8w=.8805912e-8a45-4a45-9855-e3842cbb7d36@github.com>
 <aCR3VA-Er-eu7C0InGW42leiGLCMFPq9mWsRdxptH0I=.a7a82ee7-398f-488d-a68b-92922b9ca550@github.com>
Message-ID: <CG49GDIyQ-LhJSqmQlYJkA6vuaPtbZu0BViteNL3FlE=.23a19350-6984-4d4f-b1bd-1fc6d7d3fc4a@github.com>

On Mon, 25 Jan 2021 22:42:40 GMT, Phil Race <prr at openjdk.org> wrote:

>> Min_macos version is changed to 11.0 for macos_aarch64
>> 
>> https://github.com/openjdk/jdk/pull/2200/files/0c2cb0a372bf1a8607810d773b53d6959616a816#diff-7cd97cdbeb3053597e5d6659016cdf0f60b2c412bd39934a43817ee0b717b7a7R136
>
> 1) I meant change to NSWindowStyleMaskBorderless from NSBorderlessWindowMask
> 2) So maybe rather than the deprecation suppression  you could change both constants to the new ones.
> Ordinarily I'd say let someone else do that but this looks like a simple obvious change and is dwarfed by all the other changes going on for Mac ARM ...

that sounds good to me, I am just afraid to break intel mac on older macos versions with this change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From cjplummer at openjdk.java.net  Mon Jan 25 23:01:47 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 25 Jan 2021 23:01:47 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
Message-ID: <rdKaZHN6LY1Q-gyUsnoyyVo1v_aNHC2FA9o2fnHV7p4=.22083b03-2e46-4ebf-80d0-08ca351a26d7@github.com>

On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor CDS disabling
>  - Redo builsys support for aarch64-darwin

I looked through the SA changes. Overall looks good except for a couple of minor issues noted. For the most part it seems to have been boilerplate copy-n-paste from existing ports. If there is anything you want me to take a closer look at, let me know.

src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m line 702:

> 700:   primitiveArray = (*env)->GetLongArrayElements(env, registerArray, NULL);
> 701: 
> 702: #undef REG_INDEX

I'm not so sure why the #undef and subsequent #define of REG_INDEX is needed since it seems to just get #define'd back to the same value.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/aarch64/BsdAARCH64ThreadContext.java line 2:

> 1: /*
> 2:  * Copyright (c) 2003, Oracle and/or its affiliates. All rights reserved.

Update copyright.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2200

From cjplummer at openjdk.java.net  Mon Jan 25 23:08:48 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 25 Jan 2021 23:08:48 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
Message-ID: <0a4qdfSXm3tmLgOW3MJoTc8VSL4XGnaKXrSEbaeL3h0=.d7c6ce7f-183f-429c-8b3e-7f6bc3379f23@github.com>

On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor CDS disabling
>  - Redo builsys support for aarch64-darwin

JDI changes also look good.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2200

From prr at openjdk.java.net  Mon Jan 25 23:38:44 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 25 Jan 2021 23:38:44 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <tPYHeoCfwsWBUwwbzR-qCHaBALbNGepSA5oFyAPonLU=.3933e6d3-0e0c-40c5-80a8-f5d1d88cc6e7@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>
 <gj_wnThKIfmIY913pDF9UfWDmaEaM5zpeuGnzpflCFs=.c647f0d9-f5c7-45ff-ba62-15887a071b81@github.com>
 <adeGQ-2g5gzY-ktzTBvkCmImwYyZ9s2J5qvb_mX82wA=.46778120-7b11-4448-b90f-27d6f3cc033a@github.com>
 <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com>
 <lUUs89xMKCesBvqrcHR1ARJ4tkAapLf3zsw8Q6Xzy8w=.8805912e-8a45-4a45-9855-e3842cbb7d36@github.com>
 <aCR3VA-Er-eu7C0InGW42leiGLCMFPq9mWsRdxptH0I=.a7a82ee7-398f-488d-a68b-92922b9ca550@github.com>
 <CG49GDIyQ-LhJSqmQlYJkA6vuaPtbZu0BViteNL3FlE=.23a19350-6984-4d4f-b1bd-1fc6d7d3fc4a@github.com>
 <tPYHeoCfwsWBUwwbzR-qCHaBALbNGepSA5oFyAPonLU=.3933e6d3-0e0c-40c5-80a8-f5d1d88cc6e7@github.com>
Message-ID: <WfEqLKuao1Rb3IbgKVhOvdZY-_SQ8bfEmV-kxjm207Y=.b8ff8e15-9379-41d7-9562-fcd84ac34d7e@github.com>

On Mon, 25 Jan 2021 23:34:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> that sounds good to me, I am just afraid to break intel mac on older macos versions with this change.
>
> That may actually be a valid concern. Both say macOS 10.12+ ...  which might conflict with the 10.9 target.

Maybe you should just file a bug after all for this to be dealt with separately.
Certainly if it is NOT fixed now such a bug needs to be filed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From prr at openjdk.java.net  Mon Jan 25 23:38:43 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 25 Jan 2021 23:38:43 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <CG49GDIyQ-LhJSqmQlYJkA6vuaPtbZu0BViteNL3FlE=.23a19350-6984-4d4f-b1bd-1fc6d7d3fc4a@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>
 <gj_wnThKIfmIY913pDF9UfWDmaEaM5zpeuGnzpflCFs=.c647f0d9-f5c7-45ff-ba62-15887a071b81@github.com>
 <adeGQ-2g5gzY-ktzTBvkCmImwYyZ9s2J5qvb_mX82wA=.46778120-7b11-4448-b90f-27d6f3cc033a@github.com>
 <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com>
 <lUUs89xMKCesBvqrcHR1ARJ4tkAapLf3zsw8Q6Xzy8w=.8805912e-8a45-4a45-9855-e3842cbb7d36@github.com>
 <aCR3VA-Er-eu7C0InGW42leiGLCMFPq9mWsRdxptH0I=.a7a82ee7-398f-488d-a68b-92922b9ca550@github.com>
 <CG49GDIyQ-LhJSqmQlYJkA6vuaPtbZu0BViteNL3FlE=.23a19350-6984-4d4f-b1bd-1fc6d7d3fc4a@github.com>
Message-ID: <tPYHeoCfwsWBUwwbzR-qCHaBALbNGepSA5oFyAPonLU=.3933e6d3-0e0c-40c5-80a8-f5d1d88cc6e7@github.com>

On Mon, 25 Jan 2021 22:47:33 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> 1) I meant change to NSWindowStyleMaskBorderless from NSBorderlessWindowMask
>> 2) So maybe rather than the deprecation suppression  you could change both constants to the new ones.
>> Ordinarily I'd say let someone else do that but this looks like a simple obvious change and is dwarfed by all the other changes going on for Mac ARM ...
>
> that sounds good to me, I am just afraid to break intel mac on older macos versions with this change.

That may actually be a valid concern. Both say macOS 10.12+ ...  which might conflict with the 10.9 target.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From jdcrowley at gmail.com  Mon Jan 25 12:33:44 2021
From: jdcrowley at gmail.com (John Crowley)
Date: Mon, 25 Jan 2021 07:33:44 -0500
Subject: jpackage problem submitting to Apple Store
In-Reply-To: <7D58F4B7-2D9F-44B3-BA15-AAED28586E91@gmail.com>
References: <511A88CF-2D6F-4B04-81BE-5BB95B750754@computer.org>
 <7D58F4B7-2D9F-44B3-BA15-AAED28586E91@gmail.com>
Message-ID: <0C799B5F-D3B6-4E8F-8A6A-341A9A3EDE15@computer.org>

Trying again. Changed the name of pkg1.sh to just pkg1 in case email is dropping any executable attachment.

John Crowley
Charlotte, NC
203-856-2396
j.crowley at computer.org





> On Jan 24, 2021, at 9:20 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Jan 24, 2021, at 8:28 AM, John Crowley <jdcrowley at gmail.com> wrote:
>> 
>> Hi All,
>> 
>> Have been having a problem trying to use jpackage to sign an app and submit it to the Apple Store.
>> 
>> Attached are the following:
> 
> No attachments that I?m seeing.
> 


From jdcrowley at gmail.com  Mon Jan 25 12:36:50 2021
From: jdcrowley at gmail.com (John Crowley)
Date: Mon, 25 Jan 2021 07:36:50 -0500
Subject: jpackage problem submitting to Apple Store
In-Reply-To: <7D58F4B7-2D9F-44B3-BA15-AAED28586E91@gmail.com>
References: <511A88CF-2D6F-4B04-81BE-5BB95B750754@computer.org>
 <7D58F4B7-2D9F-44B3-BA15-AAED28586E91@gmail.com>
Message-ID: <4C496BFA-8715-4E5B-A0D1-D1C99CD901AD@computer.org>

As an alternate, a link to Google Drive - https://drive.google.com/drive/folders/1SgLhlovuH2x18gRh-ffhZCHVeXt1AOXo?usp=sharing <https://drive.google.com/drive/folders/1SgLhlovuH2x18gRh-ffhZCHVeXt1AOXo?usp=sharing>

Thanks,

John Crowley
Charlotte, NC
203-856-2396
j.crowley at computer.org






> On Jan 24, 2021, at 9:20 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Jan 24, 2021, at 8:28 AM, John Crowley <jdcrowley at gmail.com> wrote:
>> 
>> Hi All,
>> 
>> Have been having a problem trying to use jpackage to sign an app and submit it to the Apple Store.
>> 
>> Attached are the following:
> 
> No attachments that I?m seeing.
> 


From vkempik at openjdk.java.net  Tue Jan 26 07:26:43 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 26 Jan 2021 07:26:43 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <WfEqLKuao1Rb3IbgKVhOvdZY-_SQ8bfEmV-kxjm207Y=.b8ff8e15-9379-41d7-9562-fcd84ac34d7e@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>
 <gj_wnThKIfmIY913pDF9UfWDmaEaM5zpeuGnzpflCFs=.c647f0d9-f5c7-45ff-ba62-15887a071b81@github.com>
 <adeGQ-2g5gzY-ktzTBvkCmImwYyZ9s2J5qvb_mX82wA=.46778120-7b11-4448-b90f-27d6f3cc033a@github.com>
 <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com>
 <lUUs89xMKCesBvqrcHR1ARJ4tkAapLf3zsw8Q6Xzy8w=.8805912e-8a45-4a45-9855-e3842cbb7d36@github.com>
 <aCR3VA-Er-eu7C0InGW42leiGLCMFPq9mWsRdxptH0I=.a7a82ee7-398f-488d-a68b-92922b9ca550@github.com>
 <CG49GDIyQ-LhJSqmQlYJkA6vuaPtbZu0BViteNL3FlE=.23a19350-6984-4d4f-b1bd-1fc6d7d3fc4a@github.com>
 <tPYHeoCfwsWBUwwbzR-qCHaBALbNGepSA5oFyAPonLU=.3933e6d3-0e0c-40c5-80a8-f5d1d88cc6e7@github.com>
 <WfEqLKuao1Rb3IbgKVhOvdZY-_SQ8bfEmV-
 kxjm207Y=.b8ff8e15-9379-41d7-9562-fcd84ac34d7e@github.com>
Message-ID: <suhKbL5tx6LK-OYunNUVrwm8sQ9p5pnIlf4R8St_6fY=.95827835-840f-4611-b913-88c1a4591dc7@github.com>

On Mon, 25 Jan 2021 23:35:52 GMT, Phil Race <prr at openjdk.org> wrote:

>> That may actually be a valid concern. Both say macOS 10.12+ ...  which might conflict with the 10.9 target.
>
> Maybe you should just file a bug after all for this to be dealt with separately.
> Certainly if it is NOT fixed now such a bug needs to be filed.

I have created https://bugs.openjdk.java.net/browse/JDK-8260402 which is blocked by jep-391 currently

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From stefank at openjdk.java.net  Tue Jan 26 08:57:54 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Tue, 26 Jan 2021 08:57:54 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
Message-ID: <LPIrDcPyBUiYSxhlNElZv49wesHgigBXIRjiQ0npkFY=.32795c2b-2d9f-4fb5-9a35-b7b7d4e7fa49@github.com>

On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor CDS disabling
>  - Redo builsys support for aarch64-darwin

>     * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.

I wonder if this is the right choice. I think it would have been good if this could have been completely hidden in the transition classes. However, that doesn't seem to have been enough and now there are explicit Thread::WXWriteFromExecSetter instances where it's not at all obvious why they are needed. For example, why was it added here?:
OopStorageParIterPerf::~OopStorageParIterPerf() {
  // missing transition to vm state
  Thread::WXWriteFromExecSetter wx_write;
  _storage.release(_entries, ARRAY_SIZE(_entries));
}
You need to dig down in the OopStorage implementation to find that it's because it uses SafeFetch, which has the opposite transition:
inline int SafeFetch32(int* adr, int errValue) {
  assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");
  Thread::WXExecFromWriteSetter wx_exec;
  return StubRoutines::SafeFetch32_stub()(adr, errValue);
}
I think this adds complexity to code that shouldn't have to deal with this. I'm fine with having to force devs / code that writes to exec memory to have to deal with a bit more complexity, but it seems wrong to let this leak out to code that is staying far away from that.

For my understanding, was this choice made because the nmethods instances (and maybe other types as well) are placed in the code cache memory segment, which is executable? If the code cache only contained the JIT:ed code, and not object instances, I think this could more easily have been contained a bit more.

If the proposed solution is going to stay, maybe this could be made a little bit nicer by changing the SafeFetch implementation to use a new scoped object that doesn't enforce the "from" state to be "write"? Instead it could check if the state is "write" and only then flip the state back and forth. I think, this would remove the change needed OopStorageParIterPerf, and probably other places as well.

src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp line 38:

> 36: #include "runtime/os.hpp"
> 37: #include "runtime/stubRoutines.hpp"
> 38: #include "runtime/stubRoutines.inline.hpp"

Remove stubRutines.hpp line

src/hotspot/share/runtime/stubRoutines.inline.hpp line 29:

> 27: 
> 28: #include <runtime/thread.hpp>
> 29: #include <runtime/stubRoutines.hpp>

Replace < > with " "

src/hotspot/os/aix/os_aix.cpp line 70:

> 68: #include "runtime/statSampler.hpp"
> 69: #include "runtime/stubRoutines.hpp"
> 70: #include "runtime/stubRoutines.inline.hpp"

Remove stubRutines.hpp line

-------------

Changes requested by stefank (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2200

From ihse at openjdk.java.net  Tue Jan 26 09:25:50 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 26 Jan 2021 09:25:50 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
Message-ID: <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>

On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor CDS disabling
>  - Redo builsys support for aarch64-darwin

Changes requested by ihse (Reviewer).

make/autoconf/build-aux/autoconf-config.guess line 1275:

> 1273: 		      UNAME_PROCESSOR="aarch64"
> 1274: 		  fi
> 1275: 		fi ;;

Almost, but not quite, correct. We cannot change the autoconf-config.guess file due to license restrictions (the license allows redistribution, not modifications). Instead we have the config.guess file which "wraps" autoconf-config.guess and makes pre-/post-call modifications to work around limitations in the autoconf original file. So you need to check there if you are getting incorrect results back and adjust it in that case. See the already existing clauses in that file.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From ihse at openjdk.java.net  Tue Jan 26 10:14:41 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 26 Jan 2021 10:14:41 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v4]
In-Reply-To: <ad2uU37xBO8wpE-w6Ogj3paBihqfXiKLRJ627VwNgkc=.1d6a7573-d606-4eb1-ba21-5daaf47c485c@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>
 <YT7on7W1w9GJRTMfz2KtftKo7yGbVTgZxYcqXv1POBU=.59b49a13-da41-4c93-88c7-1830b87d0b63@github.com>
 <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com>
 <ABB2Pleoo1GTfmn0SdjrztH_u6VrfPRseLfMIrYhMdg=.a576b5bc-b25b-43ee-b5d3-394bce1415ca@github.com>
 <ad2uU37xBO8wpE-w6Ogj3paBihqfXiKLRJ627VwNgkc=.1d6a7573-d606-4eb1-ba21-5daaf47c485c@github.com>
Message-ID: <aq-xpyHEodngcRGTGmPGqWJ3nsBiCmJEDWvyvjLXBxo=.fb62e3dd-ddbf-4b71-b3fb-3d93d7fdd4bf@github.com>

On Sat, 23 Jan 2021 07:55:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> We should create a separate issue to rename them and get rid of the copying in the make file.

I opened https://bugs.openjdk.java.net/browse/JDK-8260406.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1611

From ihse at openjdk.java.net  Tue Jan 26 10:39:50 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 26 Jan 2021 10:39:50 GMT
Subject: RFR: 8260406: Do not copy pure java source code to gensrc
Message-ID: <mphLq20MyNWOF3ZcnmkTRBiLM5KuAoiefQyvtRLh4SE=.a0cd9436-f299-4ce9-9659-dd5ca84c6cfa@github.com>

For java.base gensrc we do the following:

# Copy two Java files that need no preprocessing.
$(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java: $(CHARACTERDATA_TEMPLATES)/%.java.template
$(call LogInfo, Generating $(@F))
$(call install-file)

GENSRC_CHARACTERDATA += $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataUndefined.java \
    $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataPrivateUse.java

What this means is that we have two "template" files that are just compiled as java files, but only after being copied to gensrc. :-)

We should just rename these files to java and move them to the normal source directory.

-------------

Commit messages:
 - 8260406: Do not copy pure java source code to gensrc

Changes: https://git.openjdk.java.net/jdk/pull/2233/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2233&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260406
  Stats: 9 lines in 3 files changed: 0 ins; 8 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2233.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2233/head:pull/2233

PR: https://git.openjdk.java.net/jdk/pull/2233

From akozlov at openjdk.java.net  Tue Jan 26 11:33:45 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 26 Jan 2021 11:33:45 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <-_A-bf8i3jWY1awmyxwzi3yv4UoJQelRbJrMQVWQGLU=.5103b95d-3ad7-4a70-8d46-60c0eb0a301f@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com>
 <-_A-bf8i3jWY1awmyxwzi3yv4UoJQelRbJrMQVWQGLU=.5103b95d-3ad7-4a70-8d46-60c0eb0a301f@github.com>
Message-ID: <YPcSqODkAflJPr_fnUNlHxpGB9IQSNqMhuf_2gFq8GY=.c8ed7d36-a354-43a8-9161-9c7160e7096b@github.com>

On Mon, 25 Jan 2021 14:40:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/thread.hpp line 915:
>> 
>>> 913:       verify_wx_state(WXExec);
>>> 914:     }
>>> 915:   };
>> 
>> Rather than add all this to thread.hpp, can you make a wxVerifier.hpp and just add the class instance as a field in thread.hpp?
>
> This could be a follow-up RFE.

I assume a WXVerifier class that tracks W^X mode in debug mode and does nothing in release mode. I've considered to do this, it's relates to small inefficiencies, while this patch brings zero overhead (in release) for a platform that does not need W^X. 
* We don't need thread instance in release to call `os::current_thread_enable_wx`. Having WXVerifier a part of the Thread will require calling `Thread::current()` first and we could only hope for compiler to optimize this out, not sure if it will happen at all. In some contexts the Thread instance is available, in some it's not. 
* An instance of the empty class (as WXVerifier will be in the release) will occupy non-zero space in the Thread instance.

If such costs are negligible, I can do as suggested.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From alanb at openjdk.java.net  Tue Jan 26 11:48:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 26 Jan 2021 11:48:40 GMT
Subject: RFR: 8260406: Do not copy pure java source code to gensrc
In-Reply-To: <mphLq20MyNWOF3ZcnmkTRBiLM5KuAoiefQyvtRLh4SE=.a0cd9436-f299-4ce9-9659-dd5ca84c6cfa@github.com>
References: <mphLq20MyNWOF3ZcnmkTRBiLM5KuAoiefQyvtRLh4SE=.a0cd9436-f299-4ce9-9659-dd5ca84c6cfa@github.com>
Message-ID: <KnKRax-YYQEj1WyBuk4oXFsdQYoLU_ypuU79gcnEwYU=.853cc18a-4d95-4d1e-b95a-197c02f8657c@github.com>

On Tue, 26 Jan 2021 10:35:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> For java.base gensrc we do the following:
> 
> # Copy two Java files that need no preprocessing.
> $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java: $(CHARACTERDATA_TEMPLATES)/%.java.template
> $(call LogInfo, Generating $(@F))
> $(call install-file)
> 
> GENSRC_CHARACTERDATA += $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataUndefined.java \
>     $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataPrivateUse.java
> 
> What this means is that we have two "template" files that are just compiled as java files, but only after being copied to gensrc. :-)
> 
> We should just rename these files to java and move them to the normal source directory.

Good. I notice the comment in both source files says "Java.lang.Character" rather than "java.lang.Character", probably should fix that at some point.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2233

From redestad at openjdk.java.net  Tue Jan 26 11:52:53 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 26 Jan 2021 11:52:53 GMT
Subject: RFR: 8260391: Remove StringCoding::err
Message-ID: <oC8kygG9JP-QrcBdh-WctL8EISrhAsYydOyRslQWMsQ=.735d4978-96f6-4609-8b06-207c9d5e667f@github.com>

This patch removes the unused StringCoding::err method, and the associated native code.

-------------

Commit messages:
 - Remove StringCoding::err

Changes: https://git.openjdk.java.net/jdk/pull/2236/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2236&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260391
  Stats: 82 lines in 2 files changed: 0 ins; 82 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2236.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2236/head:pull/2236

PR: https://git.openjdk.java.net/jdk/pull/2236

From redestad at openjdk.java.net  Tue Jan 26 11:52:53 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 26 Jan 2021 11:52:53 GMT
Subject: RFR: 8260391: Remove StringCoding::err
In-Reply-To: <oC8kygG9JP-QrcBdh-WctL8EISrhAsYydOyRslQWMsQ=.735d4978-96f6-4609-8b06-207c9d5e667f@github.com>
References: <oC8kygG9JP-QrcBdh-WctL8EISrhAsYydOyRslQWMsQ=.735d4978-96f6-4609-8b06-207c9d5e667f@github.com>
Message-ID: <eTYjpJwVEahptpPdzKtamKp6jpLDGoqseHNNJydUA_E=.833b744d-b634-40b3-af51-857f5fb7000a@github.com>

On Tue, 26 Jan 2021 11:47:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch removes the unused StringCoding::err method, and the associated native code.

Testing: tier1+2

-------------

PR: https://git.openjdk.java.net/jdk/pull/2236

From coleenp at openjdk.java.net  Tue Jan 26 12:04:48 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 26 Jan 2021 12:04:48 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <YPcSqODkAflJPr_fnUNlHxpGB9IQSNqMhuf_2gFq8GY=.c8ed7d36-a354-43a8-9161-9c7160e7096b@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com>
 <-_A-bf8i3jWY1awmyxwzi3yv4UoJQelRbJrMQVWQGLU=.5103b95d-3ad7-4a70-8d46-60c0eb0a301f@github.com>
 <YPcSqODkAflJPr_fnUNlHxpGB9IQSNqMhuf_2gFq8GY=.c8ed7d36-a354-43a8-9161-9c7160e7096b@github.com>
Message-ID: <OTfNjQUNPASnskM8tBLuTLhT5OrJ36rjx4RDRbyBhQo=.05a1a086-9494-4483-963a-cb41955623a5@github.com>

On Tue, 26 Jan 2021 11:31:18 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> This could be a follow-up RFE.
>
> I assume a WXVerifier class that tracks W^X mode in debug mode and does nothing in release mode. I've considered to do this, it's relates to small inefficiencies, while this patch brings zero overhead (in release) for a platform that does not need W^X. 
> * We don't need thread instance in release to call `os::current_thread_enable_wx`. Having WXVerifier a part of the Thread will require calling `Thread::current()` first and we could only hope for compiler to optimize this out, not sure if it will happen at all. In some contexts the Thread instance is available, in some it's not. 
> * An instance of the empty class (as WXVerifier will be in the release) will occupy non-zero space in the Thread instance.
> 
> If such costs are negligible, I can do as suggested.

I really just want the minimal number of lines of code and hooks in thread.hpp.  You can still access it through the thread, just like these lines currently.  Look at HandshakeState as an example.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From github.com+4146708+a74nh at openjdk.java.net  Tue Jan 26 12:04:47 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Tue, 26 Jan 2021 12:04:47 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
Message-ID: <RVUqncN8BLrGU1Rxdrg1zk_yE-sSQsZ08fge6Jp9ijI=.c355f1e9-1b9f-4e11-9243-c44b557b447d@github.com>

On Tue, 26 Jan 2021 09:23:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor CDS disabling
>>  - Redo builsys support for aarch64-darwin
>
> Changes requested by ihse (Reviewer).

AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework
ie:
`
--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'
`

Otherwise there will be missing _JNFNative* functions.

Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From vkempik at openjdk.java.net  Tue Jan 26 12:09:42 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 26 Jan 2021 12:09:42 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <RVUqncN8BLrGU1Rxdrg1zk_yE-sSQsZ08fge6Jp9ijI=.c355f1e9-1b9f-4e11-9243-c44b557b447d@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
 <RVUqncN8BLrGU1Rxdrg1zk_yE-sSQsZ08fge6Jp9ijI=.c355f1e9-1b9f-4e11-9243-c44b557b447d@github.com>
Message-ID: <AE1YSbX-p_TaPh63xDXrPiDSfWhU6Ve4fDxg5KPrFSc=.7a3c8269-7238-4928-af00-00c3e13e76c6@github.com>

On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework
> ie:
> `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`
> 
> Otherwise there will be missing _JNFNative* functions.
> 
> Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts?

There is ongoing work by P. Race to eliminate dependence on JNF at all

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From github.com+4146708+a74nh at openjdk.java.net  Tue Jan 26 12:36:44 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Tue, 26 Jan 2021 12:36:44 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <AE1YSbX-p_TaPh63xDXrPiDSfWhU6Ve4fDxg5KPrFSc=.7a3c8269-7238-4928-af00-00c3e13e76c6@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
 <RVUqncN8BLrGU1Rxdrg1zk_yE-sSQsZ08fge6Jp9ijI=.c355f1e9-1b9f-4e11-9243-c44b557b447d@github.com>
 <AE1YSbX-p_TaPh63xDXrPiDSfWhU6Ve4fDxg5KPrFSc=.7a3c8269-7238-4928-af00-00c3e13e76c6@github.com>
Message-ID: <5n9zRTs8D3vp3QU8I7JxtR-Ly-yJKqUb_2NFZRf488Q=.f49c6b0f-6768-4e4a-87ec-fe46a7cf287b@github.com>

On Tue, 26 Jan 2021 12:06:28 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> > AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework
> > ie:
> > `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`
> > Otherwise there will be missing _JNFNative* functions.
> > Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts?
> 
> There is ongoing work by P. Race to eliminate dependence on JNF at all

Ok, that's great.
In the meantime is it worth adding something to the MacOS section of doc/building.* ?
(I pieced together the required line from multiple posts in a mailing list)

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From magnus.ihse.bursie at oracle.com  Tue Jan 26 12:44:34 2021
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 26 Jan 2021 13:44:34 +0100
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <AE1YSbX-p_TaPh63xDXrPiDSfWhU6Ve4fDxg5KPrFSc=.7a3c8269-7238-4928-af00-00c3e13e76c6@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
 <RVUqncN8BLrGU1Rxdrg1zk_yE-sSQsZ08fge6Jp9ijI=.c355f1e9-1b9f-4e11-9243-c44b557b447d@github.com>
 <AE1YSbX-p_TaPh63xDXrPiDSfWhU6Ve4fDxg5KPrFSc=.7a3c8269-7238-4928-af00-00c3e13e76c6@github.com>
Message-ID: <0ce3d16d-76e1-dd38-1b13-d693bc490915@oracle.com>

On 2021-01-26 13:09, Vladimir Kempik wrote:
> On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:
>
>> AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework
>> ie:
>> `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`
>>
>> Otherwise there will be missing _JNFNative* functions.
>>
>> Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts?
> There is ongoing work by P. Race to eliminate dependence on JNF at all
How far has that work come? Otherwise the logic should be added to 
configure to look for this framework automatically, and provide a way to 
override it/set it if not found.

I don't think it's OK to publish a new port that cannot build 
out-of-the-box without hacks like this.

/Magnus
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/2200


From akozlov at openjdk.java.net  Tue Jan 26 12:52:44 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 26 Jan 2021 12:52:44 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <jXnEmEqfBhFsYuuaQSFX09N2_0SdvH05rEhstHxEtIU=.87837f33-2ddc-4667-84db-b2134a916069@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <X9wlF4x4NEgbqm4jgkh3npkup8hOt70EBr9HOk_boU0=.2850f987-a8bf-436d-9a8f-f3588f18f0f7@github.com>
 <gh9aHbfKHXKAG3LTBZWitlw6L7p5kxwQC-Xxiyii1Ww=.d56e467d-4135-4785-968c-766c4505eb3c@github.com>
 <jXnEmEqfBhFsYuuaQSFX09N2_0SdvH05rEhstHxEtIU=.87837f33-2ddc-4667-84db-b2134a916069@github.com>
Message-ID: <LAHF4QAE1MzvoQElpyRW5K_MnNdA3asNRceSXclodHw=.b2b705e3-a073-4597-8293-b2f25fdca37f@github.com>

On Mon, 25 Jan 2021 19:12:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I've tried to do something like this initially. The idea was to use Write in VM state and Exec in Java and Native states. However, for example, JIT runs in the Native state and needs Write access. So instead, W^X is managed on entry and exit from VM code, in macros like JRT_ENTRY. Unfortunately, not every JVM entry function is defined with an appropriate macro (at least for now), so I had to add explicit W^X state management along with the explicit java thread state, like here.
>
> Yes, that's why I thought it should be added to the classes ThreadInVMfromNative, etc like:
> class ThreadInVMfromNative : public ThreadStateTransition {
>   ResetNoHandleMark __rnhm;
> 
> We can look at it with cleaning up the thread transitions RFE or as a follow-on.  If every line of ThreadInVMfromNative has to have one of these   Thread::WXWriteVerifier __wx_write;     people are going to miss them when adding the former.

Not every ThreadInVMfromNative needs this, for example JIT goes to Native state without changing of W^X state. But from some experience of maintaining this patch, I actually had a duty to add missing W^X transitions after assert failures. A possible solution is actually to make W^X transition a part of ThreadInVMfromNative (and similar), but controlled by an optional constructor parameter with possible values "do exec->write", "verify write"...;. So in a common case ThreadInVMfromNative would implicitly do the transition and still would allow something uncommon like verification of the state for the JIT. I have to think about this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From jiefu at openjdk.java.net  Tue Jan 26 13:27:40 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 26 Jan 2021 13:27:40 GMT
Subject: RFR: 8259925: [Vector API] Unreasonable IndexOutOfBoundsException
 message when length < vlen
In-Reply-To: <oGnSUOfY151JLoMo2ITtc6FRLOQ-210RjUl-nGnhBgo=.36a91aa9-de48-4818-aea7-a9ba99a506e5@github.com>
References: <IXlGGauVhUjxPJXm8CjZ0Eo4-ySUttJ_EqYpxiW7p8E=.32dc9082-78ad-4407-a6a2-3652dfef8a4c@github.com>
 <LzL6761_WZOicSWpwUGbYjnnWKlqQPSLtMqLKp5Q_ls=.343834be-ef22-4bc1-91c5-c8388627f6f5@github.com>
 <ZAH7vzOKC5VPi7V6ElL55VxQsgA4AAuVUOH4v8u4QfY=.4cb1b26e-6c19-4083-8495-2d046efa3ddd@github.com>
 <wc6FWksUAR7mY0S_XQox0UgcR9DwpOswrqNRpAZrnDI=.e7327508-a423-4c35-854e-02a55c0aa971@github.com>
 <7fzq6Na3zlPQIp8-ZRytFFDHLU58CaWon0tNEzww4yc=.e4e11ac0-4906-4da0-af83-c3ac8de1f957@github.com>
 <oGnSUOfY151JLoMo2ITtc6FRLOQ-210RjUl-nGnhBgo=.36a91aa9-de48-4818-aea7-a9ba99a506e5@github.com>
Message-ID: <dauO6-VuQ7oX4AzzYFoMIAf3pUZrKKf4Fx8ODhIK27E=.c1ae3c03-dd95-439a-b4fd-8ffa3cfba5e3@github.com>

On Thu, 21 Jan 2021 16:54:36 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> The intrinsic enables C2 to more reliably elide bounds checks. I don't know the exact details but at a high-level it transforms signed values into unsigned values (and therefore the signed comparisons become unsigned comparisons), which helps C2 remove checks when there is a dominating check of, for example, an upper loop bound.
> 
> You say "the intrinsified Objects.checkIndex seems to generate more code than inlined if-statements". Can you present some examples of Java code and the corresponding C2 generated assembler where this happens?

Hi @PaulSandoz ,

I agree with you that let's keep the code as it is for the sake of performance.

I spent some time looking into the assembly code generated by Objects.checkIndex and inlined if-statements.
Here are the test program [1], running script [2] and diff [3].

 - For testSimple [4] that I checked last week, inlined if-statements [5] is better than Objects.checkIndex [6].
 - However, for testLoop [7], Objects.checkIndex [8] is better than inlined if-statements [9].
   (I'm sorry I didn't check loop methods last week.)
   AFAICS, the inlined if-statements will generate two more instructions [10] to check wether idx >= 0 for each loop iteration.

It seems that the intrinsified Objects.checkIndex will be able to optimize out the lower bound check for loops.
So I also agree with you that an intrinsified method seems the right choice.

Thanks.
Best regards,
Jie

[1] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/Bar.java
[2] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/1.sh
[3] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/1.diff
[4] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/Bar.java#L10
[5] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/3-testSimple.log
[6] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/2-testSimple.log
[7] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/Bar.java#L15
[8] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/2-testLoop.log
[9] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/3-testLoop.log
[10] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/3-testLoop.log#L135

-------------

PR: https://git.openjdk.java.net/jdk/pull/2127

From jlahoda at openjdk.java.net  Tue Jan 26 13:45:40 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 26 Jan 2021 13:45:40 GMT
Subject: Integrated: 8242456: PreviewFeature.Feature enum removal of
 TEXT_BLOCKS
In-Reply-To: <YMZvuKAKkou_KXKbudx_xXDmq4t2I5rdePt_0PeGNdI=.1eafe546-b5ed-4fe4-a124-5dc78ef43bba@github.com>
References: <YMZvuKAKkou_KXKbudx_xXDmq4t2I5rdePt_0PeGNdI=.1eafe546-b5ed-4fe4-a124-5dc78ef43bba@github.com>
Message-ID: <0BAew0yyRZKxJUVisyRKALBcn2f0wDlePsPDLofzHd4=.9153df78-b969-4a32-bea1-dd1978760f36@github.com>

On Mon, 25 Jan 2021 11:55:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The enum constant is unused, and can be removed. The class is not an API.

This pull request has now been integrated.

Changeset: 5e8e0ada
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5e8e0ada
Stats:     7 lines in 1 file changed: 0 ins; 7 del; 0 mod

8242456: PreviewFeature.Feature enum removal of TEXT_BLOCKS

Reviewed-by: jlaskey

-------------

PR: https://git.openjdk.java.net/jdk/pull/2218

From erikj at openjdk.java.net  Tue Jan 26 13:52:40 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 26 Jan 2021 13:52:40 GMT
Subject: RFR: 8260406: Do not copy pure java source code to gensrc
In-Reply-To: <mphLq20MyNWOF3ZcnmkTRBiLM5KuAoiefQyvtRLh4SE=.a0cd9436-f299-4ce9-9659-dd5ca84c6cfa@github.com>
References: <mphLq20MyNWOF3ZcnmkTRBiLM5KuAoiefQyvtRLh4SE=.a0cd9436-f299-4ce9-9659-dd5ca84c6cfa@github.com>
Message-ID: <qYJMQ0wf-q_2v9loxJlSNq9SNPyv1mGuuotj7ZgVmP8=.f713be22-f637-49d5-b833-493b3550b2db@github.com>

On Tue, 26 Jan 2021 10:35:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> For java.base gensrc we do the following:
> 
> # Copy two Java files that need no preprocessing.
> $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java: $(CHARACTERDATA_TEMPLATES)/%.java.template
> $(call LogInfo, Generating $(@F))
> $(call install-file)
> 
> GENSRC_CHARACTERDATA += $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataUndefined.java \
>     $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataPrivateUse.java
> 
> What this means is that we have two "template" files that are just compiled as java files, but only after being copied to gensrc. :-)
> 
> We should just rename these files to java and move them to the normal source directory.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2233

From shade at openjdk.java.net  Tue Jan 26 13:56:41 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 26 Jan 2021 13:56:41 GMT
Subject: RFR: 8260391: Remove StringCoding::err
In-Reply-To: <oC8kygG9JP-QrcBdh-WctL8EISrhAsYydOyRslQWMsQ=.735d4978-96f6-4609-8b06-207c9d5e667f@github.com>
References: <oC8kygG9JP-QrcBdh-WctL8EISrhAsYydOyRslQWMsQ=.735d4978-96f6-4609-8b06-207c9d5e667f@github.com>
Message-ID: <tWIqUQzKZEzAMVnVp20USUEfTB6UeA8nLRXSPlTAKnc=.592b5abe-a02e-4d10-a6c1-fef44c2abe42@github.com>

On Tue, 26 Jan 2021 11:47:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch removes the unused StringCoding::err method, and the associated native code.

Looks fine.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2236

From ihse at openjdk.java.net  Tue Jan 26 14:11:41 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 26 Jan 2021 14:11:41 GMT
Subject: Integrated: 8260406: Do not copy pure java source code to gensrc
In-Reply-To: <mphLq20MyNWOF3ZcnmkTRBiLM5KuAoiefQyvtRLh4SE=.a0cd9436-f299-4ce9-9659-dd5ca84c6cfa@github.com>
References: <mphLq20MyNWOF3ZcnmkTRBiLM5KuAoiefQyvtRLh4SE=.a0cd9436-f299-4ce9-9659-dd5ca84c6cfa@github.com>
Message-ID: <rPRO86ud7e4KzdBXYH1cLz56ykiWRJfsgeWgLoJLESw=.4cc87f17-ea8a-4a09-b9cb-c80516d05ab4@github.com>

On Tue, 26 Jan 2021 10:35:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> For java.base gensrc we do the following:
> 
> # Copy two Java files that need no preprocessing.
> $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java: $(CHARACTERDATA_TEMPLATES)/%.java.template
> $(call LogInfo, Generating $(@F))
> $(call install-file)
> 
> GENSRC_CHARACTERDATA += $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataUndefined.java \
>     $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataPrivateUse.java
> 
> What this means is that we have two "template" files that are just compiled as java files, but only after being copied to gensrc. :-)
> 
> We should just rename these files to java and move them to the normal source directory.

This pull request has now been integrated.

Changeset: 8d2f77fd
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8d2f77fd
Stats:     9 lines in 3 files changed: 0 ins; 8 del; 1 mod

8260406: Do not copy pure java source code to gensrc

Reviewed-by: alanb, erikj

-------------

PR: https://git.openjdk.java.net/jdk/pull/2233

From rriggs at openjdk.java.net  Tue Jan 26 14:49:40 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 26 Jan 2021 14:49:40 GMT
Subject: RFR: 8260391: Remove StringCoding::err
In-Reply-To: <oC8kygG9JP-QrcBdh-WctL8EISrhAsYydOyRslQWMsQ=.735d4978-96f6-4609-8b06-207c9d5e667f@github.com>
References: <oC8kygG9JP-QrcBdh-WctL8EISrhAsYydOyRslQWMsQ=.735d4978-96f6-4609-8b06-207c9d5e667f@github.com>
Message-ID: <EhpL06PPwwUbrcvin3Olak5iJJdFu-Fl5UG6pGskR5k=.f51eba33-a914-4360-a8f7-4e2ac50c29ba@github.com>

On Tue, 26 Jan 2021 11:47:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch removes the unused StringCoding::err method, and the associated native code.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2236

From akozlov at openjdk.java.net  Tue Jan 26 15:06:14 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 26 Jan 2021 15:06:14 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v4]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <XYWWD_-xDBcyFTTPPpMp1ZFg6yTMYHekN6gGIchvl6Q=.089fc86a-cdda-4c8e-9da5-c0aa5bf45b44@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request incrementally with three additional commits since the last revision:

 - Little adjustement of SlowSignatureHandler
 - Partially bring previous commit
 - Revert "Address feedback for signature generators"
   
   This reverts commit 50b55f6684cd21f8b532fa979b7b6fbb4613266d.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/0c2cb0a3..fef36580

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=02-03

  Stats: 98 lines in 1 file changed: 74 ins; 13 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Tue Jan 26 15:06:14 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 26 Jan 2021 15:06:14 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v4]
In-Reply-To: <0WPkx3i-N0HHqCqrxE_B0Rf2akunbQaWQb7M7Z88BQY=.c582d11a-ba8d-4789-a55b-279e1286ad8d@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
 <FIAu02KPkeT8mjt2BKIcVnei38gRk3aoXWTfpIvFhos=.773b9848-15d8-45b5-9669-4df8ca65b2d0@github.com>
 <0WPkx3i-N0HHqCqrxE_B0Rf2akunbQaWQb7M7Z88BQY=.c582d11a-ba8d-4789-a55b-279e1286ad8d@github.com>
Message-ID: <yrOiRGUo0yNwPkJP1jmyylqNEOqZwbRcwSs5aWi_eKc=.5a1f3d0f-b71a-4af8-8708-9299d188f8aa@github.com>

On Mon, 25 Jan 2021 10:00:20 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> I like the suggestion. For the defense, new functions were made this way intentionally, to match existing `pass_int`, `pass_long`,.. I take your comment as a blessing to fix all of them. But I feel that refactoring of existing code should go in a separate commit. Especially after `pass_int` used `ldr/str` instead of `ldrw/strw`, which looks wrong. https://github.com/openjdk/jdk/pull/2200/files#diff-1ff58ce70aeea7e9842d34e8d8fd9c94dd91182999d455618b2a171efd8f742cL87-R122
>
> This is new code, and it should not repeat the mistakes of the past. There's no need to refactor the similar existing code as part of this patch.

Makes sense, I've reverted changes in the old code but will propose them in the separate PR shortly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From redestad at openjdk.java.net  Tue Jan 26 15:27:41 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 26 Jan 2021 15:27:41 GMT
Subject: RFR: 8260391: Remove StringCoding::err
In-Reply-To: <tWIqUQzKZEzAMVnVp20USUEfTB6UeA8nLRXSPlTAKnc=.592b5abe-a02e-4d10-a6c1-fef44c2abe42@github.com>
References: <oC8kygG9JP-QrcBdh-WctL8EISrhAsYydOyRslQWMsQ=.735d4978-96f6-4609-8b06-207c9d5e667f@github.com>
 <tWIqUQzKZEzAMVnVp20USUEfTB6UeA8nLRXSPlTAKnc=.592b5abe-a02e-4d10-a6c1-fef44c2abe42@github.com>
Message-ID: <d3qzOb6bx3LvBJAeHOHEoAu_9QSUrXO0MQNTWaWAs3k=.5ac00872-c5db-4f18-9205-194c98d6d652@github.com>

On Tue, 26 Jan 2021 13:53:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This patch removes the unused StringCoding::err method, and the associated native code.
>
> Looks fine.

@shipilev, @RogerRiggs, thanks for reviewing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2236

From redestad at openjdk.java.net  Tue Jan 26 15:27:43 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 26 Jan 2021 15:27:43 GMT
Subject: Integrated: 8260391: Remove StringCoding::err
In-Reply-To: <oC8kygG9JP-QrcBdh-WctL8EISrhAsYydOyRslQWMsQ=.735d4978-96f6-4609-8b06-207c9d5e667f@github.com>
References: <oC8kygG9JP-QrcBdh-WctL8EISrhAsYydOyRslQWMsQ=.735d4978-96f6-4609-8b06-207c9d5e667f@github.com>
Message-ID: <D2ngvXySjDfWo7q1irp1tBATkiDCh5Xd0RqW1Lc4YHA=.ec72dd48-3c19-43ca-aa7d-60872ffa5804@github.com>

On Tue, 26 Jan 2021 11:47:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch removes the unused StringCoding::err method, and the associated native code.

This pull request has now been integrated.

Changeset: b07797c2
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b07797c2
Stats:     82 lines in 2 files changed: 0 ins; 82 del; 0 mod

8260391: Remove StringCoding::err

Reviewed-by: shade, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/2236

From vkempik at openjdk.java.net  Tue Jan 26 16:09:50 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 26 Jan 2021 16:09:50 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com>
Message-ID: <lm6_fD7AG2u5_qnZvcgUhV3sE7lOkhY4VHNthCcRUMo=.fbfa3181-7a8e-4c17-9407-70b41a750333@github.com>

On Mon, 25 Jan 2021 17:43:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> src/java.desktop/share/native/libharfbuzz/hb-common.h line 113:
> 
>> 111: 
>> 112: #define HB_TAG(c1,c2,c3,c4) ((hb_tag_t)((((uint32_t)(c1)&0xFF)<<24)|(((uint32_t)(c2)&0xFF)<<16)|(((uint32_t)(c3)&0xFF)<<8)|((uint32_t)(c4)&0xFF)))
>> 113: #define HB_UNTAG(tag)   (char)(((tag)>>24)&0xFF), (char)(((tag)>>16)&0xFF), (char)(((tag)>>8)&0xFF), (char)((tag)&0xFF)
> 
> I need a robust explanation of these changes.
> They are not mentioned, nor are they in upstream harfbuzz.
> Likely these should be pushed to upstream first if there is a reason for them.

@lewurm This and other harfbuzz changes came from MS, could you please comment here ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From burban at openjdk.java.net  Tue Jan 26 16:38:47 2021
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Tue, 26 Jan 2021 16:38:47 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <lm6_fD7AG2u5_qnZvcgUhV3sE7lOkhY4VHNthCcRUMo=.fbfa3181-7a8e-4c17-9407-70b41a750333@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com>
 <lm6_fD7AG2u5_qnZvcgUhV3sE7lOkhY4VHNthCcRUMo=.fbfa3181-7a8e-4c17-9407-70b41a750333@github.com>
Message-ID: <JM00RWcui-aHK-ytznCeMD_RrUopPTgXMVYspuK4SU0=.11098349-bc01-424f-a2d5-79265689e021@github.com>

On Tue, 26 Jan 2021 16:07:19 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> src/java.desktop/share/native/libharfbuzz/hb-common.h line 113:
>> 
>>> 111: 
>>> 112: #define HB_TAG(c1,c2,c3,c4) ((hb_tag_t)((((uint32_t)(c1)&0xFF)<<24)|(((uint32_t)(c2)&0xFF)<<16)|(((uint32_t)(c3)&0xFF)<<8)|((uint32_t)(c4)&0xFF)))
>>> 113: #define HB_UNTAG(tag)   (char)(((tag)>>24)&0xFF), (char)(((tag)>>16)&0xFF), (char)(((tag)>>8)&0xFF), (char)((tag)&0xFF)
>> 
>> I need a robust explanation of these changes.
>> They are not mentioned, nor are they in upstream harfbuzz.
>> Likely these should be pushed to upstream first if there is a reason for them.
>
> @lewurm This and other harfbuzz changes came from MS, could you please comment here ?

This looks like a merge fix mistake: https://github.com/openjdk/jdk/commit/051357ef977ecab77fa9b2b1e61f94f288e716f9#diff-e3815f37244d076e27feef0c778fb78a4e5691b47db9c92abcb28bb2a9c2865e

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From chegar at openjdk.java.net  Tue Jan 26 16:53:42 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 26 Jan 2021 16:53:42 GMT
Subject: RFR: 8257074 Update the ByteBuffers micro benchmark [v4]
In-Reply-To: <5aRQdVf_tbxSwfbsvWMcqO_kBNTZ2m5RuZ6djoqGWQk=.a7c618fe-096f-43f9-b897-ba9ad4fd3dce@github.com>
References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
 <errcLY0kIB3FnhDO18G3aH0YepgWutAIheDPTkrvPfg=.4fe346ab-5eba-4230-9765-be1095f9f844@github.com>
 <4QlCNtToXuqjt-0lnwZgVwjkEr04wWmh_AYvQLOq2BA=.38b61f48-c633-488a-a9b0-8137346013c5@github.com>
 <nkpF544xQjSTdHoDwDQjxYrFJ_CZTk0KuKJzOAS12og=.98bad397-790c-4c81-991f-31fed28ae512@github.com>
 <5aRQdVf_tbxSwfbsvWMcqO_kBNTZ2m5RuZ6djoqGWQk=.a7c618fe-096f-43f9-b897-ba9ad4fd3dce@github.com>
Message-ID: <Aq3KUVDHGqw4Nmyqnl9sKm3akJ9F6SUq_h3v0ApfNIY=.3a1eb056-db2d-4320-9798-1bb7871ea81b@github.com>

On Thu, 10 Dec 2020 14:01:56 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> While the updated set of scenarios covered by this benchmark is
>> reasonably (and vastly improves coverage), I find myself reluctant to
>> add the last remaining buffer property - read-only views. It's time to
>> template the generation of this code!
>
> If the cases get to be too many, you might also want to consider splitting the benchmark class into several classes that cover different cases (we did this for the memory access benchmarks as well). That would also make it easier to run a subset of cases in isolation.

All comments to date have been addressed. Unless there are any further comments, I would like to integrate this change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1430

From chegar at openjdk.java.net  Tue Jan 26 17:22:13 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 26 Jan 2021 17:22:13 GMT
Subject: RFR: 8257074 Update the ByteBuffers micro benchmark [v6]
In-Reply-To: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
Message-ID: <AulnwYAjRQigEj5nTE4SrjLpyax2fjL9Hth2UnPP9SI=.6a5b04b4-569c-482d-87e5-df4e21c379f2@github.com>

> The ByteBuffers micro benchmark seems to be a little dated. 
> 
> It should be a useful resource to leverage when analysing the performance impact of any potential implementation changes in the byte buffer classes. More specifically, the impact of such changes on the performance of sharp memory access operations. 
> 
> This issue proposes to update the benchmark in the following ways to meet the aforementioned use-case: 
> 
> 1. Remove allocation from the individual benchmarks - it just creates noise. 
> 2. Consolidate per-thread shared heap and direct buffers. 
> 3. All scenarios now use absolute memory access operations - so no state of the shared buffers is considered. 
> 4. Provide more reasonable default fork, warmup, etc, out-of-the-box. 
> 5. There seems to have been an existing bug in the test where the size parameter was not always considered - this is now fixed.

Chris Hegarty 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:

 - Update copyright year range and tailing whitespace
 - Merge branch 'master' into bb-bench
 - Template generation of carrier specific micro-benchmarks.
   
   * Benchmarks are now split out into carrier specific source files
   * All variants and views are covered
   * Test scenario naming is idiomatic
   
   Even with the split by carrier, regex expressions can be used to easily run subsets the benchmarks. E.g. test all memory operations related to Short with read-only buffers:
   
   $ java -jar benchmarks.jar "org.openjdk.bench.java.nio..*Buffers.testDirect.*Short.*"  -l
   Benchmarks:
   org.openjdk.bench.java.nio.ByteBuffers.testDirectLoopGetShortRO
   org.openjdk.bench.java.nio.ByteBuffers.testDirectLoopGetShortSwapRO
   org.openjdk.bench.java.nio.ShortBuffers.testDirectBulkGetShortViewRO
   org.openjdk.bench.java.nio.ShortBuffers.testDirectBulkGetShortViewSwapRO
   org.openjdk.bench.java.nio.ShortBuffers.testDirectLoopGetShortViewRO
   org.openjdk.bench.java.nio.ShortBuffers.testDirectLoopGetShortViewSwapRO
 - Merge branch 'master' into bb-bench
 - Add explicitly allocated heap carrier buffer tests
 - Replace Single with Loop
 - whitespace
 - Add additional carrier views and endianness variants.
   
   A large number of variants are now covered. The individual benchmarks conform to the following convention:
     test(Direct|Heap)(Bulk|Single)(Get|Put)(Byte|Char|Short|Int|Long|Float|Double)(View)?(Swap)?
   
   This allows to easily run a subset of particular interest. For example:
     Direct only :- "org.openjdk.bench.java.nio.ByteBuffers.testDirect.*"
     Char only   :- "org.openjdk.bench.java.nio.ByteBuffers.test.*Char.*"
     Bulk only   :- "org.openjdk.bench.java.nio.ByteBuffers.test.*Bulk.*"
     Put with Int or Long carrier :-
        test(Direct|Heap)(Single)(Put)(Int|Long)(View)?(Swap)?"
   
   Running all variants together is likely not all that useful, since there will be a lot of data.
   
   The param sizes are changed so as to better allow for wider carrier views.
   
   There are a lot of individual benchmark methods, but their implementation is trivial, and largely mechanical.
   
   Question: where do folk stand on having a `main` method in a benchmark - as a standalone-run sanity? I found this useful to assert the validity of the benchmark code. It can be commented out if it could somehow affect the benchmark runs.
   
   ( I omitted read-only views, since they less interesting, and we already have a lot of variants )
 - Initial changes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1430/files
  - new: https://git.openjdk.java.net/jdk/pull/1430/files/a8e81a84..9e8014cf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1430&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1430&range=04-05

  Stats: 123643 lines in 3239 files changed: 61246 ins; 39707 del; 22690 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1430.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1430/head:pull/1430

PR: https://git.openjdk.java.net/jdk/pull/1430

From github.com+471021+marschall at openjdk.java.net  Tue Jan 26 18:22:02 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Tue, 26 Jan 2021 18:22:02 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v4]
In-Reply-To: <TujK1flvtJ144KxV3OE5JgwAbQ6X4GRS8EWuskcE_A0=.786a8094-0066-4012-abfb-dc0f97b0f9f8@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <E8UILDsjWetV8n_CS6BsLUpAS9YNOyFup_zlV0uXaNY=.7df5871c-da6d-41e8-a0a5-c39503e50297@github.com>
 <66uDvXvRZ0UyNV93dFYWuQ-xp7GM-eVjCxsP-Aa0fMY=.46a98be7-25d9-4091-8db2-5b25beb5a9b1@github.com>
 <TujK1flvtJ144KxV3OE5JgwAbQ6X4GRS8EWuskcE_A0=.786a8094-0066-4012-abfb-dc0f97b0f9f8@github.com>
Message-ID: <T_ipXFaf3d4GIT0HxS-oSKdss9Yensfqd8qt6uQ8_So=.8e915e8e-0297-46fb-96f8-beab5439159a@github.com>

On Tue, 19 Jan 2021 07:22:49 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 207:
>> 
>>> 205:                         target.put(cbuf, 0, n);
>>> 206:                         nread += n;
>>> 207:                         remaining -= n;
>> 
>> Wouldn't there be a possibility for target.put(cbuf, 0, n) to throw BufferOverflowException ?
>> For example:
>> - there's room (remaining) for TRANSFER_BUFFER_SIZE + 1 characters in target
>> - cbuff is sized to TRANSFER_BUFFER_SIZE
>> - 1st iteration of do loop transfers TRANSFER_BUFFER_SIZE charasters (remaining == 1)
>> - 2nd iteration reads > 1 (up to TRANSFER_BUFFER_SIZE) characters
>> - target.put throws BufferOverflowException
>> 
>> You have to limit the amount read in each iteration to be Math.min(remaining, cbuf.length)
>
> You're correct. I need to expand the unit tests.

Fixed

-------------

PR: https://git.openjdk.java.net/jdk/pull/1915

From github.com+471021+marschall at openjdk.java.net  Tue Jan 26 18:22:02 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Tue, 26 Jan 2021 18:22:02 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v5]
In-Reply-To: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
Message-ID: <0iyhKVh5Aq4_7Smt9_-gBboOoEC0tGl5iv_QNzJLhYc=.c4145fe6-ebcc-4ac2-a623-692061f02229@github.com>

> Implement three optimiztations for Reader.read(CharBuffer)
> 
> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.

Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision:

  Limit amount read to avoid BufferOverflowException
  
  - limit the amount read
  - add tests

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1915/files
  - new: https://git.openjdk.java.net/jdk/pull/1915/files/d247b637..a8531c1b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=03-04

  Stats: 79 lines in 2 files changed: 62 ins; 2 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1915.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1915/head:pull/1915

PR: https://git.openjdk.java.net/jdk/pull/1915

From psandoz at openjdk.java.net  Tue Jan 26 18:22:40 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 26 Jan 2021 18:22:40 GMT
Subject: RFR: 8259925: [Vector API] Unreasonable IndexOutOfBoundsException
 message when length < vlen
In-Reply-To: <dauO6-VuQ7oX4AzzYFoMIAf3pUZrKKf4Fx8ODhIK27E=.c1ae3c03-dd95-439a-b4fd-8ffa3cfba5e3@github.com>
References: <IXlGGauVhUjxPJXm8CjZ0Eo4-ySUttJ_EqYpxiW7p8E=.32dc9082-78ad-4407-a6a2-3652dfef8a4c@github.com>
 <LzL6761_WZOicSWpwUGbYjnnWKlqQPSLtMqLKp5Q_ls=.343834be-ef22-4bc1-91c5-c8388627f6f5@github.com>
 <ZAH7vzOKC5VPi7V6ElL55VxQsgA4AAuVUOH4v8u4QfY=.4cb1b26e-6c19-4083-8495-2d046efa3ddd@github.com>
 <wc6FWksUAR7mY0S_XQox0UgcR9DwpOswrqNRpAZrnDI=.e7327508-a423-4c35-854e-02a55c0aa971@github.com>
 <7fzq6Na3zlPQIp8-ZRytFFDHLU58CaWon0tNEzww4yc=.e4e11ac0-4906-4da0-af83-c3ac8de1f957@github.com>
 <oGnSUOfY151JLoMo2ITtc6FRLOQ-210RjUl-nGnhBgo=.36a91aa9-de48-4818-aea7-a9ba99a506e5@github.com>
 <dauO6-VuQ7oX4AzzYFoMIAf3pUZrKKf4Fx8ODhIK27E=.c1ae3c03-dd95-439a-b4fd-8ffa3cfba5e3@github.com>
Message-ID: <Bv6uo3HAI0IbbdpcB5YtKMATOHcz4vwBEXzHwN0rFYM=.d951817c-8cf2-4027-88a8-7982eae893ba@github.com>

On Tue, 26 Jan 2021 13:24:57 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> The intrinsic enables C2 to more reliably elide bounds checks. I don't know the exact details but at a high-level it transforms signed values into unsigned values (and therefore the signed comparisons become unsigned comparisons), which helps C2 remove checks when there is a dominating check of, for example, an upper loop bound.
>> 
>> You say "the intrinsified Objects.checkIndex seems to generate more code than inlined if-statements". Can you present some examples of Java code and the corresponding C2 generated assembler where this happens?
>
>> The intrinsic enables C2 to more reliably elide bounds checks. I don't know the exact details but at a high-level it transforms signed values into unsigned values (and therefore the signed comparisons become unsigned comparisons), which helps C2 remove checks when there is a dominating check of, for example, an upper loop bound.
>> 
>> You say "the intrinsified Objects.checkIndex seems to generate more code than inlined if-statements". Can you present some examples of Java code and the corresponding C2 generated assembler where this happens?
> 
> Hi @PaulSandoz ,
> 
> I agree with you that let's keep the code as it is for the sake of performance.
> 
> I spent some time looking into the assembly code generated by Objects.checkIndex and inlined if-statements.
> Here are the test program [1], running script [2] and diff [3].
> 
>  - For testSimple [4] that I checked last week, inlined if-statements [5] is better than Objects.checkIndex [6].
>  - However, for testLoop [7], Objects.checkIndex [8] is better than inlined if-statements [9].
>    (I'm sorry I didn't check loop methods last week.)
>    AFAICS, the inlined if-statements will generate two more instructions [10] to check wether idx >= 0 for each loop iteration.
> 
> It seems that the intrinsified Objects.checkIndex will be able to optimize out the lower bound check for loops.
> So I also agree with you that an intrinsified method seems the right choice.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/Bar.java
> [2] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/1.sh
> [3] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/1.diff
> [4] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/Bar.java#L10
> [5] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/3-testSimple.log
> [6] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/2-testSimple.log
> [7] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/Bar.java#L15
> [8] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/2-testLoop.log
> [9] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/3-testLoop.log
> [10] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/3-testLoop.log#L135

Hi Jie,

Thanks for the detailed analysis.

I suspect the difference outside of loops is because of expression "length - (vlen - 1)?.

We need to make intrinsic Objects.checkFromIndexSize. Is that something you might be interested in pursuing?

Paul.

On Jan 26, 2021, at 5:25 AM, Jie Fu <notifications at github.com<mailto:notifications at github.com>> wrote:



The intrinsic enables C2 to more reliably elide bounds checks. I don't know the exact details but at a high-level it transforms signed values into unsigned values (and therefore the signed comparisons become unsigned comparisons), which helps C2 remove checks when there is a dominating check of, for example, an upper loop bound.

You say "the intrinsified Objects.checkIndex seems to generate more code than inlined if-statements". Can you present some examples of Java code and the corresponding C2 generated assembler where this happens?

Hi @PaulSandoz<https://urldefense.com/v3/__https://github.com/PaulSandoz__;!!GqivPVa7Brio!MjVcmwqonN75cKLtklQpW6WVz_c3e2SZku7ErC-dlU0rSZ46SKCWqQ_Fqki3MpUu-w$> ,

I agree with you that let's keep the code as it is for the sake of performance.

I spent some time looking into the assembly code generated by Objects.checkIndex and inlined if-statements.
Here are the test program [1], running script [2] and diff [3].

  *   For testSimple [4] that I checked last week, inlined if-statements [5] is better than Objects.checkIndex [6].
  *   However, for testLoop [7], Objects.checkIndex [8] is better than inlined if-statements [9].
(I'm sorry I didn't check loop methods last week.)
AFAICS, the inlined if-statements will generate two more instructions [10] to check wether idx >= 0 for each loop iteration.

It seems that the intrinsified Objects.checkIndex will be able to optimize out the lower bound check for loops.
So I also agree with you that an intrinsified method seems the right choice.

Thanks.
Best regards,
Jie

[1] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/Bar.java<https://urldefense.com/v3/__https://github.com/DamonFool/experiment/blob/main/JDK-8259925/Bar.java__;!!GqivPVa7Brio!MjVcmwqonN75cKLtklQpW6WVz_c3e2SZku7ErC-dlU0rSZ46SKCWqQ_Fqkgg0xOSvw$>
[2] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/1.sh<https://urldefense.com/v3/__https://github.com/DamonFool/experiment/blob/main/JDK-8259925/1.sh__;!!GqivPVa7Brio!MjVcmwqonN75cKLtklQpW6WVz_c3e2SZku7ErC-dlU0rSZ46SKCWqQ_FqkhuQpNMig$>
[3] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/1.diff<https://urldefense.com/v3/__https://github.com/DamonFool/experiment/blob/main/JDK-8259925/1.diff__;!!GqivPVa7Brio!MjVcmwqonN75cKLtklQpW6WVz_c3e2SZku7ErC-dlU0rSZ46SKCWqQ_FqkhABlSb0g$>
[4] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/Bar.java#L10<https://urldefense.com/v3/__https://github.com/DamonFool/experiment/blob/main/JDK-8259925/Bar.java*L10__;Iw!!GqivPVa7Brio!MjVcmwqonN75cKLtklQpW6WVz_c3e2SZku7ErC-dlU0rSZ46SKCWqQ_FqkjdFLWTPg$>
[5] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/3-testSimple.log<https://urldefense.com/v3/__https://github.com/DamonFool/experiment/blob/main/JDK-8259925/3-testSimple.log__;!!GqivPVa7Brio!MjVcmwqonN75cKLtklQpW6WVz_c3e2SZku7ErC-dlU0rSZ46SKCWqQ_FqkglteeJyA$>
[6] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/2-testSimple.log<https://urldefense.com/v3/__https://github.com/DamonFool/experiment/blob/main/JDK-8259925/2-testSimple.log__;!!GqivPVa7Brio!MjVcmwqonN75cKLtklQpW6WVz_c3e2SZku7ErC-dlU0rSZ46SKCWqQ_Fqkj7_CEbEw$>
[7] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/Bar.java#L15<https://urldefense.com/v3/__https://github.com/DamonFool/experiment/blob/main/JDK-8259925/Bar.java*L15__;Iw!!GqivPVa7Brio!MjVcmwqonN75cKLtklQpW6WVz_c3e2SZku7ErC-dlU0rSZ46SKCWqQ_Fqkhxo3sJjg$>
[8] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/2-testLoop.log<https://urldefense.com/v3/__https://github.com/DamonFool/experiment/blob/main/JDK-8259925/2-testLoop.log__;!!GqivPVa7Brio!MjVcmwqonN75cKLtklQpW6WVz_c3e2SZku7ErC-dlU0rSZ46SKCWqQ_FqkhIy4Qh-A$>
[9] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/3-testLoop.log<https://urldefense.com/v3/__https://github.com/DamonFool/experiment/blob/main/JDK-8259925/3-testLoop.log__;!!GqivPVa7Brio!MjVcmwqonN75cKLtklQpW6WVz_c3e2SZku7ErC-dlU0rSZ46SKCWqQ_Fqkh7uhCIiQ$>
[10] https://github.com/DamonFool/experiment/blob/main/JDK-8259925/3-testLoop.log#L135<https://urldefense.com/v3/__https://github.com/DamonFool/experiment/blob/main/JDK-8259925/3-testLoop.log*L135__;Iw!!GqivPVa7Brio!MjVcmwqonN75cKLtklQpW6WVz_c3e2SZku7ErC-dlU0rSZ46SKCWqQ_FqkiamkUoew$>

?
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/2127*issuecomment-767538738__;Iw!!GqivPVa7Brio!MjVcmwqonN75cKLtklQpW6WVz_c3e2SZku7ErC-dlU0rSZ46SKCWqQ_Fqkh5OZMwFg$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AABHQQHPG3FX4YWS6L3L7NTS327DTANCNFSM4WHJ6CHQ__;!!GqivPVa7Brio!MjVcmwqonN75cKLtklQpW6WVz_c3e2SZku7ErC-dlU0rSZ46SKCWqQ_FqkjBYJBa4A$>.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2127

From akozlov at openjdk.java.net  Tue Jan 26 18:42:02 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 26 Jan 2021 18:42:02 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v5]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <gPhGkmWJHK8x-AKI-M3tQAHU9UvkU6FWbzmVuc-j__k=.12e5dcc4-aa00-4099-934f-a23128cdf41c@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Revert harfbuzz changes, disable warnings for it

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/fef36580..b2b396fc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=03-04

  Stats: 5 lines in 3 files changed: 1 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

From erik.joelsson at oracle.com  Tue Jan 26 18:42:49 2021
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 26 Jan 2021 10:42:49 -0800
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <0ce3d16d-76e1-dd38-1b13-d693bc490915@oracle.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
 <RVUqncN8BLrGU1Rxdrg1zk_yE-sSQsZ08fge6Jp9ijI=.c355f1e9-1b9f-4e11-9243-c44b557b447d@github.com>
 <AE1YSbX-p_TaPh63xDXrPiDSfWhU6Ve4fDxg5KPrFSc=.7a3c8269-7238-4928-af00-00c3e13e76c6@github.com>
 <0ce3d16d-76e1-dd38-1b13-d693bc490915@oracle.com>
Message-ID: <58df0666-2c69-a4dd-3bb8-fd00c859b490@oracle.com>


On 2021-01-26 04:44, Magnus Ihse Bursie wrote:
> On 2021-01-26 13:09, Vladimir Kempik wrote:
>> On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward 
>> <github.com+4146708+a74nh at openjdk.org> wrote:
>>
>>> AIUI, the configure line needs passing a prebuilt 
>>> JavaNativeFoundation framework
>>> ie:
>>> `--with-extra-ldflags='-F 
>>> /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`
>>>
>>> Otherwise there will be missing _JNFNative* functions.
>>>
>>> Is this the long term plan? Or will eventually the required code be 
>>> moved into JDK and/or the xcode one automatically get picked up by 
>>> the configure scripts?
>> There is ongoing work by P. Race to eliminate dependence on JNF at all
> How far has that work come? Otherwise the logic should be added to 
> configure to look for this framework automatically, and provide a way 
> to override it/set it if not found.
>
> I don't think it's OK to publish a new port that cannot build 
> out-of-the-box without hacks like this.
>
My understanding is that Apple chose to not provide JNF for aarch64, so 
if you want to build OpenJDK, you first need to build JNF yourself (it's 
available in github). Phil is working on removing this dependency 
completely, which will solve this issue [1].

In the meantime, I don't think we should rely on finding JNF in 
unsupported locations inside Xcode. Could we wait with integrating this 
port until it can be built without such hacks? If not, then adding 
something in the documentation on how to get a working JNF would at 
least be needed.

/Erik

[1] https://bugs.openjdk.java.net/browse/JDK-8257852

From akozlov at openjdk.java.net  Tue Jan 26 18:54:46 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 26 Jan 2021 18:54:46 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <JM00RWcui-aHK-ytznCeMD_RrUopPTgXMVYspuK4SU0=.11098349-bc01-424f-a2d5-79265689e021@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com>
 <lm6_fD7AG2u5_qnZvcgUhV3sE7lOkhY4VHNthCcRUMo=.fbfa3181-7a8e-4c17-9407-70b41a750333@github.com>
 <JM00RWcui-aHK-ytznCeMD_RrUopPTgXMVYspuK4SU0=.11098349-bc01-424f-a2d5-79265689e021@github.com>
Message-ID: <w7gwBf0UyQDfwKv7o8VxdnTOMrb6O03paC15dcq3mj0=.360a880d-e452-4f5d-8b63-687fee1ecc0a@github.com>

On Tue, 26 Jan 2021 16:35:54 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> @lewurm This and other harfbuzz changes came from MS, could you please comment here ?
>
> This looks like a merge fix mistake: https://github.com/openjdk/jdk/commit/051357ef977ecab77fa9b2b1e61f94f288e716f9#diff-e3815f37244d076e27feef0c778fb78a4e5691b47db9c92abcb28bb2a9c2865e

I've reverted this change and disabled some warnings for libharfbuzz instead. I should be blamed, yes. Now this is consistent with other changes covered by JDK-8260402

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From weijun at openjdk.java.net  Tue Jan 26 19:36:50 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 26 Jan 2021 19:36:50 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v5]
In-Reply-To: <gPhGkmWJHK8x-AKI-M3tQAHU9UvkU6FWbzmVuc-j__k=.12e5dcc4-aa00-4099-934f-a23128cdf41c@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <gPhGkmWJHK8x-AKI-M3tQAHU9UvkU6FWbzmVuc-j__k=.12e5dcc4-aa00-4099-934f-a23128cdf41c@github.com>
Message-ID: <U4n2FxioAOMTtN3q40S5qmtBypJRATRHFWbynqyFI7U=.37557c2f-1c10-4f12-88cd-7058f0bb97d2@github.com>

On Tue, 26 Jan 2021 18:42:02 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert harfbuzz changes, disable warnings for it

src/java.security.jgss/share/native/libj2gss/gssapi.h line 48:

> 46: // Condition was copied from
> 47: // Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h
> 48: #if TARGET_OS_MAC && (defined(__ppc__) || defined(__ppc64__) || defined(__i386__) || defined(__x86_64__))

So for macOS/AArch64, this `if` is no longer true?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From burban at openjdk.java.net  Tue Jan 26 19:41:50 2021
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Tue, 26 Jan 2021 19:41:50 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com>
Message-ID: <yfXs-k0GMczJKtfJ96FRVLLl9U5K2qJpCRni571FCoU=.328206a8-8ed3-4cb8-940a-a9f3e718cf20@github.com>

On Mon, 25 Jan 2021 17:43:35 GMT, Phil Race <prr at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> src/java.desktop/share/native/libharfbuzz/hb-coretext.cc line 193:
> 
>> 191:    * crbug.com/549610 */
>> 192:   // 0x00070000 stands for "kCTVersionNumber10_10", see CoreText.h
>> 193: #if TARGET_OS_OSX && MAC_OS_X_VERSION_MIN_REQUIRED < __MAC_10_10
> 
> I need a robust explanation of these changes.
> They are not mentioned, nor are they in upstream harfbuzz.
> Likely these should be pushed to upstream first if there is a reason for them.

I'm afraid it's one of those dirty changes that we did to make progress, but forgot to revisit later. Without the guard you would get:
* For target support_native_java.desktop_libharfbuzz_hb-coretext.o:

  if (&CTGetCoreTextVersion != nullptr && CTGetCoreTextVersion() < 0x00070000) {
       ^

uint32_t CTGetCoreTextVersion( void ) CT_DEPRECATED("Use -[NSProcessInfo operatingSystemVersion]", macos(10.5, 11.0), ios(3.2, 14.0), watchos(2.0, 7.0), tvos(9.0, 14.0));
         ^

  if (&CTGetCoreTextVersion != nullptr && CTGetCoreTextVersion() < 0x00070000) {
                                          ^

uint32_t CTGetCoreTextVersion( void ) CT_DEPRECATED("Use -[NSProcessInfo operatingSystemVersion]", macos(10.5, 11.0), ios(3.2, 14.0), watchos(2.0, 7.0), tvos(9.0, 14.0));
         ^
2 errors generated.
For now, it's probably better to go with what Anton did in the latest commit https://github.com/openjdk/jdk/pull/2200/commits/b2b396fca679fbc7ee78fb5bc80191bc79e1c490
Eventually upstream will do something about it I assume? How often does it get synced with upstream? Maybe worth to file an issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From vkempik at openjdk.java.net  Tue Jan 26 20:02:50 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 26 Jan 2021 20:02:50 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v5]
In-Reply-To: <U4n2FxioAOMTtN3q40S5qmtBypJRATRHFWbynqyFI7U=.37557c2f-1c10-4f12-88cd-7058f0bb97d2@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <gPhGkmWJHK8x-AKI-M3tQAHU9UvkU6FWbzmVuc-j__k=.12e5dcc4-aa00-4099-934f-a23128cdf41c@github.com>
 <U4n2FxioAOMTtN3q40S5qmtBypJRATRHFWbynqyFI7U=.37557c2f-1c10-4f12-88cd-7058f0bb97d2@github.com>
Message-ID: <gQHutmDlViAyVjtcm2IaOKZ6kbKMoYQhGhPXbwSpEPo=.59f467de-01ed-4f25-9438-40cab26d50b2@github.com>

On Tue, 26 Jan 2021 19:33:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert harfbuzz changes, disable warnings for it
>
> src/java.security.jgss/share/native/libj2gss/gssapi.h line 48:
> 
>> 46: // Condition was copied from
>> 47: // Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h
>> 48: #if TARGET_OS_MAC && (defined(__ppc__) || defined(__ppc64__) || defined(__i386__) || defined(__x86_64__))
> 
> So for macOS/AArch64, this `if` is no longer true?

That is according to Xcode sdk.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From martin at openjdk.java.net  Tue Jan 26 21:27:59 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Tue, 26 Jan 2021 21:27:59 GMT
Subject: RFR: 8260461: Modernize jsr166 tck tests
Message-ID: <OBrb6EJRDv2ILtRc4akmS1K5t6lC1Q3o5XmvqCNmKHM=.e15f8410-75ab-4f5e-b1ea-4551cf41f9a1@github.com>

8260461: Modernize jsr166 tck tests

-------------

Commit messages:
 - JDK-8260461

Changes: https://git.openjdk.java.net/jdk/pull/2245/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2245&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260461
  Stats: 7535 lines in 70 files changed: 314 ins; 183 del; 7038 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2245.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2245/head:pull/2245

PR: https://git.openjdk.java.net/jdk/pull/2245

From akozlov at openjdk.java.net  Tue Jan 26 21:59:03 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 26 Jan 2021 21:59:03 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <PMUYint7pX2wmQ5wONMdgL7GclrxCnolwttyJC7BzTg=.ca680fa2-5b08-491f-9c1c-8253ffa2bbb4@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Redo buildsys fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/b2b396fc..f1ef6240

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=04-05

  Stats: 18 lines in 2 files changed: 8 ins; 10 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

From vkempik at openjdk.java.net  Tue Jan 26 22:07:48 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 26 Jan 2021 22:07:48 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
Message-ID: <ovN1AB7FTV92iIOLhFzcn8zJb0m02eoVDY5JVgQ6IW8=.faed2b97-2fbe-42f0-8aa9-b6b7eabc1326@github.com>

On Tue, 26 Jan 2021 09:23:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor CDS disabling
>>  - Redo builsys support for aarch64-darwin
>
> make/autoconf/build-aux/autoconf-config.guess line 1275:
> 
>> 1273: 		      UNAME_PROCESSOR="aarch64"
>> 1274: 		  fi
>> 1275: 		fi ;;
> 
> Almost, but not quite, correct. We cannot change the autoconf-config.guess file due to license restrictions (the license allows redistribution, not modifications). Instead we have the config.guess file which "wraps" autoconf-config.guess and makes pre-/post-call modifications to work around limitations in the autoconf original file. So you need to check there if you are getting incorrect results back and adjust it in that case. See the already existing clauses in that file.

Hello
I have updated PR and moved this logic to make/autoconf/build-aux/config.guess
It's pretty similar to i386 -> x86_64 fix-up on macos_intel

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From mchung at openjdk.java.net  Tue Jan 26 22:46:46 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 26 Jan 2021 22:46:46 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
 [v3]
In-Reply-To: <fUm4Dayv7nRXfJMPfSN2K1Q9-MAebjdGT5zMNsN_Tno=.f5968959-48ad-4b72-a811-1db0ff08b10c@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
 <fUm4Dayv7nRXfJMPfSN2K1Q9-MAebjdGT5zMNsN_Tno=.f5968959-48ad-4b72-a811-1db0ff08b10c@github.com>
Message-ID: <MTh0whTJeyYgPJ2KVCEyeS47kXE3-94Yk9KBvpJEML0=.8793e573-a82e-4b1b-b548-0c3f9c4eec3f@github.com>

On Mon, 25 Jan 2021 20:51:06 GMT, Mahendra Chhipa <github.com+34924738+mahendrachhipa at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8183372
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented the review comments.

test/jdk/java/lang/Class/forName/NonJavaNames.java line 37:

> 35:  * @bug 4952558
> 36:  * @library /test/lib
> 37:  * @build NonJavaNames

This `@build` can be dropped as this is done implicitly.

test/jdk/java/lang/Class/forName/NonJavaNames.java line 63:

> 61:     private static final String TEST_SRC = SRC_DIR + "/classes/";
> 62:     private static final String TEST_CLASSES = System.getProperty("test.classes", ".");
> 63:     Path dhyphenPath, dcommaPath, dperiodPath, dleftsquarePath, drightsquarePath, dplusPath, dsemicolonPath, dzeroPath, dthreePath, dzadePath;

These variables should belong to the `createInvalidNameClasses` method.  You can simply add `Path` type declaration in line 78-87.

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 90:

> 88:         Path enclosingPath = Paths.get(ENCLOSING_CLASS_SRC);
> 89:         Path pkg1Dir = Paths.get(SRC_DIR + "/pkg1");
> 90:         Path pkg2Dir = Paths.get(SRC_DIR+"/pkg1/pkg2");

nit: space before and after `+` is missing

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 89:

> 87:     public void createEnclosingClasses() throws Throwable {
> 88:         Path enclosingPath = Paths.get(ENCLOSING_CLASS_SRC);
> 89:         Path pkg1Dir = Paths.get(SRC_DIR + "/pkg1");

Alternatively:

    Path pkg1Dir = Paths.get(SRC_DIR, pkg1);
    Path pkg2Dir = Paths.get(SRC_DIR, pkg1, pkg2);
    Path pkg1File = pkg1Dir.resolve("EnclosingClass.java");
    Path pkg2File = pkg2Dir.resolve("EnclosingClass.java");

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 84:

> 82: public class EnclosingClassTest {
> 83:     private static final String SRC_DIR = System.getProperty("test.src");
> 84:     private static final String ENCLOSING_CLASS_SRC = SRC_DIR + "/EnclosingClass.java";

Suggestion:

    private static final Path ENCLOSING_CLASS_SRC = Paths.get(SRC_DIR, "EnclosingClass.java");

Use Path::toString to convert to a String where needed.

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 103:

> 101:         String javacPath = JDKToolFinder.getJDKTool("javac");
> 102:         OutputAnalyzer outputAnalyzer = ProcessTools.executeCommand(javacPath, "-d", System.getProperty("test.classes", "."),
> 103:                 SRC_DIR + "/EnclosingClass.java", SRC_DIR + "/pkg1/EnclosingClass.java", SRC_DIR + "/pkg1/pkg2/EnclosingClass.java");

`File.separator` is different on Unix and Windows.   Either replace `/` with `File.separator`.   Or you can use `java.nio.file.Path` and call `Path::toString` to get the string representation.

See above suggestion of declaring `static final Path ENCLOSING_CLASS_SRC`.  So the above should use `ENCLOSING_CLASS_SRC` and `pkg2File` instead (calling toString)

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 108:

> 106: 
> 107:     @Test
> 108:     public void testEnclosingClasses() throws Throwable {

better to throw specific exceptions for example `ReflectiveOperationException`.  Same for the `@Test` below.

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 124:

> 122:     @AfterClass
> 123:     public void deleteEnclosingClasses() throws IOException {
> 124:         Path pkg1Dir = Paths.get(SRC_DIR + "/pkg1");

Suggestion:

        Path pkg1Dir = Paths.get(SRC_DIR, "pkg1");

-------------

PR: https://git.openjdk.java.net/jdk/pull/2170

From mchung at openjdk.java.net  Tue Jan 26 22:46:47 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 26 Jan 2021 22:46:47 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
 [v2]
In-Reply-To: <h50knYdW8dElRBhMDtc8w9WibLcoHY5FKsroXr1NA0g=.a99bb2ad-8f46-415e-b8a8-5ef08baa030a@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
 <yJcUp9Y_StqxljldFR_wXRA5QsKro5pp3sxqgQWW-js=.6fe3b134-81ee-4925-b951-b60f9e885215@github.com>
 <xBkb4pJvfGw3zc5UEpO2rJLrLo7u-5aUYFjFtjdazqA=.98c049c2-e8f7-456e-b6d8-12cd573a7b4c@github.com>
 <h50knYdW8dElRBhMDtc8w9WibLcoHY5FKsroXr1NA0g=.a99bb2ad-8f46-415e-b8a8-5ef08baa030a@github.com>
Message-ID: <KAD5mx0d_pp8Eb5xyhClHiS_GcMfV7mmQ-wEEMVSkgM=.0ae8cf5c-b295-441e-8f76-d9dba0f1fe6d@github.com>

On Mon, 25 Jan 2021 19:33:08 GMT, Mahendra Chhipa <github.com+34924738+mahendrachhipa at openjdk.org> wrote:

>> test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 103:
>> 
>>> 101:         createAndWriteEnclosingClasses(enclosingPath, pkg2File, "pkg1.pkg2");
>>> 102: 
>>> 103:         String javacPath = JDKToolFinder.getJDKTool("javac");
>> 
>> You can use `jdk.test.lib.compiler.CompilerUtils` test library to compile the file in process.
>
> I tried to use the CopmilerUtils to compile the file, But this utility is not able to  the dependencies of the class. Example it is not able to find the common.TestMe class while try to compile the EnclosingClass.java.

You need to add `--source-path` where it can find the dependent source files.

>> test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 176:
>> 
>>> 174:     }
>>> 175: 
>>> 176:     private void check(final Class<?> c, final Class<?> enc,
>> 
>> I see that you make all parameters in all methods final.   It just adds noise.   Can you leave it out?
>
> To avoid the Checkstyle warnings, I added them.

Is it from your IDE configurations?  You can turn off Checkstyle warnings.  This just adds noise.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2170

From mchung at openjdk.java.net  Tue Jan 26 22:46:48 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 26 Jan 2021 22:46:48 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
 [v2]
In-Reply-To: <KAD5mx0d_pp8Eb5xyhClHiS_GcMfV7mmQ-wEEMVSkgM=.0ae8cf5c-b295-441e-8f76-d9dba0f1fe6d@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
 <yJcUp9Y_StqxljldFR_wXRA5QsKro5pp3sxqgQWW-js=.6fe3b134-81ee-4925-b951-b60f9e885215@github.com>
 <xBkb4pJvfGw3zc5UEpO2rJLrLo7u-5aUYFjFtjdazqA=.98c049c2-e8f7-456e-b6d8-12cd573a7b4c@github.com>
 <h50knYdW8dElRBhMDtc8w9WibLcoHY5FKsroXr1NA0g=.a99bb2ad-8f46-415e-b8a8-5ef08baa030a@github.com>
 <KAD5mx0d_pp8Eb5xyhClHiS_GcMfV7mmQ-wEEMVSkgM=.0ae8cf5c-b295-441e-8f76-d9dba0f1fe6d@github.com>
Message-ID: <bqhXQogKHUEhbx1dxJc3cVvLJCBIfkR1Xpkd2hU6vuY=.6db93bf0-1f13-4a35-984e-1ead07aa7edd@github.com>

On Tue, 26 Jan 2021 22:30:03 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> To avoid the Checkstyle warnings, I added them.
>
> Is it from your IDE configurations?  You can turn off Checkstyle warnings.  This just adds noise.

I also assume some of the formatting changes are changed by your IDE suggestion.  Can you please revert the formatting changes (there are quite a few of them).   This will help the reviewers.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2170

From bchristi at openjdk.java.net  Tue Jan 26 23:02:47 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 26 Jan 2021 23:02:47 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
 [v3]
In-Reply-To: <fUm4Dayv7nRXfJMPfSN2K1Q9-MAebjdGT5zMNsN_Tno=.f5968959-48ad-4b72-a811-1db0ff08b10c@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
 <fUm4Dayv7nRXfJMPfSN2K1Q9-MAebjdGT5zMNsN_Tno=.f5968959-48ad-4b72-a811-1db0ff08b10c@github.com>
Message-ID: <dotXorU_ykwCOblQVPC3eNuYiBK9Oe7EBcKrV84meKQ=.09a4c388-50d3-43bb-b8c6-1628ab6f86e2@github.com>

On Mon, 25 Jan 2021 20:51:06 GMT, Mahendra Chhipa <github.com+34924738+mahendrachhipa at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8183372
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented the review comments.

I like keeping the changes within the existing .java files, thanks.  I have a few more suggestions.

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 76:

> 74: * @modules jdk.compiler
> 75: * @build jdk.test.lib.process.* EnclosingClassTest
> 76: * @run testng/othervm EnclosingClassTest

The test should still be run with -esa -ea

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 88:

> 86:     @BeforeClass
> 87:     public void createEnclosingClasses() throws Throwable {
> 88:         Path enclosingPath = Paths.get(ENCLOSING_CLASS_SRC);

The 'enclosingPath' Path could be the constant.  Then ENCLOSING_CLASS_SRC is not needed.

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 126:

> 124:         Path pkg1Dir = Paths.get(SRC_DIR + "/pkg1");
> 125:         FileUtils.deleteFileTreeWithRetry(pkg1Dir);
> 126:     }

I'm not convinced the `@AfterClass` method is necessary.  Pre-cleanup is already done on LL94-95.  And occasionally, test-generated artifacts are helpful in post-mortem analysis.

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 158:

> 156:     private void match(final String actual, final String expected) {
> 157:         System.out.println("actual:" + actual + "expected:" + expected);
> 158:         assert ((actual == null && expected == null) || actual.trim().equals(expected.trim()));

Out of curiousity, why is the trim() now needed ?

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 180:

> 178:         info(c, encClass, annotation.desc());
> 179:         check(c, encClass, "" + encClass, annotation.encl(), c.getSimpleName(), annotation.simple(),
> 180:                 c.getCanonicalName(), annotation.hasCanonical() ? annotation.canonical() : null);

This looks like an unneeded formatting change

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 187:

> 185:         check(array, array.getEnclosingClass(), "", "", array.getSimpleName(),
> 186:                 annotation.simple() + "[]", array.getCanonicalName(), annotation.hasCanonical()
> 187:                         ? annotation.canonical() + "[]" : null);

This looks like an unneeded formatting change

test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 197:

> 195:                     testClass((Class<?>) f.get(tests), annotation, f);
> 196:                 } catch (AssertionError ex) {
> 197:                     System.err.println("Error in " + tests.getClass().getName() + "." + f.getName());

This looks like an unneeded formatting change

-------------

Changes requested by bchristi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2170

From github.com+592810+efge at openjdk.java.net  Tue Jan 26 23:27:43 2021
From: github.com+592810+efge at openjdk.java.net (Florent Guillaume)
Date: Tue, 26 Jan 2021 23:27:43 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
 [v3]
In-Reply-To: <fUm4Dayv7nRXfJMPfSN2K1Q9-MAebjdGT5zMNsN_Tno=.f5968959-48ad-4b72-a811-1db0ff08b10c@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
 <fUm4Dayv7nRXfJMPfSN2K1Q9-MAebjdGT5zMNsN_Tno=.f5968959-48ad-4b72-a811-1db0ff08b10c@github.com>
Message-ID: <VB2ZA9FDB03NtlCeMvboqHK6lKGeQjVBUcPPOquF1s4=.82aff354-b7e1-4966-84b5-38306aa24e02@github.com>

On Mon, 25 Jan 2021 20:51:06 GMT, Mahendra Chhipa <github.com+34924738+mahendrachhipa at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8183372
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented the review comments.

test/jdk/java/lang/Class/forName/NonJavaNames.java line 67:

> 65:     @BeforeClass
> 66:     public void createInvalidNameClasses() throws IOException {
> 67:         Path hyphenPath = Paths.get(TEST_SRC + "hyphen.class");

Building a `Path` with string concatenation is an anti-pattern.
Also `Path.of` is probably preferred instead of `Paths.get`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2170

From jiefu at openjdk.java.net  Tue Jan 26 23:48:40 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 26 Jan 2021 23:48:40 GMT
Subject: RFR: 8259925: [Vector API] Unreasonable IndexOutOfBoundsException
 message when length < vlen
In-Reply-To: <Bv6uo3HAI0IbbdpcB5YtKMATOHcz4vwBEXzHwN0rFYM=.d951817c-8cf2-4027-88a8-7982eae893ba@github.com>
References: <IXlGGauVhUjxPJXm8CjZ0Eo4-ySUttJ_EqYpxiW7p8E=.32dc9082-78ad-4407-a6a2-3652dfef8a4c@github.com>
 <LzL6761_WZOicSWpwUGbYjnnWKlqQPSLtMqLKp5Q_ls=.343834be-ef22-4bc1-91c5-c8388627f6f5@github.com>
 <ZAH7vzOKC5VPi7V6ElL55VxQsgA4AAuVUOH4v8u4QfY=.4cb1b26e-6c19-4083-8495-2d046efa3ddd@github.com>
 <wc6FWksUAR7mY0S_XQox0UgcR9DwpOswrqNRpAZrnDI=.e7327508-a423-4c35-854e-02a55c0aa971@github.com>
 <7fzq6Na3zlPQIp8-ZRytFFDHLU58CaWon0tNEzww4yc=.e4e11ac0-4906-4da0-af83-c3ac8de1f957@github.com>
 <oGnSUOfY151JLoMo2ITtc6FRLOQ-210RjUl-nGnhBgo=.36a91aa9-de48-4818-aea7-a9ba99a506e5@github.com>
 <dauO6-VuQ7oX4AzzYFoMIAf3pUZrKKf4Fx8ODhIK27E=.c1ae3c03-dd95-439a-b4fd-8ffa3cfba5e3@github.com>
 <Bv6uo3HAI0IbbdpcB5YtKMATOHcz4vwBEXzHwN0rFYM=.d951817c-8cf2-4027-88a8-7982eae893ba@github.com>
Message-ID: <M-2NFr8S-pzjxENitaj0-m45-fGi0Fo62JRaGiZwEVs=.af8621ee-023b-4f3e-ba2e-aaabb97bc8c5@github.com>

On Tue, 26 Jan 2021 18:20:00 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Hi Jie, Thanks for the detailed analysis. I suspect the difference outside of loops is because of expression "length - (vlen - 1)?. We need to make intrinsic Objects.checkFromIndexSize. Is that something you might be interested in pursuing? 

Yes, I'd like to do that in the future.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2127

From dl at openjdk.java.net  Wed Jan 27 00:47:39 2021
From: dl at openjdk.java.net (Doug Lea)
Date: Wed, 27 Jan 2021 00:47:39 GMT
Subject: RFR: 8260461: Modernize jsr166 tck tests
In-Reply-To: <OBrb6EJRDv2ILtRc4akmS1K5t6lC1Q3o5XmvqCNmKHM=.e15f8410-75ab-4f5e-b1ea-4551cf41f9a1@github.com>
References: <OBrb6EJRDv2ILtRc4akmS1K5t6lC1Q3o5XmvqCNmKHM=.e15f8410-75ab-4f5e-b1ea-4551cf41f9a1@github.com>
Message-ID: <-pOwn99YxdLHGuRnCvGfrCMzc1c6CQ8wYKma6Z09Cog=.ac9de67a-3f23-41ff-b8b3-866a0042854f@github.com>

On Tue, 26 Jan 2021 21:23:25 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> 8260461: Modernize jsr166 tck tests

Marked as reviewed by dl (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2245

From mik3hall at gmail.com  Wed Jan 27 01:16:36 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 26 Jan 2021 19:16:36 -0600
Subject: bug jpackage in JDK 15
In-Reply-To: <C7A06A93-AF65-4379-8D82-445893891E04@gmail.com>
References: <CAH2-wONu7wpxBmgKL8qx3cB+NWfnNLw-XTqCMLqnUZ2JjuDtkA@mail.gmail.com>
 <0DF4D073-FAD7-4708-AECE-51BD0720957F@gmail.com>
 <C7A06A93-AF65-4379-8D82-445893891E04@gmail.com>
Message-ID: <6450AD66-0DCF-41DA-8028-7621BD9FC42C@gmail.com>


> 
> When I open the built dmg there is an application icon, a drag to indicating arrow, but no application folder icon as the drag target.
> 
> Possibly related?
> 
> Running [osascript, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack Blastoff-dmg-setup.scpt]
> /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack Blastoff-dmg-setup.scpt:1112:1334: execution error: Finder got an error: Can?t make class alias file. (-2710)
> java.io.IOException: Command [osascript, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack Blastoff-dmg-setup.scpt] exited with 1 code
> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Executor.executeExpectSuccess(Executor.java:75)
> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:167)
> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:135)
> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.buildDMG(MacDmgBundler.java:393)
> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.bundle(MacDmgBundler.java:91)
> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.execute(MacDmgBundler.java:535)
> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:680)
> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:549)
> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:98)
> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:52)
> 
> Also it seems...
> --add-modules java.desktop,java.prefs,java.se \
> 
> Is no longer an option?
> ?help doesn?t show it and I end up with?
> java-options=--module-path
> 
> In the .cfg

Fwiw I was curious if this was a known issue.
https://bugs.openjdk.java.net/browse/JDK-8250615 <https://bugs.openjdk.java.net/browse/JDK-8250615>

It seems like this might still be an open issue?
I am guessing new Folder security on OS X Catalina. If so I would be interested in hearing of any resolution. I have had another problem with a java app on the Documents folder.



From smarks at openjdk.java.net  Wed Jan 27 03:22:47 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 27 Jan 2021 03:22:47 GMT
Subject: RFR: 8259816: Typo in java.util.stream package description
Message-ID: <4Sy-nuhF9tNPiPpSySyDYt2-3hnMHORvrUdWaaODEmk=.28386f79-a94f-402d-8e65-4a886f1200c7@github.com>

Fix a typo, and change an example to use Stream.toList().

-------------

Commit messages:
 - 8259816: Typo in java.util.stream package description

Changes: https://git.openjdk.java.net/jdk/pull/2249/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2249&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259816
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2249.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2249/head:pull/2249

PR: https://git.openjdk.java.net/jdk/pull/2249

From martin at openjdk.java.net  Wed Jan 27 03:36:54 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Wed, 27 Jan 2021 03:36:54 GMT
Subject: RFR: 8260461: Modernize jsr166 tck tests [v2]
In-Reply-To: <OBrb6EJRDv2ILtRc4akmS1K5t6lC1Q3o5XmvqCNmKHM=.e15f8410-75ab-4f5e-b1ea-4551cf41f9a1@github.com>
References: <OBrb6EJRDv2ILtRc4akmS1K5t6lC1Q3o5XmvqCNmKHM=.e15f8410-75ab-4f5e-b1ea-4551cf41f9a1@github.com>
Message-ID: <HcSNFBmLYQjOei48P8uROCFNS5I5t83Efnlq7Br07s8=.0ed22a57-f399-48e9-b80f-39980b435f61@github.com>

> 8260461: Modernize jsr166 tck tests

Martin Buchholz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  JDK-8260461

-------------

Changes: https://git.openjdk.java.net/jdk/pull/2245/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2245&range=01
  Stats: 7616 lines in 71 files changed: 318 ins; 187 del; 7111 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2245.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2245/head:pull/2245

PR: https://git.openjdk.java.net/jdk/pull/2245

From martin at openjdk.java.net  Wed Jan 27 04:21:03 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Wed, 27 Jan 2021 04:21:03 GMT
Subject: RFR: 8260461: Modernize jsr166 tck tests [v3]
In-Reply-To: <OBrb6EJRDv2ILtRc4akmS1K5t6lC1Q3o5XmvqCNmKHM=.e15f8410-75ab-4f5e-b1ea-4551cf41f9a1@github.com>
References: <OBrb6EJRDv2ILtRc4akmS1K5t6lC1Q3o5XmvqCNmKHM=.e15f8410-75ab-4f5e-b1ea-4551cf41f9a1@github.com>
Message-ID: <kp-zBjIL_UNA8iusq2VNTp3wqBrSc-4hMGahVqoA24M=.63b49842-35fb-40e3-858f-e64ef1f16177@github.com>

> 8260461: Modernize jsr166 tck tests

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. The pull request contains one new commit since the last revision:

  JDK-8260461

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2245/files
  - new: https://git.openjdk.java.net/jdk/pull/2245/files/0cd05e2d..ed6b6f0f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2245&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2245&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2245.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2245/head:pull/2245

PR: https://git.openjdk.java.net/jdk/pull/2245

From martin at openjdk.java.net  Wed Jan 27 04:21:04 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Wed, 27 Jan 2021 04:21:04 GMT
Subject: RFR: 8260461: Modernize jsr166 tck tests [v3]
In-Reply-To: <-pOwn99YxdLHGuRnCvGfrCMzc1c6CQ8wYKma6Z09Cog=.ac9de67a-3f23-41ff-b8b3-866a0042854f@github.com>
References: <OBrb6EJRDv2ILtRc4akmS1K5t6lC1Q3o5XmvqCNmKHM=.e15f8410-75ab-4f5e-b1ea-4551cf41f9a1@github.com>
 <-pOwn99YxdLHGuRnCvGfrCMzc1c6CQ8wYKma6Z09Cog=.ac9de67a-3f23-41ff-b8b3-866a0042854f@github.com>
Message-ID: <IiSFrECD_An1vOUS-Wn8nWLfVNSZ8jC6l8uBzC1dRn0=.ee308576-2c04-4106-b665-d03712af3a3b@github.com>

On Wed, 27 Jan 2021 00:44:51 GMT, Doug Lea <dl at openjdk.org> wrote:

>> 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. The pull request contains one new commit since the last revision:
>> 
>>   JDK-8260461
>
> Marked as reviewed by dl (Reviewer).

jcheck bot caught trailing whitespace in commit

-------------

PR: https://git.openjdk.java.net/jdk/pull/2245

From iris at openjdk.java.net  Wed Jan 27 05:59:40 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 27 Jan 2021 05:59:40 GMT
Subject: RFR: 8259816: Typo in java.util.stream package description
In-Reply-To: <4Sy-nuhF9tNPiPpSySyDYt2-3hnMHORvrUdWaaODEmk=.28386f79-a94f-402d-8e65-4a886f1200c7@github.com>
References: <4Sy-nuhF9tNPiPpSySyDYt2-3hnMHORvrUdWaaODEmk=.28386f79-a94f-402d-8e65-4a886f1200c7@github.com>
Message-ID: <RJde-mrgICyBY3HJGSJwzkGwyGzZogZLagZHffqWxKI=.5b920847-bacc-4c2b-a9b5-413947668376@github.com>

On Wed, 27 Jan 2021 03:18:09 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Fix a typo, and change an example to use Stream.toList().

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2249

From joehw at openjdk.java.net  Wed Jan 27 06:33:01 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 27 Jan 2021 06:33:01 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline [v2]
In-Reply-To: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
Message-ID: <YdVSKzq7EnlPWnOQcwQoWiDpMCqR_jDIMPvLgE-DJfw=.3319eacd-67c7-482c-969f-ec014179a230@github.com>

> Please review a patch to add an explicit control over whether a newline should be added after the XML header. This is done by adding a DOM LSSerializer property "jdk-is-standalone" and System property "jdk.xml.isStandalone". 
> 
> This change addresses an incompatibility introduced during 7u4 as an update to Xalan 2.7.1.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  Update: add javadoc for impl specific features and properties in module-info; update the patch accordingly.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2041/files
  - new: https://git.openjdk.java.net/jdk/pull/2041/files/3ab9fed9..a3591aa7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2041&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2041&range=00-01

  Stats: 249 lines in 5 files changed: 233 ins; 5 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2041.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2041/head:pull/2041

PR: https://git.openjdk.java.net/jdk/pull/2041

From dholmes at openjdk.java.net  Wed Jan 27 06:50:45 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 27 Jan 2021 06:50:45 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <5n9zRTs8D3vp3QU8I7JxtR-Ly-yJKqUb_2NFZRf488Q=.f49c6b0f-6768-4e4a-87ec-fe46a7cf287b@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
 <RVUqncN8BLrGU1Rxdrg1zk_yE-sSQsZ08fge6Jp9ijI=.c355f1e9-1b9f-4e11-9243-c44b557b447d@github.com>
 <AE1YSbX-p_TaPh63xDXrPiDSfWhU6Ve4fDxg5KPrFSc=.7a3c8269-7238-4928-af00-00c3e13e76c6@github.com>
 <5n9zRTs8D3vp3QU8I7JxtR-Ly-yJKqUb_2NFZRf488Q=.f49c6b0f-6768-4e4a-87ec-fe46a7cf287b@github.com>
Message-ID: <Txu8OUN7kV33jxLsGHrwYJRV2fwE0wPaYEM2B4PjwHA=.ca204c57-7ffb-4540-b397-c1d805b16481@github.com>

On Tue, 26 Jan 2021 12:34:11 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

>>> AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework
>>> ie:
>>> `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`
>>> 
>>> Otherwise there will be missing _JNFNative* functions.
>>> 
>>> Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts?
>> 
>> There is ongoing work by P. Race to eliminate dependence on JNF at all
>
>> > AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework
>> > ie:
>> > `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`
>> > Otherwise there will be missing _JNFNative* functions.
>> > Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts?
>> 
>> There is ongoing work by P. Race to eliminate dependence on JNF at all
> 
> Ok, that's great.
> In the meantime is it worth adding something to the MacOS section of doc/building.* ?
> (I pieced together the required line from multiple posts in a mailing list)

Hi Anton,

Just to add weight to comments already made by @coleenp and @stefank , I also find the W^X coding support to be too intrusive and polluting of the shared code. I would much rather see this support pushed down as far as possible, to minimise the impact and to use ifdef'd code for macos/Aarch64 (via MACOS_AARCH64_ONLY macro) rather than providing empty methods.

Thanks,
David

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From ihse at openjdk.java.net  Wed Jan 27 08:29:45 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 27 Jan 2021 08:29:45 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
In-Reply-To: <IQ1xC4wgzr9t6IQyuHlZGkLgbgCpjbGCquoe6QwF6OA=.20391856-485c-4057-865b-37974b526f10@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <DbmqwFNrfBhdBMARLx4fbTam5Nqjb4nHDfDX9ePhSdw=.1969f025-2b9c-4d36-957c-2ba4718a2fbb@github.com>
 <H0K3sUe4APFRYh0HtLdrFW0q1_pFibrkvTUZlMceV_Y=.0ac40c75-c893-424a-af17-adc558dc6c17@github.com>
 <IQ1xC4wgzr9t6IQyuHlZGkLgbgCpjbGCquoe6QwF6OA=.20391856-485c-4057-865b-37974b526f10@github.com>
Message-ID: <l19MEW6eFCLdUx8xhNrTnlSNGlfNglpFAa4NmB7KnVg=.f2c5a11d-7001-49a2-aaa5-36caf0445894@github.com>

On Mon, 25 Jan 2021 16:00:23 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> @luhenry , could you please check this comment, I think SA-agent was MS's job here.
>
> The target is identified by the header file now:
> https://github.com/openjdk/jdk/pull/2200/files#diff-51442e74eeef2163f0f0643df0ae995083f666367e25fba2b527a9a5bc8743a6R35-R41
> 
> Do you think there is any problem with this approach?

@lewurm No, that's okay. I just wanted to know that this had not been lost.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From ihse at openjdk.java.net  Wed Jan 27 08:32:46 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 27 Jan 2021 08:32:46 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <ovN1AB7FTV92iIOLhFzcn8zJb0m02eoVDY5JVgQ6IW8=.faed2b97-2fbe-42f0-8aa9-b6b7eabc1326@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
 <ovN1AB7FTV92iIOLhFzcn8zJb0m02eoVDY5JVgQ6IW8=.faed2b97-2fbe-42f0-8aa9-b6b7eabc1326@github.com>
Message-ID: <RMVoZHdrp_odKyra8FySso-UsmmIaJ2H3DGS2YvzWMo=.6bf4c5f2-c173-4d1f-8e70-f72124eee46f@github.com>

On Tue, 26 Jan 2021 22:04:48 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> make/autoconf/build-aux/autoconf-config.guess line 1275:
>> 
>>> 1273: 		      UNAME_PROCESSOR="aarch64"
>>> 1274: 		  fi
>>> 1275: 		fi ;;
>> 
>> Almost, but not quite, correct. We cannot change the autoconf-config.guess file due to license restrictions (the license allows redistribution, not modifications). Instead we have the config.guess file which "wraps" autoconf-config.guess and makes pre-/post-call modifications to work around limitations in the autoconf original file. So you need to check there if you are getting incorrect results back and adjust it in that case. See the already existing clauses in that file.
>
> Hello
> I have updated PR and moved this logic to make/autoconf/build-aux/config.guess
> It's pretty similar to i386 -> x86_64 fix-up on macos_intel

Thanks. That looks better.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From ihse at openjdk.java.net  Wed Jan 27 08:38:46 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 27 Jan 2021 08:38:46 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
In-Reply-To: <PMUYint7pX2wmQ5wONMdgL7GclrxCnolwttyJC7BzTg=.ca680fa2-5b08-491f-9c1c-8253ffa2bbb4@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <PMUYint7pX2wmQ5wONMdgL7GclrxCnolwttyJC7BzTg=.ca680fa2-5b08-491f-9c1c-8253ffa2bbb4@github.com>
Message-ID: <LCUqjT2-6eTqN1RVGbHJQY1XBzUNRWlwDOj-ZCXDGfI=.949076d9-4311-4e7d-a95f-e59ea8e3b5e1@github.com>

On Tue, 26 Jan 2021 21:59:03 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Redo buildsys fix

Build changes per se now looks okay. However, I agree with Erik that unless this PR can wait for the JNF removal, at the very least the build docs needs to be updated to explain how to successfully build for this platform. (I can live with the configure command line hack, since it's temporary -- otherwise I'd have requested a new configure argument.) This can be done in this PR or a follow-up PR.

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2200

From david.holmes at oracle.com  Wed Jan 27 08:42:53 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 27 Jan 2021 18:42:53 +1000
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <Txu8OUN7kV33jxLsGHrwYJRV2fwE0wPaYEM2B4PjwHA=.ca204c57-7ffb-4540-b397-c1d805b16481@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
 <RVUqncN8BLrGU1Rxdrg1zk_yE-sSQsZ08fge6Jp9ijI=.c355f1e9-1b9f-4e11-9243-c44b557b447d@github.com>
 <AE1YSbX-p_TaPh63xDXrPiDSfWhU6Ve4fDxg5KPrFSc=.7a3c8269-7238-4928-af00-00c3e13e76c6@github.com>
 <5n9zRTs8D3vp3QU8I7JxtR-Ly-yJKqUb_2NFZRf488Q=.f49c6b0f-6768-4e4a-87ec-fe46a7cf287b@github.com>
 <Txu8OUN7kV33jxLsGHrwYJRV2fwE0wPaYEM2B4PjwHA=.ca204c57-7ffb-4540-b397-c1d805b16481@github.com>
Message-ID: <2f9e8ea2-a3a9-53d0-f735-894272a3717e@oracle.com>

I don't know why the Skara tools decided to associate my comment with 
Alan Hayward's comment as they are not at all related. :(

David

On 27/01/2021 4:50 pm, David Holmes wrote:
> On Tue, 26 Jan 2021 12:34:11 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:
> 
>>>> AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework
>>>> ie:
>>>> `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`
>>>>
>>>> Otherwise there will be missing _JNFNative* functions.
>>>>
>>>> Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts?
>>>
>>> There is ongoing work by P. Race to eliminate dependence on JNF at all
>>
>>>> AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework
>>>> ie:
>>>> `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`
>>>> Otherwise there will be missing _JNFNative* functions.
>>>> Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts?
>>>
>>> There is ongoing work by P. Race to eliminate dependence on JNF at all
>>
>> Ok, that's great.
>> In the meantime is it worth adding something to the MacOS section of doc/building.* ?
>> (I pieced together the required line from multiple posts in a mailing list)
> 
> Hi Anton,
> 
> Just to add weight to comments already made by @coleenp and @stefank , I also find the W^X coding support to be too intrusive and polluting of the shared code. I would much rather see this support pushed down as far as possible, to minimise the impact and to use ifdef'd code for macos/Aarch64 (via MACOS_AARCH64_ONLY macro) rather than providing empty methods.
> 
> Thanks,
> David
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2200
> 

From aph at redhat.com  Wed Jan 27 09:43:36 2021
From: aph at redhat.com (Andrew Haley)
Date: Wed, 27 Jan 2021 09:43:36 +0000
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <2f9e8ea2-a3a9-53d0-f735-894272a3717e@oracle.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
 <RVUqncN8BLrGU1Rxdrg1zk_yE-sSQsZ08fge6Jp9ijI=.c355f1e9-1b9f-4e11-9243-c44b557b447d@github.com>
 <AE1YSbX-p_TaPh63xDXrPiDSfWhU6Ve4fDxg5KPrFSc=.7a3c8269-7238-4928-af00-00c3e13e76c6@github.com>
 <5n9zRTs8D3vp3QU8I7JxtR-Ly-yJKqUb_2NFZRf488Q=.f49c6b0f-6768-4e4a-87ec-fe46a7cf287b@github.com>
 <Txu8OUN7kV33jxLsGHrwYJRV2fwE0wPaYEM2B4PjwHA=.ca204c57-7ffb-4540-b397-c1d805b16481@github.com>
 <2f9e8ea2-a3a9-53d0-f735-894272a3717e@oracle.com>
Message-ID: <90fd9651-f954-42da-1282-bf9a7de63e13@redhat.com>

On 1/26/21 6:42 PM, erik.joelsson at oracle.com wrote:
> My understanding is that Apple chose to not provide JNF for aarch64, so
> if you want to build OpenJDK, you first need to build JNF yourself (it's
> available in github). Phil is working on removing this dependency
> completely, which will solve this issue [1].
>
> In the meantime, I don't think we should rely on finding JNF in
> unsupported locations inside Xcode. Could we wait with integrating this
> port until it can be built without such hacks?

That sounds right to me.

In the meantime, there is some cleanup work to be done in mainline
on slow_signature_handler, which will potentially make the AArch64
back end merge much simpler.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From lancea at openjdk.java.net  Wed Jan 27 11:42:42 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 27 Jan 2021 11:42:42 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline [v2]
In-Reply-To: <YdVSKzq7EnlPWnOQcwQoWiDpMCqR_jDIMPvLgE-DJfw=.3319eacd-67c7-482c-969f-ec014179a230@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
 <YdVSKzq7EnlPWnOQcwQoWiDpMCqR_jDIMPvLgE-DJfw=.3319eacd-67c7-482c-969f-ec014179a230@github.com>
Message-ID: <cE1cRLI-8GTsRyjYSGNnI0C6WREOUXDfGugZNBaMhxE=.65a17c58-243a-487f-91d7-d887eac1bc75@github.com>

On Wed, 27 Jan 2021 06:33:01 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Please review a patch to add an explicit control over whether a newline should be added after the XML header. This is done by adding a DOM LSSerializer property "jdk-is-standalone" and System property "jdk.xml.isStandalone". 
>> 
>> This change addresses an incompatibility introduced during 7u4 as an update to Xalan 2.7.1.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update: add javadoc for impl specific features and properties in module-info; update the patch accordingly.

src/java.xml/share/classes/module-info.java line 82:

> 80:  *
> 81:  * <h3>jaxp.properties</h3>
> 82:  * A system property can be specified in the {@code jaxp.properties} file to

I know this is covered in the tutorial, but perhaps add a section to module-info describing the jaxp.properties file so you do not have to leave the page to find out more details?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2041

From lancea at openjdk.java.net  Wed Jan 27 11:56:41 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 27 Jan 2021 11:56:41 GMT
Subject: RFR: 8259816: Typo in java.util.stream package description
In-Reply-To: <4Sy-nuhF9tNPiPpSySyDYt2-3hnMHORvrUdWaaODEmk=.28386f79-a94f-402d-8e65-4a886f1200c7@github.com>
References: <4Sy-nuhF9tNPiPpSySyDYt2-3hnMHORvrUdWaaODEmk=.28386f79-a94f-402d-8e65-4a886f1200c7@github.com>
Message-ID: <-72Zuof95EePgs4VMirdCiRf5p_D_h2kGpK22ZQOhWw=.1e1caa9d-9ca3-49a2-9587-c9c7d434de1c@github.com>

On Wed, 27 Jan 2021 03:18:09 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Fix a typo, and change an example to use Stream.toList().

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2249

From redestad at openjdk.java.net  Wed Jan 27 12:19:53 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 27 Jan 2021 12:19:53 GMT
Subject: RFR: 8260506: VersionHelper cleanup
Message-ID: <st0l6YCTXoUp_arTlgqzHG3uvsUrEcjuzPc6sVXu7dg=.e7451f2b-f670-48a8-8a0d-3b6ee6cf8e09@github.com>

Some small modernizations and cleanups that ultimately help startup of apps using JNDI/InitialContext

-------------

Commit messages:
 - VersionHelper cleanup

Changes: https://git.openjdk.java.net/jdk/pull/2259/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2259&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260506
  Stats: 30 lines in 1 file changed: 2 ins; 16 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2259.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2259/head:pull/2259

PR: https://git.openjdk.java.net/jdk/pull/2259

From lzang at openjdk.java.net  Wed Jan 27 12:57:49 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 27 Jan 2021 12:57:49 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump
Message-ID: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>

8252842: Extend jmap to support parallel heap dump

-------------

Commit messages:
 - fix white space trailing issue
 - 8252842: Extend jmap to support parallel heap dump

Changes: https://git.openjdk.java.net/jdk/pull/2261/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252842
  Stats: 777 lines in 6 files changed: 590 ins; 57 del; 130 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2261.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261

PR: https://git.openjdk.java.net/jdk/pull/2261

From chegar at openjdk.java.net  Wed Jan 27 14:11:42 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 27 Jan 2021 14:11:42 GMT
Subject: Integrated: 8257074 Update the ByteBuffers micro benchmark
In-Reply-To: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
Message-ID: <RQRgt7w_ZF2VE2OVyWA94k_5JJc_zcbuQRDeuZ5z6Ug=.76462fa3-0550-483b-bfca-f18c25ec67ca@github.com>

On Wed, 25 Nov 2020 12:41:40 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> The ByteBuffers micro benchmark seems to be a little dated. 
> 
> It should be a useful resource to leverage when analysing the performance impact of any potential implementation changes in the byte buffer classes. More specifically, the impact of such changes on the performance of sharp memory access operations. 
> 
> This issue proposes to update the benchmark in the following ways to meet the aforementioned use-case: 
> 
> 1. Remove allocation from the individual benchmarks - it just creates noise. 
> 2. Consolidate per-thread shared heap and direct buffers. 
> 3. All scenarios now use absolute memory access operations - so no state of the shared buffers is considered. 
> 4. Provide more reasonable default fork, warmup, etc, out-of-the-box. 
> 5. There seems to have been an existing bug in the test where the size parameter was not always considered - this is now fixed.

This pull request has now been integrated.

Changeset: ac276bb3
Author:    Chris Hegarty <chegar at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ac276bb3
Stats:     2771 lines in 11 files changed: 2612 ins; 9 del; 150 mod

8257074: Update the ByteBuffers micro benchmark

Reviewed-by: redestad, dfuchs, jvernee, bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/1430

From akozlov at openjdk.java.net  Wed Jan 27 14:50:01 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 27 Jan 2021 14:50:01 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v7]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <rNYdBWEDqqr_8YrP9VqCYXxL_5TIWEogUHXWC4BZynI=.1f31c19c-6547-401d-b29a-d42cab24718e@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright year for BsdAARCH64ThreadContext.java
 - Fix inclusing of StubRoutines header

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/f1ef6240..9d8b07c2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=05-06

  Stats: 5 lines in 4 files changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

From vkempik at openjdk.java.net  Wed Jan 27 15:01:47 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Wed, 27 Jan 2021 15:01:47 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
In-Reply-To: <LCUqjT2-6eTqN1RVGbHJQY1XBzUNRWlwDOj-ZCXDGfI=.949076d9-4311-4e7d-a95f-e59ea8e3b5e1@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <PMUYint7pX2wmQ5wONMdgL7GclrxCnolwttyJC7BzTg=.ca680fa2-5b08-491f-9c1c-8253ffa2bbb4@github.com>
 <LCUqjT2-6eTqN1RVGbHJQY1XBzUNRWlwDOj-ZCXDGfI=.949076d9-4311-4e7d-a95f-e59ea8e3b5e1@github.com>
Message-ID: <A2D8hAuv2S3R1jr0w8WpqNl-JfEDkT_ZpAMpYhBG-Ao=.95043299-5f1d-4198-b5aa-a9907f43fed2@github.com>

On Wed, 27 Jan 2021 08:36:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Build changes per se now looks okay. However, I agree with Erik that unless this PR can wait for the JNF removal, at the very least the build docs needs to be updated to explain how to successfully build for this platform. (I can live with the configure command line hack, since it's temporary -- otherwise I'd have requested a new configure argument.) This can be done in this PR or a follow-up PR.

I believe it's better be done under separate PR/bugfix, so it can be completely reverted once JNF removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From alanb at openjdk.java.net  Wed Jan 27 15:35:42 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 27 Jan 2021 15:35:42 GMT
Subject: RFR: 8260506: VersionHelper cleanup
In-Reply-To: <st0l6YCTXoUp_arTlgqzHG3uvsUrEcjuzPc6sVXu7dg=.e7451f2b-f670-48a8-8a0d-3b6ee6cf8e09@github.com>
References: <st0l6YCTXoUp_arTlgqzHG3uvsUrEcjuzPc6sVXu7dg=.e7451f2b-f670-48a8-8a0d-3b6ee6cf8e09@github.com>
Message-ID: <Fg97GGrQnJOoyC30DC33Vm7GDYfcUPrvbdE_t_P8idI=.d17b8a60-0059-43a5-9af2-36ab394dc265@github.com>

On Wed, 27 Jan 2021 12:15:43 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Some small modernizations and cleanups that ultimately help startup of apps using JNDI/InitialContext

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2259

From rriggs at openjdk.java.net  Wed Jan 27 15:52:44 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 27 Jan 2021 15:52:44 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline [v2]
In-Reply-To: <YdVSKzq7EnlPWnOQcwQoWiDpMCqR_jDIMPvLgE-DJfw=.3319eacd-67c7-482c-969f-ec014179a230@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
 <YdVSKzq7EnlPWnOQcwQoWiDpMCqR_jDIMPvLgE-DJfw=.3319eacd-67c7-482c-969f-ec014179a230@github.com>
Message-ID: <vsFBWeAK3qb-7IIyEH_gN3HpyRrXSfXmBD0AN8eb4KA=.fcaac82e-656b-42a9-83df-46ee3f9937b1@github.com>

On Wed, 27 Jan 2021 06:33:01 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Please review a patch to add an explicit control over whether a newline should be added after the XML header. This is done by adding a DOM LSSerializer property "jdk-is-standalone" and System property "jdk.xml.isStandalone". 
>> 
>> This change addresses an incompatibility introduced during 7u4 as an update to Xalan 2.7.1.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update: add javadoc for impl specific features and properties in module-info; update the patch accordingly.

src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/LSSerializerImpl.java line 639:

> 637:                 if (state) {
> 638:                     fDOMConfigProperties.setProperty(DOMConstants.S_JDK_PROPERTIES_NS
> 639:                             + DOMConstants.S_IS_STANDALONE, "yes");

Multiple concatenations of the same strings, seems awkward at best and perhaps a maintenance burden.
Would it make sense to declare them as static strings?
Though in this case, it could be a single call to setProperty with the value being `(state ? "yes" : "no")`

src/java.xml/share/classes/module-info.java line 58:

> 56:  * The prefix for System Properties:
> 57:  * <pre>
> 58:  *     {@systemProperty jdk.xml.}

The use of {@systemProperty...} seems inappropriate, it should be used to refer to specific properties. (IMHO)

src/java.xml/share/classes/module-info.java line 64:

> 62:  * A name may consist of one or multiple words that are case-sensitive.
> 63:  * All letters of the first word shall be in lowercase, while the first letter of
> 64:  * each subsequent word capitalized.

capitalized -> "is capitalized"

src/java.xml/share/classes/module-info.java line 91:

> 89:  * <h3 id="ScopeAndOrder">Scope and Order</h3>
> 90:  * The {@link javax.xml.XMLConstants#FEATURE_SECURE_PROCESSING} feature
> 91:  * (hereafter referred to as FSP) is required for XML processors including DOM,

I think it would be more readable to use "secure processing" instead of "FSP".
I.e.  when secure processing is set..., etc.

src/java.xml/share/classes/module-info.java line 103:

> 101:  * <p>
> 102:  * Properties specified in the jaxp.properties file affect all invocations of
> 103:  * the JDK and JRE, and will override their default values, or those that may

We've phased out the "JRE", so it can be dropped here.

src/java.xml/share/classes/module-info.java line 107:

> 105:  * <p>
> 106:  * System properties, when set, affect the invocation of the JDK and JRE, and
> 107:  * override the default settings or that set in jaxp.properties, or those that

"that set" -> 'that are set"

-------------

PR: https://git.openjdk.java.net/jdk/pull/2041

From dfuchs at openjdk.java.net  Wed Jan 27 16:06:39 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 27 Jan 2021 16:06:39 GMT
Subject: RFR: 8260506: VersionHelper cleanup
In-Reply-To: <st0l6YCTXoUp_arTlgqzHG3uvsUrEcjuzPc6sVXu7dg=.e7451f2b-f670-48a8-8a0d-3b6ee6cf8e09@github.com>
References: <st0l6YCTXoUp_arTlgqzHG3uvsUrEcjuzPc6sVXu7dg=.e7451f2b-f670-48a8-8a0d-3b6ee6cf8e09@github.com>
Message-ID: <NoyI5BaTLco0CYBFVzHanlV9_w8fh7U6gYQZmIyDokY=.4eb013cc-7c06-4c58-b994-c7c5d1df2b0a@github.com>

On Wed, 27 Jan 2021 12:15:43 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Some small modernizations and cleanups that ultimately help startup of apps using JNDI/InitialContext

Looks fine to me. I have satisfied myself that `c` couldn't be a primitive type if we reach here.
Please make sure to run tier2 for this one too.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2259

From naoto at openjdk.java.net  Wed Jan 27 16:21:45 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 27 Jan 2021 16:21:45 GMT
Subject: RFR: 8259816: Typo in java.util.stream package description
In-Reply-To: <4Sy-nuhF9tNPiPpSySyDYt2-3hnMHORvrUdWaaODEmk=.28386f79-a94f-402d-8e65-4a886f1200c7@github.com>
References: <4Sy-nuhF9tNPiPpSySyDYt2-3hnMHORvrUdWaaODEmk=.28386f79-a94f-402d-8e65-4a886f1200c7@github.com>
Message-ID: <wBHn48o_GWuOUK3QercRzLs8f3ZCW0YA57mN0R1mRlA=.15c36dda-6cf4-476b-b28f-971549888c2a@github.com>

On Wed, 27 Jan 2021 03:18:09 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Fix a typo, and change an example to use Stream.toList().

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2249

From naoto at openjdk.java.net  Wed Jan 27 17:21:43 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 27 Jan 2021 17:21:43 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline [v2]
In-Reply-To: <YdVSKzq7EnlPWnOQcwQoWiDpMCqR_jDIMPvLgE-DJfw=.3319eacd-67c7-482c-969f-ec014179a230@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
 <YdVSKzq7EnlPWnOQcwQoWiDpMCqR_jDIMPvLgE-DJfw=.3319eacd-67c7-482c-969f-ec014179a230@github.com>
Message-ID: <bNI8NKcwN_VvQaLjdIh2b4kJqrBXz4DIerxYJm8iDoY=.0d3fe019-711b-494a-aa07-7661129a5b73@github.com>

On Wed, 27 Jan 2021 06:33:01 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Please review a patch to add an explicit control over whether a newline should be added after the XML header. This is done by adding a DOM LSSerializer property "jdk-is-standalone" and System property "jdk.xml.isStandalone". 
>> 
>> This change addresses an incompatibility introduced during 7u4 as an update to Xalan 2.7.1.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update: add javadoc for impl specific features and properties in module-info; update the patch accordingly.

src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/LSSerializerImpl.java line 362:

> 360:         // JDK specific property jdk-is-standalone
> 361:         String p = SecuritySupport.getSystemProperty(DOMConstants.SP_IS_STANDALONE);
> 362:         if (p == null || p.equals("")) {

Although I see it aligns with other locations, `p.isEmpty()` is better?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2041

From aefimov at openjdk.java.net  Wed Jan 27 17:48:41 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 27 Jan 2021 17:48:41 GMT
Subject: RFR: 8260506: VersionHelper cleanup
In-Reply-To: <st0l6YCTXoUp_arTlgqzHG3uvsUrEcjuzPc6sVXu7dg=.e7451f2b-f670-48a8-8a0d-3b6ee6cf8e09@github.com>
References: <st0l6YCTXoUp_arTlgqzHG3uvsUrEcjuzPc6sVXu7dg=.e7451f2b-f670-48a8-8a0d-3b6ee6cf8e09@github.com>
Message-ID: <DK9x-AuEsYXE-DJEisQD6ioEyQPoYX0uyE_1CJsqXyQ=.bea6e45a-a9e4-4ab7-8da8-4bd54fe49222@github.com>

On Wed, 27 Jan 2021 12:15:43 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Some small modernizations and cleanups that ultimately help startup of apps using JNDI/InitialContext

Marked as reviewed by aefimov (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2259

From aefimov at openjdk.java.net  Wed Jan 27 17:48:42 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 27 Jan 2021 17:48:42 GMT
Subject: RFR: 8260506: VersionHelper cleanup
In-Reply-To: <NoyI5BaTLco0CYBFVzHanlV9_w8fh7U6gYQZmIyDokY=.4eb013cc-7c06-4c58-b994-c7c5d1df2b0a@github.com>
References: <st0l6YCTXoUp_arTlgqzHG3uvsUrEcjuzPc6sVXu7dg=.e7451f2b-f670-48a8-8a0d-3b6ee6cf8e09@github.com>
 <NoyI5BaTLco0CYBFVzHanlV9_w8fh7U6gYQZmIyDokY=.4eb013cc-7c06-4c58-b994-c7c5d1df2b0a@github.com>
Message-ID: <QRviDiJITPxu5vUKrlSoivMlTUv4xGCeOHz3EjbmTUo=.c815fc63-fb0c-419f-8246-a8d0fe4dc2a6@github.com>

On Wed, 27 Jan 2021 16:03:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Some small modernizations and cleanups that ultimately help startup of apps using JNDI/InitialContext
>
> Looks fine to me. I have satisfied myself that `c` couldn't be a primitive type if we reach here.
> Please make sure to run tier2 for this one too.

The changes looks good to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2259

From joehw at openjdk.java.net  Wed Jan 27 18:16:47 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 27 Jan 2021 18:16:47 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline [v2]
In-Reply-To: <cE1cRLI-8GTsRyjYSGNnI0C6WREOUXDfGugZNBaMhxE=.65a17c58-243a-487f-91d7-d887eac1bc75@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
 <YdVSKzq7EnlPWnOQcwQoWiDpMCqR_jDIMPvLgE-DJfw=.3319eacd-67c7-482c-969f-ec014179a230@github.com>
 <cE1cRLI-8GTsRyjYSGNnI0C6WREOUXDfGugZNBaMhxE=.65a17c58-243a-487f-91d7-d887eac1bc75@github.com>
Message-ID: <ItggBcq_YhRQZCrOjINyJBP2X4_lvjHZ8vCPsbSLZ3Q=.8dac4885-dba6-478d-ae9b-b7d1162048bf@github.com>

On Wed, 27 Jan 2021 11:39:29 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update: add javadoc for impl specific features and properties in module-info; update the patch accordingly.
>
> src/java.xml/share/classes/module-info.java line 82:
> 
>> 80:  *
>> 81:  * <h3>jaxp.properties</h3>
>> 82:  * A system property can be specified in the {@code jaxp.properties} file to
> 
> I know this is covered in the tutorial, but perhaps add a section to module-info describing the jaxp.properties file so you do not have to leave the page to find out more details?

The jaxp.properties file is described in detail in JAXP factories. I'll add a link to one of the factories.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2041

From jlaskey at openjdk.java.net  Wed Jan 27 18:25:40 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 27 Jan 2021 18:25:40 GMT
Subject: RFR: 8260337: Optimize ImageReader lookup,
 used by Class.getResource [v2]
In-Reply-To: <wiOiXfQx_b4KCY5jbwgez-iMByKK3-SWOKZshzcE-ac=.563935b2-f60a-480a-a883-a3f354de704c@github.com>
References: <zQXTGreWNlfXRT-l_G5Ptd6i_ZQ5XbD7yQj40Kr84Ic=.8dab254e-0aa9-4932-a8bd-0194e25ed68f@github.com>
 <wiOiXfQx_b4KCY5jbwgez-iMByKK3-SWOKZshzcE-ac=.563935b2-f60a-480a-a883-a3f354de704c@github.com>
Message-ID: <gbNZMNf4bYbwEL9jnIEgUhs73orb-SyfUG9e0r1l0tE=.86993b35-6ba4-4279-b65a-c29266eebe66@github.com>

On Mon, 25 Jan 2021 16:09:01 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch optimizes the code paths exercised by `String.class.getResource("String.class")` by:
>> 
>> - Adding an ASCII fast-path to methods verifying strings in the jimage, which can then be done allocation-free
>> - Avoiding the allocation of the `long[8]` attributes when verifying only for the purpose of verifying a path exists
>> - Using the `JNUA.create` fast-path in `SystemModuleReader` (which should be OK since we just verified the given name is a JRT path)
>> - Remove a redundant check in `Class::resolveName` and fitting the `StringBuilder` to size
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyrights and rename containsLocation

Nice clean up. LGTM

-------------

Marked as reviewed by jlaskey (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2212

From joehw at openjdk.java.net  Wed Jan 27 18:38:43 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 27 Jan 2021 18:38:43 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline [v2]
In-Reply-To: <vsFBWeAK3qb-7IIyEH_gN3HpyRrXSfXmBD0AN8eb4KA=.fcaac82e-656b-42a9-83df-46ee3f9937b1@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
 <YdVSKzq7EnlPWnOQcwQoWiDpMCqR_jDIMPvLgE-DJfw=.3319eacd-67c7-482c-969f-ec014179a230@github.com>
 <vsFBWeAK3qb-7IIyEH_gN3HpyRrXSfXmBD0AN8eb4KA=.fcaac82e-656b-42a9-83df-46ee3f9937b1@github.com>
Message-ID: <xMfkbERwES8Xx6gKzsv2vQ_BDTsrA-gqA__-CQprK6Y=.b304ecbf-c894-4ce6-9072-0949a0047966@github.com>

On Wed, 27 Jan 2021 15:34:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update: add javadoc for impl specific features and properties in module-info; update the patch accordingly.
>
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/LSSerializerImpl.java line 639:
> 
>> 637:                 if (state) {
>> 638:                     fDOMConfigProperties.setProperty(DOMConstants.S_JDK_PROPERTIES_NS
>> 639:                             + DOMConstants.S_IS_STANDALONE, "yes");
> 
> Multiple concatenations of the same strings, seems awkward at best and perhaps a maintenance burden.
> Would it make sense to declare them as static strings?
> Though in this case, it could be a single call to setProperty with the value being `(state ? "yes" : "no")`

Will do. I'll see if we should do the same with the existing ones.

> src/java.xml/share/classes/module-info.java line 58:
> 
>> 56:  * The prefix for System Properties:
>> 57:  * <pre>
>> 58:  *     {@systemProperty jdk.xml.}
> 
> The use of {@systemProperty...} seems inappropriate, it should be used to refer to specific properties. (IMHO)

will change to @code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2041

From joehw at openjdk.java.net  Wed Jan 27 18:59:45 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 27 Jan 2021 18:59:45 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline [v2]
In-Reply-To: <vsFBWeAK3qb-7IIyEH_gN3HpyRrXSfXmBD0AN8eb4KA=.fcaac82e-656b-42a9-83df-46ee3f9937b1@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
 <YdVSKzq7EnlPWnOQcwQoWiDpMCqR_jDIMPvLgE-DJfw=.3319eacd-67c7-482c-969f-ec014179a230@github.com>
 <vsFBWeAK3qb-7IIyEH_gN3HpyRrXSfXmBD0AN8eb4KA=.fcaac82e-656b-42a9-83df-46ee3f9937b1@github.com>
Message-ID: <6-7uOyZHItBKd7NwPLK13lwex3Phg1vy5RTGKtLIHqg=.54a20c70-d3a2-4422-bc38-eee0231d87b6@github.com>

On Wed, 27 Jan 2021 15:41:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update: add javadoc for impl specific features and properties in module-info; update the patch accordingly.
>
> src/java.xml/share/classes/module-info.java line 64:
> 
>> 62:  * A name may consist of one or multiple words that are case-sensitive.
>> 63:  * All letters of the first word shall be in lowercase, while the first letter of
>> 64:  * each subsequent word capitalized.
> 
> capitalized -> "is capitalized"

Fixed.

> src/java.xml/share/classes/module-info.java line 103:
> 
>> 101:  * <p>
>> 102:  * Properties specified in the jaxp.properties file affect all invocations of
>> 103:  * the JDK and JRE, and will override their default values, or those that may
> 
> We've phased out the "JRE", so it can be dropped here.

Removed all cases.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2041

From smarks at openjdk.java.net  Wed Jan 27 19:05:42 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 27 Jan 2021 19:05:42 GMT
Subject: Integrated: 8259816: Typo in java.util.stream package description
In-Reply-To: <4Sy-nuhF9tNPiPpSySyDYt2-3hnMHORvrUdWaaODEmk=.28386f79-a94f-402d-8e65-4a886f1200c7@github.com>
References: <4Sy-nuhF9tNPiPpSySyDYt2-3hnMHORvrUdWaaODEmk=.28386f79-a94f-402d-8e65-4a886f1200c7@github.com>
Message-ID: <C4zAztCFa1uR8sPxA_6pP6oVN6nZJrmywsfeKdIdD_M=.c3fdd464-e690-49c5-b2f9-cef66b2e1656@github.com>

On Wed, 27 Jan 2021 03:18:09 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Fix a typo, and change an example to use Stream.toList().

This pull request has now been integrated.

Changeset: eb923685
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/eb923685
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8259816: Typo in java.util.stream package description

Reviewed-by: iris, lancea, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/2249

From poonam at openjdk.java.net  Wed Jan 27 21:15:52 2021
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Wed, 27 Jan 2021 21:15:52 GMT
Subject: RFR: 8257746: Regression introduced with JDK-8250984 - memory might
 be null in some machines
Message-ID: <Fy288IpbsbT1qiVcV5yF950k_6guA5BcW1bdolDeCmQ=.2518cad3-5efb-4643-95c6-8cc6d0e2c6a5@github.com>

Please review this simple change that adds null checks for memory in CgroupV1Subsystem.java.

Problem: After the backport of JDK-8250984,  there are places where memory.isSwapEnabled() is called. For example:

    public long getMemoryAndSwapFailCount() {
        if (!memory.isSwapEnabled()) {
            return getMemoryFailCount();
        }
        return SubSystem.getLongValue(memory, "memory.memsw.failcnt");
    }
 
But memory could be Null on some machines that have cgroup entries for CPU but not for memory. This would cause a NullPointerException when memory is accessed.

Fix: Add null checks for memory.

-------------

Commit messages:
 - 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines

Changes: https://git.openjdk.java.net/jdk/pull/2269/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2269&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257746
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2269.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2269/head:pull/2269

PR: https://git.openjdk.java.net/jdk/pull/2269

From amenkov at openjdk.java.net  Wed Jan 27 21:44:39 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 27 Jan 2021 21:44:39 GMT
Subject: RFR: 8258917: NativeMemoryTracking is handled by launcher
 inconsistenly [v2]
In-Reply-To: <9YSxbXm9PS0nI-nLOCayqUooZDOpuIz50AeuiHwGT04=.53a3951a-b5aa-4e17-804c-9588fb1ce801@github.com>
References: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
 <1ojc6R4Tkg2oSXjEb7Y2nrvb-fcoZICYVckWdkcQ3FA=.f6ad204e-ff50-4669-a17e-8bf037e0d18f@github.com>
 <9YSxbXm9PS0nI-nLOCayqUooZDOpuIz50AeuiHwGT04=.53a3951a-b5aa-4e17-804c-9588fb1ce801@github.com>
Message-ID: <BDuTUXvvGlTgmtcyD4kjUC4TgJFPCMiKZba34vafh90=.9309818e-0ba5-4dc5-a1f0-e1abe5a63bd5@github.com>

On Tue, 19 Jan 2021 23:18:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Non-lava launchers should process all "-J" arguments
>
> Hi Alex,
> 
> I think this is functionally correct now - though the comment you added is confusing to me (see below).
> 
> However I remain concerned that this requires processing the arg list twice for non-Java launchers. Is that a startup issue we should be concerned about?
> 
> Thanks,
> David

Hi David,

> You integrated this change but neither Zhengyu nor myself approved the
> final changes. Zhengyu's Review was prior to the logic fix, and my
> comment "this seems functionally correct" was just a comment and we were
> still discussing the overhead aspect of this.
> 
> David

I was sure I saw 2 approvals for the fix, but most likely I misread it and there were 2 reviewers.
Do you have some suggestions how to handle this?
I don't think it makes sense to revert the change and re-do it from the beginning.
I think we don't need to worry about startup time impact. It's minimal and only non-java launchers are affected (AFAIR the main goal of performance/startup optimizations was java launcher).
I can file an RFE to reorder launcher logic and handle NMT in ParseArguments as I described earlier. If it's possible, this would remove one cycle (SetJvmEnvironment) for java/javaw launchers.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2106

From rriggs at openjdk.java.net  Wed Jan 27 22:14:49 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 27 Jan 2021 22:14:49 GMT
Subject: RFR: 8260561: [doc] HexFormat has incorrect @since tag
Message-ID: <g0k88vwbPye3IloAV_noj5WEOrsE5ltmDLzPcFOoZhU=.f2bf3266-ce3e-46ca-9bf9-0b300a129874@github.com>

A doc-only change to correct the @ since tag.

-------------

Commit messages:
 - 8260561: [doc] HexFormat has incorrect @since tag

Changes: https://git.openjdk.java.net/jdk/pull/2270/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2270&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260561
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2270.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2270/head:pull/2270

PR: https://git.openjdk.java.net/jdk/pull/2270

From github.com+34924738+mahendrachhipa at openjdk.java.net  Wed Jan 27 22:15:46 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Wed, 27 Jan 2021 22:15:46 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
 [v3]
In-Reply-To: <dotXorU_ykwCOblQVPC3eNuYiBK9Oe7EBcKrV84meKQ=.09a4c388-50d3-43bb-b8c6-1628ab6f86e2@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
 <fUm4Dayv7nRXfJMPfSN2K1Q9-MAebjdGT5zMNsN_Tno=.f5968959-48ad-4b72-a811-1db0ff08b10c@github.com>
 <dotXorU_ykwCOblQVPC3eNuYiBK9Oe7EBcKrV84meKQ=.09a4c388-50d3-43bb-b8c6-1628ab6f86e2@github.com>
Message-ID: <tZhKceXHEE32exxIRlJrzj-jlIqwQDtoOdZ1SxD2epU=.3b653c6d-797b-4f44-a5ed-41733644b538@github.com>

On Tue, 26 Jan 2021 22:56:25 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented the review comments.
>
> test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 158:
> 
>> 156:     private void match(final String actual, final String expected) {
>> 157:         System.out.println("actual:" + actual + "expected:" + expected);
>> 158:         assert ((actual == null && expected == null) || actual.trim().equals(expected.trim()));
> 
> Out of curiousity, why is the trim() now needed ?

expected string having one space as prefixed in some class names incase of pkg1 and pkg2 packages. So trimmig before comparing with actual name:

=================================================
nested class within top level class:
class EnclosingClass$Nested
	is enclosed by:		class EnclosingClass
	has simple name:	`Nested'
	has canonical name:	`EnclosingClass.Nested'
actual:class EnclosingClassexpected:class EnclosingClass

=================================================
nested class within top level class:
class pkg1.pkg2.EnclosingClass$Nested
	is enclosed by:		class pkg1.pkg2.EnclosingClass
	has simple name:	`Nested'
	has canonical name:	`pkg1.pkg2.EnclosingClass.Nested'
actual:class pkg1.pkg2.EnclosingClass**expected: class pkg1.pkg2.EnclosingClass**
==================================================

nested class within top level class:
class pkg1.EnclosingClass$Nested
	is enclosed by:		class pkg1.EnclosingClass
	has simple name:	`Nested'
	has canonical name:	`pkg1.EnclosingClass.Nested'
actual:class pkg1.EnclosingClass**expected: class pkg1.EnclosingClass**

-------------

PR: https://git.openjdk.java.net/jdk/pull/2170

From darcy at openjdk.java.net  Wed Jan 27 22:18:40 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 27 Jan 2021 22:18:40 GMT
Subject: RFR: 8260561: [doc] HexFormat has incorrect @since tag
In-Reply-To: <g0k88vwbPye3IloAV_noj5WEOrsE5ltmDLzPcFOoZhU=.f2bf3266-ce3e-46ca-9bf9-0b300a129874@github.com>
References: <g0k88vwbPye3IloAV_noj5WEOrsE5ltmDLzPcFOoZhU=.f2bf3266-ce3e-46ca-9bf9-0b300a129874@github.com>
Message-ID: <4iK-cdOThEXs2BzgUHjVqZ5ked8x-lql6oaPcGPjkt8=.b2f78a1e-c8b1-4465-ab34-00863e9b7677@github.com>

On Wed, 27 Jan 2021 22:10:01 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> A doc-only change to correct the @ since tag.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2270

From naoto at openjdk.java.net  Wed Jan 27 22:18:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 27 Jan 2021 22:18:40 GMT
Subject: RFR: 8260561: [doc] HexFormat has incorrect @since tag
In-Reply-To: <g0k88vwbPye3IloAV_noj5WEOrsE5ltmDLzPcFOoZhU=.f2bf3266-ce3e-46ca-9bf9-0b300a129874@github.com>
References: <g0k88vwbPye3IloAV_noj5WEOrsE5ltmDLzPcFOoZhU=.f2bf3266-ce3e-46ca-9bf9-0b300a129874@github.com>
Message-ID: <7MI3unPJib8MNbwlSusYerik9ipCt2EsllYgZPCkjBg=.609c9f29-4e2f-438b-b5ae-5574cd7c2eca@github.com>

On Wed, 27 Jan 2021 22:10:01 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> A doc-only change to correct the @ since tag.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2270

From github.com+34924738+mahendrachhipa at openjdk.java.net  Wed Jan 27 22:20:48 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Wed, 27 Jan 2021 22:20:48 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
 [v3]
In-Reply-To: <VB2ZA9FDB03NtlCeMvboqHK6lKGeQjVBUcPPOquF1s4=.82aff354-b7e1-4966-84b5-38306aa24e02@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
 <fUm4Dayv7nRXfJMPfSN2K1Q9-MAebjdGT5zMNsN_Tno=.f5968959-48ad-4b72-a811-1db0ff08b10c@github.com>
 <VB2ZA9FDB03NtlCeMvboqHK6lKGeQjVBUcPPOquF1s4=.82aff354-b7e1-4966-84b5-38306aa24e02@github.com>
Message-ID: <RTrwwhTf63OIrXtVcR-PzALpXX0AV-DMd_mjGoZvXKY=.3a494dd3-84a1-4fe4-b3d6-0cd52e496fc9@github.com>

On Tue, 26 Jan 2021 23:25:03 GMT, Florent Guillaume <github.com+592810+efge at openjdk.org> wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented the review comments.
>
> test/jdk/java/lang/Class/forName/NonJavaNames.java line 67:
> 
>> 65:     @BeforeClass
>> 66:     public void createInvalidNameClasses() throws IOException {
>> 67:         Path hyphenPath = Paths.get(TEST_SRC + "hyphen.class");
> 
> Building a `Path` with string concatenation is an anti-pattern.
> Also `Path.of` is probably preferred instead of `Paths.get`.

Now not doing the concatenation of the strings to create Path.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2170

From bpb at openjdk.java.net  Wed Jan 27 22:22:39 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 27 Jan 2021 22:22:39 GMT
Subject: RFR: 8260561: [doc] HexFormat has incorrect @since tag
In-Reply-To: <g0k88vwbPye3IloAV_noj5WEOrsE5ltmDLzPcFOoZhU=.f2bf3266-ce3e-46ca-9bf9-0b300a129874@github.com>
References: <g0k88vwbPye3IloAV_noj5WEOrsE5ltmDLzPcFOoZhU=.f2bf3266-ce3e-46ca-9bf9-0b300a129874@github.com>
Message-ID: <PsiSme50zcjVlK-nkNmZg9rTH83xyQ1Xbva74wRFfT4=.ee2a33d2-22f8-4443-ba7f-cc64e5de77ec@github.com>

On Wed, 27 Jan 2021 22:10:01 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> A doc-only change to correct the @ since tag.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2270

From github.com+34924738+mahendrachhipa at openjdk.java.net  Wed Jan 27 22:23:44 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Wed, 27 Jan 2021 22:23:44 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
 [v3]
In-Reply-To: <dotXorU_ykwCOblQVPC3eNuYiBK9Oe7EBcKrV84meKQ=.09a4c388-50d3-43bb-b8c6-1628ab6f86e2@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
 <fUm4Dayv7nRXfJMPfSN2K1Q9-MAebjdGT5zMNsN_Tno=.f5968959-48ad-4b72-a811-1db0ff08b10c@github.com>
 <dotXorU_ykwCOblQVPC3eNuYiBK9Oe7EBcKrV84meKQ=.09a4c388-50d3-43bb-b8c6-1628ab6f86e2@github.com>
Message-ID: <1y-yNau19ar7xgbR4DfhTUGzaK0O1Tc1QQBDQgwimyI=.c23967a6-83ca-4092-a591-f576e46e9aa8@github.com>

On Tue, 26 Jan 2021 22:52:15 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented the review comments.
>
> test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 76:
> 
>> 74: * @modules jdk.compiler
>> 75: * @build jdk.test.lib.process.* EnclosingClassTest
>> 76: * @run testng/othervm EnclosingClassTest
> 
> The test should still be run with -esa -ea

Yes, while running from command line providing the -esa and -a option to run the tests.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2170

From lancea at openjdk.java.net  Wed Jan 27 22:34:39 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 27 Jan 2021 22:34:39 GMT
Subject: RFR: 8260561: [doc] HexFormat has incorrect @since tag
In-Reply-To: <g0k88vwbPye3IloAV_noj5WEOrsE5ltmDLzPcFOoZhU=.f2bf3266-ce3e-46ca-9bf9-0b300a129874@github.com>
References: <g0k88vwbPye3IloAV_noj5WEOrsE5ltmDLzPcFOoZhU=.f2bf3266-ce3e-46ca-9bf9-0b300a129874@github.com>
Message-ID: <UC4JU-arqxAD2T2vS-pStD2hzgFkDj0s0UjFnzvdzLA=.0ce79f7b-0219-4a06-9df5-3a19565c8e95@github.com>

On Wed, 27 Jan 2021 22:10:01 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> A doc-only change to correct the @ since tag.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2270

From rriggs at openjdk.java.net  Wed Jan 27 22:40:41 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 27 Jan 2021 22:40:41 GMT
Subject: Integrated: 8260561: [doc] HexFormat has incorrect @since tag
In-Reply-To: <g0k88vwbPye3IloAV_noj5WEOrsE5ltmDLzPcFOoZhU=.f2bf3266-ce3e-46ca-9bf9-0b300a129874@github.com>
References: <g0k88vwbPye3IloAV_noj5WEOrsE5ltmDLzPcFOoZhU=.f2bf3266-ce3e-46ca-9bf9-0b300a129874@github.com>
Message-ID: <EMPA3hnoaU-5_LQbyHJ6w2vakyVsSvwMtjiTLwIyNk0=.94c7ebf7-4f46-457e-8e92-7f12267964af@github.com>

On Wed, 27 Jan 2021 22:10:01 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> A doc-only change to correct the @ since tag.

This pull request has now been integrated.

Changeset: c7661aed
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c7661aed
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8260561: [doc] HexFormat has incorrect @since tag

Reviewed-by: darcy, naoto, bpb, lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/2270

From github.com+34924738+mahendrachhipa at openjdk.java.net  Wed Jan 27 22:44:00 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Wed, 27 Jan 2021 22:44:00 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
 [v4]
In-Reply-To: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
Message-ID: <KdLHhfLNaVeppK_hi6UR0NnCnLapQaBFricBTkRR4yM=.21bfe892-e48f-44e9-9573-07770feb514a@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8183372

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  Implemented the review comments.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2170/files
  - new: https://git.openjdk.java.net/jdk/pull/2170/files/9517404b..cd57d8f5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=02-03

  Stats: 58 lines in 2 files changed: 6 ins; 6 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2170.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2170/head:pull/2170

PR: https://git.openjdk.java.net/jdk/pull/2170

From github.com+34924738+mahendrachhipa at openjdk.java.net  Wed Jan 27 23:06:43 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Wed, 27 Jan 2021 23:06:43 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
 [v3]
In-Reply-To: <dotXorU_ykwCOblQVPC3eNuYiBK9Oe7EBcKrV84meKQ=.09a4c388-50d3-43bb-b8c6-1628ab6f86e2@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
 <fUm4Dayv7nRXfJMPfSN2K1Q9-MAebjdGT5zMNsN_Tno=.f5968959-48ad-4b72-a811-1db0ff08b10c@github.com>
 <dotXorU_ykwCOblQVPC3eNuYiBK9Oe7EBcKrV84meKQ=.09a4c388-50d3-43bb-b8c6-1628ab6f86e2@github.com>
Message-ID: <gT6aG81NIT8WAFZLEO5wdImgAUokI2iuuB9oiqkCI6s=.6cf78b6b-58e8-479a-b33a-aeed3625b63a@github.com>

On Tue, 26 Jan 2021 22:55:32 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented the review comments.
>
> test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 126:
> 
>> 124:         Path pkg1Dir = Paths.get(SRC_DIR + "/pkg1");
>> 125:         FileUtils.deleteFileTreeWithRetry(pkg1Dir);
>> 126:     }
> 
> I'm not convinced the `@AfterClass` method is necessary.  Pre-cleanup is already done on LL94-95.  And occasionally, test-generated artifacts are helpful in post-mortem analysis.

To keep the source code repo clean from temporary generated files, these files are removed after test. Test logs have the information about the generated files for the Postmortem analysis.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2170

From github.com+34924738+mahendrachhipa at openjdk.java.net  Wed Jan 27 23:14:04 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Wed, 27 Jan 2021 23:14:04 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
 [v5]
In-Reply-To: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
Message-ID: <g1NPQdgtkFDIJtekbXsK5i2okC0wWrKv4BKV-F84HBw=.0e4cdf0f-f37e-4865-ae5b-af4796e95747@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8183372

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  Implemented review comment.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2170/files
  - new: https://git.openjdk.java.net/jdk/pull/2170/files/cd57d8f5..d8ce7caa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2170.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2170/head:pull/2170

PR: https://git.openjdk.java.net/jdk/pull/2170

From bpb at openjdk.java.net  Thu Jan 28 02:27:55 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 28 Jan 2021 02:27:55 GMT
Subject: RFR: 8247918: Clarify Reader.skip behavior for end of stream
Message-ID: <fgoDHyNsOAaD8s0Q_gNlqdWvVq62n13yVviXug76Cuk=.f7510f1e-08bf-430a-bf35-6e6bbf850a54@github.com>

Please review this clarification of the specification of the method `skip(long)` in `java.io.Reader` and its subclasses. Specifically, the behavior of the method is made clear for the case when the `Reader` is already at the end of its stream when the method is invoked. A corresponding CSR will be filed. Also, the change includes an update to an existing test in order to verify that the specification change reflects actual behavior.

-------------

Commit messages:
 - 8247918: Clarify Reader.skip behavior for end of stream

Changes: https://git.openjdk.java.net/jdk/pull/2274/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2274&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8247918
  Stats: 132 lines in 8 files changed: 62 ins; 38 del; 32 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2274.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2274/head:pull/2274

PR: https://git.openjdk.java.net/jdk/pull/2274

From david.holmes at oracle.com  Thu Jan 28 05:09:49 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 28 Jan 2021 15:09:49 +1000
Subject: RFR: 8258917: NativeMemoryTracking is handled by launcher
 inconsistenly [v2]
In-Reply-To: <BDuTUXvvGlTgmtcyD4kjUC4TgJFPCMiKZba34vafh90=.9309818e-0ba5-4dc5-a1f0-e1abe5a63bd5@github.com>
References: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
 <1ojc6R4Tkg2oSXjEb7Y2nrvb-fcoZICYVckWdkcQ3FA=.f6ad204e-ff50-4669-a17e-8bf037e0d18f@github.com>
 <9YSxbXm9PS0nI-nLOCayqUooZDOpuIz50AeuiHwGT04=.53a3951a-b5aa-4e17-804c-9588fb1ce801@github.com>
 <BDuTUXvvGlTgmtcyD4kjUC4TgJFPCMiKZba34vafh90=.9309818e-0ba5-4dc5-a1f0-e1abe5a63bd5@github.com>
Message-ID: <5e249817-fc42-dc34-8a3a-84e892fd826b@oracle.com>

Hi Alex,

On 28/01/2021 7:44 am, Alex Menkov wrote:
> On Tue, 19 Jan 2021 23:18:04 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    Non-lava launchers should process all "-J" arguments
>>
>> Hi Alex,
>>
>> I think this is functionally correct now - though the comment you added is confusing to me (see below).
>>
>> However I remain concerned that this requires processing the arg list twice for non-Java launchers. Is that a startup issue we should be concerned about?
>>
>> Thanks,
>> David
> 
> Hi David,
> 
>> You integrated this change but neither Zhengyu nor myself approved the
>> final changes. Zhengyu's Review was prior to the logic fix, and my
>> comment "this seems functionally correct" was just a comment and we were
>> still discussing the overhead aspect of this.
>>
>> David
> 
> I was sure I saw 2 approvals for the fix, but most likely I misread it and there were 2 reviewers.
> Do you have some suggestions how to handle this?

Just ask Zhengyu to add his final Review as a comment to show he is okay 
with the final result, and I'll do the same via this email. :)

> I don't think it makes sense to revert the change and re-do it from the beginning.

No.

> I think we don't need to worry about startup time impact. It's minimal and only non-java launchers are affected (AFAIR the main goal of performance/startup optimizations was java launcher).

Yes, it is our main concern. But that's not to say someone else may not 
be concerned. Any way the point was to discuss the overhead in case it 
was an issue and we're deciding we think it is not an issue so okay.

> I can file an RFE to reorder launcher logic and handle NMT in ParseArguments as I described earlier. If it's possible, this would remove one cycle (SetJvmEnvironment) for java/javaw launchers.

Please do. I don't know if anyone will look at it, but at least it 
acknowledges the current approach is not optimial.

Thanks,
David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2106
> 

From darcy at openjdk.java.net  Thu Jan 28 07:17:39 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Jan 2021 07:17:39 GMT
Subject: RFR: JDK-8257086: Clarify differences between {Float,
 Double}.equals and ==
In-Reply-To: <Qhg9J-7_l6Pk-NKrG-FFGVrkFG_beuSzrnKTBss1b6I=.9924a65a-6e9d-4110-b1df-3d7359d01d4c@github.com>
References: <sxbxBYIClZ26dmLvW8fUbnNPybVl_k16wHbBPEDx40o=.86762561-b05f-4814-a57b-e5fc02f58d8f@github.com>
 <87yS9DH4_CxvLZYSVYcw5bham03wLB0sVHQWY0nGMBk=.b6af4284-f3c7-4a1e-920b-915663fe38e6@github.com>
 <v4rFMmum40OlQjccGpbSsaVH7pK3oK1BwPSJzHqBkM4=.3b8355b9-9202-40d5-89d5-4792b56f2afb@github.com>
 <Qhg9J-7_l6Pk-NKrG-FFGVrkFG_beuSzrnKTBss1b6I=.9924a65a-6e9d-4110-b1df-3d7359d01d4c@github.com>
Message-ID: <JTBK_oK-XYFJuoM7KUZo1VPqH-_JMcWUXvEwx_oiK9o=.e46ddd17-1bdf-4efa-aa97-0f715d682c26@github.com>

On Thu, 10 Dec 2020 01:32:24 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> 
> 
> Great, let me know if you'd like me to provide some text for any particular topics in this area.

Before sending out another iteration in code, there the draft javadoc text of a discussion at the end of the class-level discussion of java.lang.Double:

 * <h2><a id=equivalenceRelation>Floating-point Equality, Equivalence,
 * and Comparison</a></h2>
 *
 * IEEE 754 floating-point values include finite nonzero values,
 * signed zeros ({@code +0.0} and {@code -0.0}), signed infinities
 * {@linkplain Double#POSITIVE_INFINITY positive infinity} and
 * {@linkplain Double#NEGATIVE_INFINITY negative infinity}), and
 * {@linkplain Double#NaN NaN} (not-a-number).
 *
 * <p>An <em>equivalence relation</em> on a set of values is a boolean
 * relation on pairs of values that is reflexive, symmetric, and
 * transitive. A set can have multiple equivalence relations defined
 * for it. For example, {@link java.util.HashMap HashMap} compares
 * keys in the set of objects using the equivalence relation of {@link
 * Object#equals Object.equals} while {@link java.util.IdentityHashMap
 * IdentityHashMap} compares keys in the set of objects using the
 * equivalence relation of reference equality.
 * 
 * <p>For floating-point values to be used in data structures like
 * sets and maps, the {@linkplain Double#equals equals} or {@linkplain
 * Double#compareTo comparison} method must satisfy the usual
 * requirements of being an equivalence relation or analogous
 * requirement for comparison methods. However, surprisingly, the
 * built-in {@code ==} operation on floating-point values does
 * <em>not</em> implement an equivalence relation. Despite not
 * defining an equivalence relation, the semantics of the IEEE 754
 * {@code ==} operator were deliberately designed to meet other needs
 * of numerical computation. There are two exceptions where the
 * properties of an equivalence relations are not satisfied by {@code
 * ==} on floating-point values:
 *
 * <ul>
 *
 * <li>If {@code v1} and {@code v2} are both NaN, then {@code v1
 * == v2} has the value {@code false}. Therefore, for two NaN
 * arguments the <em>reflexive</em> property of an equivalence
 * relation is <em>not</em> satisfied by the {@code ==} operator.
 *
 * <li>If {@code v1} represents {@code +0.0} while {@code v2}
 * represents {@code -0.0}, or vice versa, then {@code v1 == v2} has
 * the value {@code true} even though {@code +0.0} and {@code -0.0}
 * are distinguishable under various floating-point operations. For
 * example, {@code 1.0/+0.0} evaluates to positive infinity while
 * {@code 1.0/-0.0} evaluates to <em>negative</em> infinity and
 * positive infinity and negative infinity are neither equal to each
 * other nor equivalent to each other.
 *
 * </ul>
 *
 * <p>For ordered comparisons using the built-in comparison operator
 * ({@code <}, {@code <=}, etc.), NaN values have another anomalous
 * situation: a NaN is neither less than, greater than, nor equal to
 * any value, including itself. This means the <em>trichotomy of
 * comparison</em> does <em>not</em> hold.
 * 
 * <p>To provide the appropriate semantics for {@code equals} and {@code
 * compareTo} methods, those methods cannot simply to wrappers around
 * {@code ==} or ordered comparison operations. Instead, {@link
 * Double#equals equals} defines NaN arguments to be equal to each
 * other and defines {@code +0.0} to <em>not</em> be equal to {@code
 * -0.0}, restoring reflexivity. For comparisons, {@link
 * Double#compareTo compareTo} defines a total order where {@code
 * -0.0} is less than {@code +0.0} and where a NaN is equal to itself
 * and considered greater than positive infinity.
 *
 * <p>The operational semantics of {@code equals} and {@code
 * compareTo} are expressed in terms of {@linkplain doubleToLongBigs
 * bit-wise converting} the floating-point values to integral values 
 *
 * <p>The <em>natural ordering</em> implemented by {@link compareTo
 * compareTo} is {@linkplain Comparable consistent with equals}; that
 * is values are only reported as equal by {@code equals} if {@code
 * compareTo} on those objects returns zero.
 *
 * @jls 4.2.3 Floating-Point Types, Formats, and Values
 * @jls 4.2.4. Floating-Point Operations
 * @jls 15.21.1 Numerical Equality Operators == and !=

Comments?

Thanks,

-------------

PR: https://git.openjdk.java.net/jdk/pull/1699

From redestad at openjdk.java.net  Thu Jan 28 11:16:40 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 28 Jan 2021 11:16:40 GMT
Subject: RFR: 8260506: VersionHelper cleanup
In-Reply-To: <Fg97GGrQnJOoyC30DC33Vm7GDYfcUPrvbdE_t_P8idI=.d17b8a60-0059-43a5-9af2-36ab394dc265@github.com>
References: <st0l6YCTXoUp_arTlgqzHG3uvsUrEcjuzPc6sVXu7dg=.e7451f2b-f670-48a8-8a0d-3b6ee6cf8e09@github.com>
 <Fg97GGrQnJOoyC30DC33Vm7GDYfcUPrvbdE_t_P8idI=.d17b8a60-0059-43a5-9af2-36ab394dc265@github.com>
Message-ID: <wjYIZ5DQDLg8uHMWyiiR6-yvn8ReIN9Gajy4Q-HHLNc=.ccda0930-6385-4dc3-add6-aab942b92934@github.com>

On Wed, 27 Jan 2021 15:32:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Some small modernizations and cleanups that ultimately help startup of apps using JNDI/InitialContext
>
> Marked as reviewed by alanb (Reviewer).

@AlanBateman @dfuch @AlekseiEfimov - thanks for reviewing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2259

From redestad at openjdk.java.net  Thu Jan 28 11:16:42 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 28 Jan 2021 11:16:42 GMT
Subject: Integrated: 8260506: VersionHelper cleanup
In-Reply-To: <st0l6YCTXoUp_arTlgqzHG3uvsUrEcjuzPc6sVXu7dg=.e7451f2b-f670-48a8-8a0d-3b6ee6cf8e09@github.com>
References: <st0l6YCTXoUp_arTlgqzHG3uvsUrEcjuzPc6sVXu7dg=.e7451f2b-f670-48a8-8a0d-3b6ee6cf8e09@github.com>
Message-ID: <ND5dN_KGfpWLnnaks7eoYNTAzXqYQ6Kqu3A0tt_pcqU=.a5435e58-0167-4d03-b05e-ec97c339d99f@github.com>

On Wed, 27 Jan 2021 12:15:43 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Some small modernizations and cleanups that ultimately help startup of apps using JNDI/InitialContext

This pull request has now been integrated.

Changeset: ecde52ec
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ecde52ec
Stats:     30 lines in 1 file changed: 2 ins; 16 del; 12 mod

8260506: VersionHelper cleanup

Reviewed-by: alanb, dfuchs, aefimov

-------------

PR: https://git.openjdk.java.net/jdk/pull/2259

From jvernee at openjdk.java.net  Thu Jan 28 12:29:42 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 28 Jan 2021 12:29:42 GMT
Subject: Integrated: 8255531: MethodHandles::permuteArguments throws NPE when
 duplicating dropped arguments
In-Reply-To: <jjesjsHhraVtdE1gJGmOtJmO0Q-ICo5NhoLSWVA4RHg=.4d60e3b6-7d23-4a1b-8f34-b3fdb2329617@github.com>
References: <jjesjsHhraVtdE1gJGmOtJmO0Q-ICo5NhoLSWVA4RHg=.4d60e3b6-7d23-4a1b-8f34-b3fdb2329617@github.com>
Message-ID: <JghHb58VBmExEkrDV8H7wb9cBbcGFUv5m83WPNLVj4s=.9be6e240-919c-452a-854f-0c71dc18338d@github.com>

On Tue, 12 Jan 2021 16:58:45 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi,
> 
> This small patch fixes the NPE in the following case:
> 
>     MethodHandle mh = MethodHandles.empty(MethodType.methodType(void.class, int.class, int.class));
>     MethodHandles.permuteArguments(mh, MethodType.methodType(void.class, int.class), 0, 0);
>     
> If a parameter name was changed by a lambda form edit, `LambdaForm::endEdit` will try to sort the names that fall into the old range of parameter names (starting from `firstChanged` and up to `arity` in the code) to make sure that non-parameter names (`exprs`) properly appear after parameter names. But, if a parameter was dropped, and there are no non-paramter names, a `null` will fall into the range that is being sorted, and the call to `name.isParam()` in the sorting algorithm will result in an NPE.
> 
> We can just add a `name != null` check there, since `null` is definitely not a parameter. However, we still need to do the loop in order to get an accurate `exprp` value, which is later used to adjust the `arity` after sorting (there are other ways to get there that don't involve copying the extra `null`, but they are more convoluted, so I elected to go for this solution).
> 
> Thanks,
> Jorn
> 
> Testing: tier1-tier2

This pull request has now been integrated.

Changeset: d07af2b8
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d07af2b8
Stats:     9 lines in 2 files changed: 8 ins; 0 del; 1 mod

8255531: MethodHandles::permuteArguments throws NPE when duplicating dropped arguments

Reviewed-by: redestad

-------------

PR: https://git.openjdk.java.net/jdk/pull/2054

From sgehwolf at openjdk.java.net  Thu Jan 28 13:46:40 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 28 Jan 2021 13:46:40 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection
In-Reply-To: <Mat51HIuUYISDvMtuz4R7LJ2R1aBeGASWCyBWAXFlAI=.f3329041-9c29-4b4b-ba66-163233764fb9@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
 <Ynmw17EfEzNeUK5w2ABmHkXqqXo98GTcYTnZFGoAYIk=.1079ee11-c9e7-443f-b74b-d94838206a2a@github.com>
 <eFFokFwfdmu0YTyAhvPJ7xBFo0ypjHw3MyC_9-aTS6g=.80ad5876-3ae3-4ca3-96b5-08db53ed6627@github.com>
 <COWzygAauFzmvgYYP6DVjIg0MH6EDyIMx0ZzeTRHol0=.8a01079b-6e40-4b1b-bb75-e693f89d8871@github.com>
 <iT7Ltrm52E9skv98tAKIYPB1ZCaXw8ep-YSegjEnhxc=.68635047-f51c-4c60-9731-0da103e56a39@github.com>
 <m1iurC4l1M904NY7lj5eVIB8jgCfBLR2sh8XrQzhJUM=.c2c5c01f-c29a-4b22-922b-e56472e951ec@github.com>
 <Mat51HIuUYISDvMtuz4R7LJ2R1aBeGASWCyBWAXFlAI=.f3329041-9c29-4b4b-ba66-163233764fb9@github.com>
Message-ID: <11sbHrCz8oo_V4p6dgJTr3MAY64Z3e1pMfaB063K28o=.55ec61ed-be40-4485-b2f4-7e8ed893550c@github.com>

On Tue, 12 Jan 2021 14:29:28 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Ping? Anyone?
>
> Anybody willing to review this?

PING?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1393

From zgu at openjdk.java.net  Thu Jan 28 13:47:41 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 28 Jan 2021 13:47:41 GMT
Subject: RFR: 8258917: NativeMemoryTracking is handled by launcher
 inconsistenly [v3]
In-Reply-To: <Bs9EErmySj3EJ0myZdK55gJCEPorfMJIPwUCm-vhhyE=.8afc2742-b240-4eea-8ec1-9d44e7ae6e6f@github.com>
References: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
 <Bs9EErmySj3EJ0myZdK55gJCEPorfMJIPwUCm-vhhyE=.8afc2742-b240-4eea-8ec1-9d44e7ae6e6f@github.com>
Message-ID: <wg1g-bvGzVKDbQA2U0GHPGUoenGKMG6-uOSYP-WY_AM=.16384490-cc55-4854-bd7a-cf0cbea75e49@github.com>

On Wed, 20 Jan 2021 01:47:54 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix adds NMT handling for non-java launchers
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated comment

Sorry, I overlooked some of details. Final change looks fine to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2106

From herrick at openjdk.java.net  Thu Jan 28 14:01:53 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 28 Jan 2021 14:01:53 GMT
Subject: RFR: JDK-8260335: [macos] Running app using relative path causes
 problems
Message-ID: <UErEM5Ylr_Pj7-K3OIGsaYawwGdgB1BX5I01RA-oyqw=.89fdab22-6a37-4a06-9daa-f833691209ed@github.com>

Fixing FileUtils.dirname() to skip over "/.".

-------------

Commit messages:
 - JDK-8260335: [macos] Running app using relative path causes problems on MacOS

Changes: https://git.openjdk.java.net/jdk/pull/2260/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2260&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260335
  Stats: 10 lines in 1 file changed: 8 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2260.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2260/head:pull/2260

PR: https://git.openjdk.java.net/jdk/pull/2260

From shade at openjdk.java.net  Thu Jan 28 14:38:53 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 28 Jan 2021 14:38:53 GMT
Subject: RFR: 8260592: jpackage tests fail when Desktop is not supported
Message-ID: <LxoXmxOCVkAxOpxADonAZaGzooDXIrqi1eBEe9eu-h0=.dfebfe41-279d-45ba-ab14-4e6b4f52a266@github.com>

If you run x86 configuration (cross-compiled on x86_64), then many tests would fail with:

$ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/jpackage
...
can not load libgnomevfs-2.so
Exception in thread "main" java.lang.ExceptionInInitializerError
Caused by: java.lang.UnsupportedOperationException: Desktop API is not supported on the current platform
at java.desktop/java.awt.Desktop.getDesktop(Unknown Source)
at com.that/com.that.main.Florence.createInstance(Unknown Source)
at com.that/com.that.main.Florence.<clinit>(Unknown Source)
Failed to launch JVM
java.lang.AssertionError: Expected [0]. Actual [1]: Check command [/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_jdk_tools_jpackage/scratch/10/./testMainLauncherIsModular.ed4f638d/output/MainLauncherIsModularAddLauncherTest/bin/ModularAppLauncher](1) exited with 0 code

The tests probably need to check `Desktop.isDesktopSupported()`, similarly how they check `GraphicsEnvironment.isHeadless()`.

Additional testing:
 - [x] Linux x86_32 `tools/jpackage` (now pass)
 - [x] Linux x86_64 `tools/jpackage` (still pass)

-------------

Commit messages:
 - 8260592: jpackage tests fail when Desktop is not supported

Changes: https://git.openjdk.java.net/jdk/pull/2291/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2291&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260592
  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2291.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2291/head:pull/2291

PR: https://git.openjdk.java.net/jdk/pull/2291

From sgehwolf at openjdk.java.net  Thu Jan 28 14:39:43 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 28 Jan 2021 14:39:43 GMT
Subject: RFR: 8257746: Regression introduced with JDK-8250984 - memory
 might be null in some machines
In-Reply-To: <Fy288IpbsbT1qiVcV5yF950k_6guA5BcW1bdolDeCmQ=.2518cad3-5efb-4643-95c6-8cc6d0e2c6a5@github.com>
References: <Fy288IpbsbT1qiVcV5yF950k_6guA5BcW1bdolDeCmQ=.2518cad3-5efb-4643-95c6-8cc6d0e2c6a5@github.com>
Message-ID: <agRjIE7nfmoIoNsd3dXVHr3UEFjaogrJdFl9Pj0Oo7w=.2064ecab-89d7-418c-bf50-b231c26b4e14@github.com>

On Wed, 27 Jan 2021 21:10:16 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> Please review this simple change that adds null checks for memory in CgroupV1Subsystem.java.
> 
> Problem: After the backport of JDK-8250984,  there are places where memory.isSwapEnabled() is called. For example:
> 
>     public long getMemoryAndSwapFailCount() {
>         if (!memory.isSwapEnabled()) {
>             return getMemoryFailCount();
>         }
>         return SubSystem.getLongValue(memory, "memory.memsw.failcnt");
>     }
>  
> But memory could be Null on some machines that have cgroup entries for CPU but not for memory. This would cause a NullPointerException when memory is accessed.
> 
> Fix: Add null checks for memory.

I'm curious: What config is this to actually trigger the NPE? How does `/proc/self/mountinfo`, `/proc/self/cgroup` and `/proc/cgroups` look like?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2269

From hseigel at openjdk.java.net  Thu Jan 28 14:49:39 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 28 Jan 2021 14:49:39 GMT
Subject: RFR: 8257746: Regression introduced with JDK-8250984 - memory
 might be null in some machines
In-Reply-To: <Fy288IpbsbT1qiVcV5yF950k_6guA5BcW1bdolDeCmQ=.2518cad3-5efb-4643-95c6-8cc6d0e2c6a5@github.com>
References: <Fy288IpbsbT1qiVcV5yF950k_6guA5BcW1bdolDeCmQ=.2518cad3-5efb-4643-95c6-8cc6d0e2c6a5@github.com>
Message-ID: <_CcSq09bQp2dOnV_eqbVDN3BpDuHAU4iwe_3EBihEao=.6310c732-0525-4dae-a985-450cf808ccd5@github.com>

On Wed, 27 Jan 2021 21:10:16 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> Please review this simple change that adds null checks for memory in CgroupV1Subsystem.java.
> 
> Problem: After the backport of JDK-8250984,  there are places where memory.isSwapEnabled() is called. For example:
> 
>     public long getMemoryAndSwapFailCount() {
>         if (!memory.isSwapEnabled()) {
>             return getMemoryFailCount();
>         }
>         return SubSystem.getLongValue(memory, "memory.memsw.failcnt");
>     }
>  
> But memory could be Null on some machines that have cgroup entries for CPU but not for memory. This would cause a NullPointerException when memory is accessed.
> 
> Fix: Add null checks for memory.

Changes look good!  Thanks for doing this.

Harold

-------------

Marked as reviewed by hseigel (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2269

From poonam at openjdk.java.net  Thu Jan 28 15:03:40 2021
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Thu, 28 Jan 2021 15:03:40 GMT
Subject: RFR: 8257746: Regression introduced with JDK-8250984 - memory
 might be null in some machines
In-Reply-To: <agRjIE7nfmoIoNsd3dXVHr3UEFjaogrJdFl9Pj0Oo7w=.2064ecab-89d7-418c-bf50-b231c26b4e14@github.com>
References: <Fy288IpbsbT1qiVcV5yF950k_6guA5BcW1bdolDeCmQ=.2518cad3-5efb-4643-95c6-8cc6d0e2c6a5@github.com>
 <agRjIE7nfmoIoNsd3dXVHr3UEFjaogrJdFl9Pj0Oo7w=.2064ecab-89d7-418c-bf50-b231c26b4e14@github.com>
Message-ID: <hEQ6zxOY0ulqGcvHgypW8L2-vHWPD0nGp_BItdbZmwo=.8ff7ec90-3ee6-462c-86ea-a0d9e28d92df@github.com>

On Thu, 28 Jan 2021 14:36:36 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> I'm curious: What config is this to actually trigger the NPE? How does `/proc/self/mountinfo`, `/proc/self/cgroup` and `/proc/cgroups` look like?

I don't have access to the config. The issue was reported by a customer.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2269

From poonam at openjdk.java.net  Thu Jan 28 15:10:43 2021
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Thu, 28 Jan 2021 15:10:43 GMT
Subject: Integrated: 8257746: Regression introduced with JDK-8250984 - memory
 might be null in some machines
In-Reply-To: <Fy288IpbsbT1qiVcV5yF950k_6guA5BcW1bdolDeCmQ=.2518cad3-5efb-4643-95c6-8cc6d0e2c6a5@github.com>
References: <Fy288IpbsbT1qiVcV5yF950k_6guA5BcW1bdolDeCmQ=.2518cad3-5efb-4643-95c6-8cc6d0e2c6a5@github.com>
Message-ID: <K-jio7AfC-gsd-89yzQU23o8zyn70VJB51KPtHREjMc=.8c280ee7-2c93-484c-afe4-2f6c591a64e3@github.com>

On Wed, 27 Jan 2021 21:10:16 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> Please review this simple change that adds null checks for memory in CgroupV1Subsystem.java.
> 
> Problem: After the backport of JDK-8250984,  there are places where memory.isSwapEnabled() is called. For example:
> 
>     public long getMemoryAndSwapFailCount() {
>         if (!memory.isSwapEnabled()) {
>             return getMemoryFailCount();
>         }
>         return SubSystem.getLongValue(memory, "memory.memsw.failcnt");
>     }
>  
> But memory could be Null on some machines that have cgroup entries for CPU but not for memory. This would cause a NullPointerException when memory is accessed.
> 
> Fix: Add null checks for memory.

This pull request has now been integrated.

Changeset: abc4300d
Author:    Poonam Bajaj <poonam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/abc4300d
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8257746: Regression introduced with JDK-8250984 - memory might be null in some machines

Reviewed-by: hseigel

-------------

PR: https://git.openjdk.java.net/jdk/pull/2269

From sgehwolf at openjdk.java.net  Thu Jan 28 16:03:43 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 28 Jan 2021 16:03:43 GMT
Subject: RFR: 8257746: Regression introduced with JDK-8250984 - memory
 might be null in some machines
In-Reply-To: <hEQ6zxOY0ulqGcvHgypW8L2-vHWPD0nGp_BItdbZmwo=.8ff7ec90-3ee6-462c-86ea-a0d9e28d92df@github.com>
References: <Fy288IpbsbT1qiVcV5yF950k_6guA5BcW1bdolDeCmQ=.2518cad3-5efb-4643-95c6-8cc6d0e2c6a5@github.com>
 <agRjIE7nfmoIoNsd3dXVHr3UEFjaogrJdFl9Pj0Oo7w=.2064ecab-89d7-418c-bf50-b231c26b4e14@github.com>
 <hEQ6zxOY0ulqGcvHgypW8L2-vHWPD0nGp_BItdbZmwo=.8ff7ec90-3ee6-462c-86ea-a0d9e28d92df@github.com>
Message-ID: <CPC85t6FMv51Vd0nCDcNNW_XlDXfW5mX_QOBe7ExpB4=.e5cfbf2e-1a79-4f75-adf8-c30097038ba9@github.com>

On Thu, 28 Jan 2021 15:01:11 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

>> I'm curious: What config is this to actually trigger the NPE? How does `/proc/self/mountinfo`, `/proc/self/cgroup` and `/proc/cgroups` look like?
>
>> I'm curious: What config is this to actually trigger the NPE? How does `/proc/self/mountinfo`, `/proc/self/cgroup` and `/proc/cgroups` look like?
> 
> I don't have access to the config. The issue was reported by a customer.

> I'm curious: What config is this to actually trigger the NPE? How does `/proc/self/mountinfo`, `/proc/self/cgroup` and `/proc/cgroups` look like?



> > I'm curious: What config is this to actually trigger the NPE? How does `/proc/self/mountinfo`, `/proc/self/cgroup` and `/proc/cgroups` look like?
> 
> I don't have access to the config. The issue was reported by a customer.

This isn't very satisfying, though. How can we be sure this issue isn't also present in the cgroup v2 code? Has this been tested? Surely, there was some stack trace reported by the customer or some sort of reproducer got provided. What was the reasoning that established this issue is present in JDK head and **only** in cgroups v1 code? My guess is that the issue got triggered via the OperatingSystemMXBean, but nothing to that effect has been noted here or in the bug.

If I were to propose such a point fix, clearly, I'd have to provide some details what the actual problem is and explain why the fix is sufficient and covers all branches. All that got provided is: "But memory could be Null on some machines that have cgroup entries for CPU but not for memory."

-------------

PR: https://git.openjdk.java.net/jdk/pull/2269

From weijun at openjdk.java.net  Thu Jan 28 16:24:51 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 28 Jan 2021 16:24:51 GMT
Subject: RFR: 8260596: Comment cleanup in BigInteger
Message-ID: <dg6Hvx4agLNkIbE_uqyysugGEo3I_VjMPn8tvJN_e3A=.9bb46c65-6517-4372-81f0-eb75823d311a@github.com>

Fix some small errors.

-------------

Commit messages:
 - 8260596: Comment cleanup in BigInteger

Changes: https://git.openjdk.java.net/jdk/pull/2292/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2292&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260596
  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2292/head:pull/2292

PR: https://git.openjdk.java.net/jdk/pull/2292

From bpb at openjdk.java.net  Thu Jan 28 16:46:43 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 28 Jan 2021 16:46:43 GMT
Subject: RFR: 8260596: Comment cleanup in BigInteger
In-Reply-To: <dg6Hvx4agLNkIbE_uqyysugGEo3I_VjMPn8tvJN_e3A=.9bb46c65-6517-4372-81f0-eb75823d311a@github.com>
References: <dg6Hvx4agLNkIbE_uqyysugGEo3I_VjMPn8tvJN_e3A=.9bb46c65-6517-4372-81f0-eb75823d311a@github.com>
Message-ID: <qC8HwpSnW-HdfxFU6Ie0jbju1og6LsJBOt8ASeb3tSQ=.cba39b5f-a9d1-48cd-8a8f-3d726ddd04b4@github.com>

On Thu, 28 Jan 2021 16:19:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Fix some small errors.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2292

From poonam at openjdk.java.net  Thu Jan 28 17:22:40 2021
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Thu, 28 Jan 2021 17:22:40 GMT
Subject: RFR: 8257746: Regression introduced with JDK-8250984 - memory
 might be null in some machines
In-Reply-To: <CPC85t6FMv51Vd0nCDcNNW_XlDXfW5mX_QOBe7ExpB4=.e5cfbf2e-1a79-4f75-adf8-c30097038ba9@github.com>
References: <Fy288IpbsbT1qiVcV5yF950k_6guA5BcW1bdolDeCmQ=.2518cad3-5efb-4643-95c6-8cc6d0e2c6a5@github.com>
 <agRjIE7nfmoIoNsd3dXVHr3UEFjaogrJdFl9Pj0Oo7w=.2064ecab-89d7-418c-bf50-b231c26b4e14@github.com>
 <hEQ6zxOY0ulqGcvHgypW8L2-vHWPD0nGp_BItdbZmwo=.8ff7ec90-3ee6-462c-86ea-a0d9e28d92df@github.com>
 <CPC85t6FMv51Vd0nCDcNNW_XlDXfW5mX_QOBe7ExpB4=.e5cfbf2e-1a79-4f75-adf8-c30097038ba9@github.com>
Message-ID: <BOuwrCxLyMc_RjSLqTlD_ivXyV1ad9V1Eh2K7HyWj1Y=.8f44aa38-9d50-4ba6-b5df-4eba40f8a166@github.com>

On Thu, 28 Jan 2021 16:00:36 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > I'm curious: What config is this to actually trigger the NPE? How does `/proc/self/mountinfo`, `/proc/self/cgroup` and `/proc/cgroups` look like?
> 
> > > I'm curious: What config is this to actually trigger the NPE? How does `/proc/self/mountinfo`, `/proc/self/cgroup` and `/proc/cgroups` look like?
> > 
> > 
> > I don't have access to the config. The issue was reported by a customer.
> 
> This isn't very satisfying, though. How can we be sure this issue isn't also present in the cgroup v2 code? Has this been tested? Surely, there was some stack trace reported by the customer or some sort of reproducer got provided. What was the reasoning that established this issue is present in JDK head and **only** in cgroups v1 code? My guess is that the issue got triggered via the OperatingSystemMXBean, but nothing to that effect has been noted here or in the bug.
> 
> If I were to propose such a point fix, clearly, I'd have to provide some details what the actual problem is and explain why the fix is sufficient and covers all branches. All that got provided is: "But memory could be Null on some machines that have cgroup entries for CPU but not for memory."

I can check with the customer if they could share their config. 

The cgroups v2 code was thoroughly examined and this problem does not exist in that code. cgroups v2 does not have a separate MemorySubSystemController as we have for c1 cgroups. 

An instance of the CgroupV1MemorySubSystemController is stored as a member in CgroupV1Subsystem.

    private CgroupV1MemorySubSystemController memory;

    private void setMemorySubSystem(CgroupV1MemorySubSystemController memory) {
          this.memory = memory;
    }

This memory instance variable could stay null if "memory" entry is not found while creating sub-system objects in createSubSystemController(). 

               case "memory":
                      subsystem.setMemorySubSystem(new CgroupV1MemorySubSystemController(mountentry[3], mountentry[4]));
                      break;

This fix ensure that the memory instance is not null before invoking any method on it.

Such problem does not exist in cgroups v2 code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2269

From weijun at openjdk.java.net  Thu Jan 28 17:57:43 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 28 Jan 2021 17:57:43 GMT
Subject: Integrated: 8260596: Comment cleanup in BigInteger
In-Reply-To: <dg6Hvx4agLNkIbE_uqyysugGEo3I_VjMPn8tvJN_e3A=.9bb46c65-6517-4372-81f0-eb75823d311a@github.com>
References: <dg6Hvx4agLNkIbE_uqyysugGEo3I_VjMPn8tvJN_e3A=.9bb46c65-6517-4372-81f0-eb75823d311a@github.com>
Message-ID: <ZaMg6y2K3fEKbHOIBywpHQXAIAlOZDhiLNkYqR4Ydd4=.e32fdd5d-4a84-42a3-a805-b16cb77c7754@github.com>

On Thu, 28 Jan 2021 16:19:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Fix some small errors.

This pull request has now been integrated.

Changeset: 2b166d81
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2b166d81
Stats:     5 lines in 1 file changed: 0 ins; 0 del; 5 mod

8260596: Comment cleanup in BigInteger

Reviewed-by: bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/2292

From sgehwolf at openjdk.java.net  Thu Jan 28 18:08:41 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 28 Jan 2021 18:08:41 GMT
Subject: RFR: 8257746: Regression introduced with JDK-8250984 - memory
 might be null in some machines
In-Reply-To: <BOuwrCxLyMc_RjSLqTlD_ivXyV1ad9V1Eh2K7HyWj1Y=.8f44aa38-9d50-4ba6-b5df-4eba40f8a166@github.com>
References: <Fy288IpbsbT1qiVcV5yF950k_6guA5BcW1bdolDeCmQ=.2518cad3-5efb-4643-95c6-8cc6d0e2c6a5@github.com>
 <agRjIE7nfmoIoNsd3dXVHr3UEFjaogrJdFl9Pj0Oo7w=.2064ecab-89d7-418c-bf50-b231c26b4e14@github.com>
 <hEQ6zxOY0ulqGcvHgypW8L2-vHWPD0nGp_BItdbZmwo=.8ff7ec90-3ee6-462c-86ea-a0d9e28d92df@github.com>
 <CPC85t6FMv51Vd0nCDcNNW_XlDXfW5mX_QOBe7ExpB4=.e5cfbf2e-1a79-4f75-adf8-c30097038ba9@github.com>
 <BOuwrCxLyMc_RjSLqTlD_ivXyV1ad9V1Eh2K7HyWj1Y=.8f44aa38-9d50-4ba6-b5df-4eba40f8a166@github.com>
Message-ID: <YOK0NkRAuIDG2SYCFwi0YjL87sZNnrjMnXDTDeYll9M=.c0cbeda9-a8ca-4b1f-9794-badb6b7a5bf5@github.com>

On Thu, 28 Jan 2021 17:19:53 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> > > I'm curious: What config is this to actually trigger the NPE? How does `/proc/self/mountinfo`, `/proc/self/cgroup` and `/proc/cgroups` look like?
> > 
> > 
> > > > I'm curious: What config is this to actually trigger the NPE? How does `/proc/self/mountinfo`, `/proc/self/cgroup` and `/proc/cgroups` look like?
> > > 
> > > 
> > > I don't have access to the config. The issue was reported by a customer.
> > 
> > 
> > This isn't very satisfying, though. How can we be sure this issue isn't also present in the cgroup v2 code? Has this been tested? Surely, there was some stack trace reported by the customer or some sort of reproducer got provided. What was the reasoning that established this issue is present in JDK head and **only** in cgroups v1 code? My guess is that the issue got triggered via the OperatingSystemMXBean, but nothing to that effect has been noted here or in the bug.
> > If I were to propose such a point fix, clearly, I'd have to provide some details what the actual problem is and explain why the fix is sufficient and covers all branches. All that got provided is: "But memory could be Null on some machines that have cgroup entries for CPU but not for memory."
> 
> I can check with the customer if they could share their config.

That would be helpful. A stack trace of the NPE would be good too.

> The cgroups v2 code was thoroughly examined and this problem does not exist in that code. cgroups v2 does not have a separate MemorySubSystemController as we have for c1 cgroups.
> 
> An instance of the CgroupV1MemorySubSystemController is stored as a member in CgroupV1Subsystem.
> 
> ```
> private CgroupV1MemorySubSystemController memory;
> 
> private void setMemorySubSystem(CgroupV1MemorySubSystemController memory) {
>       this.memory = memory;
> }
> ```
> 
> This memory instance variable could stay null if "memory" entry is not found while creating sub-system objects in createSubSystemController().
> 
> ```
>            case "memory":
>                   subsystem.setMemorySubSystem(new CgroupV1MemorySubSystemController(mountentry[3], mountentry[4]));
>                   break;
> ```
> 
> This fix ensure that the memory instance is not null before invoking any method on it.
> 
> Such problem does not exist in cgroups v2 code.

Right, but is this reasoning sound? Without knowing the code path triggering the problem **and** knowing something about the config can we really say? Depending on the config it might fail in some very different way on cgroups v2!

On the other hand, knowing the config, might allow us to conclude it's an impossible config on cgroups v2 and we are done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2269

From martin at openjdk.java.net  Thu Jan 28 18:09:44 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Thu, 28 Jan 2021 18:09:44 GMT
Subject: Integrated: 8260461: Modernize jsr166 tck tests
In-Reply-To: <OBrb6EJRDv2ILtRc4akmS1K5t6lC1Q3o5XmvqCNmKHM=.e15f8410-75ab-4f5e-b1ea-4551cf41f9a1@github.com>
References: <OBrb6EJRDv2ILtRc4akmS1K5t6lC1Q3o5XmvqCNmKHM=.e15f8410-75ab-4f5e-b1ea-4551cf41f9a1@github.com>
Message-ID: <jzIdQYcPWrF6zkWmcKuKRz0hDSRx02atVn1Z4UF2ez0=.e3ec2f38-eb71-407c-881e-11b44eee8886@github.com>

On Tue, 26 Jan 2021 21:23:25 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> 8260461: Modernize jsr166 tck tests

This pull request has now been integrated.

Changeset: 81e9e6a7
Author:    Martin Buchholz <martin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/81e9e6a7
Stats:     7616 lines in 71 files changed: 318 ins; 187 del; 7111 mod

8260461: Modernize jsr166 tck tests

Reviewed-by: dl

-------------

PR: https://git.openjdk.java.net/jdk/pull/2245

From ecki at zusammenkunft.net  Thu Jan 28 19:16:47 2021
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 28 Jan 2021 19:16:47 +0000
Subject: RFR: JDK-8257086: Clarify differences between {Float,
 Double}.equals and ==
In-Reply-To: <JTBK_oK-XYFJuoM7KUZo1VPqH-_JMcWUXvEwx_oiK9o=.e46ddd17-1bdf-4efa-aa97-0f715d682c26@github.com>
References: <sxbxBYIClZ26dmLvW8fUbnNPybVl_k16wHbBPEDx40o=.86762561-b05f-4814-a57b-e5fc02f58d8f@github.com>
 <87yS9DH4_CxvLZYSVYcw5bham03wLB0sVHQWY0nGMBk=.b6af4284-f3c7-4a1e-920b-915663fe38e6@github.com>
 <v4rFMmum40OlQjccGpbSsaVH7pK3oK1BwPSJzHqBkM4=.3b8355b9-9202-40d5-89d5-4792b56f2afb@github.com>
 <Qhg9J-7_l6Pk-NKrG-FFGVrkFG_beuSzrnKTBss1b6I=.9924a65a-6e9d-4110-b1df-3d7359d01d4c@github.com>,
 <JTBK_oK-XYFJuoM7KUZo1VPqH-_JMcWUXvEwx_oiK9o=.e46ddd17-1bdf-4efa-aa97-0f715d682c26@github.com>
Message-ID: <AM0PR03MB414541A8A78E365AFFFA6954FFBA9@AM0PR03MB4145.eurprd03.prod.outlook.com>

I like the text it?s good to mix object and value identities. I would only miss unequal behavior of NaN in the description.

Gruss
Bernd


--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von Joe Darcy <darcy at openjdk.java.net>
Gesendet: Thursday, January 28, 2021 8:17:39 AM
An: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>
Betreff: Re: RFR: JDK-8257086: Clarify differences between {Float, Double}.equals and ==

On Thu, 10 Dec 2020 01:32:24 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>
>
> Great, let me know if you'd like me to provide some text for any particular topics in this area.

Before sending out another iteration in code, there the draft javadoc text of a discussion at the end of the class-level discussion of java.lang.Double:

 * <h2><a id=equivalenceRelation>Floating-point Equality, Equivalence,
 * and Comparison</a></h2>
 *
 * IEEE 754 floating-point values include finite nonzero values,
 * signed zeros ({@code +0.0} and {@code -0.0}), signed infinities
 * {@linkplain Double#POSITIVE_INFINITY positive infinity} and
 * {@linkplain Double#NEGATIVE_INFINITY negative infinity}), and
 * {@linkplain Double#NaN NaN} (not-a-number).
 *
 * <p>An <em>equivalence relation</em> on a set of values is a boolean
 * relation on pairs of values that is reflexive, symmetric, and
 * transitive. A set can have multiple equivalence relations defined
 * for it. For example, {@link java.util.HashMap HashMap} compares
 * keys in the set of objects using the equivalence relation of {@link
 * Object#equals Object.equals} while {@link java.util.IdentityHashMap
 * IdentityHashMap} compares keys in the set of objects using the
 * equivalence relation of reference equality.
 *
 * <p>For floating-point values to be used in data structures like
 * sets and maps, the {@linkplain Double#equals equals} or {@linkplain
 * Double#compareTo comparison} method must satisfy the usual
 * requirements of being an equivalence relation or analogous
 * requirement for comparison methods. However, surprisingly, the
 * built-in {@code ==} operation on floating-point values does
 * <em>not</em> implement an equivalence relation. Despite not
 * defining an equivalence relation, the semantics of the IEEE 754
 * {@code ==} operator were deliberately designed to meet other needs
 * of numerical computation. There are two exceptions where the
 * properties of an equivalence relations are not satisfied by {@code
 * ==} on floating-point values:
 *
 * <ul>
 *
 * <li>If {@code v1} and {@code v2} are both NaN, then {@code v1
 * == v2} has the value {@code false}. Therefore, for two NaN
 * arguments the <em>reflexive</em> property of an equivalence
 * relation is <em>not</em> satisfied by the {@code ==} operator.
 *
 * <li>If {@code v1} represents {@code +0.0} while {@code v2}
 * represents {@code -0.0}, or vice versa, then {@code v1 == v2} has
 * the value {@code true} even though {@code +0.0} and {@code -0.0}
 * are distinguishable under various floating-point operations. For
 * example, {@code 1.0/+0.0} evaluates to positive infinity while
 * {@code 1.0/-0.0} evaluates to <em>negative</em> infinity and
 * positive infinity and negative infinity are neither equal to each
 * other nor equivalent to each other.
 *
 * </ul>
 *
 * <p>For ordered comparisons using the built-in comparison operator
 * ({@code <}, {@code <=}, etc.), NaN values have another anomalous
 * situation: a NaN is neither less than, greater than, nor equal to
 * any value, including itself. This means the <em>trichotomy of
 * comparison</em> does <em>not</em> hold.
 *
 * <p>To provide the appropriate semantics for {@code equals} and {@code
 * compareTo} methods, those methods cannot simply to wrappers around
 * {@code ==} or ordered comparison operations. Instead, {@link
 * Double#equals equals} defines NaN arguments to be equal to each
 * other and defines {@code +0.0} to <em>not</em> be equal to {@code
 * -0.0}, restoring reflexivity. For comparisons, {@link
 * Double#compareTo compareTo} defines a total order where {@code
 * -0.0} is less than {@code +0.0} and where a NaN is equal to itself
 * and considered greater than positive infinity.
 *
 * <p>The operational semantics of {@code equals} and {@code
 * compareTo} are expressed in terms of {@linkplain doubleToLongBigs
 * bit-wise converting} the floating-point values to integral values
 *
 * <p>The <em>natural ordering</em> implemented by {@link compareTo
 * compareTo} is {@linkplain Comparable consistent with equals}; that
 * is values are only reported as equal by {@code equals} if {@code
 * compareTo} on those objects returns zero.
 *
 * @jls 4.2.3 Floating-Point Types, Formats, and Values
 * @jls 4.2.4. Floating-Point Operations
 * @jls 15.21.1 Numerical Equality Operators == and !=

Comments?

Thanks,

-------------

PR: https://git.openjdk.java.net/jdk/pull/1699

From redestad at openjdk.java.net  Thu Jan 28 19:26:47 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 28 Jan 2021 19:26:47 GMT
Subject: RFR: 8260605: Various java.lang.invoke cleanups
Message-ID: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>

- Remove unused code
- Inline and simplify the bootstrap method invocation code (remove pointless reboxing checks etc)
- Apply pattern matching to make some code more readable

-------------

Commit messages:
 - Avoid unnecessary reboxing checks, inline and simplify class/mt invokes
 - j.l.invoke cleanups

Changes: https://git.openjdk.java.net/jdk/pull/2300/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2300&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260605
  Stats: 269 lines in 14 files changed: 11 ins; 161 del; 97 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2300.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2300/head:pull/2300

PR: https://git.openjdk.java.net/jdk/pull/2300

From redestad at openjdk.java.net  Thu Jan 28 19:33:55 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 28 Jan 2021 19:33:55 GMT
Subject: RFR: 8260605: Various java.lang.invoke cleanups [v2]
In-Reply-To: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
References: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
Message-ID: <yeXcSnRpX3O3WYi7oIZ3Oh7icii6w5_49NNKUxivhks=.489b41c8-a282-4de1-96d8-8fecf762a7f0@github.com>

> - Remove unused code
> - Inline and simplify the bootstrap method invocation code (remove pointless reboxing checks etc)
> - Apply pattern matching to make some code more readable

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Missing outstanding changes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2300/files
  - new: https://git.openjdk.java.net/jdk/pull/2300/files/dc8b586d..68d3475a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2300&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2300&range=00-01

  Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2300.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2300/head:pull/2300

PR: https://git.openjdk.java.net/jdk/pull/2300

From asemenyuk at openjdk.java.net  Thu Jan 28 20:16:40 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 28 Jan 2021 20:16:40 GMT
Subject: RFR: 8260592: jpackage tests fail when Desktop is not supported
In-Reply-To: <LxoXmxOCVkAxOpxADonAZaGzooDXIrqi1eBEe9eu-h0=.dfebfe41-279d-45ba-ab14-4e6b4f52a266@github.com>
References: <LxoXmxOCVkAxOpxADonAZaGzooDXIrqi1eBEe9eu-h0=.dfebfe41-279d-45ba-ab14-4e6b4f52a266@github.com>
Message-ID: <ENvsCqH8dt3UzHnPWm1_hKDabNOkVhPyA0UPKl_3M8Q=.bff4168d-a529-4969-b5aa-464987b5b63d@github.com>

On Thu, 28 Jan 2021 14:33:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> If you run x86 configuration (cross-compiled on x86_64), then many tests would fail with:
> 
> $ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/jpackage
> ...
> can not load libgnomevfs-2.so
> Exception in thread "main" java.lang.ExceptionInInitializerError
> Caused by: java.lang.UnsupportedOperationException: Desktop API is not supported on the current platform
> at java.desktop/java.awt.Desktop.getDesktop(Unknown Source)
> at com.that/com.that.main.Florence.createInstance(Unknown Source)
> at com.that/com.that.main.Florence.<clinit>(Unknown Source)
> Failed to launch JVM
> java.lang.AssertionError: Expected [0]. Actual [1]: Check command [/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_jdk_tools_jpackage/scratch/10/./testMainLauncherIsModular.ed4f638d/output/MainLauncherIsModularAddLauncherTest/bin/ModularAppLauncher](1) exited with 0 code
> 
> The tests probably need to check `Desktop.isDesktopSupported()`, similarly how they check `GraphicsEnvironment.isHeadless()`.
> 
> Additional testing:
>  - [x] Linux x86_32 `tools/jpackage` (now pass)
>  - [x] Linux x86_64 `tools/jpackage` (still pass)

Changes requested by asemenyuk (Committer).

test/jdk/tools/jpackage/apps/image/Hello.java line 166:

> 164:         }
> 165: 
> 166:         if (!Desktop.isDesktopSupported()) {

Would it make more sense to replace
`if (GraphicsEnvironment.isHeadless())`
with
`if (GraphicsEnvironment.isHeadless() || !Desktop.isDesktopSupported())`
without need to add another `trace()` call?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2291

From herrick at openjdk.java.net  Thu Jan 28 21:58:45 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 28 Jan 2021 21:58:45 GMT
Subject: RFR: 8260592: jpackage tests fail when Desktop is not supported
In-Reply-To: <LxoXmxOCVkAxOpxADonAZaGzooDXIrqi1eBEe9eu-h0=.dfebfe41-279d-45ba-ab14-4e6b4f52a266@github.com>
References: <LxoXmxOCVkAxOpxADonAZaGzooDXIrqi1eBEe9eu-h0=.dfebfe41-279d-45ba-ab14-4e6b4f52a266@github.com>
Message-ID: <T1kXQzwgkssmwzx9elDDD_mSSJduQUWEnWq-oUnhFn4=.794f9e2c-cb41-4b88-ae16-d12331a16f6a@github.com>

On Thu, 28 Jan 2021 14:33:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> If you run x86 configuration (cross-compiled on x86_64), then many tests would fail with:
> 
> $ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/jpackage
> ...
> can not load libgnomevfs-2.so
> Exception in thread "main" java.lang.ExceptionInInitializerError
> Caused by: java.lang.UnsupportedOperationException: Desktop API is not supported on the current platform
> at java.desktop/java.awt.Desktop.getDesktop(Unknown Source)
> at com.that/com.that.main.Florence.createInstance(Unknown Source)
> at com.that/com.that.main.Florence.<clinit>(Unknown Source)
> Failed to launch JVM
> java.lang.AssertionError: Expected [0]. Actual [1]: Check command [/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_jdk_tools_jpackage/scratch/10/./testMainLauncherIsModular.ed4f638d/output/MainLauncherIsModularAddLauncherTest/bin/ModularAppLauncher](1) exited with 0 code
> 
> The tests probably need to check `Desktop.isDesktopSupported()`, similarly how they check `GraphicsEnvironment.isHeadless()`.
> 
> Additional testing:
>  - [x] Linux x86_32 `tools/jpackage` (now pass)
>  - [x] Linux x86_64 `tools/jpackage` (still pass)

Marked as reviewed by herrick (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2291

From shade at openjdk.java.net  Thu Jan 28 22:08:43 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 28 Jan 2021 22:08:43 GMT
Subject: RFR: 8260592: jpackage tests fail when Desktop is not supported
In-Reply-To: <ENvsCqH8dt3UzHnPWm1_hKDabNOkVhPyA0UPKl_3M8Q=.bff4168d-a529-4969-b5aa-464987b5b63d@github.com>
References: <LxoXmxOCVkAxOpxADonAZaGzooDXIrqi1eBEe9eu-h0=.dfebfe41-279d-45ba-ab14-4e6b4f52a266@github.com>
 <ENvsCqH8dt3UzHnPWm1_hKDabNOkVhPyA0UPKl_3M8Q=.bff4168d-a529-4969-b5aa-464987b5b63d@github.com>
Message-ID: <EoyX2AT1qQO21Iyy_-QNCV_-kGpTZ9tuP-4ESRmffrk=.b9401097-9497-462f-9fb4-e3358822d28e@github.com>

On Thu, 28 Jan 2021 20:13:23 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> If you run x86 configuration (cross-compiled on x86_64), then many tests would fail with:
>> 
>> $ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/jpackage
>> ...
>> can not load libgnomevfs-2.so
>> Exception in thread "main" java.lang.ExceptionInInitializerError
>> Caused by: java.lang.UnsupportedOperationException: Desktop API is not supported on the current platform
>> at java.desktop/java.awt.Desktop.getDesktop(Unknown Source)
>> at com.that/com.that.main.Florence.createInstance(Unknown Source)
>> at com.that/com.that.main.Florence.<clinit>(Unknown Source)
>> Failed to launch JVM
>> java.lang.AssertionError: Expected [0]. Actual [1]: Check command [/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_jdk_tools_jpackage/scratch/10/./testMainLauncherIsModular.ed4f638d/output/MainLauncherIsModularAddLauncherTest/bin/ModularAppLauncher](1) exited with 0 code
>> 
>> The tests probably need to check `Desktop.isDesktopSupported()`, similarly how they check `GraphicsEnvironment.isHeadless()`.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 `tools/jpackage` (now pass)
>>  - [x] Linux x86_64 `tools/jpackage` (still pass)
>
> test/jdk/tools/jpackage/apps/image/Hello.java line 166:
> 
>> 164:         }
>> 165: 
>> 166:         if (!Desktop.isDesktopSupported()) {
> 
> Would it make more sense to replace
> `if (GraphicsEnvironment.isHeadless())`
> with
> `if (GraphicsEnvironment.isHeadless() || !Desktop.isDesktopSupported())`
> without need to add another `trace()` call?

I would prefer to have separate messages for "headless" and "desktop capable". I can merge these, if you insist.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2291

From asemenyuk at openjdk.java.net  Thu Jan 28 23:44:43 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 28 Jan 2021 23:44:43 GMT
Subject: RFR: 8260592: jpackage tests fail when Desktop is not supported
In-Reply-To: <EoyX2AT1qQO21Iyy_-QNCV_-kGpTZ9tuP-4ESRmffrk=.b9401097-9497-462f-9fb4-e3358822d28e@github.com>
References: <LxoXmxOCVkAxOpxADonAZaGzooDXIrqi1eBEe9eu-h0=.dfebfe41-279d-45ba-ab14-4e6b4f52a266@github.com>
 <ENvsCqH8dt3UzHnPWm1_hKDabNOkVhPyA0UPKl_3M8Q=.bff4168d-a529-4969-b5aa-464987b5b63d@github.com>
 <EoyX2AT1qQO21Iyy_-QNCV_-kGpTZ9tuP-4ESRmffrk=.b9401097-9497-462f-9fb4-e3358822d28e@github.com>
Message-ID: <iuh-_jhCYmdIvYLR3Yw0ac8-ekSvsgXWamm-0eeCbfY=.d3671bca-01b3-4f2f-bdb8-c41ed5118bf8@github.com>

On Thu, 28 Jan 2021 22:05:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> test/jdk/tools/jpackage/apps/image/Hello.java line 166:
>> 
>>> 164:         }
>>> 165: 
>>> 166:         if (!Desktop.isDesktopSupported()) {
>> 
>> Would it make more sense to replace
>> `if (GraphicsEnvironment.isHeadless())`
>> with
>> `if (GraphicsEnvironment.isHeadless() || !Desktop.isDesktopSupported())`
>> without need to add another `trace()` call?
>
> I would prefer to have separate messages for "headless" and "desktop capable". I can merge these, if you insist.

Duplicated messages are not much help in understanding control flow. I'd change the new message or merge conditions. Whatever you prefer.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2291

From joehw at openjdk.java.net  Fri Jan 29 00:07:59 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 29 Jan 2021 00:07:59 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline [v3]
In-Reply-To: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
Message-ID: <d-jHqtj2YuUQSe-29Qbv3Z1m_NIjZXolL2iTNjRzaEE=.c68e8d9a-b909-417f-b814-242949d9585a@github.com>

> Please review a patch to add an explicit control over whether a newline should be added after the XML header. This is done by adding a DOM LSSerializer property "jdk-is-standalone" and System property "jdk.xml.isStandalone". 
> 
> This change addresses an incompatibility introduced during 7u4 as an update to Xalan 2.7.1.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  Updated the patch based on review comments. Refer to the previous reviews.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2041/files
  - new: https://git.openjdk.java.net/jdk/pull/2041/files/a3591aa7..0ed62318

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2041&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2041&range=01-02

  Stats: 57 lines in 3 files changed: 14 ins; 8 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2041.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2041/head:pull/2041

PR: https://git.openjdk.java.net/jdk/pull/2041

From mr at openjdk.java.net  Fri Jan 29 00:17:46 2021
From: mr at openjdk.java.net (Mark Reinhold)
Date: Fri, 29 Jan 2021 00:17:46 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v14]
In-Reply-To: <E0-BDWvabmEyn-UQgb52JyxyoUlezyKlmvJNm81f6dw=.eb3d6e3f-5581-4152-9a6d-d6634c100e0e@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <E0-BDWvabmEyn-UQgb52JyxyoUlezyKlmvJNm81f6dw=.eb3d6e3f-5581-4152-9a6d-d6634c100e0e@github.com>
Message-ID: <QChmNZImKh2hp53TfVl_80Ks2e8HxzhmTOqZEilXs8E=.8644b711-c441-4f2a-b44d-c55e97ff5936@github.com>

On Mon, 18 Jan 2021 16:45:00 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
>> 
>> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
>> 
>> old PR:  https://github.com/openjdk/jdk/pull/1273
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update package info to credit LMX algorithm

src/java.base/share/classes/java/util/random/RandomGenerator.java line 110:

> 108:      /**
> 109:      * Returns an instance of {@link RandomGenerator} that utilizes the
> 110:      * {@code name} algorithm.

Shouldn't this method, and related methods, mention the fact that `RandomGenerator` instances are located as services? I see no mention of of that fact anywhere, unless I missed it, but I do see the `uses` and `provides` declarations in the module declaration. A paragraph explaining how services are used here, perhaps in the package specification, would be ideal.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From almatvee at openjdk.java.net  Fri Jan 29 01:06:39 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 29 Jan 2021 01:06:39 GMT
Subject: RFR: JDK-8260335: [macos] Running app using relative path causes
 problems
In-Reply-To: <UErEM5Ylr_Pj7-K3OIGsaYawwGdgB1BX5I01RA-oyqw=.89fdab22-6a37-4a06-9daa-f833691209ed@github.com>
References: <UErEM5Ylr_Pj7-K3OIGsaYawwGdgB1BX5I01RA-oyqw=.89fdab22-6a37-4a06-9daa-f833691209ed@github.com>
Message-ID: <NnBRqj-006cPcEvkygv5RkeSwKN-8_pLUm-1QGKVuR4=.494c6fe8-3581-4255-881c-6a4d42850537@github.com>

On Wed, 27 Jan 2021 12:43:40 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> Fixing FileUtils.dirname() to skip over "/.".

Marked as reviewed by almatvee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2260

From almatvee at openjdk.java.net  Fri Jan 29 01:16:41 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 29 Jan 2021 01:16:41 GMT
Subject: RFR: 8260592: jpackage tests fail when Desktop is not supported
In-Reply-To: <iuh-_jhCYmdIvYLR3Yw0ac8-ekSvsgXWamm-0eeCbfY=.d3671bca-01b3-4f2f-bdb8-c41ed5118bf8@github.com>
References: <LxoXmxOCVkAxOpxADonAZaGzooDXIrqi1eBEe9eu-h0=.dfebfe41-279d-45ba-ab14-4e6b4f52a266@github.com>
 <ENvsCqH8dt3UzHnPWm1_hKDabNOkVhPyA0UPKl_3M8Q=.bff4168d-a529-4969-b5aa-464987b5b63d@github.com>
 <EoyX2AT1qQO21Iyy_-QNCV_-kGpTZ9tuP-4ESRmffrk=.b9401097-9497-462f-9fb4-e3358822d28e@github.com>
 <iuh-_jhCYmdIvYLR3Yw0ac8-ekSvsgXWamm-0eeCbfY=.d3671bca-01b3-4f2f-bdb8-c41ed5118bf8@github.com>
Message-ID: <nRmWCt5uymqvdo_wMME-K2WpLzIUYKNxKl1P7ipTguc=.f2d528b9-1ed3-40a4-bfd6-f412ef03e67c@github.com>

On Thu, 28 Jan 2021 23:41:44 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> I would prefer to have separate messages for "headless" and "desktop capable". I can merge these, if you insist.
>
> Duplicated messages are not much help in understanding control flow. I'd change the new message or merge conditions. Whatever you prefer.

It is fine with me to have two separate messages for display and desktop, but it is better to move this check to top of function after if (GraphicsEnvironment.isHeadless()). No point to execute other code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2291

From smarks at openjdk.java.net  Fri Jan 29 03:19:39 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 29 Jan 2021 03:19:39 GMT
Subject: RFR: JDK-8257086: Clarify differences between {Float,
 Double}.equals and ==
In-Reply-To: <JTBK_oK-XYFJuoM7KUZo1VPqH-_JMcWUXvEwx_oiK9o=.e46ddd17-1bdf-4efa-aa97-0f715d682c26@github.com>
References: <sxbxBYIClZ26dmLvW8fUbnNPybVl_k16wHbBPEDx40o=.86762561-b05f-4814-a57b-e5fc02f58d8f@github.com>
 <87yS9DH4_CxvLZYSVYcw5bham03wLB0sVHQWY0nGMBk=.b6af4284-f3c7-4a1e-920b-915663fe38e6@github.com>
 <v4rFMmum40OlQjccGpbSsaVH7pK3oK1BwPSJzHqBkM4=.3b8355b9-9202-40d5-89d5-4792b56f2afb@github.com>
 <Qhg9J-7_l6Pk-NKrG-FFGVrkFG_beuSzrnKTBss1b6I=.9924a65a-6e9d-4110-b1df-3d7359d01d4c@github.com>
 <JTBK_oK-XYFJuoM7KUZo1VPqH-_JMcWUXvEwx_oiK9o=.e46ddd17-1bdf-4efa-aa97-0f715d682c26@github.com>
Message-ID: <BtPlMo2QpdqR4JQ_RYtgVZJegLz5SdPGENBYvdNV3G4=.76d4c116-2c65-4052-a7db-9adbe3da62b5@github.com>

On Thu, 28 Jan 2021 07:15:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Great, let me know if you'd like me to provide some text for any particular topics in this area.
>
>> 
>> 
>> Great, let me know if you'd like me to provide some text for any particular topics in this area.
> 
> Before sending out another iteration in code, there the draft javadoc text of a discussion at the end of the class-level discussion of java.lang.Double:
> 
>  * <h2><a id=equivalenceRelation>Floating-point Equality, Equivalence,
>  * and Comparison</a></h2>
>  *
>  * IEEE 754 floating-point values include finite nonzero values,
>  * signed zeros ({@code +0.0} and {@code -0.0}), signed infinities
>  * {@linkplain Double#POSITIVE_INFINITY positive infinity} and
>  * {@linkplain Double#NEGATIVE_INFINITY negative infinity}), and
>  * {@linkplain Double#NaN NaN} (not-a-number).
>  *
>  * <p>An <em>equivalence relation</em> on a set of values is a boolean
>  * relation on pairs of values that is reflexive, symmetric, and
>  * transitive. A set can have multiple equivalence relations defined
>  * for it. For example, {@link java.util.HashMap HashMap} compares
>  * keys in the set of objects using the equivalence relation of {@link
>  * Object#equals Object.equals} while {@link java.util.IdentityHashMap
>  * IdentityHashMap} compares keys in the set of objects using the
>  * equivalence relation of reference equality.
>  * 
>  * <p>For floating-point values to be used in data structures like
>  * sets and maps, the {@linkplain Double#equals equals} or {@linkplain
>  * Double#compareTo comparison} method must satisfy the usual
>  * requirements of being an equivalence relation or analogous
>  * requirement for comparison methods. However, surprisingly, the
>  * built-in {@code ==} operation on floating-point values does
>  * <em>not</em> implement an equivalence relation. Despite not
>  * defining an equivalence relation, the semantics of the IEEE 754
>  * {@code ==} operator were deliberately designed to meet other needs
>  * of numerical computation. There are two exceptions where the
>  * properties of an equivalence relations are not satisfied by {@code
>  * ==} on floating-point values:
>  *
>  * <ul>
>  *
>  * <li>If {@code v1} and {@code v2} are both NaN, then {@code v1
>  * == v2} has the value {@code false}. Therefore, for two NaN
>  * arguments the <em>reflexive</em> property of an equivalence
>  * relation is <em>not</em> satisfied by the {@code ==} operator.
>  *
>  * <li>If {@code v1} represents {@code +0.0} while {@code v2}
>  * represents {@code -0.0}, or vice versa, then {@code v1 == v2} has
>  * the value {@code true} even though {@code +0.0} and {@code -0.0}
>  * are distinguishable under various floating-point operations. For
>  * example, {@code 1.0/+0.0} evaluates to positive infinity while
>  * {@code 1.0/-0.0} evaluates to <em>negative</em> infinity and
>  * positive infinity and negative infinity are neither equal to each
>  * other nor equivalent to each other.
>  *
>  * </ul>
>  *
>  * <p>For ordered comparisons using the built-in comparison operator
>  * ({@code <}, {@code <=}, etc.), NaN values have another anomalous
>  * situation: a NaN is neither less than, greater than, nor equal to
>  * any value, including itself. This means the <em>trichotomy of
>  * comparison</em> does <em>not</em> hold.
>  * 
>  * <p>To provide the appropriate semantics for {@code equals} and {@code
>  * compareTo} methods, those methods cannot simply to wrappers around
>  * {@code ==} or ordered comparison operations. Instead, {@link
>  * Double#equals equals} defines NaN arguments to be equal to each
>  * other and defines {@code +0.0} to <em>not</em> be equal to {@code
>  * -0.0}, restoring reflexivity. For comparisons, {@link
>  * Double#compareTo compareTo} defines a total order where {@code
>  * -0.0} is less than {@code +0.0} and where a NaN is equal to itself
>  * and considered greater than positive infinity.
>  *
>  * <p>The operational semantics of {@code equals} and {@code
>  * compareTo} are expressed in terms of {@linkplain doubleToLongBigs
>  * bit-wise converting} the floating-point values to integral values 
>  *
>  * <p>The <em>natural ordering</em> implemented by {@link compareTo
>  * compareTo} is {@linkplain Comparable consistent with equals}; that
>  * is values are only reported as equal by {@code equals} if {@code
>  * compareTo} on those objects returns zero.
>  *
>  * @jls 4.2.3 Floating-Point Types, Formats, and Values
>  * @jls 4.2.4. Floating-Point Operations
>  * @jls 15.21.1 Numerical Equality Operators == and !=
> 
> Comments?
> 
> Thanks,

I took the liberty of making an editing pass over the proposed text. Along with a few editorial and markup adjustments, the key changes are as follows:

1) I moved discussion of interaction with Set and Map to the end, after all the issues have been set up.

2) I added the concept of substitution alongside the equivalence relation. AFAIK substitution (or substitutability) is not part of an equivalence relation, but it seems that in many systems, equivalence implies substitutability. Of course, the point is that it _doesn't_ apply for -0.0 and +0.0.

We'll see how well this survives github markup. If it doesn't work out, I can email the text file. (Triple backquotes seem to do the trick.)

 * <h2><a id=equivalenceRelation>Floating-point Equality, Equivalence,
 * and Comparison</a></h2>
 *
 * IEEE 754 floating-point values include finite nonzero values,
 * signed zeros ({@code +0.0} and {@code -0.0}), signed infinities
 * {@linkplain Double#POSITIVE_INFINITY positive infinity} and
 * {@linkplain Double#NEGATIVE_INFINITY negative infinity}), and
 * {@linkplain Double#NaN NaN} (not-a-number).
 *
 * <p>An <em>equivalence relation</em> on a set of values is a boolean
 * relation on pairs of values that is reflexive, symmetric, and
 * transitive. For more discussion of equivalence relations, see
 * the {@link Object#equals Object.equals} specification. Additionally,
 * In a numeric expression, values that are equivalent can generally
 * be <em>substituted</em> for one another without changing the value
 * of the expression, though there are exceptions.
 * 
 * <p>Notably, the
 * built-in {@code ==} operation on floating-point values does
 * <em>not</em> implement an equivalence relation. Despite not
 * defining an equivalence relation, the semantics of the IEEE 754
 * {@code ==} operator were deliberately designed to meet other needs
 * of numerical computation. There are two exceptions where the
 * properties of an equivalence relations are not satisfied by {@code
 * ==} on floating-point values:
 *
 * <ul>
 *
 * <li>If {@code v1} and {@code v2} are both NaN, then {@code v1
 * == v2} has the value {@code false}. Therefore, for two NaN
 * arguments the <em>reflexive</em> property of an equivalence
 * relation is <em>not</em> satisfied by the {@code ==} operator.
 *
 * <li>If {@code v1} represents {@code +0.0} while {@code v2}
 * represents {@code -0.0}, or vice versa, then {@code v1 == v2} has
 * the value {@code true} even though {@code +0.0} and {@code -0.0}
 * are distinguishable under various floating-point operations. For
 * example, {@code 1.0/+0.0} evaluates to positive infinity while
 * {@code 1.0/-0.0} evaluates to <em>negative</em> infinity and
 * positive infinity and negative infinity are neither equal to each
 * other nor equivalent to each other. Thus, {@code +0.0} and {@code
 * -0.0} may not be substituted for each other in general.
 *
 * </ul>
 *
 * <p>For ordered comparisons using the built-in comparison operators
 * ({@code <}, {@code <=}, etc.), NaN values have another anomalous
 * situation: a NaN is neither less than, greater than, nor equal to
 * any value, including itself. This means the <em>trichotomy of
 * comparison</em> does <em>not</em> hold.
 * 
 * <p>To provide the appropriate semantics for {@code equals} and {@code
 * compareTo} methods, those methods cannot simply to wrappers around
 * {@code ==} or ordered comparison operations. Instead, {@link
 * Double#equals equals} defines NaN arguments to be equal to each
 * other and defines {@code +0.0} to <em>not</em> be equal to {@code
 * -0.0}, restoring reflexivity. For comparisons, {@link
 * Double#compareTo compareTo} defines a total order where {@code
 * -0.0} is less than {@code +0.0} and where a NaN is equal to itself
 * and considered greater than positive infinity.
 *
 * <p>The operational semantics of {@code equals} and {@code
 * compareTo} are expressed in terms of {@linkplain #doubleToLongBits
 * bit-wise converting} the floating-point values to integral values.
 *
 * <p>The <em>natural ordering</em> implemented by {@link #compareTo
 * compareTo} is {@linkplain Comparable consistent with equals}. That
 * is, its values are reported as equal by {@code equals} if and only
 * if {@code compareTo} on those objects returns zero.
 * 
 * <p>The adjusted behaviors defined for {@code equals} and {@code
 * compareTo} allow instances of wrapper classes to work properly with
 * conventional data structures. For example, defining NaN
 * values to be {@code equals} to one another allows NaN to be used as
 * an element of a {@link java.util.HashSet HashSet} or as the key of
 * a {@link java.util.HashMap HashMap}. Similarly, defining {@code
 * compareTo} as a total ordering, including {@code +0.0}, {@code
 * -0.0}, and NaN, allows instances of wrapper classes to be used as
 * elements of a {@link java.util.SortedSet SortedSet} or as keys of a
 * {@link java.util.SortedMap SortedMap}.
 *
 * @jls 4.2.3 Floating-Point Types, Formats, and Values
 * @jls 4.2.4. Floating-Point Operations
 * @jls 15.21.1 Numerical Equality Operators == and !=

-------------

PR: https://git.openjdk.java.net/jdk/pull/1699

From joe.darcy at oracle.com  Fri Jan 29 03:43:38 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 28 Jan 2021 19:43:38 -0800
Subject: RFR: JDK-8257086: Clarify differences between {Float,
 Double}.equals and ==
In-Reply-To: <BtPlMo2QpdqR4JQ_RYtgVZJegLz5SdPGENBYvdNV3G4=.76d4c116-2c65-4052-a7db-9adbe3da62b5@github.com>
References: <sxbxBYIClZ26dmLvW8fUbnNPybVl_k16wHbBPEDx40o=.86762561-b05f-4814-a57b-e5fc02f58d8f@github.com>
 <87yS9DH4_CxvLZYSVYcw5bham03wLB0sVHQWY0nGMBk=.b6af4284-f3c7-4a1e-920b-915663fe38e6@github.com>
 <v4rFMmum40OlQjccGpbSsaVH7pK3oK1BwPSJzHqBkM4=.3b8355b9-9202-40d5-89d5-4792b56f2afb@github.com>
 <Qhg9J-7_l6Pk-NKrG-FFGVrkFG_beuSzrnKTBss1b6I=.9924a65a-6e9d-4110-b1df-3d7359d01d4c@github.com>
 <JTBK_oK-XYFJuoM7KUZo1VPqH-_JMcWUXvEwx_oiK9o=.e46ddd17-1bdf-4efa-aa97-0f715d682c26@github.com>
 <BtPlMo2QpdqR4JQ_RYtgVZJegLz5SdPGENBYvdNV3G4=.76d4c116-2c65-4052-a7db-9adbe3da62b5@github.com>
Message-ID: <8cabd067-3fd6-5c67-f917-32b1109b2afd@oracle.com>

Hi Stuart,

On 1/28/2021 7:19 PM, Stuart Marks wrote:
> On Thu, 28 Jan 2021 07:15:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>
>>> Great, let me know if you'd like me to provide some text for any particular topics in this area.
>>>
>>> Great, let me know if you'd like me to provide some text for any particular topics in this area.
>> Before sending out another iteration in code, there the draft javadoc text of a discussion at the end of the class-level discussion of java.lang.Double:
>>

[snip]

>>
>> Comments?
>>
>> Thanks,
> I took the liberty of making an editing pass over the proposed text. Along with a few editorial and markup adjustments, the key changes are as follows:
>
> 1) I moved discussion of interaction with Set and Map to the end, after all the issues have been set up.
>
> 2) I added the concept of substitution alongside the equivalence relation. AFAIK substitution (or substitutability) is not part of an equivalence relation, but it seems that in many systems, equivalence implies substitutability. Of course, the point is that it _doesn't_ apply for -0.0 and +0.0.

Yes; substitutability was an implicit concept in the earlier write-up; 
it is an improvement to call it out my name.

I'll work on integrating this version into an update of the PR with 
references from the equals and compareTo methods, etc.

Thanks,

-Joe



>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/1699

From sspitsyn at openjdk.java.net  Fri Jan 29 05:39:59 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 29 Jan 2021 05:39:59 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v13]
In-Reply-To: <AM3ukYnjNSnPy8QCMyEsKn8LPUunjjRgQVdCd9qtVk0=.ee52a440-86bf-4a69-90e9-6e9dc2e33642@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <_XHsdihfp48gENT26xI6Br_8d1kdCBwXzHZBtRJ5ZWY=.874f77c5-c945-458c-a260-1f5e02b635a5@github.com>
 <k-WhLggIqzlJq3A1jILFkmImIWzvvWjo6DmZFD4E6ig=.20383022-47d7-4a96-b13c-1382790675e4@github.com>
 <rzzTJKFRJ9SUhS0CYcmSkIWnhZ1uJw-Lt9H85zFE5zs=.c7f9e6ce-1664-4f83-9c1c-2f48dc52860e@github.com>
 <AM3ukYnjNSnPy8QCMyEsKn8LPUunjjRgQVdCd9qtVk0=.ee52a440-86bf-4a69-90e9-6e9dc2e33642@github.com>
Message-ID: <MQdzS56wOfmbxOF8ovgvAqlD6C7_qfbJxVCV9OZ2wro=.edfa23f7-6597-4b54-88df-3aadd0ff2013@github.com>

On Fri, 29 Jan 2021 05:14:31 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Hi Lin,
>> 
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java
>> 
>> Thank you for the update.
>> 
>> The list of possible commands must include one more variant with no arguments:
>> +                     * Possible command:
>> +                     *     dumpheap gz=1 file;
>> +                     *     dumpheap gz=1;
>> +                     *     dumpheap file;
>> +                     *     dumpheap
>> 
>> The argument processing is still not right.
>> Why are there no checks for gzlevel < 0 and gzlevel > 9 ?
>> 
>> I'd suggest the following refactoring below:
>> 
>>                    /*
>>                     * Possible commands:
>>                     *     dumpheap gz=1 file
>>                     *     dumpheap gz=1
>>                     *     dumpheap file
>>                     *     dumpheap
>>                     *
>>                     * Use default filename if cntTokens == 0.
>>                     * Handle cases with cntTokens == 1 or 2.
>>                     */
>> 
>>                     if (cntTokens > 2) {
>>                         err.println("Too big number of options: " + cntTokens);
>>                         usage();
>>                         return;
>>                     }
>>                     if (cntTokens >= 1) { // parse first argument which is "gz=" option
>>                         String option  = t.nextToken();
>>                         gzlevel = parseHeapDumpCompressionLevel(option);
>>                         if (gzlevel <= 0 || gzlevel > 9) {
>>                             err.println("Invalid "gz=" option: " + option);
>>                             usage();
>>                             return;
>>                         }
>>                         filename = "heap.bin.gz";
>>                     }
>>                     if (cntTokens == 2) { // parse second argument which is filename
>>                         filename = t.nextToken();
>>                         if (filename.startsWith("gz=")) {
>>                             err.println("Filename should not start with "gz=": " + filename);
>>                             usage();
>>                             return;
>>                         }
>>                     }
>
> Hi @sspitsyn,
> Thanks for your suggestion, the parseHeapDumpCompresslevel() inside tested the gzlevel, but I think your code is much reasonable. I will make it in next update. 
> BRs,
> Lin

You are right.
So, in my suggestion just replace this block:
                        if (gzlevel <= 0 || gzlevel > 9) {
                            err.println("Invalid "gz=" option: " + option);
                            usage();
                            return;
                        }
with:
                        if (gzlevel == 0) {
                            usage();
                            return;
                        }

-------------

PR: https://git.openjdk.java.net/jdk/pull/1712

From lzang at openjdk.java.net  Fri Jan 29 05:39:59 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 29 Jan 2021 05:39:59 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v14]
In-Reply-To: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
Message-ID: <hshEN06sqJcgNmcW4Yb75mtnYFVMiqX3lfmekNjzApU=.183255d4-56da-48ac-8a81-7a81b5900253@github.com>

> 8257234 : Add gz option to SA jmap to write a gzipped heap dump

Lin Zang has updated the pull request incrementally with two additional commits since the last revision:

 - fix an issue of double printing error message.
 - fix jcmd jmap issue and add test in BascJMapTest and code refine

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1712/files
  - new: https://git.openjdk.java.net/jdk/pull/1712/files/db38b6a8..0d30aaf3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=12-13

  Stats: 50 lines in 4 files changed: 27 ins; 7 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1712.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1712/head:pull/1712

PR: https://git.openjdk.java.net/jdk/pull/1712

From lzang at openjdk.java.net  Fri Jan 29 05:39:59 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 29 Jan 2021 05:39:59 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v13]
In-Reply-To: <MQdzS56wOfmbxOF8ovgvAqlD6C7_qfbJxVCV9OZ2wro=.edfa23f7-6597-4b54-88df-3aadd0ff2013@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <_XHsdihfp48gENT26xI6Br_8d1kdCBwXzHZBtRJ5ZWY=.874f77c5-c945-458c-a260-1f5e02b635a5@github.com>
 <k-WhLggIqzlJq3A1jILFkmImIWzvvWjo6DmZFD4E6ig=.20383022-47d7-4a96-b13c-1382790675e4@github.com>
 <rzzTJKFRJ9SUhS0CYcmSkIWnhZ1uJw-Lt9H85zFE5zs=.c7f9e6ce-1664-4f83-9c1c-2f48dc52860e@github.com>
 <AM3ukYnjNSnPy8QCMyEsKn8LPUunjjRgQVdCd9qtVk0=.ee52a440-86bf-4a69-90e9-6e9dc2e33642@github.com>
 <MQdzS56wOfmbxOF8ovgvAqlD6C7_qfbJxVCV9OZ2wro=.edfa23f7-6597-4b54-88df-3aadd0ff2013@github.com>
Message-ID: <cf-ZkQ1ry5HEWI9dQpsWUs4r1AftCQwmTWTC5-K5PGg=.fddb774f-3d7c-41b3-ac6a-c5b101403fe3@github.com>

On Fri, 29 Jan 2021 05:33:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> You are right.
> So, in my suggestion just replace this block:
> 
> ```
>                         if (gzlevel <= 0 || gzlevel > 9) {
>                             err.println("Invalid "gz=" option: " + option);
>                             usage();
>                             return;
>                         }
> ```
> 
> with:
> 
> ```
>                         if (gzlevel == 0) {
>                             usage();
>                             return;
>                         }
> ```

Thanks, just found there can be two prints of same error for option like gz=abc,
I will change back:)

-------------

PR: https://git.openjdk.java.net/jdk/pull/1712

From shade at openjdk.java.net  Fri Jan 29 07:31:55 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 29 Jan 2021 07:31:55 GMT
Subject: RFR: 8260592: jpackage tests fail when Desktop is not supported
 [v2]
In-Reply-To: <LxoXmxOCVkAxOpxADonAZaGzooDXIrqi1eBEe9eu-h0=.dfebfe41-279d-45ba-ab14-4e6b4f52a266@github.com>
References: <LxoXmxOCVkAxOpxADonAZaGzooDXIrqi1eBEe9eu-h0=.dfebfe41-279d-45ba-ab14-4e6b4f52a266@github.com>
Message-ID: <yrH-pOj9JMAql6YzcJSAnetxFZN361xeu8Cbj-gZLM4=.2ec21820-257e-4b4c-b205-26c8fd6ac945@github.com>

> If you run x86 configuration (cross-compiled on x86_64), then many tests would fail with:
> 
> $ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/jpackage
> ...
> can not load libgnomevfs-2.so
> Exception in thread "main" java.lang.ExceptionInInitializerError
> Caused by: java.lang.UnsupportedOperationException: Desktop API is not supported on the current platform
> at java.desktop/java.awt.Desktop.getDesktop(Unknown Source)
> at com.that/com.that.main.Florence.createInstance(Unknown Source)
> at com.that/com.that.main.Florence.<clinit>(Unknown Source)
> Failed to launch JVM
> java.lang.AssertionError: Expected [0]. Actual [1]: Check command [/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_jdk_tools_jpackage/scratch/10/./testMainLauncherIsModular.ed4f638d/output/MainLauncherIsModularAddLauncherTest/bin/ModularAppLauncher](1) exited with 0 code
> 
> The tests probably need to check `Desktop.isDesktopSupported()`, similarly how they check `GraphicsEnvironment.isHeadless()`.
> 
> Additional testing:
>  - [x] Linux x86_32 `tools/jpackage` (now pass)
>  - [x] Linux x86_64 `tools/jpackage` (still pass)

Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:

 - Reinstate trace message
 - Move check higher

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2291/files
  - new: https://git.openjdk.java.net/jdk/pull/2291/files/c0975ae3..ddf28110

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2291&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2291&range=00-01

  Stats: 12 lines in 1 file changed: 6 ins; 6 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2291.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2291/head:pull/2291

PR: https://git.openjdk.java.net/jdk/pull/2291

From shade at openjdk.java.net  Fri Jan 29 07:31:55 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 29 Jan 2021 07:31:55 GMT
Subject: RFR: 8260592: jpackage tests fail when Desktop is not supported
 [v2]
In-Reply-To: <nRmWCt5uymqvdo_wMME-K2WpLzIUYKNxKl1P7ipTguc=.f2d528b9-1ed3-40a4-bfd6-f412ef03e67c@github.com>
References: <LxoXmxOCVkAxOpxADonAZaGzooDXIrqi1eBEe9eu-h0=.dfebfe41-279d-45ba-ab14-4e6b4f52a266@github.com>
 <ENvsCqH8dt3UzHnPWm1_hKDabNOkVhPyA0UPKl_3M8Q=.bff4168d-a529-4969-b5aa-464987b5b63d@github.com>
 <EoyX2AT1qQO21Iyy_-QNCV_-kGpTZ9tuP-4ESRmffrk=.b9401097-9497-462f-9fb4-e3358822d28e@github.com>
 <iuh-_jhCYmdIvYLR3Yw0ac8-ekSvsgXWamm-0eeCbfY=.d3671bca-01b3-4f2f-bdb8-c41ed5118bf8@github.com>
 <nRmWCt5uymqvdo_wMME-K2WpLzIUYKNxKl1P7ipTguc=.f2d528b9-1ed3-40a4-bfd6-f412ef03e67c@github.com>
Message-ID: <ureU53q9jc0DONKE-BOstJhFXJLaq5Ri4kfsPEPlbvY=.f3f51271-d679-460d-b4f3-fec9c908eb80@github.com>

On Fri, 29 Jan 2021 01:13:30 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Duplicated messages are not much help in understanding control flow. I'd change the new message or merge conditions. Whatever you prefer.
>
> It is fine with me to have two separate messages for display and desktop, but it is better to move this check to top of function after if (GraphicsEnvironment.isHeadless()). No point to execute other code.

Okay, I moved the check upwards. The trace message is left intact. Note it says "desktop", there, so it is not a duplicate message.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2291

From redestad at openjdk.java.net  Fri Jan 29 09:56:57 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 29 Jan 2021 09:56:57 GMT
Subject: RFR: 8260617: Merge ZipFile encoding check with the initial hash
 calculation
Message-ID: <rdXUh4BYI5qnXEVdDLeqhFj5URWwg5puLEZQSu8kLkY=.49f605d2-5de4-4da4-919f-9d4a40da53fd@github.com>

- Merge checkEncoding into the byte[]-based normalizedHash. The latter is only used from ZipFile.initCEN right after the checkEncoding today, so verifying this is equivalent is straightforward.
- Factor out the logic to calculate hash, check encoding etc into the addEntry method to allow JITs to chew off larger chunks of the logic early on

Roughly 1.2x speedup on the JarFileMeta microbenchmarks, which include the time required to open the jar file and thus exercising the optimized code.

Testing: tier1-4

-------------

Commit messages:
 - Refactor ZipFile.initCEN, merging checkEncoding and normalizedHash

Changes: https://git.openjdk.java.net/jdk/pull/2306/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2306&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260617
  Stats: 132 lines in 2 files changed: 31 ins; 68 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2306.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2306/head:pull/2306

PR: https://git.openjdk.java.net/jdk/pull/2306

From redestad at openjdk.java.net  Fri Jan 29 09:56:57 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 29 Jan 2021 09:56:57 GMT
Subject: RFR: 8260617: Merge ZipFile encoding check with the initial hash
 calculation
In-Reply-To: <rdXUh4BYI5qnXEVdDLeqhFj5URWwg5puLEZQSu8kLkY=.49f605d2-5de4-4da4-919f-9d4a40da53fd@github.com>
References: <rdXUh4BYI5qnXEVdDLeqhFj5URWwg5puLEZQSu8kLkY=.49f605d2-5de4-4da4-919f-9d4a40da53fd@github.com>
Message-ID: <aFQ6EQjTXr_Ve1z-9kFTZ_pVToNdCSU9XDdXlM48w_Q=.78fbcbe2-df8a-4174-8d9d-ef4842592f37@github.com>

On Fri, 29 Jan 2021 00:54:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Merge checkEncoding into the byte[]-based normalizedHash. The latter is only used from ZipFile.initCEN right after the checkEncoding today, so verifying this is equivalent is straightforward.
> - Factor out the logic to calculate hash, check encoding etc into the addEntry method to allow JITs to chew off larger chunks of the logic early on
> 
> Roughly 1.2x speedup on the JarFileMeta microbenchmarks, which include the time required to open the jar file and thus exercising the optimized code.
> 
> Testing: tier1-4

Baseline:
Benchmark                                       (size)  Mode  Cnt    Score    Error  Units
JarFileMeta.getManifestFromJarWithManifest         512  avgt    5  246.534 ? 32.934  us/op
JarFileMeta.getManifestFromJarWithManifest        1024  avgt    5  475.978 ? 70.689  us/op
JarFileMeta.getStreamFromJarWithManifest           512  avgt    5  243.401 ? 33.190  us/op
JarFileMeta.getStreamFromJarWithManifest          1024  avgt    5  465.899 ? 58.306  us/op
JarFileMeta.getStreamFromJarWithNoManifest         512  avgt    5  243.480 ? 44.631  us/op
JarFileMeta.getStreamFromJarWithNoManifest        1024  avgt    5  454.937 ? 55.268  us/op
JarFileMeta.getStreamFromJarWithSignatureFiles     512  avgt    5  267.522 ? 48.914  us/op
JarFileMeta.getStreamFromJarWithSignatureFiles    1024  avgt    5  509.779 ? 81.314  us/op

Patched:
JarFileMeta.getManifestFromJarWithManifest         512  avgt    5  186.973 ? 26.564  us/op
JarFileMeta.getManifestFromJarWithManifest        1024  avgt    5  360.141 ? 33.414  us/op
JarFileMeta.getStreamFromJarWithManifest           512  avgt    5  186.244 ? 30.014  us/op
JarFileMeta.getStreamFromJarWithManifest          1024  avgt    5  362.870 ? 61.271  us/op
JarFileMeta.getStreamFromJarWithNoManifest         512  avgt    5  182.841 ? 13.797  us/op
JarFileMeta.getStreamFromJarWithNoManifest        1024  avgt    5  354.254 ? 67.377  us/op
JarFileMeta.getStreamFromJarWithSignatureFiles     512  avgt    5  215.419 ? 20.463  us/op
JarFileMeta.getStreamFromJarWithSignatureFiles    1024  avgt    5  403.043 ? 78.926  us/op

-------------

PR: https://git.openjdk.java.net/jdk/pull/2306

From github.com+34924738+mahendrachhipa at openjdk.java.net  Fri Jan 29 10:57:04 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 29 Jan 2021 10:57:04 GMT
Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java
 [v6]
In-Reply-To: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
References: <faJvkgWUm2q2zyMxQ9iSsuVQc2AAdtc2VPAtv1g3Tcs=.217a668f-a2ee-473d-9238-fb2fe0fb26bd@github.com>
Message-ID: <5naBbCjr--gxYWghzxxV3HxHQMJH72Ci8em1R1HUaUU=.620a5035-d308-415c-b974-330fe2672e4e@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8183372

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  Reset the formatting.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2170/files
  - new: https://git.openjdk.java.net/jdk/pull/2170/files/d8ce7caa..40ba2b3b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=04-05

  Stats: 24 lines in 1 file changed: 7 ins; 2 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2170.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2170/head:pull/2170

PR: https://git.openjdk.java.net/jdk/pull/2170

From asemenyuk at openjdk.java.net  Fri Jan 29 13:11:43 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 29 Jan 2021 13:11:43 GMT
Subject: RFR: 8260592: jpackage tests fail when Desktop is not supported
 [v2]
In-Reply-To: <yrH-pOj9JMAql6YzcJSAnetxFZN361xeu8Cbj-gZLM4=.2ec21820-257e-4b4c-b205-26c8fd6ac945@github.com>
References: <LxoXmxOCVkAxOpxADonAZaGzooDXIrqi1eBEe9eu-h0=.dfebfe41-279d-45ba-ab14-4e6b4f52a266@github.com>
 <yrH-pOj9JMAql6YzcJSAnetxFZN361xeu8Cbj-gZLM4=.2ec21820-257e-4b4c-b205-26c8fd6ac945@github.com>
Message-ID: <ELZ3wM9meK9p4mi8YXZq-JsBvmJMnAvS2UZNvn8utVU=.098993bb-dc8a-4926-b1d3-9b06e2e1a031@github.com>

On Fri, 29 Jan 2021 07:31:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> If you run x86 configuration (cross-compiled on x86_64), then many tests would fail with:
>> 
>> $ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/jpackage
>> ...
>> can not load libgnomevfs-2.so
>> Exception in thread "main" java.lang.ExceptionInInitializerError
>> Caused by: java.lang.UnsupportedOperationException: Desktop API is not supported on the current platform
>> at java.desktop/java.awt.Desktop.getDesktop(Unknown Source)
>> at com.that/com.that.main.Florence.createInstance(Unknown Source)
>> at com.that/com.that.main.Florence.<clinit>(Unknown Source)
>> Failed to launch JVM
>> java.lang.AssertionError: Expected [0]. Actual [1]: Check command [/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_jdk_tools_jpackage/scratch/10/./testMainLauncherIsModular.ed4f638d/output/MainLauncherIsModularAddLauncherTest/bin/ModularAppLauncher](1) exited with 0 code
>> 
>> The tests probably need to check `Desktop.isDesktopSupported()`, similarly how they check `GraphicsEnvironment.isHeadless()`.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 `tools/jpackage` (now pass)
>>  - [x] Linux x86_64 `tools/jpackage` (still pass)
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Reinstate trace message
>  - Move check higher

Marked as reviewed by asemenyuk (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2291

From shade at openjdk.java.net  Fri Jan 29 14:09:44 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 29 Jan 2021 14:09:44 GMT
Subject: Integrated: 8260592: jpackage tests fail when Desktop is not supported
In-Reply-To: <LxoXmxOCVkAxOpxADonAZaGzooDXIrqi1eBEe9eu-h0=.dfebfe41-279d-45ba-ab14-4e6b4f52a266@github.com>
References: <LxoXmxOCVkAxOpxADonAZaGzooDXIrqi1eBEe9eu-h0=.dfebfe41-279d-45ba-ab14-4e6b4f52a266@github.com>
Message-ID: <cd-0JyH9asoYH-QzYz8lvm-31OsQvnLmnP7TpEoKApk=.b5a0ee2d-a868-4979-a93a-b32db04e0ad8@github.com>

On Thu, 28 Jan 2021 14:33:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> If you run x86 configuration (cross-compiled on x86_64), then many tests would fail with:
> 
> $ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/jpackage
> ...
> can not load libgnomevfs-2.so
> Exception in thread "main" java.lang.ExceptionInInitializerError
> Caused by: java.lang.UnsupportedOperationException: Desktop API is not supported on the current platform
> at java.desktop/java.awt.Desktop.getDesktop(Unknown Source)
> at com.that/com.that.main.Florence.createInstance(Unknown Source)
> at com.that/com.that.main.Florence.<clinit>(Unknown Source)
> Failed to launch JVM
> java.lang.AssertionError: Expected [0]. Actual [1]: Check command [/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_jdk_tools_jpackage/scratch/10/./testMainLauncherIsModular.ed4f638d/output/MainLauncherIsModularAddLauncherTest/bin/ModularAppLauncher](1) exited with 0 code
> 
> The tests probably need to check `Desktop.isDesktopSupported()`, similarly how they check `GraphicsEnvironment.isHeadless()`.
> 
> Additional testing:
>  - [x] Linux x86_32 `tools/jpackage` (now pass)
>  - [x] Linux x86_64 `tools/jpackage` (still pass)

This pull request has now been integrated.

Changeset: 24a26212
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/24a26212
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

8260592: jpackage tests fail when Desktop is not supported

Reviewed-by: asemenyuk, herrick

-------------

PR: https://git.openjdk.java.net/jdk/pull/2291

From weijun at openjdk.java.net  Fri Jan 29 14:35:50 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 29 Jan 2021 14:35:50 GMT
Subject: RFR: 8257858: [macOS]: Remove JNF dependency from
 libosxsecurity/KeystoreImpl.m
In-Reply-To: <JwWl1EtSLT3WtyEh1DmkJPmjaxFCMR_csWSUexwnBUM=.45f91eb0-1f63-4989-9387-d904fc89dfae@github.com>
References: <JwWl1EtSLT3WtyEh1DmkJPmjaxFCMR_csWSUexwnBUM=.45f91eb0-1f63-4989-9387-d904fc89dfae@github.com>
Message-ID: <b9iew5yF3nN2jN3yfaPtWLrMMrnG0Dj8F1ZlU0cdGIA=.50f84d9f-56be-4188-9d53-d3feb80a857d@github.com>

On Fri, 18 Dec 2020 19:20:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This fix covers both
> 
> - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
> - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860)

New commit pushed. There is completely no dependency on JavaNativeFramework anymore.

Major change this time: Update the format of `SCDynamicStoreConfig::getKerberosConfig`.

ToDo: clean up `JNIUtilities.h`, take back `JNFPerformEnvBlock`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1845

From weijun at openjdk.java.net  Fri Jan 29 14:35:50 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 29 Jan 2021 14:35:50 GMT
Subject: RFR: 8257858: [macOS]: Remove JNF dependency from
 libosxsecurity/KeystoreImpl.m
Message-ID: <JwWl1EtSLT3WtyEh1DmkJPmjaxFCMR_csWSUexwnBUM=.45f91eb0-1f63-4989-9387-d904fc89dfae@github.com>

This fix covers both

- [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
- [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860)

-------------

Commit messages:
 - error check, new JavaStringToNSString
 - do not find class and method in loop
 - no more header file
 - better macro, no more JNI_COCOA_ENTER
 - Merge branch 'master' into 8257858
 - callback libosxsecurity/KeystoreImpl.m
 - new SCDynamicStoreConfig return value format
 - add framework so link succeeds
 - 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m

Changes: https://git.openjdk.java.net/jdk/pull/1845/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257858
  Stats: 484 lines in 6 files changed: 153 ins; 212 del; 119 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1845.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1845/head:pull/1845

PR: https://git.openjdk.java.net/jdk/pull/1845

From erikj at openjdk.java.net  Fri Jan 29 14:48:41 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 29 Jan 2021 14:48:41 GMT
Subject: RFR: 8257858: [macOS]: Remove JNF dependency from
 libosxsecurity/KeystoreImpl.m
In-Reply-To: <JwWl1EtSLT3WtyEh1DmkJPmjaxFCMR_csWSUexwnBUM=.45f91eb0-1f63-4989-9387-d904fc89dfae@github.com>
References: <JwWl1EtSLT3WtyEh1DmkJPmjaxFCMR_csWSUexwnBUM=.45f91eb0-1f63-4989-9387-d904fc89dfae@github.com>
Message-ID: <Tu05Z1AqgbLZMxbWmTH-abVes-MMLZEgysAIvocZ9Wg=.2ad5dcb3-7fea-4265-bbfe-6d3410ee4234@github.com>

On Fri, 18 Dec 2020 19:20:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This fix covers both
> 
> - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
> - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860)

Build changes look good.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1845

From weijun at openjdk.java.net  Fri Jan 29 14:57:56 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 29 Jan 2021 14:57:56 GMT
Subject: RFR: 8257858: [macOS]: Remove JNF dependency from
 libosxsecurity/KeystoreImpl.m [v2]
In-Reply-To: <JwWl1EtSLT3WtyEh1DmkJPmjaxFCMR_csWSUexwnBUM=.45f91eb0-1f63-4989-9387-d904fc89dfae@github.com>
References: <JwWl1EtSLT3WtyEh1DmkJPmjaxFCMR_csWSUexwnBUM=.45f91eb0-1f63-4989-9387-d904fc89dfae@github.com>
Message-ID: <-F0tHX1FDgcp-8kRi-EkcpfLHdDnEGtGxtPckeBkU4A=.7228511d-529c-4b52-8733-0e4bdaf0c789@github.com>

> This fix covers both
> 
> - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
> - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860)

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  same behavior as before -- empty realm map

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1845/files
  - new: https://git.openjdk.java.net/jdk/pull/1845/files/cb02503f..b0ee18a8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=00-01

  Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1845.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1845/head:pull/1845

PR: https://git.openjdk.java.net/jdk/pull/1845

From lancea at openjdk.java.net  Fri Jan 29 17:29:42 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 29 Jan 2021 17:29:42 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline [v3]
In-Reply-To: <d-jHqtj2YuUQSe-29Qbv3Z1m_NIjZXolL2iTNjRzaEE=.c68e8d9a-b909-417f-b814-242949d9585a@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
 <d-jHqtj2YuUQSe-29Qbv3Z1m_NIjZXolL2iTNjRzaEE=.c68e8d9a-b909-417f-b814-242949d9585a@github.com>
Message-ID: <HVYdGzPqWMHCfgX5Uo2cveGauaBVP-8IMdBJB8E-Rrw=.080470aa-d5f9-4298-9652-e5774848d41d@github.com>

On Fri, 29 Jan 2021 00:07:59 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Please review a patch to add an explicit control over whether a newline should be added after the XML header. This is done by adding a DOM LSSerializer property "jdk-is-standalone" and System property "jdk.xml.isStandalone". 
>> 
>> This change addresses an incompatibility introduced during 7u4 as an update to Xalan 2.7.1.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated the patch based on review comments. Refer to the previous reviews.

Hi Joe, 

The latest changes look fine

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2041

From darcy at openjdk.java.net  Fri Jan 29 17:31:09 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 29 Jan 2021 17:31:09 GMT
Subject: RFR: JDK-8257086: Clarify differences between {Float,
 Double}.equals and == [v3]
In-Reply-To: <sxbxBYIClZ26dmLvW8fUbnNPybVl_k16wHbBPEDx40o=.86762561-b05f-4814-a57b-e5fc02f58d8f@github.com>
References: <sxbxBYIClZ26dmLvW8fUbnNPybVl_k16wHbBPEDx40o=.86762561-b05f-4814-a57b-e5fc02f58d8f@github.com>
Message-ID: <ukjQIa0bXDIFUorR2JfOgNcUa0MKQ8Ji5pl391UdXEA=.a3e4509f-8141-4c3b-8697-a6a8f1314cde@github.com>

> Updates to the specifications of Double.{equals, compareTo} to explain more explicitly why the obvious wrappers around "==" and "<"/"==" are not sufficient for floating-point values.
> 
> Once the wording is worked out, I'll replicate it for the analogous methods on Float.

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 six additional commits since the last revision:

 - Merge branch 'master' into JDK-8257086
 - Update reworked wording from @smarks.
 - Merge branch 'master' into JDK-8257086
 - Merge branch 'master' into JDK-8257086
 - Fix whitespace
 - Initial work for JDK-8257086.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1699/files
  - new: https://git.openjdk.java.net/jdk/pull/1699/files/308b387d..9d80e279

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1699&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1699&range=01-02

  Stats: 61247 lines in 1475 files changed: 22192 ins; 24174 del; 14881 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1699/head:pull/1699

PR: https://git.openjdk.java.net/jdk/pull/1699

From rriggs at openjdk.java.net  Fri Jan 29 17:36:43 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 29 Jan 2021 17:36:43 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline [v3]
In-Reply-To: <d-jHqtj2YuUQSe-29Qbv3Z1m_NIjZXolL2iTNjRzaEE=.c68e8d9a-b909-417f-b814-242949d9585a@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
 <d-jHqtj2YuUQSe-29Qbv3Z1m_NIjZXolL2iTNjRzaEE=.c68e8d9a-b909-417f-b814-242949d9585a@github.com>
Message-ID: <1Z9MH2wG9qlY2EDH6HOov9HZH4w4Vm9ooiFtSUdPv4E=.5c98f78b-11db-4f69-9376-2714f8bcdf02@github.com>

On Fri, 29 Jan 2021 00:07:59 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Please review a patch to add an explicit control over whether a newline should be added after the XML header. This is done by adding a DOM LSSerializer property "jdk-is-standalone" and System property "jdk.xml.isStandalone". 
>> 
>> This change addresses an incompatibility introduced during 7u4 as an update to Xalan 2.7.1.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated the patch based on review comments. Refer to the previous reviews.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2041

From naoto at openjdk.java.net  Fri Jan 29 17:36:44 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 29 Jan 2021 17:36:44 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline [v3]
In-Reply-To: <d-jHqtj2YuUQSe-29Qbv3Z1m_NIjZXolL2iTNjRzaEE=.c68e8d9a-b909-417f-b814-242949d9585a@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
 <d-jHqtj2YuUQSe-29Qbv3Z1m_NIjZXolL2iTNjRzaEE=.c68e8d9a-b909-417f-b814-242949d9585a@github.com>
Message-ID: <wrGTu3yacZckFSWtzLCmJbF5zXstmkz9C7aTqZahmBQ=.665cec39-c824-4a63-91a8-8b6b5a519094@github.com>

On Fri, 29 Jan 2021 00:07:59 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Please review a patch to add an explicit control over whether a newline should be added after the XML header. This is done by adding a DOM LSSerializer property "jdk-is-standalone" and System property "jdk.xml.isStandalone". 
>> 
>> This change addresses an incompatibility introduced during 7u4 as an update to Xalan 2.7.1.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated the patch based on review comments. Refer to the previous reviews.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2041

From dfuchs at openjdk.java.net  Fri Jan 29 18:01:42 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 29 Jan 2021 18:01:42 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline [v3]
In-Reply-To: <d-jHqtj2YuUQSe-29Qbv3Z1m_NIjZXolL2iTNjRzaEE=.c68e8d9a-b909-417f-b814-242949d9585a@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
 <d-jHqtj2YuUQSe-29Qbv3Z1m_NIjZXolL2iTNjRzaEE=.c68e8d9a-b909-417f-b814-242949d9585a@github.com>
Message-ID: <mtvdawbY5rmFmTPSL8HbJtGuNynrp4h0lChZGE-UTbw=.11030cc8-0d32-451d-953c-53ef76511f06@github.com>

On Fri, 29 Jan 2021 00:07:59 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Please review a patch to add an explicit control over whether a newline should be added after the XML header. This is done by adding a DOM LSSerializer property "jdk-is-standalone" and System property "jdk.xml.isStandalone". 
>> 
>> This change addresses an incompatibility introduced during 7u4 as an update to Xalan 2.7.1.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated the patch based on review comments. Refer to the previous reviews.

I have just two cosmetic comments. Otherwise LGTM!

src/java.xml/share/classes/module-info.java line 78:

> 76:  * <h3>System Properties</h3>
> 77:  * A property may have a corresponding System Property that has the same name
> 78:  * except the prefix as shown above. A System Property should be set prior to

should that be "except for the prefix"?

src/java.xml/share/classes/module-info.java line 188:

> 186:  * </tbody>
> 187:  * </table>
> 188:  *

One question is whether the code samples in the table above should be escaped with {@code }. e.g.:

<td>
{@code first line of code;}<br>
{@code second line of code;}<br>
</td>

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2041

From joehw at openjdk.java.net  Fri Jan 29 18:24:59 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 29 Jan 2021 18:24:59 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline [v4]
In-Reply-To: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
Message-ID: <pCC0NuehZoT38ieEF1lV9hLSqcvYBc2bJBVbKYKa64o=.f5573242-3899-4c3f-ab6e-1f951a2c783d@github.com>

> Please review a patch to add an explicit control over whether a newline should be added after the XML header. This is done by adding a DOM LSSerializer property "jdk-is-standalone" and System property "jdk.xml.isStandalone". 
> 
> This change addresses an incompatibility introduced during 7u4 as an update to Xalan 2.7.1.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  update javadoc

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2041/files
  - new: https://git.openjdk.java.net/jdk/pull/2041/files/0ed62318..44a568b5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2041&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2041&range=02-03

  Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2041.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2041/head:pull/2041

PR: https://git.openjdk.java.net/jdk/pull/2041

From lancea at openjdk.java.net  Fri Jan 29 18:43:44 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 29 Jan 2021 18:43:44 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline [v3]
In-Reply-To: <mtvdawbY5rmFmTPSL8HbJtGuNynrp4h0lChZGE-UTbw=.11030cc8-0d32-451d-953c-53ef76511f06@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
 <d-jHqtj2YuUQSe-29Qbv3Z1m_NIjZXolL2iTNjRzaEE=.c68e8d9a-b909-417f-b814-242949d9585a@github.com>
 <mtvdawbY5rmFmTPSL8HbJtGuNynrp4h0lChZGE-UTbw=.11030cc8-0d32-451d-953c-53ef76511f06@github.com>
Message-ID: <i_zDyprfDzJ_i_F_6FK3DvbAdGgGBCBjb1FFGbD54Ts=.573d6295-dafd-40e5-84d8-25422781fb25@github.com>

On Fri, 29 Jan 2021 17:52:33 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated the patch based on review comments. Refer to the previous reviews.
>
> src/java.xml/share/classes/module-info.java line 78:
> 
>> 76:  * <h3>System Properties</h3>
>> 77:  * A property may have a corresponding System Property that has the same name
>> 78:  * except the prefix as shown above. A System Property should be set prior to
> 
> should that be "except for the prefix"?

yes that would be clearer

-------------

PR: https://git.openjdk.java.net/jdk/pull/2041

From smarks at openjdk.java.net  Fri Jan 29 18:58:45 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 29 Jan 2021 18:58:45 GMT
Subject: RFR: JDK-8257086: Clarify differences between {Float,
 Double}.equals and == [v3]
In-Reply-To: <ukjQIa0bXDIFUorR2JfOgNcUa0MKQ8Ji5pl391UdXEA=.a3e4509f-8141-4c3b-8697-a6a8f1314cde@github.com>
References: <sxbxBYIClZ26dmLvW8fUbnNPybVl_k16wHbBPEDx40o=.86762561-b05f-4814-a57b-e5fc02f58d8f@github.com>
 <ukjQIa0bXDIFUorR2JfOgNcUa0MKQ8Ji5pl391UdXEA=.a3e4509f-8141-4c3b-8697-a6a8f1314cde@github.com>
Message-ID: <UsKh-aZ4yFnR_bPhfmKhhBmXFOjpfQJh8kFU-rctaGk=.01055f48-528f-4157-9169-55a2b9de1fa6@github.com>

On Fri, 29 Jan 2021 17:31:09 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Updates to the specifications of Double.{equals, compareTo} to explain more explicitly why the obvious wrappers around "==" and "<"/"==" are not sufficient for floating-point values.
>> 
>> Once the wording is worked out, I'll replicate it for the analogous methods on Float.
>
> 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 six additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8257086
>  - Update reworked wording from @smarks.
>  - Merge branch 'master' into JDK-8257086
>  - Merge branch 'master' into JDK-8257086
>  - Fix whitespace
>  - Initial work for JDK-8257086.

Overall good! Just some whitespace errors and a couple typos as noted.

src/java.base/share/classes/java/lang/Double.java line 117:

> 115:  * 
> 116:  * <p>To provide the appropriate semantics for {@code equals} and {@code
> 117:  * compareTo} methods, those methods cannot simply to wrappers around

I think this should be "cannot simply be wrappers".

-------------

Marked as reviewed by smarks (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1699

From dfuchs at openjdk.java.net  Fri Jan 29 19:03:44 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 29 Jan 2021 19:03:44 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline [v4]
In-Reply-To: <pCC0NuehZoT38ieEF1lV9hLSqcvYBc2bJBVbKYKa64o=.f5573242-3899-4c3f-ab6e-1f951a2c783d@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
 <pCC0NuehZoT38ieEF1lV9hLSqcvYBc2bJBVbKYKa64o=.f5573242-3899-4c3f-ab6e-1f951a2c783d@github.com>
Message-ID: <pEcGoMX3F9TTyQvll5kFIc0PFzBOloKpSGYhDMgI41I=.47cebea7-2d71-42ad-99bd-3e911f90e5c6@github.com>

On Fri, 29 Jan 2021 18:24:59 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Please review a patch to add an explicit control over whether a newline should be added after the XML header. This is done by adding a DOM LSSerializer property "jdk-is-standalone" and System property "jdk.xml.isStandalone". 
>> 
>> This change addresses an incompatibility introduced during 7u4 as an update to Xalan 2.7.1.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update javadoc

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2041

From joehw at openjdk.java.net  Fri Jan 29 19:33:45 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 29 Jan 2021 19:33:45 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline [v3]
In-Reply-To: <i_zDyprfDzJ_i_F_6FK3DvbAdGgGBCBjb1FFGbD54Ts=.573d6295-dafd-40e5-84d8-25422781fb25@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
 <d-jHqtj2YuUQSe-29Qbv3Z1m_NIjZXolL2iTNjRzaEE=.c68e8d9a-b909-417f-b814-242949d9585a@github.com>
 <mtvdawbY5rmFmTPSL8HbJtGuNynrp4h0lChZGE-UTbw=.11030cc8-0d32-451d-953c-53ef76511f06@github.com>
 <i_zDyprfDzJ_i_F_6FK3DvbAdGgGBCBjb1FFGbD54Ts=.573d6295-dafd-40e5-84d8-25422781fb25@github.com>
Message-ID: <bNL9eFAjuRTqAC_CpdXTrIO8O_gJQ6nfJlLtoibl4Vo=.77ff4ab2-3d21-49e6-8530-174bedb5691a@github.com>

On Fri, 29 Jan 2021 18:40:55 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.xml/share/classes/module-info.java line 78:
>> 
>>> 76:  * <h3>System Properties</h3>
>>> 77:  * A property may have a corresponding System Property that has the same name
>>> 78:  * except the prefix as shown above. A System Property should be set prior to
>> 
>> should that be "except for the prefix"?
>
> yes that would be clearer

Changed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2041

From joehw at openjdk.java.net  Fri Jan 29 19:33:48 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 29 Jan 2021 19:33:48 GMT
Subject: RFR: 8249867: xml declaration is not followed by a newline [v3]
In-Reply-To: <mtvdawbY5rmFmTPSL8HbJtGuNynrp4h0lChZGE-UTbw=.11030cc8-0d32-451d-953c-53ef76511f06@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
 <d-jHqtj2YuUQSe-29Qbv3Z1m_NIjZXolL2iTNjRzaEE=.c68e8d9a-b909-417f-b814-242949d9585a@github.com>
 <mtvdawbY5rmFmTPSL8HbJtGuNynrp4h0lChZGE-UTbw=.11030cc8-0d32-451d-953c-53ef76511f06@github.com>
Message-ID: <oddRAeHrzln20JcSFi7D7ZSXDw2tfZYrAUyw-uyVt38=.1bbc7f6c-7086-4af9-8457-61e5650234f4@github.com>

On Fri, 29 Jan 2021 17:57:14 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated the patch based on review comments. Refer to the previous reviews.
>
> src/java.xml/share/classes/module-info.java line 188:
> 
>> 186:  * </tbody>
>> 187:  * </table>
>> 188:  *
> 
> One question is whether the code samples in the table above should be escaped with {@code }. e.g.:
> 
> <td>
> {@code first line of code;}<br>
> {@code second line of code;}<br>
> </td>

Looks better.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2041

From prr at openjdk.java.net  Fri Jan 29 21:19:48 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Jan 2021 21:19:48 GMT
Subject: RFR: 8257858: [macOS]: Remove JNF dependency from
 libosxsecurity/KeystoreImpl.m [v2]
In-Reply-To: <-F0tHX1FDgcp-8kRi-EkcpfLHdDnEGtGxtPckeBkU4A=.7228511d-529c-4b52-8733-0e4bdaf0c789@github.com>
References: <JwWl1EtSLT3WtyEh1DmkJPmjaxFCMR_csWSUexwnBUM=.45f91eb0-1f63-4989-9387-d904fc89dfae@github.com>
 <-F0tHX1FDgcp-8kRi-EkcpfLHdDnEGtGxtPckeBkU4A=.7228511d-529c-4b52-8733-0e4bdaf0c789@github.com>
Message-ID: <06TlDaeAfh41fK0rXHZkVqHJFccZuhTH6WX-VGihKH8=.67aa28d4-9576-4b68-a128-2015fb262c55@github.com>

On Fri, 29 Jan 2021 14:57:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This fix covers both
>> 
>> - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
>> - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860)
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   same behavior as before -- empty realm map

make/modules/java.security.jgss/Lib.gmk line 84:

> 82:             $(call SET_SHARED_LIBRARY_ORIGIN), \
> 83:         LIBS := -framework Cocoa -framework SystemConfiguration \
> 84:             -framework Kerberos -ljava, \

The need to add -ljava is interesting. It implies we were getting something from the platform that usually we'd expect to come from the JDK itself ??

src/java.base/macosx/classes/apple/security/KeychainStore.java line 820:

> 818:     private void createKeyEntry(String alias, long creationDate, long secKeyRef,
> 819:                                 long[] secCertificateRefs, byte[][] rawCertData) {
> 820:         KeyEntry ke = new KeyEntry();

removing these exceptions is presumably just clean up - not directly related ??

src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 28:

> 26: #import "apple_security_KeychainStore.h"
> 27: #include "jni.h"
> 28: #include "jni_util.h"

jni_util.h includes jni.h so I don't understand the need for this change.
Also why did you change import to include ? import is the Obj-C norm ...

src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 619:

> 617:             (*env)->ReleaseCharArrayElements(env, passwordObj, passwordChars,
> 618:                 JNI_ABORT);
> 619:         }

Although you have it in the later code, here you are missing
 @catch (NSException *e) { 
     NSLog(@"%@", [e callStackSymbols]); 
 }

src/java.security.jgss/macosx/native/libosxkrb5/SCDynamicStoreConfig.m line 41:

> 39:     if ([keys count] == 0) return;
> 40:     if (![keys containsObject:KERBEROS_DEFAULT_REALMS] && ![keys containsObject:KERBEROS_DEFAULT_REALM_MAPPINGS]) return;
> 41:     //    JNFPerformEnvBlock(JNFThreadDetachOnThreadDeath | JNFThreadSetSystemClassLoaderOnAttach | JNFThreadAttachAsDaemon, ^(JNIEnv *env) {

remove commented out code

src/java.security.jgss/macosx/native/libosxkrb5/SCDynamicStoreConfig.m line 57:

> 55:         }
> 56:     }
> 57:     (*localVM)->DetachCurrentThread(localVM);

I think you only want to detach if you actually attached ! you don't want to be detaching VM threads.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1845

From lancea at openjdk.java.net  Fri Jan 29 21:47:43 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 29 Jan 2021 21:47:43 GMT
Subject: RFR: 8260617: Merge ZipFile encoding check with the initial hash
 calculation
In-Reply-To: <rdXUh4BYI5qnXEVdDLeqhFj5URWwg5puLEZQSu8kLkY=.49f605d2-5de4-4da4-919f-9d4a40da53fd@github.com>
References: <rdXUh4BYI5qnXEVdDLeqhFj5URWwg5puLEZQSu8kLkY=.49f605d2-5de4-4da4-919f-9d4a40da53fd@github.com>
Message-ID: <KSwRXECNsdnWOQK741sTHU25sWI7P40NTzp4fH0ST_Q=.cf3705a7-d01e-4728-bde9-7a85a7c9babe@github.com>

On Fri, 29 Jan 2021 00:54:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Merge checkEncoding into the byte[]-based normalizedHash. The latter is only used from ZipFile.initCEN right after the checkEncoding today, so verifying this is equivalent is straightforward.
> - Factor out the logic to calculate hash, check encoding etc into the addEntry method to allow JITs to chew off larger chunks of the logic early on
> 
> Roughly 1.2x speedup on the JarFileMeta microbenchmarks, which include the time required to open the jar file and thus exercising the optimized code.
> 
> Testing: tier1-4

Hi Claes,

Overall, the changes seem good.  A few comments below.

src/java.base/share/classes/java/util/zip/ZipCoder.java line 140:

> 138:     // aborting the ASCII fast-path in the UTF8 implementation, so {@code h}
> 139:     // might be a partially calculated hash code
> 140:     int normalizedHashDecode(int h, byte[] a, int off, int end) {

Would it make sense to keep some of this comment for clarity?

src/java.base/share/classes/java/util/zip/ZipFile.java line 1531:

> 1529:                 entryPos = pos + CENHDR;
> 1530:             }
> 1531:             this.total = idx / 3;

It took me a moment to figure out why  you made the change of total = idx/3 but I understand now.

I guess my question  is this part of your change more performant as I think it was easier to read /understand when total was used?   

 If you believe this is the better way to go, I think it would be helpful to add a comment  as the change is not obvious on a first pass to the reader or at least me ;-)

src/java.base/share/classes/java/util/zip/ZipFile.java line 1501:

> 1499:                 if (entryPos + nlen > limit)
> 1500:                     zerror("invalid CEN header (bad header size)");
> 1501:                 idx = addEntry(idx, table, nlen, pos, entryPos);

Perhaps  consider adding  a comment describing addEntry.  Probably  similar to the  line 1500 comment (or similar) would be beneficial

-------------

PR: https://git.openjdk.java.net/jdk/pull/2306

From weijun at openjdk.java.net  Fri Jan 29 21:54:45 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 29 Jan 2021 21:54:45 GMT
Subject: RFR: 8257858: [macOS]: Remove JNF dependency from
 libosxsecurity/KeystoreImpl.m [v2]
In-Reply-To: <06TlDaeAfh41fK0rXHZkVqHJFccZuhTH6WX-VGihKH8=.67aa28d4-9576-4b68-a128-2015fb262c55@github.com>
References: <JwWl1EtSLT3WtyEh1DmkJPmjaxFCMR_csWSUexwnBUM=.45f91eb0-1f63-4989-9387-d904fc89dfae@github.com>
 <-F0tHX1FDgcp-8kRi-EkcpfLHdDnEGtGxtPckeBkU4A=.7228511d-529c-4b52-8733-0e4bdaf0c789@github.com>
 <06TlDaeAfh41fK0rXHZkVqHJFccZuhTH6WX-VGihKH8=.67aa28d4-9576-4b68-a128-2015fb262c55@github.com>
Message-ID: <VjydnD2mTqKUUjWMPSSmZbEpw2AyICbhHThot_Pa-4Q=.d7632094-9fb4-4be2-aec6-2dfd84a4ff5c@github.com>

On Fri, 29 Jan 2021 20:51:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   same behavior as before -- empty realm map
>
> make/modules/java.security.jgss/Lib.gmk line 84:
> 
>> 82:             $(call SET_SHARED_LIBRARY_ORIGIN), \
>> 83:         LIBS := -framework Cocoa -framework SystemConfiguration \
>> 84:             -framework Kerberos -ljava, \
> 
> The need to add -ljava is interesting. It implies we were getting something from the platform that usually we'd expect to come from the JDK itself ??

I tried removing it and the build runs fine. But I remember I have seen some error before.

> src/java.base/macosx/classes/apple/security/KeychainStore.java line 820:
> 
>> 818:     private void createKeyEntry(String alias, long creationDate, long secKeyRef,
>> 819:                                 long[] secCertificateRefs, byte[][] rawCertData) {
>> 820:         KeyEntry ke = new KeyEntry();
> 
> removing these exceptions is presumably just clean up - not directly related ??

Yes.

> src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 28:
> 
>> 26: #import "apple_security_KeychainStore.h"
>> 27: #include "jni.h"
>> 28: #include "jni_util.h"
> 
> jni_util.h includes jni.h so I don't understand the need for this change.
> Also why did you change import to include ? import is the Obj-C norm ...

Will fix.

> src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 619:
> 
>> 617:             (*env)->ReleaseCharArrayElements(env, passwordObj, passwordChars,
>> 618:                 JNI_ABORT);
>> 619:         }
> 
> Although you have it in the later code, here you are missing
>  @catch (NSException *e) { 
>      NSLog(@"%@", [e callStackSymbols]); 
>  }

Will add.

BTW, will these be shown on stdout or stderr? If so, is this a good idea?

> src/java.security.jgss/macosx/native/libosxkrb5/SCDynamicStoreConfig.m line 57:
> 
>> 55:         }
>> 56:     }
>> 57:     (*localVM)->DetachCurrentThread(localVM);
> 
> I think you only want to detach if you actually attached ! you don't want to be detaching VM threads.

So I should remember how env was retrieved and only detach when it's from `AttachCurrentThreadAsDaemon`? In fact, in my test the plain `GetEnv` has never succeeded and it was always attached.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1845

From prr at openjdk.java.net  Fri Jan 29 22:03:42 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Jan 2021 22:03:42 GMT
Subject: RFR: 8254702: jpackage app launcher crashes on CentOS
In-Reply-To: <aujMru5JWTuHatXdps6K9ewXlziyLN6MCb6hANcwhGU=.8acbb137-8178-41c9-8fce-e4cad8639fef@github.com>
References: <aujMru5JWTuHatXdps6K9ewXlziyLN6MCb6hANcwhGU=.8acbb137-8178-41c9-8fce-e4cad8639fef@github.com>
Message-ID: <f6Hrf5tR3DmorJUuPtgXz2eyfAgFkJYQFi7U-1CyeJ4=.deaf47f4-c24e-4e56-af53-e93dcb997b8c@github.com>

On Fri, 29 Jan 2021 21:33:40 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702
> 
> The fix splits Linux app launcher in app launcher and launcher shared lib. App launcher is pure C and doesn't have C++ code. App launcher lib incorporates bulk of C++ code from app launcher. 
> At startup app launcher loads launcher shared lib and calls functions it provides to get data for launching JVM (path to jli lib and arguments for JLI_Launch function call).
> App launcher unloads launcher shared lib before launching JVM to remove C++ runtime from the process memory.
> 
> Getting rid of C++ code from app launcher required to rewrite app installation location lookup code from C++ to C. LinuxPackage.c source is C alternative for https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Package.cpp and https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Executor.cpp.
> 
> Layout of jpackage's native code changed:
> - `common`: code shared between all jpackage binaries.
> - `applauncher`: launcher only code.
> - `applauncherlib`: launcher lib code on Linux and launcher code on other platforms.
> - `applaunchercommon`: code shared between launcher and launcher lib on Linux and launcher code on other platforms.

So after this change if you bundle and run an app on Linux and then do "ps" .. what is shown to be running ? Java or the app-name you expected ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2320

From prr at openjdk.java.net  Fri Jan 29 22:08:40 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Jan 2021 22:08:40 GMT
Subject: RFR: 8257858: [macOS]: Remove JNF dependency from
 libosxsecurity/KeystoreImpl.m [v2]
In-Reply-To: <VjydnD2mTqKUUjWMPSSmZbEpw2AyICbhHThot_Pa-4Q=.d7632094-9fb4-4be2-aec6-2dfd84a4ff5c@github.com>
References: <JwWl1EtSLT3WtyEh1DmkJPmjaxFCMR_csWSUexwnBUM=.45f91eb0-1f63-4989-9387-d904fc89dfae@github.com>
 <-F0tHX1FDgcp-8kRi-EkcpfLHdDnEGtGxtPckeBkU4A=.7228511d-529c-4b52-8733-0e4bdaf0c789@github.com>
 <06TlDaeAfh41fK0rXHZkVqHJFccZuhTH6WX-VGihKH8=.67aa28d4-9576-4b68-a128-2015fb262c55@github.com>
 <VjydnD2mTqKUUjWMPSSmZbEpw2AyICbhHThot_Pa-4Q=.d7632094-9fb4-4be2-aec6-2dfd84a4ff5c@github.com>
Message-ID: <EqXALU1z_EW0P1TDvTku4yClNvDfyaIpQjkmRXCAuHE=.4baa7da8-28fe-4a4b-abac-e88d745dd671@github.com>

On Fri, 29 Jan 2021 21:47:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 619:
>> 
>>> 617:             (*env)->ReleaseCharArrayElements(env, passwordObj, passwordChars,
>>> 618:                 JNI_ABORT);
>>> 619:         }
>> 
>> Although you have it in the later code, here you are missing
>>  @catch (NSException *e) { 
>>      NSLog(@"%@", [e callStackSymbols]); 
>>  }
>
> Will add.
> 
> BTW, will these be shown on stdout or stderr? If so, is this a good idea?

should be stderr. Whether to log is up to you. You could wrap it in something that checks for a debug build.
The idea is that if this ever happens there is a serious problem. NSException is only thrown (by the OS frameworks) in supposedly fatal scenarios.

>> src/java.security.jgss/macosx/native/libosxkrb5/SCDynamicStoreConfig.m line 57:
>> 
>>> 55:         }
>>> 56:     }
>>> 57:     (*localVM)->DetachCurrentThread(localVM);
>> 
>> I think you only want to detach if you actually attached ! you don't want to be detaching VM threads.
>
> So I should remember how env was retrieved and only detach when it's from `AttachCurrentThreadAsDaemon`? In fact, in my test the plain `GetEnv` has never succeeded and it was always attached.

Yes that is the idea. BTW which thread was it attached to in what you saw ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1845

From asemenyuk at openjdk.java.net  Fri Jan 29 22:20:41 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 29 Jan 2021 22:20:41 GMT
Subject: RFR: 8254702: jpackage app launcher crashes on CentOS
In-Reply-To: <f6Hrf5tR3DmorJUuPtgXz2eyfAgFkJYQFi7U-1CyeJ4=.deaf47f4-c24e-4e56-af53-e93dcb997b8c@github.com>
References: <aujMru5JWTuHatXdps6K9ewXlziyLN6MCb6hANcwhGU=.8acbb137-8178-41c9-8fce-e4cad8639fef@github.com>
 <f6Hrf5tR3DmorJUuPtgXz2eyfAgFkJYQFi7U-1CyeJ4=.deaf47f4-c24e-4e56-af53-e93dcb997b8c@github.com>
Message-ID: <wQI6ra72b41RgNCpCLgsPANRfFajbEyduMj5-nDWyVk=.a45e6922-6ce0-44ba-8935-01fc34645df2@github.com>

On Fri, 29 Jan 2021 22:00:32 GMT, Phil Race <prr at openjdk.org> wrote:

>> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702
>> 
>> The fix splits Linux app launcher in app launcher and launcher shared lib. App launcher is pure C and doesn't have C++ code. App launcher lib incorporates bulk of C++ code from app launcher. 
>> At startup app launcher loads launcher shared lib and calls functions it provides to get data for launching JVM (path to jli lib and arguments for JLI_Launch function call).
>> App launcher unloads launcher shared lib before launching JVM to remove C++ runtime from the process memory.
>> 
>> Getting rid of C++ code from app launcher required to rewrite app installation location lookup code from C++ to C. LinuxPackage.c source is C alternative for https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Package.cpp and https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Executor.cpp.
>> 
>> Layout of jpackage's native code changed:
>> - `common`: code shared between all jpackage binaries.
>> - `applauncher`: launcher only code.
>> - `applauncherlib`: launcher lib code on Linux and launcher code on other platforms.
>> - `applaunchercommon`: code shared between launcher and launcher lib on Linux and launcher code on other platforms.
>
> So after this change if you bundle and run an app on Linux and then do "ps" .. what is shown to be running ? Java or the app-name you expected ?

"ps" will show app-name. It was never Java for jpackage apps before this patch and this patch doesn't change it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2320

From weijun at openjdk.java.net  Fri Jan 29 22:38:39 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 29 Jan 2021 22:38:39 GMT
Subject: RFR: 8257858: [macOS]: Remove JNF dependency from
 libosxsecurity/KeystoreImpl.m [v2]
In-Reply-To: <EqXALU1z_EW0P1TDvTku4yClNvDfyaIpQjkmRXCAuHE=.4baa7da8-28fe-4a4b-abac-e88d745dd671@github.com>
References: <JwWl1EtSLT3WtyEh1DmkJPmjaxFCMR_csWSUexwnBUM=.45f91eb0-1f63-4989-9387-d904fc89dfae@github.com>
 <-F0tHX1FDgcp-8kRi-EkcpfLHdDnEGtGxtPckeBkU4A=.7228511d-529c-4b52-8733-0e4bdaf0c789@github.com>
 <06TlDaeAfh41fK0rXHZkVqHJFccZuhTH6WX-VGihKH8=.67aa28d4-9576-4b68-a128-2015fb262c55@github.com>
 <VjydnD2mTqKUUjWMPSSmZbEpw2AyICbhHThot_Pa-4Q=.d7632094-9fb4-4be2-aec6-2dfd84a4ff5c@github.com>
 <EqXALU1z_EW0P1TDvTku4yClNvDfyaIpQjkmRXCAuHE=.4baa7da8-28fe-4a4b-abac-e88d745dd671@github.com>
Message-ID: <zFKvPITJDc4MHXdhEbKI0DfFvIWVc990zsNU8G7UuGk=.61064682-211d-4525-8d87-8bac4efc86f3@github.com>

On Fri, 29 Jan 2021 22:05:21 GMT, Phil Race <prr at openjdk.org> wrote:

>> So I should remember how env was retrieved and only detach when it's from `AttachCurrentThreadAsDaemon`? In fact, in my test the plain `GetEnv` has never succeeded and it was always attached.
>
> Yes that is the idea. BTW which thread was it attached to in what you saw ?

It's a new thread in the main group. After the method finishes, the thread exits (`Thread::exit`).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1845

From weijun at openjdk.java.net  Fri Jan 29 22:47:52 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 29 Jan 2021 22:47:52 GMT
Subject: RFR: 8257858: [macOS]: Remove JNF dependency from
 libosxsecurity/KeystoreImpl.m [v3]
In-Reply-To: <JwWl1EtSLT3WtyEh1DmkJPmjaxFCMR_csWSUexwnBUM=.45f91eb0-1f63-4989-9387-d904fc89dfae@github.com>
References: <JwWl1EtSLT3WtyEh1DmkJPmjaxFCMR_csWSUexwnBUM=.45f91eb0-1f63-4989-9387-d904fc89dfae@github.com>
Message-ID: <XbxrkXhA9lF9W39Tqyewtfo7n1K9wZjHZD_NdKLo0zE=.059f0d4f-fe48-42f2-9d2e-2b4a88780f04@github.com>

> This fix covers both
> 
> - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
> - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860)

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  phil comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1845/files
  - new: https://git.openjdk.java.net/jdk/pull/1845/files/b0ee18a8..ba3d1a1f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=01-02

  Stats: 14 lines in 3 files changed: 7 ins; 3 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1845.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1845/head:pull/1845

PR: https://git.openjdk.java.net/jdk/pull/1845

From asemenyuk at openjdk.java.net  Fri Jan 29 23:06:20 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 29 Jan 2021 23:06:20 GMT
Subject: RFR: 8254702: jpackage app launcher crashes on CentOS [v2]
In-Reply-To: <aujMru5JWTuHatXdps6K9ewXlziyLN6MCb6hANcwhGU=.8acbb137-8178-41c9-8fce-e4cad8639fef@github.com>
References: <aujMru5JWTuHatXdps6K9ewXlziyLN6MCb6hANcwhGU=.8acbb137-8178-41c9-8fce-e4cad8639fef@github.com>
Message-ID: <BovHLhqJd8QYCq8L6aVoEAFh61_uFsFzv9lLd_8JLUU=.f3d1542d-568a-4bbf-a5ab-0158291002b3@github.com>

> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702
> 
> The fix splits Linux app launcher in app launcher and launcher shared lib. App launcher is pure C and doesn't have C++ code. App launcher lib incorporates bulk of C++ code from app launcher. 
> At startup app launcher loads launcher shared lib and calls functions it provides to get data for launching JVM (path to jli lib and arguments for JLI_Launch function call).
> App launcher unloads launcher shared lib before launching JVM to remove C++ runtime from the process memory.
> 
> Getting rid of C++ code from app launcher required to rewrite app installation location lookup code from C++ to C. LinuxPackage.c source is C alternative for https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Package.cpp and https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Executor.cpp.
> 
> Layout of jpackage's native code changed:
> - `common`: code shared between all jpackage binaries.
> - `applauncher`: launcher only code.
> - `applauncherlib`: launcher lib code on Linux and launcher code on other platforms.
> - `applaunchercommon`: code shared between launcher and launcher lib on Linux and launcher code on other platforms.

Alexey Semenyuk 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:

  8254702: jpackage app launcher crashes on CentOS

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2320/files
  - new: https://git.openjdk.java.net/jdk/pull/2320/files/14d277a2..b493bcfd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2320&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2320&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2320.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2320/head:pull/2320

PR: https://git.openjdk.java.net/jdk/pull/2320

From amenkov at openjdk.java.net  Fri Jan 29 23:09:40 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 29 Jan 2021 23:09:40 GMT
Subject: RFR: 8258917: NativeMemoryTracking is handled by launcher
 inconsistenly [v3]
In-Reply-To: <wg1g-bvGzVKDbQA2U0GHPGUoenGKMG6-uOSYP-WY_AM=.16384490-cc55-4854-bd7a-cf0cbea75e49@github.com>
References: <XppfMIMt-Js6GzD8SegBBEhNEN-6ywxmJ9_pjY6dY2c=.a53d5934-7f98-44f7-9d76-04fb4f1aadba@github.com>
 <Bs9EErmySj3EJ0myZdK55gJCEPorfMJIPwUCm-vhhyE=.8afc2742-b240-4eea-8ec1-9d44e7ae6e6f@github.com>
 <wg1g-bvGzVKDbQA2U0GHPGUoenGKMG6-uOSYP-WY_AM=.16384490-cc55-4854-bd7a-cf0cbea75e49@github.com>
Message-ID: <tGF5O3yOMyfy3hmiPHqF0VZeuJsrYy3BSBEfPdalWLg=.da590bea-853c-4a74-b472-f7dce6c06ca5@github.com>

On Thu, 28 Jan 2021 13:45:15 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated comment
>
> Sorry, I overlooked some of details. Final change looks fine to me.

@zhengyu123 Thank you for re-reviewing

@dholmes-ora RFE created: JDK-8260675

-------------

PR: https://git.openjdk.java.net/jdk/pull/2106

From redestad at openjdk.java.net  Fri Jan 29 23:16:11 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 29 Jan 2021 23:16:11 GMT
Subject: RFR: 8260617: Merge ZipFile encoding check with the initial hash
 calculation [v2]
In-Reply-To: <rdXUh4BYI5qnXEVdDLeqhFj5URWwg5puLEZQSu8kLkY=.49f605d2-5de4-4da4-919f-9d4a40da53fd@github.com>
References: <rdXUh4BYI5qnXEVdDLeqhFj5URWwg5puLEZQSu8kLkY=.49f605d2-5de4-4da4-919f-9d4a40da53fd@github.com>
Message-ID: <Mp_cS6eKyr9ZZS-p46SpWBr-zIUt00l6pbB5NmMHVcM=.0613e192-22c7-4f3d-ba0d-59cc4215cc53@github.com>

> - Merge checkEncoding into the byte[]-based normalizedHash. The latter is only used from ZipFile.initCEN right after the checkEncoding today, so verifying this is equivalent is straightforward.
> - Factor out the logic to calculate hash, check encoding etc into the addEntry method to allow JITs to chew off larger chunks of the logic early on
> 
> Roughly 1.2x speedup on the JarFileMeta microbenchmarks, which include the time required to open the jar file and thus exercising the optimized code.
> 
> Testing: tier1-4

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Refactor to do most entry validation in one place, out of line from initCEN.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2306/files
  - new: https://git.openjdk.java.net/jdk/pull/2306/files/ccf4d954..713e03b4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2306&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2306&range=00-01

  Stats: 71 lines in 2 files changed: 31 ins; 13 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2306.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2306/head:pull/2306

PR: https://git.openjdk.java.net/jdk/pull/2306

From redestad at openjdk.java.net  Fri Jan 29 23:21:44 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 29 Jan 2021 23:21:44 GMT
Subject: RFR: 8260617: Merge ZipFile encoding check with the initial hash
 calculation [v2]
In-Reply-To: <KSwRXECNsdnWOQK741sTHU25sWI7P40NTzp4fH0ST_Q=.cf3705a7-d01e-4728-bde9-7a85a7c9babe@github.com>
References: <rdXUh4BYI5qnXEVdDLeqhFj5URWwg5puLEZQSu8kLkY=.49f605d2-5de4-4da4-919f-9d4a40da53fd@github.com>
 <KSwRXECNsdnWOQK741sTHU25sWI7P40NTzp4fH0ST_Q=.cf3705a7-d01e-4728-bde9-7a85a7c9babe@github.com>
Message-ID: <KEzf9zc94VzmHhwmRc9_nXZKleAFykwTxBGETODHkRU=.69c1cc28-6741-4552-b79f-15d8d25a03d4@github.com>

On Fri, 29 Jan 2021 18:43:40 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor to do most entry validation in one place, out of line from initCEN.
>
> src/java.base/share/classes/java/util/zip/ZipCoder.java line 140:
> 
>> 138:     // aborting the ASCII fast-path in the UTF8 implementation, so {@code h}
>> 139:     // might be a partially calculated hash code
>> 140:     int normalizedHashDecode(int h, byte[] a, int off, int end) {
> 
> Would it make sense to keep some of this comment for clarity?

The comment is misleading after JDK-8260010 since the UTF8 implementation can't use this method, and I should have rewritten or removed it with JDK-8260010.

> src/java.base/share/classes/java/util/zip/ZipFile.java line 1501:
> 
>> 1499:                 if (entryPos + nlen > limit)
>> 1500:                     zerror("invalid CEN header (bad header size)");
>> 1501:                 idx = addEntry(idx, table, nlen, pos, entryPos);
> 
> Perhaps  consider adding  a comment describing addEntry.  Probably  similar to the  line 1500 comment (or similar) would be beneficial

I've refactored this code a bit further, both for clarity and to outline more related things into what's now `checkAndAddEntry`, which helps startup time as measured with a spring-petclinic startup test (time spent opening 393 jar files drop from ~46 to ~41ms on my setup).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2306

From prr at openjdk.java.net  Sat Jan 30 00:09:44 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 30 Jan 2021 00:09:44 GMT
Subject: RFR: 8257858: [macOS]: Remove JNF dependency from
 libosxsecurity/KeystoreImpl.m [v3]
In-Reply-To: <XbxrkXhA9lF9W39Tqyewtfo7n1K9wZjHZD_NdKLo0zE=.059f0d4f-fe48-42f2-9d2e-2b4a88780f04@github.com>
References: <JwWl1EtSLT3WtyEh1DmkJPmjaxFCMR_csWSUexwnBUM=.45f91eb0-1f63-4989-9387-d904fc89dfae@github.com>
 <XbxrkXhA9lF9W39Tqyewtfo7n1K9wZjHZD_NdKLo0zE=.059f0d4f-fe48-42f2-9d2e-2b4a88780f04@github.com>
Message-ID: <LRTVqQyYspXJCBPiKvg4lcBYjLu8QuvV8pfTI9o9sEU=.4eddabbf-b0e4-41cf-bda2-db947e79016e@github.com>

On Fri, 29 Jan 2021 22:47:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This fix covers both
>> 
>> - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
>> - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860)
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   phil comment

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1845

From darcy at openjdk.java.net  Sat Jan 30 00:15:57 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 30 Jan 2021 00:15:57 GMT
Subject: RFR: JDK-8257086: Clarify differences between {Float,
 Double}.equals and == [v4]
In-Reply-To: <sxbxBYIClZ26dmLvW8fUbnNPybVl_k16wHbBPEDx40o=.86762561-b05f-4814-a57b-e5fc02f58d8f@github.com>
References: <sxbxBYIClZ26dmLvW8fUbnNPybVl_k16wHbBPEDx40o=.86762561-b05f-4814-a57b-e5fc02f58d8f@github.com>
Message-ID: <oRGoGM1a0NeRJZ9u84Bz0r2-J_0iEybfe-Xr4ZxxqEM=.3759a03c-3eb4-4d74-9323-487cdeb09bf5@github.com>

> Updates to the specifications of Double.{equals, compareTo} to explain more explicitly why the obvious wrappers around "==" and "<"/"==" are not sufficient for floating-point values.
> 
> Once the wording is worked out, I'll replicate it for the analogous methods on Float.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Editing pass on changes in Double; add accommodations in Float.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1699/files
  - new: https://git.openjdk.java.net/jdk/pull/1699/files/9d80e279..072c40d9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1699&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1699&range=02-03

  Stats: 78 lines in 2 files changed: 18 ins; 15 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1699/head:pull/1699

PR: https://git.openjdk.java.net/jdk/pull/1699

From mik3hall at gmail.com  Sat Jan 30 01:37:17 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 29 Jan 2021 19:37:17 -0600
Subject: bug jpackage in JDK 15
In-Reply-To: <6450AD66-0DCF-41DA-8028-7621BD9FC42C@gmail.com>
References: <CAH2-wONu7wpxBmgKL8qx3cB+NWfnNLw-XTqCMLqnUZ2JjuDtkA@mail.gmail.com>
 <0DF4D073-FAD7-4708-AECE-51BD0720957F@gmail.com>
 <C7A06A93-AF65-4379-8D82-445893891E04@gmail.com>
 <6450AD66-0DCF-41DA-8028-7621BD9FC42C@gmail.com>
Message-ID: <9EED7FF5-050F-49C1-AD0B-DB7A8F8F45E4@gmail.com>



> On Jan 26, 2021, at 7:16 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
>> 
>> 
>> When I open the built dmg there is an application icon, a drag to indicating arrow, but no application folder icon as the drag target.
>> 
>> Possibly related?
>> 
>> Running [osascript, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack Blastoff-dmg-setup.scpt]
>> /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack Blastoff-dmg-setup.scpt:1112:1334: execution error: Finder got an error: Can?t make class alias file. (-2710)
>> java.io.IOException: Command [osascript, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack Blastoff-dmg-setup.scpt] exited with 1 code
>> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Executor.executeExpectSuccess(Executor.java:75)
>> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:167)
>> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:135)
>> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.buildDMG(MacDmgBundler.java:393)
>> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.bundle(MacDmgBundler.java:91)
>> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.execute(MacDmgBundler.java:535)
>> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:680)
>> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:549)
>> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:98)
>> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:52)

This doesn?t necessarily seem to be security related. So possibly not related to my other problem.
I was going to try and re-open a bug report but that doesn?t appear currently possible for me.

It seems it could possibly be the path for the Applications folder. Say if you want something nice to get a name without a forward slash.
Based on DMGSetup.scpt?

tell application "Finder"
	set DEPLOY_VOLUME_PATH to "/Volumes/TestImage/"
	set DEPLOY_INSTALL_LOCATION to "Applications"
	set DEPLOY_INSTALL_NAME to "Applications"
	make new alias file at POSIX file DEPLOY_VOLUME_PATH to POSIX file DEPLOY_INSTALL_LOCATION with properties {name:DEPLOY_INSTALL_LOCATION}
end tell

tell application "Finder"
	make new alias file at file "TestImage:" to file ":Applications" with properties {name:"Applications"}
Result:
error "Finder got an error: Can?t make class alias file." number -2710 from alias file to class

You get the same error. Note INSTALL_LOCATION is used for both destination and name.

If you make that a correct path with forward slash but have a separate name variable without forward slash for the name.

tell application "Finder"
	make new alias file at file "TestImage:" to file "Macintosh HD:Applications:" with properties {name:"Applications"}
end tell
Result:
alias file "Applications" of disk "TestImage" of application ?Finder?

It works. I?m not sure unless something changed why that would suddenly be broke but it does seem to be for DMG?s. 








From darcy at openjdk.java.net  Sat Jan 30 01:50:42 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 30 Jan 2021 01:50:42 GMT
Subject: RFR: JDK-8257086: Clarify differences between {Float,
 Double}.equals and == [v4]
In-Reply-To: <sgXhxo4YJcMNZFoZxEoJULgGMcvfVqN9ZoAKMVlPKMM=.a219671b-5322-4103-897a-2e2d4a180a4b@github.com>
References: <sxbxBYIClZ26dmLvW8fUbnNPybVl_k16wHbBPEDx40o=.86762561-b05f-4814-a57b-e5fc02f58d8f@github.com>
 <sgXhxo4YJcMNZFoZxEoJULgGMcvfVqN9ZoAKMVlPKMM=.a219671b-5322-4103-897a-2e2d4a180a4b@github.com>
Message-ID: <Jq_QvBOH25EJnjUVxls2FLBXI_fXIJRw2ieJOFarj34=.52af9d8f-8507-4841-a222-1305f900fdee@github.com>

On Tue, 8 Dec 2020 17:10:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Editing pass on changes in Double; add accommodations in Float.
>
> src/java.base/share/classes/java/lang/Double.java line 1008:
> 
>> 1006:      * This method imposes a total order on {@code Double} objects
>> 1007:      * with two differences compared to the incomplete order defined the
>> 1008:      * by Java language numerical comparison operators ({@code <, <=,
> 
> Typo: defined the by Java -> defined by the Java.

Will fix; thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1699

From darcy at openjdk.java.net  Sat Jan 30 01:58:02 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 30 Jan 2021 01:58:02 GMT
Subject: RFR: JDK-8257086: Clarify differences between {Float,
 Double}.equals and == [v5]
In-Reply-To: <sxbxBYIClZ26dmLvW8fUbnNPybVl_k16wHbBPEDx40o=.86762561-b05f-4814-a57b-e5fc02f58d8f@github.com>
References: <sxbxBYIClZ26dmLvW8fUbnNPybVl_k16wHbBPEDx40o=.86762561-b05f-4814-a57b-e5fc02f58d8f@github.com>
Message-ID: <HL4KGJ8CfPPtMJKBYXSz6Ar3lVG3KnxI1XImGQKymfw=.7d768c4e-762b-40a7-acd6-0253e91308f0@github.com>

> Updates to the specifications of Double.{equals, compareTo} to explain more explicitly why the obvious wrappers around "==" and "<"/"==" are not sufficient for floating-point values.
> 
> Once the wording is worked out, I'll replicate it for the analogous methods on Float.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Fix typos noticed by @bplb.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1699/files
  - new: https://git.openjdk.java.net/jdk/pull/1699/files/072c40d9..b419ca79

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1699&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1699&range=03-04

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1699/head:pull/1699

PR: https://git.openjdk.java.net/jdk/pull/1699

From almatvee at openjdk.java.net  Sat Jan 30 02:36:44 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Sat, 30 Jan 2021 02:36:44 GMT
Subject: RFR: 8254702: jpackage app launcher crashes on CentOS [v2]
In-Reply-To: <BovHLhqJd8QYCq8L6aVoEAFh61_uFsFzv9lLd_8JLUU=.f3d1542d-568a-4bbf-a5ab-0158291002b3@github.com>
References: <aujMru5JWTuHatXdps6K9ewXlziyLN6MCb6hANcwhGU=.8acbb137-8178-41c9-8fce-e4cad8639fef@github.com>
 <BovHLhqJd8QYCq8L6aVoEAFh61_uFsFzv9lLd_8JLUU=.f3d1542d-568a-4bbf-a5ab-0158291002b3@github.com>
Message-ID: <NGKIi7u1jJciEzWXi0Pdm1M8IODzzVEdsesWORzmDSk=.f8a4e162-2800-4ec2-892a-924b4d257513@github.com>

On Fri, 29 Jan 2021 23:06:20 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702
>> 
>> The fix splits Linux app launcher in app launcher and launcher shared lib. App launcher is pure C and doesn't have C++ code. App launcher lib incorporates bulk of C++ code from app launcher. 
>> At startup app launcher loads launcher shared lib and calls functions it provides to get data for launching JVM (path to jli lib and arguments for JLI_Launch function call).
>> App launcher unloads launcher shared lib before launching JVM to remove C++ runtime from the process memory.
>> 
>> Getting rid of C++ code from app launcher required to rewrite app installation location lookup code from C++ to C. LinuxPackage.c source is C alternative for https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Package.cpp and https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Executor.cpp.
>> 
>> Layout of jpackage's native code changed:
>> - `common`: code shared between all jpackage binaries.
>> - `applauncher`: launcher only code.
>> - `applauncherlib`: launcher lib code on Linux and launcher code on other platforms.
>> - `applaunchercommon`: code shared between launcher and launcher lib on Linux and launcher code on other platforms.
>
> Alexey Semenyuk 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.

Marked as reviewed by almatvee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2320

From joehw at openjdk.java.net  Sat Jan 30 02:37:41 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Sat, 30 Jan 2021 02:37:41 GMT
Subject: Integrated: 8249867: xml declaration is not followed by a newline
In-Reply-To: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
References: <3ZaAaovwzo3JDek5H9c9z-SdU1G_AtAa3Cvr8zuYSVg=.f6b54700-6cf7-4285-901d-9f7e5238e1c3@github.com>
Message-ID: <lPdwL8T3WOisR8dsm4iIOb2sJy5PeVlEU91uQT3LQ1g=.16926d56-6221-4646-a99f-d9a8405386ee@github.com>

On Tue, 12 Jan 2021 01:24:38 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Please review a patch to add an explicit control over whether a newline should be added after the XML header. This is done by adding a DOM LSSerializer property "jdk-is-standalone" and System property "jdk.xml.isStandalone". 
> 
> This change addresses an incompatibility introduced during 7u4 as an update to Xalan 2.7.1.

This pull request has now been integrated.

Changeset: 69ee314b
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/69ee314b
Stats:     479 lines in 5 files changed: 428 ins; 2 del; 49 mod

8249867: xml declaration is not followed by a newline

Reviewed-by: rriggs, naoto, lancea, dfuchs

-------------

PR: https://git.openjdk.java.net/jdk/pull/2041

From jpai at openjdk.java.net  Sat Jan 30 14:40:51 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 30 Jan 2021 14:40:51 GMT
Subject: RFR: 8260401: StackOverflowError on open WindowsPreferences
Message-ID: <iwCaHBTAU6cVMrHNlWTc0zniFxrWLWfJIpRnww6zY7A=.f69ec5ec-882f-4fa4-a435-713c65ecfee5@github.com>

Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8260401?

As noted in that issue, when the constructor of `java.util.prefs.WindowsPreferences` runs into an error while dealing with the Windows registry, it logs a warning message. The message construction calls `rootNativeHandle()` (on the same instance of `WindowsPreferences` that's being constructed) which then ultimately ends up calling the constructor of `WindowsPreferences` which then again runs into the Windows registry error and attempts to log a message and this whole cycle repeats indefinitely leading to that `StackOverFlowError`. 

Based on my limited knowledge of the code in that constructor and analyzing that code a bit, it's my understanding (and also the input provided by the reporter of the bug) that the log message should actually be using the `rootNativeHandle` parameter that is passed to this constructor instead of invoking the `rootNativeHandle()` method. The commit in this PR does this change to use the passed `rootNativeHandle` in the log message.

Furthermore, there's another constructor in this class which does a similar thing and potentially can run into the same error as this one. I've changed that constructor too, to avoid the call to `rootNativeHandle()` method in that log message. Reading the log message that's being generated there, it's my understanding that this change shouldn't cause any inaccuracy in what's being logged and in fact, I think it's now more precise about which handle returned the error code.

Finally, this log message creation, in both the constructors, also calls `windowsAbsolutePath()` and `byteArrayToString()` methods. The `byteArrayToString()` is a static method and a call to it doesn't lead back to the constructor again. The `windowsAbsolutePath()` is a instance method and although it does use a instance variable `absolutePath`, that instance variable is already initialized appropriately by the time this `windowsAbsolutePath()` gets called in the log message. Also, the `windowsAbsolutePath()` call doesn't lead back to the constructor of the `WindowsPreferences` so it doesn't pose the same issue as a call to `rootNativeHandle()`.

Given the nature of this issue, I haven't added any jtreg test for this change.

-------------

Commit messages:
 - 8260401: StackOverflowError on open WindowsPreferences

Changes: https://git.openjdk.java.net/jdk/pull/2326/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2326&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260401
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2326.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2326/head:pull/2326

PR: https://git.openjdk.java.net/jdk/pull/2326

From weijun at openjdk.java.net  Sat Jan 30 15:23:09 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sat, 30 Jan 2021 15:23:09 GMT
Subject: RFR: 8257858: [macOS]: Remove JNF dependency from
 libosxsecurity/KeystoreImpl.m [v4]
In-Reply-To: <JwWl1EtSLT3WtyEh1DmkJPmjaxFCMR_csWSUexwnBUM=.45f91eb0-1f63-4989-9387-d904fc89dfae@github.com>
References: <JwWl1EtSLT3WtyEh1DmkJPmjaxFCMR_csWSUexwnBUM=.45f91eb0-1f63-4989-9387-d904fc89dfae@github.com>
Message-ID: <KN-93fVL4UxG4XVlGx6Q8BZiLAb2Z_JBNzp8IZFHFRQ=.d024249d-a156-42df-b81a-d30416ac40be@github.com>

> This fix covers both
> 
> - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
> - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860)

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  end values should be vectors

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1845/files
  - new: https://git.openjdk.java.net/jdk/pull/1845/files/ba3d1a1f..a0cad8fd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=02-03

  Stats: 12 lines in 1 file changed: 8 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1845.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1845/head:pull/1845

PR: https://git.openjdk.java.net/jdk/pull/1845

From weijun at openjdk.java.net  Sat Jan 30 18:07:22 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sat, 30 Jan 2021 18:07:22 GMT
Subject: RFR: 8257858: [macOS]: Remove JNF dependency from
 libosxsecurity/KeystoreImpl.m [v5]
In-Reply-To: <JwWl1EtSLT3WtyEh1DmkJPmjaxFCMR_csWSUexwnBUM=.45f91eb0-1f63-4989-9387-d904fc89dfae@github.com>
References: <JwWl1EtSLT3WtyEh1DmkJPmjaxFCMR_csWSUexwnBUM=.45f91eb0-1f63-4989-9387-d904fc89dfae@github.com>
Message-ID: <VpVIMZOdsJqlwbECbbmzfsqAx1MvvM9QL1u1Ow9-gO8=.4b5cc68b-9868-419f-b3c9-181f3d94c7ca@github.com>

> This fix covers both
> 
> - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
> - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860)

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  a test
  
  only in patch2:
  unchanged:

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1845/files
  - new: https://git.openjdk.java.net/jdk/pull/1845/files/a0cad8fd..38616b32

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=03-04

  Stats: 200 lines in 3 files changed: 199 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1845.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1845/head:pull/1845

PR: https://git.openjdk.java.net/jdk/pull/1845

From weijun at openjdk.java.net  Sat Jan 30 18:07:23 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sat, 30 Jan 2021 18:07:23 GMT
Subject: RFR: 8257858: [macOS]: Remove JNF dependency from
 libosxsecurity/KeystoreImpl.m [v3]
In-Reply-To: <LRTVqQyYspXJCBPiKvg4lcBYjLu8QuvV8pfTI9o9sEU=.4eddabbf-b0e4-41cf-bda2-db947e79016e@github.com>
References: <JwWl1EtSLT3WtyEh1DmkJPmjaxFCMR_csWSUexwnBUM=.45f91eb0-1f63-4989-9387-d904fc89dfae@github.com>
 <XbxrkXhA9lF9W39Tqyewtfo7n1K9wZjHZD_NdKLo0zE=.059f0d4f-fe48-42f2-9d2e-2b4a88780f04@github.com>
 <LRTVqQyYspXJCBPiKvg4lcBYjLu8QuvV8pfTI9o9sEU=.4eddabbf-b0e4-41cf-bda2-db947e79016e@github.com>
Message-ID: <vGtRa2bbk6nZlSshwWMpajGcyfPqHqq_p524vMKkmh8=.82540301-c0d2-45a6-bea6-0878e510ba47@github.com>

On Sat, 30 Jan 2021 00:06:51 GMT, Phil Race <prr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   phil comment
>
> Marked as reviewed by prr (Reviewer).

Added a test. Unfortunately it has to be `manual` because updating the dynamic store needs `sudo` privilege.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1845

From dfranken.jdk at gmail.com  Sat Jan 30 18:30:06 2021
From: dfranken.jdk at gmail.com (dfranken.jdk at gmail.com)
Date: Sat, 30 Jan 2021 19:30:06 +0100
Subject: Why does Set.of disallow duplicate elements?
Message-ID: <a0171e042852fa76d34a6beac49ff534d8361663.camel@gmail.com>

Dear users,

While looking at the implementation of Set.of(...) I noticed that
duplicate elements are not allowed, e.g. Set.of(1, 1) will throw an
IllegalArgumentException. Why has it been decided to do this?

My expectation was that duplicates would simply be removed.

If I do for instance new HashSet<>(<collection containing duplicates>)
it works and duplicates are removed. To me, it looks a bit inconsistent
to have duplicates removed for a collection passed in the constructor,
but not for a collection (even though it is a vararg array) passed to a
static factory method.

Kind regards,

Dave Franken


From redestad at openjdk.java.net  Sat Jan 30 18:30:59 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sat, 30 Jan 2021 18:30:59 GMT
Subject: RFR: 8260617: Merge ZipFile encoding check with the initial hash
 calculation [v3]
In-Reply-To: <rdXUh4BYI5qnXEVdDLeqhFj5URWwg5puLEZQSu8kLkY=.49f605d2-5de4-4da4-919f-9d4a40da53fd@github.com>
References: <rdXUh4BYI5qnXEVdDLeqhFj5URWwg5puLEZQSu8kLkY=.49f605d2-5de4-4da4-919f-9d4a40da53fd@github.com>
Message-ID: <PYILyZ4GY87AjacFMUp-j4LYS6PRYQ3gUw4kSvoMYu0=.ca4fc812-f255-4179-bb7b-fd4080c2a55d@github.com>

> - Merge checkEncoding into the byte[]-based normalizedHash. The latter is only used from ZipFile.initCEN right after the checkEncoding today, so verifying this is equivalent is straightforward.
> - Factor out the logic to calculate hash, check encoding etc into the addEntry method to allow JITs to chew off larger chunks of the logic early on
> 
> Roughly 1.2x speedup on the JarFileMeta microbenchmarks, which include the time required to open the jar file and thus exercising the optimized code.
> 
> Testing: tier1-4

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Clarify comments, put normal path branch first in UTF8 checkedHash

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2306/files
  - new: https://git.openjdk.java.net/jdk/pull/2306/files/713e03b4..bb1659e3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2306&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2306&range=01-02

  Stats: 12 lines in 1 file changed: 4 ins; 5 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2306.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2306/head:pull/2306

PR: https://git.openjdk.java.net/jdk/pull/2306

From forax at univ-mlv.fr  Sat Jan 30 20:30:04 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 30 Jan 2021 21:30:04 +0100 (CET)
Subject: Why does Set.of disallow duplicate elements?
In-Reply-To: <a0171e042852fa76d34a6beac49ff534d8361663.camel@gmail.com>
References: <a0171e042852fa76d34a6beac49ff534d8361663.camel@gmail.com>
Message-ID: <2099264599.1848135.1612038604962.JavaMail.zimbra@u-pem.fr>

Set.of() is the closest way we've got to a literal Set without having introduced a special syntax for that in the language.

The idea is that if you conceptually want to write
  Set<String> set = { "hello", "world" };
instead, you write
  Set<String> set = Set.of("hello", "world");

In that context, it makes sense to reject Set constructed with the same element twice because this is usually a programming error.
So
  Set.of("hello", "hello")
throws an IAE.

If you want a Set from a collection of elements, you can use
  Set.copyOf(List.of("hello", "hello"))

regards,
R?mi

----- Mail original -----
> De: "dfranken jdk" <dfranken.jdk at gmail.com>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Samedi 30 Janvier 2021 19:30:06
> Objet: Why does Set.of disallow duplicate elements?

> Dear users,
> 
> While looking at the implementation of Set.of(...) I noticed that
> duplicate elements are not allowed, e.g. Set.of(1, 1) will throw an
> IllegalArgumentException. Why has it been decided to do this?
> 
> My expectation was that duplicates would simply be removed.
> 
> If I do for instance new HashSet<>(<collection containing duplicates>)
> it works and duplicates are removed. To me, it looks a bit inconsistent
> to have duplicates removed for a collection passed in the constructor,
> but not for a collection (even though it is a vararg array) passed to a
> static factory method.
> 
> Kind regards,
> 
> Dave Franken

From mik3hall at gmail.com  Sat Jan 30 21:14:21 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 30 Jan 2021 15:14:21 -0600
Subject: bug jpackage in JDK 15
In-Reply-To: <9EED7FF5-050F-49C1-AD0B-DB7A8F8F45E4@gmail.com>
References: <CAH2-wONu7wpxBmgKL8qx3cB+NWfnNLw-XTqCMLqnUZ2JjuDtkA@mail.gmail.com>
 <0DF4D073-FAD7-4708-AECE-51BD0720957F@gmail.com>
 <C7A06A93-AF65-4379-8D82-445893891E04@gmail.com>
 <6450AD66-0DCF-41DA-8028-7621BD9FC42C@gmail.com>
 <9EED7FF5-050F-49C1-AD0B-DB7A8F8F45E4@gmail.com>
Message-ID: <74CB986F-8256-4B12-9B7D-9F7D6A241D0E@gmail.com>



> On Jan 29, 2021, at 7:37 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Jan 26, 2021, at 7:16 PM, Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
>> 
>>> 
>>> 
>>> When I open the built dmg there is an application icon, a drag to indicating arrow, but no application folder icon as the drag target.
>>> 
>>> Possibly related?
>>> 
>>> Running [osascript, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack Blastoff-dmg-setup.scpt]
>>> /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack Blastoff-dmg-setup.scpt:1112:1334: execution error: Finder got an error: Can?t make class alias file. (-2710)
>>> java.io.IOException: Command [osascript, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack Blastoff-dmg-setup.scpt] exited with 1 code
>>> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Executor.executeExpectSuccess(Executor.java:75)
>>> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:167)
>>> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:135)
>>> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.buildDMG(MacDmgBundler.java:393)
>>> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.bundle(MacDmgBundler.java:91)
>>> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.execute(MacDmgBundler.java:535)
>>> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:680)
>>> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:549)
>>> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:98)
>>> 	at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:52)
> 
> This doesn?t necessarily seem to be security related. So possibly not related to my other problem.
> I was going to try and re-open a bug report but that doesn?t appear currently possible for me.
> 
> It seems it could possibly be the path for the Applications folder. Say if you want something nice to get a name without a forward slash.
> Based on DMGSetup.scpt?
> 
> tell application "Finder"
> 	set DEPLOY_VOLUME_PATH to "/Volumes/TestImage/"
> 	set DEPLOY_INSTALL_LOCATION to "Applications"
> 	set DEPLOY_INSTALL_NAME to "Applications"
> 	make new alias file at POSIX file DEPLOY_VOLUME_PATH to POSIX file DEPLOY_INSTALL_LOCATION with properties {name:DEPLOY_INSTALL_LOCATION}
> end tell
> 
> tell application "Finder"
> 	make new alias file at file "TestImage:" to file ":Applications" with properties {name:"Applications"}
> Result:
> error "Finder got an error: Can?t make class alias file." number -2710 from alias file to class
> 
> You get the same error. Note INSTALL_LOCATION is used for both destination and name.
> 
> If you make that a correct path with forward slash but have a separate name variable without forward slash for the name.
> 
> tell application "Finder"
> 	make new alias file at file "TestImage:" to file "Macintosh HD:Applications:" with properties {name:"Applications"}
> end tell
> Result:
> alias file "Applications" of disk "TestImage" of application ?Finder?
> 
> It works. I?m not sure unless something changed why that would suddenly be broke but it does seem to be for DMG?s. 

This was a hypothetical, hopefully plausible, possibility that reproduced the actual error. I don?t work on the JDK and don?t know how I would debug to get the values actually being passed. Possibly a ?debug? option where the script output is saved instead of being written to a temporary file and disappearing could be useful?


From martin at openjdk.java.net  Sat Jan 30 21:29:59 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sat, 30 Jan 2021 21:29:59 GMT
Subject: RFR: 8259074: regex benchmarks and tests
Message-ID: <dUQnlQE4mrODO0V9bxIinjylxDIWiuDHRK9CvWxRU08=.b0bf4cc0-09e8-4ea6-9414-01ba3a8886da@github.com>

8259074: regex benchmarks and tests

-------------

Commit messages:
 - more benchmarks
 - JDK-8259074

Changes: https://git.openjdk.java.net/jdk/pull/1940/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1940&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259074
  Stats: 444 lines in 5 files changed: 442 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1940.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1940/head:pull/1940

PR: https://git.openjdk.java.net/jdk/pull/1940

From martin at openjdk.java.net  Sat Jan 30 21:35:41 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sat, 30 Jan 2021 21:35:41 GMT
Subject: RFR: 8259074: regex benchmarks and tests
In-Reply-To: <dUQnlQE4mrODO0V9bxIinjylxDIWiuDHRK9CvWxRU08=.b0bf4cc0-09e8-4ea6-9414-01ba3a8886da@github.com>
References: <dUQnlQE4mrODO0V9bxIinjylxDIWiuDHRK9CvWxRU08=.b0bf4cc0-09e8-4ea6-9414-01ba3a8886da@github.com>
Message-ID: <ab_XV9IlVxcjDYTOXRxSXkcnNNYGkpmpgCXzNHrJx6M=.5aa530dc-6b70-42d7-bd6f-197fb99005ca@github.com>

On Tue, 5 Jan 2021 03:15:56 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> 8259074: regex benchmarks and tests

@amalloy - you are invited to comment on regex content
@cl4es @shipilev - you are invited to point out my jmh bad practices

-------------

PR: https://git.openjdk.java.net/jdk/pull/1940

From amalloy at openjdk.java.net  Sat Jan 30 22:05:42 2021
From: amalloy at openjdk.java.net (Alan Malloy)
Date: Sat, 30 Jan 2021 22:05:42 GMT
Subject: RFR: 8259074: regex benchmarks and tests
In-Reply-To: <dUQnlQE4mrODO0V9bxIinjylxDIWiuDHRK9CvWxRU08=.b0bf4cc0-09e8-4ea6-9414-01ba3a8886da@github.com>
References: <dUQnlQE4mrODO0V9bxIinjylxDIWiuDHRK9CvWxRU08=.b0bf4cc0-09e8-4ea6-9414-01ba3a8886da@github.com>
Message-ID: <0JFjmMuXWF6x9PBqy-ZrsXK-6oq-8fYleSGmJSt73fU=.ef98c527-bfc8-4890-940c-b3d059c192c8@github.com>

On Tue, 5 Jan 2021 03:15:56 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> 8259074: regex benchmarks and tests

test/jdk/java/util/regex/TestCases.txt line 1248:

> 1246: false 1
> 1247: 
> 1248: // Unary power of two (8), reluctant quantifier

I think the comment here is meant as "Giving a power of 2 as input to the primarily tester", but coming right after a unary primality tester commented with "Unary prime", it sounds like you are labeling this as a power-of-2 detector.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1940

From martin at openjdk.java.net  Sat Jan 30 22:43:10 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sat, 30 Jan 2021 22:43:10 GMT
Subject: RFR: 8259074: regex benchmarks and tests [v2]
In-Reply-To: <dUQnlQE4mrODO0V9bxIinjylxDIWiuDHRK9CvWxRU08=.b0bf4cc0-09e8-4ea6-9414-01ba3a8886da@github.com>
References: <dUQnlQE4mrODO0V9bxIinjylxDIWiuDHRK9CvWxRU08=.b0bf4cc0-09e8-4ea6-9414-01ba3a8886da@github.com>
Message-ID: <6PsLwBq14fzr95q7JsFcpZzACniQ7cB6OZ6cZZqwN8M=.e4545830-0777-45e9-8a61-0b29b51c60d9@github.com>

> 8259074: regex benchmarks and tests

Martin Buchholz has updated the pull request incrementally with one additional commit since the last revision:

  address comments from @amalloy; introduce technically correct use of "numeral"

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1940/files
  - new: https://git.openjdk.java.net/jdk/pull/1940/files/cf0922f4..abb6c672

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1940&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1940&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1940.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1940/head:pull/1940

PR: https://git.openjdk.java.net/jdk/pull/1940

From shade at openjdk.java.net  Sun Jan 31 08:21:43 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Sun, 31 Jan 2021 08:21:43 GMT
Subject: RFR: 8259074: regex benchmarks and tests [v2]
In-Reply-To: <6PsLwBq14fzr95q7JsFcpZzACniQ7cB6OZ6cZZqwN8M=.e4545830-0777-45e9-8a61-0b29b51c60d9@github.com>
References: <dUQnlQE4mrODO0V9bxIinjylxDIWiuDHRK9CvWxRU08=.b0bf4cc0-09e8-4ea6-9414-01ba3a8886da@github.com>
 <6PsLwBq14fzr95q7JsFcpZzACniQ7cB6OZ6cZZqwN8M=.e4545830-0777-45e9-8a61-0b29b51c60d9@github.com>
Message-ID: <IIoQfO6LUBHTkmBhyCG7MD2MZGYDB6ZZWOp63OWZHRA=.990000c9-719a-4d55-b509-67dfafd39908@github.com>

On Sat, 30 Jan 2021 22:43:10 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> 8259074: regex benchmarks and tests
>
> Martin Buchholz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments from @amalloy; introduce technically correct use of "numeral"

test/micro/org/openjdk/bench/java/util/regex/Trim.java line 119:

> 117:         assert ! lookBehind_find();
> 118:         assert ! find_loop_two_matchers();
> 119:         assert ! find_loop_usePattern();

At a risk of muddling the profiles a bit, this can be rewritten as:

 if (!simple_find()) throw new IllegalStateException("simple_find is incorrect");
 ...

-------------

PR: https://git.openjdk.java.net/jdk/pull/1940

From alanb at openjdk.java.net  Sun Jan 31 12:22:56 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 31 Jan 2021 12:22:56 GMT
Subject: RFR: JDK-8259395 Patching automatic module with additional
 packages re-creates module without "requires java.base" [v5]
In-Reply-To: <7QFhztqPN4Z3ZI2qvxDG9PRJKMxGWxM4h1azimX3CKQ=.4eb110b1-1dc7-4a7f-8017-716131d13545@github.com>
References: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
 <7QFhztqPN4Z3ZI2qvxDG9PRJKMxGWxM4h1azimX3CKQ=.4eb110b1-1dc7-4a7f-8017-716131d13545@github.com>
Message-ID: <6YRS8C6EBg6pP5QE5O_CQeHeZOiqw_WJb4FLQXM4jMY=.5eb1f708-3780-4f8f-9ece-0d6d3f4d7a5f@github.com>

On Tue, 19 Jan 2021 23:12:02 GMT, Johannes Kuhn <github.com+652983+DasBrain at openjdk.org> wrote:

>> Simple fix - one line change: https://openjdk.github.io/cr/?repo=jdk&pr=2000&range=00#sdiff-0.
>> 
>> Most of the changes come from an additional test that fails without this fix:
>> 
>>      Error: Unable to load main class somelib.test.TestMain in module somelib
>>     	java.lang.IllegalAccessError: superclass access check failed: class somelib.test.TestMain (in module somelib) cannot access class java.lang.Object (in module java.base) because module java.base does not export java.lang to module somelib
>> 
>> As described in JDK-8259395.
>> You can view the output of the test without patch here: https://github.com/DasBrain/jdk/runs/1668078245
>> 
>> Thanks to @AlanBateman for pointing out the right fix.
>
> Johannes Kuhn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment, and missing newline in module-info.java

Thanks for expanding the test to cover the initial module and automatic module on the module path cases. I think we are nearly good to me, just a few suggestions to make the test easier to maintain in the future.

test/jdk/tools/launcher/modules/patch/automatic/PatchTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2015, 2021, Oracle and/or its affiliates. All rights reserved.

Minor nit, should be 2021 only.

test/jdk/tools/launcher/modules/patch/automatic/PatchTest.java line 34:

> 32:  * @run testng PatchTest
> 33:  * @bug 8259395
> 34:  * @summary Runs tests that make use of automatic modules

Can we change the summary to say that it tests patching an automatic module?

test/jdk/tools/launcher/modules/patch/automatic/PatchTest.java line 122:

> 120: 
> 121:     @Test
> 122:     public void modulePathExtend() throws Exception {

I think it would be useful for future maintainers if there was a comment on each of the 4 tests. I'd probably rename them them too, e.g. testExtendAutomaticModuleOnModulePath, testExtendAutomaticModuleAsInitialModule, so that it's a bit clear what each one does.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2000

From dfranken.jdk at gmail.com  Sun Jan 31 12:54:44 2021
From: dfranken.jdk at gmail.com (Dave Franken)
Date: Sun, 31 Jan 2021 13:54:44 +0100
Subject: Why does Set.of disallow duplicate elements?
In-Reply-To: <2099264599.1848135.1612038604962.JavaMail.zimbra@u-pem.fr>
References: <a0171e042852fa76d34a6beac49ff534d8361663.camel@gmail.com>
 <2099264599.1848135.1612038604962.JavaMail.zimbra@u-pem.fr>
Message-ID: <CALw878=Rpb7x0YhVLq9Oq+horjQ4xKp1-qhX-ANAPy1nX=f0Ag@mail.gmail.com>

Okay, I understand this reasoning, but when you want to construct a Set
from an array, you might be tempted to use Set.of(...) because it looks
like it supports an array and indeed, you can do Set.of(new int[] {1, 2 })
I believe?

Maybe this is just a quirk because of how varargs work.

I wondered if there was a canonical way to create a Set from an array, but
couldn't find it, maybe I am missing something?
I did notice Arrays.asList exists (which makes sense because it creates an
ArrayList backed by the array), but not Arrays.asSet.

So the way I would create a Set from an array would be either
Arrays.stream(myArr).collect(Collectors.toUnmodifiableSet()) or new
HashSet<>(Arrays.asList(myArray)) or Set.copyOf(Arrays.asList(myArray)).

I'm not saying the way it is currently implemented is wrong, it's just
something which can suprise developers as it surprised me. :)

Kind regards,

Dave

Op za 30 jan. 2021 om 21:30 schreef Remi Forax <forax at univ-mlv.fr>:

> Set.of() is the closest way we've got to a literal Set without having
> introduced a special syntax for that in the language.
>
> The idea is that if you conceptually want to write
>   Set<String> set = { "hello", "world" };
> instead, you write
>   Set<String> set = Set.of("hello", "world");
>
> In that context, it makes sense to reject Set constructed with the same
> element twice because this is usually a programming error.
> So
>   Set.of("hello", "hello")
> throws an IAE.
>
> If you want a Set from a collection of elements, you can use
>   Set.copyOf(List.of("hello", "hello"))
>
> regards,
> R?mi
>
> ----- Mail original -----
> > De: "dfranken jdk" <dfranken.jdk at gmail.com>
> > ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> > Envoy?: Samedi 30 Janvier 2021 19:30:06
> > Objet: Why does Set.of disallow duplicate elements?
>
> > Dear users,
> >
> > While looking at the implementation of Set.of(...) I noticed that
> > duplicate elements are not allowed, e.g. Set.of(1, 1) will throw an
> > IllegalArgumentException. Why has it been decided to do this?
> >
> > My expectation was that duplicates would simply be removed.
> >
> > If I do for instance new HashSet<>(<collection containing duplicates>)
> > it works and duplicates are removed. To me, it looks a bit inconsistent
> > to have duplicates removed for a collection passed in the constructor,
> > but not for a collection (even though it is a vararg array) passed to a
> > static factory method.
> >
> > Kind regards,
> >
> > Dave Franken
>

From alanb at openjdk.java.net  Sun Jan 31 15:07:41 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 31 Jan 2021 15:07:41 GMT
Subject: RFR: 8260337: Optimize ImageReader lookup,
 used by Class.getResource [v2]
In-Reply-To: <gbNZMNf4bYbwEL9jnIEgUhs73orb-SyfUG9e0r1l0tE=.86993b35-6ba4-4279-b65a-c29266eebe66@github.com>
References: <zQXTGreWNlfXRT-l_G5Ptd6i_ZQ5XbD7yQj40Kr84Ic=.8dab254e-0aa9-4932-a8bd-0194e25ed68f@github.com>
 <wiOiXfQx_b4KCY5jbwgez-iMByKK3-SWOKZshzcE-ac=.563935b2-f60a-480a-a883-a3f354de704c@github.com>
 <gbNZMNf4bYbwEL9jnIEgUhs73orb-SyfUG9e0r1l0tE=.86993b35-6ba4-4279-b65a-c29266eebe66@github.com>
Message-ID: <vyvvzSh_uXYR_2mwDFIBy2JctGTJwJJ68Oyrk8wM6lU=.8729d3d9-78c3-4880-97a4-c101b6fdf857@github.com>

On Wed, 27 Jan 2021 18:22:54 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyrights and rename containsLocation
>
> Nice clean up. LGTM

@JimLaskey Do you have anything that documents the jimage format that could be checked into the repo to help with future changes in this change? Clearly any such document would need a warning in 96pt font that the format is JDK internal, submit to change from build to build, etc. but it could be helpful when working on this code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2212

From james.laskey at oracle.com  Sun Jan 31 15:40:39 2021
From: james.laskey at oracle.com (Jim Laskey)
Date: Sun, 31 Jan 2021 15:40:39 +0000
Subject: RFR: 8260337: Optimize ImageReader lookup, used by
 Class.getResource [v2]
In-Reply-To: <vyvvzSh_uXYR_2mwDFIBy2JctGTJwJJ68Oyrk8wM6lU=.8729d3d9-78c3-4880-97a4-c101b6fdf857@github.com>
References: <zQXTGreWNlfXRT-l_G5Ptd6i_ZQ5XbD7yQj40Kr84Ic=.8dab254e-0aa9-4932-a8bd-0194e25ed68f@github.com>
 <wiOiXfQx_b4KCY5jbwgez-iMByKK3-SWOKZshzcE-ac=.563935b2-f60a-480a-a883-a3f354de704c@github.com>
 <gbNZMNf4bYbwEL9jnIEgUhs73orb-SyfUG9e0r1l0tE=.86993b35-6ba4-4279-b65a-c29266eebe66@github.com>,
 <vyvvzSh_uXYR_2mwDFIBy2JctGTJwJJ68Oyrk8wM6lU=.8729d3d9-78c3-4880-97a4-c101b6fdf857@github.com>
Message-ID: <D90BBB0A-4E89-45F2-8443-5B7D9BAE974C@oracle.com>

I?ve been handing out the original jimage docs on request. Surprisingly, it?s still accurate.  Will dig up on Monday to post. 

??

> On Jan 31, 2021, at 11:07 AM, Alan Bateman <alanb at openjdk.java.net> wrote:
> 
> ?On Wed, 27 Jan 2021 18:22:54 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:
> 
>>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>>> 
>>>  Copyrights and rename containsLocation
>> 
>> Nice clean up. LGTM
> 
> @JimLaskey Do you have anything that documents the jimage format that could be checked into the repo to help with future changes in this change? Clearly any such document would need a warning in 96pt font that the format is JDK internal, submit to change from build to build, etc. but it could be helpful when working on this code.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2212

From github.com+652983+dasbrain at openjdk.java.net  Sun Jan 31 16:26:58 2021
From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn)
Date: Sun, 31 Jan 2021 16:26:58 GMT
Subject: RFR: JDK-8259395 Patching automatic module with additional
 packages re-creates module without "requires java.base" [v6]
In-Reply-To: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
References: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
Message-ID: <GqgPiGKdkfgBnxn_X8gE1czjbXtp50tsrpNx1SdJBOo=.d3ac3c65-72b9-405b-8acf-591b8ff70322@github.com>

> Simple fix - one line change: https://openjdk.github.io/cr/?repo=jdk&pr=2000&range=00#sdiff-0.
> 
> Most of the changes come from an additional test that fails without this fix:
> 
>      Error: Unable to load main class somelib.test.TestMain in module somelib
>     	java.lang.IllegalAccessError: superclass access check failed: class somelib.test.TestMain (in module somelib) cannot access class java.lang.Object (in module java.base) because module java.base does not export java.lang to module somelib
> 
> As described in JDK-8259395.
> You can view the output of the test without patch here: https://github.com/DasBrain/jdk/runs/1668078245
> 
> Thanks to @AlanBateman for pointing out the right fix.

Johannes Kuhn has updated the pull request incrementally with one additional commit since the last revision:

  Renamed tests, to make it more clear what they should test.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2000/files
  - new: https://git.openjdk.java.net/jdk/pull/2000/files/15a057d9..87b4a8ec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2000&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2000&range=04-05

  Stats: 26 lines in 1 file changed: 0 ins; 0 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2000.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2000/head:pull/2000

PR: https://git.openjdk.java.net/jdk/pull/2000

From alanb at openjdk.java.net  Sun Jan 31 16:32:42 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 31 Jan 2021 16:32:42 GMT
Subject: RFR: JDK-8259395 Patching automatic module with additional
 packages re-creates module without "requires java.base" [v6]
In-Reply-To: <GqgPiGKdkfgBnxn_X8gE1czjbXtp50tsrpNx1SdJBOo=.d3ac3c65-72b9-405b-8acf-591b8ff70322@github.com>
References: <IqCNa1ROq5CVy3kj7p-QZ1B_4kgt4SW29WE3B_x_ohs=.0fd10138-c3da-48e0-b307-5bf625f8b195@github.com>
 <GqgPiGKdkfgBnxn_X8gE1czjbXtp50tsrpNx1SdJBOo=.d3ac3c65-72b9-405b-8acf-591b8ff70322@github.com>
Message-ID: <Kp-SL35--2TZWNnXhbULZwvGMMKdrQn5Tf5YOPKXggE=.35a84146-602e-4476-a7b8-20488c1de78c@github.com>

On Sun, 31 Jan 2021 16:26:58 GMT, Johannes Kuhn <github.com+652983+DasBrain at openjdk.org> wrote:

>> Simple fix - one line change: https://openjdk.github.io/cr/?repo=jdk&pr=2000&range=00#sdiff-0.
>> 
>> Most of the changes come from an additional test that fails without this fix:
>> 
>>      Error: Unable to load main class somelib.test.TestMain in module somelib
>>     	java.lang.IllegalAccessError: superclass access check failed: class somelib.test.TestMain (in module somelib) cannot access class java.lang.Object (in module java.base) because module java.base does not export java.lang to module somelib
>> 
>> As described in JDK-8259395.
>> You can view the output of the test without patch here: https://github.com/DasBrain/jdk/runs/1668078245
>> 
>> Thanks to @AlanBateman for pointing out the right fix.
>
> Johannes Kuhn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renamed tests, to make it more clear what they should test.

Thanks for the updates.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2000

From lancea at openjdk.java.net  Sun Jan 31 18:08:42 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sun, 31 Jan 2021 18:08:42 GMT
Subject: RFR: 8260617: Merge ZipFile encoding check with the initial hash
 calculation [v3]
In-Reply-To: <PYILyZ4GY87AjacFMUp-j4LYS6PRYQ3gUw4kSvoMYu0=.ca4fc812-f255-4179-bb7b-fd4080c2a55d@github.com>
References: <rdXUh4BYI5qnXEVdDLeqhFj5URWwg5puLEZQSu8kLkY=.49f605d2-5de4-4da4-919f-9d4a40da53fd@github.com>
 <PYILyZ4GY87AjacFMUp-j4LYS6PRYQ3gUw4kSvoMYu0=.ca4fc812-f255-4179-bb7b-fd4080c2a55d@github.com>
Message-ID: <yM0Crl3uPYFEvmvtUS5e_i0Qmja-USjHu2FJsdlE2pc=.09f637d3-832a-42d2-820b-32064e78c286@github.com>

On Sat, 30 Jan 2021 18:30:59 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> - Merge checkEncoding into the byte[]-based normalizedHash. The latter is only used from ZipFile.initCEN right after the checkEncoding today, so verifying this is equivalent is straightforward.
>> - Factor out the logic to calculate hash, check encoding etc into the addEntry method to allow JITs to chew off larger chunks of the logic early on
>> 
>> Roughly 1.2x speedup on the JarFileMeta microbenchmarks, which include the time required to open the jar file and thus exercising the optimized code.
>> 
>> Testing: tier1-4
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify comments, put normal path branch first in UTF8 checkedHash

Hi Claes

I gone through your changes a couple of times and with your latest updates, the patch looks good.  We should probably consider looking at Zip FS as its initCEN is similar at a future time.

Thank you for your efforts to optimize the performance in this area.

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2306

From akozlov at openjdk.java.net  Sun Jan 31 20:14:01 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Sun, 31 Jan 2021 20:14:01 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <ugV_PtxgaQkJQw3i1cwYiaKZ46--TZfgdVsuhQd5_3Y=.5b39eb44-1398-41b1-8bdf-2e6a3149e865@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits:

 - Merge branch 'master' into jdk-macos
 - Update copyright year for BsdAARCH64ThreadContext.java
 - Fix inclusing of StubRoutines header
 - Redo buildsys fix
 - Revert harfbuzz changes, disable warnings for it
 - Little adjustement of SlowSignatureHandler
 - Partially bring previous commit
 - Revert "Address feedback for signature generators"
   
   This reverts commit 50b55f6684cd21f8b532fa979b7b6fbb4613266d.
 - Refactor CDS disabling
 - Redo builsys support for aarch64-darwin
 - ... and 52 more: https://git.openjdk.java.net/jdk/compare/8a9004da...b421e0b4

-------------

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=07
  Stats: 3266 lines in 114 files changed: 3164 ins; 41 del; 61 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

From vkempik at openjdk.java.net  Sun Jan 31 20:14:02 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Sun, 31 Jan 2021 20:14:02 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8]
In-Reply-To: <GUQ9iV90tXzdUOtyjcIJygM7qBCcUtSHVOol8hOK2OE=.7b3ab947-f835-43d4-a852-cde094efbf62@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
 <h9On7_RFadcLwhW15R4Jig9PZ0y9JoMI2diiqXv99eY=.9b814ff7-64cf-496f-a507-0a8f86070c2d@github.com>
 <GUQ9iV90tXzdUOtyjcIJygM7qBCcUtSHVOol8hOK2OE=.7b3ab947-f835-43d4-a852-cde094efbf62@github.com>
Message-ID: <0-H97G4l5XqFtiEUbNAqrP_j143iny5kkF0tsiAqMvQ=.2396963b-db5d-469e-bc30-511f754a600a@github.com>

On Mon, 25 Jan 2021 09:48:46 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Would you like me to do something about it now? The problem is that the functions of SlowSignatureHandler are subtly different, so it will be multiple tables, not sure how many. Such change is another candidate for a separate code enhancement, which I would like not to mix into the JEP implementation (it's already not a small change :)). But if you think it would be a good thing, please let me know. In another case, I'll add this to a queue of follow-up enhancements.
>
> I'm not sure it can wait. This change turns already-messy code into something significantly messier, to the extent that it's not really good enough to go into mainline.

Hello
Does this look like something in the right direction ? 

https://github.com/VladimirKempik/jdk/commit/c2820734f4b10148154085a70d380b8c5775fa49

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From forax at univ-mlv.fr  Sun Jan 31 21:35:24 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sun, 31 Jan 2021 22:35:24 +0100 (CET)
Subject: Why does Set.of disallow duplicate elements?
In-Reply-To: <CALw878=Rpb7x0YhVLq9Oq+horjQ4xKp1-qhX-ANAPy1nX=f0Ag@mail.gmail.com>
References: <a0171e042852fa76d34a6beac49ff534d8361663.camel@gmail.com>
 <2099264599.1848135.1612038604962.JavaMail.zimbra@u-pem.fr>
 <CALw878=Rpb7x0YhVLq9Oq+horjQ4xKp1-qhX-ANAPy1nX=f0Ag@mail.gmail.com>
Message-ID: <1964605040.2099457.1612128924150.JavaMail.zimbra@u-pem.fr>






De: "dfranken jdk" <dfranken.jdk at gmail.com> 
?: "Remi Forax" <forax at univ-mlv.fr> 
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net> 
Envoy?: Dimanche 31 Janvier 2021 13:54:44 
Objet: Re: Why does Set.of disallow duplicate elements? 




BQ_BEGIN

Okay, I understand this reasoning, but when you want to construct a Set from an array, you might be tempted to use Set.of(...) because it looks like it supports an array and indeed, you can do Set.of(new int[] {1, 2 }) I believe? 

BQ_END

Set.of(int[]) will call Set.of(E) with E being an int[]. 
but 
Set.of(new Integer[] { ... }) calls Set.of(...). 


BQ_BEGIN


Maybe this is just a quirk because of how varargs work. 

BQ_END

Yes, exactly, it's a known issue with varargs, you have no way to say, i don't want this varargs to be called with an array. 


BQ_BEGIN


I wondered if there was a canonical way to create a Set from an array, but couldn't find it, maybe I am missing something? 
I did notice Arrays.asList exists (which makes sense because it creates an ArrayList backed by the array), but not Arrays.asSet. 

BQ_END

asList() reuse the same backing array, you can not do that with asSet() or contains() will be in O(n) in the worst case. 


BQ_BEGIN


So the way I would create a Set from an array would be either Arrays.stream(myArr).collect(Collectors.toUnmodifiableSet()) or new HashSet<>(Arrays.asList(myArray)) or Set.copyOf(Arrays.asList(myArray)). 

BQ_END

yes, the last one is the easy way to create an unmodifiable set from an array. 


BQ_BEGIN


I'm not saying the way it is currently implemented is wrong, it's just something which can suprise developers as it surprised me. :) 

BQ_END

Arrays are currently second class citizen in Java, because they are always modifiable and always covariant (String[] can be seen as a Object[]). 
We have talked several times to introduce new variants of arrays, non-modifiable one, non-covariant one, etc under the name Array 2.0, but Valhalla generics is a blocker for that project. 
Once Valhalla is done, it may be a follow up. 


BQ_BEGIN


Kind regards, 

Dave 

BQ_END


regards, 
R?mi 


BQ_BEGIN



Op za 30 jan. 2021 om 21:30 schreef Remi Forax < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >: 

BQ_BEGIN
Set.of() is the closest way we've got to a literal Set without having introduced a special syntax for that in the language. 

The idea is that if you conceptually want to write 
Set<String> set = { "hello", "world" }; 
instead, you write 
Set<String> set = Set.of("hello", "world"); 

In that context, it makes sense to reject Set constructed with the same element twice because this is usually a programming error. 
So 
Set.of("hello", "hello") 
throws an IAE. 

If you want a Set from a collection of elements, you can use 
Set.copyOf(List.of("hello", "hello")) 

regards, 
R?mi 

----- Mail original ----- 
> De: "dfranken jdk" < [ mailto:dfranken.jdk at gmail.com | dfranken.jdk at gmail.com ] > 
> ?: "core-libs-dev" < [ mailto:core-libs-dev at openjdk.java.net | core-libs-dev at openjdk.java.net ] > 
> Envoy?: Samedi 30 Janvier 2021 19:30:06 
> Objet: Why does Set.of disallow duplicate elements? 

> Dear users, 
> 
> While looking at the implementation of Set.of(...) I noticed that 
> duplicate elements are not allowed, e.g. Set.of(1, 1) will throw an 
> IllegalArgumentException. Why has it been decided to do this? 
> 
> My expectation was that duplicates would simply be removed. 
> 
> If I do for instance new HashSet<>(<collection containing duplicates>) 
> it works and duplicates are removed. To me, it looks a bit inconsistent 
> to have duplicates removed for a collection passed in the constructor, 
> but not for a collection (even though it is a vararg array) passed to a 
> static factory method. 
> 
> Kind regards, 
> 
> Dave Franken 

BQ_END


BQ_END