RFR(S) 8189688: NMT: Report per-class load metadata information
David Holmes
david.holmes at oracle.com
Tue Oct 31 02:41:49 UTC 2017
On 30/10/2017 11:57 PM, Zhengyu Gu wrote:
> Hi David,
>
>
>>> During VM exit, we are not supposed to request a safepoint, correct?
>>
>> VM exit uses a safepoint - can you use it do gather the data?
>>
>
> Apparently, not all VM exits go through safepoint. If Java is terminated
> due to application's main method exists (JVM is terminated via
> jni_DestoryJavaVM) , there is not safepoint executed.
Yes there is. See the comments in Threads::destroy_vm and
VMThread::wait_for_vm_thread_exit.
JNI_DestroyJavaVM ->
Threads::destroy_vm() ->
VMThread::wait_for_vm_thread_exit();
_should_terminate = true;
VMThread::run()
this->loop(); // returns when _should_terminate is true
...
// 4526887 let VM thread exit at Safepoint
_no_op_reason = "Halt";
SafepointSynchronize::begin();
The VMThread always takes the VM to a safepoint on a non-aborting exit.
David
> Thanks,
>
> -Zhengyu
>
>> David
>>
>>> Without a safepoint, it is unsafe to walk class loaders.
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>>> 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>> wrote:
>>>>
>>>> Hi Zhengyu,
>>>>
>>>> On Tue, Oct 24, 2017 at 8:04 PM, Zhengyu Gu <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/>
>>>>
>>>>
>>>> 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>>> 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>>>
>>>>
>>>>
>>>>
>>>> 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/>>
>>>>
>>>> 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>>>>> 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>>>>
>>>> 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>>>>>".
>>>> 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>>>>>>> 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>>>>>>
>>>> Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>>>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>>>>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>>>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>>>>>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>>>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>>>>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>>>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html
>>>> <http://cr.openjdk.java.net/~zgu/8189688/webrev.00/index.html>>>>>>
>>>>
>>>> Test:
>>>>
>>>> hotspot_tier1_runtime,
>>>> fastdebug and
>>>> release on
>>>> x64 Linux.
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
More information about the hotspot-runtime-dev
mailing list