RFR(M/L): 7145569: G1: optimize nmethods scanning

Thomas Schatzl thomas.schatzl at oracle.com
Fri Jun 21 09:59:36 UTC 2013


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.


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


More information about the hotspot-gc-dev mailing list