Quick question about Metaspace verifications (8185034)

[coleen.phillimore at oracle.com]

Hi Thomas,

The bug was confidential because it was for our then-closed arm port and 
for a closed test.   The test was timing out in nightly testing.  It 
still has paths in the description so I don't think I can open the 
bug.   And there isn't very much usable data except:

This looks like an issue that I've come across while developing tests as 
well.
The problem is that this kind of workload causes the vm to spend a lot 
of time verifying all the metaspace chunks:
% Run time using "perf record" on Linux.
  49.48% java libjvm.so [.] ChunkManager::locked_verify_free_chunks_total()
  47.69% java libjvm.so [.] ChunkManager::locked_verify_free_chunks_count()
I'll try to figure out the call path that causes 
ChunkManager::locked_verify to be called.

I think fastdebug should be careful about slow metaspace verification, 
because we test with fastdebug.

On 3/7/18 1:28 AM, Thomas Stüfe wrote:
>   Hi all,
>
> I am currently working on 8185034 to clean up the metaspace coding a bit,
> partially to work off the complexity debt incurred by 8198423.
>
> some quick questions, maybe someone knows:
>
> - We have the metaspace_slow_verify which guards a number of expensive
> verifications (I feel a bit arbitrarily). When looking at the history, I
> see a change:
>
> changeset:   14474:4154f1817a75 14382:5e86124b835d
> user:        mgerdin
> date:        Fri Nov 09 00:38:31 2012 +0100
> summary:     7200229: NPG: possible performance issue exposed by
> closed/runtime/6559877/Test6559877.java
> Summary: Reduce the amount of calls to ChunkManager verification code
> Reviewed-by: jmasa, coleenp
>
> 7200229 is a closed bug report, I cannot see it. Any details on this? More
> important, should I keep guarding expensive verifications not only with
> ASSERT but also with this always-off switch? And if yes, what counts as
> expensive? To me, this defies a bit the point of having a debug build.
>
> - Speaking of verifications, I see often verification methods (e.g.
> ChunkManager::verify()) which are not guarded by ASSERT - is there a point
> to have those functions in release builds? All they do is checking and
> asserting, which become no-ops.
There is some GC verification that is done with 
-XX:+Verify{Before,During,After}GC that is exposed in the product and is 
frequently used for diagnosing problems.  I don't know if metaspace 
verification is part of this without looking.   If it is, we should keep 
it available in PRODUCT build.  If not, yes, please make it #ifndef PRODUCT.

Coleen
>
> Thank you,
>
> Thomas