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? --Jakob
