Geir Magnusson Jr. wrote:
JamVM is optimized for size (and succeeds incredibly well at that),
not necessarily completeness. For example, I don't think that it
supports class loader unloading or soft/weak/phantom references (Robert
please correct me if this is wrong). Those are non-trivial bits to
have to design and write from scratch, and retro-fitting them into
an existing VM could potential require significant rework.
Are you suggesting we do it w/ JC? :) Is there a single copyright
holder such
I'll have to abstain from the voting on that :-) Really I'm just
trying to add some perspective from my experience. Implementing the
soft/weak/phantom reference stuff required major surgery on JC's
garbage collector. And I know that class unloading can also be
a major headache if the VM does not carefully track all the implicit
references between class loaders. I haven't inspected JamVM so can't
say how hard it might be to add that stuff.. hopefully it would be
easy.. it's just something to think about in any case.
I guess what I was thinking was that we start with a small VM kernel in
C/C++ and refactor and build the modules in C/C++ and Java, as we can.
I didn't want to appear to be proclaiming that JamVM is "it", but
rather a small kernel to start with , start refactoring, and start
doing the modularization work in both C and Java.
Would JCVM meet these criterion? More importantly, would you consider
a donation?
The intent isn't to fork or "be" JamVM or JCVM, but really reuse the
core as a base. I would guess that in a short period of time, we'll
make it be completely different than what was donated.
That approach makes sense to me. As pointed out before, JC is available
license-wise [1]. My guess is that at minimum there are some useful
bits that can immediately used.
I'd also consider using some of the good ideas (mostly from SableVM)
that JC implements, if not the actual code. For example, per-class loader
memory areas, bidirectional object layout, and the threading state
management. The latter in particular is a bug-prone area that has already
been carefully thought out by Etienne Gagnon.
My suggestion (if I may be so bold) is for people to look at some
of the ideas that are out there, represented not only in research
papers but also in actual implementations, and start making a wish
list of "that's cool, we should do it that way!" items. This list can
be debated etc. and a vague form will emerge. E.g. per-loader memory
is an obvious choice IMHO (it makes class unloading a heck of a lot
easier, to circle back to the original point...).
To the extent that these ideas agree with JC's code base, harmony
is welcome to embrace & extend any or all of it.
-Archie
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200505.mbox/[EMAIL PROTECTED]
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
