perlmachine

perlmachine is a Java Virtual Machine written in Perl. Currently it doesn't have
too many features. However a few simple programs that don't require native code
work fine. The lack of I/O however makes this not obvious. :)

I intend to use GNU Classpath as the class library. It seems quite simple to
include.

perlmachine Dependencies
------------------------

- Perl 5.10.0 or higher (for switch); since that got EOL'd, you might consider
  switching to 5.12 or 5.14 anyway
- Moose (I don't know what version; I guess 'not ancient' is enough)

Running perlmachine
-------------------

In order to run perlmachine you need to do the following things:

1. setup GNU Classpath
  - either you find a precompiled solution or you compile it yourself
  - if you compile, you might have to patch (see https://projects.archlinux.org/svntogit/community.git/tree/classpath/trunk/PKGBUILD),
    otherwise it didn't work for me
  - if you have a precompiled version, unpack it
2. modify vm_main.pl
  - add entries for the directory that contains the compiled classes from GNU
    Classpath (well, technically almost any implementation should do because
    currently only java.lang.Object is ever loaded but in the future the binding
    might get tighter) as well as other classes you might want to run
  - change the name of the main class if needed
    The name of the main class is provided in normal dot notation (pkg.Test).
  
  for example:
  
  $classpath->add_entry( '/path/to/classpath/lib' );
  $classpath->add_entry( '/here/is/mymainclass' );
  my $vm = Java::VM->new( class_name => 'MyMainClass', ...
  
3. execute vm_main.pl

Currently Supported
-------------------

- classpath traversal through user defined classpath
- loading classes from file system
- many operations that deal with storing and reading variables
- reading/writing static/instance fields
- static/instance method execution, including arguments and returning values
- arrays
- string literals and some string operations work (concatenating strings with
  strings for example)
- a single native method is hardcoded in the interpreter: System.arraycopy()
  because it is needed so often

Limitations (a lot...)
-----------

- I guess handling of static initializers is still buggy
- class literals are unsupported
- anything that remotely requires a native bridge to the JVM doesn't work
  Unfortunately that means a lot of useful things can't get tested yet. For
  example concatenating a string with an integer or putting an integer in a
  collection requires loading of java.lang.Integer which wants to know its
  primitive class. No can do.
- invoking of interface methods is broken; just use the implementation for the
  variable (ArrayList a = new ArrayList(); etc.)
- complete lack of support for exceptions, you better program defensively
- no type checking whatsoever
  I'm afraid this will incur too high a performance impact. However this makes
  debugging a nightmare. All kinds of simple errors creep into the variables or
  the stack and there is no easy way to find out where they came from. Maybe I
  have to rethink that...

Planned (or likely)
-------------------

- implementation for all instructions
- native methods (not JNI but a Perl specific interface I yet have to design)
  This is of course inevitable.
- I/O is quite high on my priority list
- loading classes from JAR files (I think this comes automatically with the
  library)
- exceptions

Undecided
---------

- threading
  Threading might be a bit complicated due to Perl's conservative way of
  sharing data between threads. If I find an efficient way to implement multiple
  threads without simply sharing *everything*, I'll do it of course.

Not Planned (or very unlikely)
------------------------------

- JNI
  I never did anything with XS and I don't really intend to go that way. That is
  I assume that I need to know a thing or two about XS before I can call native
  C/C++ libraries.
- most of the tooling like JVMTI, debugging and stuff like that
- GUI stuff (AWT, SWING)
- some sort of Perl JIT
  This could be accomplished by building strings that are Perl code which can be
  eval'd. I thought of something along the lines of
  
    my $method_ref = eval 'sub { ... do stuff here ... }';
    $method_ref->();
  
  However I don't think this'll make it.

License
-------

perlmachine is licensed under the GNU General Public License v3 as
provided in COPYING. I would have preferred a more permissive license
like one of the BSD's but I fear GNU Classpath forces me into it.
(Here's a thought, maybe Apache Harmony can be included as well?)

------------------------------------------------------------------------

Copyright (C) 2011  Werner Hahn

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.