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

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Thu Jan 15 07:40:14 UTC 2015


On 1/14/15 11:36 PM, David Holmes wrote:
> 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.

Ok, thanks.
Just wanted to make sure it was not forgotten.

Thanks,
Serguei

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