This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration only decrements _sem 1 but dequeues N messages. If logging threads keep preempting async logging thread, it may cause the value of _sem accumulates until overflow!

We decide to ditch counting semaphore. os::PlatformMonitor can be used as low-level combination of Mutex/CondVar. It may work if we simply ignore Semaphore::signal failure due to value overflow, but we have to pollute Semaphore interface. Also it seems that MacOS semaphore which is non-posix doesn't fail in this case.

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change must be properly reviewed

Issue

• JDK-8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX

Reviewers

• David Holmes (@dholmes-ora - Reviewer) ⚠️ Review applies to 0816eb2dd2aef357b33aa4e7eb8038acf1147a8f
• Patricio Chilano Mateo (@pchilano - Committer) ⚠️ Review applies to 0816eb2dd2aef357b33aa4e7eb8038acf1147a8f

Reviewing

This is a follow-up patch for [1]. When we are trying to add the VectorMask query implementation for Arm NEON, we found the jtreg tests for VectorMask.trueCount/firstTrue/lastTrue is not effective. The tests failure cannot be reported as expected. The main reason is that the Vector API methods are not hot enough to be compiled by C2 compiler. Wrap the main test codes inside a loop can make the tests effective.

With the tests taking effect, we can see a JVM crash due to the following assertion:

  vector/src/hotspot/share/opto/vectornode.hpp:879), pid=168241, tid=168257
  # Error: assert(mask->Opcode() == Op_VectorStoreMask) failed

The mask input might be other vector nodes like "LoadVectorNode", since there is an optimization for "VectorStoreMask":

  VectorStoreMask (VectorLoadMask value) ==> value

Changing the code to check whether its element basic type is "T_BOOLEAN" is more reasonable.

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

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change must be properly reviewed

Issue

• JDK-8269568: JVM crashes when running VectorMask query tests

Reviewers

• Paul Sandoz (@PaulSandoz - Reviewer) ⚠️ Review applies to 8e3fcfaef51b2f555fec4bbe7eb53412696f8555
• Jie Fu (@DamonFool - Reviewer) ⚠️ Review applies to 8e3fcfaef51b2f555fec4bbe7eb53412696f8555
• Jatin Bhateja (@jatin-bhateja - Committer)
• Sandhya Viswanathan (@sviswa7 - Reviewer)

Contributors

• Sandhya Viswanathan <[email protected]>

Reviewing

See the bug report for more details.

I believe the JDK-8191998 change introduced a slight regression, where the speculative type join may empty the type. It would then crash on assert in fastdebug builds, or miscompile the null-check to true in release bits. New test captures both failure modes.

This is not a recent regression, but a regression nevertheless, so I would like to have that fix in JDK 17. Please review carefully, or speak up if you want to move it to JDK 18+ and then backport later.

Additional testing:

• [x] New test fails without the patch, passes with it
• [x] Linux x86_64 fastdebug tier1

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change must be properly reviewed

Issue

• JDK-8269285: Crash/miscompile in CallGenerator::for_method_handle_inline after JDK-8191998

Reviewers

• Vladimir Kozlov (@vnkozlov - Reviewer)
• Igor Veresov (@veresov - Reviewer) ⚠️ Review applies to 86b6f2cfa19356ffb505296531749171833d10aa
• Vladimir Ivanov (@iwanowww - Reviewer) ⚠️ Review applies to 02e01bbd93717110f39ef4c57b6ea7deeeb82171

Reviewing

The wording of the @implSpec referred to internal methods in the description. The patch rewords the @implSpec to be more descriptive of the algorithm than the methods used.

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change must be properly reviewed

Issue

• JDK-8266313: (JEP-356) - RandomGenerator spec implementation requirements tightly coupled to JDK internal classes

Reviewers

• Roger Riggs (@RogerRiggs - Reviewer)

Reviewing

The OpenJDK 17 early access build from jdk.java.net fails to load svml library. We need to give full svml library path to dll_load call for the load to succeed.,

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change must be properly reviewed

Issue

• JDK-8269335: Unable to load svml library

Reviewers

• Paul Sandoz (@PaulSandoz - Reviewer)

Reviewing

Hi all,

The following patch fixes deadlocks issues that could occur when checking for suspension while holding VM locks. See the bug description for a concrete case. The solution is to avoid checking for suspend requests when using the TBIVM wrapper. The original patch was actually written by @robehn(now on vacations) and I only made small changes.

Tested in mach5 tiers1-7. I also verified that the new added test SuspendBlocked.java deadlocks with the current bits and passes with this patch.

Thanks, 
Patricio

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change must be properly reviewed

Issue

• JDK-8270085: Suspend during block transition may deadlock if lock held

Reviewers

• Daniel D. Daugherty (@dcubed-ojdk - Reviewer)
• David Holmes (@dholmes-ora - Reviewer)
• Coleen Phillimore (@coleenp - Reviewer) ⚠️ Review applies to 6ad7c4ea32925e515d9bf228276a2794135d4897

Contributors

• Robbin Ehn <[email protected]>
• Patricio Chilano Mateo <[email protected]>

Reviewing

GetPrimitiveArrayCritical() is supposed to only be used with primitive array types, but nothing prevents current implementation from accepting object arrays (please see attached test case in bug).

