Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm: [14637] rvmroot/branches/RVM-549-OpenJDK

[gnu_andrew]

2008/7/1  <gousios@...>:
> Revision: 14637
>          http://jikesrvm.svn.sourceforge.net/jikesrvm/?rev=14637&view=rev
> Author:   gousios
> Date:     2008-07-01 02:10:55 -0700 (Tue, 01 Jul 2008)
>
> Log Message:
> -----------
> Initial download and build support. Will fail while trying to create rt.jar
>

Some obvious issues:

* Why OpenJDK7 and not OpenJDK6? There is no JDK7 JSR yet.
* Why not use IcedTea to build? Depending on the proprietary Sun JDK
makes this useless for me.
--
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Georgios Gousios]

Hi Andrew,

thanks for your remarks. I will definitely need to look into IcedTea,
although I am afraid that it will need a load of external dependencies
to be pulled in. As for why JDK7, my answer is that I don't want to
invest effort on something that will be deprecated in half a year or so.

Cheers,
Georgios

>> Some obvious issues:
>>
>> * Why OpenJDK7 and not OpenJDK6? There is no JDK7 JSR yet.
>> * Why not use IcedTea to build? Depending on the proprietary Sun JDK
>> makes this useless for me
>>    


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Georgios Gousios]

Hi again,

I 've spent a day trying to get IcedTea to build. I didn't manage to get
the build to proceed past some initial phase of the OpenJDK build
process. The list of dependencies is dire, including Mozilla, GTK,
javac, ecj and gcj, none of which is a dependency of the original
OpenJDK. I hear this has been the experience of Ian Rogers too. I
believe that the complexity of the IcedTea build warrants it being a
class library interface of its own. As this isn't a priority for my
work, and the IcedTea build can already leverage the rest of the OpenJDK
build I produce, I would like to concentrate my efforts on creating an
OpenJDK build in the first instance. Clearly work on integrating IcedTea
can occur in parallel and it would certainly benefit from my efforts.

Regards,
Georgios

> * Why OpenJDK7 and not OpenJDK6? There is no JDK7 JSR yet.
> * Why not use IcedTea to build? Depending on the proprietary Sun JDK
> makes this useless for me.
>  


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[gnu_andrew]

2008/7/1 Georgios Gousios <gousiosg@...>:
> Hi again,
>
> I 've spent a day trying to get IcedTea to build.

Well two hours going by your previous mail, but never mind.

 I didn't manage to get
> the build to proceed past some initial phase of the OpenJDK build
> process. The list of dependencies is dire, including Mozilla, GTK,
> javac, ecj and gcj, none of which is a dependency of the original
> OpenJDK.

Most of these are dependencies of the real OpenJDK.  Essentially, all IcedTea
does is wrap the OpenJDK build process which is the nightmare itself.  The
Mozilla dependency is additional, but you can turn off plugin support if not
required.  I don't think the complete set of dependencies is much different from
that of GNU Classpath.  The main addition is lesstif, Xalan and
Xerces, all of which
are needed by the OpenJDK build rather than the IcedTea wrapper.

I hear this has been the experience of Ian Rogers too. I
> believe that the complexity of the IcedTea build warrants it being a
> class library interface of its own.

The compiled rt.jar from IcedTea IS OpenJDK (to the point that the trademark
license allows it to be called this and the Fedora build has passed
the Java 6 TCK).
There is no need for a separate interface; it would be identical.

? As this isn't a priority for my
> work, and the IcedTea build can already leverage the rest of the OpenJDK
> build I produce, I would like to concentrate my efforts on creating an
> OpenJDK build in the first instance. Clearly work on integrating IcedTea
> can occur in parallel and it would certainly benefit from my efforts.
>

If your build requirements still contain a proprietary JDK, which your
initial commit
seemed to imply, then the work as it stands is useless to me and the
rest of the Free
Java community unfortunately.  This is a pity, as OpenJDK-JikesRVM
integration is
something I'd really like to see.

Please give more feedback than 'it won't build'.  If there are real
issues, they can be discussed
on distro-pkg-dev@... or (preferably) live on #openjdk on
OFTC IRC.  It's better for
the community as a whole that we try and work together.

