accessing a static field
tom.deneau at amd.com
Thu May 16 09:40:14 PDT 2013
Are you saying the GC might have to patch the code multiple times (i.e, every time the class object has moved)?
We were counting on being able to generate the code once (as source), compile it and use the compiled code without change.
From: Doug Simon [mailto:doug.simon at oracle.com]
Sent: Thursday, May 16, 2013 11:31 AM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: accessing a static field
On May 16, 2013, at 5:37 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
> In our graal HSAIL compiler, we would like to be able to compile accesses of a static field.
> I can see that we are generating a MoveToRegOp with the result being a register and the input
> being a Constant of kind = Object, the Object being the class object which contains the static field.
> and I think we want to end up with code like:
> mov_b64 $d1, constant_address_of_class;
> ld_global_s32 $s1, [$d1 + 148];
> The second instruction is being correctly generated but for the first instruction how do I
> in java get the actual constant address to insert in the instruction, given the class Object?
> (I am assuming the address of the class really does remain constant in the face of GC)
> I glanced at the AMD64 code and I don't really understand what is going on with the
> recordDataReferenceInCode logic.
The recordDataReferenceInCode creates a patch record that the C++ layer uses to embed the oop (of the java.lang.Class instance in your case) in the instruction stream. This cannot be done until the necessary metadata describing embedded oops has been created. These embedded oops are only constant from the code's perspective, not from the GC's perspective.
Have you looked at the code starting at AMD64Move.java:488? This is how oops are embedded in AMD64 code and will hopefully instruct how you can do likewise for the HSAIL backend. The critical thing is to ensure the GC knows where the embedded oops are.
More information about the graal-dev