RFR (XS): 8211123: GC Metaspace printing after full gc does not reflect recent changes (Was: Re: A Bug Of Metaspace After Full GC)
thomas.stuefe at gmail.com
Fri Sep 28 05:57:01 UTC 2018
On Fri, Sep 28, 2018 at 12:55 AM, JC Beyler <jcbeyler at google.com> wrote:
> Thanks both Thomas.
> I created https://bugs.openjdk.java.net/browse/JDK-8211255 for getting the
> code in to do the compilation on the fly and being to deprecate the
> testcase.jar that this would add. I have not put myself as assignee for that
> one due to me still knee deep in the vmTestbase rebasing. If I get some free
> cycles, I'll take a stab at it :-)
> I believe I have a LGTM from Thomas Schatzl for this webrev. Would you
> Thomas Stüfe provide one as well or would someone else?
Looks fine to me as well. Not sure if we really need 1G of heapspace
in the child process, but I have no strong emotions there.
> On Thu, Sep 27, 2018 at 12:19 PM Thomas Schatzl <thomas.schatzl at oracle.com>
>> Hi JC,
>> On Thu, 2018-09-27 at 21:05 +0200, Thomas Stüfe wrote:
>> > Hi JC,
>> > On Thu, Sep 27, 2018 at 8:29 PM, JC Beyler <jcbeyler at google.com>
>> > wrote:
>> > > Hi Thomas and Thomas,
>> > >
>> > > Thanks for the reviews!
>> > >
>> > > @Thomas Schatzl: I looked for using a MXBean but I'm confused about
>> > > using this. What this fix+test is trying to ascertain is that the
>> > > moment of the logging of the metaspace data, the new size has been
>> > > calculated; how do I do that with a MXBean? Would I not always get
>> > > the current size? So if I did before FullGC, I'd get the previous
>> > > size, after FullGC, I'd always get the new size, no? I am most
>> > > likely missing something and I apologize!
>> No, you are right, the MXBeans will be correct after GC of course, it's
>> the logs that are wrong.
>> So forget what I said.
More information about the hotspot-gc-dev