Embed ciMethod's methodOop into CodeBuffer?

Gary Benson gbenson at redhat.com
Wed Jun 3 01:32:53 PDT 2009


Hi Tom,

Thanks for that, I guessed it ought to be possible but I couldn't
figure out the exact steps.  For Shark we can't patch the instruction
stream itself (that's generated by LLVM into its own buffer) but we
still have the HotSpot codebuffer so I plan to drop the oops into
that and then load them from there.  It's not quite the same as
having the address as an immediate in the code, but it's the next
best thing.

Cheers,
Gary

Tom Rodriguez wrote:
> You can safely embed perm oops in nmethods but not regular
> CodeBuffers.  During code generation you use methods in the
> MacroAssembler to embed references to a JNI handle in the code,
> along with relocation information to describe it.  When the
> compilation CodeBuffer is converted into an nmethod, the jobject
> is dereferenced and that object is placed into the code stream.
> This dance is required partly because the compiler is running in
> native mode, so it has to use JNI for GC safety.  On intel look
> at movoop and the associated code for that, along with
> oop_Relocation in relocInfo.hpp and OopRecorder in oopRecorder.hpp.
> I'm not sure how well our strategy is going to work for Zero since
> it requires the ability to patch the instruction stream after a GC
> to update any oops which have moved.  Are you able to support that?
>
> tom
>
> On Jun 2, 2009, at 5:10 AM, Gary Benson wrote:
> > Hi all,
> >
> > I've been looking at the method call stuff in Shark, and I figure
> > there's a whole bunch of optimizations I can perform if I can
> > embed the methodOop corresponding to a given ciMethod into the
> > CodeBuffer.  Is this possible?
> >
> > Cheers,
> > Gary
> >
> > -- 
> > http://gbenson.net/

-- 
http://gbenson.net/



More information about the hotspot-compiler-dev mailing list