You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Jakob Praher <jp...@yahoo.de> on 2005/05/18 22:29:55 UTC
timeframe for mid-level decissions
hi people,
first of all it's great to hear so much harmony for open source java!
Ever since I'm working with open source java software, I was dreaming of
a great open source java vm movement. Now given the amount of great
people involved here sounds it would truly be possible.
Now the reason why I write this mail, is that I'd like to see some
actual timelines put up and I would like to see a separation of the
philosophical (long-term) issues from implementation issues (tasks that
can be started assap).
The central point is:
When do you want the first Harmony J2SE alpha snapshots to reach the masses?
>From this central question, I think the tasks which are of highest priority:
-> Which VM(s) should be chosen? [this will be the hardest decision]
-> Should there be a compatibilty Layer between VMs (like the Classpath
VM classes)
IMHO it would be important to take a multi-layer approach:
A) A short term project (ship it early and improve it along the way)
B) A mid term project (use the huge amount of knowledge which is out
there in the vm projects and build on that)
Some "advices":
* First try to be conservative and build a VM based on what works now,
and try to gain people by actually having a VM that works quite good.
[ I don't think that building a VM in java is good for achieving that
results for now ]
* Stay close to the operating system - GCJ,LLVM,... - See
http://www.research.ibm.com/vee04/Boehm.pdf
I am currently working with LLVM as part of my diploma thesis and really
like it for its open possibilties (for other languages too) and for its
typed ssa risk-like ir specification. The compiler implementation is
also quite nice and it would give enough room to implement many features
and different runtimes [http://www.research.ibm.com/vee04/Grove.pdf] .
As a side node:
Also the LLVM guys are heavily thinking about implementing many
intrinsics based on APR and other core libraries. Sure there are many
things which have to be built yet (garbage collecter, memory model
(which is very low level right now) ...) but a llvm-java frontend is
arleady being worked on.
But to be clear - the message from my side: fix decision deadlines and
stick to them. build something, ship it early. This is the only way to make
*) testers/developers aware
*) gain ground in the VM cake
just some thoughts form my side.
-- Jakob
Re: timeframe for mid-level decissions
Posted by Jakob Praher <jp...@yahoo.de>.
Hi Renaud,
thanks for your response on the technical side. See my coments inline.
Renaud BECHADE wrote:
>
> ＞* Stay close to the operating system - GCJ,LLVM,... - See
> ＞ http://www.research.ibm.com/vee04/Boehm.pdf
>
> Especially as GCJ and LLVM (especially LLVM) are relatively fast, NOW.
> (I remember comparing some floating point test between gcc -O 10^8 and
> llvm-gcc + llvi. The llvm was damn fast on my machine - I think I had a 20%
> or 30% improvement, which is indeed quite good - so good as say the Intel
> compiler or so on Intel machines. That was a pity Objective-C was not
> available :-( )
Yeah its pretty agressive. Objective C is something which is very
intersting too - since they (apple) have one of the fastest dynamic
dispatch algorithms based on caching
[http://www.mulle-kybernetik.com/artikel/Optimization/opti-9.html].
>
> ＞As a side node:
> ＞Also the LLVM guys are heavily thinking about implementing many
> ＞intrinsics based on APR and other core libraries. Sure there are many
> ＞things which have to be built yet (garbage collecter, memory model
> ＞(which is very low level right now) ...) but a llvm-java frontend is
> ＞arleady being worked on.
>
> Since GCJ and GCC share the same code generator, and since GCC code
> generator has been ported to LLVM (with may-be heavy changes, though), why
> not just make sure a GCJ-LLVM-with-jit-plugin is developed, once GCJ gets
> some minimal support for java5 bytecode ("all-except-reflection")?
There are some things I'm working on as a side project for now. LLVM for
instance uses a different exception handling mechanism then GCC. But one
could work around this because LLVM has a very high level view of
exceptions (which is quite nice) - every invoke instruction has an
implicit catch target. So the way exceptions are actually implemented
can be user specific.
I personally see LLVM as a MIR but with the advantage of beeing well
specified. Jikes also has this sort of IR - but in LLVM you can see the
MIR as a kind of execution engine since it supports a type system and
has a well carried out binary representation. The binary representation
would help in many things for instance one could store optimizations in
the llvm bytecode format and reuse them later.
>From this side I'm also interesting in the c-- project which comes form
the ML/OCAML people. It is a very low level c representation, which
features continuations,exceptions, ... . [I haven't had time to look
through it carefully]
> So far as I know, LLVM enables or is scheduled to enable at-runtime LLVM
> bytecode generation (used for Ruby and Scheme interpreters I think[1]), so
> that we could have a cool JIT without the burden of actually generating
> low-level machine code (kind of a write once, run everywhere JIT).
So you mean a JIT that generates LLVM bytecode - please tell me more on
that.
Actually there is a interpreter and a jit in the cvs tree. The JIt
(called JELLO) is special since it works with the target machine code as
if it was in SSA form. I don't know how good/bad this is practice, I've
just read the paper from 2002. You can come a long way with the
interpreter alone since it is very low levelish - many of the
optimizations is already done in in the bytecode - which is not possible
for HIRs like Java - and the registers are in SSA form so you have
superb data flow information available at no cost.
> This kind of plan could also have the theoretical advantage of being able to
> release early and on a very big bunch of architectures code that /actually/
> works, and is kind-of used by default by many, many, many people (*BSD
> users, embedded systems, linux hackers, and so on).
Yes thats true. Such a system would be very interesting, since you can
extend the VM with LLVM bytecodes and reuse many aspects. There is also
a new wave of building secure systems based on Proof Carrying Codes.
(PCC). Since LLVM has typed instruction set and needs explicit casts to
do type conversion (cast instruction) - you can say whether a piece of
code is type safe or not. I don't know how hard it would be to add proof
carrying codes into the LLVM. But if that would be enabled, a whole new
interesting possibilties would arise. (extending the VM by PCC based
LLVM instructions).
[http://www.cs.nott.ac.uk/~fxr/papers/2004_scp/franz_scp.pdf]
-- Jakob
Re: timeframe for mid-level decissions
Posted by Jakob Praher <jp...@yahoo.de>.
I've put some corrections in, so that its more understandable.
Jakob Praher wrote:
> Geir Magnusson Jr. wrote:
>
>>On May 19, 2005, at 5:24 AM, Jakob Praher wrote:
>
>>
>>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.
To state it more clearly:
GCJ has a "copy" of classpath in its own tree. In former classpath and
gcj haven't worked that closely toghether. Most of the libjava classes
are 1:1 copies of the classpath classes. But for some high performance
classes / low level classes the gcj team rewrites them. This is a
problem if they want to merge the whole classpath tree in.
Why did I mention that: This is an example of the VMXxx classes to be to
high level - a faster implementation can be done if using CNI (the GCJ
native interface that uses C++ ABI).
-- Jakob
Re: timeframe for mid-level decissions
Posted by Jakob Praher <jp...@yahoo.de>.
hi David,
thanks for pointing that out. I haven't looked into the application but,
some notes from my side.
David Griffiths wrote:
> From the llvm web site: "LLVM does not currently support garbage
> collection of multi-threaded programs or GC-safe points other than
> function calls, but these will be added in the future as there is
> interest." I would imagine that's quite a lot of work.
>
First of all that is an issue regarding the existing llvm garbage
collector implementation not with the specification/bytecode stuff. So
its more or less an implementation detail.
AFAIK: GC-safe points are important for stop-the-world algorithms. There
are some papers around for implementing patching/polling to advance
another thread to a safe point (the one that triggers GC is already at a
safe point) = A safe point is a distinct point where GC is allowed or
"save" to happen.
So the problem really is multi-threaded apps (since safe points don't
matter for single threaded apps). The question is why they are facing
problems.
1) allocation is in principle the GC trigger
safepoints could be basic blocks that don't contain execution calls or
allocations.
2) Other problems with GC and multi threaded apps will have to be dealt
with (I don't think they are because the garbage collector is not thread
safe in its own respect - Such a thing could be simply worked around). I
will try to get into the details.
Given the amount of good papers and work in that area I don't think that
it is a too big problem to get worked out.
-- Jakob
Re: timeframe for mid-level decissions
Posted by David Griffiths <da...@gmail.com>.
>From the llvm web site: "LLVM does not currently support garbage
collection of multi-threaded programs or GC-safe points other than
function calls, but these will be added in the future as there is
interest." I would imagine that's quite a lot of work.
Cheers,
Dave
Re: timeframe for mid-level decissions
Posted by Jakob Praher <jp...@yahoo.de>.
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
Re: timeframe for mid-level decissions
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
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
RE: timeframe for mid-level decissions
Posted by Renaud BECHADE <re...@numerix.com>.
I like it.
＞* Work together with the GCJ people to build a really fast AOT-compiler
＞that also works with LLVM based Execution Engine
I which case we theoretically have a JIT at supposedly low cost...
(translating bytecode to bytecode /without having to optimize it/ is great)
I still like the plugin way this could be implemented. (one can
theoretically call LLVM and get called by LLVM)
There would still be a lot of work needed for the java5 apis, anyway.
RB
ーーーーーーーーーーーー
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.
Thanks
-- Jakob
Re: timeframe for mid-level decissions
Posted by Jakob Praher <jp...@yahoo.de>.
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
layouts.
>>
>> 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, ...
* 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.
Thanks
-- Jakob
Re: timeframe for mid-level decissions
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 19, 2005, at 5:24 AM, Jakob Praher wrote:
> Hi Leo,
>
> Leo Simons wrote:
>
>> Hi Jakob!
>>
>> On 18-05-2005 22:29, "Jakob Praher" <jp...@yahoo.de> wrote:
>>
>>
>>> When do you want the first Harmony J2SE alpha snapshots to reach
>>> the masses?
>>>
>>
>>
>> "when they're ready"
>>
>
> I think that the psychological aspect of having actual some
> milestones/deadlines helps sort out some of the long-term stuff
> from the
> short term hacking. Especially in VM technology there is so much
> great
> stuff out there - so many projects to build on - that you might never
> reach a point of concensus, if you only ship when everyone is happy
> with
> it. IMHO thinking about this "big picture" stuff helps sort out some
> infrastructure decisions:
>
> -> 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?
>
> -> 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.
>
> -> are the java specs anough for vm interoperability or should we add
> yet another interoperability layer between runtimes?
I don't understand
>
> -> 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".
>
> -> how much manpower is available in the early stages - that helps to
> clarify how broad the first aim would be?
That's coming together. It's been a week.
>
> Questions like that are essential for establishing the projects
> identity.
>
> 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.
>
> 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?
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: timeframe for mid-level decissions
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Jakob" == Jakob Praher <jp...@yahoo.de> writes:
>> 2. Performance. The result has to be reasonable competitive
>> performance wise. E.g., starting eclipse has to be reasonable both in
>> time and space.
Jakob> How are doing with gcj in this direction?
I'm not sure I understand. We do ok right now -- not great, but
competitive. We're starting to look at performance a bit more now
than we did in the past.
Jakob> IMHO harmony should be ably to understand the
Jakob> gcj abi and the so cache, which is right now at the very heart of gcj.
This is hard for the reasons outlined before.
Tom
Re: timeframe for mid-level decissions
Posted by Jakob Praher <jp...@yahoo.de>.
hi Tom,
Tom Tromey wrote:
>>>>>>"Jakob" == Jakob Praher <jp...@yahoo.de> writes:
>
>
> Jakob> do we want to build something that competes with sun j2se/mono on the
> Jakob> desktop side (gnome/redhat would be interested in that)
>
> I don't speak for Red Hat, but I can explain a little about why we
> ship gcj and not other VMs. In addition to all our in house history
> with gcc and gcj, it basically boils down to 3 things:
>
> 1. Platform coverage. The solution has to work on at least whatever
> platforms Fedora Core and RHEL work on.
>
> 2. Performance. The result has to be reasonable competitive
> performance wise. E.g., starting eclipse has to be reasonable both in
> time and space.
How are doing with gcj in this direction?
>
> 3. Debugging. There has to be some debugger story.
>
> Harmony would have to excel on all of these before I would even
> consider, say, recommending it for FC.
>
These are important points.
I think that the 2 platforms should be interoperable. So probably many
installations will use gcj soon.(at least if its the default for fedora)
Especially for UI stuff it would be really interesting to get
interoperability right. IMHO harmony should be ably to understand the
gcj abi and the so cache, which is right now at the very heart of gcj.
Perhaps a second implementation of that would lead to more specification
which would have positive results on gcj too.
-- Jakob
Re: timeframe for mid-level decissions
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
Tom Tromey wrote:
>
>3. Debugging. There has to be some debugger story.
>
>Harmony would have to excel on all of these before I would even
>consider, say, recommending it for FC.
>
>
This is an important point. If the VM should be usable for a developer
it must support debugging. If it is to be a viable alternative to Suns
VM for a developer (i.e. me at work) then it eventually should also
support hot swap of code.
I think I saw that SableVM supported debugging recently. Is there any
OpenSource VM that supports hot swap?
Re: timeframe for mid-level decissions
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Jakob" == Jakob Praher <jp...@yahoo.de> writes:
Jakob> do we want to build something that competes with sun j2se/mono on the
Jakob> desktop side (gnome/redhat would be interested in that)
I don't speak for Red Hat, but I can explain a little about why we
ship gcj and not other VMs. In addition to all our in house history
with gcc and gcj, it basically boils down to 3 things:
1. Platform coverage. The solution has to work on at least whatever
platforms Fedora Core and RHEL work on.
2. Performance. The result has to be reasonable competitive
performance wise. E.g., starting eclipse has to be reasonable both in
time and space.
3. Debugging. There has to be some debugger story.
Harmony would have to excel on all of these before I would even
consider, say, recommending it for FC.
Tom
Re: timeframe for mid-level decissions
Posted by Jakob Praher <jp...@yahoo.de>.
Hi Leo,
Leo Simons wrote:
> Hi Jakob!
>
> On 18-05-2005 22:29, "Jakob Praher" <jp...@yahoo.de> wrote:
>
>>When do you want the first Harmony J2SE alpha snapshots to reach the masses?
>
>
> "when they're ready"
I think that the psychological aspect of having actual some
milestones/deadlines helps sort out some of the long-term stuff from the
short term hacking. Especially in VM technology there is so much great
stuff out there - so many projects to build on - that you might never
reach a point of concensus, if you only ship when everyone is happy with
it. IMHO thinking about this "big picture" stuff helps sort out some
infrastructure decisions:
-> 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)
-> do we want to have different projects for different tasks (is that
effordable now - what is harmony then - a meta project?)
-> are the java specs anough for vm interoperability or should we add
yet another interoperability layer between runtimes?
-> 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?
-> how much manpower is available in the early stages - that helps to
clarify how broad the first aim would be?
Questions like that are essential for establishing the projects identity.
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.
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.
>
>
>>But to be clear - the message from my side: fix decision deadlines and
>>stick to them. build something, ship it early. This is the only way to make
>>*) testers/developers aware
>>*) gain ground in the VM cake
>
>
> Seriously, that works well when you can actually do resource planning. In
> volunteer efforts like this, we don't know what resources we have (esp. Not
> the human resources, ie developer hours to spend) so we can't have a
> deadline.
Ok. I don't meant that everybody should work for 24 hours to meet
deadlines. I see deadlines merely as some meta guidlines. For people to
orientate - for instance if I work on some big topics I soon get lost,
when I don't have any organisational structuring. This should help
people - not force them to work!
>
> Do you know any open source project friendly to volunteer participation that
> is able to fix then keep any kind of deadline? We don't do that at apache,
> it causes stress :)
Ok. I don't want to cause but rather relieve stress by decision making,
structuring and creating a project identity.
bye,
-- Jakob
RE: timeframe for mid-level decissions
Posted by Renaud BECHADE <re...@numerix.com>.
＞* Stay close to the operating system - GCJ,LLVM,... - See
＞ http://www.research.ibm.com/vee04/Boehm.pdf
Especially as GCJ and LLVM (especially LLVM) are relatively fast, NOW.
(I remember comparing some floating point test between gcc -O 10^8 and
llvm-gcc + llvi. The llvm was damn fast on my machine - I think I had a 20%
or 30% improvement, which is indeed quite good - so good as say the Intel
compiler or so on Intel machines. That was a pity Objective-C was not
available :-( )
＞I am currently working with LLVM as part of my diploma thesis and really
＞like it for its open possibilties (for other languages too) and for its
＞typed ssa risk-like ir specification. The compiler implementation is
＞also quite nice and it would give enough room to implement many features
＞and different runtimes [http://www.research.ibm.com/vee04/Grove.pdf] .
＞
＞As a side node:
＞Also the LLVM guys are heavily thinking about implementing many
＞intrinsics based on APR and other core libraries. Sure there are many
＞things which have to be built yet (garbage collecter, memory model
＞(which is very low level right now) ...) but a llvm-java frontend is
＞arleady being worked on.
Since GCJ and GCC share the same code generator, and since GCC code
generator has been ported to LLVM (with may-be heavy changes, though), why
not just make sure a GCJ-LLVM-with-jit-plugin is developed, once GCJ gets
some minimal support for java5 bytecode ("all-except-reflection")?
So far as I know, LLVM enables or is scheduled to enable at-runtime LLVM
bytecode generation (used for Ruby and Scheme interpreters I think[1]), so
that we could have a cool JIT without the burden of actually generating
low-level machine code (kind of a write once, run everywhere JIT).
This kind of plan could also have the theoretical advantage of being able to
release early and on a very big bunch of architectures code that /actually/
works, and is kind-of used by default by many, many, many people (*BSD
users, embedded systems, linux hackers, and so on).
Regards,
RB (fed up with Sun JDK weird open-source licensing that forces freebsd
users to download everything by hand...)
[1] sorry for any technical mistake.
-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Jakob Praher
Sent: Thursday, May 19, 2005 5:30 AM
To: harmony-dev@incubator.apache.org
Subject: timeframe for mid-level decissions
hi people,
first of all it's great to hear so much harmony for open source java!
Ever since I'm working with open source java software, I was dreaming of
a great open source java vm movement. Now given the amount of great
people involved here sounds it would truly be possible.
Now the reason why I write this mail, is that I'd like to see some
actual timelines put up and I would like to see a separation of the
philosophical (long-term) issues from implementation issues (tasks that
can be started assap).
The central point is:
When do you want the first Harmony J2SE alpha snapshots to reach the masses?
>From this central question, I think the tasks which are of highest priority:
-> Which VM(s) should be chosen? [this will be the hardest decision]
-> Should there be a compatibilty Layer between VMs (like the Classpath
VM classes)
IMHO it would be important to take a multi-layer approach:
A) A short term project (ship it early and improve it along the way)
B) A mid term project (use the huge amount of knowledge which is out
there in the vm projects and build on that)
Some "advices":
* First try to be conservative and build a VM based on what works now,
and try to gain people by actually having a VM that works quite good.
[ I don't think that building a VM in java is good for achieving that
results for now ]
* Stay close to the operating system - GCJ,LLVM,... - See
http://www.research.ibm.com/vee04/Boehm.pdf
I am currently working with LLVM as part of my diploma thesis and really
like it for its open possibilties (for other languages too) and for its
typed ssa risk-like ir specification. The compiler implementation is
also quite nice and it would give enough room to implement many features
and different runtimes [http://www.research.ibm.com/vee04/Grove.pdf] .
As a side node:
Also the LLVM guys are heavily thinking about implementing many
intrinsics based on APR and other core libraries. Sure there are many
things which have to be built yet (garbage collecter, memory model
(which is very low level right now) ...) but a llvm-java frontend is
arleady being worked on.
But to be clear - the message from my side: fix decision deadlines and
stick to them. build something, ship it early. This is the only way to make
*) testers/developers aware
*) gain ground in the VM cake
just some thoughts form my side.
-- Jakob
Re: timeframe for mid-level decissions
Posted by Leo Simons <ma...@leosimons.com>.
Hi Jakob!
On 18-05-2005 22:29, "Jakob Praher" <jp...@yahoo.de> wrote:
> When do you want the first Harmony J2SE alpha snapshots to reach the masses?
"when they're ready"
> But to be clear - the message from my side: fix decision deadlines and
> stick to them. build something, ship it early. This is the only way to make
> *) testers/developers aware
> *) gain ground in the VM cake
Seriously, that works well when you can actually do resource planning. In
volunteer efforts like this, we don't know what resources we have (esp. Not
the human resources, ie developer hours to spend) so we can't have a
deadline.
Do you know any open source project friendly to volunteer participation that
is able to fix then keep any kind of deadline? We don't do that at apache,
it causes stress :)
Cheers!
Leo