Request for review - 7197557

[Srinivas Ramakrishna]

Hi Jon --

While I am not familiar with all of the details of the new metaspaces
implementation,
from my high level knowledge of how it works, the shape of the code changes
here to address the bug looks good to me.
(Although it would have been nice if one could have read the stack retrace
of the JVM when the deadlock occurred, i
think such information was not in the public part of the bug report visible
on bugs.sun.com.)

A somewhat orthogonal question:
Could you tell me if there is any a-priori limit that the JVM sets on the
c-heap space used for the metadata?
If yes, can that limit be changed from the command-line? If there is no
such a-priori limit, could you shed any light
on a comparison of the memory footprint between the pre-NPG world and the
new post-NPG world for
some benchmarks that exercise class load/unload etc.?

thanks!
-- ramki

On Mon, Sep 17, 2012 at 3:18 PM, Jon Masamitsu <jon.masamitsu at oracle.com>wrote:

> I have one review (Thanks JohnCu).  The change is straight forward
> but it is code that has problems in the past (GC_locker code) so any
> other reviews would be welcome.
>
> Jon
>
>
> On 09/16/12 20:09, Jon Masamitsu wrote:
>
>> NPG: nsk/sysdict/vm/stress/chain/**chain004 hangs intermittently
>>
>> The code that was doing a GC to find dead class loaders so that metadata
>> could be freed does not correctly account for GC_locker activity (i.e.,
>> use
>> of JNI critical sections which stall GC).  Added code to recognize if
>> a GC_locker is active and expand the Metaspace and allocate out of the
>> expanded area.  If the expansion cannot provide metadata, wait for
>> the GC_locker to inactivate so that a GC can be done.
>>
>> http://cr.openjdk.java.net/~**jmasa/7197557/webrev.00/<http://cr.openjdk.java.net/%7Ejmasa/7197557/webrev.00/>
>>
>> Note that there are three places in the different GC's that need to
>> account for GC_locker activity.  I am investigating whether this
>> code can be unified.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120917/ebf1eeb2/attachment.htm>