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.

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.

--
John.

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 dev.perl.com or talk to Dan Sugalski or Simon Cozens to see why.
-pete

Entropy is not what is used to be.

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 perl.com 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 (http://martynov.org/)

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.

Cheers,
-- moodster