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

[Paul Sandoz]

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:
>  http://cr.openjdk.java.net/~vlivanov/8079205/webrev.02
> 

+1


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

Ok.

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150513/ca8a3f9c/signature.asc>