Re: [dev-tools] was Re: Against using Java to implement Java (Was: Java)

[FaeLLe]

So have to agree with Mark...

Making a JVM in a .NET language this deserves a . LOL

Sorry if i sound out of order had to do it :s

On 5/19/05, Mark Brooks <[EMAIL PROTECTED]> wrote:
> 
> >If we are going to entertain writing most of the JVM in a type-safe
> >language, we should also consider the proposed ECMA C++/CLI. From
> >what I understand, it standardizes a form of type-safe C++. It has
> >the promise of keeping both the Java and C camps happy.
> 
> Not really. First, it is a Microsoft thing, tied in with .NET. Second, we
> don't want to have to depend on a .NET runtime to get a Java runtime.
> Third, never try to implement a large and complex existing project in a
> brand new technology.
> 
> _
> Express yourself instantly with MSN Messenger! Download today - it's FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> 
> 


-- 
www.FaeLLe.com 

[dev-tools] was Re: Against using Java to implement Java (Was: Java)

[Mark Brooks]

If we are going to entertain writing most of the JVM in a type-safe
language, we should also consider the proposed ECMA C++/CLI.  From
what I understand, it standardizes a form of type-safe C++.  It has
the promise of keeping both the Java and C camps happy.
Not really.  First, it is a Microsoft thing, tied in with .NET.  Second, we 
don't want to have to depend on a .NET runtime to get a Java runtime.  
Third, never try to implement a large and  complex existing project in a 
brand new technology.

_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Against using Java to implement Java (Was: Java)

[Stefano Mazzocchi]

Steve Blackburn wrote:

> Keeping a leading-edge
> JVM at the leading edge is a lot of work---this is a fast moving field.

Yes and I don't think anybody believes that is likely to go away even if
we manage to get Harmony off the ground.

At the same time, Apache shows in a number of project how distributed,
parallel collaboration, lazy consensus and incremental evolution can
normally lead to a more organic and optimized evolution of a software
project, means that it might not have the same amount of energy injected
in the system as a commercial venture, but being its efficiency higher,
the result can potentially be even faster than commercial venues.

For more info on why this is, see my presentation at OSCON04 on
"darwinian software development"

http://www.betaversion.org/~stefano/papers/oscon2004.pdf

-- 
Stefano.

Re: Against using Java to implement Java (Was: Java)

[Steve Blackburn]

Very interesting.  Please point me to the web pages that show
SpecJAppServer/JBB/JVM... numbers for Jikes.
 

I don't have a pointer for you.  Jikes RVM numbers appear on shudo's 
page.  Unfortunately the IA32 performance is not stellar.  It was not 
that long ago that Jikes RVM was competitive with the IBM's commercial 
VM on PPC, but as you probably know the commercial VM's have been 
improving in leaps and bounds.  Dave Grove has outlined a number of 
improvements to the opt compiler which should give us a big boost.  We 
just don't have the legs to do it ourselves...  Keeping a leading-edge 
JVM at the leading edge is a lot of work---this is a fast moving field.

I see some mention of "magic types".   Does this work around the java
verifier by coercing a reference pointer into a Java int and
vice-versa?  This could be done by calling a non-verifiable chunk of
code written in Java.  Something like "Object int2ref(int x);" and
"int ref2obj(Object z)".  The net result sort of "C++-izes" java
without having to modify the language.
 

The use of the magic types is limited to VM code.  This is currently 
unenforced in Jikes RVM, but should be.

If we are going to entertain writing most of the JVM in a type-safe
language, we should also consider the proposed ECMA C++/CLI.  From
what I understand, it standardizes a form of type-safe C++.  It has
the promise of keeping both the Java and C camps happy.
Regarding the inlining of assembly in the JIT.  You point out that
this code can be written in Java then fed to the JIT.  Do you see any
reason why this code can not be written in C/C++, C#, etc?
 

Yes.  The advantage we're getting is that there is no impedence mismatch 
between the user code and the language in which the barriers etc are 
expressed in (both are Java).   Thus the JIT can trivially inline the 
barrier and optimize it, disolving any artificial boundary between user 
and VM code.  This depends entirely on the VM implementation lanaguage 
and the source language being the same (Java in our case).  Does this 
make sense?  You may find it useful to read our ICSE paper on building 
MMTk in Java.  The paper is dated now, but the key ideas remain unchanged.

Cheers,
--Steve

On 5/18/05, Steve Blackburn <[EMAIL PROTECTED]> wrote:
 

Hi Weldon,
It seems we have similar experiences with modularity, you in ORP, me in
Jikes RVM and MMTk.
   

Elaborating on a previous comment about inlining allocation/write
barrier sequences.  First design step: the GC team hand optimizes an
assembly sequence while making sure the functionality is absolutely
correct.  Second step: the JIT team blindly inlines the GC team's
assembly code and starts doing performance analysis.  Third step: the
JIT team integrates the inline sequence(s) into the IR so that all the
optimizations can be performed.  Perhaps these steps are the same for
both a JVM written in Java as well as C/C++.
 

No.  It is as I stated in the post to which you were responding.  In
MMTk, we express the barriers and allocation sequences in Java and then
the opt compiler inlines them and optimizes them.  The first Jikes RVM
collectors used assembler for the barriers, but we transitioned to
expressing them in Java a long time ago.  This gives us much greater
expressibility on the GC side of the fence, greater portability (MMTk is
totally architecture neutral),  and better performance because it
presents better opportunities for optimization to the compiler (constant
folding etc etc).
   

I am curious if a JVM written in Java must break type-safety.   Does
anyone know? For example, the "new" bytecode will need to manipulate
(gasp!) raw "C" pointers.  In specific, Java code will need to
scribble on free memory to slice off "X" untyped bytes and return a
raw pointer to the base of chunk of memory.  Then the java code will
need to use the raw pointer to install stuff like a vtable pointer.
Once the object is setup, the Java code can revert to running code
that can actually be verified.  Also does anyone know the current
state of research on formally proving a GC written in Java is
type-safe?
 

