RFR: JDK-8212186: JVMTI lacks a few GC barriers/hooks

[Per Liden]

On 10/18/2018 09:46 AM, Aleksey Shipilev wrote:
> On 10/18/2018 09:38 AM, Per Liden wrote:
>> On 10/18/2018 09:24 AM, Aleksey Shipilev wrote:
>>> On 10/18/2018 09:13 AM, Per Liden wrote:
>>>>> Tracing. Scanning would require to carry around complete marking info
>>>>> (to be able to avoid holes of dead objects with recycled Klass*), which
>>>>> we don't.
>>>>
>>>> So that makes me wonder why you needed JDK-8211955 (GC abstraction for LAB reserve) and why you
>>>> insert filler objects at all? Am I missing something?
>>>
>>> I think Roman meant that Shenandoah does tracing for _external_ heap walk, e.g. for heap dumps. The
>>> internal heap walks, e.g. for evac/update-refs, are still pretty much scanning the self-parsable
>>> heap, which requires us doing fillers right.
>>
>> Don't you have the problem of potentially stepping on an object with a stale klass pointer in that
>> case too?
> 
> No, we do not. Objects below TAMS would be walked using marking bitmap data, which would bypass dead
> objects, and object above TAMS would be walked as self-parsable heap, but those objects (and their
> klasses) are guaranteed to be alive.

Ah, sounds good.

> 
> Shenandoah does tracing for external heap walks, on the off chance external walk is requested
> mid-marking. There are other ways to do this, e.g. wait for marking to complete before doing
> external walk, which gets us back to heap parsability :)

We initially did that in ZGC, but found that forcing the GC to be in a 
specific state before you can do certain operations just wasn't very 
attractive (more complex code, potentially stalled operations, strange 
error paths, etc). So, I think you made the right choice ;)

cheers,
Per