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