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

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Fri May 15 12:14:59 UTC 2015


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 JVMnmethodBucket* 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 javalanginvokeCallSiteContext, 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