RFR(S) 8189688: NMT: Report per-class load metadata information

Zhengyu Gu zgu at redhat.com
Mon Oct 30 15:29:11 UTC 2017


> 
> 
> 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