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

[Vladimir Ivanov]

After private discussion with Paul, here's an update:
   http://cr.openjdk.java.net/~vlivanov/8079205/webrev.03

Renamed CallSite$Context to MethodHandleNatives$Context.

Best regards,
Vladimir Ivanov

On 5/14/15 3:18 PM, Vladimir Ivanov wrote:
> Small update in JDK code (webrev updated in place):
>    http://cr.openjdk.java.net/~vlivanov/8079205/webrev.02
>
> Changes:
>    - hid Context.dependencies field from Reflection
>    - new test case: CallSiteDepContextTest.testHiddenDepField()
>
> Best regards,
> Vladimir Ivanov
>
> On 5/13/15 5:56 PM, Paul Sandoz wrote:
>>
>> 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.
>>