Yes.  We put a lot of work into making MMTk type safe.  Type safety is
key.  Perry Cheng was the person who initially did all the hard work on
this.
We have introduced new magic types for Address (think void*), Word
(think "32 or 64 bit unsigned values"), ObjectReference (abstract notion
of a refernce to an object, could in principle be a handle, for Jikes
RVM it is an Address), etc etc.  Each of these looks like a heavyweight
regular Java type, but our compiler "knows" about them and folds them
into primitives.  The fact that we *do* preserve type safety is what
allows the opt compiler to be as agressive as it is in compiling across
barriers and allocations.  I've provided pointers to this previously.
Jnode has been using these magic types for a while now (for the same
reasons).
http://jikesrvm.sourceforge.net/api/org/vmmagic/unboxed/package-summary.html
I would like (n

Re: Against using Java to implement Java (Was: Java)

[Weldon Washburn]

Steve,

Very interesting.  Please point me to the web pages that show
SpecJAppServer/JBB/JVM... numbers for Jikes.

I see some mention of "magic types".   Does this work around the java
verifier by coercing a reference pointer into a Java int and
vice-versa?  This could be done by calling a non-verifiable chunk of
code written in Java.  Something like "Object int2ref(int x);" and
"int ref2obj(Object z)".  The net result sort of "C++-izes" java
without having to modify the language.

If we are going to entertain writing most of the JVM in a type-safe
language, we should also consider the proposed ECMA C++/CLI.  From
what I understand, it standardizes a form of type-safe C++.  It has
the promise of keeping both the Java and C camps happy.

Regarding the inlining of assembly in the JIT.  You point out that
this code can be written in Java then fed to the JIT.  Do you see any
reason why this code can not be written in C/C++, C#, etc?



On 5/18/05, Steve Blackburn <[EMAIL PROTECTED]> wrote:
> Hi Weldon,
> 
> It seems we have similar experiences with modularity, you in ORP, me in
> Jikes RVM and MMTk.
> 
> >Elaborating on a previous comment about inlining allocation/write
> >barrier sequences.  First design step: the GC team hand optimizes an
> >assembly sequence while making sure the functionality is absolutely
> >correct.  Second step: the JIT team blindly inlines the GC team's
> >assembly code and starts doing performance analysis.  Third step: the
> >JIT team integrates the inline sequence(s) into the IR so that all the
> >optimizations can be performed.  Perhaps these steps are the same for
> >both a JVM written in Java as well as C/C++.
> >
> >
> No.  It is as I stated in the post to which you were responding.  In
> MMTk, we express the barriers and allocation sequences in Java and then
> the opt compiler inlines them and optimizes them.  The first Jikes RVM
> collectors used assembler for the barriers, but we transitioned to
> expressing them in Java a long time ago.  This gives us much greater
> expressibility on the GC side of the fence, greater portability (MMTk is
> totally architecture neutral),  and better performance because it
> presents better opportunities for optimization to the compiler (constant
> folding etc etc).
> 
> >I am curious if a JVM written in Java must break type-safety.   Does
> >anyone know? For example, the "new" bytecode will need to manipulate
> >(gasp!) raw "C" pointers.  In specific, Java code will need to
> >scribble on free memory to slice off "X" untyped bytes and return a
> >raw pointer to the base of chunk of memory.  Then the java code will
> >need to use the raw pointer to install stuff like a vtable pointer.
> >Once the object is setup, the Java code can revert to running code
> >that can actually be verified.  Also does anyone know the current
> >state of research on formally proving a GC written in Java is
> >type-safe?
> >
> >
> Yes.  We put a lot of work into making MMTk type safe.  Type safety is
> key.  Perry Cheng was the person who initially did all the hard work on
> this.
> 
> We have introduced new magic types for Address (think void*), Word
> (think "32 or 64 bit unsigned values"), ObjectReference (abstract notion
> of a refernce to an object, could in principle be a handle, for Jikes
> RVM it is an Address), etc etc.  Each of these looks like a heavyweight
> regular Java type, but our compiler "knows" about them and folds them
> into primitives.  The fact that we *do* preserve type safety is what
> allows the opt compiler to be as agressive as it is in compiling across
> barriers and allocations.  I've provided pointers to this previously.
> Jnode has been using these magic types for a while now (for the same
> reasons).
> 
> http://jikesrvm.sourceforge.net/api/org/vmmagic/unboxed/package-summary.html
> 
> I would like (not now, I need to run) to discuss different notions of
> modularity and modular design.  We have approached it very differently
> to you and I think it would be profitable for us all to share our thoughts.
> 
> Cheers,
> 
> --Steve
>

Re: Against using Java to implement Java (Was: Java)

[Steve Blackburn]

Hi Weldon,
It seems we have similar experiences with modularity, you in ORP, me in 
Jikes RVM and MMTk.

Elaborating on a previous comment about inlining allocation/write
barrier sequences.  First design step: the GC team hand optimizes an
assembly sequence while making sure the functionality is absolutely
correct.  Second step: the JIT team blindly inlines the GC team's
assembly code and starts doing performance analysis.  Third step: the
JIT team integrates the inline sequence(s) into the IR so that all the
optimizations can be performed.  Perhaps these steps are the same for
both a JVM written in Java as well as C/C++.
 

No.  It is as I stated in the post to which you were responding.  In 
MMTk, we express the barriers and allocation sequences in Java and then 
the opt compiler inlines them and optimizes them.  The first Jikes RVM 
collectors used assembler for the barriers, but we transitioned to 
expressing them in Java a long time ago.  This gives us much greater 
expressibility on the GC side of the fence, greater portability (MMTk is 
totally architecture neutral),  and better performance because it 
presents better opportunities for optimization to the compiler (constant 
folding etc etc).

I am curious if a JVM written in Java must break type-safety.   Does
anyone know? For example, the "new" bytecode will need to manipulate
(gasp!) raw "C" pointers.  In specific, Java code will need to
scribble on free memory to slice off "X" untyped bytes and return a
raw pointer to the base of chunk of memory.  Then the java code will
need to use the raw pointer to install stuff like a vtable pointer. 
Once the object is setup, the Java code can revert to running code
that can actually be verified.  Also does anyone know the current
state of research on formally proving a GC written in Java is
type-safe?
 

Yes.  We put a lot of work into making MMTk type safe.  Type safety is 
key.  Perry Cheng was the person who initially did all the hard work on 
this.

We have introduced new magic types for Address (think void*), Word 
(think "32 or 64 bit unsigned values"), ObjectReference (abstract notion 
of a refernce to an object, could in principle be a handle, for Jikes 
RVM it is an Address), etc etc.  Each of these looks like a heavyweight 
regular Java type, but our compiler "knows" about them and folds them 
into primitives.  The fact that we *do* preserve type safety is what 
allows the opt compiler to be as agressive as it is in compiling across 
barriers and allocations.  I've provided pointers to this previously.  
Jnode has been using these magic types for a while now (for the same 
reasons).

http://jikesrvm.sourceforge.net/api/org/vmmagic/unboxed/package-summary.html
I would like (not now, I need to run) to discuss different notions of 
modularity and modular design.  We have approached it very differently 
to you and I think it would be profitable for us all to share our thoughts.

Cheers,
--Steve

Re: Against using Java to implement Java (Was: Java)

[Weldon Washburn]

On 5/18/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> 
> On May 18, 2005, at 9:36 AM, Steve Blackburn wrote:
> 
> > This subject has been covered in detail at least twice already.
> >
> > There is no need for any function call on the fast path of the
> > allocation sequence.  In a Java in Java VM the allocation sequence
> > is inlined into the user code.  This has considerable advantages
> > over "a few lines of assembler".  Aside from the obvious advantage
> > of not having to express your allocator in assembler, using Java
> > also compiles to better code since the code can be optimized in
> > context (register allocation, constant folding etc), producing much
> > better code than hand crafted assembler.
> >
> > However this is small fry compared to the importance of compiling
> > write barriers correctly (barriers are used by most high
> > performance GCs and are executed far more frequently than
> > allocations).  The same argument applies though.  The barrier
> > expressed in Java is inlined insitu, and the optimizing compiler is
> > able to optimize in context.
> >
> > Modularization does not imply any of this.
> 
> I assume you mean that Modularization is orthogonal to this - that
> they are independent aspects?

Modularization always interacts with performance.  I believe empirical
evidence suggests that the performance impact of splitting out the JIT
and GC as separate modules is in the noise.  I suspect the internal
JVM support for java.lang.Thread, java.lang.Object can also be split
off as a separate module with very little performance impact.  It
might even be possible to include java.util.concurrent support in the
same threads module.

Elaborating on a previous comment about inlining allocation/write
barrier sequences.  First design step: the GC team hand optimizes an
assembly sequence while making sure the functionality is absolutely
correct.  Second step: the JIT team blindly inlines the GC team's
assembly code and starts doing performance analysis.  Third step: the
JIT team integrates the inline sequence(s) into the IR so that all the
optimizations can be performed.  Perhaps these steps are the same for
both a JVM written in Java as well as C/C++.

I am curious if a JVM written in Java must break type-safety.   Does
anyone know? For example, the "new" bytecode will need to manipulate
(gasp!) raw "C" pointers.  In specific, Java code will need to
scribble on free memory to slice off "X" untyped bytes and return a
raw pointer to the base of chunk of memory.  Then the java code will
need to use the raw pointer to install stuff like a vtable pointer. 
Once the object is setup, the Java code can revert to running code
that can actually be verified.  Also does anyone know the current
state of research on formally proving a GC written in Java is
type-safe?
 
> 
> geir
> 
> >
> > --Steve
> >
> >
> > Weldon Washburn wrote:
> >
> >
> >> On 5/18/05, David Griffiths <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>> I think it's too slow to have the overhead of a function call for
> >>> every object allocation. This is the cost of modularization. I doubt
> >>> any of the mainstream JVMs you are competing with do this.
> >>>
> >>>
> >> Yes.  I agree.  A clean interface would have a function call for
> >> every
> >> object allocation.  However if the allocation code itself is only a
> >> few lines of assemby, it can be inlined by the JIT.  Using a moving
> >> GC, it is possible to get the allocation sequence down to a bump the
> >> pointer and a compare to see if you have run off the end of the
> >> allocation area.
> >>
> >>
> >
> >
> 
> --
> Geir Magnusson Jr  +1-203-665-6437
> [EMAIL PROTECTED]
> 
> 
>

Re: Against using Java to implement Java (Was: Java)

[Geir Magnusson Jr.]

Or post to the dev list first so everyone can see it, and then take a  
summary to the wiki.

On May 18, 2005, at 2:43 PM, Davanum Srinivas wrote:
Weldon,
One way to handle this is to write something up on the wiki
(http://wiki.apache.org/harmony/) and ask people to comment and then
incorporate the comments back. So that we have a record of the
discussion and the conclusions. Yes, we need to stick to harmony-dev
for now.
Thanks,
dims
On 5/18/05, Weldon Washburn <[EMAIL PROTECTED]> wrote:
On 17 May 2005 18:27:42 -0600, Tom Tromey <[EMAIL PROTECTED]> wrote:
"David" == David Griffiths <[EMAIL PROTECTED]> writes:
David> Maybe a concrete example would help. Let's say you have a  
GC module
David> written in C. One of it's API calls is to allocate a new  
object. How
David> is your JIT module going to produce code to use that API?  
Via a C
David> function pointer?

Yes.
One way is to mandate link- or compile-time pluggability only.  Then
this can be done by name.  Your JIT just references
'&harmony_allocate_object' in its source and uses this pointer
in the code it generates.
The other way is to have the JIT call some central function to get a
pointer to the allocator function (or functions, in libgcj it turned
out to be useful to have several).  This only needs to be done once,
at startup.
For folks interested in pluggability, I advise downloading a copy of
ORP and reading through it.  ORP already solved these problems in a
fairly reasonable way.
Thanks.  I am more than willing to respond to questions about ORP.
Since ORP was last posted to open source, I have done some additional
thinking about interfaces as well as JVM and .NET design in general.
I really look forward to discussing these ideas.  It would be  
great if
we can quickly get to the point where we can discuss interface
details.  For example, I would like to start a detailed discussion on
JIT and GC interface header files.  Should we start this on the
general harmony-dev list?
Weldon


Tom



--
Davanum Srinivas - http://webservices.apache.org/~dims/

--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Against using Java to implement Java (Was: Java)

[Geir Magnusson Jr.]

On May 18, 2005, at 1:24 PM, Weldon Washburn wrote:
Thanks.  I am more than willing to respond to questions about ORP.
Since ORP was last posted to open source, I have done some additional
thinking about interfaces as well as JVM and .NET design in general.
I really look forward to discussing these ideas.  It would be great if
we can quickly get to the point where we can discuss interface
details.  For example, I would like to start a detailed discussion on
JIT and GC interface header files.  Should we start this on the
general harmony-dev list?
You mean here?  yes!
geir
Weldon

Tom


--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Against using Java to implement Java (Was: Java)

[Geir Magnusson Jr.]

On May 18, 2005, at 9:36 AM, Steve Blackburn wrote:
This subject has been covered in detail at least twice already.
There is no need for any function call on the fast path of the  
allocation sequence.  In a Java in Java VM the allocation sequence  
is inlined into the user code.  This has considerable advantages  
over "a few lines of assembler".  Aside from the obvious advantage  
of not having to express your allocator in assembler, using Java  
also compiles to better code since the code can be optimized in  
context (register allocation, constant folding etc), producing much  
better code than hand crafted assembler.

However this is small fry compared to the importance of compiling  
write barriers correctly (barriers are used by most high  
performance GCs and are executed far more frequently than  
allocations).  The same argument applies though.  The barrier  
expressed in Java is inlined insitu, and the optimizing compiler is  
able to optimize in context.

Modularization does not imply any of this.
I assume you mean that Modularization is orthogonal to this - that  
they are independent aspects?

geir
--Steve
Weldon Washburn wrote:

On 5/18/05, David Griffiths <[EMAIL PROTECTED]> wrote:

I think it's too slow to have the overhead of a function call for
every object allocation. This is the cost of modularization. I doubt
any of the mainstream JVMs you are competing with do this.

Yes.  I agree.  A clean interface would have a function call for  
every
object allocation.  However if the allocation code itself is only a
few lines of assemby, it can be inlined by the JIT.  Using a moving
GC, it is possible to get the allocation sequence down to a bump the
pointer and a compare to see if you have run off the end of the
allocation area.



--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Against using Java to implement Java (Was: Java)

[Davanum Srinivas]

Weldon,

One way to handle this is to write something up on the wiki
(http://wiki.apache.org/harmony/) and ask people to comment and then
incorporate the comments back. So that we have a record of the
discussion and the conclusions. Yes, we need to stick to harmony-dev
for now.

Thanks,
dims

On 5/18/05, Weldon Washburn <[EMAIL PROTECTED]> wrote:
> On 17 May 2005 18:27:42 -0600, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > > "David" == David Griffiths <[EMAIL PROTECTED]> writes:
> >
> > David> Maybe a concrete example would help. Let's say you have a GC module
> > David> written in C. One of it's API calls is to allocate a new object. How
> > David> is your JIT module going to produce code to use that API? Via a C
> > David> function pointer?
> >
> > Yes.
> >
> > One way is to mandate link- or compile-time pluggability only.  Then
> > this can be done by name.  Your JIT just references
> > '&harmony_allocate_object' in its source and uses this pointer
> > in the code it generates.
> >
> > The other way is to have the JIT call some central function to get a
> > pointer to the allocator function (or functions, in libgcj it turned
> > out to be useful to have several).  This only needs to be done once,
> > at startup.
> >
> > For folks interested in pluggability, I advise downloading a copy of
> > ORP and reading through it.  ORP already solved these problems in a
> > fairly reasonable way.
> 
> Thanks.  I am more than willing to respond to questions about ORP.
> Since ORP was last posted to open source, I have done some additional
> thinking about interfaces as well as JVM and .NET design in general.
> I really look forward to discussing these ideas.  It would be great if
> we can quickly get to the point where we can discuss interface
> details.  For example, I would like to start a detailed discussion on
> JIT and GC interface header files.  Should we start this on the
> general harmony-dev list?
> Weldon
> 
> >
> > Tom
> >
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: Against using Java to implement Java (Was: Java)

[Tom Tromey]

> "Steve" == Steve Blackburn <[EMAIL PROTECTED]> writes:

Steve> There is no need for any function call on the fast path of the
Steve> allocation sequence.
[ ... ]

Steve> However this is small fry compared to the importance of compiling
Steve> write barriers correctly (barriers are used by most high performance
Steve> GCs and are executed far more frequently than allocations).
[ ... ]

Steve> Modularization does not imply any of this.

I wanted to mention a few things on what modularity is not.

Just because we have some tunable knob, it does not imply that we must
support all possible settings of that knob.  And, likewise, we are not
compelled to support every possible combination of settings of all the
knobs.  Finally, modularity does not imply that all aspects of the VM
will be selectable at runtime.  It is completely reasonable to require
compile-time choices.

So, in this case, it isn't as if we would have to design an allocation
interface that allows all possible choices.  It can merely allow the
subset we know to be immediately usable.

Tom

Re: Against using Java to implement Java (Was: Java)

[Weldon Washburn]

On 17 May 2005 18:27:42 -0600, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > "David" == David Griffiths <[EMAIL PROTECTED]> writes:
> 
> David> Maybe a concrete example would help. Let's say you have a GC module
> David> written in C. One of it's API calls is to allocate a new object. How
> David> is your JIT module going to produce code to use that API? Via a C
> David> function pointer?
> 
> Yes.
> 
> One way is to mandate link- or compile-time pluggability only.  Then
> this can be done by name.  Your JIT just references
> '&harmony_allocate_object' in its source and uses this pointer
> in the code it generates.
> 
> The other way is to have the JIT call some central function to get a
> pointer to the allocator function (or functions, in libgcj it turned
> out to be useful to have several).  This only needs to be done once,
> at startup.
> 
> For folks interested in pluggability, I advise downloading a copy of
> ORP and reading through it.  ORP already solved these problems in a
> fairly reasonable way.

Thanks.  I am more than willing to respond to questions about ORP. 
Since ORP was last posted to open source, I have done some additional
thinking about interfaces as well as JVM and .NET design in general. 
I really look forward to discussing these ideas.  It would be great if
we can quickly get to the point where we can discuss interface
details.  For example, I would like to start a detailed discussion on
JIT and GC interface header files.  Should we start this on the
general harmony-dev list?
Weldon

> 
> Tom
>

Re: Against using Java to implement Java (Was: Java)

[David Griffiths]

I know, but despite the subject line my original point was about the
problem of modularizing a VM written in C.

Cheers,

Dave

On 5/18/05, Steve Blackburn <[EMAIL PROTECTED]> wrote:
> This subject has been covered in detail at least twice already.
> 
> There is no need for any function call on the fast path of the
> allocation sequence.  In a Java in Java VM the allocation sequence is
> inlined into the user code.  This has considerable advantages over "a
> few lines of assembler".  Aside from the obvious advantage of not having
> to express your allocator in assembler, using Java also compiles to
> better code since the code can be optimized in context (register
> allocation, constant folding etc), producing much better code than hand
> crafted assembler.
> 
> However this is small fry compared to the importance of compiling write
> barriers correctly (barriers are used by most high performance GCs and
> are executed far more frequently than allocations).  The same argument
> applies though.  The barrier expressed in Java is inlined insitu, and
> the optimizing compiler is able to optimize in context.
> 
> Modularization does not imply any of this.
> 
> --Steve
> 
> 
> Weldon Washburn wrote:
> 
> >On 5/18/05, David Griffiths <[EMAIL PROTECTED]> wrote:
> >
> >
> >>I think it's too slow to have the overhead of a function call for
> >>every object allocation. This is the cost of modularization. I doubt
> >>any of the mainstream JVMs you are competing with do this.
> >>
> >>
> >Yes.  I agree.  A clean interface would have a function call for every
> >object allocation.  However if the allocation code itself is only a
> >few lines of assemby, it can be inlined by the JIT.  Using a moving
> >GC, it is possible to get the allocation sequence down to a bump the
> >pointer and a compare to see if you have run off the end of the
> >allocation area.
> >
> >
>

Re: Against using Java to implement Java (Was: Java)

[Steve Blackburn]

This subject has been covered in detail at least twice already.
There is no need for any function call on the fast path of the 
allocation sequence.  In a Java in Java VM the allocation sequence is 
inlined into the user code.  This has considerable advantages over "a 
few lines of assembler".  Aside from the obvious advantage of not having 
to express your allocator in assembler, using Java also compiles to 
better code since the code can be optimized in context (register 
allocation, constant folding etc), producing much better code than hand 
crafted assembler.

However this is small fry compared to the importance of compiling write 
barriers correctly (barriers are used by most high performance GCs and 
are executed far more frequently than allocations).  The same argument 
applies though.  The barrier expressed in Java is inlined insitu, and 
the optimizing compiler is able to optimize in context.

Modularization does not imply any of this.
--Steve
Weldon Washburn wrote:
On 5/18/05, David Griffiths <[EMAIL PROTECTED]> wrote:
 

I think it's too slow to have the overhead of a function call for
every object allocation. This is the cost of modularization. I doubt
any of the mainstream JVMs you are competing with do this.
   

Yes.  I agree.  A clean interface would have a function call for every
object allocation.  However if the allocation code itself is only a
few lines of assemby, it can be inlined by the JIT.  Using a moving
GC, it is possible to get the allocation sequence down to a bump the
pointer and a compare to see if you have run off the end of the
allocation area.
 

Re: Against using Java to implement Java (Was: Java)

[Weldon Washburn]

On 5/18/05, David Griffiths <[EMAIL PROTECTED]> wrote:
> I think it's too slow to have the overhead of a function call for
> every object allocation. This is the cost of modularization. I doubt
> any of the mainstream JVMs you are competing with do this.
Yes.  I agree.  A clean interface would have a function call for every
object allocation.  However if the allocation code itself is only a
few lines of assemby, it can be inlined by the JIT.  Using a moving
GC, it is possible to get the allocation sequence down to a bump the
pointer and a compare to see if you have run off the end of the
allocation area.
> 
> Cheers,
> 
> Dave
> 
> On 17 May 2005 18:27:42 -0600, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > > "David" == David Griffiths <[EMAIL PROTECTED]> writes:
> >
> > David> Maybe a concrete example would help. Let's say you have a GC module
> > David> written in C. One of it's API calls is to allocate a new object. How
> > David> is your JIT module going to produce code to use that API? Via a C
> > David> function pointer?
> >
> > Yes.
> >
> > One way is to mandate link- or compile-time pluggability only.  Then
> > this can be done by name.  Your JIT just references
> > '&harmony_allocate_object' in its source and uses this pointer
> > in the code it generates.
> >
> > The other way is to have the JIT call some central function to get a
> > pointer to the allocator function (or functions, in libgcj it turned
> > out to be useful to have several).  This only needs to be done once,
> > at startup.
> >
> > For folks interested in pluggability, I advise downloading a copy of
> > ORP and reading through it.  ORP already solved these problems in a
> > fairly reasonable way.
> >
> > Tom
> >
>

Re: Against using Java to implement Java (Was: Java)

[Ben Laurie]

David Griffiths wrote:
By having the JIT produce code to inline the object allocation using
its knowledge of the GC internals. I'm not recommending this approach,
just saying that this is how things tend to be done in practice. And
if you want to compete on speed then you're going to have to address
the issue. (This seems to be an area where Java in Java wins if I
understand it right, ie you can have your modularity cake and eat it
too).
Well, inlining stuff sometimes makes things faster (though it sometimes 
doesn't). But I'd be seriously surprised if object allocation was simple 
enough to make it worthwhile.

I do take the point, however, that using dispatch tables without 
embellishment does preclude inlining.

It doesn't take me a huge leap to imagine including a function in the 
dispatch table that would do inlining instead of finding the appropriate 
function, though.

Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Re: Against using Java to implement Java (Was: Java)

[David Griffiths]

By having the JIT produce code to inline the object allocation using
its knowledge of the GC internals. I'm not recommending this approach,
just saying that this is how things tend to be done in practice. And
if you want to compete on speed then you're going to have to address
the issue. (This seems to be an area where Java in Java wins if I
understand it right, ie you can have your modularity cake and eat it
too).

Cheers,

Dave

On 5/18/05, Ben Laurie <[EMAIL PROTECTED]> wrote:
> David Griffiths wrote:
> > I think it's too slow to have the overhead of a function call for
> > every object allocation. This is the cost of modularization. I doubt
> > any of the mainstream JVMs you are competing with do this.
> 
> How do you propose to allocate objects without function calls?
> 
> --
> http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
> 
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
>

Re: Against using Java to implement Java (Was: Java)

[Ben Laurie]

David Griffiths wrote:
I think it's too slow to have the overhead of a function call for
every object allocation. This is the cost of modularization. I doubt
any of the mainstream JVMs you are competing with do this.
How do you propose to allocate objects without function calls?
--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Re: Against using Java to implement Java (Was: Java)

[Royce Ausburn]

I think it's too slow to have the overhead of a function call for
every object allocation. This is the cost of modularization. I doubt
any of the mainstream JVMs you are competing with do this.
Given how java (Apple JVM on OS X tiger) seems to allocate a chunk of  
memory when you first load it and only occasionally reallocate more  
if I'm using alot of memory, I'd say that it gets around that  
'external function call overhead' by allocating memory into its  
internal heap and then using native (pure java) code to manage the  
VM's memory.  I've no idea though - I'm interested now!

How do they do it?
--Royce

Re: Against using Java to implement Java

[David Griffiths]

Well that's the theory but I think you'll find in practice that real
JITs cheat and inline object allocation using their knowledge of the
GC internals.

And there is no way that a JIT is going to implement synchronized
methods by doing a "monitorEnter" function call!

Dave

On 5/18/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> There is an old document describing a JIT interface though ORP should
> be more advanced, for example, as having GC interface.
> 
>   The JIT Compiler Interface Specification
>   http://java.sun.com/docs/jit_interface.html
> 
> Sun's Classic VM, which was a reference VM, of JDK 1.0.2 and 1.1.X
> implements this interface and it was modified a bit for J2SDK 1.2.
> There were actually multiple JIT compilers based on this JIT interface
> including Symantec JIT, OpenJIT, shuJIT and TYA.
> 
> This interface is not enough to support advanced optimizations
> including adaptive compilation, which today's Sun's and IBM's runtimes
> do.  Adaptive compilation needs cooperation by an interpreter (or a
> baseline compiler) and I am not sure whether it can be factored out
> from the JVM core.
> 
> From: Tom Tromey <[EMAIL PROTECTED]>
> 
> > David> Maybe a concrete example would help. Let's say you have a GC module
> > David> written in C. One of it's API calls is to allocate a new object. How
> > David> is your JIT module going to produce code to use that API? Via a C
> > David> function pointer?
> >
> > Yes.
> >
> > One way is to mandate link- or compile-time pluggability only.  Then
> > this can be done by name.  Your JIT just references
> > '&harmony_allocate_object' in its source and uses this pointer
> > in the code it generates.
> >
> > The other way is to have the JIT call some central function to get a
> > pointer to the allocator function (or functions, in libgcj it turned
> > out to be useful to have several).  This only needs to be done once,
> > at startup.
> >
> >
> > For folks interested in pluggability, I advise downloading a copy of
> > ORP and reading through it.  ORP already solved these problems in a
> > fairly reasonable way.
> 
>   Kazuyuki Shudo[EMAIL PROTECTED]  http://www.shudo.net/
>

Re: Against using Java to implement Java (Was: Java)

[David Griffiths]

I think it's too slow to have the overhead of a function call for
every object allocation. This is the cost of modularization. I doubt
any of the mainstream JVMs you are competing with do this.

Cheers,

Dave

On 17 May 2005 18:27:42 -0600, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > "David" == David Griffiths <[EMAIL PROTECTED]> writes:
> 
> David> Maybe a concrete example would help. Let's say you have a GC module
> David> written in C. One of it's API calls is to allocate a new object. How
> David> is your JIT module going to produce code to use that API? Via a C
> David> function pointer?
> 
> Yes.
> 
> One way is to mandate link- or compile-time pluggability only.  Then
> this can be done by name.  Your JIT just references
> '&harmony_allocate_object' in its source and uses this pointer
> in the code it generates.
> 
> The other way is to have the JIT call some central function to get a
> pointer to the allocator function (or functions, in libgcj it turned
> out to be useful to have several).  This only needs to be done once,
> at startup.
> 
> For folks interested in pluggability, I advise downloading a copy of
> ORP and reading through it.  ORP already solved these problems in a
> fairly reasonable way.
> 
> Tom
>

Re: Against using Java to implement Java

[shudo]

There is an old document describing a JIT interface though ORP should
be more advanced, for example, as having GC interface.

  The JIT Compiler Interface Specification
  http://java.sun.com/docs/jit_interface.html

Sun's Classic VM, which was a reference VM, of JDK 1.0.2 and 1.1.X
implements this interface and it was modified a bit for J2SDK 1.2.
There were actually multiple JIT compilers based on this JIT interface
including Symantec JIT, OpenJIT, shuJIT and TYA.

This interface is not enough to support advanced optimizations
including adaptive compilation, which today's Sun's and IBM's runtimes
do.  Adaptive compilation needs cooperation by an interpreter (or a
baseline compiler) and I am not sure whether it can be factored out
from the JVM core.


From: Tom Tromey <[EMAIL PROTECTED]>

> David> Maybe a concrete example would help. Let's say you have a GC module
> David> written in C. One of it's API calls is to allocate a new object. How
> David> is your JIT module going to produce code to use that API? Via a C
> David> function pointer?
>
> Yes.
>
> One way is to mandate link- or compile-time pluggability only.  Then
> this can be done by name.  Your JIT just references
> '&harmony_allocate_object' in its source and uses this pointer
> in the code it generates.
>
> The other way is to have the JIT call some central function to get a
> pointer to the allocator function (or functions, in libgcj it turned
> out to be useful to have several).  This only needs to be done once,
> at startup.
>
>
> For folks interested in pluggability, I advise downloading a copy of
> ORP and reading through it.  ORP already solved these problems in a
> fairly reasonable way.


  Kazuyuki Shudo[EMAIL PROTECTED]   http://www.shudo.net/

Re: Against using Java to implement Java (Was: Java)

[Tom Tromey]

> "David" == David Griffiths <[EMAIL PROTECTED]> writes:

David> Maybe a concrete example would help. Let's say you have a GC module
David> written in C. One of it's API calls is to allocate a new object. How
David> is your JIT module going to produce code to use that API? Via a C
David> function pointer?

Yes.

One way is to mandate link- or compile-time pluggability only.  Then
this can be done by name.  Your JIT just references
'&harmony_allocate_object' in its source and uses this pointer
in the code it generates.

The other way is to have the JIT call some central function to get a
pointer to the allocator function (or functions, in libgcj it turned
out to be useful to have several).  This only needs to be done once,
at startup.


For folks interested in pluggability, I advise downloading a copy of
ORP and reading through it.  ORP already solved these problems in a
fairly reasonable way.

Tom

Re: Against using Java to implement Java (Was: Java)

[Geir Magnusson Jr.]

On May 17, 2005, at 5:51 AM, David Griffiths wrote:
Maybe a concrete example would help. Let's say you have a GC module
written in C. One of it's API calls is to allocate a new object. How
is your JIT module going to produce code to use that API? Via a C
function pointer?
This is a good example of what I was trying to get at.  We'll need to  
decide on one standard way that things interoperate, and let those  
who which implementation freedom to deal with the impedance match.

geir
Dave
On 5/16/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:

I'd only be happy here if the performance hit to cross "framework"
and "module implementation" boundaries was borne by the *module*, not
the framework, so that we can get fast implementations via
homogeneous implementation language and let anyone who wants to use
other languages bear the cost of marshaling across the boundary.
if we aren't performant, it won't be interesting to users and
innovators.
geir
--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]


--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Against using Java to implement Java (Was: Java)

[David Griffiths]

Maybe a concrete example would help. Let's say you have a GC module
written in C. One of it's API calls is to allocate a new object. How
is your JIT module going to produce code to use that API? Via a C
function pointer?

Dave

On 5/16/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:

> I'd only be happy here if the performance hit to cross "framework"
> and "module implementation" boundaries was borne by the *module*, not
> the framework, so that we can get fast implementations via
> homogeneous implementation language and let anyone who wants to use
> other languages bear the cost of marshaling across the boundary.
> 
> if we aren't performant, it won't be interesting to users and
> innovators.
> 
> geir
> 
> --
> Geir Magnusson Jr  +1-203-665-6437
> [EMAIL PROTECTED]
> 
>

Re: Against using Java to implement Java (Was: Java)

[Geir Magnusson Jr.]

On May 13, 2005, at 1:30 PM, Stefano Mazzocchi wrote:
Ben Laurie wrote:
As I've said before, I'd like to see a framework that _allows_  
most of the VM to be run in Java (or Python, or Perl, or Erlang,  
or whatever-floats-your-boat), but doesn't require it.

Yes, I think this is the most sensible compromise.
I would agree in making this one of our high level requirements for  
Harmony's architecture.
I'd only be happy here if the performance hit to cross "framework"  
and "module implementation" boundaries was borne by the *module*, not  
the framework, so that we can get fast implementations via  
homogeneous implementation language and let anyone who wants to use  
other languages bear the cost of marshaling across the boundary.

if we aren't performant, it won't be interesting to users and  
innovators.

geir
--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Against using Java to implement Java (Was: Java)

[Geir Magnusson Jr .]

On May 12, 2005, at 11:26 PM, Kev Jackson wrote:



So speak up project lead(s).  We are here.  We are talking a lot,  
but not much is happening.  Order us about.  Assign work.  Let's  
get our hands dirty.  The likelihood is that there will be changes  
along the way anyhow.  There almost always are, and developers  
dedicated to the project will simply have to adapt.


couldn't agree more, the more 'talking' happening here, the less  
progress seems to be made.  The guys rant on bile blog had some  
points about people here talking and waiting for a code drop from  
IBM/Sun/whoever.  I'd like to help on this I really would, but I  
need a direction, what are we doing here?  Is it a glue classpath  
to kaffe to xxx?  Is it a write everything from scratch?  If we  
want to get started we need some code, without it we're just  
wasting everyone's time

It's been one (1) week.  There's been lots of good conversation.  We  
have lots of things to explore.  I wouldn't force the issue right  
now.  I'm happy to go w/ C/C++ or Java.  I just want to understand  
the trade-offs.

I'd like to be sure that :
a) this is modular
b) that it's *fast*
c) that it's maintainable
d) that it's portable
I've seen both Java and C++/C codebases that satisfy a - d :)
I'm hoping that we can start looking at a small modular VM - even  
just a toy implementation that we can hook to GNU Classpath through  
an interfacing API that we judge to be sufficient for any  
implementation of VM _or_ class library.

