Isolated Methods JEP

[John Rose]

On Aug 12, 2016, at 2:56 PM, Michael Haupt <michael.haupt at oracle.com> wrote:
> 
> Hi Martijn,
> 
>> Am 09.08.2016 um 00:15 schrieb Martijn Verburg <martijnverburg at gmail.com <mailto:martijnverburg at gmail.com>>:
>> Love the overall idea.  A few thoughts (feel free to ignore as I'm by no means an expert in the VM).
> 
> thank you. As this JEP spans the VM and the libraries, with a definitely client-facing part in MethodHandles.Lookup, user questions are important. :-)
> 
>> * Is there a risk that Gargantuan can expand to infinite size?
> 
> There is, as much as there is a risk that infinitely many classes are loaded dynamically (e.g., via Unsafe.defineAnonymousClass()). Collecting IMs (and the constants they introduce) is not out of the question, though. Once the method handle representing an IM can be collected, the IM itself can be, too; and its constants can unless they are shared.

Indeed, special GC work is one of the costs of IMs, since the normal class-scale storage management does not apply.  The benefit is you can load bits of code with low latency and low footprint, and they can go away as soon as you stop using them.  (The MH produced by the Lookup call is the only user-visible GC root to the "stuff" of the IM.  When that MH goes dead, the JVM can edit the big G class to reclaim space, at the JVM's option.)

>> * I'm really nervous about the security implications of being able to load an arbitrary byte[] that can be executed as a method. I'm hoping that the use of the internal Unsafe + Jigsaw's module boundaries makes this secure. Lots of really, really smart people have looked at the security implications of this, right? :-)
> 
> Does Unsafe.defineAnonymousClass() worry you? It allows just this: loading some byte[] that can be executed as a method - albeit with the added complexity of it being wrapped in a complete class file.
> 
> The choice of MethodHandles.Lookup as the place for loadCode() is deliberate. A Lookup instance defines a context for visibility and access to other elements, and the instructions in the byte[] array will be subject to the scrutiny imposed by the Lookup instance at hand.
> 
> People smarter than me will say more about the security implications. This is a JEP draft. There is no implementation yet, not even a prototype, and there is a lot to be learned along the way.

See also my previous points about MH factories handling access checks, using pre-existing Lookup APIs.

Probably the IM is just a faster, more compact way to make something you could also have made by spinning MH's together.  If someone figures out what an IM can do that you can't also do with MethodHandles.* methods, I'm very eager to hear about it.  (And I'll probably want to take it away, or else add a new MHs API point.)  Mainly, an IM gives you control over packaging and backtrace structure.

>> * Gargantuan - Appreciate it's a placeholder but I can't say I like the name, it doesn't tell me what it does on the tin.
> 
> It's a literary reference that's supposed to imply "large" [1] - could've used "Gulliver" but he's one of us. ;-)
> 
> Best,
> 
> Michael
> 
> [1] https://en.wikipedia.org/wiki/Gargantua_and_Pantagruel <https://en.wikipedia.org/wiki/Gargantua_and_Pantagruel>
I love the Online Etymology Dictionary for this sort of stuff:
  http://etymonline.com/index.php?term=gargantuan

— John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20160812/2155a301/attachment.html>