harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Archie Cobbs <arc...@dellroad.org>
Subject Re: [arch] The Third Way : C/C++ and Java and lets go forward
Date Mon, 23 May 2005 23:00:25 GMT
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/%3c4288F308.9000502@dellroad.org%3e

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com

Mime
View raw message