geir
--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Against using Java to implement Java (Was: Java)

[Geir Magnusson Jr.]

On May 13, 2005, at 3:58 AM, Ben Laurie wrote:
Mark Brooks wrote:
I hope you use C to write the VM for Harmony.
The chief objection I have to using C to write the VM is that it  
introduces a host of common errors and delays associated with  
using C or C++ for large products.  C is an excellent language for  
its purposes, but this isn't 1972.  Java was created to resolve a  
number of problems that arose from the ever-growing design of C++,  
which I swear is rapidly becoming the new PL/1.  We could use a  
restricted subset of C++ I guess, but a lot of "gee-whiz" features  
would have to be left out to assure cross-platform compatibility.   
So why not use Java?

One of the reasons why not, from my POV, is because it runs so  
badly on most platforms. If you happen to use Windows, Solaris or  
Linux(? I don't, so I don't know) you may be happy developing in  
Java. Anywhere else, its a PITA.

I've tried to sell C++ in the ASF many times. Even back when it  
wasn't quite so bloated as it is now it wasn't a popular idea. Far  
fewer people can write C++ than C, and hardly any of those can  
write _good_ C++.
I used to write good C++ (or so I thought :)
I'm happy dusting off C++ and using it again.
So, I think we'll end up back at C. As I've said before, I'd like  
to see a framework that _allows_ most of the VM to be run in Java  
(or Python, or Perl, or Erlang, or whatever-floats-your-boat), but  
doesn't require it.
Right.  And I really probably can't handle doing everything in C.  It  
will be like banging rocks together :)

