Thanks, John.
What do you think about the following version:
http://cr.openjdk.java.net/~vlivanov/8079205/webrev.04
Best regards,
Vladimir Ivanov
On 5/15/15 8:06 PM, John Rose wrote:
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.
