Isolated Methods JEP

[Michael Haupt]

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 process.

Regarding Smalltalk block implementation, I wonder how you'd deal with closing over elements of the lexical context. VarHandles, included in an IM's constants array, might play a role here.

Best,

Michael

> Am 15.08.2016 um 01:07 schrieb Mark Roos <mroos at roos.com>:
> 
> My expectations would be for faster load time and a simpler implementation. In my application 
> I do think that the need to use a tool like ASM to handle the complexity of class file generation is 
> the primary bottleneck. 
> 
> Getting rid of computing the various data structures and placing them in the correct location was 
> the primary reason to not even start looking at writing the class file directly.  Separating out the 
> bytecodes in nice, but for me the constants are the most difficult part.  In my case this 
> is due to the constant pool being a combination of values used by the jvm as parameters along with 
> values used directly as constants in my program.  The former is handled by ASM as needed by the 
> jvm while the latter my compiler generates as a serialized representation of a Smalltalk constant. 
> It would be nice if these were separable ( and of course bytes not Strings for my constants) 
> 
> I do use line numbers but I also place them in the BSMs for my debugger.  The only place which 
> not having them may matter is within some optimizations which cause back jumps. I could recreate 
> these if I knew the byte code index anyway.   
> 
> Since Smalltalk uses blocks quite a bit I do have more than one method in each of my class files. 
> Each block within the method creates an additional static method.  The idea of helper methods 
> sounds intriguing.  Since different methods can have different stack frames having a view method 
> would be handy as would the source code lookup and debugger helpers. 
> 
> I use exceptions to handle the Smalltalk return in block ( [^foo] and Smalltalk thrown exceptions.   
> I do like the fiber ideas.  It would be interesting to try to make the fiber idea a standard 
> feature.  This seems like a way to get stack manipulation as well even without reification. 
> 
> Ah yes, mission creep.  I would be happy with a fast defineClass with the GC improvements John 
> mentioned. 
> 
> regards 
> mark

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment

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