When allocating large object arrays, ZObjArrayAllocator instantiates a non-cleared array of longs and later installs the correct klass pointer once the array has been cleared. While this might work it's also error prone. For example, there are at least two asserts() that will re-loaded the klass pointer and fail. It's also easy for someone in the future to make the innocent mistake of re-loading the klass pointer in some sensitive path, which would lead to new problems. We can avoid all these problems by not substituting with the klass pointer, and instead have another mechanism to tell GC marker threads to not follow the elements in not-yet-cleared arrays.