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

David Holmes david.holmes at oracle.com
Thu Jan 15 07:36:16 UTC 2015


On 15/01/2015 4:20 AM, serguei.spitsyn at oracle.com wrote:
> It looks Ok (a copyright comment can be updated as well).
> However, there is still a major issue with this API per David H.
> Did you file new bug for this?

I will file one but haven't got to it yet.

David

> Thanks,
> Serguei
>
> On 1/14/15 5:31 AM, Dmitry Samersoff wrote:
>> Any other reviewers?
>>
>> -Dmitry
>>
>> On 2015-01-13 08:10, David Holmes wrote:
>>> 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
>>>>
>>
>


More information about the serviceability-dev mailing list