Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3]
On 3/09/2021 12:45 am, Roger Riggs wrote: On Sat, 28 Aug 2021 02:34:48 GMT, Roger Riggs wrote: The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Revised to use native /bin/sleep program on Unix* (non-Windows). For Windows, a native "BasicSleep" program is used. And also about Timeout on Windows: it can't be used because it requires a working input stream. Child args: [C:\Windows\System32\Timeout.exe, 600] ERROR: Input redirection is not supported, exiting the process immediately. Did you try with the /NOBREAK flag? David - PR: https://git.openjdk.java.net/jdk/pull/5239
Re: better random numbers
On Sep 2, 2021, at 4:35 PM, John Rose mailto:john.r.r...@oracle.com>> wrote: The state of the art for PRNGs (pseudo-random number generators) is much advanced since ju.Random was written. Surely at some point we will refresh our APIs that produce random numbers. In fact, we have added SplittableRandom, but I think the state of the art is farther enough along to consider another refresh. Well, I didn’t know about https://openjdk.java.net/jeps/356 when I wrote the previous, so I’m a little late to be as helpful as I hoped to be. Still, Joe and Brian B. (thanks guys for handing me the Missing Clue) lead me to hope we can add options to cover the PCG algorithms, if (as I think) they turn out to be useful. The 128-bit PCG state with the 64-bit multiplier of da942042e4dd58b5 looks especially promising to me. It’s used here: https://github.com/imneme/pcg-cpp/blob/ffd522e7188bef30a00c74dc7eb9de5faff90092/include/pcg_random.hpp#L176 O’Neill says that’s her PRNG of choice for most purposes is pcg64_fast (defined in the file above using that multiplier). It competes better with the xoshiro family performance than the shootout figures provided by the xoshiro developers would seem to indicate. And the state size for pcg64_fast is 128 bits which (I think) is about half the size of a xoshiro state.
Integrated: 8214761: Bug in parallel Kahan summation implementation
On Fri, 2 Jul 2021 20:12:39 GMT, Ian Graves wrote: > 8214761: Bug in parallel Kahan summation implementation This pull request has now been integrated. Changeset: dd871819 Author:Ian Graves URL: https://git.openjdk.java.net/jdk/commit/dd871819a05886ee09fc00c7c778268440ebedb7 Stats: 235 lines in 5 files changed: 225 ins; 0 del; 10 mod 8214761: Bug in parallel Kahan summation implementation Reviewed-by: darcy - PR: https://git.openjdk.java.net/jdk/pull/4674
Re: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v3]
On Thu, 2 Sep 2021 11:35:52 GMT, Vladimir Ivanov wrote: >> `MethodHandle.asTypeCache` keeps a strong reference to adapted >> `MethodHandle` and it can introduce a class loader leak through its >> `MethodType`. >> >> Proposed fix introduces a 2-level cache (1 element each) where 1st level can >> only contain `MethodHandle`s which are guaranteed to not introduce any >> dependencies on new class loaders compared to the original `MethodHandle`. >> 2nd level is backed by a `SoftReference` and is used as a backup when the >> result of `MethodHandle.asType()` conversion can't populate the higher level >> cache. >> >> The fix is based on [the >> work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/) >> made by Peter Levart @plevart back in 2015. >> >> Testing: tier1 - tier6 > > Vladimir Ivanov has updated the pull request incrementally with one > additional commit since the last revision: > > Address review comments This looks good to me. For the change of `MethodHandle::asType` to a final method, this needs a CSR. Is this spec change intentional? I wonder if `MethodHandle` should be a sealed class instead. In any case, maybe you can consider the spec change as a separate issue. - PR: https://git.openjdk.java.net/jdk/pull/5246
better random numbers
The state of the art for PRNGs (pseudo-random number generators) is much advanced since ju.Random was written. Surely at some point we will refresh our APIs that produce random numbers. In fact, we have added SplittableRandom, but I think the state of the art is farther enough along to consider another refresh. (When we get advanced numerics via Valhalla, I think we will probably want generic algorithms on 128-bit int and vectorized states, as well; that’s just a guess.) I bring this up not for any immediate purpose, but because every so often I google around for information about PRNGs, and I have noticed that a particular reference (since at least 2018) keeps coming to the top of the pile of interesting stuff. I’d like to share it with you all, and talk about making use of it. (FWIW, last weekend I was doing some experiments with perfect hash functions, and I wanted to roll my own PRNG to drive the search for them. A few months ago my problem was test vector generation, and again I rolled my own PRNG after looking at ju.*Random.) The reference I’d like to give here is to Dr. Melissa O’Neill’s website and articles: https://www.pcg-random.org …Read more here: http://cr.openjdk.java.net/~jrose/jdk/pcg-psa.txt
Re: RFR: 8273259: Character.getName doesn't follow Unicode spec for ideographs
On Thu, 2 Sep 2021 19:26:12 GMT, Naoto Sato wrote: > Simple spec clarification. A CSR has also been drafted > (https://bugs.openjdk.java.net/browse/JDK-8273296). Associated CSR also "Reviewed". - Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5354
Re: RFR: 8273259: Character.getName doesn't follow Unicode spec for ideographs
On Thu, 2 Sep 2021 19:26:12 GMT, Naoto Sato wrote: > Simple spec clarification. A CSR has also been drafted > (https://bugs.openjdk.java.net/browse/JDK-8273296). Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5354
Re: RFR: 8273259: Character.getName doesn't follow Unicode spec for ideographs
On Thu, 2 Sep 2021 19:26:12 GMT, Naoto Sato wrote: > Simple spec clarification. A CSR has also been drafted > (https://bugs.openjdk.java.net/browse/JDK-8273296). Marked as reviewed by bpb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5354
RFR: 8273259: Character.getName doesn't follow Unicode spec for ideographs
Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296). - Commit messages: - 8273259: Character.getName doesn't follow Unicode spec for ideographs Changes: https://git.openjdk.java.net/jdk/pull/5354/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5354=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273259 Stats: 19 lines in 1 file changed: 8 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/5354.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5354/head:pull/5354 PR: https://git.openjdk.java.net/jdk/pull/5354
Re: RFR: JDK-8273194: Document the two possible cases when Lookup::ensureInitialized returns [v2]
> Improve the specification to document the cases when > `Lookup::ensureInitialized` returns as specified JVMS 5.5 and matches the > implementation. > > Please also review CSR: https://bugs.openjdk.java.net/browse/JDK-8273253 Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: review comment - Changes: - all: https://git.openjdk.java.net/jdk/pull/5343/files - new: https://git.openjdk.java.net/jdk/pull/5343/files/3a2aa6da..3f7e66b0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=5343=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5343=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5343.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5343/head:pull/5343 PR: https://git.openjdk.java.net/jdk/pull/5343
Re: RFR: JDK-8273194: Document the two possible cases when Lookup::ensureInitialized returns [v2]
On Thu, 2 Sep 2021 14:00:03 GMT, Alan Bateman wrote:
>> Mandy Chung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> review comment
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2787:
>
>> 2785: * This method returns when {@code targetClass} is fully
>> initialized, or
>> 2786: * when {@code targetClass} is being initialized if this
>> method is called
>> 2787: * by the initializing thread.
>
> This looks okay but I wonder if it might be a bit clearer to say "when
> targetClass is being initialized on the current thread".
That works for me. Updated.
-
PR: https://git.openjdk.java.net/jdk/pull/5343
Re: RFR: JDK-8273194: Document the two possible cases when Lookup::ensureInitialized returns [v2]
On Thu, 2 Sep 2021 16:18:03 GMT, Mandy Chung wrote: >> Improve the specification to document the cases when >> `Lookup::ensureInitialized` returns as specified JVMS 5.5 and matches the >> implementation. >> >> Please also review CSR: https://bugs.openjdk.java.net/browse/JDK-8273253 > > Mandy Chung has updated the pull request incrementally with one additional > commit since the last revision: > > review comment Marked as reviewed by alanb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5343
Integrated: 8273250: Address javadoc issues in Deflater::setDictionationary
On Wed, 1 Sep 2021 19:26:17 GMT, Lance Andersen wrote: > Hi, > > Please review this trivial fix to the javadoc which addresses an issue shown > via Intellij where the error: "Symbol 'getAdler' is inaccessible from here" > is generated for the "@See Inflater#getAlder" references. > > Best > Lance This pull request has now been integrated. Changeset: aaa6f696 Author:Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/aaa6f696b06b335f81efccf0966612b086dd2e73 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8273250: Address javadoc issues in Deflater::setDictionationary Reviewed-by: rriggs, naoto, iris, bpb - PR: https://git.openjdk.java.net/jdk/pull/5340
Re: RFR: 8273261: Replace 'while' cycles with iterator with enhanced-for in java.base
On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov wrote: > There are few places in code where manual while loop is used with Iterator to > iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle > instead: it's less verbose, makes code easier to read and it's less > error-prone. > It doesn't have any performance impact: java compiler generates similar code > when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5328
Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3]
On Sat, 28 Aug 2021 02:34:48 GMT, Roger Riggs wrote: >> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified >> unexpected messages from a child Java VM >> as the cause of the test failure. Attempts to control the output of the >> child VM have failed, the VM is unrepentant . >> >> There is no functionality in the child except to wait long enough for the >> test to finish and the child is destroyed. >> The fix is to switch from using a Java child to using a native child; a new >> executable `sleepmillis`. > > Roger Riggs has updated the pull request incrementally with one additional > commit since the last revision: > > Revised to use native /bin/sleep program on Unix* (non-Windows). > For Windows, a native "BasicSleep" program is used. And also about Timeout on Windows: it can't be used because it requires a working input stream. Child args: [C:\Windows\System32\Timeout.exe, 600] ERROR: Input redirection is not supported, exiting the process immediately. - PR: https://git.openjdk.java.net/jdk/pull/5239
Re: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux
On Wed, 1 Sep 2021 12:38:38 GMT, Alan Bateman wrote: > I haven't come across this configuration like but changing it to use realpath > seem reasonable. Thanks, this scenario comes from our customers. > Using `realpath` instead of `readlink` will change results on systems which > use symbolic links instead of hard links to de-duplicate the timezone files. > For example, on Debian, if `UTC` is configured (`/etc/localtime` points to > `/usr/share/zoneinfo/UTC`), I think the result will be `Etc/UTC` instead of > `UTC` after this change. But I have not actually tested this. We tested it on ubuntu, it does have this kind of problem, thank you for your reminder. `realpath` doesn't seem to be suitable here, maybe we could directly process the previous `linkbuf` to remove the extra'.' and'/'. > The change looks reasonable. Please test your fix with macOS as well. Thanks, the test on macOS is passed. - PR: https://git.openjdk.java.net/jdk/pull/5327
Re: RFR: JDK-8273194: Document the two possible cases when Lookup::ensureInitialized returns
On Wed, 1 Sep 2021 20:56:59 GMT, Mandy Chung wrote:
> Improve the specification to document the cases when
> `Lookup::ensureInitialized` returns as specified JVMS 5.5 and matches the
> implementation.
>
> Please also review CSR: https://bugs.openjdk.java.net/browse/JDK-8273253
src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2787:
> 2785: * This method returns when {@code targetClass} is fully
> initialized, or
> 2786: * when {@code targetClass} is being initialized if this method
> is called
> 2787: * by the initializing thread.
This looks okay but I wonder if it might be a bit clearer to say "when
targetClass is being initialized on the current thread".
-
PR: https://git.openjdk.java.net/jdk/pull/5343
Re: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux
On Wed, 1 Sep 2021 12:51:15 GMT, Florian Weimer wrote: >> Hi, >> Please help me review the change to enhance getting time zone ID from >> /etc/localtime on linux. >> >> We use `realpath` instead of `readlink` to obtain the link name of >> /etc/localtime, because `readlink` can only read the value of a symbolic of >> link, not the canonicalized absolute pathname. >> >> For example, the value of /etc/localtime is >> "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by >> `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of >> `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which >> consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you >> can get “/usr/share/zoneinfo/Asia/Shanghai“ directly from “/etc/localtime“. >> >> Thanks, >> wuyan > > src/java.base/unix/native/libjava/TimeZone_md.c line 292: > >> 290: /* canonicalize the path */ >> 291: char resolvedpath[PATH_MAX + 1]; >> 292: char *path = realpath(DEFAULT_ZONEINFO_FILE, resolvedpath); > > You really should use `realpath` with `NULL` as the second argument, to avoid > any risk of buffer overflow. Future C library headers may warn about non-null > arguments here. Ok, Thanks. I will refer to the implementation of `os::Posix::realpath` to fix it if we still use `realpath`. https://github.com/openjdk/jdk/blob/5245c1cf0260a78ca5f8ab4e7d13107f21faf071/src/hotspot/os/posix/os_posix.cpp#L805 - PR: https://git.openjdk.java.net/jdk/pull/5327
Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3]
On Sat, 28 Aug 2021 02:34:48 GMT, Roger Riggs wrote: >> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified >> unexpected messages from a child Java VM >> as the cause of the test failure. Attempts to control the output of the >> child VM have failed, the VM is unrepentant . >> >> There is no functionality in the child except to wait long enough for the >> test to finish and the child is destroyed. >> The fix is to switch from using a Java child to using a native child; a new >> executable `sleepmillis`. > > Roger Riggs has updated the pull request incrementally with one additional > commit since the last revision: > > Revised to use native /bin/sleep program on Unix* (non-Windows). > For Windows, a native "BasicSleep" program is used. The `timeout --help` version is from a CI job: Unexpected child output, to: getErrorStream Child args: [cmd.exe, /c, timeout, 60] Try 'timeout --help' for more information. But ...\cygwin\bin is in PATH before Windows\System32 So sleep would be available, but on cygwin it is in /usr/bin. sleep would work everywhere, except a real Windows build. What a tortuous workaround because of a 'feature' of the VM! - PR: https://git.openjdk.java.net/jdk/pull/5239
Re: RFR: 8273261: Replace 'while' cycles with iterator with enhanced-for in java.base
On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov wrote: > There are few places in code where manual while loop is used with Iterator to > iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle > instead: it's less verbose, makes code easier to read and it's less > error-prone. > It doesn't have any performance impact: java compiler generates similar code > when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 LGTM For the security related code a second reviewer would be good. - Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5328
Re: RFR: 6957241: ClassLoader.getResources() returns only 1 instance when using jar indexing
On Tue, 31 Aug 2021 12:11:46 GMT, wxiang
wrote:
> Using jarIndex for Hibench, there is an unexpected behavior with the
> exception "Exception in thread "main"
> org.apache.hadoop.fs.UnsupportedFileSystemException: No FileSystem for scheme
> "hdfs"".
>
> After investigating it, it is related to the usage of ServiceLoader with
> JarIndex.
> The below stack shows the issue with JDK11:
>
> getResource:1016, URLClassPath$JarLoader (jdk.internal.loader)
> getResource:937, URLClassPath$JarLoader (jdk.internal.loader)
> findResource:912, URLClassPath$JarLoader (jdk.internal.loader)
> next:341, URLClassPath$1 (jdk.internal.loader)
> hasMoreElements:351, URLClassPath$1 (jdk.internal.loader)
> hasNext:355, BuiltinClassLoader$1 (jdk.internal.loader)
> hasMoreElements:363, BuiltinClassLoader$1 (jdk.internal.loader)
> next:3032, CompoundEnumeration (java.lang)
> hasMoreElements:3041, CompoundEnumeration (java.lang)
> nextProviderClass:1203, ServiceLoader$LazyClassPathLookupIterator (java.util)
> hasNextService:1221, ServiceLoader$LazyClassPathLookupIterator (java.util)
> hasNext:1265, ServiceLoader$LazyClassPathLookupIterator (java.util)
> hasNext:1300, ServiceLoader$2 (java.util)
> hasNext:1385, ServiceLoader$3 (java.util)
>
> The below API tries to get all the resources with the same name.
>
> public Enumeration findResources(final String name,
> final boolean check)
> ```
> After using JarIndex, URLClassPath.findResources only returns 1 URL.
> It is the same as the description in JDK-6957241.
>
> The issue still exists in JDK18.
>
> Root cause:
>
> public Enumeration findResources(final String name,
> final boolean check) {
> return new Enumeration<>() {
> private int index = 0;
> private URL url = null;
>
> private boolean next() {
> if (url != null) {
> return true;
> } else {
> Loader loader;
> while ((loader = getLoader(index++)) != null) {
> url = loader.findResource(name, check);
> if (url != null) {
> return true;
> }
> }
> return false;
> }
> }
> ...
> };
> }
>
> With the JarIndex, there is only one loader which is corresponding to the jar
> with the index due to the implementation in JarLoader.getResource(final
> String name, boolean check, Set visited).
>
> Loaders corresponding to other jar packages will not appear in this while.
> So it only returns 1 instance.
>
> To solve the issue, I change the implementation "private boolean next()".
> If the loader has index, traverse the index and get all the resource from the
> loader.
@wxiang I think there is at least some support for removing the JAR indexing
support rather than trying to fix findResources. The issue of what to do with
the legacy JAR index mechanism came up during JDK 9 in the context of modular
JARs and also Multi-Release JARs but it was too much to take on at the time.
Would you be interested in working out the changes to remove it?
-
PR: https://git.openjdk.java.net/jdk/pull/5316
Re: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation [v2]
On Thu, 2 Sep 2021 05:08:38 GMT, David Holmes wrote:
>> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 1152:
>>
>>> 1150: * The call returns when either class {@code c} is fully
>>> initialized or
>>> 1151: * class {@code c} is being initialized and the call is performed
>>> from
>>> 1152: * the initializing thread.
>>
>> Suggestion:
>>
>> * The call returns when either class {@code c} is fully initialized or
>> * class {@code c} is being initialized and the call is performed from
>> * the initializing thread. In the latter case a subsequent call to
>> * {@link #shouldBeInitialized}, from the calling thread of this call,
>> * will return {@code true}.
>
> Aren't "the calling thread of this call" and "the initializing thread" the
> same thread in the latter case?
Agree. I dropped "from the calling thread of this call" part and incorporated
the rest into the latest version.
-
PR: https://git.openjdk.java.net/jdk/pull/5258
Re: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation [v3]
> Get rid of WeakReference-based logic in > DirectMethodHandle::checkInitialized() and reimplement it with > `Unsafe::ensureClassInitialized()`/`shouldBeInitialized()`. > > The key observation is that `Unsafe::ensureClassInitialized()` does not block > the initializing thread. > > Also, removed `Unsafe::shouldBeInitialized()` in > `DMH::shouldBeInitialized(MemberName)` to save on calling into the VM. > `Unsafe::ensureClassInitialized()` already has a fast-path check which checks > whether the class is fully initialized or not. > > Testing: tier1 - tier6 Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: Update the comment - Changes: - all: https://git.openjdk.java.net/jdk/pull/5258/files - new: https://git.openjdk.java.net/jdk/pull/5258/files/64f2de83..09c36317 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=5258=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5258=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5258.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5258/head:pull/5258 PR: https://git.openjdk.java.net/jdk/pull/5258
Re: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v2]
On Wed, 1 Sep 2021 17:28:37 GMT, Mandy Chung wrote:
>> Vladimir Ivanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address review comments
>
> src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 926:
>
>> 924: /* Returns true when {@code loader} keeps {@code cls} either
>> directly or indirectly through the loader delegation chain. */
>> 925: private static boolean keepsAlive(Class cls, ClassLoader loader)
>> {
>> 926: return keepsAlive(cls.getClassLoader(), loader);
>
> Suggestion:
>
> ClassLoader defLoader = cls.getClassLoader();
> if (isBuiltinLoader(defLoader)) {
> return true; // built-in loaders are always reachable
> }
> return keepsAlive(defLoader, loader);
>
>
> I think it's clearer to check if `cls` is not defined by any builtin loader
> here and then check if `loader` keeps `cls` alive.
>
> So `keepsAlive(ClassLoader loader1, ClassLoader loader2)` is not needed and
> replace line 935 and 940 to `keepsAlive(Class, ClassLoader)` instead.
Sounds good.
Incorporated your suggestions along with some minor refactorings.
-
PR: https://git.openjdk.java.net/jdk/pull/5246
Re: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v3]
> `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle` > and it can introduce a class loader leak through its `MethodType`. > > Proposed fix introduces a 2-level cache (1 element each) where 1st level can > only contain `MethodHandle`s which are guaranteed to not introduce any > dependencies on new class loaders compared to the original `MethodHandle`. > 2nd level is backed by a `SoftReference` and is used as a backup when the > result of `MethodHandle.asType()` conversion can't populate the higher level > cache. > > The fix is based on [the > work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/) > made by Peter Levart @plevart back in 2015. > > Testing: tier1 - tier6 Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: Address review comments - Changes: - all: https://git.openjdk.java.net/jdk/pull/5246/files - new: https://git.openjdk.java.net/jdk/pull/5246/files/b2c0..7a87aee3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=5246=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5246=01-02 Stats: 41 lines in 1 file changed: 15 ins; 18 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/5246.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5246/head:pull/5246 PR: https://git.openjdk.java.net/jdk/pull/5246
Integrated: JDK-8273229: Update OS detection code to recognize Windows Server 2022
On Thu, 2 Sep 2021 06:43:16 GMT, Matthias Baesken wrote: > Hello, please review this small change. > The OS detection code of the JDK/JVM should recognize the new Windows server > 2022 : > > https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022 > https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info > > The build number of Windows server 2022 according to the documentation in the > second link is 20348 . > Thanks, Matthias This pull request has now been integrated. Changeset: c2e015c3 Author:Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/c2e015c3c1a2274112bb8e6671a85bc7fb624fde Stats: 14 lines in 2 files changed: 9 ins; 0 del; 5 mod 8273229: Update OS detection code to recognize Windows Server 2022 Reviewed-by: alanb, dholmes - PR: https://git.openjdk.java.net/jdk/pull/5347
Re: RFR: 8273261: Replace 'while' cycles with iterator with enhanced-for in java.base
On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov wrote: > There are few places in code where manual while loop is used with Iterator to > iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle > instead: it's less verbose, makes code easier to read and it's less > error-prone. > It doesn't have any performance impact: java compiler generates similar code > when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 Generally this looks like a good improvement as the resulting code becomes more readable. Changes in sun/net or jar index classes look fine. Please obtain approval from maintainers of the other areas before integrating. - Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5328
Re: RFR: 8247980: Exclusive execution of java/util/stream tests slows down tier1
On Tue, 24 Aug 2021 13:18:21 GMT, Christoph Langer wrote: > I have added this to our internal testing, let's see how it goes. Notifying > @ArnoZeller about this. Any good or bad results? - PR: https://git.openjdk.java.net/jdk/pull/5189
Re: RFR: JDK-8273229: Update OS detection code to recognize Windows Server 2022 [v2]
On Thu, 2 Sep 2021 08:16:52 GMT, Matthias Baesken wrote: >> Hello, please review this small change. >> The OS detection code of the JDK/JVM should recognize the new Windows server >> 2022 : >> >> https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022 >> https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info >> >> The build number of Windows server 2022 according to the documentation in >> the second link is 20348 . >> Thanks, Matthias > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > Adjust comments Thanks for the updates - Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5347
RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging
The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11. This is the request to delete the usage of AppContext in the LogManager and related tests. Tested by tier1/tier2/tier3 and jdk_desktop tests. - Commit messages: - Some tests deleted - Update the RootLevelInConfigFile test - Initial version of JDK-8273101 Changes: https://git.openjdk.java.net/jdk/pull/5326/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5326=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273101 Stats: 1423 lines in 10 files changed: 0 ins; 1418 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5326.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5326/head:pull/5326 PR: https://git.openjdk.java.net/jdk/pull/5326
Re: RFR: JDK-8273229: Update OS detection code to recognize Windows Server 2022 [v2]
On Thu, 2 Sep 2021 07:49:55 GMT, David Holmes wrote: >> Matthias Baesken has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Adjust comments > > src/hotspot/os/windows/os_windows.cpp line 1871: > >> 1869: // distinguish Windows Server 2016, 2019 and 2022 by build number >> 1870: // Windows server 2019 GA 10/2018 build number is 17763 >> 1871: // Windows server 2022 build number is 20348 > > Perhaps to avoid too much future editing: > > // Distinguish Windows Server by build number: > // - 2016 GA 10/2016 build: 14393 > // - 2019 GA 11/2018 build: 17763 > // - 2022 GA 08/2021 build: 20348 Hi David , thanks for your suggestions. I adjusted the comments. Best regards, Matthias - PR: https://git.openjdk.java.net/jdk/pull/5347
Re: RFR: JDK-8273229: Update OS detection code to recognize Windows Server 2022 [v2]
> Hello, please review this small change. > The OS detection code of the JDK/JVM should recognize the new Windows server > 2022 : > > https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022 > https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info > > The build number of Windows server 2022 according to the documentation in the > second link is 20348 . > Thanks, Matthias Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust comments - Changes: - all: https://git.openjdk.java.net/jdk/pull/5347/files - new: https://git.openjdk.java.net/jdk/pull/5347/files/c7ce4abc..f8952e3e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=5347=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5347=00-01 Stats: 5 lines in 2 files changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5347.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5347/head:pull/5347 PR: https://git.openjdk.java.net/jdk/pull/5347
Integrated: 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible
On Mon, 30 Aug 2021 14:26:56 GMT, Сергей Цыпанов
wrote:
> Just a very tiny clean-up.
>
> There are some places in JDK code base where we call
> `Enum.class.getEnumConstants()` to get all the values of the referenced
> `enum`. This is excessive, less-readable and slower than just calling
> `Enum.values()` as in `getEnumConstants()` we have volatile access:
>
> public T[] getEnumConstants() {
> T[] values = getEnumConstantsShared();
> return (values != null) ? values.clone() : null;
> }
>
> private transient volatile T[] enumConstants;
>
> T[] getEnumConstantsShared() {
> T[] constants = enumConstants;
> if (constants == null) { /* ... */ }
> return constants;
> }
>
> Calling values() method is slightly faster:
>
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class EnumBenchmark {
>
> @Benchmark
> public Enum[] values() {
> return Enum.values();
> }
>
> @Benchmark
> public Enum[] getEnumConstants() {
> return Enum.class.getEnumConstants();
> }
>
> private enum Enum {
> A,
> B
> }
> }
>
>
> BenchmarkMode Cnt
> Score Error Units
> EnumBenchmark.getEnumConstants avgt 15
> 6,265 ± 0,051 ns/op
> EnumBenchmark.getEnumConstants:·gc.alloc.rateavgt 15
> 2434,075 ± 19,568 MB/sec
> EnumBenchmark.getEnumConstants:·gc.alloc.rate.norm avgt 15
> 24,002 ± 0,001B/op
> EnumBenchmark.getEnumConstants:·gc.churn.G1_Eden_Space avgt 15
> 2433,709 ± 70,216 MB/sec
> EnumBenchmark.getEnumConstants:·gc.churn.G1_Eden_Space.norm avgt 15
> 23,998 ± 0,659B/op
> EnumBenchmark.getEnumConstants:·gc.churn.G1_Survivor_Space avgt 15
> 0,009 ± 0,003 MB/sec
> EnumBenchmark.getEnumConstants:·gc.churn.G1_Survivor_Space.norm avgt 15
> ≈ 10⁻⁴ B/op
> EnumBenchmark.getEnumConstants:·gc.count avgt 15
> 210,000counts
> EnumBenchmark.getEnumConstants:·gc.time avgt 15
> 119,000ms
>
> EnumBenchmark.values avgt 15
> 4,164 ± 0,134 ns/op
> EnumBenchmark.values:·gc.alloc.rate avgt 15
> 3665,341 ± 120,721 MB/sec
> EnumBenchmark.values:·gc.alloc.rate.norm avgt 15
> 24,002 ± 0,001B/op
> EnumBenchmark.values:·gc.churn.G1_Eden_Space avgt 15
> 3660,512 ± 137,250 MB/sec
> EnumBenchmark.values:·gc.churn.G1_Eden_Space.normavgt 15
> 23,972 ± 0,529B/op
> EnumBenchmark.values:·gc.churn.G1_Survivor_Space avgt 15
> 0,017 ± 0,003 MB/sec
> EnumBenchmark.values:·gc.churn.G1_Survivor_Space.normavgt 15
> ≈ 10⁻⁴ B/op
> EnumBenchmark.values:·gc.count avgt 15
> 262,000counts
> EnumBenchmark.values:·gc.timeavgt 15
> 155,000ms
This pull request has now been integrated.
Changeset: 152e6692
Author:Sergey Tsypanov
Committer: Thomas Schatzl
URL:
https://git.openjdk.java.net/jdk/commit/152e66923dc36cfd83cdfe18e96631abc06b9199
Stats: 13 lines in 4 files changed: 0 ins; 2 del; 11 mod
8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values()
where possible
Reviewed-by: tschatzl
-
PR: https://git.openjdk.java.net/jdk/pull/5303
Re: RFR: JDK-8273229: Update OS detection code to recognize Windows Server 2022
On Thu, 2 Sep 2021 06:43:16 GMT, Matthias Baesken wrote: > Hello, please review this small change. > The OS detection code of the JDK/JVM should recognize the new Windows server > 2022 : > > https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022 > https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info > > The build number of Windows server 2022 according to the documentation in the > second link is 20348 . > Thanks, Matthias Hi Matthias, Some minor suggestions but okay as-is. Thanks, David src/hotspot/os/windows/os_windows.cpp line 1871: > 1869: // distinguish Windows Server 2016, 2019 and 2022 by build number > 1870: // Windows server 2019 GA 10/2018 build number is 17763 > 1871: // Windows server 2022 build number is 20348 Perhaps to avoid too much future editing: // Distinguish Windows Server by build number: // - 2016 GA 10/2016 build: 14393 // - 2019 GA 11/2018 build: 17763 // - 2022 GA 08/2021 build: 20348 src/java.base/windows/native/libjava/java_props_md.c line 478: > 476: * where (buildNumber > 17762) > 477: * Windows Server 2022 10 0 > (!VER_NT_WORKSTATION) > 478: * where (buildNumber > 20347) There is a comment at line 392 that you may want to adjust too - perhaps just say "Windows Server 2016+" to avoid the need to keep updating it. - Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5347
Re: RFR: JDK-8273229: Update OS detection code to recognize Windows Server 2022
On Thu, 2 Sep 2021 06:43:16 GMT, Matthias Baesken wrote: > Hello, please review this small change. > The OS detection code of the JDK/JVM should recognize the new Windows server > 2022 : > > https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022 > https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info > > The build number of Windows server 2022 according to the documentation in the > second link is 20348 . > Thanks, Matthias The link to the "Windows Server release information" page is useful to check the build number - thanks! - Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5347
Re: RFR: 8273261: Replace 'while' cycles with iterator with enhanced-for in java.base
On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov wrote: > There are few places in code where manual while loop is used with Iterator to > iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle > instead: it's less verbose, makes code easier to read and it's less > error-prone. > It doesn't have any performance impact: java compiler generates similar code > when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 Tested "tier2" on linux-x86_64-server-fastdebug Ubuntu 21.04 == Test summary == TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk:tier2 3772 3771 1 0 << jtreg:test/langtools:tier2 1111 0 0 jtreg:test/jaxp:tier2 452 452 0 0 == TEST FAILURE Only one test `java/nio/file/FileStore/Basic.java` failed, but it fails without my changes too. --System.out:(46/2591)-- - PR: https://git.openjdk.java.net/jdk/pull/5328
RFR: 8273261: Replace 'while' cycles with iterator with enhanced-for in java.base
There are few places in code where manual while loop is used with Iterator to iterate over Collection. Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. Similar cleanups: * https://bugs.openjdk.java.net/browse/JDK-8258006 * https://bugs.openjdk.java.net/browse/JDK-8257912 - Commit messages: - [PATCH] Replace while cycles with iterator with enhanced-for in java.base Changes: https://git.openjdk.java.net/jdk/pull/5328/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5328=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273261 Stats: 93 lines in 11 files changed: 1 ins; 50 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/5328.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5328/head:pull/5328 PR: https://git.openjdk.java.net/jdk/pull/5328
RFR: JDK-8273229: Update OS detection code to recognize Windows Server 2022
Hello, please review this small change. The OS detection code of the JDK/JVM should recognize the new Windows server 2022 : https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022 https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info The build number of Windows server 2022 according to the documentation in the second link is 20348 . Thanks, Matthias - Commit messages: - JDK-8273229 Changes: https://git.openjdk.java.net/jdk/pull/5347/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5347=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273229 Stats: 11 lines in 2 files changed: 8 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5347.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5347/head:pull/5347 PR: https://git.openjdk.java.net/jdk/pull/5347
