From xerxes at zafena.se  Thu Aug  5 05:39:55 2010
From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=)
Date: Thu, 05 Aug 2010 14:39:55 +0200
Subject: Shark hg repositories are now in harmony.
Message-ID: <4C5AB11B.3070802@zafena.se>

Hi all!

I have harmonized all the three different Shark hg repositories in use
by back-porting changes in between them.
The three different shark repositories are:

http://icedtea.classpath.org/hg/shark/hotspot
This are the current "main" Shark hg repository where Gary does his work
and makes sure that shark are ready to be included upstream into OpenJDK.
This repository are targets the latest Hotspot hs19.

http://icedtea.classpath.org/hg/icedtea
This are the icedtea 7 hg repository containing the version of Shark
fixed to work with Hotspot hs18 and OpenJDK 7.
Today i have back-ported and pushed a fix to icedtea6 from the "main"
shark repository to make Shark build with LLVM 2.7 on non-product builds.
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-August/009915.html
I have also pushed some changes to make it in sync with the icedtea6 hg.
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-August/009911.html
- Match Shark in icedtea6, makes OSR work by removing vestigal check.
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-August/009916.html
- Match Shark in icedtea6, Correct suffix for the llvm.atomic.cmp.swap
intrinsic.

http://icedtea.classpath.org/hg/icedtea6
This are the icedtea6 hg repository containing the version of Shark that
currently gets packaged and used by various linux distributions.
This repository are fixed to work with Hotspot hs17.
Today i have backported and pushed a fix to icedtea6 from the "main"
shark repository to make Shark build with LLVM 2.7 on non-product builds.
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-August/009914.html

With these fixes in place all Shark hg repository HEAD's are now in
harmony, they can bootstrap them self nicely and runs rock stable.

Cheers and have a great day!
Xerxes











From gbenson at redhat.com  Thu Aug  5 05:48:30 2010
From: gbenson at redhat.com (Gary Benson)
Date: Thu, 5 Aug 2010 13:48:30 +0100
Subject: Shark hg repositories are now in harmony.
In-Reply-To: <4C5AB11B.3070802@zafena.se>
References: <4C5AB11B.3070802@zafena.se>
Message-ID: <20100805124830.GC3799@redhat.com>

Xerxes R?nby wrote:
> Hi all!
> 
> I have harmonized all the three different Shark hg repositories in
> use by back-porting changes in between them.
[snip]
> With these fixes in place all Shark hg repository HEAD's are now in
> harmony, they can bootstrap them self nicely and runs rock stable.

Awesome work, thank you Xerxes!

Cheers,
Gary

-- 
http://gbenson.net/

From ahughes at redhat.com  Thu Aug  5 08:43:48 2010
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Thu, 5 Aug 2010 16:43:48 +0100
Subject: Shark hg repositories are now in harmony.
In-Reply-To: <4C5AB11B.3070802@zafena.se>
References: <4C5AB11B.3070802@zafena.se>
Message-ID: <AANLkTin3dJSKNOxVULWbWTmrc1LZKNhEOGHUfxGmps+x@mail.gmail.com>

On 5 August 2010 13:39, Xerxes R?nby <xerxes at zafena.se> wrote:
> Hi all!
>
> I have harmonized all the three different Shark hg repositories in use
> by back-porting changes in between them.

Thanks for doing this.

> The three different shark repositories are:
>
> http://icedtea.classpath.org/hg/shark/hotspot
> This are the current "main" Shark hg repository where Gary does his work
> and makes sure that shark are ready to be included upstream into OpenJDK.
> This repository are targets the latest Hotspot hs19.
>
> http://icedtea.classpath.org/hg/icedtea
> This are the icedtea 7 hg repository containing the version of Shark
> fixed to work with Hotspot hs18 and OpenJDK 7.
> Today i have back-ported and pushed a fix to icedtea6 from the "main"
> shark repository to make Shark build with LLVM 2.7 on non-product builds.
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-August/009915.html
> I have also pushed some changes to make it in sync with the icedtea6 hg.
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-August/009911.html
> - Match Shark in icedtea6, makes OSR work by removing vestigal check.
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-August/009916.html
> - Match Shark in icedtea6, Correct suffix for the llvm.atomic.cmp.swap
> intrinsic.
>

Does this actually build now?  It's never worked for me before.

Please be aware that IcedTea7 will be bumping up to the latest
OpenJDK7 now 1.13 is out.

> http://icedtea.classpath.org/hg/icedtea6
> This are the icedtea6 hg repository containing the version of Shark that
> currently gets packaged and used by various linux distributions.

Does Shark get packaged? I wasn't aware of this.

> This repository are fixed to work with Hotspot hs17.
> Today i have backported and pushed a fix to icedtea6 from the "main"
> shark repository to make Shark build with LLVM 2.7 on non-product builds.
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-August/009914.html
>
> With these fixes in place all Shark hg repository HEAD's are now in
> harmony, they can bootstrap them self nicely and runs rock stable.
>
> Cheers and have a great day!

You too!  Great work.

> Xerxes
>
>
>
>
>
>
>
>
>
>
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

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

From xerxes at zafena.se  Sat Aug  7 07:04:21 2010
From: xerxes at zafena.se (Xerxes Ranby)
Date: Sat, 07 Aug 2010 16:04:21 +0200
Subject: Shark hg repositories are now in harmony.
In-Reply-To: <AANLkTin3dJSKNOxVULWbWTmrc1LZKNhEOGHUfxGmps+x@mail.gmail.com>
References: <4C5AB11B.3070802@zafena.se>
	<AANLkTin3dJSKNOxVULWbWTmrc1LZKNhEOGHUfxGmps+x@mail.gmail.com>
Message-ID: <4C5D67E5.1040302@zafena.se>

On 2010-08-05 17:43, Dr Andrew John Hughes wrote:
> On 5 August 2010 13:39, Xerxes R?nby<xerxes at zafena.se>  wrote:
>    
>> Hi all!
>>
>> I have harmonized all the three different Shark hg repositories in use
>> by back-porting changes in between them.
>>      
> Thanks for doing this.
>
>    
>> The three different shark repositories are:
>>
>> http://icedtea.classpath.org/hg/shark/hotspot
>> This are the current "main" Shark hg repository where Gary does his work
>> and makes sure that shark are ready to be included upstream into OpenJDK.
>> This repository are targets the latest Hotspot hs19.
>>
>> http://icedtea.classpath.org/hg/icedtea
>> This are the icedtea 7 hg repository containing the version of Shark
>> fixed to work with Hotspot hs18 and OpenJDK 7.
>> Today i have back-ported and pushed a fix to icedtea6 from the "main"
>> shark repository to make Shark build with LLVM 2.7 on non-product builds.
>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-August/009915.html
>> I have also pushed some changes to make it in sync with the icedtea6 hg.
>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-August/009911.html
>> - Match Shark in icedtea6, makes OSR work by removing vestigal check.
>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-August/009916.html
>> - Match Shark in icedtea6, Correct suffix for the llvm.atomic.cmp.swap
>> intrinsic.
>>
>>      
> Does this actually build now?  It's never worked for me before.
>    
Yes it does build!
I have done sucessfull full bootstrap builds of icedtea 7 + shark on 
ia32 and amd64 using Ubuntu 10.04.
For these two builds I have built Shark in combination with the Ubuntu 
supplied LLVM 2.7 package.

This are how i configured my build on amd64:

$ hg clone http://icedtea.classpath.org/hg/icedtea
$ mkdir icedtea-shark
$ cd icedtea
icedtea$ ./autogen.sh
icedtea$ cd ../icedtea-shark
icedtea-shark$ ../icedtea/configure --enable-shark --with-parallel-jobs=4
icedtea-shark$ time make

