RFR (S) 6909265: assert(_OnDeck != Self->_MutexEvent, "invariant") with -XX:+PrintMallocFree
David Holmes
david.holmes at oracle.com
Fri Feb 2 05:08:51 UTC 2018
Hi Coleen,
On 2/02/2018 2:24 PM, coleen.phillimore at oracle.com wrote:
>
> Okay, here is PrintMallocFree and PrintMalloc removed. tier1,2 testing
> is in progress.
So the difference now is that even more of the logging has been removed,
leaving only a couple of special cases?
>
> I changed two things in addition to removing this tracing.
>
> 1. Arena::operator new(nothrow) calls AllocateHeap to be consistent with
> it's throw alternative. I suspect it called os::malloc() from before
> AllocateHeap had the flag AllocFailStrategy::RETURN_NULL.
Okay. Took me a little while to follow it through. :)
> 2. I have log tags malloc/free as tags to log_warning when we get a
> memory stomping error and tracing MallocCatchPtr which is better than
> tty->print alternative in our UL world.
It seems odd to me to have log tags "malloc" and "free" but not have
them actually log mallocs or frees! Shouldn't these just be
unconditional warnings? Afterall if I get a memory stomp I'd like to
know about it now - not sure what would prompt me to enable special
logging just to see that. ??
Thanks,
David
> open webrev at http://cr.openjdk.java.net/~coleenp/6909265.02/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-6909265
> Thanks,
> Coleen
>
>
> On 2/1/18 6:04 PM, David Holmes wrote:
>> Hi Coleen,
>>
>> I have no experience using PrintMallocFree. Unless someone wants to
>> champion its existance then I'd suggest just getting rid of it. We
>> have/had a few flags that were presumably useful while
>> debugging/devoloping something and which are left in "just in case"
>> but then never get used.
>>
>> Thanks,
>> David
>>
>> On 1/02/2018 11:37 PM, 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?
>>>
>>> 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
>>>
>
More information about the hotspot-runtime-dev
mailing list