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 Sat, 21 May 2005 07:53:42 GMT
hi Geir,

Geir Magnusson Jr. wrote:
> On May 19, 2005, at 8:18 AM, Jakob Praher wrote:
>> Geir Magnusson Jr. wrote:
>>> On May 19, 2005, at 5:24 AM, Jakob Praher wrote:
>>> Both of these are conventional expectations, and we can meet this via
>>> pluggability, right?

If you have for instance completly different object layouts, caching
mechanisms, method lookup, then pluggablity becomes difficult. We are
talking about high performance stuff - so it should't get too much
wrapping - except for #ifdefs (also jikes rvm has this sort of stuff in
java :-)).
One thing that should be in common are the intermediate representations
- see below.

What would be interesting is to implement method lookup based on
hashing (java signatures are strings as well), with inline caching based
on hashes (not vtables) and then compare the result with a vtable
approach, which in Java must also be built at load time. The
self/smalltalk/... community has proven that this can be done quite
efficient and gives you a whole lot of flexibility - speaking of "hot
swapping" for instance, or implementing scripting langauge on top of it.

>> 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.
> That's sort of true. :)
> I'd agree that they would be separate efforts, but there's no reason 
> why they couldn't be in the same Apache Harmony community.  For 
> example, look at the Apache Logging communty- there are alternate 
> language implementations of the same functionality.
> I'd want to keep things close, as we do want to be able to share things.
Yes thats sort of clear. Since its likely that harmony is becoming
top-level project, these projects should definitely go under the
"harmony roof".

What I was trying to say with LLVM is that you could implement exactly
that. You have a spec, a MIR, ... . So you implement one VM/Compiler in
Java and the other in C/C++ - you get the advantage of sticking to the
same specs and could also reuse some of the portions - for instance the
dynamic compiler, after the C implementation has bootstrapped the VM and
set up the execution environment, it can compile itself using in Java.
This also works with other MIRs. But to make sure: Build on something
that was already specified nicely (like LLVM for instance) and extend
that specs to fix things. (More evolutionary). I think starting with a
whole new IR spec and stuff would be much work.

>> 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
>> layouts.
> Right - we're forming our identity as we do this.  Patience :)

> I want to use APR to *implement* our platform interfacing layer, but  I
> have no idea if APR is the right *definition* of the API for OS 
> interfacing.  I'd rather not presume an API until we understand  what's
> required by the VM.
Ok. APR is quite interesting as a low level abstraction layer. And its
favourable because it is a very low layer. Too much abstraction from the
OS is probably more problematic then having some modules implemented for
different OSes clearly.
> Much more :)
Yes, much more is in my head.

counter question:
What's your favorable VM technology - I've heard on the list that a VM
might be contributed - what should that mean?


View raw message