Perl on the JVM
     Ben Evans
Why?

• Haven’t we been here before?
• Has anything changed?
• Is C-based Perl a 10-point Stag?
• Doesn’t Perl already hav...
What could we gain?
• Threads
• Exceptions
• Uniformity of Deployments
• Performance (mostly via JIT tech)
• Interop (not ...
Open Source Aspects
•   Java is, to all intents and purposes, Open Source
    now
•   Virtually everything is GPL, Iced Te...
JVM Basics
• Stack-based VM : No Registers
• Single byte opcodes, with restricted args
• Constant pools
• Classloaders
• J...
My approach
• Perl package == Java class
• Perl function == Java method
• Perl object == Instance of subclass of SV
• Alig...
The SV class



• Houses all basic SV information
• New “foreign object” slot - for proxying
  Java (and other) objects
• ...
invokedynamic
• No way to directly manipulate the JVM stack frame
• JVM has several invoke* opcodes
• All are tightly type...
invokedynamic example




•   New opcode, and a new “bootstrap” type - MethodHandle
•   invoke() doesn’t exist at compile-...
Tools for Compilation
• AOT Compilation to start with (ie no eval)
• SableCC
• Choice of an AST / Codegen lib:
• Homegrown...
Example Code
SableCC
• Automated Parser Generator
• Java-based (some .NET support)
• Compiles a grammar to a set of Node
  classes
• Au...
Simple use of SableCC
JRuby
•   Very nice and clean AST
•   Pretty damn close in many ways...
•   BUT
•   Everything-Is-An-Object seems unPerly
...
Using a foreign AST
Compiling using JRuby
A Modest Proposal
• Restricted semantics (also: new)
• Subset of syntax?
• Moose as new core keywords
• New keywords for e...
Thank You
 Questions?
Upcoming SlideShare
Loading in …5
×

Perl On The JVM (London.pm Talk 2009-04)

1,143 views
1,080 views

Published on

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,143
On SlideShare
0
From Embeds
0
Number of Embeds
21
Actions
Shares
0
Downloads
12
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Perl On The JVM (London.pm Talk 2009-04)

  1. 1. Perl on the JVM Ben Evans
  2. 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. 3. What could we gain? • Threads • Exceptions • Uniformity of Deployments • Performance (mostly via JIT tech) • Interop (not just with Java) • Static type improvements
  4. 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. 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. 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. 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. 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. 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. 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. 11. Example Code
  12. 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. 13. Simple use of SableCC
  14. 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. 15. Using a foreign AST
  16. 16. Compiling using JRuby
  17. 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. 18. Thank You Questions?

×