RFR (M) 8005012: Add WB APIs to better support NMT testing

Christian Törnqvist christian.tornqvist at oracle.com
Thu Jan 10 02:52:19 PST 2013


Hi David,

> This method blocks while holding the query_lock - is that intended?

Yes, this will prevent NMT from shutting down and freeing the data structures we're using.

> Aside: the MemSnapshot::wait method is troubling me. What are you waiting upon ie what state condition? The notification is done in the 
> destructor but how can the destructor be called if someone is calling
> wait() upon the object's lock ??? It means you are destroying an object that is still in use, including the lock that is being waited upon!!!

This was obviously incorrect, thanks for catching this. I've removed it and done some small other cleanups, a new webrev can be found at http://cr.openjdk.java.net/~ehelin/8005012/webrev.01/

Thanks,
Christian

-----Original Message-----
From: David Holmes 
Sent: den 19 december 2012 00:21
To: Christian Törnqvist
Cc: hotspot-runtime-dev at openjdk.java.net; Zhengyu Gu
Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT testing

On 19/12/2012 12:10 AM, Christian Törnqvist wrote:
> Hi everyone,
>
> This change is about adding three new WB APIs to better support NMT 
> testing. The changes are:
>
> ·A Test memory type, used by WB API's NMTAllocTest and 
> NMTFreeTestMemory
>
> ·Added a WaitForDataMerge WB API to be able to block until the current 
> generation has been merged and is visible, most of this work was done 
> by Zhengyu Gu.

This method blocks while holding the query_lock - is that intended?

Aside: the MemSnapshot::wait method is troubling me. What are you waiting upon ie what state condition? The notification is done in the destructor but how can the destructor be called if someone is calling
wait() upon the object's lock ??? It means you are destroying an object that is still in use, including the lock that is being waited upon!!!

David
-----

>
> Webrev can be found at:
>
> http://cr.openjdk.java.net/~ehelin/8005012/webrev.00/
>
> Thanks,
>
> Christian
>


More information about the hotspot-runtime-dev mailing list