8151460: Metaspace counters can have inconsistent values
per.liden at oracle.com
Tue Mar 29 09:40:43 UTC 2016
On 2016-03-23 10:04, Stefan Johansson wrote:
> Hi Jon,
> Thanks for taking a look at this.
> On 2016-03-22 19:15, Jon Masamitsu wrote:
>> 80 // Adding a second GC due to metadata allocations caused caused by
>> 81 // initial size from the pool. This is needed when running with
>> 82 System.gc();
>> 83 assertEQ(getUsed(perfNS), pool.getUsage().getUsed(), "Used out of
>> 84 assertEQ(getCapacity(perfNS), pool.getUsage().getCommitted(),
>> "Committed out of sync");
>> The comment (which has an extra "caused" BTW) says that the call to
>> get the
>> initial size necessitates the System.gc(). Is there reason to believe
>> that the
>> call to get the used will sometime down the road require another
> Fixed the extra "caused". This is a fair question and I believe it
> could, but hopefully it will not cause metaspace to grow and make the
> capacity numbers get out of sync. An other problem, with no easy
> solution, would be if within the call to getUsed() something is loaded
> and added to the used number before returning it. But we haven't seen
> this and until we do I think the single System.gc() call should be
>> 87 // Need to ensure that used is up to date and the all unloadable
>> 88 // classes are unloaded before doing this check.
>> I'd suggest "unreachable" or "dead" in place of "unloadable"
> I agree, changed to "unreachable" and "the" to "that".
> New webrevs:
> Full: http://cr.openjdk.java.net/~sjohanss/8151460/hotspot.01/
> Inc: http://cr.openjdk.java.net/~sjohanss/8151460/hotspot.00-01/
Still looks good.
>> // Need to ensure that used is up to date and the all unreachable
>> // classes are unloaded before doing this check.
>> Using "unloadable" feels a little like using an adjective to
>> describe itself. Kind of like "What classes can be unloaded?
>> The unloadable ones." :-)
>> On 3/22/2016 6:35 AM, Stefan Johansson wrote:
>>> Please review this test-fix to avoid the problems described in:
>>> Two of the metaspace perf-counter tests fails intermittently when run
>>> with -Xcomp. One reason this has been more frequent lately is a
>>> change to one of the tests that removed a System.gc() call. This call
>>> seems to be more important when running with -Xcomp. Having the
>>> System.gc() call is needed because the PerfCounters are only updated
>>> after a GC. And if any class loading/unloading happens after the call
>>> we can't do the assertions we are doing.
>>> When doing this fix I also realized that one of the tests hadn't
>>> changed UseCompressedKlassPointers to UseCompressedClassPointers,
>>> both the command-line and the test-code used the old version so I
>>> updated this as well.
>>> The updated tests pass in RBT.
More information about the hotspot-gc-dev