[9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared (original) (raw)
John Rose john.r.rose at oracle.com
Fri May 15 17:06:50 UTC 2015
- Previous message: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared
- Next message: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I know injected fields are somewhat hacky, but there are a couple of conditions here which would motivate their use:
- 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.
- 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 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.
- Previous message: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared
- Next message: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]