You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Patrice Le Vexier <pl...@bellsouth.net> on 2005/05/16 00:42:16 UTC
impatient ;)
Dear all,
correct me if i'm wrong, but, to make a J2SE platform, we need:
- a compiler (javac)
- a JVM (maybe a simple interpreter at first time, then a jit/wat/xxx of the
death)
- class library (classpath as good bet)
- some tools (appletviewer, keytool etc)
- an installer
- ...
I know we're at the very first stage of the development and a lot of stuff
are currently actively discussed, but is there nothing of this list we can
begin to code, maybe just as proof of concept, or to try some solutions ?
I'm on windows platform, and i can participate to the compiler or even the
installer ;)
patrice
Re: impatient ;)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 15, 2005, at 7:32 PM, Listreader account wrote:
> Hello all,
>
> On Sun, May 15, 2005 at 06:42:16PM -0400, Patrice Le Vexier wrote:
>
>
>> Dear all,
>>
>> correct me if i'm wrong, but, to make a J2SE platform, we need:
>>
>> - a compiler (javac)
>> - a JVM (maybe a simple interpreter at first time, then a jit/wat/=20
>> xxx of the
>> death)
>> - class library (classpath as good bet)
>> - some tools (appletviewer, keytool etc)
>> - an installer
>> - ...
>>
>>
>
> True, but from an architect's point of view, I believe we should look
> closer at some fundamentals WRT requirements and at a common
> implementation layer. Questions such as
>
> a) Do we have a go from Apache and Sun Legal to actually pursue this
> project? (Noone wants to end up in a legal battle somewhere down
> =20=
>
> the
> road).
>
> =3D=3D> Geir? Your ball?
>
No, we don't. We are doing this project. There's no legal issue =20
right now.
>
> b) Which OS's should be targeted?
> (This gives info for a baseline to installation and OS
> abstraction layers.)
>
> Given experience from some large open source projects such as =20
> Debian
> GNU/Linux, targeting a multitude of OS'es can slow down the project
> considerably - while at the same time creating a de-facto =20
> standard in
> strength of its many platform options.
>
> =3D=3D> Is it sensible to start with the OSs [Windows 2K/XP,
> Linux =20=
>
> <pick
> libc version>, Solaris, Mac OS X]?
>
Right - we shouldn't target a specific OS. I think that with a =20
careful OS/(VM|class lib) boundary, we let people port as they need to.
>
> c) Could we augment the proposed architecture in
> (http://people.apache.org/~geirm/harmony.jpg) by introducing an OS
> abstraction layer (OAL) to failitate porting? (Similar to the
> strategy used for GCC porting.)
>
yes - that was the intent
>
> I attach a small and quickly scribbled image describing this; =20
> will do
> a proper architecture sketch should the need arise.
>
The attachment didn't come through.
>
> d) What strategy do we pick WRT JDK tool implementation? I would
> recommend that we create a common library that can be used by all
> tools. That way, we can minimize the porting effort to different
> OS'es and have a single library to distribute instead of a splay
> of smaller ones.
>
> Attaching a small sketch on the structure.
>
>
didn't come through
>
>
>> I know we're at the very first stage of the development and a lot =20
>> of stuff
>> are currently actively discussed, but is there nothing of this =20
>> list we can
>> begin to code, maybe just as proof of concept, or to try some =20
>> solutions ?
>>
>>
>
> Since Harmony is potentially an *extremely* important project, I
> recommend that we stick to the Apache development process. We will =20
> have
> quite a lot to code soon enough.
>
As long as it's an apache process, that's what we'll do.
geir
>
> Patience.
>
> ;)
>
> ---
> // Lennart J=F6relid, Senior J2EE Architect
> // jGuru Europe AB
> // lj@jguru.se
>
>
--=20
Geir Magnusson Jr +1-203-665-6437
geir@optonline.net
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: OS Abstraction Layer and Common Tools Library
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 15, 2005, at 7:38 PM, Listreader account wrote:
>
> c) Could we augment the proposed architecture in
> (http://people.apache.org/~geirm/harmony.jpg) by introducing an OS
> abstraction layer (OAL) to failitate porting? (Similar to the
> strategy used for GCC porting.)
>
> Placing a quick sketch of this on
> http://www.jguru.se/images/harmony_OAL.jpg
>
Yes - that was the point of the Hardware Implementation Interface. I
just needed to move it all the way across. Will do so and update.
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Introduction, and a question
Posted by Brad Cox <br...@gmail.com>.
Doubt it would/should be done automatically. Checkpoints would be
triggered by a checkpoint() library call which would save the executable
state as an executable file (and exit without returning). When the file
is executed, execution would resume as if returning from the
checkpoint() function.
Christian Damsgaard wrote:
> I brought up this idea with Lars Bak (HotSpot architect at Sun back
> then) at a conference some years back when Sun introduced the HotSpot
> VM. The argument back then was that a program mays not execute in the
> same pattern every time and the optimization made previously may no
> longer apply.
>
> Regards
> Christian Damsgaard
>
> Brad Cox wrote:
>
>> Hello. I'm an old-timer with OO languages (Objective-C originator)
>> but a newcomer to open source. I've just signed up to this list
>> because Harmony sounds like something I could really get excited by.
>> I'd welcome suggestions as to how to get started, traps to avoid, etc.
>>
>> I'll start by venturing what I suspect might be a naive question.
>> Java is fast enough once it gets its legs beneath it, but the
>> classloader is giving it a bad rap for speed. That's my impression,
>> not measured fact.
>>
>> Has there been any consideration to stealing an old trick from
>> Smalltalk/Lisp environments...a "restart" option that reloads the
>> dynamic state saved by a previous execution, typically one that has
>> just completed loading an app's classes but before run-specific
>> instances were created?
>>
>> I seems too simple to not have been tried, particularly with such as
>> Peter Deutch involved with the JIT compiler.
>
>
>
>
Re: Introduction, and a question
Posted by Torsten Curdt <tc...@apache.org>.
> True, but if you saved the entire state of the JVM memory on disk (an
> JVM 'hibernation'?) then you could just start from where you left,
> instruction pointer included.
huuuh ...that would be awesome!
> Not sure how hard it is to write, but doesn't sound like a bad idea to me.
absolutely!
cheers
--
Torsten
Re: Introduction, and a question
Posted by Ian Darwin <ia...@darwinsys.com>.
> >True, but if you saved the entire state of the JVM memory on disk (an
> >JVM 'hibernation'?) then you could just start from where you left,
> >instruction pointer included.
>
> Just one _teensy_ snag. Open files and sockets. And all state external
> to the JVM.
No, that's not the snag. This is not a new idea, as pointed out Emacs and other
stuff has used it for years. The actual technique is you pre-load the application
but don't start it running (see also the Zombie calls in JikesRVM). Since it hasn't
been started, there is no external state, no open files, etc.
As is now obvious, the snag for doing it in Java is: how do you know what classes
to load and precompile? There is no right answer, but the simple answer is to inspect
the byte code for all classes that are instantiated. This works for the cases without
dynamic loading, so HelloWorldJDBC.java won't run. Unless you also support dynamic
loading in your VM.
Re: Introduction, and a question
Posted by Ben Laurie <be...@algroup.co.uk>.
Stefano Mazzocchi wrote:
> Christian Damsgaard wrote:
>
>> I brought up this idea with Lars Bak (HotSpot architect at Sun back
>> then) at a conference some years back when Sun introduced the HotSpot
>> VM. The argument back then was that a program mays not execute in the
>> same pattern every time and the optimization made previously may no
>> longer apply.
>
>
> True, but if you saved the entire state of the JVM memory on disk (an
> JVM 'hibernation'?) then you could just start from where you left,
> instruction pointer included.
Just one _teensy_ snag. Open files and sockets. And all state external
to the JVM.
--
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: Introduction, and a question
Posted by Zaw Win Aung <zw...@gmail.com>.
I think what Brad brought up is good. Do we have any way to optimise
the saved classes for current environment before instantiation.
On 5/16/05, Stefano Mazzocchi <st...@apache.org> wrote:
> Christian Damsgaard wrote:
> > I brought up this idea with Lars Bak (HotSpot architect at Sun back
> > then) at a conference some years back when Sun introduced the HotSpot
> > VM. The argument back then was that a program mays not execute in the
> > same pattern every time and the optimization made previously may no
> > longer apply.
>
> True, but if you saved the entire state of the JVM memory on disk (an
> JVM 'hibernation'?) then you could just start from where you left,
> instruction pointer included.
>
> Not sure how hard it is to write, but doesn't sound like a bad idea to me.
>
> (wasn't this was EMACS was doing with the 'core dump trick'?)
>
> --
> Stefano.
>
>
Re: Introduction, and a question
Posted by Stefano Mazzocchi <st...@apache.org>.
Christian Damsgaard wrote:
> I brought up this idea with Lars Bak (HotSpot architect at Sun back
> then) at a conference some years back when Sun introduced the HotSpot
> VM. The argument back then was that a program mays not execute in the
> same pattern every time and the optimization made previously may no
> longer apply.
True, but if you saved the entire state of the JVM memory on disk (an
JVM 'hibernation'?) then you could just start from where you left,
instruction pointer included.
Not sure how hard it is to write, but doesn't sound like a bad idea to me.
(wasn't this was EMACS was doing with the 'core dump trick'?)
--
Stefano.
Re: Introduction, and a question
Posted by Steve Blackburn <St...@anu.edu.au>.
Take a look at Quicksilver (no longer active).
http://www.research.ibm.com/quicksilver/
"The Quicksilver project is exploring novel compilation models for Java.
Our goals are to support deep analysis, aggressive optimization,
testability and control over executables, all in the context of a fully
compliant Java system. Our prototype is implemented within the Jalapeño
compiler project."
--Steve
Christian Damsgaard wrote:
> I brought up this idea with Lars Bak (HotSpot architect at Sun back
> then) at a conference some years back when Sun introduced the HotSpot
> VM. The argument back then was that a program mays not execute in the
> same pattern every time and the optimization made previously may no
> longer apply.
>
> Regards
> Christian Damsgaard
>
> Brad Cox wrote:
>
>> Hello. I'm an old-timer with OO languages (Objective-C originator)
>> but a newcomer to open source. I've just signed up to this list
>> because Harmony sounds like something I could really get excited by.
>> I'd welcome suggestions as to how to get started, traps to avoid, etc.
>>
>> I'll start by venturing what I suspect might be a naive question.
>> Java is fast enough once it gets its legs beneath it, but the
>> classloader is giving it a bad rap for speed. That's my impression,
>> not measured fact.
>>
>> Has there been any consideration to stealing an old trick from
>> Smalltalk/Lisp environments...a "restart" option that reloads the
>> dynamic state saved by a previous execution, typically one that has
>> just completed loading an app's classes but before run-specific
>> instances were created?
>>
>> I seems too simple to not have been tried, particularly with such as
>> Peter Deutch involved with the JIT compiler.
>
>
Re: Introduction, and a question
Posted by Christian Damsgaard <ch...@damsgaard.biz>.
I brought up this idea with Lars Bak (HotSpot architect at Sun back
then) at a conference some years back when Sun introduced the HotSpot
VM. The argument back then was that a program mays not execute in the
same pattern every time and the optimization made previously may no
longer apply.
Regards
Christian Damsgaard
Brad Cox wrote:
> Hello. I'm an old-timer with OO languages (Objective-C originator) but
> a newcomer to open source. I've just signed up to this list because
> Harmony sounds like something I could really get excited by. I'd
> welcome suggestions as to how to get started, traps to avoid, etc.
>
> I'll start by venturing what I suspect might be a naive question. Java
> is fast enough once it gets its legs beneath it, but the classloader
> is giving it a bad rap for speed. That's my impression, not measured
> fact.
>
> Has there been any consideration to stealing an old trick from
> Smalltalk/Lisp environments...a "restart" option that reloads the
> dynamic state saved by a previous execution, typically one that has
> just completed loading an app's classes but before run-specific
> instances were created?
>
> I seems too simple to not have been tried, particularly with such as
> Peter Deutch involved with the JIT compiler.
Re: Introduction, and a question
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 15, 2005, at 8:23 PM, Brad Cox wrote:
> Hello. I'm an old-timer with OO languages (Objective-C originator)
> but a newcomer to open source. I've just signed up to this list
> because Harmony sounds like something I could really get excited
> by. I'd welcome suggestions as to how to get started, traps to
> avoid, etc.
>
> I'll start by venturing what I suspect might be a naive question.
> Java is fast enough once it gets its legs beneath it, but the
> classloader is giving it a bad rap for speed. That's my impression,
> not measured fact.
>
> Has there been any consideration to stealing an old trick from
> Smalltalk/Lisp environments...a "restart" option that reloads the
> dynamic state saved by a previous execution, typically one that has
> just completed loading an app's classes but before run-specific
> instances were created?
No, but that's a good one :)
>
> I seems too simple to not have been tried, particularly with such
> as Peter Deutch involved with the JIT compiler.
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Introduction, and a question
Posted by Brad Cox <br...@gmail.com>.
Hello. I'm an old-timer with OO languages (Objective-C originator) but a
newcomer to open source. I've just signed up to this list because
Harmony sounds like something I could really get excited by. I'd welcome
suggestions as to how to get started, traps to avoid, etc.
I'll start by venturing what I suspect might be a naive question. Java
is fast enough once it gets its legs beneath it, but the classloader is
giving it a bad rap for speed. That's my impression, not measured fact.
Has there been any consideration to stealing an old trick from
Smalltalk/Lisp environments...a "restart" option that reloads the
dynamic state saved by a previous execution, typically one that has just
completed loading an app's classes but before run-specific instances
were created?
I seems too simple to not have been tried, particularly with such as
Peter Deutch involved with the JIT compiler.
Re: OS Abstraction Layer and Common Tools Library
Posted by Marco Lange <ma...@rwth-aachen.de>.
Hi,
> b) Which OS's should be targeted?
> (This gives info for a baseline to installation and OS
> abstraction layers.)
>
> Given experience from some large open source projects such as Debian
> GNU/Linux, targeting a multitude of OS'es can slow down the project
> considerably - while at the same time creating a de-facto standard in
> strength of its many platform options.
>
> ==> Is it sensible to start with the OSs [Windows 2K/XP, Linux <pick
> libc version>, Solaris, Mac OS X]?
I suggest targeting a few more Unix platforms in order not to stick to
Linux specialties to much. Maybe some of the *BSDs. Later refactoring
the existing code to remove the Linux-dependent parts would be wasted
time and effort, IMO. On the other side, I would not regard Solaris
support as
necessary from the start, unless it has to be done to achieve TCK
compability.
> c) Could we augment the proposed architecture in
> (http://people.apache.org/~geirm/harmony.jpg) by introducing an OS
> abstraction layer (OAL) to failitate porting? (Similar to the
> strategy used for GCC porting.)
>
> Placing a quick sketch of this on
> http://www.jguru.se/images/harmony_OAL.jpg
ACK. I support this. Maybe APR can be used, maybe something self-made,
that remains to be seen. But there may be some parts which not only
depend on the OS but also heavily on the specific underlying platform,
like optimizing JIT compiler. This problem is also very important to be
addressed.
Regards,
Marco
OS Abstraction Layer and Common Tools Library
Posted by Listreader account <li...@jguru.se>.
Hello all,
On Sun, May 15, 2005 at 06:42:16PM -0400, Patrice Le Vexier wrote:
> Dear all,
>
> correct me if i'm wrong, but, to make a J2SE platform, we need:
>
> - a compiler (javac)
> - a JVM (maybe a simple interpreter at first time, then a jit/wat/xxx of the
> death)
> - class library (classpath as good bet)
> - some tools (appletviewer, keytool etc)
> - an installer
> - ...
True, but from an architect's point of view, I believe we should look
closer at some fundamentals WRT requirements and at a common
implementation layer. Questions such as
a) Do we have a go from Apache and Sun Legal to actually pursue this
project? (Noone wants to end up in a legal battle somewhere down the
road).
==> Geir? Your ball?
b) Which OS's should be targeted?
(This gives info for a baseline to installation and OS
abstraction layers.)
Given experience from some large open source projects such as Debian
GNU/Linux, targeting a multitude of OS'es can slow down the project
considerably - while at the same time creating a de-facto standard in
strength of its many platform options.
==> Is it sensible to start with the OSs [Windows 2K/XP, Linux <pick
libc version>, Solaris, Mac OS X]?
c) Could we augment the proposed architecture in
(http://people.apache.org/~geirm/harmony.jpg) by introducing an OS
abstraction layer (OAL) to failitate porting? (Similar to the
strategy used for GCC porting.)
Placing a quick sketch of this on
http://www.jguru.se/images/harmony_OAL.jpg
d) What strategy do we pick WRT JDK tool implementation? I would
recommend that we create a common library that can be used by all
tools. That way, we can minimize the porting effort to different
OS'es and have a single library to distribute instead of a splay
of smaller ones.
Placing a small sketch of this on
http://www.jguru.se/images/ctl.jpg
> I know we're at the very first stage of the development and a lot of stuff
> are currently actively discussed, but is there nothing of this list we can
> begin to code, maybe just as proof of concept, or to try some solutions ?
Since Harmony is potentially an *extremely* important project, I
recommend that we stick to the Apache development process. We will have
quite a lot to code soon enough.
Patience.
;)
---
// Lennart J�relid, Senior J2EE Architect
// jGuru Europe AB
// lj@jguru.se
Re: impatient ;)
Posted by Listreader account <li...@jguru.se>.
Hello all,
On Sun, May 15, 2005 at 06:42:16PM -0400, Patrice Le Vexier wrote:
> Dear all,
>
> correct me if i'm wrong, but, to make a J2SE platform, we need:
>
> - a compiler (javac)
> - a JVM (maybe a simple interpreter at first time, then a jit/wat/xxx of the
> death)
> - class library (classpath as good bet)
> - some tools (appletviewer, keytool etc)
> - an installer
> - ...
True, but from an architect's point of view, I believe we should look
closer at some fundamentals WRT requirements and at a common
implementation layer. Questions such as
a) Do we have a go from Apache and Sun Legal to actually pursue this
project? (Noone wants to end up in a legal battle somewhere down the
road).
==> Geir? Your ball?
b) Which OS's should be targeted?
(This gives info for a baseline to installation and OS
abstraction layers.)
Given experience from some large open source projects such as Debian
GNU/Linux, targeting a multitude of OS'es can slow down the project
considerably - while at the same time creating a de-facto standard in
strength of its many platform options.
==> Is it sensible to start with the OSs [Windows 2K/XP, Linux <pick
libc version>, Solaris, Mac OS X]?
c) Could we augment the proposed architecture in
(http://people.apache.org/~geirm/harmony.jpg) by introducing an OS
abstraction layer (OAL) to failitate porting? (Similar to the
strategy used for GCC porting.)
I attach a small and quickly scribbled image describing this; will do
a proper architecture sketch should the need arise.
d) What strategy do we pick WRT JDK tool implementation? I would
recommend that we create a common library that can be used by all
tools. That way, we can minimize the porting effort to different
OS'es and have a single library to distribute instead of a splay
of smaller ones.
Attaching a small sketch on the structure.
> I know we're at the very first stage of the development and a lot of stuff
> are currently actively discussed, but is there nothing of this list we can
> begin to code, maybe just as proof of concept, or to try some solutions ?
Since Harmony is potentially an *extremely* important project, I
recommend that we stick to the Apache development process. We will have
quite a lot to code soon enough.
Patience.
;)
---
// Lennart J�relid, Senior J2EE Architect
// jGuru Europe AB
// lj@jguru.se
Re: impatient ;)
Posted by Phillip Rhodes <mi...@cpphacker.co.uk>.
Brett Porter wrote:
> - - a JVM (maybe a simple interpreter at first time, then a jit/wat/xxx
> of the
> death) - as it should work with other compilers and mutliple class libraries
> - - an installer
> - - class library (classpath as good bet)
> - - a compiler (javac)
> - - some tools (appletviewer, keytool etc)
I think a compiler should be pretty close to last on the priority list.
There are plenty of Java compilers, including an open-source one (I'm
thinking of the Eclipse compiler, fwiw). The runtime (JVM /
Class-Library) is, IMHO, the main thing we need, followed by misc
tools like keytool and rmic, etc.
Just my $00.02 worth..
TTYL,
Phil
--
North Carolina - First In Freedom
Free America - Vote Libertarian
www.lp.org
Re: impatient ;)
Posted by Brett Porter <br...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Patrice Le Vexier wrote:
>Dear all,
>
>correct me if i'm wrong, but, to make a J2SE platform, we need:
>
>- a compiler (javac)
>- a JVM (maybe a simple interpreter at first time, then a jit/wat/xxx of the
>death)
>- class library (classpath as good bet)
>- some tools (appletviewer, keytool etc)
>- an installer
>- ...
IMO, I expect the order would be:
- - a JVM (maybe a simple interpreter at first time, then a jit/wat/xxx
of the
death) - as it should work with other compilers and mutliple class libraries
- - an installer
- - class library (classpath as good bet)
- - a compiler (javac)
- - some tools (appletviewer, keytool etc)
The tools probably creep in at all stages, though.
Cheers,
Brett
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCh9cGOb5RoQhMkRMRAu8BAJ4lbtnW0ESGtbzO7LBRXnoJ36zHOQCgsT5K
RTEY+HzHlET+gl+BY+hdASo=
=eTpB
-----END PGP SIGNATURE-----
Re: impatient ;)
Posted by Davanum Srinivas <da...@gmail.com>.
i hereby second all the motions :)
-- dims
On 5/16/05, Stefano Mazzocchi <st...@apache.org> wrote:
> Here is my take (with all my hats off):
>
> Patrice Le Vexier wrote:
> > Dear all,
> >
> > correct me if i'm wrong, but, to make a J2SE platform, we need:
> >
> > - a compiler (javac)
>
> let's use eclipse JDT compiler. it rocks, it's fast, has a compatible
> license and uses classloaders instead of classpaths (makes it a lot more
> flexible and embeddable as a compiler).
>
> > - a JVM (maybe a simple interpreter at first time, then a jit/wat/xxx of the
> > death)
>
> Those who have a JVM and want to donate it under the apache license to
> seed harmony raise their hands now!
>
> > - class library (classpath as good bet)
>
> Yes, let's go with Classpath.
>
> > - some tools (appletviewer, keytool etc)
>
> I think we need to have "java and javac" the rest will follow when needed.
>
> > - an installer
>
> that's too early :-)
>
> > - ...
> >
> > I know we're at the very first stage of the development and a lot of stuff
> > are currently actively discussed, but is there nothing of this list we can
> > begin to code, maybe just as proof of concept, or to try some solutions ?
> >
> > I'm on windows platform, and i can participate to the compiler or even the
> > installer ;)
>
> here's a task for those of you who want something to do: wrap the
> eclipse JDT compiler and make it look/feel like javac from the command line.
>
> --
> Stefano.
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
RE: impatient ;)
Posted by Patrice Le Vexier <pl...@bellsouth.net>.
ok ahmed, I thought to take, more or less the same direction, so keep
going, and tell me if I can help on something.
You certainly have to consider portability issues with paths and files, here
a small document from sun who talks a little bit about that
http://java.sun.com/products/archive/100percent/4.1.1/100PercentPureJavaCook
book-4_1_1.pdf, and by googling, I think you will find a lot more.
I'm going to work on some ideas I would like to dig out for the compiler,
let me check if they are good ideas, if yes, I'll share it with you ;)
patrice
> -----Message d'origine-----
> De : Ahmed Saad [mailto:myanywhere@gmail.com]
> Envoyé : Tuesday, May 17, 2005 1:58 PM
> À : harmony-dev@incubator.apache.org; dims@apache.org
> Objet : Re: impatient ;)
>
>
> i'm working on that too.. i'm using args4j to support javac-like option
> parsing capabilites... i'm reading the tomcat Jasper source code to learn
> more about how they did that (the JDTCompiler class)... would be great if
> you wanna share ideas
>
> -ahmed
>
> On 5/17/05, Davanum Srinivas <da...@gmail.com> wrote:
> >
> > go for it!
> >
> > -- dims
> >
> > On 5/16/05, Patrice Le Vexier <pl...@bellsouth.net> wrote:
> > > > here's a task for those of you who want something to do: wrap the
> > > > eclipse JDT compiler and make it look/feel like javac from the
> > > > command line.
> > > >
> > > > --
> > > > Stefano.
> > > >
> > > >
> > >
> > > If there is no objection to use this compiler, I can do that.
> > >
> > > Please, let me know.
> > >
> > > patrice
> > >
> >
> > --
> > Davanum Srinivas - http://webservices.apache.org/~dims/
> >
>
Re: impatient ;)
Posted by Ahmed Saad <my...@gmail.com>.
i'm working on that too.. i'm using args4j to support javac-like option
parsing capabilites... i'm reading the tomcat Jasper source code to learn
more about how they did that (the JDTCompiler class)... would be great if
you wanna share ideas
-ahmed
On 5/17/05, Davanum Srinivas <da...@gmail.com> wrote:
>
> go for it!
>
> -- dims
>
> On 5/16/05, Patrice Le Vexier <pl...@bellsouth.net> wrote:
> > > here's a task for those of you who want something to do: wrap the
> > > eclipse JDT compiler and make it look/feel like javac from the
> > > command line.
> > >
> > > --
> > > Stefano.
> > >
> > >
> >
> > If there is no objection to use this compiler, I can do that.
> >
> > Please, let me know.
> >
> > patrice
> >
>
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
>
Re: impatient ;)
Posted by Davanum Srinivas <da...@gmail.com>.
go for it!
-- dims
On 5/16/05, Patrice Le Vexier <pl...@bellsouth.net> wrote:
> > here's a task for those of you who want something to do: wrap the
> > eclipse JDT compiler and make it look/feel like javac from the
> > command line.
> >
> > --
> > Stefano.
> >
> >
>
> If there is no objection to use this compiler, I can do that.
>
> Please, let me know.
>
> patrice
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/
Posted by usman bashir <gr...@gmail.com>.
It seems good geir ! and also seems to be following what we planned for
harmony, and it could be a good starting point for us, later on we can make
required changes as we moves on, and it will also help to impatients to work
on and see some thing written down from the air to papers :)
On 5/18/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
> For those that want meaningful subjects lines, here it is and for
> those that are waiting for an architecture discussion - here it is.
>
> Here's the first of the offered VMs. (I've privately mailed Tom van
> Dijck about mudGE so we can look at something else)
>
> I've downloaded and will begin playing with today. Archie, can you
> give a brief overview of structure?
>
> Can we get some discussion about this from those that know about
> about VM architecture?
>
> geir
>
> On May 16, 2005, at 3:22 PM, Archie Cobbs wrote:
> >
> > As mentioned before, and/all of JC [1] is available and I'll
> > be happy to relicense it. All of the code was written by me
> > (though I didn't invent all of the algorithms of course).
> >
> > Some bits I can think of that may be useful, roughly ordered
> > from smaller and more likely to larger and less likely...
> >
> > - Splay tree implementation (splay.c)
> > - String/UTF-8 functions (string.c, utf.c)
> > - ZIP file reader (zip.c)
> > - Class file parser (cf_parse.c)
> > - Native local and global reference code (native_ref.c)
> > - Per-classloader memory allocator (cl_alloc.c)
> > - SableVM thin lock algorithm (lock.c)
> > - Native library loader (native_lib.c)
> > - VM Bootstrap code (vm.c, bootstrap.c)
> > - JNI support (jni_invoke.c, jni_native.c)
> > - Reflection support (reflect.c)
> > - Dynamic invoker (invoke.c)
> > - Threading support (thread.c)
> > - Heap structure and garbage collector (heap.c, gc_root.c,
> > gc_scan.c).
> > - Bytecode interpreter (interp.c)
> > - Class loading, derivation, and resolution (load2.c, derive2.c,
> > resolve.c)
> >
> > There's also an ELF object loader and DWARF2 parser if you need
> > those :-)
> >
> > -Archie
> >
> > [1] http://jcvm.sourceforge.net/
> >
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
--
Usman Bashir
Certified IBM XML Solution Developer
Certified UML Developer
Brainbench Certified Internet Perfessional[advance](BCIP)
Brainbench Certified Java Perfessional (BCJP)
Brainbench Certified .NET Perfessional
Brainbench Ceritified C++ Perfessional (BCCP)
Software engineer IT24
Faculty Member Operation Badar Lahore
Re: JCVM on windows? (Re: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/)
Posted by Archie Cobbs <ar...@dellroad.org>.
Davanum Srinivas wrote:
> Just found this thread on jcvm mailing list:
> http://sourceforge.net/mailarchive/forum.php?thread_id=7007768&forum_id=41274
>
> Can you please comment on effort to port JCVM to windows platforms?
There is none that I know of... it's also not something I could
help with unfortunately because of my complete Windows ignorance.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
JCVM on windows? (Re: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/)
Posted by Davanum Srinivas <da...@gmail.com>.
Archie,
Just found this thread on jcvm mailing list:
http://sourceforge.net/mailarchive/forum.php?thread_id=7007768&forum_id=41274
Can you please comment on effort to port JCVM to windows platforms?
thanks,
dims
On 5/18/05, Archie Cobbs <ar...@dellroad.org> wrote:
> Geir Magnusson Jr. wrote:
> > For those that want meaningful subjects lines, here it is and for those
> > that are waiting for an architecture discussion - here it is.
> >
> > Here's the first of the offered VMs. (I've privately mailed Tom van
> > Dijck about mudGE so we can look at something else)
> >
> > I've downloaded and will begin playing with today. Archie, can you
> > give a brief overview of structure?
> >
> > Can we get some discussion about this from those that know about about
> > VM architecture?
>
> The structure of JC is reasonably straightforward, i.e., the bits
> that are obviously going to be dependent (e.g., heap allocation code
> and GC code) are dependent, but otherwise there shouldn't be more than
> the "usual" amount of cross-dependency between code modules.
>
> Any of the "little" bits such as classfile parsing and ZIP/JAR decoding
> should be very modular and easily transplanted.
>
> The online manual provides some useful info about the overall design.
>
> Cross-cutting design issues include, as you might expect:
>
> - Object layout & lockword bits layout
> - Type, field, & method meta-data structures
> - Thread meta-data
> - How exceptions are thrown & caught
> - Stack frame layout (in JC, it's the same as C), stack unwinding
>
> On the topic of writing the VM in Java: this makes a lot of sense and
> there's no reason it should inherently be slower. In fact, eliminating
> the "impedence mismatch" between VM internal code execution and Java
> code execution was also one of the goals of JC as well (as a result, e.g.,
> the native methods in JC (not including JNI) have zero overhead). And
> JC's code generator is written in Java, so a major portion of JC is
> written in Java too.
>
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs * CTO, Awarix * http://www.awarix.com
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/
Posted by Archie Cobbs <ar...@dellroad.org>.
Geir Magnusson Jr. wrote:
> For those that want meaningful subjects lines, here it is and for those
> that are waiting for an architecture discussion - here it is.
>
> Here's the first of the offered VMs. (I've privately mailed Tom van
> Dijck about mudGE so we can look at something else)
>
> I've downloaded and will begin playing with today. Archie, can you
> give a brief overview of structure?
>
> Can we get some discussion about this from those that know about about
> VM architecture?
The structure of JC is reasonably straightforward, i.e., the bits
that are obviously going to be dependent (e.g., heap allocation code
and GC code) are dependent, but otherwise there shouldn't be more than
the "usual" amount of cross-dependency between code modules.
Any of the "little" bits such as classfile parsing and ZIP/JAR decoding
should be very modular and easily transplanted.
The online manual provides some useful info about the overall design.
Cross-cutting design issues include, as you might expect:
- Object layout & lockword bits layout
- Type, field, & method meta-data structures
- Thread meta-data
- How exceptions are thrown & caught
- Stack frame layout (in JC, it's the same as C), stack unwinding
On the topic of writing the VM in Java: this makes a lot of sense and
there's no reason it should inherently be slower. In fact, eliminating
the "impedence mismatch" between VM internal code execution and Java
code execution was also one of the goals of JC as well (as a result, e.g.,
the native methods in JC (not including JNI) have zero overhead). And
JC's code generator is written in Java, so a major portion of JC is
written in Java too.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/
Posted by Royce Ausburn <es...@gmail.com>.
Tom,
Thanks! =)
Doesn't compile on my powerbook, but it doesn't look like it would be
*too* hard to get working (but I've no real coding experience (CS
student) and have only read the win32/* code)
Will it?
--Royce
On 18/05/2005, at 4:27 PM, Tom van Dijck wrote:
> Hi,
>
> I've had some time today to cleanup and make the VM a standalone
> thing,
> since it pretty much was designed to work together with our Game
> Engine.
> Full game engine (forgive me my commercial plug on the list) can be
> licensed
> as well. It's been used for "Red Ninja: End of Honor" and several
> other
> games.
>
> Please bare in mind that in our Game Engine we use java as a scripting
> language, NOT as our main development language, and thus use a very
> restricted and small runtime. We do NOT fully implement the J2SE
> API, nor do
> we have any intensions to do so.
>
> Anyway, the standalone VM is available on www.mudge.nl/java/
> It is distributed under a somewhat modified version of the ZLIB
> license, so
> for use as reference or as a base for harmony there should be no
> problem
> whatsoever. If there are any problems with the license please let
> me know so
> we can negotiate, all I want is to be notified about what happens
> to my code
> and who uses it.
>
> Tom van Dijck
> mudGE Entertainment
>
>
>
>
>
>> -----Original Message-----
>> From: Geir Magnusson Jr. [mailto:geirm@apache.org]
>> Sent: Wednesday, May 18, 2005 6:35 AM
>> To: harmony-dev@incubator.apache.org
>> Subject: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/
>>
>> For those that want meaningful subjects lines, here it is and
>> for those that are waiting for an architecture discussion -
>> here it is.
>>
>> Here's the first of the offered VMs. (I've privately mailed
>> Tom van Dijck about mudGE so we can look at something else)
>>
>> I've downloaded and will begin playing with today. Archie,
>> can you give a brief overview of structure?
>>
>> Can we get some discussion about this from those that know
>> about about VM architecture?
>>
>> geir
>>
>>
>> On May 16, 2005, at 3:22 PM, Archie Cobbs wrote:
>>
>>>
>>> As mentioned before, and/all of JC [1] is available and
>>>
>> I'll be happy
>>
>>> to relicense it. All of the code was written by me (though I didn't
>>> invent all of the algorithms of course).
>>>
>>> Some bits I can think of that may be useful, roughly ordered from
>>> smaller and more likely to larger and less likely...
>>>
>>> - Splay tree implementation (splay.c)
>>> - String/UTF-8 functions (string.c, utf.c)
>>> - ZIP file reader (zip.c)
>>> - Class file parser (cf_parse.c)
>>> - Native local and global reference code (native_ref.c)
>>> - Per-classloader memory allocator (cl_alloc.c)
>>> - SableVM thin lock algorithm (lock.c)
>>> - Native library loader (native_lib.c)
>>> - VM Bootstrap code (vm.c, bootstrap.c)
>>> - JNI support (jni_invoke.c, jni_native.c)
>>> - Reflection support (reflect.c)
>>> - Dynamic invoker (invoke.c)
>>> - Threading support (thread.c)
>>> - Heap structure and garbage collector (heap.c, gc_root.c,
>>> gc_scan.c).
>>> - Bytecode interpreter (interp.c)
>>> - Class loading, derivation, and resolution (load2.c, derive2.c,
>>> resolve.c)
>>>
>>> There's also an ELF object loader and DWARF2 parser if you
>>>
>> need those
>>
>>> :-)
>>>
>>> -Archie
>>>
>>> [1] http://jcvm.sourceforge.net/
>>>
>>>
>>
>> --
>> Geir Magnusson Jr +1-203-665-6437
>> geirm@apache.org
>>
>>
>>
>
>
>
Re: [arch] mudGE VM ( was Re: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/)
Posted by Tom van Dijck <to...@mudge.nl>.
Just on the side, although you have already got it working I guess...
The JavaPack.exe is just a small tool that serialized a set of classes into
a binary format that is somewhat standarized throughout the engine... a bit
like MFC style object serialisation. nothing fancy though.
The disadvantage is that you loose any compatibility with sun's java class
filespec, and that is has a very native mudge format. Anyway, for now it is
just my replacement of the jar archiving thing.
Tommie.
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@apache.org>
To: <ha...@incubator.apache.org>
Sent: Wednesday, May 18, 2005 3:40 PM
Subject: Re: [arch] mudGE VM ( was Re: [arch] VM Candidate : JC @
http://jcvm.sourceforge.net/)
> Oh, never mind. I didn't RTFM (I did, but missed the top section...)
>
> geir
>
> On May 18, 2005, at 9:14 AM, Geir Magnusson Jr. wrote:
>
> > Tom,
> >
> > I tried to build and got this :
> >
> > BUILD FAILED
> > /Users/geir/dev/apache/harmony/mudGE/mudJavaRuntime/build.xml:35:
> > Execute failed: java.io.IOException: /Users/geir/dev/apache/harmony/
> > mudGE/mudJavaRuntime/JavaPack.exe: not found
> >
> > I asked privately, but might as well ask here for the benefit of
> > others...
> >
> > geir
> >
> >
> > On May 18, 2005, at 8:57 AM, Geir Magnusson Jr. wrote:
> >
> >
> >>
> >> On May 18, 2005, at 4:27 AM, Tom van Dijck wrote:
> >>
> >>
> >>
> >>> Hi,
> >>>
> >>> I've had some time today to cleanup and make the VM a standalone
> >>> thing,
> >>> since it pretty much was designed to work together with our Game
> >>> Engine.
> >>> Full game engine (forgive me my commercial plug on the list) can
> >>> be licensed
> >>> as well. It's been used for "Red Ninja: End of Honor" and several
> >>> other
> >>> games.
> >>>
> >>> Please bare in mind that in our Game Engine we use java as a
> >>> scripting
> >>> language, NOT as our main development language, and thus use a very
> >>> restricted and small runtime. We do NOT fully implement the J2SE
> >>> API, nor do
> >>> we have any intensions to do so.
> >>>
> >>> Anyway, the standalone VM is available on www.mudge.nl/java/
> >>> It is distributed under a somewhat modified version of the ZLIB
> >>> license, so
> >>> for use as reference or as a base for harmony there should be no
> >>> problem
> >>> whatsoever. If there are any problems with the license please let
> >>> me know so
> >>> we can negotiate, all I want is to be notified about what happens
> >>> to my code
> >>> and who uses it.
> >>>
> >>>
> >>>
> >>
> >> Tom, thanks for this. Comments?
> >>
> >> geir
> >>
> >>
> >>
> >>> Tom van Dijck
> >>> mudGE Entertainment
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Geir Magnusson Jr. [mailto:geirm@apache.org]
> >>>> Sent: Wednesday, May 18, 2005 6:35 AM
> >>>> To: harmony-dev@incubator.apache.org
> >>>> Subject: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/
> >>>>
> >>>> For those that want meaningful subjects lines, here it is and
> >>>> for those that are waiting for an architecture discussion -
> >>>> here it is.
> >>>>
> >>>> Here's the first of the offered VMs. (I've privately mailed
> >>>> Tom van Dijck about mudGE so we can look at something else)
> >>>>
> >>>> I've downloaded and will begin playing with today. Archie,
> >>>> can you give a brief overview of structure?
> >>>>
> >>>> Can we get some discussion about this from those that know
> >>>> about about VM architecture?
> >>>>
> >>>> geir
> >>>>
> >>>>
> >>>> On May 16, 2005, at 3:22 PM, Archie Cobbs wrote:
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> As mentioned before, and/all of JC [1] is available and
> >>>>>
> >>>>>
> >>>>>
> >>>> I'll be happy
> >>>>
> >>>>
> >>>>
> >>>>> to relicense it. All of the code was written by me (though I
> >>>>> didn't
> >>>>> invent all of the algorithms of course).
> >>>>>
> >>>>> Some bits I can think of that may be useful, roughly ordered from
> >>>>> smaller and more likely to larger and less likely...
> >>>>>
> >>>>> - Splay tree implementation (splay.c)
> >>>>> - String/UTF-8 functions (string.c, utf.c)
> >>>>> - ZIP file reader (zip.c)
> >>>>> - Class file parser (cf_parse.c)
> >>>>> - Native local and global reference code (native_ref.c)
> >>>>> - Per-classloader memory allocator (cl_alloc.c)
> >>>>> - SableVM thin lock algorithm (lock.c)
> >>>>> - Native library loader (native_lib.c)
> >>>>> - VM Bootstrap code (vm.c, bootstrap.c)
> >>>>> - JNI support (jni_invoke.c, jni_native.c)
> >>>>> - Reflection support (reflect.c)
> >>>>> - Dynamic invoker (invoke.c)
> >>>>> - Threading support (thread.c)
> >>>>> - Heap structure and garbage collector (heap.c, gc_root.c,
> >>>>> gc_scan.c).
> >>>>> - Bytecode interpreter (interp.c)
> >>>>> - Class loading, derivation, and resolution (load2.c, derive2.c,
> >>>>> resolve.c)
> >>>>>
> >>>>> There's also an ELF object loader and DWARF2 parser if you
> >>>>>
> >>>>>
> >>>>>
> >>>> need those
> >>>>
> >>>>
> >>>>
> >>>>> :-)
> >>>>>
> >>>>> -Archie
> >>>>>
> >>>>> [1] http://jcvm.sourceforge.net/
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Geir Magnusson Jr +1-203-665-6437
> >>>> geirm@apache.org
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >> --
> >> Geir Magnusson Jr +1-203-665-6437
> >> geirm@apache.org
> >>
> >>
> >>
> >>
> >
> > --
> > Geir Magnusson Jr +1-203-665-6437
> > geirm@apache.org
> >
> >
> >
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
Re: [arch] mudGE VM ( was Re: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Oh, never mind. I didn't RTFM (I did, but missed the top section...)
geir
On May 18, 2005, at 9:14 AM, Geir Magnusson Jr. wrote:
> Tom,
>
> I tried to build and got this :
>
> BUILD FAILED
> /Users/geir/dev/apache/harmony/mudGE/mudJavaRuntime/build.xml:35:
> Execute failed: java.io.IOException: /Users/geir/dev/apache/harmony/
> mudGE/mudJavaRuntime/JavaPack.exe: not found
>
> I asked privately, but might as well ask here for the benefit of
> others...
>
> geir
>
>
> On May 18, 2005, at 8:57 AM, Geir Magnusson Jr. wrote:
>
>
>>
>> On May 18, 2005, at 4:27 AM, Tom van Dijck wrote:
>>
>>
>>
>>> Hi,
>>>
>>> I've had some time today to cleanup and make the VM a standalone
>>> thing,
>>> since it pretty much was designed to work together with our Game
>>> Engine.
>>> Full game engine (forgive me my commercial plug on the list) can
>>> be licensed
>>> as well. It's been used for "Red Ninja: End of Honor" and several
>>> other
>>> games.
>>>
>>> Please bare in mind that in our Game Engine we use java as a
>>> scripting
>>> language, NOT as our main development language, and thus use a very
>>> restricted and small runtime. We do NOT fully implement the J2SE
>>> API, nor do
>>> we have any intensions to do so.
>>>
>>> Anyway, the standalone VM is available on www.mudge.nl/java/
>>> It is distributed under a somewhat modified version of the ZLIB
>>> license, so
>>> for use as reference or as a base for harmony there should be no
>>> problem
>>> whatsoever. If there are any problems with the license please let
>>> me know so
>>> we can negotiate, all I want is to be notified about what happens
>>> to my code
>>> and who uses it.
>>>
>>>
>>>
>>
>> Tom, thanks for this. Comments?
>>
>> geir
>>
>>
>>
>>> Tom van Dijck
>>> mudGE Entertainment
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Geir Magnusson Jr. [mailto:geirm@apache.org]
>>>> Sent: Wednesday, May 18, 2005 6:35 AM
>>>> To: harmony-dev@incubator.apache.org
>>>> Subject: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/
>>>>
>>>> For those that want meaningful subjects lines, here it is and
>>>> for those that are waiting for an architecture discussion -
>>>> here it is.
>>>>
>>>> Here's the first of the offered VMs. (I've privately mailed
>>>> Tom van Dijck about mudGE so we can look at something else)
>>>>
>>>> I've downloaded and will begin playing with today. Archie,
>>>> can you give a brief overview of structure?
>>>>
>>>> Can we get some discussion about this from those that know
>>>> about about VM architecture?
>>>>
>>>> geir
>>>>
>>>>
>>>> On May 16, 2005, at 3:22 PM, Archie Cobbs wrote:
>>>>
>>>>
>>>>
>>>>>
>>>>> As mentioned before, and/all of JC [1] is available and
>>>>>
>>>>>
>>>>>
>>>> I'll be happy
>>>>
>>>>
>>>>
>>>>> to relicense it. All of the code was written by me (though I
>>>>> didn't
>>>>> invent all of the algorithms of course).
>>>>>
>>>>> Some bits I can think of that may be useful, roughly ordered from
>>>>> smaller and more likely to larger and less likely...
>>>>>
>>>>> - Splay tree implementation (splay.c)
>>>>> - String/UTF-8 functions (string.c, utf.c)
>>>>> - ZIP file reader (zip.c)
>>>>> - Class file parser (cf_parse.c)
>>>>> - Native local and global reference code (native_ref.c)
>>>>> - Per-classloader memory allocator (cl_alloc.c)
>>>>> - SableVM thin lock algorithm (lock.c)
>>>>> - Native library loader (native_lib.c)
>>>>> - VM Bootstrap code (vm.c, bootstrap.c)
>>>>> - JNI support (jni_invoke.c, jni_native.c)
>>>>> - Reflection support (reflect.c)
>>>>> - Dynamic invoker (invoke.c)
>>>>> - Threading support (thread.c)
>>>>> - Heap structure and garbage collector (heap.c, gc_root.c,
>>>>> gc_scan.c).
>>>>> - Bytecode interpreter (interp.c)
>>>>> - Class loading, derivation, and resolution (load2.c, derive2.c,
>>>>> resolve.c)
>>>>>
>>>>> There's also an ELF object loader and DWARF2 parser if you
>>>>>
>>>>>
>>>>>
>>>> need those
>>>>
>>>>
>>>>
>>>>> :-)
>>>>>
>>>>> -Archie
>>>>>
>>>>> [1] http://jcvm.sourceforge.net/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Geir Magnusson Jr +1-203-665-6437
>>>> geirm@apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Geir Magnusson Jr +1-203-665-6437
>> geirm@apache.org
>>
>>
>>
>>
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [arch] mudGE VM ( was Re: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Tom,
I tried to build and got this :
BUILD FAILED
/Users/geir/dev/apache/harmony/mudGE/mudJavaRuntime/build.xml:35:
Execute failed: java.io.IOException: /Users/geir/dev/apache/harmony/
mudGE/mudJavaRuntime/JavaPack.exe: not found
I asked privately, but might as well ask here for the benefit of
others...
geir
On May 18, 2005, at 8:57 AM, Geir Magnusson Jr. wrote:
>
> On May 18, 2005, at 4:27 AM, Tom van Dijck wrote:
>
>
>> Hi,
>>
>> I've had some time today to cleanup and make the VM a standalone
>> thing,
>> since it pretty much was designed to work together with our Game
>> Engine.
>> Full game engine (forgive me my commercial plug on the list) can
>> be licensed
>> as well. It's been used for "Red Ninja: End of Honor" and several
>> other
>> games.
>>
>> Please bare in mind that in our Game Engine we use java as a
>> scripting
>> language, NOT as our main development language, and thus use a very
>> restricted and small runtime. We do NOT fully implement the J2SE
>> API, nor do
>> we have any intensions to do so.
>>
>> Anyway, the standalone VM is available on www.mudge.nl/java/
>> It is distributed under a somewhat modified version of the ZLIB
>> license, so
>> for use as reference or as a base for harmony there should be no
>> problem
>> whatsoever. If there are any problems with the license please let
>> me know so
>> we can negotiate, all I want is to be notified about what happens
>> to my code
>> and who uses it.
>>
>>
>
> Tom, thanks for this. Comments?
>
> geir
>
>
>> Tom van Dijck
>> mudGE Entertainment
>>
>>
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: Geir Magnusson Jr. [mailto:geirm@apache.org]
>>> Sent: Wednesday, May 18, 2005 6:35 AM
>>> To: harmony-dev@incubator.apache.org
>>> Subject: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/
>>>
>>> For those that want meaningful subjects lines, here it is and
>>> for those that are waiting for an architecture discussion -
>>> here it is.
>>>
>>> Here's the first of the offered VMs. (I've privately mailed
>>> Tom van Dijck about mudGE so we can look at something else)
>>>
>>> I've downloaded and will begin playing with today. Archie,
>>> can you give a brief overview of structure?
>>>
>>> Can we get some discussion about this from those that know
>>> about about VM architecture?
>>>
>>> geir
>>>
>>>
>>> On May 16, 2005, at 3:22 PM, Archie Cobbs wrote:
>>>
>>>
>>>>
>>>> As mentioned before, and/all of JC [1] is available and
>>>>
>>>>
>>> I'll be happy
>>>
>>>
>>>> to relicense it. All of the code was written by me (though I didn't
>>>> invent all of the algorithms of course).
>>>>
>>>> Some bits I can think of that may be useful, roughly ordered from
>>>> smaller and more likely to larger and less likely...
>>>>
>>>> - Splay tree implementation (splay.c)
>>>> - String/UTF-8 functions (string.c, utf.c)
>>>> - ZIP file reader (zip.c)
>>>> - Class file parser (cf_parse.c)
>>>> - Native local and global reference code (native_ref.c)
>>>> - Per-classloader memory allocator (cl_alloc.c)
>>>> - SableVM thin lock algorithm (lock.c)
>>>> - Native library loader (native_lib.c)
>>>> - VM Bootstrap code (vm.c, bootstrap.c)
>>>> - JNI support (jni_invoke.c, jni_native.c)
>>>> - Reflection support (reflect.c)
>>>> - Dynamic invoker (invoke.c)
>>>> - Threading support (thread.c)
>>>> - Heap structure and garbage collector (heap.c, gc_root.c,
>>>> gc_scan.c).
>>>> - Bytecode interpreter (interp.c)
>>>> - Class loading, derivation, and resolution (load2.c, derive2.c,
>>>> resolve.c)
>>>>
>>>> There's also an ELF object loader and DWARF2 parser if you
>>>>
>>>>
>>> need those
>>>
>>>
>>>> :-)
>>>>
>>>> -Archie
>>>>
>>>> [1] http://jcvm.sourceforge.net/
>>>>
>>>>
>>>>
>>>
>>> --
>>> Geir Magnusson Jr +1-203-665-6437
>>> geirm@apache.org
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
[arch] mudGE VM ( was Re: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 18, 2005, at 4:27 AM, Tom van Dijck wrote:
> Hi,
>
> I've had some time today to cleanup and make the VM a standalone
> thing,
> since it pretty much was designed to work together with our Game
> Engine.
> Full game engine (forgive me my commercial plug on the list) can be
> licensed
> as well. It's been used for "Red Ninja: End of Honor" and several
> other
> games.
>
> Please bare in mind that in our Game Engine we use java as a scripting
> language, NOT as our main development language, and thus use a very
> restricted and small runtime. We do NOT fully implement the J2SE
> API, nor do
> we have any intensions to do so.
>
> Anyway, the standalone VM is available on www.mudge.nl/java/
> It is distributed under a somewhat modified version of the ZLIB
> license, so
> for use as reference or as a base for harmony there should be no
> problem
> whatsoever. If there are any problems with the license please let
> me know so
> we can negotiate, all I want is to be notified about what happens
> to my code
> and who uses it.
>
Tom, thanks for this. Comments?
geir
> Tom van Dijck
> mudGE Entertainment
>
>
>
>
>
>> -----Original Message-----
>> From: Geir Magnusson Jr. [mailto:geirm@apache.org]
>> Sent: Wednesday, May 18, 2005 6:35 AM
>> To: harmony-dev@incubator.apache.org
>> Subject: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/
>>
>> For those that want meaningful subjects lines, here it is and
>> for those that are waiting for an architecture discussion -
>> here it is.
>>
>> Here's the first of the offered VMs. (I've privately mailed
>> Tom van Dijck about mudGE so we can look at something else)
>>
>> I've downloaded and will begin playing with today. Archie,
>> can you give a brief overview of structure?
>>
>> Can we get some discussion about this from those that know
>> about about VM architecture?
>>
>> geir
>>
>>
>> On May 16, 2005, at 3:22 PM, Archie Cobbs wrote:
>>
>>>
>>> As mentioned before, and/all of JC [1] is available and
>>>
>> I'll be happy
>>
>>> to relicense it. All of the code was written by me (though I didn't
>>> invent all of the algorithms of course).
>>>
>>> Some bits I can think of that may be useful, roughly ordered from
>>> smaller and more likely to larger and less likely...
>>>
>>> - Splay tree implementation (splay.c)
>>> - String/UTF-8 functions (string.c, utf.c)
>>> - ZIP file reader (zip.c)
>>> - Class file parser (cf_parse.c)
>>> - Native local and global reference code (native_ref.c)
>>> - Per-classloader memory allocator (cl_alloc.c)
>>> - SableVM thin lock algorithm (lock.c)
>>> - Native library loader (native_lib.c)
>>> - VM Bootstrap code (vm.c, bootstrap.c)
>>> - JNI support (jni_invoke.c, jni_native.c)
>>> - Reflection support (reflect.c)
>>> - Dynamic invoker (invoke.c)
>>> - Threading support (thread.c)
>>> - Heap structure and garbage collector (heap.c, gc_root.c,
>>> gc_scan.c).
>>> - Bytecode interpreter (interp.c)
>>> - Class loading, derivation, and resolution (load2.c, derive2.c,
>>> resolve.c)
>>>
>>> There's also an ELF object loader and DWARF2 parser if you
>>>
>> need those
>>
>>> :-)
>>>
>>> -Archie
>>>
>>> [1] http://jcvm.sourceforge.net/
>>>
>>>
>>
>> --
>> Geir Magnusson Jr +1-203-665-6437
>> geirm@apache.org
>>
>>
>>
>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
RE: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/
Posted by Tom van Dijck <to...@mudge.nl>.
Hi,
I've had some time today to cleanup and make the VM a standalone thing,
since it pretty much was designed to work together with our Game Engine.
Full game engine (forgive me my commercial plug on the list) can be licensed
as well. It's been used for "Red Ninja: End of Honor" and several other
games.
Please bare in mind that in our Game Engine we use java as a scripting
language, NOT as our main development language, and thus use a very
restricted and small runtime. We do NOT fully implement the J2SE API, nor do
we have any intensions to do so.
Anyway, the standalone VM is available on www.mudge.nl/java/
It is distributed under a somewhat modified version of the ZLIB license, so
for use as reference or as a base for harmony there should be no problem
whatsoever. If there are any problems with the license please let me know so
we can negotiate, all I want is to be notified about what happens to my code
and who uses it.
Tom van Dijck
mudGE Entertainment
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@apache.org]
> Sent: Wednesday, May 18, 2005 6:35 AM
> To: harmony-dev@incubator.apache.org
> Subject: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/
>
> For those that want meaningful subjects lines, here it is and
> for those that are waiting for an architecture discussion -
> here it is.
>
> Here's the first of the offered VMs. (I've privately mailed
> Tom van Dijck about mudGE so we can look at something else)
>
> I've downloaded and will begin playing with today. Archie,
> can you give a brief overview of structure?
>
> Can we get some discussion about this from those that know
> about about VM architecture?
>
> geir
>
>
> On May 16, 2005, at 3:22 PM, Archie Cobbs wrote:
> >
> > As mentioned before, and/all of JC [1] is available and
> I'll be happy
> > to relicense it. All of the code was written by me (though I didn't
> > invent all of the algorithms of course).
> >
> > Some bits I can think of that may be useful, roughly ordered from
> > smaller and more likely to larger and less likely...
> >
> > - Splay tree implementation (splay.c)
> > - String/UTF-8 functions (string.c, utf.c)
> > - ZIP file reader (zip.c)
> > - Class file parser (cf_parse.c)
> > - Native local and global reference code (native_ref.c)
> > - Per-classloader memory allocator (cl_alloc.c)
> > - SableVM thin lock algorithm (lock.c)
> > - Native library loader (native_lib.c)
> > - VM Bootstrap code (vm.c, bootstrap.c)
> > - JNI support (jni_invoke.c, jni_native.c)
> > - Reflection support (reflect.c)
> > - Dynamic invoker (invoke.c)
> > - Threading support (thread.c)
> > - Heap structure and garbage collector (heap.c, gc_root.c,
> > gc_scan.c).
> > - Bytecode interpreter (interp.c)
> > - Class loading, derivation, and resolution (load2.c, derive2.c,
> > resolve.c)
> >
> > There's also an ELF object loader and DWARF2 parser if you
> need those
> > :-)
> >
> > -Archie
> >
> > [1] http://jcvm.sourceforge.net/
> >
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
[arch] VM Candidate : JC @ http://jcvm.sourceforge.net/
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
For those that want meaningful subjects lines, here it is and for
those that are waiting for an architecture discussion - here it is.
Here's the first of the offered VMs. (I've privately mailed Tom van
Dijck about mudGE so we can look at something else)
I've downloaded and will begin playing with today. Archie, can you
give a brief overview of structure?
Can we get some discussion about this from those that know about
about VM architecture?
geir
On May 16, 2005, at 3:22 PM, Archie Cobbs wrote:
>
> As mentioned before, and/all of JC [1] is available and I'll
> be happy to relicense it. All of the code was written by me
> (though I didn't invent all of the algorithms of course).
>
> Some bits I can think of that may be useful, roughly ordered
> from smaller and more likely to larger and less likely...
>
> - Splay tree implementation (splay.c)
> - String/UTF-8 functions (string.c, utf.c)
> - ZIP file reader (zip.c)
> - Class file parser (cf_parse.c)
> - Native local and global reference code (native_ref.c)
> - Per-classloader memory allocator (cl_alloc.c)
> - SableVM thin lock algorithm (lock.c)
> - Native library loader (native_lib.c)
> - VM Bootstrap code (vm.c, bootstrap.c)
> - JNI support (jni_invoke.c, jni_native.c)
> - Reflection support (reflect.c)
> - Dynamic invoker (invoke.c)
> - Threading support (thread.c)
> - Heap structure and garbage collector (heap.c, gc_root.c,
> gc_scan.c).
> - Bytecode interpreter (interp.c)
> - Class loading, derivation, and resolution (load2.c, derive2.c,
> resolve.c)
>
> There's also an ELF object loader and DWARF2 parser if you need
> those :-)
>
> -Archie
>
> [1] http://jcvm.sourceforge.net/
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: impatient ;)
Posted by Peter Donald <pe...@realityforge.org>.
Hi,
I am sure that the code donated could be of use somewhere in the harmony
effort. Don't get too discouraged if no one jumps on it right away
though. The biggest need for harmony is not so much the code that you
have produced but the code that you will produce in the future.
At the start there may seem like a lot of talking gets done with no code
but eventually things will settle down and I hope you are still around
at that point. It would be very useful to get your input on the harmony
JVM in what ever form it takes.
I think someone has already said it on this list (probably Stefano if I
remember him correctly) but the best way to build a community is with
crappy code and great ideas. Community is what is needed to get Harmony
into a state that is likely to succeed.
(Just chiming in as you may not get an immediate response but that
should not discourage you.)
---
Cheers,
Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
Archie Cobbs wrote:
> Stefano Mazzocchi wrote:
>
>> Those who have a JVM and want to donate it under the apache license to
>> seed harmony raise their hands now!
>
>
> As mentioned before, and/all of JC [1] is available and I'll
> be happy to relicense it. All of the code was written by me
> (though I didn't invent all of the algorithms of course).
>
> Some bits I can think of that may be useful, roughly ordered
> from smaller and more likely to larger and less likely...
>
> - Splay tree implementation (splay.c)
> - String/UTF-8 functions (string.c, utf.c)
> - ZIP file reader (zip.c)
> - Class file parser (cf_parse.c)
> - Native local and global reference code (native_ref.c)
> - Per-classloader memory allocator (cl_alloc.c)
> - SableVM thin lock algorithm (lock.c)
> - Native library loader (native_lib.c)
> - VM Bootstrap code (vm.c, bootstrap.c)
> - JNI support (jni_invoke.c, jni_native.c)
> - Reflection support (reflect.c)
> - Dynamic invoker (invoke.c)
> - Threading support (thread.c)
> - Heap structure and garbage collector (heap.c, gc_root.c, gc_scan.c).
> - Bytecode interpreter (interp.c)
> - Class loading, derivation, and resolution (load2.c, derive2.c,
> resolve.c)
>
> There's also an ELF object loader and DWARF2 parser if you need those :-)
>
> -Archie
>
> [1] http://jcvm.sourceforge.net/
>
> __________________________________________________________________________
> Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: impatient ;)
Posted by Stefano Mazzocchi <st...@apache.org>.
Archie Cobbs wrote:
> Stefano Mazzocchi wrote:
>
>> Those who have a JVM and want to donate it under the apache license to
>> seed harmony raise their hands now!
>
>
> As mentioned before, and/all of JC [1] is available and I'll
> be happy to relicense it. All of the code was written by me
> (though I didn't invent all of the algorithms of course).
Archie, you're da man!
> Some bits I can think of that may be useful, roughly ordered
> from smaller and more likely to larger and less likely...
>
> - Splay tree implementation (splay.c)
> - String/UTF-8 functions (string.c, utf.c)
> - ZIP file reader (zip.c)
> - Class file parser (cf_parse.c)
> - Native local and global reference code (native_ref.c)
> - Per-classloader memory allocator (cl_alloc.c)
> - SableVM thin lock algorithm (lock.c)
> - Native library loader (native_lib.c)
> - VM Bootstrap code (vm.c, bootstrap.c)
> - JNI support (jni_invoke.c, jni_native.c)
> - Reflection support (reflect.c)
> - Dynamic invoker (invoke.c)
> - Threading support (thread.c)
> - Heap structure and garbage collector (heap.c, gc_root.c, gc_scan.c).
> - Bytecode interpreter (interp.c)
> - Class loading, derivation, and resolution (load2.c, derive2.c,
> resolve.c)
>
> There's also an ELF object loader and DWARF2 parser if you need those :-)
I would be in favor of having seeding harmony with JC and JikesRVM, the
first written in C and tries to compile ahead of time and the other
written in Java and tries to compile just in time.
What do you think?
--
Stefano.
Re: impatient ;)
Posted by Archie Cobbs <ar...@dellroad.org>.
Stefano Mazzocchi wrote:
> Those who have a JVM and want to donate it under the apache license to
> seed harmony raise their hands now!
As mentioned before, and/all of JC [1] is available and I'll
be happy to relicense it. All of the code was written by me
(though I didn't invent all of the algorithms of course).
Some bits I can think of that may be useful, roughly ordered
from smaller and more likely to larger and less likely...
- Splay tree implementation (splay.c)
- String/UTF-8 functions (string.c, utf.c)
- ZIP file reader (zip.c)
- Class file parser (cf_parse.c)
- Native local and global reference code (native_ref.c)
- Per-classloader memory allocator (cl_alloc.c)
- SableVM thin lock algorithm (lock.c)
- Native library loader (native_lib.c)
- VM Bootstrap code (vm.c, bootstrap.c)
- JNI support (jni_invoke.c, jni_native.c)
- Reflection support (reflect.c)
- Dynamic invoker (invoke.c)
- Threading support (thread.c)
- Heap structure and garbage collector (heap.c, gc_root.c, gc_scan.c).
- Bytecode interpreter (interp.c)
- Class loading, derivation, and resolution (load2.c, derive2.c,
resolve.c)
There's also an ELF object loader and DWARF2 parser if you need those :-)
-Archie
[1] http://jcvm.sourceforge.net/
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: impatient ;)
Posted by Stefano Mazzocchi <st...@apache.org>.
Patrice Le Vexier wrote:
>>here's a task for those of you who want something to do: wrap the
>>eclipse JDT compiler and make it look/feel like javac from the
>>command line.
>>
>>--
>>Stefano.
>>
>>
>
>
> If there is no objection to use this compiler, I can do that.
>
> Please, let me know.
Patrice,
go ahead! We need some code or we'll drawn in email ;-)
--
Stefano.
RE: impatient ;)
Posted by Patrice Le Vexier <pl...@bellsouth.net>.
> here's a task for those of you who want something to do: wrap the
> eclipse JDT compiler and make it look/feel like javac from the
> command line.
>
> --
> Stefano.
>
>
If there is no objection to use this compiler, I can do that.
Please, let me know.
patrice
Re: impatient ;)
Posted by Stefano Mazzocchi <st...@apache.org>.
Here is my take (with all my hats off):
Patrice Le Vexier wrote:
> Dear all,
>
> correct me if i'm wrong, but, to make a J2SE platform, we need:
>
> - a compiler (javac)
let's use eclipse JDT compiler. it rocks, it's fast, has a compatible
license and uses classloaders instead of classpaths (makes it a lot more
flexible and embeddable as a compiler).
> - a JVM (maybe a simple interpreter at first time, then a jit/wat/xxx of the
> death)
Those who have a JVM and want to donate it under the apache license to
seed harmony raise their hands now!
> - class library (classpath as good bet)
Yes, let's go with Classpath.
> - some tools (appletviewer, keytool etc)
I think we need to have "java and javac" the rest will follow when needed.
> - an installer
that's too early :-)
> - ...
>
> I know we're at the very first stage of the development and a lot of stuff
> are currently actively discussed, but is there nothing of this list we can
> begin to code, maybe just as proof of concept, or to try some solutions ?
>
> I'm on windows platform, and i can participate to the compiler or even the
> installer ;)
here's a task for those of you who want something to do: wrap the
eclipse JDT compiler and make it look/feel like javac from the command line.
--
Stefano.