But I think that this will be something we are led to by what gets  
donated, or what we start playing with, rather than setting out the  
direction before-hand

geir
--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Against using Java to implement Java (Was: Java)

[Geir Magnusson Jr .]

On May 13, 2005, at 5:06 AM, Matthew French wrote:

But it seems to me the reason behind the wide range of alternate  
VM's is
because each of these has a specific niche to fill. If Harmony is  
intended
to bring these efforts together, then I would think that some  
"bloat" is
inevitable. Not performance bloat, mind you, just added complexity.

I'd like to figure out if this can be solved with modularity - if  
there are needs that can be met with just configuration of parts  
rather than needs for a whole VM.

The problem is, I don't know :)
geir
--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Against using Java to implement Java (Was: Java)

[Robin Garner]

> Hi,
>
>> I'd be interested in hearing more from Steve on how well that works
within JikesRVM. From reading some papers on the web, it seems that the
MMTk has been ported to other, non-Java runtimes as well, and I guess
that this binding-vm-components-via-java-interfaces problem has been
efficiently solved by other bright people already outside the
pure-java-runtime space.
>
> Actually Robin Garner is the expert, as he wrote his honors thesis on
the subject.  http://eprints.anu.edu.au/archive/2397/  (MMTk was
previously known as JMTk---we dropped the 'J' to reflect our goals of
language neutrality).

There's also a precis paper available from here:

http://www.cs.adelaide.edu.au/~wossa2004/HTML/07-garner-1.pdf

As Steve says, the key to getting good performance in a mixed-language
environment is to minimise the frequency of crossing the language
boundary.  Also, unless you use conservative GC (with the attendant
performance issues) you need to minimise sharing of complex data
structures in order to allow copying collection.

The reason I keep emphasising copying collection is newly emerging results
like this:

http://cs.anu.edu.au/~Steve.Blackburn/pubs/papers/oor-oopsla-2004.pdf

which essentially shows that copying collection can be used to improve
locality and increase performance.  If harmony is to be the best available
optimizing JVM, then techniques like these will be necessary.

cheers
Robin

Re: Against using Java to implement Java (Was: Java)

[Ben Laurie]

Ian Darwin wrote:
I suppose that for porting issues, a C-based bootstrap VM for platforms 
that don't have an existing VM could be used, but I think that would be 
more of a future project.  For now, I suspect that the primary target 
platforms for Harmony are those currently supported by Sun, primarily *nix 
and Windows, although I think we should definitely expand to include OS X, 
if that is possible.

I disagree; my main interest in Harmony is for platforms that Sun does NOT support.
Like all the BSD platforms. 
Exactly.
--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Re: Against using Java to implement Java (Was: Java)

[Steve Blackburn]

Hi,
I'd be interested in hearing more from Steve on how well that works 
within JikesRVM. From reading some papers on the web, it seems that 
the MMTk has been ported to other, non-Java runtimes as well, and I 
guess that this binding-vm-components-via-java-interfaces problem has 
been efficiently solved by other bright people already outside the 
pure-java-runtime space. 
Actually Robin Garner is the expert, as he wrote his honors thesis on 
the subject.  http://eprints.anu.edu.au/archive/2397/  (MMTk was 
previously known as JMTk---we dropped the 'J' to reflect our goals of 
language neutrality).

The short answer is that it is easy enough to compile up the bulk of 
MMTk into a library using gcj.  However, for fine-grained interactions 
(not an issue with a compiler, but a real issue with write barriers and 
allocation sequences), one really does not want to go through a C->Java 
transition each time.  What one really wants is for the barrier and 
allocation fast paths to be compiled into the user application code.  In 
a Java-in-Java system, this happens naturally and automatically (since 
both the user app and the barrier are in Java and the compiler can 
inline the barrier code trivially).  Otherwise it is a little harder to 
make this perform well.  Exactly how one would approach it would depend 
on how the compiler dealt with allocation sequences and barriers.

As to the broader issue of componentization etc, here's a very brief 
overview.   I will try to get a better technical write up available to 
everyone soon...

