From gbenson at redhat.com Mon Aug 8 03:25:22 2011 From: gbenson at redhat.com (Gary Benson) Date: Mon, 8 Aug 2011 11:25:22 +0100 Subject: Review Request: zero/shark doesn't build after b147-fcs In-Reply-To: <7ADFDF69-ADDA-4B24-8F78-82D52F46FD2B@oracle.com> References: <4E1C5E4F.1080307@zafena.se> <4E2049CA.8060506@LGonQn.Org> <20110715145127.GA3311@redhat.com> <7ADFDF69-ADDA-4B24-8F78-82D52F46FD2B@oracle.com> Message-ID: <20110808102522.GB2761@redhat.com> Christian Thalinger wrote: > On Jul 15, 2011, at 4:51 PM, Gary Benson wrote: > > Chris Phillips wrote: > > > http://lgonqn.org/temp/ChrisPhi/webrev-sharkContext.hpp-typo-in-assert/ > > > > Nice catch :) > > > > > http://lgonqn.org/temp/ChrisPhi/webrev-methodHandles_zero.hpp-missing/ > > > > You could probably make adapter_code_size be 0, or something small > > 1ike 1*k. Nothing will presumably be generated into these buffers > > after all? > > Gary, can I add you as a reviewer? -- Christian Sure. Sorry for the delay in replying, I was on PTO. Thanks, Gary -- http://gbenson.net/ From drazzib at drazzib.com Tue Aug 9 14:53:28 2011 From: drazzib at drazzib.com (Damien Raude-Morvan) Date: Tue, 9 Aug 2011 23:53:28 +0200 Subject: [patch] ZeroVM fix under linuxthreads Message-ID: <201108092353.32567.drazzib@drazzib.com> Hi, When trying to use Zero VM with linuxthreads (under x86 but should also exist under others CPU), I found an issue with safe_cond_timedwait usage. In openjdk/hotspot/src/os/linux/vm/os_linux.cpp#safe_cond_timedwait : if (is_NPTL()) { return pthread_cond_timedwait(_cond, _mutex, _abstime); } else { #ifndef IA64 // 6292965: LinuxThreads pthread_cond_timedwait() resets FPU control // word back to default 64bit precision if condvar is signaled. Java // wants 53bit precision. Save and restore current value. int fpu = get_fpu_control_word(); #endif // IA64 int status = pthread_cond_timedwait(_cond, _mutex, _abstime); #ifndef IA64 set_fpu_control_word(fpu); #endif // IA64 return status; } So if you use linuxthreads (!= NTPL) with a arch different from x86_64, it will try to call get_fpu_control_word / set_fpu_control_word. Now, in os_linux_zero.cpp, this methods currently throw errors with ShouldNotCallThis. This obvousily fails in this case. I've choosen to just replace this with just noop (see attached patch). Regards, -- Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: zero-fpu-control-is-noop.diff Type: text/x-patch Size: 970 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20110809/cc0dd879/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20110809/cc0dd879/attachment-0001.bin From xerxes at zafena.se Wed Aug 31 00:56:34 2011 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Wed, 31 Aug 2011 10:56:34 +0300 Subject: RFC: Shark LLVM 3.0svn support Message-ID: <4E5DE932.7050908@zafena.se> Hi all Zero/Shark hackers! The attached patches updates Shark to handle the latest LLVM API changes in the LLVM 3.0svn codebase. 0-sharkllvm30-targetselect-138450.patch: The TargetSelect header have been moved to a new location. http://llvm.org/viewvc/llvm-project?view=rev&revision=138450 1-sharkllvm30-de-const-type-135375.patch: This patch are a pain, basically all LLVM types have dropped const in LLVM 3.0. * I have not yet conditionalized this patch to make shark work with older llvm versions. http://llvm.org/viewvc/llvm-project?view=rev&revision=135375 2-sharkllvm30-PHI-128537-Call-ArrayRef-135265.patch: This patch fixes two API changes. Please review this patch. * I have not yet conditionalized this patch to make shark work with older llvm versions. The CreatePHI API change added a requirement that all CreatePHI calls had to tell in advance the (known or expected) number of operands to the PHI node. I have passed a 0 here because Shark did not use the old API PHINode::reserveOperandSpace() at all. http://llvm.org/viewvc/llvm-project?view=rev&revision=128537 The CreateCall API change made it mandatory to pass multiple arguments to CreateCall inside a ArrayRef. I have solved this by wrapping the existing argument/parameter arrays in a llvm::makeArrayRef() call. http://llvm.org/viewvc/llvm-project?view=rev&revision=135265 3-sharkllvm30-MCJIT.patch: This are a fun patch that makes it possible to test Shark in combination with the new MCJIT in LLVM that uses the direct machine code emission framework. The MCJIT are intended to be the new stable JIT in LLVM that will use the same stable code path as the static compilers in LLVM. * I have not yet conditionalized this patch to make shark work with older llvm versions. Ok thats all for today! Cheers Xerxes -------------- next part -------------- A non-text attachment was scrubbed... Name: 0-sharkllvm30-targetselect-138450.patch Type: text/x-patch Size: 667 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20110831/d00aad93/attachment-0004.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: 1-sharkllvm30-de-const-type-135375.patch Type: text/x-patch Size: 23417 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20110831/d00aad93/attachment-0005.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: 2-sharkllvm30-PHI-128537-Call-ArrayRef-135265.patch Type: text/x-patch Size: 10458 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20110831/d00aad93/attachment-0006.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: 3-sharkllvm30-MCJIT.patch Type: text/x-patch Size: 615 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20110831/d00aad93/attachment-0007.bin From xerxes at zafena.se Wed Aug 31 05:18:10 2011 From: xerxes at zafena.se (Xerxes =?ISO-8859-1?Q?R=E5nby?=) Date: Wed, 31 Aug 2011 14:18:10 +0200 Subject: RFC: Shark LLVM 3.0svn support In-Reply-To: <4E5DE932.7050908@zafena.se> References: <4E5DE932.7050908@zafena.se> Message-ID: <1314793090.27119.4.camel@xranby-ESPRIMO-P7935> ons 2011-08-31 klockan 10:56 +0300 skrev Xerxes R?nby: > Hi all Zero/Shark hackers! > 2-sharkllvm30-PHI-128537-Call-ArrayRef-135265.patch: ... > The CreateCall API change made it mandatory to pass multiple arguments to CreateCall > inside a ArrayRef. I have solved this by wrapping the existing argument/parameter arrays > in a llvm::makeArrayRef() call. > http://llvm.org/viewvc/llvm-project?view=rev&revision=135265 I have attached an updated version of this patch 2-sharkllvm30-PHI-128537-Call-ArrayRef-135265-v2.patch: this solves a llvm/lib/VMCore/Value.cpp:175: void llvm::Value::setName(const llvm::Twine&): Assertion `! getType()->isVoidTy() && "Cannot assign a name to void values!"' failed. assertion error. Cheers Xerxes -------------- next part -------------- A non-text attachment was scrubbed... Name: 2-sharkllvm30-PHI-128537-Call-ArrayRef-135265-v2.patch Type: text/x-patch Size: 10656 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20110831/84df7a03/attachment.bin From xerxes at zafena.se Wed Aug 31 05:52:08 2011 From: xerxes at zafena.se (Xerxes =?ISO-8859-1?Q?R=E5nby?=) Date: Wed, 31 Aug 2011 14:52:08 +0200 Subject: RFC: Shark LLVM 3.0svn support In-Reply-To: <4E5DE932.7050908@zafena.se> References: <4E5DE932.7050908@zafena.se> Message-ID: <1314795128.27119.9.camel@xranby-ESPRIMO-P7935> ons 2011-08-31 klockan 10:56 +0300 skrev Xerxes R?nby: > Hi all Zero/Shark hackers! > > 3-sharkllvm30-MCJIT.patch: > This are a fun patch that makes it possible to test Shark in combination with the new > MCJIT in LLVM that uses the direct machine code emission framework. The MCJIT are intended > to be the new stable JIT in LLVM that will use the same stable code path as the static > compilers in LLVM. > * I have not yet conditionalized this patch to make shark work with older llvm versions. 3-sharkllvm30-MCJIT-v2.patch: Updated version of the MCJIT patch, I forgot to replace the JIT.h with MCJIT.h. this prevented the MCJIT to get linked in. If the MCJIT fails to initialize then Shark will exit with the following error: LLVM ERROR: Target does not support MC emission! llvm-dev claims that the MCJIT are functional on x86_64. Cheers Xerxes -------------- next part -------------- A non-text attachment was scrubbed... Name: 3-sharkllvm30-MCJIT-v2.patch Type: text/x-patch Size: 1342 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20110831/09279dd4/attachment.bin From xerxes at zafena.se Wed Aug 31 07:18:49 2011 From: xerxes at zafena.se (Xerxes =?ISO-8859-1?Q?R=E5nby?=) Date: Wed, 31 Aug 2011 16:18:49 +0200 Subject: RFC: Shark LLVM 3.0svn support - MCJIT In-Reply-To: <1314795128.27119.9.camel@xranby-ESPRIMO-P7935> References: <4E5DE932.7050908@zafena.se> <1314795128.27119.9.camel@xranby-ESPRIMO-P7935> Message-ID: <1314800329.27119.15.camel@xranby-ESPRIMO-P7935> ons 2011-08-31 klockan 14:52 +0200 skrev Xerxes R?nby: > ons 2011-08-31 klockan 10:56 +0300 skrev Xerxes R?nby: > > Hi all Zero/Shark hackers! > > > > 3-sharkllvm30-MCJIT.patch: > > This are a fun patch that makes it possible to test Shark in combination with the new > > MCJIT in LLVM that uses the direct machine code emission framework. The MCJIT are intended > > to be the new stable JIT in LLVM that will use the same stable code path as the static > > compilers in LLVM. > > * I have not yet conditionalized this patch to make shark work with older llvm versions. > > 3-sharkllvm30-MCJIT-v2.patch: > Updated version of the MCJIT patch, I forgot to replace the JIT.h with > MCJIT.h. this prevented the MCJIT to get linked in. > > If the MCJIT fails to initialize then Shark will exit with the following > error: LLVM ERROR: Target does not support MC emission! > > llvm-dev claims that the MCJIT are functional on x86_64. > 3-sharkllvm30-MCJIT-v3.patch: Updated patch. The MCJIT require that a native AsmPrinter are initialized before use. If MCJIT fails to insert object code into memory then the following error are reported: LLVM ERROR: Unknown object format! It are possible to test if MCJIT are supported on your target by running the following testcase: llvm-as < llvm/test/ExecutionEngine/hello.ll | lli -use-mcjit Cheers Xerxes -------------- next part -------------- A non-text attachment was scrubbed... Name: 3-sharkllvm30-MCJIT-v3.patch Type: text/x-patch Size: 1651 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20110831/4ded6354/attachment.bin