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

[Vladimir Ivanov]

Thanks, John.

What do you think about the following version:
   http://cr.openjdk.java.net/~vlivanov/8079205/webrev.04

Best regards,
Vladimir Ivanov

On 5/15/15 8:06 PM, John Rose wrote:
> I know injected fields are somewhat hacky, but there are a couple of conditions here which would motivate their use:
>
> 1. The field is of a type not known to Java.  Usually, and in this case, it is a C pointer to some metadata.
>
> We can make space for it with a Java long, but that is a size mismatch on 32-bit systems.  Such mismatches have occasionally caused bugs on big-endian systems, although we try to defend against them by using long-wise reads followed by casts.
>
> 2. The field is useless to Java code, and would be a vulnerability if somebody found a way to touch it from Java.
>
> In both these ways the 'dependencies' field is like the MemberName.vmtarget field.  (Suggestion: s/dependencies/vmdependencies/ to follow that pattern.)
>
> — John
>
> On May 15, 2015, at 5:14 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>>
>> 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.
>>>>
>