RFR: 8305895: Implementation: JEP 450: Compact Object Headers (Experimental) [v7]

[Aleksey Shipilev]

On Thu, 11 May 2023 10:49:49 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The load in mark_acquire can float up above the copying. So I don't think that will work either.
>
> Hmm, right. I guess this is not only about atomicity. It's also possible that we see that it's not marked/forwarded, then ignore the transform_stack_chunk() call, which would be wrong.
> The problem is that transform_stack_chunk() wants to access the Klass* to check is_stackChunk(). So maybe we need to extract the Klass* from the test_mark and pass it to (a new variant of) ContinuationSupport::transform_stack_chunk() which only uses that class? That should work, right?

I don't quite see the problem. So the `mark_acquire` floats before the copy, what does it break? 

If we read the "forwarded" mark early, we know it would fail installation, because there is already a forwarding. No transformation is needed then.

If we read the "not forwarded" mark, then there a chance we are going to install the copy as forwardee, so we need to transform. But for the case of compact object headers, we need to guarantee for `transform_stack_chunk` is seeing a consistent `Klass*` from the mark, which specially atomic read of mark provides. We store that mark in the copy too, thus overwriting any atomicity violations the copy routine might have introduced, and giving `transform_chunk_call` a green light to proceed with transformation. (Aside: This thing could even be just `mark`, because even the relaxed atomic load would suffice.)

IOW, if the copy routine is not atomic, and it is a problem for mark, then we can overwrite mark in the copy with the value we got with special atomic load.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13844#discussion_r1191018539