Re: Isolated Methods JEP

Hi John, > Am 13.08.2016 um 01:48 schrieb John Rose : > This does lead me to an extra thought: I think IM's could be given the > capability to have multiple entry points. This would allow a number of > interesting applications, starting with exception handling that

Re: Isolated Methods JEP

Hi Jochen, > Am 13.08.2016 um 12:21 schrieb Jochen Theodorou : > > On 13.08.2016 00:54, John Rose wrote: > [...] >> 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

Re: Isolated Methods JEP

Hi Mark, some degree of bytecode generator framework usage will be required with IMs all the same. The instructions have to come from somewhere. However, as John pointed out, the code may be substantially simpler in structure, which may lead to an overall more lightweight code installation

Re: Isolated Methods JEP

John mentioned         There's a fiber frame system struggling to emerge here. This is interesting.  The approaches I have looked at involve lots of code rewriting especially to capture the stack as its unwound.  Are you thinking of some approach where the exception could capture the stack as it

Re: Isolated Methods JEP

On 13.08.2016 00:54, John Rose wrote: [...] 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.

Re: Isolated Methods JEP

On Aug 12, 2016, at 2:56 PM, Michael Haupt wrote: > > Hi Martijn, > >> Am 09.08.2016 um 00:15 schrieb Martijn Verburg > >: >> Love the overall idea. A few thoughts (feel free to ignore as I'm by no >> means

Re: Isolated Methods JEP

On Aug 12, 2016, at 2:57 PM, Michael Haupt wrote: > > Hi Peter, > > thanks for your feedback! I'm responding to both your messages in one. > >> Am 09.08.2016 um 05:05 schrieb Peter Levart > >: >> In the JEP's

Re: Isolated Methods JEP

Hi Peter, thanks for your feedback! I'm responding to both your messages in one. > Am 09.08.2016 um 05:05 schrieb Peter Levart >: > In the JEP's description you write: > > "The loadCode method creates a method from the passed bytecode

Re: Isolated Methods JEP

Hi Martijn, > Am 09.08.2016 um 00:15 schrieb Martijn Verburg : > 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

Re: Isolated Methods JEP

Hi Michael, On 08/09/2016 02:05 PM, Peter Levart wrote: In which case would lookup privileges be insufficient to define an isolated method? I would expect the privileges of the code in the isolated method to be checked when such method is executed and not when defining such method - lazily,

Re: Isolated Methods JEP

Hi Michael, In the JEP's description you write: /"The loadCode method creates a method from the passed bytecode instructions and constants and returns a MethodHandle that can be used to call the method. The implementation of loadCode will take care of verification of the code to

Re: Isolated Methods JEP

Hi Michael, Love the overall idea. A few thoughts (feel free to ignore as I'm by no means an expert in the VM). * Is there a risk that Gargantuan can expand to infinite size? * I'm really nervous about the security implications of being able to load an arbitrary byte[] that can be executed as

Re: Isolated Methods JEP

Good to see this. What is the philosophy for code annotations, line numbers and stack maps? Would they be some form of constant entry? regards mark ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net