> Regards,
> Georgios
> 
>> * Why OpenJDK7 and not OpenJDK6? There is no JDK7 JSR yet.
>> * Why not use IcedTea to build? Depending on the proprietary Sun JDK
>> makes this useless for me.
>>
>

The reason to prefer JDK6 is so the result is something that matches a defined
specification.  A resulting binary can be run against the TCK if
licensed and certified
as Java.

I believe the completeness of OpenJDK is the main reason for putting the work in
to adapt from GNU Classpath.  If you're going to use an unspecified
API then you're
actually in a worse situation.  The main advantages of switching to
OpenJDK are only gained through
OpenJDK6 at present.

A year is a long time.

>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Jikesrvm-core mailing list
> Jikesrvm-core@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>

--
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers]

As I understand the issue OpenJDK builds an rvmrt.jar that needs binary
blobs that are closed source. IcedTea builds a near identical rvmrt.jar
that doesn't contain closed source binary blobs, but experience shows
that getting the build going is problematic [1]. Building the rvmrt.jar
is but a small part getting a class library integrated with the RVM,
ideally we're talking about a 10s of lines long ant script [2]. I don't
see a problem of having an IcedTea and OpenJDK script that will do the
rvmrt.jar build process - pick the flavor that suits you. It also
doesn't need to fall on Georgios to write such a script for IcedTea -
this is all open source so patches are welcome. Getting the bootstrap
going is a more important challenge, and one that will generate patches
rather than lose time experimenting with package installations. Of
course we'd like to see an improved, easy to use IcedTea build process.

Regards,
Ian

[1]  both you, I and a number of people from Fedora couldn't build
IcedTea at FOSDEM in an effort to get BrandWeg started. IIRC the Fedora
people claimed to have 1 machine set up the right way for it to build.
[2] including house keeping the Harmony script is 149 lines, the
Classpath script is 279 lines

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[gnu_andrew]

2008/7/1 Ian Rogers <rogers.email@...>:
> As I understand the issue OpenJDK builds an rvmrt.jar that needs binary
> blobs that are closed source. IcedTea builds a near identical rvmrt.jar
> that doesn't contain closed source binary blobs,

No longer true, at least for OpenJDK6 (7 still has a binary sound
dependency I believe).
What IcedTea does is make the build *easier* for mere mortals who
can't remember 30+
environment variables, though this is less of an issue for an
automated build like this.
It also has a number of extra features and patches for issues which
haven't yet made mainline.

but experience shows
> that getting the build going is problematic [1].

This is dated information, and not exactly done under the most ideal
conditions.  Also
the problems you encountered were with OpenJDK not IcedTea (being
failures in building CORBA, etc.)
I for one build IcedTea in some variety on an almost regular basis
these days.  I also have a Gentoo
ebuild for it.  I'm not saying it's easy now, because something of
that side never will be.  But most
of the possible configurations have been tested.

Building the rvmrt.jar
> is but a small part getting a class library integrated with the RVM,
> ideally we're talking about a 10s of lines long ant script [2].

Small in ant script size, certainly not in time.  I can just about deal with
Classpath being built inside JikesRVM, even though it takes ~1/4 of
the build time
up.  Building OpenJDK however is ridiculous - have you checked if
you're also building
HotSpot for instance?

 I don't
> see a problem of having an IcedTea and OpenJDK script that will do the
> rvmrt.jar build process - pick the flavor that suits you.

I'd actually prefer a third flavour -- pointing the build at a JAR
file and having
it do the adaptation from that.  This would then work with whatever
build, and even
(with some luck) maybe also with OpenJDK6. You may also find it works
with the proprietary
JDKs.

 It also
> doesn't need to fall on Georgios to write such a script for IcedTea -
> this is all open source so patches are welcome.

If I had time to patch this right now, I'd have already done an
IcedTea build sometime
back as I've been thinking about it for a while.  This is essentially
what irritates me; that
the work has been done, which is great, but that in doing so a
proprietary dependency has
again been introduced to a supposedly FOSS project.

