oops_do GC question

[Deneau, Tom]

Doug --

This is the default collector, and is --vm server.
Yes, it seems to always miss with -Xmx6g.

-- Tom

> -----Original Message-----
> From: Doug Simon [mailto:doug.simon at oracle.com]
> Sent: Monday, June 16, 2014 3:27 AM
> To: Deneau, Tom
> Cc: graal-dev at openjdk.java.net
> Subject: Re: oops_do GC question
> 
> Which collector is being used?
> 
> Is this with -vm server (i.e., hosted mode)? If not, then it could just
> be that Graal compilation on another thread happened to trigger a GC at
> a different time during your 6g execution.
> 
> If you are using -vm server, then this goes against my expectation of
> generational GC as well. In the 6g case, does it always "miss" the
> "this" pointer?
> 
> -Doug
> 
> On Jun 13, 2014, at 7:15 PM, Deneau, Tom <tom.deneau at amd.com> wrote:
> 
> > Hi all --
> >
> >
> >
> > I have been modifying our hsail JVM side code to use the standard
> process of updating the oops in the saved HSAIL state by calling oops_do
> from a GC thread.    The oops_do goes thru the saved hsail frames and
> applies the oops_do closure to each oop in each saved frame.  In the
> trunk today we have a hackier (and higher overhead) process involving
> copying oops to and from a java Object array and letting them get fixed
> up there if necessary.
> >
> >
> >
> > Anyway, the oops_do implementation seems to be working but I had a
> question.  I have a test app that does enough allocation that the
> HsailDeopt::oops_do gets invoked while we are processing the deopts.
> >
> > I ran it in a number of heap configurations.  I first ran it with a
> small enough heap (-Xmx1g) such that the compressed oops had no shift or
> base offset.  When I did this, I saw that each processed oop had been
> forwarded so the oops_do had the effect of changing the local oop in the
> hsail frame, for example
> >
> >
> >
> >  deopt 12475, workitem 13320, pc 2401 slot 12475, bit=0,
> >
> >       oop_ptr=0x7f00107f9238, old=fab203a0, new=ffa981d0
> >
> >
> >
> > which all made sense.
> >
> >
> >
> > Then I ran the same app with a large enough heap (-Xmx6g) that the
> compressed oops used a shift but no base.  In this configuration, the
> oops_do did not end up changing the oop in the hsailFrame, for example
> >
> >  deopt 1051, workitem 1530, pc 2423 slot 1051, bit=0,
> oop_ptr=0x2b1e5c6d41b8, old=0x640135388, new=0x640135388
> >
> >
> >
> >
> >
> > I stepped thru it the oops_do and when it calls should_scavenge, it
> does indeed come up false since the oop address (0x640135388 above) is
> not in the young generation.
> >
> >
> >
> > The oop being processed above for this kernel is I believe a "this"
> pointer for the class that wraps the kernel.
> >
> >
> >
> > Just wondering why in the 1g case this oop would still be in the young
> generation but in the 6g case it would not?
> >
> >
> >
> > -- Tom
> >
> >
> >
> >