On 8/26/15 4:02 PM, Kim Barrett wrote:
On Aug 26, 2015, at 5:15 PM, Daniel D. Daugherty <daniel.daughe...@oracle.com>
wrote:
On 8/26/15 3:00 PM, Kim Barrett wrote:
...There are lots of places that use
PerfData. Don't they all need to be updated? I was hoping the answer
would be no, but after reviewing the bug thread and code, I think that
hope was in vain.
I have only seen sightings of this crash in the monitor subsystem.
Do you know of sightings with other PerfData usage?
I don't, but I haven't been looking. Also, the monitor subsystem gets
hit a lot more heavily than any other PerfData I've looked at, and
sightings in the monitor subsystem are pretty rare.
I'm pretty confident we have the monitor case well under control
and I'd like to move forward with this fix and see what else
shakes out (if anything). The other idea that you had about
the SIGSEGV signal handler would be the next place I'd look at
if we continue to see issues with this type of race.
I'm pretty sure I could demonstrate one by patching in some sleeps and
flag spin-waits in order to achieve the necessary state.
I have no doubt since you came up with the debugging code to make
the monitor subsystem race easily reproducible. However, I can't
find any other PerfData sighting so I'm wondering if non-monitor
subsystem races are more rare.
Unfortunately, this puts me back in the position of thinking we should
just leak the memory when we're on our way to process exit. ...
Sorry, I'm not in favor of leaking memory.
We're on our way to process exit, where all such sins are forgiven.
I thought the general idea was that we're trying to reduce our memory
leaks so that we can eventually reach the stretch goal of being able
to restart the VM in the same process.
I don't want to add another memory leak to the system without
a very compelling reason to do so. So far I'm not convinced
especially without any existing bugs pointing to PerfData races
with non-monitor subsystem usage.
We already leak like a bucket without a bottom (sieves being too fine
to accurately model the situation) when performing an abnormal exit.
But we're not talking about an abnormal exit here.
Actually, a possible upside to this leak would be that the PerfData will
be present in a core file. That could maybe even be useful.
I'm pretty sure if you have a PerfData server attached, then we leave
the PerfData objects laying around so they can be harvested. However,
I'm not really a user of the PerfData stuff so I don't know that for
certain.
Dan