Getting the bootstrap
> going is a more important challenge, and one that will generate patches
> rather than lose time experimenting with package installations. Of
> course we'd like to see an improved, easy to use IcedTea build process.
>

I agree, so please consider just making it work with an existing JAR
rather than adding
significant build time by downloading and compiling OpenJDK inside
JikesRVM.  Presumably
this also means it now depends on Mercurial as you seem to insist on
using 7 (which isn't addressed here).

> Regards,
> Ian
>
> [1]  both you, I and a number of people from Fedora couldn't build
> IcedTea at FOSDEM in an effort to get BrandWeg started. IIRC the Fedora
> people claimed to have 1 machine set up the right way for it to build.

Clearly this isn't the case if Ubuntu is also packaging it.

> [2] including house keeping the Harmony script is 149 lines, the
> Classpath script is 279 lines

These are meaningless statistics.  It is clear that Classpath would
have a longer
build script simply because it's more stable and there are probably more strange
cases that are being dealt with.

I haven't personally run the Harmony build (and I'm not sure I will,
because I'm not
sure about having yet another set of JDK sources around), but I
believe it uses ant.
So from an ant build it would be simpler, but from experience with
JikesRVM and OpenJDK,
these builds are tricker to get going because of strange requirements
on estoric undocumented
parts of the JDK setup (e.g. com.sun.tools.javac.Main from a tools.jar
in a specific location being
used to compile rather than simply invoking a javac binary)

>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Jikesrvm-core mailing list
> Jikesrvm-core@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>

--
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Georgios Gousios]

Hi,

being in a University and doing a PhD, I am pretty sure that you
understand the differences between developing something for research
purposes and developing something for fun (and/or profit). I need to
hack together a JikesRVM build with OpenJDK, which I am willing (not
required) to share with other people. Now, other people are complaining
that what I do does not make sense, not technically, but license or
community-wise. The question is: should I care? My (current) answer is:
no. When I have 1. something that works 2. enough free time I might want
to look into providing a community acceptable solution. For the time
being, I need to concentrate on 1. Until I get there, the community is
welcome to provide patches against my branch.

Regards,
Georgios

