oops_do GC question

[Doug Simon]

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