Details
-
Bug
-
Resolution: Fixed
-
P2
-
21, 22, 23
-
b22
Backports
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8334447 | 21.0.5 | Aleksey Shipilev | P2 | Resolved | Fixed | b01 |
Description
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.
Attachments
Issue Links
- backported by
-
JDK-8334447 Stack chunk thawing races with concurrent GC stack iteration
-
- Resolved
-