The model is that MMTk has a reasonably well defined public interface, 
which we think of in loose software engineering terms as its "features" 
and "requirements", where the features are a much larger set than the 
requirements.  Likewise the host VM has features and requirements with 
regards to memory management.  We then build adaptors in each direction, 
satisfying the MM requirments with that VM's features, and satisfying 
the VM requirements with that MM's features.  That glue code is 
critical, but actually fairly modest.  This is how Jikes RVM and MMTk 
interact today, adn also how Rotor and (soon) jnode glue into MMTk too.  
The glue code can be written under whatever license you like.  You then 
just link your VM against MMTk.  The key to all of this (and this really 
is the key!) is that the core of MMTk is strictly VM neutral and has no 
VM-specific code in it whatsoever.  This VM neutral core is clearly 
separated, with all VM-specific code falling under a separate 
sub-package (org.mmtk.vm) with well defined dummy classes.  This means 
MMTk is never "ported", rather one just writes a suitable adaptor.  The 
above only works once one has got the abstractions right.

I hope this helps.
--Steve

Re: Against using Java to implement Java (Was: Java)

[Mark Brooks]

Isn't it a good idea to write the first implementation in a functional
programming language (read the wizard book)? That's what these
platforms are designed for and the constructs are there to help in
designing the thing. Then when you're happy you know what's good and
bad you can re-code it in something that actually runs fast. I'm aware
of a reasonable amount of literature that talks about GC and
interpretation techniques that uses languages such as ML and Scheme.
Somebody else mentioned Erlang (because of its concurrency support?), and I 
mentioned Ocaml, which is an ML variant.

I think your idea is a good one, but I don't think that will happen.  First, 
there's an entrenched base of people who think a declarative programming 
style is just weird, period.  They don't like it and don't want to do it.  
Then there'd be the issue of what functional programming language to use.  
At the end of the day, you have to have enough hands to do the work, and you 
would be surprised how many willing workers have never had exposure to 
functional programming.

If we were to go the route of writing the prototype in a functional 
programming language, I'd suggest ANSI Common Lisp.  There are a lot of 
LISPers out there (and Schemers), and LISP has features that make bottom-up 
rapid development very doable.  There are a lot of free and open-source 
Common LISP implementations as well.  SBCL, CMU-CL, CLISP, GCL, OpenMCL, 
blah blah blah, and of course there's the commercial stuff like Allegro CL 
and LispWorks.  With its macro facility, ACL codebases can become their own 
lanaguages.

ML/Ocaml is good too.  I'd actually recommend Ocaml over ML because it has 
seen actual commercial use in Europe (although SML has been used in 
England).

I don't know enough about Erlang.  Clean looks interesting, and Mozart looks 
pretty interesting too, but then we are getting into niche languages that 
almost nobody who would be interested in this project would know that much 
about.

Heck, prototype it with Jython. :)
Compiled Java initially seems as good as anything, but don't those
compilers add in their own brand of GC? Wouldn't that be an overhead
we neiter need nor want? Do we want to generate our own native
compiler? I'm thinking the best native compiler/language to use is
probably C.
We've got people here from Redhat, so they are probably thinking that 
provide a back-end to GCJ would fit that need.

I agree that most of the libraries can be written in Java, but
wouldn't that constitute a separate apache project, just like GNU
Classpath? The VM should probably be as clean as a very clean thing...
in a clean room.. (hence why I never mentioned C++ :)
I suspect that since we need both to pass the TCK, we will have two projects 
in one.  I think that the class libraries will be the bigger part of the 
work.

_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Against using Java to implement Java (Was: Java)

[Fernando Lozano]

Ian,
I guess the current state of GCJ, Kaffe and SableVM should be enough for 
bootstraping harmony on BSD. Did you tried any of these?

[]s, Fernando Lozano
I suppose that for porting issues, a C-based bootstrap VM for platforms 
that don't have an existing VM could be used, but I think that would be 
more of a future project.  For now, I suspect that the primary target 
platforms for Harmony are those currently supported by Sun, primarily *nix 
and Windows, although I think we should definitely expand to include OS X, 
if that is possible.
   

I disagree; my main interest in Harmony is for platforms that Sun does NOT support.
Like all the BSD platforms. 

 

Re: Against using Java to implement Java (Was: Java)

[Ian Darwin]

> I suppose that for porting issues, a C-based bootstrap VM for platforms 
> that don't have an existing VM could be used, but I think that would be 
> more of a future project.  For now, I suspect that the primary target 
> platforms for Harmony are those currently supported by Sun, primarily *nix 
> and Windows, although I think we should definitely expand to include OS X, 
> if that is possible.

I disagree; my main interest in Harmony is for platforms that Sun does NOT 
support.
Like all the BSD platforms. 

Re: Against using Java to implement Java (Was: Java)

[Mark Brooks]

It doesn't matter where the problem lies, the point is that I can't develop 
on the platforms I need/want to develop on.
My reply wasn't intended to be dismissive.  I'm short on details.  What 
platforms are you referring to?  Even a slow base VM can be an adequate 
bootstrap VM to create the initial Harmony install, and thereafter you use 
Harmony.

I suppose that for porting issues, a C-based bootstrap VM for platforms that 
don't have an existing VM could be used, but I think that would be more of a 
future project.  For now, I suspect that the primary target platforms for 
Harmony are those currently supported by Sun, primarily *nix and Windows, 
although I think we should definitely expand to include OS X, if that is 
possible.

Again, the project leads can probably say more about what the plan is there.
_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Against using Java to implement Java (Was: Java)

[Stefano Mazzocchi]

Ben Laurie wrote:
As I've said before, I'd like to see 
a framework that _allows_ most of the VM to be run in Java (or Python, 
or Perl, or Erlang, or whatever-floats-your-boat), but doesn't require it.
Yes, I think this is the most sensible compromise.
I would agree in making this one of our high level requirements for 
Harmony's architecture.

--
Stefano.

Re: Against using Java to implement Java (Was: Java)

[Davanum Srinivas]

Sounds great Robin. So what the the problems (if any) with JikesRVM?
how would one go about making it enterprise-ready (to use a well-worn
cliche)?

thanks,
dims

On 5/12/05, Robin Garner <[EMAIL PROTECTED]> wrote:
> > I hope you use C to write the VM for Harmony.
> >
> > The reason is, that I think, that the best is, if Harmony is nearly 100%
> > compatible to Suns Java.
> >
> > If you write the VM in Java itself, then there existing some problems:
> > 1. you need a native-code compiler (like gcj) to create it. And if Harmony
> > itself is a native-code compiler it is not 100% compatible to Suns JVM.
> 
> This isn't necessarily so.  While there are bootstrapping issues, VMs like
> JikesRVM compile themselves under normal operation.
> 
> > 2. I don't know how you want to create a JNI-Interface for C, if the JVM
> > is
> > written in Java.
> 
> This has been done successfully by existing Java-in-Java virtual machines.
>  JikesRVM is open source - you could read the code and find out how it
> does it if you want :)
> 
> cheers,
> Robin
> 
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: Against using Java to implement Java (Was: Java)

[Dalibor Topic]

Matthew French wrote:
But I am still thinking that we can make it so that we have a choice of
multiple VM's - which can be written in C, C++, Java, .Net, Perl, Python
or whatever other language takes the authors fancy. I can see many valid
reasons why we would want to do this, but the trick is getting it to work
without adding enormous complexity.
What worked well for GNU Classpath, and in my opinion helped the 
cambrian explosion of free runtimes happen, that we witnessed within GNU 
Classpath in the last two years, was to use Java for the interfaces, and 
let the VMs do their own marshalling to whatever language they use 
internally.

I'd be interested in hearing more from Steve on how well that works 
within JikesRVM. From reading some papers on the web, it seems that the 
MMTk has been ported to other, non-Java runtimes as well, and I guess 
that this binding-vm-components-via-java-interfaces problem has been 
efficiently solved by other bright people already outside the 
pure-java-runtime space.

How is Classpath done? Is the bulk of the code implemented in C and
wrapped in Java? Or is it Java with a thin C api?
The bulk is written in Java. The largest chunk of C in classpath is 
fdlibm, I believe, which should be eventually kicked out and replaced by 
VM interfaces to let the VMs optimize Math.*() operations internally any 
way they want without having to maintiain their separate copy of 
java.lang.Math.

cheers,
dalibor topic

Re: Against using Java to implement Java (Was: Java)

[Ben Laurie]

Matthew French wrote:
Ben Laurie said:
Mark Brooks wrote:
I hope you use C to write the VM for Harmony.
I've tried to sell C++ in the ASF many times. Even back when it wasn't
quite so bloated as it is now it wasn't a popular idea. Far fewer people
can write C++ than C, and hardly any of those can write _good_ C++.
So, I think we'll end up back at C.

As much as I like C++, I would have to agree that C should be the default.
But I am still thinking that we can make it so that we have a choice of
multiple VM's - which can be written in C, C++, Java, .Net, Perl, Python
or whatever other language takes the authors fancy. I can see many valid
reasons why we would want to do this, but the trick is getting it to work
without adding enormous complexity.

As I've said before, I'd like to see
a framework that _allows_ most of the VM to be run in Java (or Python,
or Perl, or Erlang, or whatever-floats-your-boat), but doesn't require it.
The bulk of a Java environment is the API/libraries. I would like to see
the  libraries written in Java as much as possible. For example, LDAP
functionality can be written entirely in Java. You just need to talk the
right binary language.
I'm not arguing with that, I'm talking about the VM, not the libraries.
Same applies to parts of the maths API like BigDecimal, date functionality
(except some cases like getting the system date), XML classes, the bulk of
the IO classes, etc. We should rely on the VM to optimise the Java code -
I see no reason why an efficient VM cannot match C code or assembler in
most cases.
There are exceptions: for example, advanced maths like sin() or a bulk
block copy will perform much better using hardware. Even then, I think it
could be useful to have implementations of these functions written in
Java, and the ability to override them.
BigDecimal is an exception, too, if you want to do serious crypto. So is 
all the rest of the crypto.

Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Re: Against using Java to implement Java (Was: Java)

[Steve Heath]

Isn't it a good idea to write the first implementation in a functional
programming language (read the wizard book)? That's what these
platforms are designed for and the constructs are there to help in
designing the thing. Then when you're happy you know what's good and
bad you can re-code it in something that actually runs fast. I'm aware
of a reasonable amount of literature that talks about GC and
interpretation techniques that uses languages such as ML and Scheme.

Compiled Java initially seems as good as anything, but don't those
compilers add in their own brand of GC? Wouldn't that be an overhead
we neiter need nor want? Do we want to generate our own native
compiler? I'm thinking the best native compiler/language to use is
probably C.

I agree that most of the libraries can be written in Java, but
wouldn't that constitute a separate apache project, just like GNU
Classpath? The VM should probably be as clean as a very clean thing...
in a clean room.. (hence why I never mentioned C++ :)

