On 05/18/2011 09:03 PM, John Rose wrote:
> On May 18, 2011, at 11:59 AM, Rémi Forax wrote:
>
>> All others are hard because the value of the method handle is not
>> statically known
>> i.e the method handle cannot be considered as constant.
> It can be optimistically inlined, which is what we do fo
On May 18, 2011, at 11:59 AM, Rémi Forax wrote:
> All others are hard because the value of the method handle is not
> statically known
> i.e the method handle cannot be considered as constant.
It can be optimistically inlined, which is what we do for invokedynamic
instructions.
-- John
___
On 05/18/2011 06:44 PM, Charles Oliver Nutter wrote:
> On Wed, May 18, 2011 at 5:34 AM, Szymon Jachim wrote:
>> I have to questions to you guys about possible (and planned) JIT
>> optimizations for MethodHandles.
>> 1. Assuming that there will be a chain of MH's:
>>mh1(invoker) -> mh2 ->
I concur...still getting the ShouldNotReadHere error on most things I
run with JRuby + indy...
- Charlie
On Wed, May 18, 2011 at 3:48 AM, Ola Bini wrote:
> Hi,
>
> The latest fix to make methodHandleWalk.cpp not crash doesn't seem to
> cover all cases. I still get the same error:
>
> # A fatal e
On Wed, May 18, 2011 at 5:34 AM, Szymon Jachim wrote:
> I have to questions to you guys about possible (and planned) JIT
> optimizations for MethodHandles.
> 1. Assuming that there will be a chain of MH's:
> mh1(invoker) -> mh2 -> aMethod()
> and there will be no other references to mh2.
Hi,
Not sure if this is the same failure as the previous one. It definitely
goes away with the -Xint flag though (and only happens after a large
number of repetitions):
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGBUS (0xa) at pc=0x012053b9, pid=65808, tid=295385088
I have to questions to you guys about possible (and planned) JIT
optimizations for MethodHandles.
1. Assuming that there will be a chain of MH's:
mh1(invoker) -> mh2 -> aMethod()
and there will be no other references to mh2. Will JIT/GC be able to
optimize unneeded mh2 and put into callsi
Hi,
The latest fix to make methodHandleWalk.cpp not crash doesn't seem to
cover all cases. I still get the same error:
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (methodHandleWalk.cpp:1143), pid=40009, tid=2955194368
# Error: ShouldNotReachHere()
#
# J
On 2011-05-18 12.52, Ola Bini wrote:
> Hey,
>
> Has anyone seen this, trying to build openjdk on Linux?: (CentOS, 64-bit)
> /home/obini2/src/davinci/sources/build/linux-amd64/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj64/unpack.o:
> In function `unpacker::redirect_stdio()':
> unpack.cpp:(.te
Hey,
Has anyone seen this, trying to build openjdk on Linux?: (CentOS, 64-bit)
/home/obini2/src/davinci/sources/build/linux-amd64/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj64/unpack.o:
In function `unpacker::redirect_stdio()':
unpack.cpp:(.text+0x840b): warning: the use of `tempnam' is dang
Changeset: 02dfcdb9591d
Author:jrose
Date: 2011-05-18 00:09 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/02dfcdb9591d
meth: reflect pushes to hotspot-comp
! meth-exc-7044892.patch
+ meth-mhw-7045513.patch
+ meth-sparc-7045514.base.patch
+ meth-sparc-7045514.patch
! s
Changeset: b5cc30d2cc6a
Author:jrose
Date: 2011-05-18 00:09 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/b5cc30d2cc6a
meth: reflect pushes to hotspot-comp
! meth-argcount-6983728.patch
! meth-doc-7014005.patch
! meth-exc-7044892.patch
+ meth-exc-7044892.txt
! meth-invoke
12 matches
Mail list logo