My purposed fix is not very friendly, it crashes JVM if a none primitive array is passed in, but I am sure what to expect in this scenario.

Specification people, please comment. Thanks!

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change must be properly reviewed

Issue

• JDK-8269697: JNI_GetPrimitiveArrayCritical() should not accept object array

Reviewers

• Kim Barrett (@kimbarrett - Reviewer)

Reviewing

Knights family of X86 Intel CPU (KNL) does not support some of avx512 features (AVX512VL/BW) and have other restrictions. We may not have such kind of machines in our testing environment and may miss bugs as JBS history shows (look recent fixes for KNL). On other hand we have some Windows VM instances which seem emulate KNL configuration and limit avx512 instructions on CPU which supports full set. Recent bug JDK-8269775 shows such example. I suggest to add -XX:+UseKNLSetting x86 diagnostic flag to emulate KNL settings in HotSpot VM to test such configuration.

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change must be properly reviewed

Issue

• JDK-8269825: [TESTBUG] Missing testing for x86 KNL platforms

Reviewers

• Dean Long (@dean-long - Reviewer) ⚠️ Review applies to 9466fb97c61dccd49212119ad9d87c6b32939c7c
• jbhateja - Committer ⚠️ Added manually

Reviewing

This issue relates to Unicode escapes, described in section 3.3 of the JLS. javac interprets Unicode escapes during the reading of ASCII characters from source. Later on, javac interprets escape sequences, described in section 3.7 of the JLS, during the tokenization of character literals, string literals, and text blocks. Escape sequences are only indirectly affected by this bug.

During reading, a normal backslash (that is, the ASCII \ character, not the corresponding Unicode escape \u005c) followed by another normal backslash is treated collectively as a pair of backslash characters. No further interpretation is done. This means that if a normal backslash immediately precedes the sequence \ u A B C D which would "normally" be interpreted as an Unicode escape, then the interpretation of that sequence as a Unicode escape is suppressed.

For example, the sequence \u2022 would be interpreted as the • character, whereas \\u2022 would be interpreted as the seven characters \ \ u 2 0 2 2.

An issue arises when Java developers choose to use a Unicode escape backslash \u005c in their source code, instead of a normal backslash. Prior to JDK 16, if the Unicode escape backslash was followed by a second Unicode escape, then the second Unicode escape was always interpreted. The normal backslash at the beginning of the second Unicode escape (immediately followed by u) was not paired with the preceding Unicode escape backslash. Elsewise, any following normal backslash will be paired with the \u005c.

For example, the sequence \u005c\u2022 would be interpreted as \ and •, whereas \u005c\tXYZ would be interpreted as \ \ t X Y Z.

The bug in JDK 16 ignored \u005c as having any effect on Unicode interpretation. Using the example from compiler-dev discussions, \u005c\\u005d :

• Prior to JDK 16, it was interpreted as \ \ ]
• JDK 16 interpreted it as \ \ \ u 0 0 5 d which would produce a syntax error downstream in the lexer because the escape sequence \u is invalid.

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change must be properly reviewed

Issue

• JDK-8269150: UnicodeReader not translating \u005c\u005d to \]

Reviewers

• Jonathan Gibbons (@jonathan-gibbons - Reviewer) ⚠️ Review applies to 67efad992c03de1b7d3556e6b4df53f0ce2662b1
• Jan Lahoda (@lahodaj - Reviewer) ⚠️ Review applies to 67efad992c03de1b7d3556e6b4df53f0ce2662b1
• Joe Darcy (@jddarcy - Reviewer)

Reviewing

The benchmark loop is roughly:

for (int i = 0; i < limit; i++) { if (!(i < max_jint && i > min_jint)) { uncommon_trap(); } }

which IfNode::fold_compares() tranforms to:

for (int i = 0; i < limit; i++) { if (!(i - min_jint - 1 <u -2)) { uncommon_trap(); } }

Range elimination then adjusts loop limits so the unsigned comparison can be removed. The new limit is:

min(limit, max(-2 + min_jint + 1, min_jint)) = min(limit, min_jint) = min_jint

and the main loop is never executed.

The logic that protects against overflows during range check elimination is what causes the main loop to never be executed. As a fix, I propose delaying IfNode::fold_compares() if the resulting test compares with a potential negative number which could then cause RC overflow code to trigger. I think that would preserve the most interesting cases for IfNode::fold_compares() when it comes to range check elimination:

i >= 0 && i < array.length

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change must be properly reviewed

Issue

• JDK-8269230: C2: main loop in micro benchmark never executed

Reviewers

• Vladimir Kozlov (@vnkozlov - Reviewer)
• Igor Veresov (@veresov - Reviewer)

Contributors

• Maurizio Cimadamore <[email protected]>

Reviewing

This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.

Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.

The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.

FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.

Testing: local running of jdk_foreign on Windows and Linux (WSL). Tier 1-3

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change must be properly reviewed

Issue

• JDK-8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC

Reviewers

• Vladimir Ivanov (@iwanowww - Reviewer) ⚠️ Review applies to c90416f52042813ef2c1a1c35d308fc631f77b2f
• David Holmes (@dholmes-ora - Reviewer)

Reviewing