> 2008/7/1 Ian Rogers <rogers.email@...>:
>  
>> As I understand the issue OpenJDK builds an rvmrt.jar that needs binary
>> blobs that are closed source. IcedTea builds a near identical rvmrt.jar
>> that doesn't contain closed source binary blobs,
>>    
>
> No longer true, at least for OpenJDK6 (7 still has a binary sound
> dependency I believe).
> What IcedTea does is make the build *easier* for mere mortals who
> can't remember 30+
> environment variables, though this is less of an issue for an
> automated build like this.
> It also has a number of extra features and patches for issues which
> haven't yet made mainline.
>
> but experience shows
>  
>> that getting the build going is problematic [1].
>>    
>
> This is dated information, and not exactly done under the most ideal
> conditions.  Also
> the problems you encountered were with OpenJDK not IcedTea (being
> failures in building CORBA, etc.)
> I for one build IcedTea in some variety on an almost regular basis
> these days.  I also have a Gentoo
> ebuild for it.  I'm not saying it's easy now, because something of
> that side never will be.  But most
> of the possible configurations have been tested.
>
> Building the rvmrt.jar
>  
>> is but a small part getting a class library integrated with the RVM,
>> ideally we're talking about a 10s of lines long ant script [2].
>>    
>
> Small in ant script size, certainly not in time.  I can just about deal with
> Classpath being built inside JikesRVM, even though it takes ~1/4 of
> the build time
> up.  Building OpenJDK however is ridiculous - have you checked if
> you're also building
> HotSpot for instance?
>
>  I don't
>  
>> see a problem of having an IcedTea and OpenJDK script that will do the
>> rvmrt.jar build process - pick the flavor that suits you.
>>    
>
> I'd actually prefer a third flavour -- pointing the build at a JAR
> file and having
> it do the adaptation from that.  This would then work with whatever
> build, and even
> (with some luck) maybe also with OpenJDK6. You may also find it works
> with the proprietary
> JDKs.
>
>  It also
>  
>> doesn't need to fall on Georgios to write such a script for IcedTea -
>> this is all open source so patches are welcome.
>>    
>
> If I had time to patch this right now, I'd have already done an
> IcedTea build sometime
> back as I've been thinking about it for a while.  This is essentially
> what irritates me; that
> the work has been done, which is great, but that in doing so a
> proprietary dependency has
> again been introduced to a supposedly FOSS project.
>
> Getting the bootstrap
>  
>> going is a more important challenge, and one that will generate patches
>> rather than lose time experimenting with package installations. Of
>> course we'd like to see an improved, easy to use IcedTea build process.
>>
>>    
>
> I agree, so please consider just making it work with an existing JAR
> rather than adding
> significant build time by downloading and compiling OpenJDK inside
> JikesRVM.  Presumably
> this also means it now depends on Mercurial as you seem to insist on
> using 7 (which isn't addressed here).
>
>  
>> Regards,
>> Ian
>>
>> [1]  both you, I and a number of people from Fedora couldn't build
>> IcedTea at FOSDEM in an effort to get BrandWeg started. IIRC the Fedora
>> people claimed to have 1 machine set up the right way for it to build.
>>    
>
> Clearly this isn't the case if Ubuntu is also packaging it.
>
>  
>> [2] including house keeping the Harmony script is 149 lines, the
>> Classpath script is 279 lines
>>    
>
> These are meaningless statistics.  It is clear that Classpath would
> have a longer
> build script simply because it's more stable and there are probably more strange
> cases that are being dealt with.
>
> I haven't personally run the Harmony build (and I'm not sure I will,
> because I'm not
> sure about having yet another set of JDK sources around), but I
> believe it uses ant.
> So from an ant build it would be simpler, but from experience with
> JikesRVM and OpenJDK,
> these builds are tricker to get going because of strange requirements
> on estoric undocumented
> parts of the JDK setup (e.g. com.sun.tools.javac.Main from a tools.jar
> in a specific location being
> used to compile rather than simply invoking a javac binary)
>  

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[gnu_andrew]

On 02/07/2008, Georgios Gousios <gousiosg@...> wrote:

> Hi,
>
>  being in a University and doing a PhD, I am pretty sure that you
>  understand the differences between developing something for research
>  purposes and developing something for fun (and/or profit). I need to
>  hack together a JikesRVM build with OpenJDK, which I am willing (not
>  required) to share with other people. Now, other people are complaining
>  that what I do does not make sense, not technically, but license or
>  community-wise. The question is: should I care? My (current) answer is:
>  no. When I have 1. something that works 2. enough free time I might want
>  to look into providing a community acceptable solution. For the time
>  being, I need to concentrate on 1. Until I get there, the community is
>  welcome to provide patches against my branch.
>
>  Regards,
>  Georgios
>
>

I very much understand your viewpoint.  Sorry if it didn't come across
in this way, but my intention was actually to _save_ time for you.
The IcedTea hackers have spent over a year working with how to build
OpenJDK.  I thought leveraging this would also be helpful in
integrating it into JikesRVM.  This is also why I encouraged you to
join us on IRC.

I also stand by the general view (applying it to GNU Classpath and
presumably Harmony too) that JikesRVM shouldn't be having its own
internal builds of things, but leverage existing system installs. I
can think of lots of advantages to this but no disadvantages (other
than time to switch), so feel free to chime in with some if you have
them.

- It stops the releases being tied to a particular version of the class library.
- It allows much quicker testing of Classpath bugs.  I use CACAO and
JamVM all the time when developing Classpath simply because I can
rebuild Classpath and the VM picks it up.  Doing the equivalent for
the RVM would mean porting the patch over to the RVM build system,
switching it to use CVS sources and then building the whole RVM again.
 I think two of those steps can go (you'd still need to rebuild parts
of the RVM due to bootstrapping/jar patching issues).
- The test machines are then not affected by someone wanting to test a
different version of GNU Classpath with the RVM.
- For OpenJDK, the build time diminishes massively and you don't have
to work out how to build it... It also adds spoke for dealing with
other variants of Sun's JDK.

