[9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Wed May 13 11:59:42 UTC 2015

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.
> CallSite.java:
> 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 

> 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.

> javaClasses.hpp:
> 1182   static oop              context(oop site);
> 1183   static void         set_context(oop site, oop context);
> Is set_context required?
Good point. Removed.

> instanceKlass.cpp:
> 1876 // recording of dependecies. Returns true if the bucket is ready for reclamation.
> typo "dependecies"

Best regards,
Vladimir Ivanov

More information about the core-libs-dev mailing list