RFR(M/L): 7145569: G1: optimize nmethods scanning
Thomas Schatzl
thomas.schatzl at oracle.com
Fri Jun 21 02:59:36 PDT 2013
Hi,
On Thu, 2013-06-20 at 14:00 -0700, John Cuthbertson wrote:
> Hi Thomas,
>
> On 6/19/2013 1:33 PM, Thomas Schatzl wrote:
> > Hi,
> >
> > one issue I forgot to mention: currently when printing remembered set
> > sizes, the new nmethod remembered set is not taken into account.
> >
> > I am asking myselves, isn't the _strong_code_root_list not a type of
> > remembered set, and shouldn't it be added to this size? What do you
> > think?
>
> I think you're right. In fact I've been calling it a sort of remembered set.
Great.
> > Additionally it would be really nice to make this information available
> > in some form so that further (size related) issues in that area could be
> > diagnosed.
>
> In the short term we could certainly add a strong_code_root_mem_size()
> routine to HeapRegion and call that from the appropriate places. It
> should be straight forward - GrowableArrays keep track of their capacity.
This seems suboptimal as this would require all places that use
G1RemSet::mem_size() to add this call extra call (but possible); my
intention is to include this value in regular printouts of remembered
set sizes.
> > Unfortunately at the moment the _strong_roots_code_list is located in
> > HeapRegion, not in the remembered set, where the method to get its size
> > is.
>
> Again calling a routine from the HeapRegion that "own" the RSet should
> be OK. I'll send out a new webrev when I've done this.
>
> Longer term moving the code roots in to the actual Rset structure (not
> OtherRegionsTable though) is desirable. I'll investigate how much effort
> it will be to this.
That's exactly what I had in mind. Thanks for looking into this.
Thanks,
Thomas
More information about the hotspot-compiler-dev
mailing list