harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Praher <jpra...@yahoo.de>
Subject Re: timeframe for mid-level decissions
Date Thu, 19 May 2005 12:18:20 GMT
Geir Magnusson Jr. wrote:
> On May 19, 2005, at 5:24 AM, Jakob Praher wrote:

>> -> do we want to concentrate on the server side (jikes rvm would
>> probably be fine for that) - for instance: no startup issues
>> -> do we want to build something that competes with sun j2se/mono  on the
>> desktop side (gnome/redhat would be interested in that)
> Both of these are conventional expectations, and we can meet this via 
> pluggability, right?
Depends on the divergence of the 2 systems. If for instance you have 2
vms (eg. one in jave for server and one in c/c++ for client then IMHO it
would be better to make two separate projects). These two vms wouldn't
have much in common.

>> -> do we want to have different projects for different tasks (is that
>> effordable now - what is harmony then - a meta project?)
> Not now - right now, I think we stick close together until we start 
> getting big.  This *will* get big, but I think that the structure 
> should be driven over time.
This sounds promising :-). Sticking close together is what I'd like to
see. Don't get too diverse now.

>> -> are the java specs anough for vm interoperability or should we add
>> yet another interoperability layer between runtimes?
> I don't understand
Take classpath project. It aims at working accross open vms. So you have
to build a glue layer between what is intrinsic to the vm and what is
expressable in plain java. Classpath has VM classes which are
implemented by the different VMs (mostly public static and often native
stuff), that gets called from within Classpath, so per VM you only have
to reimplement the VM classes. It has pros and cons, if you proceed like
this. For Classpath its the only way to meet the goal of implementing a
whole runtime without knowing exact details of the VM. On the other hand
projects like gcj, which have c++ abi for performance reason for most of
the core classes (I mean the really core stuff) - they currently have
libjava - where the whole classpath - but also would like to use the
classpath java classes without importing them into libjava (for code
management and stuff) where appropriate. Appropriate here means that the
gcj project makes the trade of towards performance (at least that was
the result of FOSDEMs discussion) if they have to decide.

>> -> should we just be a forum for vm implementors and should we specify
>> cross vm stuff (like the gnu.gcj.RawData class) in terms of  enhancement
>> requests?
> I think that we clearly want to implement, but it's not a bad place  for
> "enhancement", as long as we are clear that enhancement doesn't  mean
> distortion of the standard, or "extending".
Ok. It's only for me to get an understanding of the projects identity.
Yes thats probably true especially since we - as opposed to the closed
source vms - don't have business interest in keeping secrets about inner

>> I think the best projects (in that area) are those, that have a  special
>> goal and don't want to be all things to all people. I don't know which
>> way harmony is going here.
> I think we have a goal, and I do think it's important that we hear 
> about alternative paths to get there.  I do agree that such  discussions
> can't go on forever, and hence the pushing to start  looking at some of
> the existing VMs (both in C and Java).  I'm really  hoping we can focus
> a little on that, how we can find ways to couple  cleanly to GNU
> Classpath, etc.
That's true. Perhaps I'm a little too eager - I have seen a lot of
projects in the past.
>> You might disagree here - but i think that this project is a bit
>> different from other apache projects. Many things completly depend on
>> the initial decisions. So I don't want to see all people waiting for
>> some technical decision to take place and thus deadlock their efforts.
>> At the same the possibily matrix is so huge that you can't take into
>> account every project thats going on. So again: Make some  decissions in
>> the next months and go for that. Sure the project is in its infancy  - I
>> don't want to push too much.
> Right. Where do you stand on current VMs to look at or language?

As I've posted, I think we should stick close to the indiviual target
platforms (Unix,Win32,...) and build on stuff that works quite well (no
java in java stuff). In recent time, I am  a big fan of the LLVM
project, since it is a very well defined base line. And I think that
having a good foundation, like:
-> MIR (intermediate representation to do optimizations in)
-> Bytecode format to store optimizations in
-> Powerful and extensible type system (to map non-java types)

would be needed to make a really scalable implementation.
Be sure to look at the next generation java stuff, when chosing a VM -
dynamic invokation is coming in Dolphin and XML types are coming too!

I have played much with gcj and like it - especially the interoperabilty
with the OS and the new ABI is really nice - something which should be
implemented for any VM (as a linkage model). But GCJ, since its an ahead
of time compiler is not well suited for JITting - though you can change
the target (changing vptr) - it is more harder to optimze the call-site
easily. (which has to changed to a mutable area first and then could get

So my interest would be: LLVM + definition of memory model (Is Doug Lea
on this list?) + pluggable garbage collector (Boehm is good enough for
now (and probably for the future too).

On the other hand vms like sable or kaffee is interesting too. A very
nice strucuted vm (many stuff is in shared libraries).

So some advices from my humble side:

* Use a LLVM Exectuion Engine as the VM (the specs = IR + type system +
bytecode format are most interesting to me - The compiler and runtime
can be reimplemented to use conform to these)
* Use APR as an instrincs for threads, shared memory, ...
* Define a GCJ/Java compliant exception handling on top of LLVM
* Define a Java compliant Memory Model on top of the LLVM to Javas
Memory Model would be important.
* Work together with the GCJ people to build a really fast AOT-compiler
that also works with LLVM based Execution Engine
* Build different Runtime Linkages (Like GCJ compliant ABIs, Dynamic
dispatched ones -> It's coming to Java in 1.7, Javas internal)
* Be able to load GCJ shared objects and use them (FAST!)
* Much more

Then we have a good change of getting there on the client side and on
the server side, with many opportunities for the future.

-- Jakob

View raw message