A short talk about forthcoming JVM technology, and its applications to dynamic languages, especially Perl.

1. Perl on the JVM
Ben Evans

2. Why?
• Haven’t we been here before?
• Has anything changed?
• Is C-based Perl a 10-point Stag?
• Doesn’t Perl already have a VM?
• Isn’t Java really slow?
• Isn’t Java proprietary / not OSS?

3. What could we gain?
• Threads
• Exceptions
• Uniformity of Deployments
• Performance (mostly via JIT tech)
• Interop (not just with Java)
• Static type improvements

4. Open Source Aspects
• Java is, to all intents and purposes, Open Source
now
• Virtually everything is GPL, Iced Tea is plugging the
tiny remaining gaps
• Open processes, as well as open code - this has
problems as well as benefits
• Consensus building among competing vendors is
important - similar to standards work in some ways
• OpenJDK7
• MLVM and jvm-l

5. JVM Basics
• Stack-based VM : No Registers
• Single byte opcodes, with restricted args
• Constant pools
• Classloaders
• JIT subsystem
• Almost-typelessness of JVM (as opposed
to .NET)

6. My approach
• Perl package == Java class
• Perl function == Java method
• Perl object == Instance of subclass of SV
• Aligned calling conventions
• Java types hosted as a ‘foreign’ type within
an SV

7. The SV class
• Houses all basic SV information
• New “foreign object” slot - for proxying
Java (and other) objects
• AV and HV are subclasses of SV
• AOT to begin with (no eval)

8. invokedynamic
• No way to directly manipulate the JVM stack frame
• JVM has several invoke* opcodes
• All are tightly type-constrained at compile time
• Not good for dynamic languages
• JRuby tries to get round it - but problems
• Some dynlangs invent private calling conventions -
not good
• Need a “typesafe function pointer”

9. invokedynamic example
• New opcode, and a new “bootstrap” type - MethodHandle
• invoke() doesn’t exist at compile-time
• will use the new invokedynamic bytecode
• This is all pre-release and may change a bit before Java 7...

10. Tools for Compilation
• AOT Compilation to start with (ie no eval)
• SableCC
• Choice of an AST / Codegen lib:
• Homegrown, using ASM + invokedynamic
• Kawa (Scheme implementation)
• JRuby

11. Example Code

12. SableCC
• Automated Parser Generator
• Java-based (some .NET support)
• Compiles a grammar to a set of Node
classes
• Automatic CST to AST transformations
• Node is a class, not an interface, subclasses
are final
• Walks of the parse tree cannot directly
annotate it - have to use auxiliary structures
for semantic information

13. Simple use of SableCC

14. JRuby
• Very nice and clean AST
• Pretty damn close in many ways...
• BUT
• Everything-Is-An-Object seems unPerly
• Ruby strings are fubared from a Perl POV
• BUT
• Plenty of ideas to borrow
• Key people are approachable and friendly
• Basic approach - take a yacc parser and port it
directly to Java as a starting point seems sound

15. Using a foreign AST

16. Compiling using JRuby

17. A Modest Proposal
• Restricted semantics (also: new)
• Subset of syntax?
• Moose as new core keywords
• New keywords for exceptions?
• Sanitizing a core set of Pure-Perl modules
• Lots of work needed to get the parser right
• Tasks should segregate well, once the
parser was approaching decent coverage

18. Thank You
Questions?