Details
-
Bug
-
Resolution: Fixed
-
P2
-
20
-
b02
Backports
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8298734 | 20 | Stefan Karlsson | P2 | Resolved | Fixed | b29 |
Description
A simple fix is to change the RegisterMap to perform oops processing. However, monitors_on_stack is only used in an assert, so this means that we'll get a difference in behavior between release builds and debug builds. This has the potential to hide bugs in debug builds. It has been suggested to me that it might be better to simply remove the assert:
```
assert(monitors_on_stack(current) == ((current->held_monitor_count() - current->jni_monitor_count()) > 0),
"Held monitor count and locks on stack invariant: " INT64_FORMAT " JNI: " INT64_FORMAT, (int64_t)current->held_monitor_count(), (int64_t)current->jni_monitor_count());
```
Attachments
Issue Links
- backported by
-
JDK-8298734 monitors_on_stack extracts unprocessed oops
-
- Resolved
-
- duplicates
-
JDK-8298058 jdk/internal/vm/Continuation/Fuzz.java#default fails "assert(oopDesc::is_oop_or_null(val)) failed: bad oop found at 0xNNNN in_cont: 0 compressed: 0"
-
- Resolved
-
- relates to
-
JDK-8298058 jdk/internal/vm/Continuation/Fuzz.java#default fails "assert(oopDesc::is_oop_or_null(val)) failed: bad oop found at 0xNNNN in_cont: 0 compressed: 0"
-
- Resolved
-
- links to
-
Commit openjdk/jdk20/323e574a
-
Commit openjdk/jdk/b754aa5e
-
Review openjdk/jdk20/32
-
Review openjdk/jdk/11582