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

[John Rose]

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