Summary

Obsolete the -XX:ZMarkStackSpaceLimit JVM option as it is no longer needed.

Problem

When ZGC performs marking, a lock-free data structure is used to keep track of objects that still need to be traced in the object traversal. This lock-free data structure uses versioned pointer as a technique to avoid ABA problems, prevalent when writing lock-free data structures. This required partitioning pointers in the structure to embed both a version and a location.

Due to the reduced addressability of locations with only a portion of the pointer bits, a special memory space was created to manage the data structure such that offsets could be encoded, instead of addresses.

Since the memory area needs to be contiguous, the JVM needs to know what the expected maximum size of this space will ever be, within some limiting bounds. That is what -XX:ZMarkStackSpaceLimit controls.

While this strategy has worked well in practice, the design does limit the scalability of ZGC, due to limits in how much contiguous memory can be encoded with a subset of the pointer bits. Not to mention that users have no idea what number to put in to this JVM option.

Solution

The -XX:ZMarkStackSpaceLimit JVM option is needed due to using a contiguous allocator to solve an ABA problem in a lock-free data structure. By selecting another solution for the ABA problem, the need for the special contiguous memory allocator and hence the JVM option can be removed.

A new solution is proposed by JDK-8347335 for that original ABA problem in the lock-free data structure, which renders the entire machinery behind the -XX:ZMarkStackSpaceLimit JVM option redundant. The proposed technique is to use hazard pointers instead.

The use of hazard pointers is a well established safe memory reclamation (SMR) technique for writing lock-free data structures. The main idea is to publish what pointer has been read with a hazard pointer, so that concurrent threads know not to free memory that is being concurrently used. Freeing of such racingly accessed memory is deferred until it is safe, hence solving the ABA problem. This also allows using plain malloc/free instead of a custom contiguous memory allocator for these structures.

There are other possible solutions to the ABA problem in the implementation space, such as using epochs, RCU, global counters, etc. While the current choice is hazard pointers, the CSR request is about moving from the ABA mitigation technique that requires a JVM flag to one that does not, whichever that may end up being.

Specification

All machinery behind the -XX:ZMarkStackSpaceLimit JVM option is being removed in the proposed change. Therefore, this JVM option will no longer do anything in the JVM. The proposed change is hence to move this flag straight to obsolete, skipping the intermediate deprecation step. It would be confusing for users if the flag says it is merely deprecated, while having no effect.