Embed ciMethod's methodOop into CodeBuffer?
Thomas.Rodriguez at Sun.COM
Wed Jun 3 12:23:24 PDT 2009
Glad I could help.
On Jun 3, 2009, at 7:58 AM, Gary Benson wrote:
> Hi Tom,
> I have this working now, thanks for your help!
> Gary Benson wrote:
>> 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.
>> 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?
>>> 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?
More information about the hotspot-compiler-dev