request for review (XS), 6458402: 3 jvmti tests fail with CMS and +ExplicitGCInvokesConcurrent
David.Holmes at oracle.com
Sat Dec 4 05:46:30 UTC 2010
Igor Veresov said the following on 12/04/10 15:14:
> On 12/3/10 7:08 PM, David Holmes wrote:
>> Keith McGuigan said the following on 12/03/10 23:19:
>>> On Dec 3, 2010, at 3:30 AM, Igor Veresov wrote:
>>>> You're calling notify_gc_end() while holding the FullGCCount_lock. Is
>>>> that ok? Would it be more prudent to divert control to the user
>>>> without holding it?
>>> The notify_gc_end() call does not divert control to the user -- it
>>> contains only the code that will trigger a dtrace event (which is a
>>> no-op as far as the VM is concerned; the OS may notice it though).
>>> That said, I think it would be a good idea to release the lock before
>>> calling it and I'll change the code to do that. That way if someone
>>> adds code to the notify_gc_end() method in the future there won't be
>>> any surprises.
>> But if you release the lock before firing the probe the two events can
>> become distant in time and someone else can see a second "start" probe
>> fire before they've seen the previous "end" probe fire. That makes it
>> harder to use the probes to analyse what is happening.
> But it's all in a VM thread, so it's going to be serialized.
Ah! That's okay then.
> Anyway, like Ramki noted, it doesn't report what it is supposed to...
More information about the hotspot-gc-dev