RFR(S) 8189688: NMT: Report per-class load metadata information
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Tue Nov 7 01:00:54 UTC 2017
Zhengyu, I've reviewed the code and this looks fine. There is so
much overlapping functionality for printing sizes of metaspaces in this
file. It would be nice to have just one way of printing the metaspaces,
and have the ::dump functions go away, and have the "print" functions
consistently print sizes and statistics. There is also CLD walking and
metaspace printing in ClassLoaderDataGraph::dump which is used for
debugging. I'd be happy if that was only printing statistics about the
CLD and not details of the metaspace that they point to. This function
was only for debugging though.
I think your version may be the most currently useful so I'm fine with
it. I hope we can have a cleanup of the rest of the printing though.
I will sponsor this.
Thanks,
Coleen
On 11/6/17 3:37 PM, Zhengyu Gu wrote:
> Ping ...
>
> I need second reviewer and sponsor.
>
> Latest webrev: http://cr.openjdk.java.net/~zgu/8189688/webrev.04/
>
> Thanks,
>
> -Zhengyu
>
> On 10/30/2017 11:29 AM, Zhengyu Gu wrote:
>>>
>>>
>>> Yes, this is not trivial. I hacked it in (because I wanted to see
>>> your output at the end of my tests) and had to disable the assert. I
>>> never ran into problems. Should java threads not all be stopped at
>>> that point?
>>>
>> Yes, it looks like that all Java threads are stopped at that point.
>> However, I am not so sure about workers. Could there be active
>> workers while JVM exiting?
>>
>>
>>> But this also can be done in a follow up issue.
>>
>> Yes, let's address it separately.
>> https://bugs.openjdk.java.net/browse/JDK-8190357
>>
>>
>> Updated webrev based on your early comments:
>>
>> Webrev: http://cr.openjdk.java.net/~zgu/8189688/webrev.04/
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>>
>>> Thanks, Thomas
>>>
>>>
>>> Thanks! Thomas
>>>
>>> On Wed, Oct 25, 2017 at 7:00 AM, Thomas Stüfe
>>> <thomas.stuefe at gmail.com <mailto:thomas.stuefe at gmail.com>
>>> <mailto:thomas.stuefe at gmail.com
>>> <mailto:thomas.stuefe at gmail.com>>> wrote:
>>>
>>> Hi Zhengyu,
>>>
>>> On Tue, Oct 24, 2017 at 8:04 PM, Zhengyu Gu
>>> <zgu at redhat.com
>>> <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>> wrote:
>>>
>>> Hi Thomas,
>>>
>>> On 10/24/2017 12:08 PM, Thomas Stüfe wrote:
>>>
>>> Hi Zhengyu,
>>>
>>> - VM_PrintMetadata still has the _unit member, but
>>> I see it
>>> nowhere used.
>>>
>>> - I would have split the summary between class and
>>> non-class
>>> area, that may have been more useful. But this
>>> is a
>>> matter
>>> of taste, I leave it up to you.
>>>
>>> Agree, should go little further.
>>>
>>> Summary:
>>> Total class loaders= 754 capacity= 67528.00KB
>>> used= 61216.88KB free= 9453.11KB waste= 38.73KB
>>> Metadata capacity= 58780.00KB
>>> used= 54053.45KB free= 4726.55KB waste= 36.38KB
>>> Class data capacity= 8748.00KB
>>> used= 7163.43KB free= 1584.57KB waste= 2.35KB
>>>
>>> For anonymous classes= 580 capacity= 2732.00KB
>>> used= 1065.06KB free= 1666.94KB waste= 16.27KB
>>> Metadata capacity= 2152.00KB
>>> used= 738.46KB free= 1413.54KB waste= 16.27KB
>>> Class data capacity= 580.00KB
>>> used= 326.60KB free= 253.40KB waste= 0.00KB
>>>
>>>
>>>
>>> Nice, thanks :)
>>>
>>> Updated webrev:
>>> http://cr.openjdk.java.net/~zgu/8189688/webrev.03/
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.03/>
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.03/
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.03/>>
>>>
>>>
>>> All is well. Note that you could reduce the footprint of
>>> your change
>>> somewhat by defining a structure like this:
>>>
>>> struct numbers_t { size_t cap; size_t used; size_t free;
>>> size_t waste; }
>>>
>>> and replacing the many members in
>>> PrintCLDMetaspaceInfoClosure with
>>> instances of this structure:
>>>
>>> numbers_t total;
>>> numbers_t total_class;
>>> numbers_t total_anon;
>>> numbers_t total_anon_class;
>>> Depending on how far you go, your code could deflate quite
>>> a bit.
>>> Give the structure a default ctor and your large
>>> initializer list
>>> goes away; give it a printing function and you reduce
>>> print-summary() to four function calls; with something
>>> like an
>>> numbers_t::add(size_t cap, size_t used, size_t free,
>>> size_t
>>> waste)
>>> you can reduce the additions in
>>> PrintCLDMetaspaceInfoClosure::print_metaspace() to four
>>> lines.
>>>
>>> Just a suggestion, I leave it up to you if you do this.
>>>
>>> Lines 3108 and 3129 miss each a space before BytesPerWord.
>>> Change
>>> looks fine otherwise.
>>>
>>> Thanks, Thomas
>>>
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>> All else looks fine to me now. I do not need
>>> another review.
>>>
>>> Thanks for your work, this will come in handy!
>>>
>>> ..Thomas
>>>
>>> On Tue, Oct 24, 2017 at 5:08 PM, Zhengyu Gu
>>> <zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>>>
>>> wrote:
>>>
>>> Hi Thomas,
>>>
>>>
>>> Not sure whether we misunderstood each
>>> other. I was
>>> thinking of
>>> something in the line of:
>>>
>>> <<<<
>>> ....
>>> ClassLoader:
>>> jdk/internal/reflect/DelegatingClassLoader
>>> Metadata:
>>> capacity: 5.00KB used:
>>> 3.32KB free: 1.68KB
>>> waste: 0.00KB
>>> Class data:
>>> capacity: 1.00KB used:
>>> 0.54KB free: 0.46KB
>>> waste: 0.00KB
>>>
>>> ClassLoader: for anonymous class
>>> Metadata:
>>> capacity: 1.00KB used:
>>> 1.00KB free: 0.00KB
>>> waste: 0.00KB
>>> Class data:
>>> capacity: 1.00KB used:
>>> 0.64KB free: 0.36KB
>>> waste: 0.00KB
>>> ....
>>>
>>> Summary:
>>> XX class loaders encountered, total
>>> capacity: xx,
>>> total waste: xx.
>>>
>>> Peak usage by class loader: xxxx
>>> >>>>
>>>
>>> Added summary lines:
>>>
>>> Total class loaders= 56 capacity=
>>> 6378.00KB
>>> used= 6205.08KB free= 172.92KB waste=
>>> 1.44KB
>>> For anonymous classes= 54 capacity=
>>> 212.00KB
>>> used= 96.95KB
>>> free= 115.05KB waste= 0.94KB
>>>
>>>
>>>
>>>
>>> These numbers would not be
>>> interpretation,
>>> just a
>>> convenience to
>>> the reader to get a clear picture.
>>>
>>> It even may be useful to separate the
>>> output
>>> between basic and
>>> detailed mode, and in basic mode omit
>>> all the
>>> single class
>>> loaders and just print the summary line.
>>>
>>> Updated webrev:
>>> http://cr.openjdk.java.net/~zgu/8189688/webrev.01/index.html
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.01/index.html>
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.01/index.html
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.01/index.html>>
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.01/index.html
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.01/index.html>
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.01/index.html
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.01/index.html>>>
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.01/index.html
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.01/index.html>
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.01/index.html
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.01/index.html>>
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.01/index.html
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.01/index.html>
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.01/index.html
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.01/index.html>>>>
>>>
>>>
>>>
>>> metaspace.hpp:
>>>
>>> I would have preferred to keep
>>> scale_unit file
>>> local static
>>> instead of exposing it via MetaspaceAux,
>>> because it
>>> does not
>>> really have anything to do with
>>> metaspace.
>>>
>>> Fixed
>>>
>>>
>>> Otherwise ok.
>>>
>>> ---
>>>
>>> metaspace.cpp
>>>
>>> - ChunkManager::print_statistics():
>>> thanks for
>>> reusing this
>>> function!
>>> -> Scale can only be ever 1, K, M,
>>> G, yes?
>>> So, could you
>>> add an assert at the start of the
>>> function, and a
>>> comment at the
>>> prototype or function head?
>>> -> Also, now that
>>> ChunkManager::print_statistics() takes a
>>> scale, could you please change the
>>> printout to use
>>> floats like
>>> you did in
>>> PrintCLDMetaspaceInfoClosure::print_metaspace()?
>>>
>>> Done.
>>>
>>>
>>> Chunkmanager (non-class):
>>> 0 specialized (128 bytes) chunks, total
>>> 0.00KB
>>> 0 small (512 bytes) chunks, total 0.00KB
>>> 0 medium (8192 bytes) chunks, total 0.00KB
>>> 0 humongous chunks, total 0.00KB
>>> total size: 0.00KB.
>>> Chunkmanager (class):
>>> 0 specialized (128 bytes) chunks, total
>>> 0.00KB
>>> 0 small (256 bytes) chunks, total 0.00KB
>>> 0 medium (4096 bytes) chunks, total 0.00KB
>>> 0 humongous chunks, total 0.00KB
>>> total size: 0.00KB.
>>>
>>>
>>> - I am concerned about races in
>>> PrintCLDMetaspaceInfoClosure::do_cld(ClassLoaderData* cld).
>>> Maybe my understanding is limited. We
>>> bail if
>>> cld->is_unloading.
>>> But nothing prevents a
>>> ClassLoaderDataGraph from
>>> starting to
>>> unload a ClassLoaderData and tearing
>>> down the
>>> Metaspace after we
>>> started printing it in another thread,
>>> right? Also,
>>> I do not see
>>> any fences.
>>>
>>> So, I wonder whether
>>> PrintCLDMetaspaceInfoClosure
>>> should run in
>>> lock protection. And then, I wonder if it
>>> would be
>>> good to
>>> separate data gathering and printing. We
>>> print to a
>>> (at least in
>>> principle) unknown output stream,
>>> which may be
>>> doing slow File
>>> IO or even Network IO. Doing this
>>> under lock
>>> protection seems
>>> not a good idea (but I see other places
>>> where this
>>> happens too).
>>>
>>> For an example, see
>>> ChunkManager::get_statistic() vs
>>> ChunkManager::print_statistic(). Could
>>> you
>>> do the
>>> same, have a
>>> data gathering step where you collect
>>> your
>>> <capacity/used/free/waste> quadrupel in a
>>> variable
>>> sized list of
>>> structures in memory, and print it out
>>> in a
>>> separate step? I
>>> realize though that the effort would be
>>> larger than
>>> for what we
>>> did in ChunkManager::get_statistic(),
>>> where we only
>>> fill a
>>> structure.
>>>
>>>
>>> Unlike other NMT queries, this query is
>>> executed at a
>>> safepoint by
>>> VMThread, so it should be okay.
>>>
>>> Updated webrev:
>>> http://cr.openjdk.java.net/~zgu/8189688/webrev.02/
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.02/>
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.02/
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.02/>>
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.02/
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.02/>
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.02/
>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.02/>>>
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>> ------
>>>
>>> vm_operations.hpp
>>>
>>> - VM_PrintMetadata : do we still need
>>> _unit?
>>>
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>>
>>> Thanks!
>>>
>>> Thomas
>>>
>>>
>>>
>>> On 10/23/2017 11:08 AM, Thomas Stüfe
>>> wrote:
>>>
>>>
>>>
>>> On Mon, Oct 23, 2017 at 5:03 PM,
>>> Zhengyu Gu
>>> <zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>>
>>> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>>>
>>> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com>>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>>
>>> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com>>>>>>
>>> wrote:
>>>
>>>
>>>
>>> Okay. So this is
>>> important for
>>> understanding cases
>>> where we have
>>> a large number of
>>> miniscule class
>>> loaders,
>>> each one
>>> only having
>>> a few numbers of
>>> chunks.
>>> In this
>>> case, would it be
>>> useful to
>>> have a running total of
>>> "free"
>>> and "waste",
>>> too? Or
>>> even better,
>>> also average and peak
>>> values of
>>> "free" and
>>> "waste" (to tell
>>> apart cases where you
>>> have one
>>> outlier vs
>>> cases where
>>> just all
>>> metaspaces waste a lot
>>> of memory).
>>> Just out of
>>> curiosity, I
>>> looked at
>>> http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt>
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt>>
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt>
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt>>>
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt>
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt>>
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt>
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt>>>>
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt>
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt>>
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt>
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt>>>
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt>
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt>>
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt>
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt
>>> <http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt>>>>>
>>> and
>>> it seems that "free"
>>> is the
>>> problem, not
>>> "waste"? So I
>>> guess
>>> what happens is that
>>> all the
>>> little classloaders
>>> allocate just
>>> enough memory to push
>>> them over
>>> "_small_chunk_limit=4",
>>> so they
>>> allocate the first
>>> medium chunk,
>>> from which
>>> then they
>>> take a
>>> small bite and leave
>>> the
>>> rest
>>> laying around?
>>>
>>> Yes. The free space of
>>> anonymous
>>> classes should be
>>> counted
>>> as waste,
>>> in my opinion. I am not
>>> sure if
>>> everyone agrees,
>>> so I took the
>>> summary line out of this
>>> patch.
>>>
>>> I would be more than happy
>>> to restore
>>> the summary
>>> line, if
>>> you find
>>> it is useful :-)
>>>
>>>
>>> I agree with you. Typically
>>> class
>>> loaders
>>> stop loading
>>> at some
>>> point, especially these tine
>>> ones, and
>>> often will not
>>> resume
>>> loading. So, effectivly, the
>>> space is
>>> wasted. It still
>>> helps to
>>> distinguish "free" in the
>>> current
>>> chunks
>>> from "free" in the
>>> other chunks to tell this
>>> situation apart
>>> from a
>>> situation where
>>> we have just a bug in metaspace
>>> chunk handling
>>> preventing us to
>>> use up our chunks.
>>>
>>>
>>> The latter
>>> would be an
>>> important
>>> addition,
>>> regardless
>>> if this is
>>> for customers
>>> or for us.
>>> Chunks idling in
>>> freelists can
>>> make a
>>> huge
>>> impact, and
>>> unfortunately this
>>> may happen
>>> in perfectly
>>> valid cases.
>>> See e.g.
>>> our JEP
>>> "https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>>>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>>>>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>>>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690
>>> <https://bugs.openjdk.java.net/browse/JDK-8166690>>>>>>". We have
>>> already a printing
>>> routine for free
>>> chunks, in
>>> ChunkManager::print_all_chunkmanagers(). Could
>>> you add
>>> this to
>>> your output?
>>>
>>>
>>> Make sense!
>>> Could you
>>> recommend what data and
>>> format you
>>> would like
>>> to see?
>>>
>>>
>>>
>>> Would not
>>> ChunkManager::print_all_chunkmanagers() be
>>> sufficient?
>>>
>>> Okay, I might need to tweak
>>> output
>>> format.
>>>
>>>
>>> Fine by me. Nothing depends
>>> on it
>>> yet.
>>>
>>> Thanks, Thomas
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>>
>>> -------------
>>>
>>> Other than
>>> above notes,
>>> the changes seem
>>> straighforward, I did
>>> not see
>>> anything wrong.
>>> Minor nits:
>>>
>>> -
>>> PrintCLDMetaspaceInfoClosure::_out,
>>> _scale
>>> and _unit
>>> could all
>>> be constant
>>> (with _out
>>> being a
>>> outputStream*
>>> const).
>>> - We also do
>>> not need to
>>> provide
>>> scale *and*
>>> unit as
>>> argument,
>>> one can be
>>> deduced from
>>> the other.
>>> This would
>>> also prevent
>>> mismatches.We
>>> do need
>>> scale here,
>>> since nmt
>>> command
>>> line can set
>>> scale and
>>> we do
>>>
>>> have to honor
>>> that.
>>>
>>> However, passing
>>> unit is
>>> ugly! I don't
>>> want to
>>> introduce
>>> inverse
>>> dependence
>>> (metaspace ->
>>> nmt), which is
>>> also ugly.
>>>
>>>
>>> Yes, that would be
>>> regrettable.
>>>
>>> Probably should
>>> move scale
>>> mapping code from
>>> NMTUtil to a
>>> common util?
>>>
>>>
>>>
>>> That would be possible,
>>> these
>>> functions
>>> (scale_from_name etc)
>>> are simple enough to be
>>> moved to
>>> a generic file.
>>> However, if you
>>> pass scale, deducing
>>> the
>>> string
>>> that goes with
>>> it is
>>> trivial and
>>> I would have no qualms
>>> doing this
>>> by hand in
>>> metaspace.cpp. But
>>> it is a matter of
>>> taste.
>>>
>>>
>>> I did not look
>>> closely
>>> at locking
>>> issues, I assume
>>> MetaspaceAux::print_metadata() is
>>> supposed to
>>> run only in
>>> Safepoints?
>>>
>>>
>>> No.
>>> sum_xxx_xxx_in_use
>>> queries are
>>> guarded by locks.
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>> Thanks, Thomas
>>>
>>>
>>>
>>> Thanks & Kind
>>> Regards,
>>> Thomas
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Oct
>>> 20,
>>> 2017 at
>>> 4:00 PM,
>>> Zhengyu Gu
>>> <zgu at redhat.com
>>> <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>>
>>> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com>>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>>>
>>> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>>
>>> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com>>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>>>>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>
>>> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com>>>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>
>>> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com>>>>
>>> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>>
>>> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com>>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>>>>>
>>> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>>
>>> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com>>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>>>
>>> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>>
>>> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com>>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>>>>
>>>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>
>>> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com>>>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>
>>> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com>>>>
>>> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>>
>>> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com> <mailto:zgu at redhat.com
>>> <mailto:zgu at redhat.com>>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>>> <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>>>>>>> wrote:
>>>
>>> Up to now,
>>> there is
>>> little
>>> visibility
>>> into how
>>> metaspaces
>>> are used,
>>> and by whom.
>>>
>>> This proposed
>>> enhancement gives
>>> NMT the
>>> ability to
>>> report
>>> metaspace
>>> usages on
>>> per-classloader level,
>>> via a
>>> new NMT command
>>> "metadata"
>>>
>>>
>>> For example:
>>>
>>> 2496:
>>> Metaspaces:
>>> Metadata space:
>>> reserved= 8192KB
>>> committed= 5888KB
>>>
>>> Class space:
>>> reserved= 1048576KB
>>> committed= 640KB
>>>
>>> Per-classloader
>>> metadata:
>>>
>>> ClassLoader: for
>>> anonymous class
>>> Metadata capacity= 5.00KB
>>> used= 1.16KB
>>> free=
>>> 3.84KB
>>> waste= 0.05KB
>>>
>>> Class data
>>> capacity= 1.00KB
>>> used= 0.59KB
>>> free=
>>> 0.41KB
>>> waste= 0.00KB
>>>
>>> ....
>>>
>>> ClassLoader:
>>> <bootloader>
>>> Metadata capacity= 5640.00KB
>>> used= 5607.42KB
>>> free=
>>> 32.58KB
>>> waste= 0.46KB
>>>
>>> Class data
>>> capacity= 520.00KB
>>> used= 500.94KB
>>> free=
>>> 19.06KB
>>> waste= 0.02KB
>>>
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>>>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>>>>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>>>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>>>>>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688
>>> <https://bugs.openjdk.java.net/browse/JDK-8189688>
>>>
>>>
More information about the hotspot-runtime-dev
mailing list