On 5/13/05, Matthew French <[EMAIL PROTECTED]> wrote:
> Mark Brooks said:
> > The chief objection I have to using C to write the VM is that it
> > introduces a host of common errors and delays associated with
> > using C or C++ for large products.  C is an excellent language
> > for its purposes, but this isn't 1972.
> 
> Hmmm. First I would argue that a VM is not a big project. Extraordinarily
> complex, yes. But not big.
> 
> Secondly, the common errors and problems related to C usually are the
> result of pointers, memory management and complexity. But I don't see how
> we can get away from these using Java. The whole point of using a VM is to
> hide this functionality from the application, which means by definition we
> have to implement it in the VM.
> 
> Then Bob said:
> >>> IMHO both JITs and pre-compiling have their place.. it
> >>> depends on the application whether one is definitely better
> >>> than the other.
> >
> > This is a recipe for a bloated system that never works.
> 
> Agreed. Which is why we should try and avoid bloat. :)
> 
> But it seems to me the reason behind the wide range of alternate VM's is
> because each of these has a specific niche to fill. If Harmony is intended
> to bring these efforts together, then I would think that some "bloat" is
> inevitable. Not performance bloat, mind you, just added complexity.
> 
> My hope is that by clamping down on this complexity early [did I mention
> architecture? :) ] we will not only remove the bloat but make the task
> even less complex than it is now. (FWIW: I am working on a document, but
> it has taken on a life of its own. Hope to finish over the weekend)
> 
> > Also, most app
> > programmers don't want to worry about the details of how their program
> > is compiled.
> 
> This is dangerous territory: a person who does not know how their car
> moves will eventually run out of petrol.
> 
> Java users, whether they like it or not, will eventually be confronted
> with some implementation details. Our role should be to make such issues
> transparent, not hide them. By doing so we would be reducing the time and
> effort to resolve such issues.
> 
> This does not mean someone needs to read a 200 page tome just to run Java.
> Hopefully the quick start guide will contain just one line...
> 
> Ben Laurie said:
> > Mark Brooks wrote:
> >>> I hope you use C to write the VM for Harmony.
> >
> > I've tried to sell C++ in the ASF many times. Even back when it wasn't
> > quite so bloated as it is now it wasn't a popular idea. Far fewer people
> > can write C++ than C, and hardly any of those can write _good_ C++.
> >
> > So, I think we'll end up back at C.
> 
> As much as I like C++, I would have to agree that C should be the default.
> 
> But I am still thinking that we can make it so that we have a choice of
> multiple VM's - which can be written in C, C++, Java, .Net, Perl, Python
> or whatever other language takes the authors fancy. I can see many valid
> reasons why we would want to do this, but the trick is getting it to work
> without adding enormous complexity.
> 
> > As I've said before, I'd like to see
> > a framework that _allows_ most of the VM to be run in Java (or Python,
> > or Perl, or Erlang, or whatever-floats-your-boat), but doesn't require it.
> 
> The bulk of a Java environment is the API/libraries. I would like to see
> the  libraries written in Java as much as possible. For example, LDAP
> functionality can be written entirely in Java. You just need to talk the
> right binary language.
> 
> Same applies to parts of the maths API like BigDecimal, date functionality
> (except some cases like getting the system date), XML classes, the bulk of
> the IO classes, etc. We should rely on the VM to optimise the Java code -
> I see no reason why an efficient VM cannot match C code or assembler in
> most cases.
> 
> There are exceptions: for example, advanced maths like sin() or a bulk
> block copy will perform much better using hardware. Even then, I 

Re: Against using Java to implement Java (Was: Java)

[Panagiotis Astithas]

Ben Laurie wrote:
Mark Brooks wrote:
One of the reasons why not, from my POV, is because it runs so badly 
on most platforms.

I can't comment on that.  I've used it on Solaris, Linux, and 
Windows.  However, that is a VM issue, not a language issue.

It doesn't matter where the problem lies, the point is that I can't 
develop on the platforms I need/want to develop on.
Is it fair to assume that the problems you would be facing stem from the 
unavailability of the Sun JDK for your preferred platform? In that case 
if a Harmony build could be bootstrapped using gcj/kaffe/jcvm/JikesRVM 
you would be a happy camper, right?

Cheers,
Panagiotis
--
Panagiotis Astithas, PhD
EBS, Electronic Business Systems Ltd.
18 Evgenidou Street, 115 25, Athens GREECE
Phone: +30 210 674 7631
Fax: +30 210 674 7601
http://www.ebs.gr

RE: Against using Java to implement Java (Was: Java)

[Matthew French]

Mark Brooks said:
> The chief objection I have to using C to write the VM is that it
> introduces a host of common errors and delays associated with
> using C or C++ for large products.  C is an excellent language
> for its purposes, but this isn't 1972.

Hmmm. First I would argue that a VM is not a big project. Extraordinarily
complex, yes. But not big.

Secondly, the common errors and problems related to C usually are the
result of pointers, memory management and complexity. But I don't see how
we can get away from these using Java. The whole point of using a VM is to
hide this functionality from the application, which means by definition we
have to implement it in the VM.

Then Bob said:
>>> IMHO both JITs and pre-compiling have their place.. it
>>> depends on the application whether one is definitely better
>>> than the other.
>
> This is a recipe for a bloated system that never works.

Agreed. Which is why we should try and avoid bloat. :)

But it seems to me the reason behind the wide range of alternate VM's is
because each of these has a specific niche to fill. If Harmony is intended
to bring these efforts together, then I would think that some "bloat" is
inevitable. Not performance bloat, mind you, just added complexity.

My hope is that by clamping down on this complexity early [did I mention
architecture? :) ] we will not only remove the bloat but make the task
even less complex than it is now. (FWIW: I am working on a document, but
it has taken on a life of its own. Hope to finish over the weekend)

> Also, most app
> programmers don't want to worry about the details of how their program
> is compiled.

This is dangerous territory: a person who does not know how their car
moves will eventually run out of petrol.

Java users, whether they like it or not, will eventually be confronted
with some implementation details. Our role should be to make such issues
transparent, not hide them. By doing so we would be reducing the time and
effort to resolve such issues.

This does not mean someone needs to read a 200 page tome just to run Java.
Hopefully the quick start guide will contain just one line...

Ben Laurie said:
> Mark Brooks wrote:
>>> I hope you use C to write the VM for Harmony.
>
> I've tried to sell C++ in the ASF many times. Even back when it wasn't
> quite so bloated as it is now it wasn't a popular idea. Far fewer people
> can write C++ than C, and hardly any of those can write _good_ C++.
>
> So, I think we'll end up back at C.

As much as I like C++, I would have to agree that C should be the default.

But I am still thinking that we can make it so that we have a choice of
multiple VM's - which can be written in C, C++, Java, .Net, Perl, Python
or whatever other language takes the authors fancy. I can see many valid
reasons why we would want to do this, but the trick is getting it to work
without adding enormous complexity.

> As I've said before, I'd like to see
> a framework that _allows_ most of the VM to be run in Java (or Python,
> or Perl, or Erlang, or whatever-floats-your-boat), but doesn't require it.

The bulk of a Java environment is the API/libraries. I would like to see
the  libraries written in Java as much as possible. For example, LDAP
functionality can be written entirely in Java. You just need to talk the
right binary language.

Same applies to parts of the maths API like BigDecimal, date functionality
(except some cases like getting the system date), XML classes, the bulk of
the IO classes, etc. We should rely on the VM to optimise the Java code -
I see no reason why an efficient VM cannot match C code or assembler in
most cases.

There are exceptions: for example, advanced maths like sin() or a bulk
block copy will perform much better using hardware. Even then, I think it
could be useful to have implementations of these functions written in
Java, and the ability to override them.

How is Classpath done? Is the bulk of the code implemented in C and
wrapped in Java? Or is it Java with a thin C api?

- Matthew

Re: Against using Java to implement Java (Was: Java)

[Ben Laurie]

Mark Brooks wrote:
One of the reasons why not, from my POV, is because it runs so badly 
on most platforms.

I can't comment on that.  I've used it on Solaris, Linux, and Windows.  
However, that is a VM issue, not a language issue.
It doesn't matter where the problem lies, the point is that I can't 
develop on the platforms I need/want to develop on.

--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Re: Against using Java to implement Java (Was: Java)

[Mark Brooks]

One of the reasons why not, from my POV, is because it runs so badly on 
most platforms.
I can't comment on that.  I've used it on Solaris, Linux, and Windows.  
However, that is a VM issue, not a language issue.

I've tried to sell C++ in the ASF many times. Even back when it wasn't 
quite so bloated as it is now it wasn't a popular idea. Far fewer people 
can write C++ than C, and hardly any of those can write _good_ C++.
Agreed.
_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Against using Java to implement Java (Was: Java)

[Mark Brooks]

My point exactly, nothing has been decided, perhaps it's time to make some 
decisions
Agreed.
I read this as build a better VM than HotSpot under the APL, *and* write 
the class libraries.  I don't read this as take kaffe or JRVM or any other 
product and slap an Apache sticker and go faster stripes on it.  The 
proposal seems to be clear about writing from scratch if it isn't then my 
bad.
That was my original impression as well.  Besides, as a practical matter, 
rewriting an existing codebase doesn't necessarily save you time.  It can do 
the opposite, in fact, depending on the state of the codebase.  Maintaining 
somebody else's code is no picnic, and they might make assumptions in 
developing their own codebase that don't apply in your project.

So I suggest that, with regards to the VM at least, it should be our own 
cleanroom VM.  Really, Harmony is three projects.  First, we need a build 
environment.  Second, we need a conforming VM.  Third, we need a class 
library.  I suspect three will be the biggest issue.  The Java platform API 
is huge.

_
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

Re: Against using Java to implement Java (Was: Java)

[Ben Laurie]

Mark Brooks wrote:
I hope you use C to write the VM for Harmony.

The chief objection I have to using C to write the VM is that it 
introduces a host of common errors and delays associated with using C or 
C++ for large products.  C is an excellent language for its purposes, 
but this isn't 1972.  Java was created to resolve a number of problems 
that arose from the ever-growing design of C++, which I swear is rapidly 
becoming the new PL/1.  We could use a restricted subset of C++ I guess, 
but a lot of "gee-whiz" features would have to be left out to assure 
cross-platform compatibility.  So why not use Java?
One of the reasons why not, from my POV, is because it runs so badly on 
most platforms. If you happen to use Windows, Solaris or Linux(? I 
don't, so I don't know) you may be happy developing in Java. Anywhere 
else, its a PITA.

I've tried to sell C++ in the ASF many times. Even back when it wasn't 
quite so bloated as it is now it wasn't a popular idea. Far fewer people 
can write C++ than C, and hardly any of those can write _good_ C++.

So, I think we'll end up back at C. As I've said before, I'd like to see 
a framework that _allows_ most of the VM to be run in Java (or Python, 
or Perl, or Erlang, or whatever-floats-your-boat), but doesn't require it.

Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Re: Against using Java to implement Java (Was: Java)

[王在祥]

I dont see any problem of writing the JIT in java. It looks very clearly, 
and even can be developed and debugged as a normal Java application.

Re: Against using Java to implement Java (Was: Java)

[Mohammed Al-Qaimari]

It may seem a very odd idea but I believe that p[arts of the VM must be 
implemented at driver level to provide optimized solution for some bottlenecks 
in the hosting OS besides I agree that a larger part of the VM should be 
written C/C++. That's what people at Microsoft do for .NET platform.


There's NO Knowledge That is NOT POWER!
__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Against using Java to implement Java (Was: Java)

[FaeLLe]

I expected to get flamed for this.

Nice to see a postive healthy discussion :)

