Re: RFR: 8284640: CollectorImpl class could be a record class
On Mon, 11 Apr 2022 13:08:43 GMT, altrisi wrote: > Changes the definition of `CollectorImpl` to be a record. @stuart-marks Mind review this simple cleanup? - PR: https://git.openjdk.java.net/jdk/pull/8179
Re: RFR: 8286571: java source launcher from a minimal jdk image containing jdk.compiler fails with --enable-preview option [v3]
On Wed, 18 May 2022 06:30:34 GMT, Adam Sotona wrote: >> ### Problem description >> Minimal jdk image created by jlink with the only jdk.compiler module and its >> dependencies >> fails to run java source launcher correctly (for example when --source N is >> specified). >> Failing source launcher is only one the expressions of internal jdk.compiler >> malfunction, another example is failure to run javac with --release option. >> >> ### Root cause >> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse >> ct.sym file and so to provide full functionality. >> Module jdk.zipfs is not included in the minimal JDK image, because module >> jdk.compiler does not declare it as "requires" in its module info. >> >> ### Alternative patch >> The problem can be alternatively resolved by complex code checks in >> jdk.compiler to provide user with valid error message, however that solution >> would be just a workaround for jdk.compiler dual functionality (with or >> without presence of jdk.zipfs module). Compiler functionality without access >> to ct.sym through jdk.zipfs is very limited. >> >> ### Proposed fix >> This patch fixes the problem by explicit declaration of jdk.compiler >> dependency on jdk.zipfs. >> Plus added specific test case. >> >> Please review the patch or raise objections against declaration of >> jdk.compiler dependent on jdk.zipfs. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional > commit since the last revision: > > corrected LimitedImage test description Thank you for changing the description of the test. That part now looks fine to me. - PR: https://git.openjdk.java.net/jdk/pull/8747
Re: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v6]
> Please review this change to replace the finalizer in > `AbstractLdapNamingEnumeration` with a Cleaner. > > The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult > res`, and `LdapClient enumClnt`) are moved to a static inner class . From > there, the change is fairly mechanical. > > Details of note: > 1. Some operations need to change the state values (the update() method is > probably the most interesting). > 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read > `homeCtx` from the superclass's `state`. > > The test case is based on a copy of > `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case > might be possible, but this was done for expediency. > > The test only confirms that the new Cleaner use does not keep the object > reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` > or `LdapBindingEnumeration`, though all are subclasses of > `AbstractLdapNamingEnumeration`). > > Thanks. Brent Christian has updated the pull request incrementally with one additional commit since the last revision: NOW it builds - Changes: - all: https://git.openjdk.java.net/jdk/pull/8311/files - new: https://git.openjdk.java.net/jdk/pull/8311/files/9ffaa788..a48a56cc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8311=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8311=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8311.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8311/head:pull/8311 PR: https://git.openjdk.java.net/jdk/pull/8311
Re: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v5]
> Please review this change to replace the finalizer in > `AbstractLdapNamingEnumeration` with a Cleaner. > > The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult > res`, and `LdapClient enumClnt`) are moved to a static inner class . From > there, the change is fairly mechanical. > > Details of note: > 1. Some operations need to change the state values (the update() method is > probably the most interesting). > 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read > `homeCtx` from the superclass's `state`. > > The test case is based on a copy of > `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case > might be possible, but this was done for expediency. > > The test only confirms that the new Cleaner use does not keep the object > reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` > or `LdapBindingEnumeration`, though all are subclasses of > `AbstractLdapNamingEnumeration`). > > Thanks. Brent Christian has updated the pull request incrementally with one additional commit since the last revision: Fix the merge fix - Changes: - all: https://git.openjdk.java.net/jdk/pull/8311/files - new: https://git.openjdk.java.net/jdk/pull/8311/files/6398e5e5..9ffaa788 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8311=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8311=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8311.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8311/head:pull/8311 PR: https://git.openjdk.java.net/jdk/pull/8311
Re: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v4]
> Please review this change to replace the finalizer in > `AbstractLdapNamingEnumeration` with a Cleaner. > > The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult > res`, and `LdapClient enumClnt`) are moved to a static inner class . From > there, the change is fairly mechanical. > > Details of note: > 1. Some operations need to change the state values (the update() method is > probably the most interesting). > 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read > `homeCtx` from the superclass's `state`. > > The test case is based on a copy of > `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case > might be possible, but this was done for expediency. > > The test only confirms that the new Cleaner use does not keep the object > reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` > or `LdapBindingEnumeration`, though all are subclasses of > `AbstractLdapNamingEnumeration`). > > Thanks. Brent Christian has updated the pull request incrementally with one additional commit since the last revision: Fix merge - Changes: - all: https://git.openjdk.java.net/jdk/pull/8311/files - new: https://git.openjdk.java.net/jdk/pull/8311/files/9d19775b..6398e5e5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8311=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8311=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8311.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8311/head:pull/8311 PR: https://git.openjdk.java.net/jdk/pull/8311
Re: RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne [v2]
On Fri, 20 May 2022 22:22:43 GMT, Sandhya Viswanathan
wrote:
>> I see that you swapped `src, dst` in `match()` but `format` is sill
>> incorrect and the code is confusing.
>
> I agree with @vnkozlov that this needs explanation. Could you please add
> comments here with IR and example code generated for both the eq case and ne
> case? You have some explanation in the PR description but not in the code.
> The description needs to be in the code as well for maintenance.
Right, I missed that. Then you can use `expand %{` to avoid duplication (keep
format).
-
PR: https://git.openjdk.java.net/jdk/pull/8525
RFR: 8287103: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java fails with Xcomp
Sync improved in test - Commit messages: - 8287103: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java fails with Xcomp Changes: https://git.openjdk.java.net/jdk/pull/8821/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8821=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287103 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8821.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8821/head:pull/8821 PR: https://git.openjdk.java.net/jdk/pull/8821
Re: RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne [v2]
On Wed, 4 May 2022 23:16:41 GMT, Vladimir Kozlov wrote:
>> src/hotspot/cpu/x86/x86_64.ad line 6998:
>>
>>> 6996: ins_encode %{
>>> 6997: __ cmovl(Assembler::parity, $dst$$Register, $src$$Register);
>>> 6998: __ cmovl(Assembler::notEqual, $dst$$Register, $src$$Register);
>>
>> Should this be `equal`?
>
> I see that you swapped `src, dst` in `match()` but `format` is sill incorrect
> and the code is confusing.
I agree with @vnkozlov that this needs explanation. Could you please add
comments here with IR and example code generated for both the eq case and ne
case? You have some explanation in the PR description but not in the code. The
description needs to be in the code as well for maintenance.
-
PR: https://git.openjdk.java.net/jdk/pull/8525
Re: RFR: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo [v2]
On Fri, 20 May 2022 20:02:28 GMT, Roger Riggs wrote:
>> liach has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Convert PrimitiveTypeInfo to an enum
>
> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 932:
>
>> 930: */
>> 931: private static final class PrimitiveTypeInfo {
>> 932: private static final PrimitiveTypeInfo BYTE = new
>> PrimitiveTypeInfo(byte.class, 0);
>
> Can this be `private enum PrimitiveTypeInfo...` or perhaps a record class?
Thanks. I've converted it into an enum following the suit of
`sun.invoke.util.Wrapper`. I think an enum fits better here as we don't need
the canonical constructor and object methods of a record.
-
PR: https://git.openjdk.java.net/jdk/pull/8801
Re: RFR: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo [v2]
> Simplify opcode handling, use `final` in `PrimitiveTypeInfo`, and replace the > hash map with a simple lookup, similar to what's done in > [JDK-8284880](https://bugs.openjdk.java.net/browse/JDK-8284880) (#8242) liach has updated the pull request incrementally with one additional commit since the last revision: Convert PrimitiveTypeInfo to an enum - Changes: - all: https://git.openjdk.java.net/jdk/pull/8801/files - new: https://git.openjdk.java.net/jdk/pull/8801/files/16f3de8f..be9987bb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8801=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8801=00-01 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/8801.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8801/head:pull/8801 PR: https://git.openjdk.java.net/jdk/pull/8801
Re: RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne
On Wed, 18 May 2022 14:59:33 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch optimises the matching rules for floating-point comparison with >> respects to eq/ne on x86-64 >> >> 1, When the inputs of a comparison is the same (i.e `isNaN` patterns), `ZF` >> is always set, so we don't need `cmpOpUCF2` for the eq/ne cases, which >> improves the sequence of `If (CmpF x x) (Bool ne)` from >> >> ucomiss xmm0, xmm0 >> jp label >> jne label >> >> into >> >> ucomiss xmm0, xmm0 >> jp label >> >> 2, The move rules for `cmpOpUCF2` is missing, which makes patterns such as >> `x == y ? 1 : 0` to fall back to `cmpOpU`, which have a really high cost of >> fixing the flags, such as >> >> xorlecx, ecx >> ucomiss xmm0, xmm1 >> jnp done >> pushf >> andq[rsp], 0xff2b >> popf >> done: >> movleax, 1 >> cmovel eax, ecx >> >> The patch changes this sequence into >> >> xorlecx, ecx >> ucomiss xmm0, xmm1 >> movleax, 1 >> cmovpl eax, ecx >> cmovnel eax, ecx >> >> 3, The patch also changes the pattern of `isInfinite` to be more optimised >> by using `Math.abs` to reduce 1 comparison and compares the result with >> `MAX_VALUE` since `>` is more optimised than `==` for floating-point types. >> >> The benchmark results are as follow: >> >> Before: >> Benchmark Mode Cnt Score Error Units >> FPComparison.equalDouble avgt5 2876.242 ± 58.875 ns/op >> FPComparison.equalFloatavgt5 3062.430 ± 31.371 ns/op >> FPComparison.isFiniteDoubleavgt5 475.749 ± 19.027 ns/op >> FPComparison.isFiniteFloat avgt5 506.525 ± 14.417 ns/op >> FPComparison.isInfiniteDouble avgt5 1232.800 ± 31.677 ns/op >> FPComparison.isInfiniteFloat avgt5 1234.708 ± 70.239 ns/op >> FPComparison.isNanDouble avgt5 2255.847 ± 7.238 ns/op >> FPComparison.isNanFloatavgt5 2567.044 ± 36.078 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> FPComparison.equalDouble avgt5 594.636 ± 8.922 ns/op >> FPComparison.equalFloatavgt5 663.849 ± 3.656 ns/op >> FPComparison.isFiniteDoubleavgt5 518.309 ± 107.352 ns/op >> FPComparison.isFiniteFloat avgt5 515.576 ± 14.669 ns/op >> FPComparison.isInfiniteDouble avgt5 621.185 ± 11.935 ns/op >> FPComparison.isInfiniteFloat avgt5 623.566 ± 15.206 ns/op >> FPComparison.isNanDouble avgt5 400.124 ± 0.762 ns/op >> FPComparison.isNanFloatavgt5 546.486 ± 1.509 ns/op >> >> Thank you very much. > > I have reverted the changes to `java.lang.Float` and `java.lang.Double` to > not interfere with the intrinsic PR. More tests are added to cover all cases > regarding floating-point comparison of compiled code. > > The rules for fp comparison that output the result to `rFlagRegsU` are > expensive and should be avoided. As a result, I removed the shortcut rules > with memory or constant operands to reduce the number of match rules. Only > the basic rules are kept. > > Thanks. @merykitty Very nice work! The patch looks good to me. @merykitty Very nice work! The patch looks good to me. - PR: https://git.openjdk.java.net/jdk/pull/8525
Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v12]
On Sun, 15 May 2022 14:17:41 GMT, Piotr Tarsa wrote:
>> iaroslavski has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>>
>> * Improved mixed insertion sort
>> * Optimized insertion sort
>> * Improved merging sort
>> * Optimized soring tests
>
> i think it would make much more sense to have the extra buffer size limit in
> bytes, not in elements. for single-threaded sorting the limit should be low,
> e.g. 1/64 of the heap, not 1/8 (in case of sorting e.g. longs as each long is
> 8 byte long). multi-threaded sorting could be more aggressive when it comes
> to resource usage as it's less likely to be used in resource constrained
> environment.
@tarsa Hi Piotr,
Thank you for your interest to sorting and your point to allocation of buffers
in sorting.
Let’s I share my thoughts.
The number of elements of any array is not more than ~2 billion
(max positive int value) and therefore the size (in bytes) of
int array is not more than ~2 GB * 4 = ~8 GB.
We need additional buffer for int, long, float and double types only.
We will have 2 constants which limit the number of int/float and
long/double elements in array, like this:
private static final int MAX_BUFFER_LENGTH_1 = // for int/float
(int) Math.min(Runtime.getRuntime().maxMemory() >> 10,
Integer.MAX_VALUE);
private static final int MAX_BUFFER_LENGTH_2 = // for
long/double
(int) Math.min(Runtime.getRuntime().maxMemory() >> 11,
Integer.MAX_VALUE);
See, that the max number of elements for long/double is in 2 times less than
for int/float,
because long/double occupies 2 times more bytes.
I take factors 10 and 11 as example, it may be other values, but the first is
less than the second by 1.
Why do we need to use Math.min(…, Integer.MAX_VALUE)? We must do it in this
case:
if Runtime.getRuntime().maxMemory() >> 11 is larger than max int (for example,
we have power server),
casting to int will produce negative value. So, limit by 2 Gb max is required.
And the method tryAllocate will look like this:
private static Object tryAllocate(Object a, int length) {
try {
if (a instanceof int[]) {
return length > MAX_BUFFER_LENGTH_1 ? null : new int[length];
}
if (a instanceof long[]) {
return length > MAX_BUFFER_LENGTH_2 ? null : new long[length];
}
if (a instanceof float[]) {
return length > MAX_BUFFER_LENGTH_1 ? null : new float[length];
}
if (a instanceof double[]) {
return length > MAX_BUFFER_LENGTH_2 ? null : new double[length];
}
throw new IllegalArgumentException("Unknown array: " +
a.getClass().getName());
} catch (OutOfMemoryError e) {
return null;
}
}
What do you think, what value of shift is the best, 6, 7, 8, 9, 10, 11, 12 etc.?
Runtime.getRuntime().maxMemory() >> 10??
Do you have actual scenarios? Actual requirements? Your feedback are welcome!
-
PR: https://git.openjdk.java.net/jdk/pull/3938
Re: RFR: 8284638: store skip buffers in InputStream Object [v12]
On Wed, 20 Apr 2022 16:52:31 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> add documents
src/java.base/share/classes/java/io/InputStream.java line 72:
> 70: *
> 71: * @param size minimum length that the skip byte array must have.
> 72: * notice that this param input MUST be equal or less
> than {@link #MAX_SKIP_BUFFER_SIZE MAX_SKIP_BUFFER_SIZE}.
The "MUST be equal" reads like something will go wrong if that condition isn't
satisfied.
This method does not care about the size, except in potentially resizing if the
requested size is larger.
The "notice..." statement is making a statement about code in the caller, and
so doesn't belong here.
src/java.base/share/classes/java/io/InputStream.java line 75:
> 73: * @return the byte array.
> 74: */
> 75: private byte[] skipBufferReference(int size) {
The method name would match the return value better if named `skipBuffer(size)`.
src/java.base/share/classes/java/io/InputStream.java line 78:
> 76: SoftReference ref = this.skipBufferReference;
> 77: byte[] buffer;
> 78: if (ref == null || (buffer = ref.get()) == null || buffer.length
> < size) {
A comment here or in the method javadoc to the effect that a new buffer is
allocated unless the existing buffer is large enough might head off doubt that
buffer is always non-null at the return. As would inverting the if:
if (ref != null && (buffer = ref.get()) != null && buffer.length >= size) {
return buffer;
}
// allocate new or larger buffer
buffer = new byte[size];
this.skipBufferReference = new SoftReference<>(buffer);
return buffer;
-
PR: https://git.openjdk.java.net/jdk/pull/5872
Re: RFR: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo
On Fri, 20 May 2022 04:55:37 GMT, liach wrote:
> Simplify opcode handling, use `final` in `PrimitiveTypeInfo`, and replace the
> hash map with a simple lookup, similar to what's done in
> [JDK-8284880](https://bugs.openjdk.java.net/browse/JDK-8284880) (#8242)
src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 932:
> 930: */
> 931: private static final class PrimitiveTypeInfo {
> 932: private static final PrimitiveTypeInfo BYTE = new
> PrimitiveTypeInfo(byte.class, 0);
Can this be `private enum PrimitiveTypeInfo...` or perhaps a record class?
-
PR: https://git.openjdk.java.net/jdk/pull/8801
Re: RFR: 8285401: Proxy class initializer should use 3-arg `Class.forName` to avoid unnecessary class initialization [v3]
On Fri, 20 May 2022 18:22:47 GMT, liach wrote: >> Simplify calls `Class.forName(String, boolean, ClassLoader)` instead of >> `Class.forName(String)`. `make test >> TEST="jtreg:test/jdk/java/lang/reflect/Proxy"` passes, with the new >> `LazyInitializationTest` failing the eager initialization check on the >> baseline and passing with this patch. >> >> On a side note, this might reduce the number of methods that can be encoded >> in a proxy due to code attribute size restrictions; we probably would >> address that in another issue, as we never mandated a count of methods that >> the proxy must be able to implement. >> >> Mandy, would you mind review this? > > liach has updated the pull request incrementally with one additional commit > since the last revision: > > Move the try catch block as it doesn't throw checked exceptions Looks fine. - Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8800
Re: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v10]
On Tue, 17 May 2022 23:40:04 GMT, Naoto Sato wrote: >> Supporting `IsoFields` temporal fields in chronologies that are similar to >> ISO chronology. Corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull request contains 13 additional commits since > the last revision: > > - Merge branch 'master' into JDK-8279185 > - Addressing review comments > - Revert to use the default method > - Removed unnecessary package names > - Modified class desc of `IsoFields` > - abstract class -> top level interface > - interface -> abstract class > - Removed the method > - Changed to use a type to determine ISO based or not > - Renamed the new method > - ... and 3 more: > https://git.openjdk.java.net/jdk/compare/3b1d6d84...3f69909f Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7683
Re: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v10]
On Tue, 17 May 2022 23:40:04 GMT, Naoto Sato wrote: >> Supporting `IsoFields` temporal fields in chronologies that are similar to >> ISO chronology. Corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull request contains 13 additional commits since > the last revision: > > - Merge branch 'master' into JDK-8279185 > - Addressing review comments > - Revert to use the default method > - Removed unnecessary package names > - Modified class desc of `IsoFields` > - abstract class -> top level interface > - interface -> abstract class > - Removed the method > - Changed to use a type to determine ISO based or not > - Renamed the new method > - ... and 3 more: > https://git.openjdk.java.net/jdk/compare/2761b08b...3f69909f Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7683
Re: RFR: 8285401: Proxy class initializer should use 3-arg `Class.forName` to avoid unnecessary class initialization [v2]
On Fri, 20 May 2022 11:51:09 GMT, ExE Boss wrote: >> liach has updated the pull request incrementally with one additional commit >> since the last revision: >> >> remove unused field > > src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 608: > >> 606: mv.visitMethodInsn(INVOKEVIRTUAL, JL_CLASS, >> 607: "getClassLoader", "()" + LJL_CLASSLOADER, false); >> 608: mv.visitVarInsn(ASTORE, 0); > > Shouldn’t this go before `mv.visitLabel(L_startBlock)`? Done. - PR: https://git.openjdk.java.net/jdk/pull/8800
Re: RFR: 8285401: Proxy class initializer should use 3-arg `Class.forName` to avoid unnecessary class initialization [v3]
> Simplify calls `Class.forName(String, boolean, ClassLoader)` instead of > `Class.forName(String)`. `make test > TEST="jtreg:test/jdk/java/lang/reflect/Proxy"` passes, with the new > `LazyInitializationTest` failing the eager initialization check on the > baseline and passing with this patch. > > On a side note, this might reduce the number of methods that can be encoded > in a proxy due to code attribute size restrictions; we probably would address > that in another issue, as we never mandated a count of methods that the proxy > must be able to implement. > > Mandy, would you mind review this? liach has updated the pull request incrementally with one additional commit since the last revision: Move the try catch block as it doesn't throw checked exceptions - Changes: - all: https://git.openjdk.java.net/jdk/pull/8800/files - new: https://git.openjdk.java.net/jdk/pull/8800/files/64a70479..82f8eeb9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8800=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8800=01-02 Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8800.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8800/head:pull/8800 PR: https://git.openjdk.java.net/jdk/pull/8800
Re: RFR: 8286571: java source launcher from a minimal jdk image containing jdk.compiler fails with --enable-preview option [v3]
On Wed, 18 May 2022 06:30:34 GMT, Adam Sotona wrote: >> ### Problem description >> Minimal jdk image created by jlink with the only jdk.compiler module and its >> dependencies >> fails to run java source launcher correctly (for example when --source N is >> specified). >> Failing source launcher is only one the expressions of internal jdk.compiler >> malfunction, another example is failure to run javac with --release option. >> >> ### Root cause >> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse >> ct.sym file and so to provide full functionality. >> Module jdk.zipfs is not included in the minimal JDK image, because module >> jdk.compiler does not declare it as "requires" in its module info. >> >> ### Alternative patch >> The problem can be alternatively resolved by complex code checks in >> jdk.compiler to provide user with valid error message, however that solution >> would be just a workaround for jdk.compiler dual functionality (with or >> without presence of jdk.zipfs module). Compiler functionality without access >> to ct.sym through jdk.zipfs is very limited. >> >> ### Proposed fix >> This patch fixes the problem by explicit declaration of jdk.compiler >> dependency on jdk.zipfs. >> Plus added specific test case. >> >> Please review the patch or raise objections against declaration of >> jdk.compiler dependent on jdk.zipfs. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional > commit since the last revision: > > corrected LimitedImage test description FWIW, if adding this dependency would be seen unacceptable, we could try to tweak jlink to at least produce a warning when building an image with jdk.compiler but without jdk.zipfs. - PR: https://git.openjdk.java.net/jdk/pull/8747
Re: RFR: 8284638: store skip buffers in InputStream Object [v7]
On Wed, 20 Apr 2022 16:36:16 GMT, XenoAmess wrote: >>> no, we use other way, but yes for we take care of thread safety. >> >> Fair enough. >> >>> Don't think it necessary... I think making it cannot touched by other >>> object (with security manager on) is enough. >> >> I was thinking more for heapdumps due to extending the life of the skip >> buffer in this patch. At least we don't have to waste more cycles. >> >> Oh I forgot last time but, it looks like MIN_SKIP_BUFFER_SIZE is not used. >> Unless I'm missing something I assume that is a bug. > > @jmehrens comments about not making it static added. > @XenoAmess This pull request has been inactive for more than 4 weeks and will > be automatically closed if another 4 weeks passes without any activity. To > avoid this, simply add a new comment to the pull request. Feel free to ask > for assistance if you need help with progressing this pull request towards > integration! comment. - PR: https://git.openjdk.java.net/jdk/pull/5872
Re: RFR: 8287053: Avoid redundant HashMap.containsKey calls in ZoneInfoFile.getZoneInfo0
On Sat, 30 Apr 2022 17:00:03 GMT, Andrey Turbanov wrote: > Instead of pair `HashMap.containsKey`/`HashMap.get` method calls, we can use > single call `HashMap.getOrDefault`. > It's faster and clearer. Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8487
Re: RFR: 8287053: Avoid redundant HashMap.containsKey calls in ZoneInfoFile.getZoneInfo0
On Sat, 30 Apr 2022 17:00:03 GMT, Andrey Turbanov wrote: > Instead of pair `HashMap.containsKey`/`HashMap.get` method calls, we can use > single call `HashMap.getOrDefault`. > It's faster and clearer. Marked as reviewed by naoto (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8487
Re: RFR: 8285401: Proxy class initializer should use 3-arg `Class.forName` to avoid unnecessary class initialization [v2]
On Fri, 20 May 2022 04:06:19 GMT, liach wrote: >> Simplify calls `Class.forName(String, boolean, ClassLoader)` instead of >> `Class.forName(String)`. `make test >> TEST="jtreg:test/jdk/java/lang/reflect/Proxy"` passes, with the new >> `LazyInitializationTest` failing the eager initialization check on the >> baseline and passing with this patch. >> >> On a side note, this might reduce the number of methods that can be encoded >> in a proxy due to code attribute size restrictions; we probably would >> address that in another issue, as we never mandated a count of methods that >> the proxy must be able to implement. >> >> Mandy, would you mind review this? > > liach has updated the pull request incrementally with one additional commit > since the last revision: > > remove unused field src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 608: > 606: mv.visitMethodInsn(INVOKEVIRTUAL, JL_CLASS, > 607: "getClassLoader", "()" + LJL_CLASSLOADER, false); > 608: mv.visitVarInsn(ASTORE, 0); Shouldn’t this go before `mv.visitLabel(L_startBlock)`? - PR: https://git.openjdk.java.net/jdk/pull/8800
Re: RFR: 8286825: Linker naming cleanup [v2]
On Fri, 20 May 2022 10:57:44 GMT, Jorn Vernee wrote: >> This patch is a batch naming cleanup for the foreign linker implementation. >> >> The naming changes are as follows: >> >> - ProgrammableInvoker -> DowncallLinker >> - ProgrammableUpcallHandler -> UpcallLinker >> - 'native invoker' -> 'downcall stub' >> - 'optimzed entry blob' -> 'upcall stub' >> - OptimizedEntryBlob -> UpcallStub >> - optimized_entry_frame -> upcall_stub_frame >> >> Then renaming of some hotspot files: >> >> - universalNativeInvoker* -> downcallLinker* >> - universalUpcallHandler* -> upcallLinker* >> - foreign_globals* -> foreignGlobals* (to match existing convention) >> >> Method, field, and other variable names are also adjusted accordingly. > > Jorn Vernee has updated the pull request incrementally with one additional > commit since the last revision: > > Comments + cleanup Marked as reviewed by mcimadamore (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8777
Re: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v8]
On Fri, 20 May 2022 09:51:24 GMT, Jatin Bhateja wrote: >> Hi All, >> >> Patch adds the planned support for new vector operations and APIs targeted >> for [JEP 426: Vector API (Fourth >> Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) >> >> Following is the brief summary of changes:- >> >> 1) Extends the scope of existing lanewise API for following new vector >> operations. >>- VectorOperations.BIT_COUNT: counts the number of one-bits >>- VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero >> bits >>- VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing >> zero bits >>- VectorOperations.REVERSE: reversing the order of bits >>- VectorOperations.REVERSE_BYTES: reversing the order of bytes >>- compress and expand bits: Semantics are based on Hacker's Delight >> section 7-4 Compress, or Generalized Extract. >> >> 2) Adds following new APIs to perform cross lane vector compress and >> expansion operations under the influence of a mask. >>- Vector.compress >>- Vector.expand >>- VectorMask.compress >> >> 3) Adds predicated and non-predicated versions of following new APIs to load >> and store the contents of vector from foreign MemorySegments. >> - Vector.fromMemorySegment >> - Vector.intoMemorySegment >> >> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support >> for each newly added operation. >> >> >> Patch has been regressed over AARCH64 and X86 targets different AVX levels. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional > commit since the last revision: > > 8284960: Integrating incremental patches. The javac changes look OK to me. - Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8425
Re: RFR: 8286825: Linker naming cleanup
On Wed, 18 May 2022 16:54:06 GMT, Jorn Vernee wrote: > This patch is a batch naming cleanup for the foreign linker implementation. > > The naming changes are as follows: > > - ProgrammableInvoker -> DowncallLinker > - ProgrammableUpcallHandler -> UpcallLinker > - 'native invoker' -> 'downcall stub' > - 'optimzed entry blob' -> 'upcall stub' > - OptimizedEntryBlob -> UpcallStub > - optimized_entry_frame -> upcall_stub_frame > > Then renaming of some hotspot files: > > - universalNativeInvoker* -> downcallLinker* > - universalUpcallHandler* -> upcallLinker* > - foreign_globals* -> foreignGlobals* (to match existing convention) > > Method, field, and other variable names are also adjusted accordingly. Addressed now. I also noticed some names in strings that weren't updated yet. Updated those as well. - PR: https://git.openjdk.java.net/jdk/pull/8777
Re: RFR: 8286825: Linker naming cleanup [v2]
> This patch is a batch naming cleanup for the foreign linker implementation. > > The naming changes are as follows: > > - ProgrammableInvoker -> DowncallLinker > - ProgrammableUpcallHandler -> UpcallLinker > - 'native invoker' -> 'downcall stub' > - 'optimzed entry blob' -> 'upcall stub' > - OptimizedEntryBlob -> UpcallStub > - optimized_entry_frame -> upcall_stub_frame > > Then renaming of some hotspot files: > > - universalNativeInvoker* -> downcallLinker* > - universalUpcallHandler* -> upcallLinker* > - foreign_globals* -> foreignGlobals* (to match existing convention) > > Method, field, and other variable names are also adjusted accordingly. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Comments + cleanup - Changes: - all: https://git.openjdk.java.net/jdk/pull/8777/files - new: https://git.openjdk.java.net/jdk/pull/8777/files/7b0e3a88..b362a822 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8777=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8777=00-01 Stats: 14 lines in 3 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/8777.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8777/head:pull/8777 PR: https://git.openjdk.java.net/jdk/pull/8777
Re: RFR: 8286825: Linker naming cleanup
On Fri, 20 May 2022 10:36:17 GMT, Maurizio Cimadamore wrote: >> This patch is a batch naming cleanup for the foreign linker implementation. >> >> The naming changes are as follows: >> >> - ProgrammableInvoker -> DowncallLinker >> - ProgrammableUpcallHandler -> UpcallLinker >> - 'native invoker' -> 'downcall stub' >> - 'optimzed entry blob' -> 'upcall stub' >> - OptimizedEntryBlob -> UpcallStub >> - optimized_entry_frame -> upcall_stub_frame >> >> Then renaming of some hotspot files: >> >> - universalNativeInvoker* -> downcallLinker* >> - universalUpcallHandler* -> upcallLinker* >> - foreign_globals* -> foreignGlobals* (to match existing convention) >> >> Method, field, and other variable names are also adjusted accordingly. > > src/hotspot/cpu/riscv/upcallLinker_riscv.cpp line 30: > >> 28: #include "utilities/debug.hpp" >> 29: >> 30: address UpcallLinker::generate_optimized_upcall_stub(jobject receiver, >> Method* entry, > > Hasn't "generated_optimized_upcall_stub" changed too? Right, I missed that one. Good catch! - PR: https://git.openjdk.java.net/jdk/pull/8777
Re: RFR: 8286825: Linker naming cleanup
On Wed, 18 May 2022 16:54:06 GMT, Jorn Vernee wrote: > This patch is a batch naming cleanup for the foreign linker implementation. > > The naming changes are as follows: > > - ProgrammableInvoker -> DowncallLinker > - ProgrammableUpcallHandler -> UpcallLinker > - 'native invoker' -> 'downcall stub' > - 'optimzed entry blob' -> 'upcall stub' > - OptimizedEntryBlob -> UpcallStub > - optimized_entry_frame -> upcall_stub_frame > > Then renaming of some hotspot files: > > - universalNativeInvoker* -> downcallLinker* > - universalUpcallHandler* -> upcallLinker* > - foreign_globals* -> foreignGlobals* (to match existing convention) > > Method, field, and other variable names are also adjusted accordingly. Looks good - I spotted a potential issue in the risc-v port src/hotspot/cpu/riscv/upcallLinker_riscv.cpp line 30: > 28: #include "utilities/debug.hpp" > 29: > 30: address UpcallLinker::generate_optimized_upcall_stub(jobject receiver, > Method* entry, Hasn't "generated_optimized_upcall_stub" changed too? src/hotspot/cpu/riscv/upcallLinker_riscv.cpp line 38: > 36: ShouldNotCallThis(); > 37: return nullptr; > 38: } Missing newline (this was here before) - PR: https://git.openjdk.java.net/jdk/pull/8777
Re: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v8]
On Fri, 20 May 2022 09:51:24 GMT, Jatin Bhateja wrote: >> Hi All, >> >> Patch adds the planned support for new vector operations and APIs targeted >> for [JEP 426: Vector API (Fourth >> Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) >> >> Following is the brief summary of changes:- >> >> 1) Extends the scope of existing lanewise API for following new vector >> operations. >>- VectorOperations.BIT_COUNT: counts the number of one-bits >>- VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero >> bits >>- VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing >> zero bits >>- VectorOperations.REVERSE: reversing the order of bits >>- VectorOperations.REVERSE_BYTES: reversing the order of bytes >>- compress and expand bits: Semantics are based on Hacker's Delight >> section 7-4 Compress, or Generalized Extract. >> >> 2) Adds following new APIs to perform cross lane vector compress and >> expansion operations under the influence of a mask. >>- Vector.compress >>- Vector.expand >>- VectorMask.compress >> >> 3) Adds predicated and non-predicated versions of following new APIs to load >> and store the contents of vector from foreign MemorySegments. >> - Vector.fromMemorySegment >> - Vector.intoMemorySegment >> >> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support >> for each newly added operation. >> >> >> Patch has been regressed over AARCH64 and X86 targets different AVX levels. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional > commit since the last revision: > > 8284960: Integrating incremental patches. Javac changes look good - Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8425
Re: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v7]
On Thu, 19 May 2022 21:19:49 GMT, Paul Sandoz wrote:
>> Jatin Bhateja has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 16 commits:
>>
>> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>> - 8284960: Changes to enable jdk.incubator.vector to be treated as preview
>> participant. Code re-organization related to Reverse/ReverseByte IR
>> transforms.
>> - 8284960: Adding --enable-preview in vectorAPI benchmarks.
>> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>> - 8284960: Review comments resolution.
>> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>> - 8284960: Correcting a typo.
>> - 8284960: Integrating changes from panama-vector (Add @since 19 tags).
>> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>> - ... and 6 more:
>> https://git.openjdk.java.net/jdk/compare/9f562ef7...311f3233
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java line 50:
>
>> 48: import java.util.Set;
>> 49:
>> 50: import static com.sun.tools.javac.code.Flags.PREVIEW_API;
>
> Suggestion:
>
>
> Redundant import (sorry i should have checked before i sent you updates to
> this area)
Merged
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java line 132:
>
>> 130: * @return true if {@code s} is participating in the preview of
>> {@code previewSymbol}
>> 131: */
>> 132: public boolean isPreviewParticipating(Symbol s, Symbol
>> previewSymbol) {
>
> Some feedback from a colleague:
> Suggestion:
>
> /**
> * Returns true if {@code s} is deemed to participate in the preview of
> {@code previewSymbol}, and
> * therefore no warnings or errors will be produced.
> *
> * @param s the symbol depending on the preview symbol
> * @param previewSymbol the preview symbol marked with @Preview
> * @return true if {@code s} is participating in the preview of {@code
> previewSymbol}
> */
> public boolean participatesInPreview(Symbol s, Symbol previewSymbol) {
Merged.
-
PR: https://git.openjdk.java.net/jdk/pull/8425
Re: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v8]
> Hi All, > > Patch adds the planned support for new vector operations and APIs targeted > for [JEP 426: Vector API (Fourth > Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) > > Following is the brief summary of changes:- > > 1) Extends the scope of existing lanewise API for following new vector > operations. >- VectorOperations.BIT_COUNT: counts the number of one-bits >- VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero > bits >- VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing > zero bits >- VectorOperations.REVERSE: reversing the order of bits >- VectorOperations.REVERSE_BYTES: reversing the order of bytes >- compress and expand bits: Semantics are based on Hacker's Delight > section 7-4 Compress, or Generalized Extract. > > 2) Adds following new APIs to perform cross lane vector compress and > expansion operations under the influence of a mask. >- Vector.compress >- Vector.expand >- VectorMask.compress > > 3) Adds predicated and non-predicated versions of following new APIs to load > and store the contents of vector from foreign MemorySegments. > - Vector.fromMemorySegment > - Vector.intoMemorySegment > > 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support > for each newly added operation. > > > Patch has been regressed over AARCH64 and X86 targets different AVX levels. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8284960: Integrating incremental patches. - Changes: - all: https://git.openjdk.java.net/jdk/pull/8425/files - new: https://git.openjdk.java.net/jdk/pull/8425/files/311f3233..17a0e38c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8425=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8425=06-07 Stats: 32 lines in 7 files changed: 0 ins; 26 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8425.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8425/head:pull/8425 PR: https://git.openjdk.java.net/jdk/pull/8425
Integrated: 8286858: Remove dead code in sun.reflect.misc.MethodUtil
On Sun, 15 May 2022 12:47:10 GMT, Andrey Turbanov wrote: > They are unused and leftover since JDK 7. It's good to remove them. This pull request has now been integrated. Changeset: 4587337e Author:Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/4587337e956ed6f1a59e9d980a09ab9f784fbde0 Stats: 179 lines in 1 file changed: 4 ins; 170 del; 5 mod 8286858: Remove dead code in sun.reflect.misc.MethodUtil Reviewed-by: mchung, iris - PR: https://git.openjdk.java.net/jdk/pull/8715
Re: RFR: 8284209: Replace remaining usages of 'a the' in source code
On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: > a/the, an?/an?, the/the… > > It's the last issue in the series, and it still touches different areas of > the code. Build changes look good. Thanks for the cleanup! - Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8771
RFR: 8287073: NPE from CgroupV2Subsystem.getInstance()
Following the logic from the comment directly above the changed line, since it doesn't matter which controller we pick, pick any available controller instead of the one called "memory" specifically. This way we are guarded against getting `null` as `anyController`, which is being immediately passed down to `CgroupV2Subsystem.getInstance()` that is unprepared to accept `null` values. It is also worth noting that the previous checks (such as that at line 89) make sure that there exist at least one controller in the map. - Commit messages: - 8287073: NPE from CgroupV2Subsystem.getInstance() Changes: https://git.openjdk.java.net/jdk/pull/8803/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8803=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287073 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8803.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8803/head:pull/8803 PR: https://git.openjdk.java.net/jdk/pull/8803
Integrated: 8287013: StringConcatFactory: remove short and byte mixers/prependers
On Thu, 19 May 2022 10:47:23 GMT, Claes Redestad wrote: > The current short and byte mixers and prependers simply delegate to the int > variants. At the LambdaForm level the values has already been implicitly cast > to int, so removing this indirection and directly adapting to call the > int-based variants is possible. > > This is a cleanup with minimal effect on bootstrap overhead and peak > performance, since all the LF logic only deals with basic types (where byte > and short and other subword primitives has been widened to ints anyhow). This pull request has now been integrated. Changeset: d5d19f52 Author:Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/d5d19f52ceb1430104b12a42c78489f42477a9b0 Stats: 87 lines in 2 files changed: 12 ins; 74 del; 1 mod 8287013: StringConcatFactory: remove short and byte mixers/prependers Reviewed-by: jlaskey - PR: https://git.openjdk.java.net/jdk/pull/8786
Re: RFR: 8287053: Avoid redundant HashMap.containsKey calls in ZoneInfoFile.getZoneInfo0
On Sat, 30 Apr 2022 17:00:03 GMT, Andrey Turbanov wrote: > Instead of pair `HashMap.containsKey`/`HashMap.get` method calls, we can use > single call `HashMap.getOrDefault`. > It's faster and clearer. Marked as reviewed by redestad (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8487
Re: RFR: 8286858: Remove dead code in sun.reflect.misc.MethodUtil
On Wed, 18 May 2022 02:03:34 GMT, Mandy Chung wrote: >Do you know why there are test failures (they look unrelated)? All failed tests seems Loom-integration related. They fail only x86. Seems they are fixed in master under [JDK-8286476 ](https://bugs.openjdk.java.net/browse/JDK-8286476) - PR: https://git.openjdk.java.net/jdk/pull/8715
