On Jul 12, 2016, at 9:38 AM, Andrew Dinn <[email protected]> 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.) 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.) 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? — John
