Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Tuesday April 21, 2009
06:09 AM

jPerl - Perl on the JVM

[ #38837 ]

Note: any errors in this post are mine, not Ben's.

Many of you might think that the idea of porting Perl to the Java Virtual Machine (JVM) is silly. In fact, it's not silly, but it's difficult and what would come out of it would be different. The JVM is simply not designed for dynamic languages and its "everything is an object" assumption simply doesn't fit the multi-paradigmatic nature of Perl. However, it's still not a bad idea, just a difficult one.

Ben Evans gave a fascinating talk about this topic at a recent London.pm meeting. He's posted the slides of the Perl on the JVM (pdf) online and there's a little more discussion at his journal. He would love to have people help out with this idea, but with the caveat that this is an experiment! Like any experiment, it might fail. Ben knows that. You should know that too. And don't post long explanations about why this can't work because he's done enough of the work already that he's quite familiar with the failure modes. Basically, the project could use people with a "can do" attitude rather than a "can't do" attitude (I've worked on plenty of projects getting stuck with "can't do" people and frankly, they suck).

Why might we want to port Perl to the JVM? Well, it's blazingly fast now. Not many people talk about the Perl versus Java speed metric because, except for a few edge cases, Perl loses. Oh, and Perl would have a proper threading model, decent exceptions, a well-known deployment model, etc. There are plenty of benefits here, but plenty of issues, too.

First, Perl would have to change in some ways. Perl as it currently exists won't run on the JVM, so what comes out of this project, if anything, isn't going to be Perl in the way that jRuby isn't Ruby. Once we accept that some things would have to change, what would they be? Well, new has become a keyword. Part of the reason for this appears to be this (working) code snippet:

package TestB;

use java.util.HashMap;

sub bar {
    my $b = 1;
    my $c;
    my $obj = new HashMap();

    if ($b == 0) {
        $b = "yyyyyy";
    }
    else {
        $b = "zzzzzz";
    }

    print $b;

    print $obj->toString();
}

1;

And in case you're wondering, scalars look like this:

public class SV {
    private String pv;
    private long   iv;
    private double nv;
    private SV     rv;   // For references
    private Object obj;  // Foreign objects

    // ...

Look familiar?

Part of what's needed to get this working is coming up in OpenJDK 7 and the internals of that project might change, but the guts are there.

This isn't a project for everyone, but if it succeeded, this would be an incredibly valuable project which could have long-term benefits. However, this project is more of a "fun" project than a "we must deliver this" project. The idea is to learn new things rather than to deliver "Enterprise Perl", so keep that in mind, in spite of what I've written :)

Eventually Ben would love to get some core "Perl only" modules ported over just to see how much he could make work or how much he could bake into the language. Of course, some think "Perl 6" and wonder how this would fit, but Perl 5 will be around for a long, long time (I still see Perl 4 code) and this could give an exciting avenue for flexibility in Perl 5 -- particularly if Moose is built-in.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • question - do XS modules load parallel to the jvm, or are they off the table entirely?
    • Java uses JNI which is its native extension mechanism. I'm pretty sure at least basic XS modules could be compiled using a compat layer that provides XSUB.h and perl.h definitions but calls the appropriate JNI functions instead.

      (and no, I'm not volunteering)

    • It was my understanding that, like Ruby, the C extensions won't be available. That being said, I don't know that this is impossible, but it's not planned as far as I'm aware.

      Those XS extensions written in order to interface with different C libraries might be problematic. Those written for speed would be suitable candidates for rewriting as Java approaches the speed of C (and in some benchmarks can exceed it due to Java's optimizations).

      • i guess that my pipe dream of a spidermonkey perl module running inside the jvm isn't going to happen. oh well, at least there's still rhino.
  • In case there are people interested, I have started a similar-yet-different project.

    At the moment I am concentrating in writing a Perl parser in Perl (it can currently parse itself) and writing a .Net backend for it using DLR (there is nothing working yet, but I hope to have something soon).

    Check out http://github.com/mbarbon/language-p/tree/master [github.com].

    in time I hope to have something like PyPy: a complete Perl runtime written in Perl and recompilable to any lower level platform (I am dreaming to support

  • new has become a keyword.

    I can't see why that'd be necessary. For Perl 5 object semantics (overloading, AUTOLOAD, UNIVERSAL, dispatch) you need a thunking layer between Perl objects and Java objects already. If you want interoperability between them, you need the same thunking layer.

    In my mind, the right approach is to translate all bless REFERENCE syntax into metaobject calls, not to add new syntax. The Perl 5 data and object models are flexible enough that you can implement them in terms of Java mor

    • I agree it's not necessary to make new a keyword, and I don't think it's desirable. I wasn't thinking about making JVM objects available at the Perl level, but if you wanted to do that, I'd propose a new keyword instead: javanew, or something like that. Then Perl can be Perl, and if you want to get to JVM objects you can.

      Come to think of it, even better than a keyword might be a module. It'd have to be a very special module, though, something akin to DynaLoader.

      Anyway, great project! It's been done (and

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
      • But what do you do if you want to instantiate a Ruby object? Create a rubynew constructor? New constructors for every language out there? It gets unwieldy after a while.

        • Add to that the fact that adding keywords specific to an implementation diverges from the reference implementation. Library fragmentation is bad enough; as Microsoft and Sun about that sometime (though the latter has been happy to inflict it upon other languages).

          • You'd have to talk to the people putting it together. At some point, there's probably going to be some divergence. Perhaps they can also get rid of legacy stuff that's holding Perl back?

            • Perhaps they can also get rid of legacy stuff that's holding Perl back?

              I have no hope of that experiment succeeding until p5p consensus finally acknowledges that its long dalliance with DarkPAN-paralyzed stagnation has failed, miserably. (Perl 5 doesn't have classes in 2009?)

              Of course, a successful Perl 5 on the JVM (or even Parrot) might demonstrate that the sky hasn't fallen, and both people who care about running code last modified in 1995 on a release from 2009 can well and truly port it themselves (

        • In that case, I like the idea of having to go through a module, better. When you want a Java object, you have to explicitly go through a Perl module that provides that access. When you want a Ruby object, similar story, different module.

          I had no idea you were trying to provide access to objects in so many different languages...

          --
          J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • First of all this sounds like a very exciting and interesting project.

    But I have to agree with chromatic that, if you want to support as much of Perl as possible, you'll probably need some kind of indirection layer, both for the object system and for things like local $a[2] = $stuff; (Or is that handled in the SV structure?)

    Another piece of interest - does it support BEGIN blocks (and if not, is that planned)?

  • I posted this blog entry into reddit and this link was posted in comments: Considerations on Porting Perl to the Java Virtual Machine - master thesis [ebb.org].