-
Bug
-
Resolution: Fixed
-
P2
-
21, 22, 23
-
b22
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8343527 | 21.0.7-oracle | Erik Österlund | P2 | Closed | Fixed | b01 |
JDK-8334447 | 21.0.5 | Aleksey Shipilev | P2 | Resolved | Fixed | b01 |
In ThawBase::finalize_thaw we do this:
if (!_stream.is_done()) {
assert(_stream.sp() >= chunk->sp_address(), "");
chunk->set_sp(chunk->to_offset(_stream.sp()));
chunk->set_pc(_stream.pc());
} else {
chunk->set_argsize(0);
chunk->set_sp(chunk->stack_size());
chunk->set_pc(nullptr);
}
The sp and argsize are both read when setting up a StackChunkFrameStream from concurrent GC threads to scan the stack. The lack of atomicity implies the GC thread might observe old values of argsize with new values of sp, or vice versa. The consequences are unknown, but this is clearly not right.
if (!_stream.is_done()) {
assert(_stream.sp() >= chunk->sp_address(), "");
chunk->set_sp(chunk->to_offset(_stream.sp()));
chunk->set_pc(_stream.pc());
} else {
chunk->set_argsize(0);
chunk->set_sp(chunk->stack_size());
chunk->set_pc(nullptr);
}
The sp and argsize are both read when setting up a StackChunkFrameStream from concurrent GC threads to scan the stack. The lack of atomicity implies the GC thread might observe old values of argsize with new values of sp, or vice versa. The consequences are unknown, but this is clearly not right.
- backported by
-
JDK-8334447 Stack chunk thawing races with concurrent GC stack iteration
-
- Resolved
-
-
JDK-8343527 Stack chunk thawing races with concurrent GC stack iteration
-
- Closed
-
- links to
-
Commit openjdk/jdk21u-dev/a5eb7f25
-
Commit openjdk/jdk/8bcd2e61
-
Review openjdk/jdk21u-dev/680
-
Review openjdk/jdk/18643
(1 links to)