harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryce Leo <likwidoxi...@gmail.com>
Subject Re: JIRA and SVN
Date Fri, 20 May 2005 01:55:01 GMT
> - JCVM is maybe the VM as I would have written it : it's pure C, quite easy,
> and yet focus on bringing good speed. The interp loop is well optimized but
> not very defensive : that means that a hole in the bytecode loader verifier
> could lead to a forged bytecode exploit. It doesn't do JIT, and instead
> generate C from .class and then call GCC and dynload the binary : that
> requires a lot of libraries and might not be the approach Harmony want.
> Also, I'm a bit worried about C code portability : does it compile and run
> on Win32 using MS compiler for example ?

I agree completely on that. After we strip away what we don't want, it
looks like we'd be left with a relatively small, but capable framework
to build upon. This is also to our benefit because newer programmers
(which we clearly have a good number of, which is great to see) would
be able to get up to speed relatively quickly.

I believe that the more complex JikesRVM has some great concepts and
that we could work with that through incorporating their ideas in the
Harmony code. I mention the complexity because we have some new and
relatively new programmers, and certainly a few new to VM's (as I
would be one of them) and that the simpler code base would help out
greatly in how quickly contributions could come in. This may or may
not be an issue, if it's not then that's fine but I feel that a larger
developer base is going to be needed even if it sacrifices the initial
starting point for the project.

> compared to a good JIT written in pure C however. As a framework, it seems
> to contain several compilers, maybe focusing on one main implementation
> would be better.

Strangely I think that the multiple compiler theory of Jikes is a
great idea, it allows work to be divided up smoothly and seems to
allow for a reasonable level of plugablity so if a group wanted to
work on a re-implementation it wouldn't be terribly difficult.

 
> So my choice would be to go for either a stripped JCVM and add JIT to it (it
> should already work with interpreted, so the JIT can be written in Java or
> C) or for a stripped Jikes that - while keeping the framework architecture

I think that this is a valid approach and gives a solid base while
leaving flexibility for growth.


-- 
~Bryce Leo


--Veritas Vos Liberabis--

Mime
View raw message