RFR(S): JDK-7076820 assert(addr != 0) failed: address sanity check in PerfMemory::detach with -XX:-UsePerfData

[David Holmes]

Hi Dmitry,

Short version: okay but I'm going to file a bug to have sun.misc.Perf 
fixed properly.

Long version ... read below :)

Thanks,
David

On 12/01/2015 11:49 PM, Dmitry Samersoff wrote:
> Hi Everybody,
>
> Please review the fix.
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-7076820/webrev.01/
>
> The fix explicitly checks for UsePerfData and if it's false make
> Perf:detach a NOP.

That sidesteps the assertion failure but there is a bigger semantic 
issue here I think - which is why the bug has remained open for so long. 
UsePerfData can disable a part of the backend of the "perf" 
functionality used via sun.misc.Perf, but sun.misc.Perf is completely 
oblivious to that. It isn't even really clear what UsePerfData pertains 
to. It impacts PerfMemory turning a number of methods into no-ops - but 
it doesn't turn PerfMemory::attach nor PerfMemory::detach into no-ops. 
What is a no-op is the initialization of PerfMemory (perfMemory_init) 
during VM startup, and also the teardown (perfMemory_exit) during VM 
shutdown (via at_exit handler). So the VM responds to the -UsePerfData 
flag (in part) by not initializing the PerfMemory subsystem, but the 
PerfMemory public apis are still enabled and invoked from the JDK code. 
That doesn't make sense to me - we should fail to attach and in doing so 
not put in place the Cleaner code that will attempt the detach. But 
sun.misc.Perf doesn't understand that anything can fail. :(

Your workaround avoids calling PerfMemory::detach from the Perf_detach 
code by checking UsePerfData, but arguably the check should be inside 
PerfMemory::detach operation (which unfortunately is OS specific).

>
> -Dmitry
>