... and 96min later after processing docs etc...

IcedTea is served: /media/_/icedtea-shark/openjdk.build
...

icedtea-shark$ ./openjdk.build/j2sdk-image/bin/java -version
java version "1.7.0_89-icedtea"
OpenJDK Runtime Environment (IcedTea7 1.14-pre+r90b892525f1b) (Ubuntu 
build 1.7.0_89-icedtea-b89)
OpenJDK 64-Bit Shark VM (build 18.0-b02, mixed mode)

> Please be aware that IcedTea7 will be bumping up to the latest
> OpenJDK7 now 1.13 is out.
>
>    

Thanks,Ii will keep this in mind and backport any fixes needed from the 
"main" Shark hg if the get a new Hotspot.
Will we get a new Hotspot hs19 after the bump?

>> http://icedtea.classpath.org/hg/icedtea6
>> This are the icedtea6 hg repository containing the version of Shark that
>> currently gets packaged and used by various linux distributions.
>>      
> Does Shark get packaged? I wasn't aware of this.
>    

For what i know, the following distributions package Shark:

Debian, Ubuntu
http://packages.debian.org/search?keywords=openjdk-6-jre-zero
for amd64 armel i386 and powerpc

?ngstrom.
http://www.angstrom-distribution.org/repo/?pkgname=openjdk-6-shark-vm-shark

I have also started to see some Shark success reports where users starts 
to recommend the use of Shark on small embedded servers.
http://plugcomputer.org/plugforum/index.php?topic=1633.0


>    
>> This repository are fixed to work with Hotspot hs17.
>> Today i have backported and pushed a fix to icedtea6 from the "main"
>> shark repository to make Shark build with LLVM 2.7 on non-product builds.
>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-August/009914.html
>>
>> With these fixes in place all Shark hg repository HEAD's are now in
>> harmony, they can bootstrap them self nicely and runs rock stable.
>>
>> Cheers and have a great day!
>>      
> You too!  Great work.
>
>    
>> Xerxes
>>      


From rob at senecass.com  Sat Aug  7 16:21:11 2010
From: rob at senecass.com (Rob Savoye)
Date: Sat, 07 Aug 2010 17:21:11 -0600
Subject: pd_InlineSmallCode ?
Message-ID: <4C5DEA67.4030905@senecass.com>

Following the suggestion to use a pre pr484 revision of icedtea6, I get
this error message which seems unrelated to my changes. I'm wondering if
I need to use a new revision, I'm using this now:

  hg clone -rf50bc2a9120e http://icedtea.classpath.org/hg/icedtea6
  hg di -r373a443db017 ports/hotspot/make | patch -p1 -R

With the full error being:

/home/rsavoye/build/icedtea6/openjdk-ecj/hotspot/src/share/vm/runtime/globals.cpp:34:
error: 'pd_InlineSmallCode' was not declared in this scope
make[7]: *** [globals.o] Error 1

I have the beginnings of a patch to fix the ARM calling convention at:
http://www.senecass.com/projects/OpenJDK-ARM/thumb2-call.patch, but
can't test it till I get past the problem with pd_InlineSmallCode.

All this patch does is add an THREAD_LAST_JAVA_FP offset to the defines
in asm_helper.cpp, and then use that instead of THREAD_LAST_JAVA_SP.
This seems too simple a change, so I'm gonna assume it's not complete. :-)

	- rob -


From mark at klomp.org  Sun Aug  8 01:34:00 2010
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 08 Aug 2010 10:34:00 +0200
Subject: pd_InlineSmallCode ?
In-Reply-To: <4C5DEA67.4030905@senecass.com>
References: <4C5DEA67.4030905@senecass.com>
Message-ID: <1281256440.7386.2.camel@hermans.wildebeest.org>

Hi Rob,

On Sat, 2010-08-07 at 17:21 -0600, Rob Savoye wrote:
> Following the suggestion to use a pre pr484 revision of icedtea6, I get
> this error message which seems unrelated to my changes. I'm wondering if
> I need to use a new revision, I'm using this now:
> 
>   hg clone -rf50bc2a9120e http://icedtea.classpath.org/hg/icedtea6
>   hg di -r373a443db017 ports/hotspot/make | patch -p1 -R
> 
> With the full error being:
> 
> /home/rsavoye/build/icedtea6/openjdk-ecj/hotspot/src/share/vm/runtime/globals.cpp:34:
> error: 'pd_InlineSmallCode' was not declared in this scope
> make[7]: *** [globals.o] Error 1

I don't know/understand the whole issue, but I believe the
pd_InlineSmalCode issue and some other breakage came from changes to the
underlying hotspot version. This thread has some pointers:
http://article.gmane.org/gmane.comp.java.openjdk.distro-packaging.devel/9367

Hope that helps,

Mark


From xerxes at zafena.se  Sun Aug  8 03:05:49 2010
From: xerxes at zafena.se (Xerxes Ranby)
Date: Sun, 08 Aug 2010 12:05:49 +0200
Subject: pd_InlineSmallCode ?
In-Reply-To: <4C5DEA67.4030905@senecass.com>
References: <4C5DEA67.4030905@senecass.com>
Message-ID: <4C5E817D.3050307@zafena.se>

On 2010-08-08 01:21, Rob Savoye wrote:
> Following the suggestion to use a pre pr484 revision of icedtea6, I get
> this error message which seems unrelated to my changes. I'm wondering if
> I need to use a new revision, I'm using this now:
>
>    hg clone -rf50bc2a9120e http://icedtea.classpath.org/hg/icedtea6
>    hg di -r373a443db017 ports/hotspot/make | patch -p1 -R
>
> With the full error being:
>
> /home/rsavoye/build/icedtea6/openjdk-ecj/hotspot/src/share/vm/runtime/globals.cpp:34:
> error: 'pd_InlineSmallCode' was not declared in this scope
> make[7]: *** [globals.o] Error 1
>
> I have the beginnings of a patch to fix the ARM calling convention at:
> http://www.senecass.com/projects/OpenJDK-ARM/thumb2-call.patch, but
> can't test it till I get past the problem with pd_InlineSmallCode.
>    

Just make sure

define_pd_global(intx,  InlineSmallCode,      1000);

exist in

openjdk/hotspot/src/cpu/zero/vm/globals_zero.hpp

http://icedtea.classpath.org/hg/icedtea6/rev/caa91bae0c5c

and you build should continue fine.


> All this patch does is add an THREAD_LAST_JAVA_FP offset to the defines
> in asm_helper.cpp, and then use that instead of THREAD_LAST_JAVA_SP.
> This seems too simple a change, so I'm gonna assume it's not complete. :-)
>    

I love the simplicity of this patch by making use of the asm_helper.

Hi I think you need to update all uses if THREAD_LAST_JAVA_SP to 
THREAD_LAST_JAVA_FP in
ports/hotspot/src/cpu/zero/vm/bytecodes_arm.def
and
ports/hotspot/src/cpu/zero/vm/cppInterpreter_arm.S
as well to fix the interpreter.


> 	- rob -
>
>    

Cheers
Xerxes

From rob at senecass.com  Sun Aug  8 09:44:26 2010
From: rob at senecass.com (Rob Savoye)
Date: Sun, 08 Aug 2010 10:44:26 -0600
Subject: pd_InlineSmallCode ?
In-Reply-To: <4C5E817D.3050307@zafena.se>
References: <4C5DEA67.4030905@senecass.com> <4C5E817D.3050307@zafena.se>
Message-ID: <4C5EDEEA.3000302@senecass.com>

 On 08/08/10 04:05, Xerxes Ranby wrote:
