ZGC uses a mark stack space of limited range to be able to create versioned pointers to solve the ABA problem when pushing and popping mark stacks. The limited range is used so that we only have to use a limited set of bits for the address identification and the rest of the bits are then used for a version number.
The limit is by default very high (8 * G) but we have received a report of a use-case where the limit was hit. The user expresses that it is hard to know what the limit should be bumped to.
The reason for us filling up the mark stack space could be caused by a problem with an issue with String Deduplication but even if it is it would be nice to get rid of this limit.
The current idea on the drawing table is to solve the ABA problem with hazard pointers instead of having versioned pointers. That allows us to use full-sized pointers to the marking stacks and we don't have to limit the memory of the marking stack to a smaller memory range.
The limit is by default very high (8 * G) but we have received a report of a use-case where the limit was hit. The user expresses that it is hard to know what the limit should be bumped to.
The reason for us filling up the mark stack space could be caused by a problem with an issue with String Deduplication but even if it is it would be nice to get rid of this limit.
The current idea on the drawing table is to solve the ABA problem with hazard pointers instead of having versioned pointers. That allows us to use full-sized pointers to the marking stacks and we don't have to limit the memory of the marking stack to a smaller memory range.
- csr for
-
JDK-8349204 ZGC: Use limitless mark stack memory
-
- Closed
-
- relates to
-
JDK-8352027 JDK-8347335 introduced a ZGC regression for Micros-SystemGC
-
- Open
-
- links to
-
Commit(master) openjdk/jdk/65f79c14
-
Review(master) openjdk/jdk/23571