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