> Just make sure define_pd_global(intx,  InlineSmallCode,      1000);
> exist in openjdk/hotspot/src/cpu/zero/vm/globals_zero.hpp
  Ah, I see, I edited the original file, not the copy in the build tree.
> I love the simplicity of this patch by making use of the asm_helper.
  You mean there was another way of doing this ? :-)
> Hi I think you need to update all uses if THREAD_LAST_JAVA_SP to
> THREAD_LAST_JAVA_FP in
> ports/hotspot/src/cpu/zero/vm/bytecodes_arm.def
> and
> ports/hotspot/src/cpu/zero/vm/cppInterpreter_arm.S
> as well to fix the interpreter.

  Ah, thanks. patched them too now.  This compiled, but I had something
weird with my bootstrap, so make check wouldn't start. I'm reconfiguring
and recompiling, which will take most of the day on a C4, so this is
still untested.The new version of the patch is here:
http://www.senecass.com/projects/OpenJDK-ARM/thumb2-call.patch.

    - rob -



From gbenson at redhat.com  Mon Aug  9 01:30:32 2010
From: gbenson at redhat.com (Gary Benson)
Date: Mon, 9 Aug 2010 09:30:32 +0100
Subject: pd_InlineSmallCode ?
In-Reply-To: <4C5DEA67.4030905@senecass.com>
References: <4C5DEA67.4030905@senecass.com>
Message-ID: <20100809083032.GA3337@redhat.com>

Rob Savoye wrote:
> I have the beginnings of a patch to fix the ARM calling convention at:
> http://www.senecass.com/projects/OpenJDK-ARM/thumb2-call.patch
> 
> All this patch does is add an THREAD_LAST_JAVA_FP offset to
> the defines in asm_helper.cpp, and then use that instead of
> THREAD_LAST_JAVA_SP.  This seems too simple a change, so I'm
> gonna assume it's not complete. :-)

No, it's not.

Firstly, you only need to change THREAD_LAST_JAVA_SP to
THREAD_LAST_JAVA_FP when the value you are setting it to
is zero.

Secondly, when the value is not zero, THREAD_LAST_JAVA_SP
needs setting to the top of the Zero stack, and you need
to order the writes such that THREAD_LAST_JAVA_FP is valid
whenever THREAD_LAST_JAVA_SP is not zero.  Basically it
must match JavaFrameAnchor::set (in javaFrameAnchor_zero.hpp).

Cheers,
Gary

--
http://gbenson.net/

From ahughes at redhat.com  Mon Aug  9 14:49:33 2010
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Mon, 9 Aug 2010 22:49:33 +0100
Subject: Shark hg repositories are now in harmony.
In-Reply-To: <4C5D67E5.1040302@zafena.se>
References: <4C5AB11B.3070802@zafena.se>
	<AANLkTin3dJSKNOxVULWbWTmrc1LZKNhEOGHUfxGmps+x@mail.gmail.com>
	<4C5D67E5.1040302@zafena.se>
Message-ID: <20100809214933.GA25871@rivendell.middle-earth.co.uk>

On 16:04 Sat 07 Aug     , Xerxes Ranby wrote:
> On 2010-08-05 17:43, Dr Andrew John Hughes wrote:
> > On 5 August 2010 13:39, Xerxes R?nby<xerxes at zafena.se>  wrote:
> >    
> >> Hi all!
> >>
> >> I have harmonized all the three different Shark hg repositories in use
> >> by back-porting changes in between them.
> >>      
> > Thanks for doing this.
> >
> >    
> >> The three different shark repositories are:
> >>
> >> http://icedtea.classpath.org/hg/shark/hotspot
> >> This are the current "main" Shark hg repository where Gary does his work
> >> and makes sure that shark are ready to be included upstream into OpenJDK.
> >> This repository are targets the latest Hotspot hs19.
> >>
> >> http://icedtea.classpath.org/hg/icedtea
> >> This are the icedtea 7 hg repository containing the version of Shark
> >> fixed to work with Hotspot hs18 and OpenJDK 7.
> >> Today i have back-ported and pushed a fix to icedtea6 from the "main"
> >> shark repository to make Shark build with LLVM 2.7 on non-product builds.
> >> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-August/009915.html
> >> I have also pushed some changes to make it in sync with the icedtea6 hg.
> >> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-August/009911.html
> >> - Match Shark in icedtea6, makes OSR work by removing vestigal check.
> >> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-August/009916.html
> >> - Match Shark in icedtea6, Correct suffix for the llvm.atomic.cmp.swap
> >> intrinsic.
> >>
> >>      
> > Does this actually build now?  It's never worked for me before.
> >    
> Yes it does build!
> I have done sucessfull full bootstrap builds of icedtea 7 + shark on 
> ia32 and amd64 using Ubuntu 10.04.
> For these two builds I have built Shark in combination with the Ubuntu 
> supplied LLVM 2.7 package.
> 
> This are how i configured my build on amd64:
> 
> $ hg clone http://icedtea.classpath.org/hg/icedtea
> $ mkdir icedtea-shark
> $ cd icedtea
> icedtea$ ./autogen.sh
> icedtea$ cd ../icedtea-shark
> icedtea-shark$ ../icedtea/configure --enable-shark --with-parallel-jobs=4
> icedtea-shark$ time make
> 
> ... and 96min later after processing docs etc...
> 

You know there's a --disable-docs option, right? :-)

> IcedTea is served: /media/_/icedtea-shark/openjdk.build
> ...
> 
> icedtea-shark$ ./openjdk.build/j2sdk-image/bin/java -version
> java version "1.7.0_89-icedtea"
> OpenJDK Runtime Environment (IcedTea7 1.14-pre+r90b892525f1b) (Ubuntu 
> build 1.7.0_89-icedtea-b89)
> OpenJDK 64-Bit Shark VM (build 18.0-b02, mixed mode)
> 
> > Please be aware that IcedTea7 will be bumping up to the latest
> > OpenJDK7 now 1.13 is out.
> >
> >    
> 
> Thanks,Ii will keep this in mind and backport any fixes needed from the 
> "main" Shark hg if the get a new Hotspot.
> Will we get a new Hotspot hs19 after the bump?
> 

