Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Questions On the Perl VM, Parrot, .Net, and the JVM...

by eduardo (Curate)
on Feb 01, 2002 at 22:54 UTC ( #142797=perlmeditation: print w/replies, xml ) Need Help??

So, I've been secretly reading up on parrot (as I understand it, the Perl 6 VM) a bit in my spare time. And although it seems like the developers who are involved in this project are of the highest caliber, and probably will create a good, scaleable, powerful VM... I can't help but ask myself a question. Why wasn't the Java VM chosen as the Perl 6 target platform? It seems like a reasonable choice... or am I just being dense, and the plan is to implement a separate back end byte code compiler for the target platform, and parrot just happens to be the first VM implementation of Perl 6. This would make it so implementing a JVM or .Net implementation of Perl 6 will be a less Herculean undertaking. I eagerly await input and clarification from the much more knowledgeable community!
  • Comment on Questions On the Perl VM, Parrot, .Net, and the JVM...

Replies are listed 'Best First'.
Re (tilly) 1: Questions On the Perl VM, Parrot, .Net, and the JVM...
by tilly (Archbishop) on Feb 01, 2002 at 23:15 UTC
    Very simply because VMs are not created equal.

    A VM for Perl should have common Perl operations be single units in the VM. For instance Perl does a lot of hash lookups. That should be an opcode.

    Java's VM creates something much closer to a virtual machine. (Note that not only does Java's VM not define a hash lookup as a basic operation, but Java doesn't either!) This is a bad fit for what Perl spends its time doing, you want your basic operations to be as fast as possible, and you want basic operations that can be mapped well to the Perl code.

    Incidentally Perl 5 already has what is for all intents and purposes a VM. For obvious reasons that is a far more appropriate model for Perl 6 than Java's would be.

Re: Questions On the Perl VM, Parrot, .Net, and the JVM...
by Matts (Deacon) on Feb 01, 2002 at 23:10 UTC
    The problem is that the Java VM (and the .NET CLR) is very much tied to static typing. If you take a look at Perl.NET, it has to extend the language (via POD markup) to indicate the signature of methods so that the compiler can know how to type methods. This is a really hard problem - do you use something like that and downgrade everything to "Object" (to use Java terminology) methods and fudge a slow layer on top of that, or create our own VM, with its performance focussed on dynamically typed languages. I'd go with Parrot. Not only that, but Parrot is free, in every sense of the word.
Re: Questions On the Perl VM, Parrot, .Net, and the JVM...
by jmcnamara (Monsignor) on Feb 01, 2002 at 23:18 UTC

    In the Dr. Dobbs article about the The MIT Lightweight Languages Workshop Eugene Eric Kim had this to say:

    Several attendees noted during the talk that the Perl community seemed to be reinventing the wheel in areas such as virtual-machine implementations and garbage collection.

    I hope that isn't necessarily true.


      It's totally true.

      And for many good reasons. The communities who's wheels we are reinventing are not open. They are not welcoming. They are anally retentive. They expect us to bend to their rules. Well Perl always made its own rules, and for that it needs a VM made for them. But they should perhaps look back at themselves and think just why we're reinventing wheels. Perhaps they need to reinvent their own rulebooks? I mean how successful has Smalltalk and Scheme really been in the commercial world? Not terribly. Even compared to Perl's small standards.

      Well, as Larry says, "If you're determined to reinvent the wheel, at least try to invent a better one."
      And if the current vm techology is an all-purpose radial, then the Perl6 effort is a high-performance tire, capable of higher speeds, tighter turns, and performance in worse conditions. And it's optimized for the kind of driving that the Perl6 car does.
      Seriously, Perl needs a different type of VM than Java. Go to or talk to Dan Sugalski or Simon Cozens to see why.

      Entropy is not what is used to be.
Re: Questions On the Perl VM, Parrot, .Net, and the JVM...
by eduardo (Curate) on Feb 02, 2002 at 00:11 UTC
    I didn't know if this should be an UPDATE or if it should be a new node... I decided to go for the choice I felt was safer. So, all of those things being said (thank you matts, tilly, etc...) My next question automatically is... why is Parrot itself not being implemented in something like Java? Is it as simple as: "we don't want to, and it would be slow?" Because if that's the case, I think that following the parrot implementation in Java may be a *wonderfully* fun project for someone to undertake...
      Aside from the reasons you've given, because Java's not as portable as Perl 5 or C. Seriously -- show me a Java compiler and a Java VM that run on platforms like Stratus VOS, Windows CE, Cygwin, or VMS, as well as stalwarts like NetBSD and Linux. gcc is available there -- how about javac?

      That's not to say Java couldn't do it, but portability concerns alone would rule it out. Performance was probably also a concern -- why reimplement a virtual machine on top of another virtual machine?

      For what it's worth, chip had a secret project in 1999 called "Topaz", which involved rewriting Perl 5 in C++. I believe he also spent a week porting it to GNOME libraries. It's a nice academic exercise, but the odds seem to be stacked slightly against practical results. (Don't let me completely discourage you, though. :)

        FWIW, it was Simon Cozens who ported miniperl to the Gnome libraries. He wrote an article about it for here.
      Quote from Parrot FAQ:

      12. So you won't run on the JVM/.NET?

      Sure we will. They're just not our first target. We build our own interpreter/VM, then when that's working we start in on the JVM and/or .NET back ends.

      Ilya Martynov (

      In addition to what everyone else has been said, if you feel like contributing work on a Java port, go right ahead! It is an open source project, and that is how things go. Someone finds something interesting, does it, and then contributes back.

      Incidentally one of the desires of the Parrot project is to be faster than Perl. So far they claim to be succeeding with speedups in the range of 20-50% for identical byte code. (Of course there are enough overall design differences that we won't have any concrete idea how fast Perl 6 will or won't be for a long time.)

      This is easy to answer. Because C is ipso facto faster for this sort of thing. And one of the goals of Perl 6 is to make sure we don't continue to lose out in the performance stakes.

      Not only that, but who would write it? Perl people tend to know C as a second language. So if you want contributions you need to code in a language people are comfortable in. At the p5p meeting just before Perl 6 was decided on as the next step, Chip Salzenburg (sp?) asked what languages people would be most comfortable hacking Perl 6 out in. C was the overwhelmingly most popular choice.

Re: Questions On the Perl VM, Parrot, .Net, and the JVM...
by moodster (Hermit) on Feb 02, 2002 at 15:26 UTC
    As far as I understand, the Java VM has its limitations. For example, it cannot handle continuations properly. While this is not a problem while doing Java, it's a problem for other languages using that VM. Guido van Rossum admitted in an interview that one of the main things that kept him from implementing continuations in python was that he wanted to keep compatibility with Jython, which is a parallell implementation that runs on the Java VM.

    -- moodster

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://142797]
Approved by root
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (5)
As of 2017-09-20 02:33 GMT
Find Nodes?
    Voting Booth?
    During the recent solar eclipse, I:

    Results (230 votes). Check out past polls.