RFR (S) 6909265: assert(_OnDeck != Self->_MutexEvent, "invariant") with -XX:+PrintMallocFree

[Zhengyu Gu]

On 02/01/2018 08:37 AM, coleen.phillimore at oracle.com wrote:
> 
> 
> On 1/31/18 10:36 PM, David Holmes wrote:
>> Hi Coleen,
>>
>> On 1/02/2018 1:01 PM, coleen.phillimore at oracle.com wrote:
>>> Summary: Convert to logging without thread locking
>>>
>>> There are two options (-XX:+PrintMallocFree and -XX:+PrintMalloc) to 
>>> print the calls and memory returned in malloc and free calls in the 
>>> vm. I converted the first one to Unified Logging which doesn't crash 
>>> getting the tty lock in the Thread destructor and removed the 
>>> latter.  I don't see the usefulness of this logging honestly, so if 
>>> the opinion is to remove this logging, I'd be happy to do so.  NMT 
>>> seems much more useful.
>>
>> I'm not sure about this one. Arguably some interesting malloc/frees 
>> occur before log configuration.
> 
> They also occurred before tty initialization and afterward too.
>>
>> That aside, given you always seem to do:
>>
>> log_is_enabled(Trace, malloc, free)
>>
>> which requires
>>
>> -Xlog:malloc+free=trace
>>
>> would it make more sense to define a single tag eg mallocfree or 
>> nativemem or ???
>>
> 
> It's an opinion question.  I picked this to match the option and assume 
> one would want to see both mallocs and frees.  I like the composition of 
> small tags that have meaning.  Then again, I could change it if you have 
> an opinion about this.
>> Or, as you say, just drop this altogether. Is it useful for when 
>> debugging NMT?
>>
> 
> I doubt it's useful for debugging NMT.  It might have been useful once 
> but I don't know why.  What's your opinion?

No, I never used this to debug NMT. It just generates too much data to 
be useful, I vote to remove it all together.

Thanks,

-Zhengyu


> 
> thanks,
> Coleen
> 
>> Thanks,
>> David
>>
>>> Tested with NMT and tier1 tests, and wrote test.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/6909265.01/webrev
>>> bug link https://bugs.openjdk.java.net/browse/JDK-6909265
>>>
>>> Thanks,
>>> Coleen
>