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

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Thu May 14 12:18:31 UTC 2015


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



More information about the core-libs-dev mailing list