On 5/13/05, Kev Jackson <[EMAIL PROTECTED]> wrote:
> 
> 
> >Write code of what ? Based on what ?
> >
> >Nothing has been decided ! After all this still a proposal right ? This 
> can
> >be rejected too :)
> >
> >
> >
> >
> My point exactly, nothing has been decided, perhaps it's time to make
> some decisions
> 
> >The thing is how much later into the project will the change be decided ?
> >
> >What if the change we make due too Poor Planning (with two capital P's)
> >cause the entire work or majority of it till then to be discarded ?
> >
> >
> >
> Change isn't a bad thing. I think that the proposal is fairly clear,
> but the approach to take is currently unclear, hence all the noise on
> the mailing list (of which I'm especially guilty)
> >>
> 
> 2) create a community-developed modular runtime (VM and class library)
> architecture to allow independent implementations to share runtime
> components, and allow independent innovation in runtime components
> 
> <<
> 
> I read this as build a better VM than HotSpot under the APL, *and* write
> the class libraries. I don't read this as take kaffe or JRVM or any
> other product and slap an Apache sticker and go faster stripes on it.
> The proposal seems to be clear about writing from scratch if it isn't
> then my bad.
> 
> >Apache votes arent done by the developers it is done by the committe (or 
> am
> >i wrong)
> >
> >
> >
> AFAIK wrong, at least on the other Apache projects I've worked on,
> anyone can make a proposal, and developers can vote, but the committers
> have veto status (correct me if I'm wrong on this).
> 
> >Write a crude VM first, from scratch, using other VM's as guidance, but
> >
> >
> >>not incorporating code from other projects to avoid licensing issues.
> >>Yes []
> >>No []
> >>
> >>At least we can see what's happening
> >>
> >>
> >>
> >
> >No ?
> >
> >
> >
> >
> Ok, at least it's a start ;)
> 



-- 
www.FaeLLe.com 

Re: Against using Java to implement Java (Was: Java)

[Kev Jackson]

Write code of what ? Based on what ? 

Nothing has been decided ! After all this still a proposal right ? This can 
be rejected too :)
 

 

My point exactly, nothing has been decided, perhaps it's time to make 
some decisions

The thing is how much later into the project will the change be decided ? 

What if the change we make due too Poor Planning (with two capital P's) 
cause the entire work or majority of it till then to be discarded ?

 

Change isn't a bad thing.   I think that the proposal is fairly clear, 
but the approach to take is currently unclear, hence all the noise on 
the mailing list (of which I'm especially guilty)
>>

2) create a community-developed modular runtime (VM and class library)
  architecture to allow independent implementations to share runtime
  components, and allow independent innovation in runtime components
<<
I read this as build a better VM than HotSpot under the APL, *and* write 
the class libraries.  I don't read this as take kaffe or JRVM or any 
other product and slap an Apache sticker and go faster stripes on it.  
The proposal seems to be clear about writing from scratch if it isn't 
then my bad.

Apache votes arent done by the developers it is done by the committe (or am 
i wrong)

 

AFAIK wrong, at least on the other Apache projects I've worked on, 
anyone can make a proposal, and developers can vote, but the committers 
have veto status (correct me if I'm wrong on this).

Write a crude VM first, from scratch, using other VM's as guidance, but
 

not incorporating code from other projects to avoid licensing issues.
Yes []
No []
At least we can see what's happening
   

No ?
 

Ok, at least it's a start ;)

Re: Against using Java to implement Java (Was: Java)

[FaeLLe]

On 5/13/05, Kev Jackson <[EMAIL PROTECTED]> wrote:
> 
> 
> >
> >How are you wasting replying to emails and undertaking a discussion.
> >
> >
> >
> Undertaking discussion isn't bad by itself. But discussing things and
> producing nothing is. From these discussions that have already occured,
> I would have liked to see some resolution. "We are going to tackle x
> first, we are going to use y technology" etc.
> 
> >If you think spending time on a good design phase is a waste of time on 
> such
> >a massive project theres something wrong...
> >
> >
> hmm, nope I think spending time doing nothing is a waste of time on any
> project of any scale. Get code in the repo, get people contributing,
> gather some momentum. 


Write code of what ? Based on what ? 

Nothing has been decided ! After all this still a proposal right ? This can 
be rejected too :)

Without that we are doing exactly what critics
> will point out - nothing but arm waving. Making a decision is
> important, we can change it later. 


The thing is how much later into the project will the change be decided ? 

What if the change we make due too Poor Planning (with two capital P's) 
cause the entire work or majority of it till then to be discarded ?

Right now we aren't even at the
> design stage, so you can't say I'm against "good design" - I'm arguing
> for momentum on ideas and deciding what to approach first. Currently we
> have too many options, so I'm going to propose a vote (in the Apache
> way), just to clear away some of the debris:


Apache votes arent done by the developers it is done by the committe (or am 
i wrong)

Write a crude VM first, from scratch, using other VM's as guidance, but
> not incorporating code from other projects to avoid licensing issues.
> Yes []
> No []
> 
> At least we can see what's happening
> 

No ?


-- 
www.FaeLLe.com 

Re: Against using Java to implement Java (Was: Java)

[Kev Jackson]

How are you wasting replying to emails and undertaking a discussion.
 

Undertaking discussion isn't bad by itself.  But discussing things and 
producing nothing is.  From these discussions that have already occured, 
I would have liked to see some resolution.  "We are going to tackle x 
first, we are going to use y technology" etc.

If you think spending time on a good design phase is a waste of time on such 
a massive project theres something wrong...
 

hmm, nope I think spending time doing nothing is a waste of time on any 
project of any scale.  Get code in the repo, get people contributing, 
gather some momentum.  Without that we are doing exactly what critics 
will point out - nothing but arm waving.  Making a decision is 
important, we can change it later.  Right now we aren't even at the 
design stage, so you can't say I'm against "good design" - I'm arguing 
for momentum on ideas and deciding what to approach first.  Currently we 
have too many options, so I'm going to propose a vote (in the Apache 
way), just to clear away some of the debris:

Write a crude VM first, from scratch, using other VM's as guidance, but 
not incorporating code from other projects to avoid licensing issues.
Yes []
No []

At least we can see what's happening

Against using Java to implement Java (Was: Java)

[FaeLLe]

Hmm my mail got bounced,

*Symantec Mail Security detected that you sent a message containing 
prohibited content (SYM:09556261464022074052)* 

 Subject of the message: Re: Against using Java to implement Java (Was: 
Java)Recipient of the message: "harmony-dev@incubator.apache.org" <
harmony-dev@incubator.apache.org>

 -- Forwarded message --
From: FaeLLe <[EMAIL PROTECTED]>
Date: May 13, 2005 4:41 AM
Subject: Re: Against using Java to implement Java (Was: Java)
To: harmony-dev@incubator.apache.org


On 5/13/05, Kev Jackson <[EMAIL PROTECTED]> wrote:
> 
> 
> >
> > So speak up project lead(s). We are here. We are talking a lot, but
> > not much is happening. Order us about. Assign work. Let's get our
> > hands dirty. The likelihood is that there will be changes along the 
> > way anyhow. There almost always are, and developers dedicated to the
> > project will simply have to adapt.
> >
> couldn't agree more, the more 'talking' happening here, the less
> progress seems to be made. The guys rant on bile blog had some points 
> about people here talking and waiting for a code drop from
> IBM/Sun/whoever. I'd like to help on this I really would, but I need a
> direction, what are we doing here? Is it a glue classpath to kaffe to
> xxx? Is it a write everything from scratch? If we want to get started 
> we need some code, without it we're just wasting everyone's time


How are you wasting replying to emails and undertaking a discussion.

If you think spending time on a good design phase is a waste of time on such 
a massive project theres something wrong...

Kev
> 



-- 
www.FaeLLe.com <http://www.FaeLLe.com> 

-- 
www.FaeLLe.com <http://www.FaeLLe.com>

Re: Against using Java to implement Java (Was: Java)

[FaeLLe]

On 5/13/05, Kev Jackson <[EMAIL PROTECTED]> wrote:
> 
> 
> >
> > So speak up project lead(s). We are here. We are talking a lot, but
> > not much is happening. Order us about. Assign work. Let's get our
> > hands dirty. The likelihood is that there will be changes along the
> > way anyhow. There almost always are, and developers dedicated to the
> > project will simply have to adapt.
> >
> couldn't agree more, the more 'talking' happening here, the less
> progress seems to be made. The guys rant on bile blog had some points
> about people here talking and waiting for a code drop from
> IBM/Sun/whoever. I'd like to help on this I really would, but I need a
> direction, what are we doing here? Is it a glue classpath to kaffe to
> xxx? Is it a write everything from scratch? If we want to get started
> we need some code, without it we're just wasting everyone's time


How are you wasting replying to emails and undertaking a discussion.

If you think spending time on a good design phase is a waste of time on such 
a massive project theres something wrong...

Kev
> 



-- 
www.FaeLLe.com 

Re: Against using Java to implement Java (Was: Java)

[Kev Jackson]

So speak up project lead(s).  We are here.  We are talking a lot, but 
not much is happening.  Order us about.  Assign work.  Let's get our 
hands dirty.  The likelihood is that there will be changes along the 
way anyhow.  There almost always are, and developers dedicated to the 
project will simply have to adapt.

couldn't agree more, the more 'talking' happening here, the less 
progress seems to be made.  The guys rant on bile blog had some points 
about people here talking and waiting for a code drop from 
IBM/Sun/whoever.  I'd like to help on this I really would, but I need a 
direction, what are we doing here?  Is it a glue classpath to kaffe to 
xxx?  Is it a write everything from scratch?  If we want to get started 
we need some code, without it we're just wasting everyone's time

Kev

RE: Against using Java to implement Java (Was: Java)

[Nick Lothian]

> 
> I assume that there is a project lead or leads associated 
> with this coming from the Apache project, and they will make 
> the determination of these initial matters.
> 
> So speak up project lead(s).  We are here.  We are talking a 
> lot, but not much is happening.  Order us about.  Assign 
> work.  Let's get our hands dirty.  The likelihood is that 
> there will be changes along the way anyhow.  
> There almost always are, and developers dedicated to the 
> project will simply have to adapt.
> 

That's not really how Apache works. If someone has a good idea they
should implement it, or at least put forward a proposal for it.

For instance, a proposal that has been implicit in this project since
the start is:

"Apache Harmony should use the GNU Classpath class libraries"

Currently we are seeing a lot of discussion about that, particually WRT
licencing.

Another proposal is:

"The Apache Harmony VM should/should not be implemented in Java"

Implicit in that proposal is that a new VM will be written for this
project. That isn't a decision that has been made yet, as other people
are discussing creating an API that allows various exisitng VM
implementations to be used, but it has brought some interesting
discussion about the benefits of various approaches to light.

To get to the point:

If someone wants to write a new VM in Java then there are probably
people on this list who will be interested in helping. However, there
are probably other people who would think that decsion would be
premature, since there is already a high quality Open Source VM written
in Java (Jikes RVM) and the author/maintainer is active on this list.


Nick


IMPORTANT: This e-mail, including any attachments, may contain private or 
confidential information. If you think you may not be the intended recipient, 
or if you have received this e-mail in error, please contact the sender 
immediately and delete all copies of this e-mail. If you are not the intended 
recipient, you must not reproduce any part of this e-mail or disclose its 
contents to any other party.
This email represents the views of the individual sender, which do not 
necessarily reflect those of education.au limited except where the sender 
expressly states otherwise.
It is your responsibility to scan this email and any files transmitted with it 
for viruses or any other defects.
education.au limited will not be liable for any loss, damage or consequence 
caused directly or indirectly by this email. 

RE: Against using Java to implement Java (Was: Java)

[Mark Brooks]

I hope you use C to write the VM for Harmony.
The chief objection I have to using C to write the VM is that it introduces 
a host of common errors and delays associated with using C or C++ for large 
products.  C is an excellent language for its purposes, but this isn't 1972. 
 Java was created to resolve a number of problems that arose from the 
ever-growing design of C++, which I swear is rapidly becoming the new PL/1.  
We could use a restricted subset of C++ I guess, but a lot of "gee-whiz" 
features would have to be left out to assure cross-platform compatibility.  
So why not use Java?

The reason is, that I think, that the best is, if Harmony is nearly 100% 
compatible to Suns Java.
That won't be determined by what language the VM is written in.
If you write the VM in Java itself, then there existing some problems:
1. you need a native-code compiler (like gcj) to create it. And if Harmony 
itself is a native-code compiler it is not 100% compatible to Suns JVM.
I'm not sure why you believe this.  I think some people are confused about 
this.  Initial builds will have to be bootstrapped on another VM until the 
build-environment becomes self-hosting, at which point, it will not be 
necessary to use another VM.

This is the case with PyPy, SBCL, and many other bytecode-intepreted 
self-hosting implementations of a language platform in the language itself.  
My response to your other comments is in the same vein.  C itself is a high 
level language (it isn't assembler or machine code).  The GCC compiler and 
glibc are written in C.  How do you think this came to be?  What about that 
chicken and its egg?  Really, it is simple.  Until the build environment 
became self-hosting, it was written using another tool; once it became 
self-hosting, it could be expanded and extended on itself.

That being said, I think we are all whispering in the wind here.  I'm 
prepared to work in C or C++ if that's what we are using.  Ultimately, a 
toolset is just a toolset, and that includes the language or languages used. 
 Not all languages are equal however; we need to think outside the box a 
little if we are intent on increasing the chances of success.  What is our 
problem domain here?  If the JLS and JVMS, together with the TCK, are our 
requirements documents, then we could use almost any toolset, and the issue 
becomes one of reliability and maintainability.

I assume that there is a project lead or leads associated with this coming 
from the Apache project, and they will make the determination of these 
initial matters.

So speak up project lead(s).  We are here.  We are talking a lot, but not 
much is happening.  Order us about.  Assign work.  Let's get our hands 
dirty.  The likelihood is that there will be changes along the way anyhow.  
There almost always are, and developers dedicated to the project will simply 
have to adapt.

_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Against using Java to implement Java (Was: Java)

[Davanum Srinivas]

Ravi,

can you please add the link to the wiki as well.

thanks,
dims

On 5/14/05, Ravi kiran Gorrepati <[EMAIL PROTECTED]> wrote:
> Check the design of Jikes at,
> http://www.research.ibm.com/journal/sj/391/alpern.pdf
> 
> Though the memory subsytem section is a little outdated,
> that should not prevent you from understanding how it
> works.
> 
> --
> Ravi
> 
> On Thu, 12 May 2005 10:30:12 -0600, <[EMAIL PROTECTED]> wrote:
> 
> >
> > On 12 May 2005, at 12:17, theUser BL wrote:
> >
> >> I hope you use C to write the VM for Harmony.
> >>
> >
> > Forgive me if I am repeating what others have already said - I'm a bit
> > late to this.
> >
> > Bootstrapping the whole thing in Java is a very clever idea, but what
> > about the management of the heap (GC etc)? Presumably that would have to
> > be done in some layered system, with a very simplistic GC in the
> > bootstrap VM, with layers of extra logic on top of it? Or am I missing
> > something?
> >
> > If so, what sort of performance hit would this have? I agree that in
> > many ways it is a Good Thing, but so was Sun's handle redirection stuff
> > (where an object reference referred to a table, that referred to the
> > object) but Microsoft's Bad Way of simply linking to the object ran much
> > quicker. In fact, didn't Sun eventually switch to that way of working? I
> > think there was something about it in Simon Ritter's talk on GC at last
> > year's London Java Tech days.
> >
> > I know very little about all this (so please beat me only with a very
> > small stick and in a loving manner) but would it be possible to start
> > with an existing(?) JVM written in C/C++ and then start to migrate it
> > part by part into Java? Taking the baby steps approach, couldn't we work
> > out exactly where the log-jams are likely to be? And then get as much as
> > we can in Java, so long as it doesn't have a significant impact on
> > performance?
> >
> > Would taking the C/C++ --> Java approach mean that we could base our
> > discussions upon the evidence of the code, and less upon subjective
> > belief? More ground up and less BUFD?
> >
> > DG
> 
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: Against using Java to implement Java (Was: Java)

[Ravi kiran Gorrepati]

Check the design of Jikes at,
http://www.research.ibm.com/journal/sj/391/alpern.pdf
Though the memory subsytem section is a little outdated,
that should not prevent you from understanding how it
works.
--
Ravi
On Thu, 12 May 2005 10:30:12 -0600, <[EMAIL PROTECTED]> wrote:
On 12 May 2005, at 12:17, theUser BL wrote:
I hope you use C to write the VM for Harmony.
Forgive me if I am repeating what others have already said - I'm a bit  
late to this.

Bootstrapping the whole thing in Java is a very clever idea, but what  
about the management of the heap (GC etc)? Presumably that would have to  
be done in some layered system, with a very simplistic GC in the  
bootstrap VM, with layers of extra logic on top of it? Or am I missing  
something?

If so, what sort of performance hit would this have? I agree that in  
many ways it is a Good Thing, but so was Sun's handle redirection stuff  
(where an object reference referred to a table, that referred to the  
object) but Microsoft's Bad Way of simply linking to the object ran much  
quicker. In fact, didn't Sun eventually switch to that way of working? I  
think there was something about it in Simon Ritter's talk on GC at last  
year's London Java Tech days.

I know very little about all this (so please beat me only with a very  
small stick and in a loving manner) but would it be possible to start  
with an existing(?) JVM written in C/C++ and then start to migrate it  
part by part into Java? Taking the baby steps approach, couldn't we work  
out exactly where the log-jams are likely to be? And then get as much as  
we can in Java, so long as it doesn't have a significant impact on  
performance?

Would taking the C/C++ --> Java approach mean that we could base our  
discussions upon the evidence of the code, and less upon subjective  
belief? More ground up and less BUFD?

DG

Re: Against using Java to implement Java (Was: Java)

[tumnus]

On 12 May 2005, at 12:17, theUser BL wrote:
I hope you use C to write the VM for Harmony.
Forgive me if I am repeating what others have already said - I'm a  
bit late to this.

Bootstrapping the whole thing in Java is a very clever idea, but what  
about the management of the heap (GC etc)? Presumably that would have  
to be done in some layered system, with a very simplistic GC in the  
bootstrap VM, with layers of extra logic on top of it? Or am I  
missing something?

If so, what sort of performance hit would this have? I agree that in  
many ways it is a Good Thing, but so was Sun's handle redirection  
stuff (where an object reference referred to a table, that referred  
to the object) but Microsoft's Bad Way of simply linking to the  
object ran much quicker. In fact, didn't Sun eventually switch to  
that way of working? I think there was something about it in Simon  
Ritter's talk on GC at last year's London Java Tech days.

I know very little about all this (so please beat me only with a very  
small stick and in a loving manner) but would it be possible to start  
with an existing(?) JVM written in C/C++ and then start to migrate it  
part by part into Java? Taking the baby steps approach, couldn't we  
work out exactly where the log-jams are likely to be? And then get as  
much as we can in Java, so long as it doesn't have a significant  
impact on performance?

Would taking the C/C++ --> Java approach mean that we could base our  
discussions upon the evidence of the code, and less upon subjective  
belief? More ground up and less BUFD?

DG

Re: Against using Java to implement Java (Was: Java)

[Stefano Mazzocchi]

theUser BL wrote:
I hope you use C to write the VM for Harmony.
The reason is, that I think, that the best is, if Harmony is nearly 100% 
compatible to Suns Java.

If you write the VM in Java itself, then there existing some problems:
1. you need a native-code compiler (like gcj) to create it. 
No, a java JVM can run itself, it only need a tiny native bootstrapper.
And if 
Harmony itself is a native-code compiler it is not 100% compatible to 
Suns JVM.
eh? that is simply not true: the TCK is a functional test not an 
architectural one.

2. I don't know how you want to create a JNI-Interface for C, if the JVM 
is written in Java.
'written in java' doesn't mean that it doesn't have access to the 
underlying OS, it has to. Writing a JVM that needs another JVM to run 
would be stupid :-)

3. The best would be, if all *.DLL (on Windows) and *.so (on 
Linux/Unix/MacOSX) files are like Suns one. For example: Older J2SEs 
used Symmantecs JITter. And it is possible that there existing firms 
which try to replace also some other parts of Java with its own one. So 
it would be nice, if then Harmony can use this replacements, too.
Modularity is something we aim at for Harmony.
--
Stefano.

Re: Against using Java to implement Java (Was: Java)

[Ben Laurie]

Nookala Satish Kumar wrote:
I too support the point to implement the VM in C/C++. But the problem
with this would be porting the VM to multiple platforms like *nix,
Win32, Mac etc.
Hence we have to choose between the two: Performance and Portability.
We do? Httpd runs on _far_ more platforms than Java does. It's written in C.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Re: Against using Java to implement Java (Was: Java)

[Bob]

On May 12, 2005, at 7:17 AM, theUser BL wrote:
I hope you use C to write the VM for Harmony.
GCJ would suit all the concerns you listed.  In many ways, GCJ can be 
thought of as "C++ in Java syntax, plus a nice runtime library".  GCJ 
can load .dll/.so files, etc (using extensions to the standard Java 
language).

Re: Against using Java to implement Java (Was: Java)

[Nookala Satish Kumar]

I too support the point to implement the VM in C/C++. But the problem
with this would be porting the VM to multiple platforms like *nix,
Win32, Mac etc.

Hence we have to choose between the two: Performance and Portability.

Regards,
Satish.

On 12/05/05, theUser BL <[EMAIL PROTECTED]> wrote:
> I hope you use C to write the VM for Harmony.
> 
> The reason is, that I think, that the best is, if Harmony is nearly 100%
> compatible to Suns Java.
> 
> If you write the VM in Java itself, then there existing some problems:
> 1. you need a native-code compiler (like gcj) to create it. And if Harmony
> itself is a native-code compiler it is not 100% compatible to Suns JVM.
> 2. I don't know how you want to create a JNI-Interface for C, if the JVM is
> written in Java.
> 3. The best would be, if all *.DLL (on Windows) and *.so (on
> Linux/Unix/MacOSX) files are like Suns one. For example: Older J2SEs used
> Symmantecs JITter. And it is possible that there existing firms which try to
> replace also some other parts of Java with its own one. So it would be nice,
> if then Harmony can use this replacements, too.
> 
> Greatings
> theuserbl
> 
> 


-- 
|| Satyam Vada, Dharmam Chara ||
|| Matru Devo Bhava, Pitru Devo Bhava ||
|| Acharya Devo Bhava, Atithi Devo Bhava ||

Get Firefox. The browser you can trust.
http://www.spreadfirefox.com/?q=affiliates&id=43194&t=1

Re: Against using Java to implement Java (Was: Java)

[Robin Garner]

> I hope you use C to write the VM for Harmony.
>
> The reason is, that I think, that the best is, if Harmony is nearly 100%
> compatible to Suns Java.
>
> If you write the VM in Java itself, then there existing some problems:
> 1. you need a native-code compiler (like gcj) to create it. And if Harmony
> itself is a native-code compiler it is not 100% compatible to Suns JVM.

This isn't necessarily so.  While there are bootstrapping issues, VMs like
JikesRVM compile themselves under normal operation.

> 2. I don't know how you want to create a JNI-Interface for C, if the JVM
> is
> written in Java.

This has been done successfully by existing Java-in-Java virtual machines.
 JikesRVM is open source - you could read the code and find out how it
does it if you want :)

cheers,
Robin

Against using Java to implement Java (Was: Java)

[theUser BL]

I hope you use C to write the VM for Harmony.
The reason is, that I think, that the best is, if Harmony is nearly 100% 
compatible to Suns Java.

If you write the VM in Java itself, then there existing some problems:
1. you need a native-code compiler (like gcj) to create it. And if Harmony 
itself is a native-code compiler it is not 100% compatible to Suns JVM.
2. I don't know how you want to create a JNI-Interface for C, if the JVM is 
written in Java.
3. The best would be, if all *.DLL (on Windows) and *.so (on 
Linux/Unix/MacOSX) files are like Suns one. For example: Older J2SEs used 
Symmantecs JITter. And it is possible that there existing firms which try to 
replace also some other parts of Java with its own one. So it would be nice, 
if then Harmony can use this replacements, too.

Greatings
theuserbl