It does lessen the possibility of patching GNU Classpath, but this is
only a good thing if those patches then get pushed upstream quicker...

GCJ is the only other Classpath VM now (I believe) that bundles its
own version and the developers there would prefer not to -- but it
would take a lot of time to integrate an external build due to the
native build process, etc.  As far as I can see, JikesRVM only updates
the runtime library from Classpath anyway, so why not patch one passed
to it?

Anyway, if you want help with OpenJDK/IcedTea, the door is open.  My
project for VM integration has just been formally approved so I should
shortly have a Mercurial tree to do work on, and it would be good to
collaborate on what would work for JikesRVM in this space.
--
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers]

Andrew John Hughes wrote:
> ...
> - It allows much quicker testing of Classpath bugs.  I use CACAO and
> JamVM all the time when developing Classpath simply because I can
> rebuild Classpath and the VM picks it up.  Doing the equivalent for
> the RVM would mean porting the patch over to the RVM build system,
> switching it to use CVS sources and then building the whole RVM again.
>  I think two of those steps can go (you'd still need to rebuild parts
> of the RVM due to bootstrapping/jar patching issues).
>  

You can of course test changes to Classpath classes by putting the
modified java files in libraryInterface, where the build will pick it up
in preference to the already compiled class in Classpath. This can let
you test changes and then as a final stage put a patch for Classpath
into build/components/patches. For a prototype build, I imagine this
will take a similar time to rebuilding Classpath for JamVM or Cacao.
This way you also get Jikes RVM's test harness.

Ian

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[gnu_andrew]

2008/7/3 Ian Rogers <rogers.email@...>:

> Andrew John Hughes wrote:
>> ...
>> - It allows much quicker testing of Classpath bugs.  I use CACAO and
>> JamVM all the time when developing Classpath simply because I can
>> rebuild Classpath and the VM picks it up.  Doing the equivalent for
>> the RVM would mean porting the patch over to the RVM build system,
>> switching it to use CVS sources and then building the whole RVM again.
>>  I think two of those steps can go (you'd still need to rebuild parts
>> of the RVM due to bootstrapping/jar patching issues).
>>
>
> You can of course test changes to Classpath classes by putting the
> modified java files in libraryInterface, where the build will pick it up
> in preference to the already compiled class in Classpath. This can let
> you test changes and then as a final stage put a patch for Classpath
> into build/components/patches. For a prototype build, I imagine this
> will take a similar time to rebuilding Classpath for JamVM or Cacao.
> This way you also get Jikes RVM's test harness.
>
> Ian
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Jikesrvm-core mailing list
> Jikesrvm-core@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>

This is a better solution which I didn't think of.  However, it still
means doing the change outside the Classpath tree, so tricker to
commit there than using JamVM/CACAO. I may look into system-level
GNU Classpath support if I get chance.

What tests are available in JikesRVM? What would they cover? Most of
my testing tends to be bug-specific and I hope the Mauve testing on builder
picks up any regressions elsewhere.
--
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers]

Andrew John Hughes wrote:

> 2008/7/3 Ian Rogers <rogers.email@...>:
>  
>> Andrew John Hughes wrote:
>>    
>>> ...
>>> - It allows much quicker testing of Classpath bugs.  I use CACAO and
>>> JamVM all the time when developing Classpath simply because I can
>>> rebuild Classpath and the VM picks it up.  Doing the equivalent for
>>> the RVM would mean porting the patch over to the RVM build system,
>>> switching it to use CVS sources and then building the whole RVM again.
>>>  I think two of those steps can go (you'd still need to rebuild parts
>>> of the RVM due to bootstrapping/jar patching issues).
>>>
>>>      
>> You can of course test changes to Classpath classes by putting the
>> modified java files in libraryInterface, where the build will pick it up
>> in preference to the already compiled class in Classpath. This can let
>> you test changes and then as a final stage put a patch for Classpath
>> into build/components/patches. For a prototype build, I imagine this
>> will take a similar time to rebuilding Classpath for JamVM or Cacao.
>> This way you also get Jikes RVM's test harness.
>>
>> Ian
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> Jikesrvm-core mailing list
>> Jikesrvm-core@...
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>>
>>    
>
> This is a better solution which I didn't think of.  However, it still
> means doing the change outside the Classpath tree, so tricker to
> commit there than using JamVM/CACAO. I may look into system-level
> GNU Classpath support if I get chance.
>
> What tests are available in JikesRVM? What would they cover? Most of
> my testing tends to be bug-specific and I hope the Mauve testing on builder
> picks up any regressions elsewhere.
>  