I just updated the IcedTea forest (http://hg.openjdk.java.net/icedtea/jdk7) to b104
(last update was b89 to b101).

$ cat hotspot/make/hotspot_version
...
HS_MAJOR_VER=19
HS_MINOR_VER=0
HS_BUILD_NUMBER=05

For now, IcedTea7 still builds against the earlier b89 changesets.

> >> http://icedtea.classpath.org/hg/icedtea6
> >> This are the icedtea6 hg repository containing the version of Shark that
> >> currently gets packaged and used by various linux distributions.
> >>      
> > Does Shark get packaged? I wasn't aware of this.
> >    
> 
> For what i know, the following distributions package Shark:
> 
> Debian, Ubuntu
> http://packages.debian.org/search?keywords=openjdk-6-jre-zero
> for amd64 armel i386 and powerpc
> 
> ?ngstrom.
> http://www.angstrom-distribution.org/repo/?pkgname=openjdk-6-shark-vm-shark
> 
> I have also started to see some Shark success reports where users starts 
> to recommend the use of Shark on small embedded servers.
> http://plugcomputer.org/plugforum/index.php?topic=1633.0
> 

Do we know if anyone has used the packages?

My experiences of Shark suggest that production use is still very premature.

> 
> >    
> >> This repository are fixed to work with Hotspot hs17.
> >> Today i have backported and pushed a fix to icedtea6 from the "main"
> >> shark repository to make Shark build with LLVM 2.7 on non-product builds.
> >> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-August/009914.html
> >>
> >> With these fixes in place all Shark hg repository HEAD's are now in
> >> harmony, they can bootstrap them self nicely and runs rock stable.
> >>
> >> Cheers and have a great day!
> >>      
> > You too!  Great work.
> >
> >    
> >> Xerxes
> >>      
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

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

From gbenson at redhat.com  Tue Aug 10 01:55:50 2010
From: gbenson at redhat.com (Gary Benson)
Date: Tue, 10 Aug 2010 09:55:50 +0100
Subject: Shark hg repositories are now in harmony.
In-Reply-To: <20100809214933.GA25871@rivendell.middle-earth.co.uk>
References: <4C5AB11B.3070802@zafena.se>
	<AANLkTin3dJSKNOxVULWbWTmrc1LZKNhEOGHUfxGmps+x@mail.gmail.com>
	<4C5D67E5.1040302@zafena.se>
	<20100809214933.GA25871@rivendell.middle-earth.co.uk>
Message-ID: <20100810085550.GA3736@redhat.com>

Dr Andrew John Hughes wrote:
> On 16:04 Sat 07 Aug     , Xerxes Ranby wrote:
> > On 2010-08-05 17:43, Dr Andrew John Hughes wrote:
> > > On 5 August 2010 13:39, Xerxes R?nby<xerxes at zafena.se>  wrote:
> > > > http://icedtea.classpath.org/hg/icedtea6
> > > > This are the icedtea6 hg repository containing the version of
> > > > Shark that currently gets packaged and used by various linux
> > > > distributions.
> > > 
> > > Does Shark get packaged? I wasn't aware of this.
> > 
> > For what i know, the following distributions package Shark:
> > 
> > Debian, Ubuntu
> > http://packages.debian.org/search?keywords=openjdk-6-jre-zero
> > for amd64 armel i386 and powerpc
> > 
> > ?ngstrom.
> > http://www.angstrom-distribution.org/repo/?pkgname=openjdk-6-shark-vm-shark
> > 
> > I have also started to see some Shark success reports where users
> > starts to recommend the use of Shark on small embedded servers.
> > http://plugcomputer.org/plugforum/index.php?topic=1633.0
> 
> Do we know if anyone has used the packages?
> 
> My experiences of Shark suggest that production use is still very
> premature.

Really?  What problems are you seeing?

Cheers,
Gary

-- 
http://gbenson.net/

From ahughes at redhat.com  Tue Aug 10 02:36:25 2010
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Tue, 10 Aug 2010 10:36:25 +0100
Subject: Shark hg repositories are now in harmony.
In-Reply-To: <20100810085550.GA3736@redhat.com>
References: <4C5AB11B.3070802@zafena.se>
	<AANLkTin3dJSKNOxVULWbWTmrc1LZKNhEOGHUfxGmps+x@mail.gmail.com>
	<4C5D67E5.1040302@zafena.se>
	<20100809214933.GA25871@rivendell.middle-earth.co.uk>
	<20100810085550.GA3736@redhat.com>
Message-ID: <20100810093625.GA27843@rivendell.middle-earth.co.uk>

On 09:55 Tue 10 Aug     , Gary Benson wrote:
> Dr Andrew John Hughes wrote:
> > On 16:04 Sat 07 Aug     , Xerxes Ranby wrote:
> > > On 2010-08-05 17:43, Dr Andrew John Hughes wrote:
> > > > On 5 August 2010 13:39, Xerxes R?nby<xerxes at zafena.se>  wrote:
> > > > > http://icedtea.classpath.org/hg/icedtea6
> > > > > This are the icedtea6 hg repository containing the version of
> > > > > Shark that currently gets packaged and used by various linux
> > > > > distributions.
> > > > 
> > > > Does Shark get packaged? I wasn't aware of this.
> > > 
> > > For what i know, the following distributions package Shark:
> > > 
> > > Debian, Ubuntu
> > > http://packages.debian.org/search?keywords=openjdk-6-jre-zero
> > > for amd64 armel i386 and powerpc
> > > 
> > > ?ngstrom.
> > > http://www.angstrom-distribution.org/repo/?pkgname=openjdk-6-shark-vm-shark
> > > 
> > > I have also started to see some Shark success reports where users
> > > starts to recommend the use of Shark on small embedded servers.
> > > http://plugcomputer.org/plugforum/index.php?topic=1633.0
> > 
> > Do we know if anyone has used the packages?
> > 
> > My experiences of Shark suggest that production use is still very
> > premature.
> 
> Really?  What problems are you seeing?
> 

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=348
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=371

These are from the last time I tried it; it wouldn't even build which,
given it was regarded as alpha quality, doesn't seem all that surprising.

I've not had chance to try it more recently, and I've no doubt it has
improved since, but I still wouldn't think it's had enough testing to
be recommended for production use.

What's the current status of it on ppc?

> Cheers,
> Gary
> 
> -- 
> http://gbenson.net/

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

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

From gbenson at redhat.com  Tue Aug 10 03:12:02 2010
From: gbenson at redhat.com (Gary Benson)
Date: Tue, 10 Aug 2010 11:12:02 +0100
Subject: Shark hg repositories are now in harmony.
In-Reply-To: <20100810093625.GA27843@rivendell.middle-earth.co.uk>
References: <4C5AB11B.3070802@zafena.se>
	<AANLkTin3dJSKNOxVULWbWTmrc1LZKNhEOGHUfxGmps+x@mail.gmail.com>
	<4C5D67E5.1040302@zafena.se>
	<20100809214933.GA25871@rivendell.middle-earth.co.uk>
	<20100810085550.GA3736@redhat.com>
	<20100810093625.GA27843@rivendell.middle-earth.co.uk>
Message-ID: <20100810101202.GB3736@redhat.com>

Dr Andrew John Hughes wrote:
> On 09:55 Tue 10 Aug     , Gary Benson wrote:
> > Dr Andrew John Hughes wrote:
> > > My experiences of Shark suggest that production use is still
> > > very premature.
> > 
> > Really?  What problems are you seeing?
> 
> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=348
> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=371
> 
> These are from the last time I tried it; it wouldn't even build
> which, given it was regarded as alpha quality, doesn't seem all
> that surprising.

Ah, that was over a year ago, before all the TCK stabilization
work.  348 is a HotSpot version mismatch, I've seen it since in
icedtea6.  And 371, well, the TCK work was on x86_64, so that
platform at least should not segfault.

> I've not had chance to try it more recently, and I've no doubt
> it has improved since, but I still wouldn't think it's had
> enough testing to be recommended for production use.

Xerxes has been testing it extensively on ARM, and he knows of
people who are using it (I think).

> What's the current status of it on ppc?

I'm currently resurrecting my test machine (which got reinstalled)
to check an LLVM fix, so I should know Real Soon Now.  Though
does anybody use ppc (in the open source world) any more?

Cheers,
Gary

-- 
http://gbenson.net/

From ahughes at redhat.com  Tue Aug 10 03:59:13 2010
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Tue, 10 Aug 2010 11:59:13 +0100
Subject: Shark hg repositories are now in harmony.
In-Reply-To: <20100810101202.GB3736@redhat.com>
References: <4C5AB11B.3070802@zafena.se>
	<AANLkTin3dJSKNOxVULWbWTmrc1LZKNhEOGHUfxGmps+x@mail.gmail.com>
	<4C5D67E5.1040302@zafena.se>
	<20100809214933.GA25871@rivendell.middle-earth.co.uk>
	<20100810085550.GA3736@redhat.com>
	<20100810093625.GA27843@rivendell.middle-earth.co.uk>
	<20100810101202.GB3736@redhat.com>
Message-ID: <20100810105912.GC27843@rivendell.middle-earth.co.uk>

On 11:12 Tue 10 Aug     , Gary Benson wrote:
> Dr Andrew John Hughes wrote:
> > On 09:55 Tue 10 Aug     , Gary Benson wrote:
> > > Dr Andrew John Hughes wrote:
> > > > My experiences of Shark suggest that production use is still
> > > > very premature.
> > > 
> > > Really?  What problems are you seeing?
> > 
> > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=348
> > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=371
> > 
> > These are from the last time I tried it; it wouldn't even build
> > which, given it was regarded as alpha quality, doesn't seem all
> > that surprising.
> 
> Ah, that was over a year ago, before all the TCK stabilization
> work.  348 is a HotSpot version mismatch, I've seen it since in
> icedtea6.  And 371, well, the TCK work was on x86_64, so that
> platform at least should not segfault.
> 

Feel free to close them if they've been fixed.  I didn't think the
TCK work was done on IcedTea6 or 7, but on some random snapshot
from your own repository.

> > I've not had chance to try it more recently, and I've no doubt
> > it has improved since, but I still wouldn't think it's had
> > enough testing to be recommended for production use.
> 
> Xerxes has been testing it extensively on ARM, and he knows of
> people who are using it (I think).
> 
> > What's the current status of it on ppc?
> 
> I'm currently resurrecting my test machine (which got reinstalled)
> to check an LLVM fix, so I should know Real Soon Now.  Though
> does anybody use ppc (in the open source world) any more?
> 

Debian and Gentoo still have active ports.  Ubuntu also seems to have
one as far as I can see, and probably other distributions too.  Fedora
is the only one I've heard of dropping it, but then they never really
supported many architectures to begin with.  It's a shame because the
F11 DVD was useful recently to get my ppc box booting again.

The reason I ask is because ppc is the architecture where I could see
Shark being useful personally (currently using CACAO).  I don't really
see the point in using it on x86_64 other than for development.

> Cheers,
> Gary
> 
> -- 
> http://gbenson.net/

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

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

From dalibor.topic at oracle.com  Tue Aug 10 03:44:57 2010
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Tue, 10 Aug 2010 12:44:57 +0200
Subject: Shark hg repositories are now in harmony.
In-Reply-To: <20100810101202.GB3736@redhat.com>
References: <4C5AB11B.3070802@zafena.se>
	<AANLkTin3dJSKNOxVULWbWTmrc1LZKNhEOGHUfxGmps+x@mail.gmail.com>
	<4C5D67E5.1040302@zafena.se>
	<20100809214933.GA25871@rivendell.middle-earth.co.uk>
	<20100810085550.GA3736@redhat.com>
	<20100810093625.GA27843@rivendell.middle-earth.co.uk>
	<20100810101202.GB3736@redhat.com>
Message-ID: <4C612DA9.3020405@oracle.com>

On 8/10/10 12:12 PM, Gary Benson wrote:
>> What's the current status of it on ppc?
> 
> I'm currently resurrecting my test machine (which got reinstalled)
> to check an LLVM fix, so I should know Real Soon Now.  Though
> does anybody use ppc (in the open source world) any more?

Assuming a distribution is building with Shark and running jtreg & mauve tests,
then a look at the test results in their build logs over a longer period of time 
could be an interesting data point.

cheers,
dalibor topic
-- 
<http://www.oracle.com/>
Dalibor Topic
Phone: +49 40 23646738
Oracle

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven

<http://www.oracle.com/commitment>

	

Oracle is committed to developing practices and products that help protect the environment




From gbenson at redhat.com  Tue Aug 10 08:43:21 2010
From: gbenson at redhat.com (Gary Benson)
Date: Tue, 10 Aug 2010 16:43:21 +0100
Subject: Shark hg repositories are now in harmony.
In-Reply-To: <20100810105912.GC27843@rivendell.middle-earth.co.uk>
References: <4C5AB11B.3070802@zafena.se>
	<AANLkTin3dJSKNOxVULWbWTmrc1LZKNhEOGHUfxGmps+x@mail.gmail.com>
	<4C5D67E5.1040302@zafena.se>
	<20100809214933.GA25871@rivendell.middle-earth.co.uk>
	<20100810085550.GA3736@redhat.com>
	<20100810093625.GA27843@rivendell.middle-earth.co.uk>
	<20100810101202.GB3736@redhat.com>
	<20100810105912.GC27843@rivendell.middle-earth.co.uk>
Message-ID: <20100810154320.GC3736@redhat.com>

Dr Andrew John Hughes wrote:
> On 11:12 Tue 10 Aug     , Gary Benson wrote:
> > Dr Andrew John Hughes wrote:
> > > On 09:55 Tue 10 Aug     , Gary Benson wrote:
> > > > Dr Andrew John Hughes wrote:
> > > > > My experiences of Shark suggest that production use is still
> > > > > very premature.
> > > > 
> > > > Really?  What problems are you seeing?
> > > 
> > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=348
> > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=371
> > > 
> > > These are from the last time I tried it; it wouldn't even build
> > > which, given it was regarded as alpha quality, doesn't seem all
> > > that surprising.
> > 
> > Ah, that was over a year ago, before all the TCK stabilization
> > work.  348 is a HotSpot version mismatch, I've seen it since in
> > icedtea6.  And 371, well, the TCK work was on x86_64, so that
> > platform at least should not segfault.
> 
> Feel free to close them if they've been fixed.  I didn't think the
> TCK work was done on IcedTea6 or 7, but on some random snapshot
> from your own repository.

It was on a random snapshot of icedtea6, so that at least should be
ok.

Is there some way of seeing all Zero/Shark bugs in bugzilla?

> > Though does anybody use ppc (in the open source world) any more?
> 
> Debian and Gentoo still have active ports.  Ubuntu also seems to
> have one as far as I can see, and probably other distributions too.
> Fedora is the only one I've heard of dropping it, but then they
> never really supported many architectures to begin with.  It's a
> shame because the F11 DVD was useful recently to get my ppc box
> booting again.
> 
> The reason I ask is because ppc is the architecture where I could
> see Shark being useful personally (currently using CACAO).  I don't
> really see the point in using it on x86_64 other than for
> development.

Quite.

Cheers,
Gary

-- 
http://gbenson.net/

From ahughes at redhat.com  Tue Aug 10 09:09:43 2010
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Tue, 10 Aug 2010 17:09:43 +0100
Subject: Shark hg repositories are now in harmony.
In-Reply-To: <20100810154320.GC3736@redhat.com>
References: <4C5AB11B.3070802@zafena.se>
	<AANLkTin3dJSKNOxVULWbWTmrc1LZKNhEOGHUfxGmps+x@mail.gmail.com>
	<4C5D67E5.1040302@zafena.se>
	<20100809214933.GA25871@rivendell.middle-earth.co.uk>
	<20100810085550.GA3736@redhat.com>
	<20100810093625.GA27843@rivendell.middle-earth.co.uk>
	<20100810101202.GB3736@redhat.com>
	<20100810105912.GC27843@rivendell.middle-earth.co.uk>
	<20100810154320.GC3736@redhat.com>
Message-ID: <20100810160943.GA10867@rivendell.middle-earth.co.uk>

On 16:43 Tue 10 Aug     , Gary Benson wrote:
> Dr Andrew John Hughes wrote:
> > On 11:12 Tue 10 Aug     , Gary Benson wrote:
> > > Dr Andrew John Hughes wrote:
> > > > On 09:55 Tue 10 Aug     , Gary Benson wrote:
> > > > > Dr Andrew John Hughes wrote:
> > > > > > My experiences of Shark suggest that production use is still
> > > > > > very premature.
> > > > > 
> > > > > Really?  What problems are you seeing?
> > > > 
> > > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=348
> > > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=371
> > > > 
> > > > These are from the last time I tried it; it wouldn't even build
> > > > which, given it was regarded as alpha quality, doesn't seem all
> > > > that surprising.
> > > 
> > > Ah, that was over a year ago, before all the TCK stabilization
> > > work.  348 is a HotSpot version mismatch, I've seen it since in
> > > icedtea6.  And 371, well, the TCK work was on x86_64, so that
> > > platform at least should not segfault.
> > 
> > Feel free to close them if they've been fixed.  I didn't think the
> > TCK work was done on IcedTea6 or 7, but on some random snapshot
> > from your own repository.
> 
> It was on a random snapshot of icedtea6, so that at least should be
> ok.
> 

Oh right.  I thought you'd tested your shark tree.

> Is there some way of seeing all Zero/Shark bugs in bugzilla?
> 

http://icedtea.classpath.org/bugzilla/buglist.cgi?query_format=advanced&component=Shark&component=Zero

assuming they are correctly categorised (I triaged through them a few months back but new ones may be missing).

> > > Though does anybody use ppc (in the open source world) any more?
> > 
> > Debian and Gentoo still have active ports.  Ubuntu also seems to
> > have one as far as I can see, and probably other distributions too.
> > Fedora is the only one I've heard of dropping it, but then they
> > never really supported many architectures to begin with.  It's a
> > shame because the F11 DVD was useful recently to get my ppc box
> > booting again.
> > 
> > The reason I ask is because ppc is the architecture where I could
> > see Shark being useful personally (currently using CACAO).  I don't
> > really see the point in using it on x86_64 other than for
> > development.
> 
> Quite.
> 
> Cheers,
> Gary
> 
> -- 
> http://gbenson.net/

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

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

From rob at senecass.com  Fri Aug 13 12:22:38 2010
From: rob at senecass.com (Rob Savoye)
Date: Fri, 13 Aug 2010 13:22:38 -0600
Subject: latest pr323 patch for ARM
Message-ID: <4C659B7E.7060207@senecass.com>

I've got a greatly improved patch for pr323 to fix the ARM assembler:
	http://www.senecass.com/projects/OpenJDK-ARM/thumb2-081310.patch

At least for me, with this patch, the fast sanity check does this:

./openjdk-ecj/build/linux-arm/bin/java -Xcheck:jni -version java version
"1.6.0_19"
OpenJDK Runtime Environment (IcedTea6 1.9pre+rf50bc2a9120e) (Ubuntu
build 1.6.0_19-b19)
OpenJDK Zero VM (build 16.0-b13, interpreted mode)

I did this by just rebuilding Hotspot, but since I'm paranoid, I'll do a
full "make clean all" to make sure it everything is truly ok on the ARM.
I believe this properly handles the FP vs SP change, although it's
possible there are subtle bugs still. More testing will tell, but I as
that takes about 2-3 days on a BeagleBoard, I figured I'd post this now.

	- rob -

From gbenson at redhat.com  Mon Aug 16 02:15:05 2010
From: gbenson at redhat.com (Gary Benson)
Date: Mon, 16 Aug 2010 10:15:05 +0100
Subject: latest pr323 patch for ARM
In-Reply-To: <4C659B7E.7060207@senecass.com>
References: <4C659B7E.7060207@senecass.com>
Message-ID: <20100816091504.GA3329@redhat.com>

Rob Savoye wrote:
> I've got a greatly improved patch for pr323 to fix the ARM assembler:
> 	http://www.senecass.com/projects/OpenJDK-ARM/thumb2-081310.patch

All the bits that look like this:

  @@ -1814,7 +1814,7 @@
   	mov	r3, #0
   
   	ldr	r2, [tmp_xxx, #THREAD_TOP_ZERO_FRAME]
  -	str	r3, [tmp_xxx, #THREAD_LAST_JAVA_SP]
  +	str	r3, [tmp_xxx, #THREAD_LAST_JAVA_FP]
   	ldr	r0, [istate, #ISTATE_METHOD]
   	ldr	r3, [r2, #0]
   	ldrh	r0, [r0, #40]

are wrong, I think.  To clear the frame pointer, you set
last_Java_*sp* to zero.  So that should have been left as is.
If last_Java_sp is zero then the frame pointer is cleared and
the value of last_Java_fp is never read.

By the way, it's worth trying this with a debug build, so that
assertions are on.

Cheers,
Gary

-- 
http://gbenson.net/

From rob at senecass.com  Mon Aug 16 19:12:11 2010
From: rob at senecass.com (Rob Savoye)
Date: Mon, 16 Aug 2010 20:12:11 -0600
Subject: latest pr323 patch for ARM
In-Reply-To: <20100816091504.GA3329@redhat.com>
References: <4C659B7E.7060207@senecass.com> <20100816091504.GA3329@redhat.com>
Message-ID: <4C69EFFB.2070309@senecass.com>

On 08/16/10 03:15, Gary Benson wrote:

> are wrong, I think.  To clear the frame pointer, you set
> last_Java_*sp* to zero.  So that should have been left as is.
> If last_Java_sp is zero then the frame pointer is cleared and
> the value of last_Java_fp is never read.
> 
> By the way, it's worth trying this with a debug build, so that
> assertions are on.

I reverted bytecodes_arm.def, as all the changes I made in that file
were like this example. (setting the FP instead of the SP to 0). But if
SP is being set to a non 0 value, then I left the other changes alone.
Those follow the sequence of setting SP to 0, then set FP to the top
Zero frame, and SP to the top of the stack. (THREAD_JAVA_SP)

I have a newer patch with these changes incorporated at:
http://www.senecass.com/projects/OpenJDK-ARM/thumb2-081610.patch. I used
"hg log -p -r", which I hope is ok. I'm slowly learning how to use
mercurial.

Right now, even with this patch it still segfaults here:
	do_aload_0 () at ./bytecodes_arm.s:419

Which it did before and after this patch is applied.

Looking at the contrib/mixtec-hacks.patch, I see this patch to
openjdk/hotspot/make/linux/makefiles/product.make:

-SYSDEFS += -DPRODUCT
-VERSION = optimized
+SYSDEFS += -DASSERT
+VERSION = mixtec

Which I assume will do the trick. I'll enable that and do a rebuild tonight.

	- rob -

From xerxes at zafena.se  Fri Aug 20 02:52:42 2010
From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=)
Date: Fri, 20 Aug 2010 11:52:42 +0200
Subject: latest pr323 patch for ARM - MKBC Bytecode Interpreter generator
	documentation
In-Reply-To: <4C69EFFB.2070309@senecass.com>
References: <4C659B7E.7060207@senecass.com> <20100816091504.GA3329@redhat.com>
	<4C69EFFB.2070309@senecass.com>
Message-ID: <4C6E506A.3050202@zafena.se>

On 2010-08-17 04:12, Rob Savoye wrote:
> On 08/16/10 03:15, Gary Benson wrote:
>
>   
>> are wrong, I think.  To clear the frame pointer, you set
>> last_Java_*sp* to zero.  So that should have been left as is.
>> If last_Java_sp is zero then the frame pointer is cleared and
>> the value of last_Java_fp is never read.
>>
>> By the way, it's worth trying this with a debug build, so that
>> assertions are on.
>>     
> I reverted bytecodes_arm.def, as all the changes I made in that file
> were like this example. (setting the FP instead of the SP to 0). But if
> SP is being set to a non 0 value, then I left the other changes alone.
> Those follow the sequence of setting SP to 0, then set FP to the top
> Zero frame, and SP to the top of the stack. (THREAD_JAVA_SP)
>
> I have a newer patch with these changes incorporated at:
> http://www.senecass.com/projects/OpenJDK-ARM/thumb2-081610.patch. I used
> "hg log -p -r", which I hope is ok. I'm slowly learning how to use
> mercurial.
>
> Right now, even with this patch it still segfaults here:
> 	do_aload_0 () at ./bytecodes_arm.s:419
>
> Which it did before and after this patch is applied.
>
> Looking at the contrib/mixtec-hacks.patch, I see this patch to
> openjdk/hotspot/make/linux/makefiles/product.make:
>
> -SYSDEFS += -DPRODUCT
> -VERSION = optimized
> +SYSDEFS += -DASSERT
> +VERSION = mixtec
>
> Which I assume will do the trick. I'll enable that and do a rebuild tonight.
>
> 	- rob -
>   

The latest documentation available on the MKBC Bytecode Interpreter
generator are published on Ed's homepage:
http://camswl.com/openjdk/
  http://www.zen111407.zen.co.uk/openjdk_home.htm#BIG
  http://www.zen111407.zen.co.uk/openjdk/mkbc.htm

I am sure you will find this documentation useful while hacking on the
interpreters dispatch code.

Cheers and have a great day
Xerxes



From rob at senecass.com  Wed Aug 25 19:20:58 2010
From: rob at senecass.com (Rob Savoye)
Date: Wed, 25 Aug 2010 20:20:58 -0600
Subject: updated ARM assembler patch
Message-ID: <4C75CF8A.8000102@senecass.com>

I've got a new version of the ARM assembler patch at:
http://www.senecass.com/projects/OpenJDK-ARM/thumb2-082510.patch
I've been battling with register allocations, as it turns out minor
changes cause segfaults. Even running gdb causes problems depending
where I set breakpoints.

While this version has a segfault at the end, it's working better then
the previous patch as far as I can tell. I'm not 100% sure what the
output of the gamma test should look like, but hope all these hex
numbers are what it's supposed to do. :-)

java full version "1.6.0_18-b18"
java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8) (6b18-1.8-2ubuntu2)
OpenJDK Zero VM (build 16.0-b13, mixed mode)

 1. A1 B5 C8 D6 E3 F7 G2 H4
 2. A1 B6 C8 D3 E7 F4 G2 H5
 3. A1 B7 C4 D6 E8 F2 G5 H3
 4. A1 B7 C5 D8 E2 F4 G6 H3
 5. A2 B4 C6 D8 E3 F1 G7 H5
 6. A2 B5 C7 D1 E3 F8 G6 H4
 7. A2 B5 C7 D4 E1 F8 G6 H3
 8. A2 B6 C1 D7 E4 F8 G3 H5
 9. A2 B6 C8 D3 E1 F4 G7 H5
10. A2 B7 C3 D6 E8 F5 G1 H4
11. A2 B7 C5 D8 E1 F4 G6 H3
12. A2 B8 C6 D1 E3 F5 G7 H4
13. A3 B1 C7 D5 E8 F2 G4 H6
14. A3 B5 C2 D8 E1 F7 G4 H6
15. A3 B5 C2 D8 E6 F4 G7 H1
16. A3 B5 C7 D1 E4 F2 G8 H6
17. A3 B5 C8 D4 E1 F7 G2 H6
18. A3 B6 C2 D5 E8 F1 G7 H4
19. A3 B6 C2 D7 E1 F4 G8 H5
20. A3 B6 C2 D7 E5 F1 G8 H4
21. A3 B6 C4 D1 E8 F5 G7 H2
22. A3 B6 C4 D2 E8 F5 G7 H1
23. A3 B6 C8 D1 E4 F7 G5 H2
24. A3 B6 C8 D1 E5 F7 G2 H4
25. A3 B6 C8 D2 E4 F1 G7 H5
26. A3 B7 C2 D8 E5 F1 G4 H6
27. A3 B7 C2 D8 E6 F4 G1 H5
28. A3 B8 C4 D7 E1 F6 G2 H5
29. A4 B1 C5 D8 E2 F7 G3 H6
30. A4 B1 C5 D8 E6 F3 G7 H2
31. A4 B2 C5 D8 E6 F1 G3 H7
32. A4 B2 C7 D3 E6 F8 G1 H5
33. A4 B2 C7 D3 E6 F8 G5 H1
34. A4 B2 C7 D5 E1 F8 G6 H3
35. A4 B2 C8 D5 E7 F1 G3 H6
36. A4 B2 C8 D6 E1 F3 G5 H7
37. A4 B6 C1 D5 E2 F8 G3 H7
38. A4 B6 C8 D2 E7 F1 G3 H5
39. A4 B6 C8 D3 E1 F7 G5 H2
40. A4 B7 C1 D8 E5 F2 G6 H3
41. A4 B7 C3 D8 E2 F5 G1 H6
42. A4 B7 C5 D2 E6 F1 G3 H8
43. A4 B7 C5 D3 E1 F6 G8 H2
44. A4 B8 C1 D3 E6 F2 G7 H5
45. A4 B8 C1 D5 E7 F2 G6 H3
46. A4 B8 C5 D3 E1 F7 G2 H6
47. A5 B1 C4 D6 E8 F2 G7 H3
48. A5 B1 C8 D4 E2 F7 G3 H6
49. A5 B1 C8 D6 E3 F7 G2 H4
50. A5 B2 C4 D6 E8 F3 G1 H7
51. A5 B2 C4 D7 E3 F8 G6 H1
52. A5 B2 C6 D1 E7 F4 G8 H3
53. A5 B2 C8 D1 E4 F7 G3 H6
54. A5 B3 C1 D6 E8 F2 G4 H7
55. A5 B3 C1 D7 E2 F8 G6 H4
56. A5 B3 C8 D4 E7 F1 G6 H2
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException:
	at Queens.try_i(Queens.java:33)
	at Queens.try_i(Queens.java:41)
	at Queens.try_i(Queens.java:41)
	at Queens.try_i(Queens.java:41)
	at Queens.try_i(Queens.java:41)
	at Queens.try_i(Queens.java:41)
	at Queens.try_i(Queens.java:41)
	at Queens.main(Queens.java:65)
make[4]: *** [productzero] Error 1
make[4]: Leaving directory
`/wd/rsavoye/build/openjdk/build/linux-arm/hotspot/outputdir'
make[3]: *** [generic_buildzero] Error 2
make[3]: Leaving directory `/wd/rsavoye/build/openjdk/hotspot/make'
make[2]: *** [productzero] Error 2
make[2]: Leaving directory `/wd/rsavoye/build/openjdk/hotspot/make'
make[1]: *** [hotspot-build] Error 2
make[1]: Leaving directory `/wd/rsavoye/build/openjdk'
make: *** [stamps/icedtea.stamp] Error 2

I've been having some weird reproducibility issues with this revision
and with an older one where gamma doesn't always want to start.
Sometimes it does, and sometimes it doesn't with this error:

Exception in thread "main" java.lang.NoClassDefFoundError: Queens
Caused by: java.lang.ClassNotFoundException: Queens
	at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:266)

If I do a make, it runs once, then I get this till I make again. This
makes it extremely difficult to debug. It's been pretty stable until
today, I'm not sure what changed, as I don't think it has anything to do
with my patch.

	- rob -

From xerxes at zafena.se  Thu Aug 26 01:46:23 2010
From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=)
Date: Thu, 26 Aug 2010 10:46:23 +0200
Subject: updated ARM assembler patch
In-Reply-To: <4C75CF8A.8000102@senecass.com>
References: <4C75CF8A.8000102@senecass.com>
Message-ID: <4C7629DF.5040404@zafena.se>

On 2010-08-26 04:20, Rob Savoye wrote:
> I've got a new version of the ARM assembler patch at:
> http://www.senecass.com/projects/OpenJDK-ARM/thumb2-082510.patch
> I've been battling with register allocations, as it turns out minor
> changes cause segfaults. Even running gdb causes problems depending
> where I set breakpoints.
>
> While this version has a segfault at the end, it's working better then
> the previous patch as far as I can tell. I'm not 100% sure what the
> output of the gamma test should look like, but hope all these hex
> numbers are what it's supposed to do. :-)
>   

These "hex" numbers are actually referring to positions on a 8x8 chess
table.
The Queens program are designed to find all 92 possible solutions to the
Eight queens chess puzzle.
http://en.wikipedia.org/wiki/Eight_queens_puzzle

your output below have actually solved 52 of the 92 possible solutions
before it bailed out.

I have investigated this a bit closer to try triage what went wrong and
I have found out that the  java.lang.ArrayIndexOutOfBoundsException
below are caused by a some kind of mis-compilation when the thumb2 JIT
kicks in.

I Tested to do a build with the assembler interpreter enabled
-DHOTSPOT_ASM and the thumb2 jit disabled -DDISABLE_THUMB2 to check if
the ASM interpreter worked and yes it works and finds all 92 possible
solutions to this Queens puzzle! I have also verified that by using your
patch the Icedtea6 pr323 are fixed when using the ARM ASM interpreter!
Verry cool!

> java full version "1.6.0_18-b18"
> java version "1.6.0_18"
> OpenJDK Runtime Environment (IcedTea6 1.8) (6b18-1.8-2ubuntu2)
> OpenJDK Zero VM (build 16.0-b13, mixed mode)
>
>  1. A1 B5 C8 D6 E3 F7 G2 H4
>  2. A1 B6 C8 D3 E7 F4 G2 H5
... snip
> 55. A5 B3 C1 D7 E2 F8 G6 H4
> 56. A5 B3 C8 D4 E7 F1 G6 H2
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException:
> 	at Queens.try_i(Queens.java:33)
> 	at Queens.try_i(Queens.java:41)
> 	at Queens.try_i(Queens.java:41)
> 	at Queens.try_i(Queens.java:41)
> 	at Queens.try_i(Queens.java:41)
> 	at Queens.try_i(Queens.java:41)
> 	at Queens.try_i(Queens.java:41)
> 	at Queens.main(Queens.java:65)
> make[4]: *** [productzero] Error 1
> make[4]: Leaving directory
> `/wd/rsavoye/build/openjdk/build/linux-arm/hotspot/outputdir'
> make[3]: *** [generic_buildzero] Error 2
> make[3]: Leaving directory `/wd/rsavoye/build/openjdk/hotspot/make'
> make[2]: *** [productzero] Error 2
> make[2]: Leaving directory `/wd/rsavoye/build/openjdk/hotspot/make'
> make[1]: *** [hotspot-build] Error 2
> make[1]: Leaving directory `/wd/rsavoye/build/openjdk'
> make: *** [stamps/icedtea.stamp] Error 2
>
> I've been having some weird reproducibility issues with this revision
> and with an older one where gamma doesn't always want to start.
> Sometimes it does, and sometimes it doesn't with this error:
>
> Exception in thread "main" java.lang.NoClassDefFoundError: Queens
> Caused by: java.lang.ClassNotFoundException: Queens
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
> 	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
>   

1. are you located in the
openjdk/build/linux-arm/hotspot/outputdir/linux_arm_zero/product/ dir
when running test_gamma?
2. are you using the test_gamma script to launch gamma ?

When i test gamma manually i simply do this:
cd openjdk/build/linux-arm/hotspot/outputdir/linux_arm_zero/product/
./test_gamma

and it works for me all the time.

> If I do a make, it runs once, then I get this till I make again. This
> makes it extremely difficult to debug. It's been pretty stable until
> today, I'm not sure what changed, as I don't think it has anything to do
> with my patch.
>
> 	- rob -
>   
We have to take a closer look on the thumb2.cpp to check what went wrong
when using the ASM interpreter in combination with the thumb2 JIT.

The patched ASM interpreter now work nicely when used standalone!

Cheers
Xerxes


From gbenson at redhat.com  Fri Aug 27 01:29:42 2010
From: gbenson at redhat.com (Gary Benson)
Date: Fri, 27 Aug 2010 09:29:42 +0100
Subject: updated ARM assembler patch
In-Reply-To: <4C75CF8A.8000102@senecass.com>
References: <4C75CF8A.8000102@senecass.com>
Message-ID: <20100827082942.GB3376@redhat.com>

Rob Savoye wrote:
> I've got a new version of the ARM assembler patch at:
> http://www.senecass.com/projects/OpenJDK-ARM/thumb2-082510.patch

These bits look right:

-     str  r0, [r9, #THREAD_LAST_JAVA_SP]
+
+@      set SP to zero before setting the FP
+       str r5, [r9, #THREAD_LAST_JAVA_SP]
+@      set FP to the top zero frame
+       str r0, [r9, #THREAD_LAST_JAVA_FP]
+@      get the stack pointer, use r1 as it gets reset
+       ldr r1, [r9, #THREAD_JAVA_SP]
+@      set SP to the current top of stack
+       str r1, [r9, #THREAD_LAST_JAVA_SP]

(assuming that r1 is the _Zero_ stack pointer, not the ABI stack pointer.)
These bits are still wrong:

-     str  r5, [r9, #THREAD_LAST_JAVA_SP]
+
+@      set FP to the top zero frame, which is 0
+       str r5, [r9, #THREAD_LAST_JAVA_FP]
+

In fact, the original was right (you clear last_Java_SP to wipe the frame
anchor.)

Cheers,
Gary

-- 
http://gbenson.net/

From rob at senecass.com  Tue Aug 31 19:31:54 2010
From: rob at senecass.com (Rob Savoye)
Date: Tue, 31 Aug 2010 20:31:54 -0600
Subject: updated ARM assembler patch
In-Reply-To: <20100827082942.GB3376@redhat.com>
References: <4C75CF8A.8000102@senecass.com> <20100827082942.GB3376@redhat.com>
Message-ID: <4C7DBB1A.2060108@senecass.com>

On 08/27/10 02:29, Gary Benson wrote:
> Rob Savoye wrote:

> In fact, the original was right (you clear last_Java_SP to wipe the frame
> anchor.)

  For some reason (probably user error), "hg log -p -r xxxx:xxxx"
doesn't quite seem to get all the changes I made. The block you noticed
was fixed in the real code, but somehow missed the patch. Here's an
updated version:
http://www.senecass.com/projects/OpenJDK-ARM/thumb2-083110.patch

  The ARM assembler appears to be working, but there is still debugging
to do in thumb2.cpp before the thumb2 JIT fully works. I also merged in
a little patch from xerxes for pr484, which is currently untested.

  Which this patch, (and HOTSPOT_ASM enabled) test_gamma gets through
the first 56 tests like before, and then fails deep down in call_thumb2.
Tracking that down is the current debugging task.

	- rob -