On 12/07/16 20:40, John Rose wrote:
> On Jul 12, 2016, at 9:38 AM, Andrew Dinn <ad...@redhat.com
> <mailto:ad...@redhat.com>> wrote:
>>
>> I'm not sure how AOT compiled code is supposed to protect itself against
>> the potential consequences of my agent tweaking accessibility in this
>> way. Would it be not require -- at the least -- wholesale deoptimization
>> of compiled methods in the module to which the package is exported? How
>> would one arrange for JITted code to trap out and invalidate any
>> speculative optimizations that might be invalidated by this incremental
>> export?
>
> Either wholesale de-opt, or a fast-fail error when the injection is
> attempted.
> (It's another example of the tug-of-war between parties with different
> views on a class.)
Ok, so I suspect this may be some while coming to fruition :-)
> Either outcome is bad enough that we need speed bumps to prevent people
> from just cruising heedlessly into the failure zone. By "speed bump" I mean
> a need to assert extra-specific intention, and/or obtain an access right,
> in order to increase the visibility of (or inject code into) a module that
> has been consolidated into an AOT sub-assembly. (N.B. I'm using these
> terms in a general sense, not referring to any particular tech.)
I think this is probably necessary but it's certainly not in place right
now. Currently the 'access right' is baked into class Instrumentation,
an instance of which is simply handed out to agents - to do with what
they will. So if you want some sort of switch to drive AOT I think it
has to be as crude as 'an agent has been loaded'.
> BTW, if you contrive to inject a MethodHandles.Lookup donor into
> a class, the donee can get everything (99.9%) the class can do by
> materializing and calling appropriate method handles. With a little
> care (bind the MHs to static finals) you get identical performance.
> This is easier than spinning adapters and injecting those one by one.
> Is that how you are doing your injection?
Well, this is still being implemented so I might be able to profit form
using a MethodHandle. As it stands I'm relying on reflection so I'm
really not sure whether/how my agent might imperil any speculative AOT
compilation.
I'm not currently injecting member accesses into existing bytecode. My
agent only ever injects a callout to agent code located in the unnamed
module. That agent code may determine that it needs to use reflection to
access some specific member (field or method) that is not normally
visible to the unnamed module and in those circumstances it uses
addExports to provide the option of reflective accessibility.
Of course, it doesn't simply export the relevant package to the unnamed
module -- that would be highly insecure. Instead it exports the package
to a module provided along with the agent and employs a private channel
to acquire an enabled reflective handle.
It's hard to know for sure whether this might affect speculative AOT
compilation and, if so, how to respond. The code into which I inject the
call out may lie in any class. The members the agent accesses may lie in
any class. The reflective access is legitimised under the aegis of the
module system from a module granted the requisite permission. However,
the handle is exercised by code located in the unnamed module.
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
