Request for reviews .02 (L): 6951083: oops and relocations should part of nmethod not CodeBlob

Tom Rodriguez tom.rodriguez at oracle.com
Mon May 17 11:26:42 PDT 2010


Can you go ahead and move do_unloading out of CodeBlob completely since it's really nmethod specific.  You should switch CodeCache::do_unloading to use FOR_ALL_ALIVE_NMETHODS too.

in libjvm_db.c, oops_end - oops_beg isn't the same as oops_len since oops_end/oops_beg aren't pointers, they are integer offsets, so you'd need to divide by the sizeof oop.

in nmethod.cpp, I think they nmethod constructor for the dtrace helpers also needs to this logic:

+     _scopes_data_offset      = _oops_offset          + round_to(code_buffer->total_oop_size (), oopSize);

since there is a copy_oops_to call in that constructor.

Otherwise I think this looks good.

tom

On May 17, 2010, at 6:05 AM, Christian Thalinger wrote:

> On Wed, 2010-05-12 at 10:15 -0700, Vladimir Kozlov wrote:
>> src/share/vm/code/oopRecorder.hpp
>> 
>> // => code->copy_oops(_handles)
>>       ^ nm->
> 
> Done.
> 
>> 
>> src/share/vm/code/nmethod.hpp
>> Add embedded oop table information into nmethod's comment:
>> 
>>  104 // A nmethod contains:
>>  105 //  - header                 (the nmethod structure)
> 
> Done.
> 
>> src/share/vm/includeDB_core
>> Why it is codeBlob.hpp and not nmethod.cpp?:
>> 
>> + codeBlob.hpp                            jniHandles.hpp
> 
> Oops.  This looks like a leftover.  Removed.
> 
> http://cr.openjdk.java.net/~twisti/6951083/webrev.02/
> 
> -- Christian
> 



More information about the hotspot-compiler-dev mailing list