JVM/mlvm related attenders are Jython, JRuby, Da Vinci Machine Project.
Key questions:
* What's the basic operating mechanism for this VM?
* What are the hardest problems we have in this VM?
* What are the most interesting techniques used in this VM?
Some JVM-specific topics:
* Babel on a Java-centric VM. (Multi-language pain points.)
* Bytecode generation joys and woes.
* Connecting with HotSpot optimizations.
* Integration with Java data structures and APIs.
h2. Basic Operating Mechanism
For JVM proper BOM is well known: Java classes, bytecodes, managed heap, optimizing JIT, ports span the Known Universe.
For JRuby/Jython, there are layers of adaptation on the JVM architecture. Basic data structures are extended to support non-Java semantics (e.g., handle/body or map-based objects allowing monkey patching). Specialized interpreters and/or bytecode generators support non-Java code shapes and implicit arguments (such as "current frame").
For mlvm, BOM is JVM minus Java-originated restrictions, especially static typing. Specifically, fully late-bound call sites and interfaces, free-range method handles, exotic names, tail calls, continuations, tuples, etc. The limit to this list is the inventiveness of the community.
h2. Hardest Problems
* Introspection of runtime structures:
** Pythons sys._getframe()
** Rubys ObjectSpace
** Asking Java packages for classes is difficult due to classloading + namespace merging
* Class and object modification - "monkey patching"
** Call site volatility
h2. Interesting Techniques
Key questions:
* What's the basic operating mechanism for this VM?
* What are the hardest problems we have in this VM?
* What are the most interesting techniques used in this VM?
Some JVM-specific topics:
* Babel on a Java-centric VM. (Multi-language pain points.)
* Bytecode generation joys and woes.
* Connecting with HotSpot optimizations.
* Integration with Java data structures and APIs.
h2. Basic Operating Mechanism
For JVM proper BOM is well known: Java classes, bytecodes, managed heap, optimizing JIT, ports span the Known Universe.
For JRuby/Jython, there are layers of adaptation on the JVM architecture. Basic data structures are extended to support non-Java semantics (e.g., handle/body or map-based objects allowing monkey patching). Specialized interpreters and/or bytecode generators support non-Java code shapes and implicit arguments (such as "current frame").
For mlvm, BOM is JVM minus Java-originated restrictions, especially static typing. Specifically, fully late-bound call sites and interfaces, free-range method handles, exotic names, tail calls, continuations, tuples, etc. The limit to this list is the inventiveness of the community.
h2. Hardest Problems
* Introspection of runtime structures:
** Pythons sys._getframe()
** Rubys ObjectSpace
** Asking Java packages for classes is difficult due to classloading + namespace merging
* Class and object modification - "monkey patching"
** Call site volatility
h2. Interesting Techniques