DaCapo, Jikes RVM basic/jni/opt tests, SPEC JVM 2008, closed source
benchmarks... Most can be fired up by just giving a test-run name, the
harness will do all the crawling to pull in and run the benchmark for
you. Mauve really should be part of this harness too [1].

Ian

[1] http://jira.codehaus.org/browse/RVM-158

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[gnu_andrew]

2008/7/3 Ian Rogers <rogers.email@...>:

> Andrew John Hughes wrote:
>> 2008/7/3 Ian Rogers <rogers.email@...>:
>>
>>> Andrew John Hughes wrote:
>>>
>>>> ...
>>>> - It allows much quicker testing of Classpath bugs.  I use CACAO and
>>>> JamVM all the time when developing Classpath simply because I can
>>>> rebuild Classpath and the VM picks it up.  Doing the equivalent for
>>>> the RVM would mean porting the patch over to the RVM build system,
>>>> switching it to use CVS sources and then building the whole RVM again.
>>>>  I think two of those steps can go (you'd still need to rebuild parts
>>>> of the RVM due to bootstrapping/jar patching issues).
>>>>
>>>>
>>> You can of course test changes to Classpath classes by putting the
>>> modified java files in libraryInterface, where the build will pick it up
>>> in preference to the already compiled class in Classpath. This can let
>>> you test changes and then as a final stage put a patch for Classpath
>>> into build/components/patches. For a prototype build, I imagine this
>>> will take a similar time to rebuilding Classpath for JamVM or Cacao.
>>> This way you also get Jikes RVM's test harness.
>>>
>>> Ian
>>>
>>> -------------------------------------------------------------------------
>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>>> Studies have shown that voting for your favorite open source project,
>>> along with a healthy diet, reduces your potential for chronic lameness
>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>> _______________________________________________
>>> Jikesrvm-core mailing list
>>> Jikesrvm-core@...
>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>>>
>>>
>>
>> This is a better solution which I didn't think of.  However, it still
>> means doing the change outside the Classpath tree, so tricker to
>> commit there than using JamVM/CACAO. I may look into system-level
>> GNU Classpath support if I get chance.
>>
>> What tests are available in JikesRVM? What would they cover? Most of
>> my testing tends to be bug-specific and I hope the Mauve testing on builder
>> picks up any regressions elsewhere.
>>
>
> DaCapo, Jikes RVM basic/jni/opt tests,

Are these the pre-commit tests?

SPEC JVM 2008

Hardly a good test right now, given we know parts fail... did you test
the XML fixes yet?

, closed source
> benchmarks... Most can be fired up by just giving a test-run name, the
> harness will do all the crawling to pull in and run the benchmark for
> you.

I'm more interested in which parts of the library get exercised rather
than performance,
as the latter is VM-variable.  I want to spot if something breaks in
some corner of the library.

Mauve really should be part of this harness too [1].
>

I agree.  Have you spoken to twisti? He's done a lot of recent work on
cleaning up how Mauve
operates. I believe he now runs it distributed over several machines with CACAO.

> Ian
>
> [1] http://jira.codehaus.org/browse/RVM-158
>
> -------------------------------------------------------------------------


--
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers]

Andrew John Hughes wrote:

> 2008/7/3 Ian Rogers <rogers.email@...>:
>  
>> Andrew John Hughes wrote:
>>    
>>> 2008/7/3 Ian Rogers <rogers.email@...>:
>>>
>>>      
>>>> Andrew John Hughes wrote:
>>>>
>>>>        
>>>>> ...
>>>>> - It allows much quicker testing of Classpath bugs.  I use CACAO and
>>>>> JamVM all the time when developing Classpath simply because I can
>>>>> rebuild Classpath and the VM picks it up.  Doing the equivalent for
>>>>> the RVM would mean porting the patch over to the RVM build system,
>>>>> switching it to use CVS sources and then building the whole RVM again.
>>>>>  I think two of those steps can go (you'd still need to rebuild parts
>>>>> of the RVM due to bootstrapping/jar patching issues).
>>>>>
>>>>>
>>>>>          
>>>> You can of course test changes to Classpath classes by putting the
>>>> modified java files in libraryInterface, where the build will pick it up
>>>> in preference to the already compiled class in Classpath. This can let
>>>> you test changes and then as a final stage put a patch for Classpath
>>>> into build/components/patches. For a prototype build, I imagine this
>>>> will take a similar time to rebuilding Classpath for JamVM or Cacao.
>>>> This way you also get Jikes RVM's test harness.
>>>>
>>>> Ian
>>>>
>>>> -------------------------------------------------------------------------
>>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>>>> Studies have shown that voting for your favorite open source project,
>>>> along with a healthy diet, reduces your potential for chronic lameness
>>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>>> _______________________________________________
>>>> Jikesrvm-core mailing list
>>>> Jikesrvm-core@...
>>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>>>>
>>>>
>>>>        
>>> This is a better solution which I didn't think of.  However, it still
>>> means doing the change outside the Classpath tree, so tricker to
>>> commit there than using JamVM/CACAO. I may look into system-level
>>> GNU Classpath support if I get chance.
>>>
>>> What tests are available in JikesRVM? What would they cover? Most of
>>> my testing tends to be bug-specific and I hope the Mauve testing on builder
>>> picks up any regressions elsewhere.
>>>
>>>      
>> DaCapo, Jikes RVM basic/jni/opt tests,
>>    
>
> Are these the pre-commit tests?
>  

Pre-commit is a subset of all the tests, it should be run prior to a commit.

> SPEC JVM 2008
>
> Hardly a good test right now, given we know parts fail... did you test
> the XML fixes yet?
>  

SPEC JVM 2008 is largely running with Harmony as a class library, the
exceptions being tests that run out of memory or require a javac
compiler to be configured. The point is that to test this with JamVM or
Cacao you need to get a slower VM, go fetch all the benchmarks yourself,
worry about how to set them up, run them and then work out if the run
was a success. With the RVM you download and build the RVM then run the
test harness with the name of your chosen test; you are presented with
an easy to digest list of success and failures.

I need to figure out the XML fixes. It is certainly the case the
Classpath still cannot run the XML transform SPEC JVM 2008 benchmark. Of
course you can run the harness to see this for yourself.

> , closed source
>  
>> benchmarks... Most can be fired up by just giving a test-run name, the
>> harness will do all the crawling to pull in and run the benchmark for
>> you.
>>    
>
> I'm more interested in which parts of the library get exercised rather
> than performance,
> as the latter is VM-variable.  I want to spot if something breaks in
> some corner of the library.
>  

It is simply not true that the class library performance is just a
VM-variable. In the last years of the RVM we've been removing
optimizations to make the VM more stable, but at the same time we're an
order of magnitude faster than we used to be. We have made some of the
code smarter and added support for SSE operations on Intel, but the main
performance boost  has been down to hard work tuning the class library.
Normally this isn't tuning but just removing silly things like the
allocation per threadlocal get, implementing array versions of charset
encoders and decoders... It's all about getting slow code out of hot
paths, and the main culprits for this are code within java.lang.

The attitude in Harmony is quite different, developers are working on
more optimal security algorithms (an area where Classpath needs work
just to get functionality) and creating classes akin to our Magic class
to allow the compiler to generate multiply-accumulate and other such
operations. Whilst a compiler like GCJ may be able to take until the end
of the earth to compute a more optimal version of a method, in a JIT
compiler we just don't have this luxury.

> Mauve really should be part of this harness too [1].
>  
>
> I agree.  Have you spoken to twisti? He's done a lot of recent work on
> cleaning up how Mauve
> operates. I believe he