#ReflectiveAccessByInstrumentationAgents

[Andrew Dinn]

On 24/05/16 19:28, Alan Bateman wrote:
> On 24/05/2016 16:51, Andrew Dinn wrote:
>> :
>>
>> Given the impending guillotine for completion of JDK I intend to raise a
>> JIRA to mark the #ReflectiveAccessByInstrumentationAgents requirement as
>> still needing a fix and suggesting a modification to Instrumenatation as
>> the way to achieve it. If you have any other alternatives to the ones I
>> have described for how to provide agents with java.base privileges I'd
>> be very pleased to hear them and consider them as alternative
>> implementations. Meanwhile I'll look at providing a webrev which
>> implements what would be needed to provide the necessary capability via
>> Instrumenatation.
>>
> Adding an API to make it easy to break encapsulation has concerns so
> this is why it was not included in the API updates to
> java.lang.instrument and JVM TI. For now, the issue is on the JSR issues
> list pending discussion/agreement on the right way to proceed.

Well, I'll be happy as long as issues in the JSR issues list actually
are discussed, agreed and, where necessary, acted upon before JDK9 is
released.

> In general then we haven't seen problems with instrumentation for
> use-cases that instrument code to call into supporting classes
> (profilers for example). It just works for cases where the agent
> supporting classes are on the class path or boot class append path. It
> also works, via the API, for agent supporting classes in named module too.

No, indeed that works in a pretty starightforward way -- but it's not
the case I am concerned with.

> The use-cases that aren't directly supported at this time is where the
> agent want to access types in non-exported packages or where an agent
> instruments code that needs to access non-exported packages of other
> modules. Some of potential usages may fall out of the wash with
> #ReflectiveAccessToNonExportedTypes [1] but we'll have to see. The other

My interest is almost the same as #ReflectiveAccessToNonExportedTypes
except the use case is restricted to providing the opportunity to call
setAccessible to /agents only/ and even with very tight control over how
the enabled AccessibleObject is is employed. I am very much /not/
interested in granting package access to arbitrary modules. If I have to
use modules to do this then the only module which will be allowed to
call AccessibleObject.setAccessible will be one local to the agent. Of
course, I'd prefer to obtain the ability to perform this task via the
Instrumentation instance since that's an already existing channel for
granting special rights provided to every agent.

Note that any AccessibleObject created and enabled by the agent is used
either directly from agent code or from agent-generated bytecode. So,
the agent can guarantee that this use is limited only to operations
requested via the agent's control API. So, there is no risk of leakage
of access beyond that requested of the agent itself  by whoever
installed the agent.

> approach that I mentioned is where the agent does load time
> instrumentation, in which case it it can add an initalizer to any
> non-interface class in the module (doesn't have to public, doesn't have
> to be in an exported package). The agent can trigger the initializer to
> run and export the module internals to the agent or other modules. This
> doesn't help the late binding agent case of course but we are down to a
> much small part of the problem space at that point.

Well, as I said, that's not really relevant in the case I am looking at
where I don't intend to allow some arbitrary app code in any old package
to be able to perform accesses.

However, I'll also note that ignoring the dynamic agent case is not a
small part of the problem space but a really significant loss of
functionality. Usage of the Byteman agent is almost exclusively via
dynamic loading. It is critical to Byteman's widespread use in testing
since with command line loading the configuration of test cases from
maven is extremely difficult to manage. Bymamic installation is also
extremely important to most users as regards its acceptability for
monitoring and diagnostics. Most users are very unhappy with having an
agent present in normal running and only want it to be installed if and
when things ave gone wrong.

> So no need to panic, it is on the issue list, and there will be
> tinkering of the design, implementation and API for a few months yet.

Oh, it's ok, I'm not panicking. I just wanted to make sure that the
issues list is going to be addressed before JDK9 is released.

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