Seeking a developer/designer to implement a JVM

[Raghu Kaippully]

Hi,

I have been working on a project to implement a free JVM. I already have
a project in sourceforge (http://sf.net/projects/troy) and some details
are there in my blog (http://www.livejournal.com/users/raghu_kb/). I am
looking for developers who are interested.

Here's what I expect from a contributor.

1. Should have good understanding of Java language; added bonus for
those who have read JVM specification and at least have a rough idea of
what it is all about.
2. Should be good in C++ (That's what we use for coding!!!)
3. Should have an appetite for object oriented design.
4. Should have good exposure to systems programming. We are going to do
stuff like multi-threaded programming, synchronisation, memory
management, caching, etc.

I am looking for an experienced developer who is willing to contribute
some reasonable amount of time towards this project. Someone with the
following sort of skills should be good enough.

Java Programming: 2 yr - 5 yr
C++ Programming: 6 Mo - 2 yr
Systems Programming: 2 yr - 5 yr

Let me know if you think you fit the bill.

Thanks
Raghu

 

[Roedy Green]

Here's what I expect from a contributor.

This may seem a fairly simple project, but check out how big the teams
and how much time various other JVMs were.

The JVM interpreter itself may be no big deal. The problem is the
thousands of native methods you have to write.

 

[lotusbud]

why developing a new one while there're plenty jvms already for use

i suppose this could be a huge project if you want to make it fully
functional as well as highly efficient

 

[jan V]

The JVM interpreter itself may be no big deal. The problem is the

thousands of native methods you have to write.

Just the interpreter itself is definitely not trivial. Are you forgetting
garbage collection and multi-threading? Anyone trying to create a **REAL**
JVM implementation and simply looking around in this newsgroup for
contributors seems to be a bit naive.

Many, many moons ago I was part of a 3-man team tasked with writing a clean
room implementation of Postscript (Level 1). It took us nearly a year to
arrive at something that could execute well-known Postscript programs.
Postscript, even with its graphics commands, is less complex than a JVM even
when we ignore any native code requirements. The OP is either looking at a
multi-year project (with "contributors" slaving away full time.. sure thing)
or he's going to become demoralized pretty soon.

 

[Chris Uppal]

Just the interpreter itself is definitely not trivial. Are you forgetting
garbage collection and multi-threading? Anyone trying to create a **REAL**
JVM implementation and simply looking around in this newsgroup for
contributors seems to be a bit naive.

While I agree that creating a "real", cutting edge, JVM is a highly non-trivial
bit of work (many man-years), it isn't clear that the OP is aiming that high.
A fairly simple JVM with GC, threads, and a naive bytecode interpreter
(implemented /as/ an interpreter) is well within reach of a hobbyist project --
I can think of several that already exist. For someone with experience of
generating/manipulating machine code for a specific architecture, a simple
JITer for that architecture should also be within reach.

Creating an entire /platform/ (with class library etc) is even more work --
which is presumably why even such well-endowed enterprises as IBM and Intel
have made use of the GNU Classpath library for that side of things. (Of
course, IBM's /main/ offerings aren't based on Classpath, but -- as far as I
can tell -- on sublicensing Sun's code)

-- chris

 

[jan V]

While I agree that creating a "real", cutting edge, JVM is a highly
non-trivial

bit of work (many man-years), it isn't clear that the OP is aiming that

high.

Whatever level he's aiming at, one would assume that there's a minimum
level: being able to run the minimalist "Hello World!" example. That means
being able load/link classes such as Object (which contains native stuff),
System (which contains native stuff), PrintStream, String, possibly
StringBuffer... all from an "off the shelf" RT.JAR and any associated DLLs
for the native stuff.

If he's not aiming to be able to run HelloWorld.java, then I really don't
see the point.

 

[jan V]

high.

Whatever level he's aiming at, one would assume that there's a minimum
level: being able to run the minimalist "Hello World!" example. That means
being able load/link classes such as Object (which contains native stuff),
System (which contains native stuff), PrintStream, String, possibly
StringBuffer... all from an "off the shelf" RT.JAR and any associated DLLs
for the native stuff.

Hmmm... doing a

% java -verbose:class HelloWorld

produces a distinct surplus of information to find out what the minimal set
of needed classes would be... :-(

 

[Chris Uppal]

That means
being able load/link classes such as Object (which contains native stuff),
System (which contains native stuff), PrintStream, String, possibly
StringBuffer... all from an "off the shelf" RT.JAR

Why on earth would anyone want to do that ? The DLLs and "system" jar files
are part of the platform implementation, not part of application-domain code.
It would be silly, from a system architecture POV (and probably not allowable
from a licensing POV -- though I haven't checked), to make use of those
resources in a third party JVM implementation.

That's what the GNU Classpath project is about (which I mentioned in my post);
Raghu has already said (on the SourceForge page) that he is intending to use
Classpath.

-- chris

 

[kkiran7]

Raghu,
I have been programming for over five years. My experience spans
various
Java technologies - J2EE/J2ME ( CDC/CLDC/MIDP ) and have written
native bridges for couple of projects. I do have quite a bit of C/C++
experience,
( ~ 1.5 years ) - mostly with high performance scientifc libraries.

However, i have quite a deep interest in compiler design, linkers
/loaders and
virtual systems ( like Java, Python, Forth ). I do the reading myself,
download
code, understand it with lot of passion. Yes , I did read VM spec to a
large extent.

My special interest would be in threading model and memory management.

And I can spend decent amount of time contributing towards the project.
Let
me know if I fit your bill

Thanks,
Kiran Kumar

 

[Raghu Kaippully]

jan V wrote:




Why on earth would anyone want to do that ? The DLLs and "system" jar files
are part of the platform implementation, not part of application-domain code.
It would be silly, from a system architecture POV (and probably not allowable
from a licensing POV -- though I haven't checked), to make use of those
resources in a third party JVM implementation.

That's what the GNU Classpath project is about (which I mentioned in my post);
Raghu has already said (on the SourceForge page) that he is intending to use
Classpath.

-- chris

OK. I was on a vacation for abt a week and couldn't reply till now.

As chris pointed out, I am planning to use GNU classpath. I DO NOT have
plans to implement Java API. I am interested only in JVM.

Now why I want to do this? Just for the sake of the challenge. I am not
aiming for a cutting edge VM; in fact, the first version may not even
have JIT, only an interpreted engine. Slowly, I might add features.

The OP is either looking at a
multi-year project (with "contributors" slaving away full time.. sure thing)
or he's going to become demoralized pretty soon.

jan V <[email protected]>

I have not set a deadline as to when I should "finish" the project. It
might well be a multi-year project, but I do not see how that implies
anyone working fulltime on this.

Its just a hobby project, I want to do this just coz I like it. The aim
is not to be the best JVM (in terms of features) available.

Raghu

 

[jan V]

Its just a hobby project, I want to do this just coz I like it. The aim

is not to be the best JVM (in terms of features) available.

I wish you all the best, and let's hope you use SourceForge or something
similar to let us track your progress.. it would be interesting to see
whether a hobby-driven team could succeed at this (I'm not prejudging!).