RFR (S) 6909265: assert(_OnDeck != Self->_MutexEvent, "invariant") with -XX:+PrintMallocFree
Zhengyu Gu
zgu at redhat.com
Fri Feb 2 13:48:19 UTC 2018
Looks good to me.
Thanks,
-Zhengyu
On 02/01/2018 11:24 PM, coleen.phillimore at oracle.com wrote:
>
> Okay, here is PrintMallocFree and PrintMalloc removed. tier1,2 testing
> is in progress.
>
> 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.
> 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.
>
> 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