It's not too late for access control

[Andrew Dinn]

On 12/07/16 17:07, John Rose wrote:
> On Jul 12, 2016, at 9:00 AM, John Rose <john.r.rose at oracle.com> wrote:
>>
>> lurk mode
> 
> P.S. I forgot one more point:  As JVM/JIT guy I find the prospect of sealing
> packages very appealing.  Maybe it's a false promise, but it would be a
> home run if we could reliably seal sub-assemblies for tree-shaking AOT
> compilation.  Doing this requires pretty strong assurances that the AOT
> engine can enumerate all uses of a "public" class.  Doesn't this use case
> interfere with the proposed principle that "public always means global"?
> Again, it's a tug-of-war between the class author and an assembly-time
> operation.

I've been waiting for someone from the JVM side to make a proposal about
using modules to optimize compilation -- AOT being the obvious candidate
that stands to gain the most -- and I'm very glad it is John who finally
proposed it :-). Those assurances really do need to be very strong. I
wonder if they can be made strong enough, especially granted the current
proposal to provide class Instrumentation with method redefineModule
that, inter alia, accepts a set of exports to add to those already in
place for some module being redefined.

My agent wants to use this extended API to provide fairly tightly
constrained incremental exposure of non-exported packages. Essentially,
any currently unexported package in any module may potentially be made
visible to a single, privileged module provided as part of my agent.
This is to allow the agent to obtain specific reflective access to
non-public members of the classes so exported. Other agents may not be
quite so careful to limit the degree to which they expose module
packages to other modules.

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?

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