oops_do GC question

Deneau, Tom tom.deneau at amd.com
Fri Jun 13 17:15:46 UTC 2014

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

More information about the graal-dev mailing list