RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared
paul.sandoz at oracle.com
Wed May 13 14:56:37 UTC 2015
On May 13, 2015, at 1:59 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> Peter, Paul, thanks for the feedback!
> Updated the webrev in place:
>> I am not an export in the HS area but the code mostly made sense to me. I also like Peter's suggestion of Context implementing Runnable.
> I agree. Integrated.
>> Some minor comments.
>> 145 private final long dependencies = 0; // Used by JVM to store JVM_nmethodBucket*
>> It's a little odd to see this field be final, but i think i understand the motivation as it's essentially acting as a memory address pointing to the head of the nbucket list, so in Java code you don't want to assign it to anything other than 0.
> Yes, my motivation was to forbid reads & writes of the field from Java code. I was experimenting with injecting the field by VM, but it's less attractive.
I was wondering if that were possible.
>> Is VM access, via java_lang_invoke_CallSite_Context, affected by treating final fields as really final in the j.l.i package?
> No, field modifiers aren't respected. oopDesc::*_field_[get|put] does a raw read/write using field offset.
More information about the core-libs-dev