RFR (S) 8049304: race between VM_Exit and _sync_FutileWakeups->inc()

[Daniel D. Daugherty]

On 8/27/15 11:47 AM, Kim Barrett wrote:
> On Aug 27, 2015, at 11:51 AM, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>> 3) We don't like the "fast but safe" solution of leaking the PerfData
>>    memory. We try to make ourselves feel better about this by saying
>>    there are plenty of other leaks in the VM... slippery slope?
> "Leak" is perhaps misleading and overly perjorative.  A better
> description of what I've suggested is "pass the buck for memory
> cleanup to the OS".  When we're on our way to process exit, we know
> the OS will deal with our memory resources.  We already (and would
> still) clean up relevant non-memory resources (like shared memory
> files for the PerfData) - I'm not suggesting any change there.
> perfMemory_exit already has that separation of memory vs non-memory
> resource cleanup.
>
> I submit that in many situations when we're on our way to process
> exit, the sleep being introduced by this change may actually have a
> significant negative impact.  If we're on our way to dumping a core
> file for debugging an error, putting a sleep along the way just allows
> other threads more time to run further from the state where the error
> occurred.  I wish we were running less code rather than more in that
> situation.
>
> If we're not on our way to process exit, and instead want to achieve a
> state where we can restart the VM or unload the VM code, we clearly
> need to make sure that other cleanup has been done, such as bringing
> all threads to quiescence and eventually tearing them down.  But if we
> don't have other threads running then the problem of some thread
> trying to touch the PerfData after we've destroyed it simply doesn't
> happen.
>
> And indeed, there is at least the beginnings of code to do that sort
> of thing; see jni_DestroyJavaVM.  And what I've proposed is that we do
> the PerfData memory cleanup exactly and only when that's the goal
> state, since in that case it is safe and necessary to do the PerfData
> memory cleanup.
>

Kim, you keep changing your position. You've gone from acknowledging
that this would be a "leak" that is likely detectible by a leak detection
tool and saying that we'd have to figure out a way to shut it up to
what you have written above.

I have no idea what to think anymore.

Dan