harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: timeframe for mid-level decissions
Date Thu, 19 May 2005 22:41:27 GMT

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:
>>
>
>
>>>
>>> -> 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.

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.

>
>
>>>
>>> -> 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.

Exactly.  Lets be forced into it, rather than assuming and diluting 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.

Oh, I see.  You said between runtimes, so I had some other model,  
such as peer-peer runtime or something, which didn't make a whole lot  
of sense to me.

>
>
>>>
>>> -> 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
> layouts.

Right - we're forming our identity as we do this.  Patience :)

>
>
>>>
>>> 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
> recompiled).
>
> 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, ...

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.

> * 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

Much more :)

geir

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

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message