From xerxes at zafena.se Thu Apr 1 04:36:46 2010 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Thu, 01 Apr 2010 13:36:46 +0200 Subject: FYI: add explicit success returncode to mkbc.c Message-ID: <4BB4854E.9080504@zafena.se> I have made a trivial change that makes mkbc.c explicitly return 0 on success. When using mkbc in cross compile setups then the tool could return a non zero return code value and break the build. By explicitly returning 0 fixes it. commited to: http://icedtea.classpath.org/hg/icedtea6/rev/3e6dd786e038 Cheers Xerxes From ahughes at redhat.com Thu Apr 8 12:49:08 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 8 Apr 2010 20:49:08 +0100 Subject: porting OpenJDK In-Reply-To: <4BBE2B4C.3000000@sun.com> References: <4BBE2B4C.3000000@sun.com> Message-ID: On 8 April 2010 20:15, Dalibor Topic wrote: > Wallace Araujo wrote: >> I am intending to create a port of OpenJDK 6 to run on a playstation 2 >> (see PS2SDK and MIPS assembly). > > If you're porting to a Linux distribution on the PS2, I'd suggest > starting with the Zero interpreter backend. If you're porting to something > else running on the PS2, I'd still suggesting starting with the Zero backend, > and porting whatever is necessary along with it (libffi comes to mind). > Either way, it may be worth starting with a port of OpenJDK + Zero on > PS2-Linux first. > > Please join the zero-dev mailing list - Gery Benson should be able to > give you more specific advice there. > > cheers, > dalibor topic > -- > ******************************************************************* > Dalibor Topic ? ? ? ? ? ? ? ? ? Tel: (+49 40) 23 646 738 > Java F/OSS Ambassador ? ? ? ? ? AIM: robiladonaim > Sun Microsystems GmbH ? ? ? ? ? Mobile: (+49 177) 2664 192 > Nagelsweg 55 ? ? ? ? ? ? ? ? ? ?http://openjdk.java.net > D-20097 Hamburg ? ? ? ? ? ? ? ? mailto:Dalibor.Topic at sun.com > Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten > Amtsgericht M?nchen: HRB 161028 > Gesch?ftsf?hrer: J?rgen Kunz > > > CCing zero-dev and distro-pkg-dev (IcedTea); I'm not sure if zero has been built on MIPS before or not; if it has, it's likely to be in Debian packages so Matthias Klose (doko) may be able to advise. Zero is upstream in OpenJDK7 b76 on and will be in OpenJDK6 b19. Note that Zero is only an interpreter. It's enough to get a Java environment running, but for decent performance, you'll need to look at a JIT either via Shark (an LLVM-based JIT started by Gary Benson) or your own MIPS-specific solution. -- 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 doko at ubuntu.com Thu Apr 8 14:35:50 2010 From: doko at ubuntu.com (Matthias Klose) Date: Thu, 08 Apr 2010 23:35:50 +0200 Subject: porting OpenJDK In-Reply-To: <4BBE3CE8.8050608@reservoir.com> References: <4BBE2B4C.3000000@sun.com> <4BBE3CE8.8050608@reservoir.com> Message-ID: <4BBE4C36.6000903@ubuntu.com> On 08.04.2010 22:30, Jonathan Springer wrote: > Andrew John Hughes wrote: > [trim] >> Zero is upstream in OpenJDK7 b76 on and will be in OpenJDK6 b19. Note >> that Zero is only an interpreter. It's enough to get a Java >> environment running, but for decent performance, you'll need to look >> at a JIT either via Shark (an LLVM-based JIT started by Gary Benson) >> or your own MIPS-specific solution. any mips patches are in the icedtea6 repositories. I didn't track openjdk or icedtea. > If you do care about performance, or just feel like hacking asm, there > also exists a Linux MIPS port of the OpenJDK template interpreter. > It's mipsel, as I believe the PS2 is, although it was written to > MIPS64, so there might be some instructions used that are not in MIPS > III/IV. It is available at https://www.reservoir.com/ultraviolet this is great news. debian-mips, any volunteer to bring this into icedtea6? Matthias From xerxes at zafena.se Fri Apr 9 04:34:19 2010 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Fri, 09 Apr 2010 13:34:19 +0200 Subject: FYI: zero/cppInterpreter-fast-bytecodes.patch replaced by zero/6939845.patch from OpenJDK upsteam. Message-ID: <4BBF10BB.9030103@zafena.se> Hi all I have pushed a change to Icedtea6 head and release branch to make zero more in sync with OpenJDK upstream now after Ed's improvement, "a fallback path in the C++ interpreter for platform dependent fast bytecodes", got upstreamed into OpenJDK. 6939845: zero needs fallback path in C++ interpreter for platform dependent fast bytecodes Reviewed-by: never Contributed-by: ed at camswl.com http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f61d795ce6de These changes got pushed pushed to: http://icedtea.classpath.org/hg/release/icedtea6-1.8/rev/0ab7c62a1882 and http://icedtea.classpath.org/hg/icedtea6/rev/1af407faae6d after review by doko on IRC. Cheers Xerxes From ahughes at redhat.com Fri Apr 9 07:49:09 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 9 Apr 2010 15:49:09 +0100 Subject: FYI: zero/cppInterpreter-fast-bytecodes.patch replaced by zero/6939845.patch from OpenJDK upsteam. In-Reply-To: <4BBF10BB.9030103@zafena.se> References: <4BBF10BB.9030103@zafena.se> Message-ID: On 9 April 2010 12:34, Xerxes R?nby wrote: > Hi all > > I have pushed a change to Icedtea6 head and release branch to make zero > more in sync with OpenJDK upstream > now after Ed's improvement, "a fallback path in the C++ interpreter for > platform dependent fast bytecodes", > got upstreamed into OpenJDK. > > 6939845: zero needs fallback path in C++ interpreter for platform > dependent fast bytecodes > Reviewed-by: never > Contributed-by: ed at camswl.com > http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f61d795ce6de > > These changes got pushed pushed to: > http://icedtea.classpath.org/hg/release/icedtea6-1.8/rev/0ab7c62a1882 and > http://icedtea.classpath.org/hg/icedtea6/rev/1af407faae6d > after review by doko on IRC. > > Cheers > Xerxes > Thanks for doing this. I've posted it for inclusion in OpenJDK6 too: http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-April/001471.html -- 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 carfield at carfield.com.hk Fri Apr 9 10:29:06 2010 From: carfield at carfield.com.hk (Carfield Yim) Date: Sat, 10 Apr 2010 01:29:06 +0800 Subject: porting OpenJDK In-Reply-To: <4BBE3CE8.8050608@reservoir.com> References: <4BBE2B4C.3000000@sun.com> <4BBE3CE8.8050608@reservoir.com> Message-ID: If it suppose to work on PS3 also, I am happy to test it. On Fri, Apr 9, 2010 at 4:30 AM, Jonathan Springer wrote: > Andrew John Hughes wrote: > [trim] >> >> Zero is upstream in OpenJDK7 b76 on and will be in OpenJDK6 b19. ?Note >> that Zero is only an interpreter. ?It's enough to get a Java >> environment running, but for decent performance, you'll need to look >> at a JIT either via Shark (an LLVM-based JIT started by Gary Benson) >> or your own MIPS-specific solution. > > If you do care about performance, or just feel like hacking asm, there > also exists a Linux MIPS port of the OpenJDK template interpreter. > It's mipsel, as I believe the PS2 is, although it was written to > MIPS64, so there might be some instructions used that are not in MIPS > III/IV. ?It is available at https://www.reservoir.com/ultraviolet > > -Jonathan > > -- > Jonathan Springer ? ? | ?Reservoir Labs, Inc. > Managing Engineer ? ? | ?http://www.reservoir.com/ > From gbenson at redhat.com Mon Apr 12 03:06:01 2010 From: gbenson at redhat.com (Gary Benson) Date: Mon, 12 Apr 2010 11:06:01 +0100 Subject: FYI: zero/cppInterpreter-fast-bytecodes.patch replaced by zero/6939845.patch from OpenJDK upsteam. In-Reply-To: <4BBF10BB.9030103@zafena.se> References: <4BBF10BB.9030103@zafena.se> Message-ID: <20100412100601.GA4364@redhat.com> Xerxes R?nby wrote: > I have pushed a change to Icedtea6 head and release branch to make > zero more in sync with OpenJDK upstream now after Ed's improvement, > "a fallback path in the C++ interpreter for platform dependent fast > bytecodes", got upstreamed into OpenJDK. Awesome, thanks Xerxes. Cheers, Gary -- http://gbenson.net/ From xerxes at zafena.se Mon Apr 12 06:26:54 2010 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Mon, 12 Apr 2010 15:26:54 +0200 Subject: FYI: PR icedtea/459: shark do nothing on stub frame fix pushed Message-ID: <4BC31F9E.9090502@zafena.se> Hi all! I have pushed a fix for icedtea PR 459 to Icedtea6 head and icedtea6-1.8 release branch. http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=459 This fix got pushed to http://icedtea.classpath.org/hg/icedtea6/rev/221817e944c5 http://icedtea.classpath.org/hg/release/icedtea6-1.8/rev/cdef2ad5c0ed after review by gbenson on IRC. Cheers Xerxes From xerxes at zafena.se Mon Apr 19 11:15:11 2010 From: xerxes at zafena.se (Xerxes Ranby) Date: Mon, 19 Apr 2010 20:15:11 +0200 Subject: FYI: Updated Shark for LLVM 2.8 API change r100304 Message-ID: <4BCC9DAF.7070203@zafena.se> LLVM 2.8 svn contains a subtile API change in r100304 http://llvm.org/viewvc/llvm-project?view=rev&revision=100304 that caused a Shark runtime assertion like the extract below: java version "1.6.0_18"java: /media/disk/llvm/include/llvm/Instructions.h:1091: llvm::Value* llvm::CallInst::getOperand(unsigned int) const: Assertion `i_nocapture < OperandTraits::operands(this) && "getOperand() out of range!"' failed. Stack dump: 0. Running pass 'ARM Instruction Selection' on function '@"java.nio.CharBuffer::wrap"' Aborted This commited change fixes: http://icedtea.classpath.org/hg/icedtea6/rev/902bacad8d1b cheers Xerxes From gbenson at redhat.com Tue Apr 20 01:46:11 2010 From: gbenson at redhat.com (Gary Benson) Date: Tue, 20 Apr 2010 09:46:11 +0100 Subject: Zero heads up Message-ID: <20100420084611.GC3510@redhat.com> Hi all, There's some code floating around the HotSpot mailing lists to fix http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=323. If pushed it will appear as "6939182: Zero JNI handles fix". It's important that this commit doesn't end up in IcedTea until Shark is updated to match it. Cheers, Gary -- http://gbenson.net/ From xerxes at zafena.se Wed Apr 21 16:23:10 2010 From: xerxes at zafena.se (Xerxes Ranby) Date: Thu, 22 Apr 2010 01:23:10 +0200 Subject: RFC: Shark calling static jni method jclass argument fix Message-ID: <4BCF88DE.8090807@zafena.se> When Shark jits code that calls static jni methods then the jvm bombs if the static jni code tries to use the passed jclass argument. testcase: (tested to be fully reproduceable on ARM and AMD_64) cd openjdk/jdk/test/java/awt/geom/Path2D javac FillPPathTest.java java -Xcomp -XX:CompileOnly=java.awt.image.BufferedImage::initIDs -XX:+SharkTraceInstalls FillPPathTest output: [0x680c4010-0x680c412c): java.awt.image.BufferedImage::initIDs (284 bytes code) # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (os_linux_zero.cpp:236), pid=10552, tid=1090999440 # Error: caught unhandled signal 11 # ... backtrace: #0 0xe592300c in ?? () #1 0x40362760 in jni_GetFieldID (env=, clazz=, name=0x684484b4 "raster", sig=) at /media/disk/icedtea6-shark/openjdk/hotspot/src/share/vm/prims/jni.cpp:1634 #2 0x683dcbfc in Java_java_awt_image_BufferedImage_initIDs (env=0x40568620, cls=0x2c888) at ../../../src/share/native/sun/awt/image/imageInitIDs.c:32 #3 0x680c409c in ?? () The attached patch fix! The fix are inspired from how the cppInterpreter_zero.cpp created the passed jclass argument. ok to commit? Cheers and have a great day! Xerxes -------------- next part -------------- A non-text attachment was scrubbed... Name: 22apr-shark-static-jni-cls.patch Type: text/x-patch Size: 674 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20100422/792021b2/attachment.bin From gbenson at redhat.com Thu Apr 22 00:53:18 2010 From: gbenson at redhat.com (Gary Benson) Date: Thu, 22 Apr 2010 08:53:18 +0100 Subject: RFC: Shark calling static jni method jclass argument fix In-Reply-To: <4BCF88DE.8090807@zafena.se> References: <4BCF88DE.8090807@zafena.se> Message-ID: <20100422075318.GA4039@redhat.com> Xerxes Ranby wrote: > When Shark jits code that calls static jni methods then the jvm > bombs if the static jni code tries to use the passed jclass > argument. ... > The attached patch fix! Good catch! > ok to commit? Can you make it: target()->method_holder()->klass_part()->java_mirror() The two are equivalent, but nothing in Shark should reference the constants pool directly. Cheers, Gary -- http://gbenson.net/ From xerxes at zafena.se Thu Apr 22 02:25:09 2010 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Thu, 22 Apr 2010 11:25:09 +0200 Subject: RFC: Shark calling static jni method jclass argument fix In-Reply-To: <20100422075318.GA4039@redhat.com> References: <4BCF88DE.8090807@zafena.se> <20100422075318.GA4039@redhat.com> Message-ID: <4BD015F5.5040807@zafena.se> On 2010-04-22 09:53, Gary Benson wrote: > Xerxes Ranby wrote: > >> When Shark jits code that calls static jni methods then the jvm >> bombs if the static jni code tries to use the passed jclass >> argument. >> > ... > >> The attached patch fix! >> > Good catch! > > >> ok to commit? >> > Can you make it: > > target()->method_holder()->klass_part()->java_mirror() > > The two are equivalent, but nothing in Shark should reference the > constants pool directly. > > Cheers, > Gary > > Thank you for the code review Gary! Commited with the suggested change to: http://icedtea.classpath.org/hg/icedtea6/rev/67bc1a7196b8 Cheers, Xerxes From gbenson at redhat.com Thu Apr 22 02:38:53 2010 From: gbenson at redhat.com (Gary Benson) Date: Thu, 22 Apr 2010 10:38:53 +0100 Subject: RFC: Shark calling static jni method jclass argument fix In-Reply-To: <4BD015F5.5040807@zafena.se> References: <4BCF88DE.8090807@zafena.se> <20100422075318.GA4039@redhat.com> <4BD015F5.5040807@zafena.se> Message-ID: <20100422093853.GB4039@redhat.com> Xerxes R?nby wrote: > On 2010-04-22 09:53, Gary Benson wrote: > > Xerxes Ranby wrote: > > > When Shark jits code that calls static jni methods then the jvm > > > bombs if the static jni code tries to use the passed jclass > > > argument. > > ... > > > The attached patch fix! > > > > Good catch! > > > > > ok to commit? > > > > Can you make it: > > > > target()->method_holder()->klass_part()->java_mirror() > > > > The two are equivalent, but nothing in Shark should reference > > the constants pool directly. > > Thank you for the code review Gary! Thank you for the fix :) Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Fri Apr 30 02:36:51 2010 From: gbenson at redhat.com (Gary Benson) Date: Fri, 30 Apr 2010 10:36:51 +0100 Subject: Fix Shark where array type is unknown Message-ID: <20100430093650.GA27914@redhat.com> Hi all, This commit fixes a long standing bug in Shark where the compilation would fail if an array's type was not supplied by typeflow. This most commonly showed up in Gervill code. PR icedtea/324. Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- diff -r f882c327935a ChangeLog --- a/ChangeLog Thu Apr 29 08:59:57 2010 +0200 +++ b/ChangeLog Fri Apr 30 10:24:23 2010 +0100 @@ -1,3 +1,11 @@ +2010-04-30 Gary Benson + + PR icedtea/324 + * ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp + (SharkTopLevelBlock::do_aload): Cope with cases where + the array's type is unknown. + (SharkTopLevelBlock::do_astore): Likewise. + 2010-04-29 Pavel Tisnovsky * overlays/openjdk/jdk/test/com: Removed, correct diff -r f882c327935a ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp --- a/ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp Thu Apr 29 08:59:57 2010 +0200 +++ b/ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp Fri Apr 30 10:24:23 2010 +0100 @@ -691,12 +691,6 @@ SharkValue *index = pop(); SharkValue *array = pop(); - assert(array->type()->is_array_klass(), "should be"); - ciType *element_type = ((ciArrayKlass *) array->type())->element_type(); - assert((element_type->basic_type() == T_BOOLEAN && basic_type == T_BYTE) || - (element_type->basic_type() == T_ARRAY && basic_type == T_OBJECT) || - (element_type->basic_type() == basic_type), "type mismatch"); - check_null(array); check_bounds(array, index); @@ -729,7 +723,21 @@ break; case T_OBJECT: - push(SharkValue::create_generic(element_type, value, false)); + // You might expect that array->type()->is_array_klass() would + // always be true, but it isn't. If ciTypeFlow detects that a + // value is always null then that value becomes an untyped null + // object. Shark doesn't presently support this, so a generic + // T_OBJECT is created. In this case we guess the type using + // the BasicType we were supplied. In reality the generated + // code will never be used, as the null value will be caught + // by the above null pointer check. + // http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=324 + push( + SharkValue::create_generic( + array->type()->is_array_klass() ? + ((ciArrayKlass *) array->type())->element_type() : + ciType::make(basic_type), + value, false)); break; default: @@ -743,12 +751,6 @@ SharkValue *index = pop(); SharkValue *array = pop(); - assert(array->type()->is_array_klass(), "should be"); - ciType *element_type = ((ciArrayKlass *) array->type())->element_type(); - assert((element_type->basic_type() == T_BOOLEAN && basic_type == T_BYTE) || - (element_type->basic_type() == T_ARRAY && basic_type == T_OBJECT) || - (element_type->basic_type() == basic_type), "type mismatch"); - check_null(array); check_bounds(array, index); @@ -792,7 +794,7 @@ builder()->CreateStore(value, addr); - if (!element_type->is_primitive_type()) + if (basic_type == T_OBJECT) // XXX or T_ARRAY? builder()->CreateUpdateBarrierSet(oopDesc::bs(), addr); } From xerxes at zafena.se Fri Apr 30 05:45:34 2010 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Fri, 30 Apr 2010 14:45:34 +0200 Subject: Fix Shark where array type is unknown In-Reply-To: <20100430093650.GA27914@redhat.com> References: <20100430093650.GA27914@redhat.com> Message-ID: <4BDAD0EE.6030307@zafena.se> On 2010-04-30 11:36, Gary Benson wrote: > Hi all, > > This commit fixes a long standing bug in Shark where the compilation > would fail if an array's type was not supplied by typeflow. This most > commonly showed up in Gervill code. PR icedtea/324. > > Cheers, > Gary > > Thanks Gary! I have forwarded this fix to the icedtea6-1.8 release branch http://icedtea.classpath.org/hg/release/icedtea6-1.8/rev/16943314ca9a Cheers, Xerxes From gbenson at redhat.com Fri Apr 30 05:47:51 2010 From: gbenson at redhat.com (Gary Benson) Date: Fri, 30 Apr 2010 13:47:51 +0100 Subject: Fix Shark where array type is unknown In-Reply-To: <4BDAD0EE.6030307@zafena.se> References: <20100430093650.GA27914@redhat.com> <4BDAD0EE.6030307@zafena.se> Message-ID: <20100430124751.GB27914@redhat.com> Xerxes R?nby wrote: > On 2010-04-30 11:36, Gary Benson wrote: > > This commit fixes a long standing bug in Shark where the > > compilation would fail if an array's type was not supplied > > by typeflow. This most commonly showed up in Gervill code. > > PR icedtea/324. > > Thanks Gary! > I have forwarded this fix to the icedtea6-1.8 release branch > http://icedtea.classpath.org/hg/release/icedtea6-1.8/rev/16943314ca9a Awesome, thanks Xerxes. Cheers, Gary -- http://gbenson.net/