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

[David Holmes]

On 13/01/2015 7:00 PM, Dmitry Samersoff wrote:
> David,
>
> On 2015-01-13 08:10, David Holmes wrote:
>>
>> Short version: okay but I'm going to file a bug to have sun.misc.Perf
>> fixed properly.
>
> Thank you and please, file a new bug (you can assign it to me directly).

Filed:

https://bugs.openjdk.java.net/browse/JDK-8069149

Sorry for the delay.

David

> -Dmitry
>
>
>>
>> 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
>>>
>
>