I am getting this error again but its not repeatable. Can you give me any
idea of how I might stress it to make a
test case that happens all of the time? Or is it nothing to worry about?
This is the stack trace. This sequence is the main event handler in my
user io stream so at this point it
On Aug 17, 2011, at 2:12 PM, Rémi Forax wrote:
> perhaps this recipe is only for plumbers like you.
S'il vous plaît! Je suis un chef! Un artiste! :-)
(Sounds better in French, courtesy of translate.google.com .)
-- John___
mlvm-dev mailing list
mlvm-
On 08/17/2011 09:47 PM, John Rose wrote:
> ## Using an interface as a marker for "dynamically typed reference"
> 1. Take one fresh interface D. Remove all methods.
> 2. Sprinkle D freely in invokedynamic signatures, wherever a static type
> "dynamic" is desired.
> 3. When binding a MH to such an
On 08/17/2011 08:12 PM, MacGregor, Duncan (GE Energy) wrote:
Since Remi hasn't replied (or it hasn't reached my mailbox if he has).
Yes, MethodType is now merged with Type, and MethodHandle is now
Handle, which makes everything much more readable. You will however
have to make sure you've cha
Thanks Duncan,
you mentioned
One problem I have found is that in changing
ClassWriter.getCommonSuperClass() to not
call initialisation code they?ve limited it to classes loaded by the
bootstrap ClassLoader.
How did this show up in your code? Did you have an explicit call or was
it incidenta
## Using an interface as a marker for "dynamically typed reference"
1. Take one fresh interface D. Remove all methods.
2. Sprinkle D freely in invokedynamic signatures, wherever a static type
"dynamic" is desired.
3. When binding a MH to such an interface, retype MH in two steps, an asType
and a
On Jul 27, 2011, at 5:20 PM, Ola Bini wrote:
> I tried switching out asType to explicitCastArguments. That ended up
> being about 5% slower.
Sorting out asType and eCA probably needs a Cookbook entry or two. I'll post
those separately.
The main differences between asType and eCA are:
- eCA t
This is an auto-replied message. I am out of the office until Aug 22nd with
limited access to email and phone.
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
On Aug 12, 2011, at 9:49 PM, Charles Oliver Nutter wrote:
> On the other side of things...I hope those languages that will churn
> through method handles also realize they're unlikely to ever JIT...
Getting native code out of the MH-construction process brings them much closer
to optimizability.
This is an auto-replied message. I am out of the office until Aug 22nd with
limited access to email and phone.
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
I'm basing my mlvm builds on clones of the following two mercurial forests:
hg fclone http://hg.openjdk.java.net/bsd-port/bsd-port sources
hg fclone http://hg.openjdk.java.net/mlvm/mlvm patches
Complete build scripts here: https://gist.github.com/243072
Are there changes I should make sinc
This is an auto-replied message. I am out of the office until Aug 22nd with
limited access to email and phone.
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Since Remi hasn't replied (or it hasn't reached my mailbox if he has). Yes,
MethodType is now merged with Type, and MethodHandle is now Handle, which makes
everything much more readable. You will however have to make sure you've
changed everything from org.objectweb to org.ow2.
One problem I
For depth I am using 5 as the limit, but it is just a rough guess based on
empirical comparisons of chained GWT versus our inline cache. I need to
reevaluate with recent patches in place.
By "wipe out" I mean clear the call site's target and start over with a new GWT
chain.
- Charlie (mobile)
>From Charlie
* If we encounter a new type at a call site and have not exceeded our
GWT cascade limit, we add it to the chain.
* If we exceed the limit of GWT chaining, wipe out the site and switch
it permanently to an inline cache
Charlie, what is the depth limit you set and how did you arrive
With 292, nothing is simple.
If you pull the latest Nashorn and run - you should see it (make sure JDK7
platform is set to java-1.7.0-internal-mlvm-2011_08_08.)
It might take a day or two to come up with an isolated example.
Cheers,
-- Jim
On 2011-08-17, at 9:07 AM, Christian Thalinger wro
On Aug 17, 2011, at 2:01 PM, Jim Laskey wrote:
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error
> (/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/runtime/frame.cpp:1158),
> pid=1021, tid=4410376192
> # Error: ShouldNotReachHere()
Do y
This is an auto-replied message. I am out of the office until Aug 22nd with
limited access to email and phone.
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error
(/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/runtime/frame.cpp:1158),
pid=1021, tid=4410376192
# Error: ShouldNotReachHere()
Just getting back from vacation and switched to the 2011_08_08 bu
On Tue, Aug 9, 2011 at 2:43 PM, Tom Rodriguez wrote:
>> Same numbers. Is there some other patch you have applied locally?
>> What's the best way for me to investigate?
>
> Can you collect PrintCompilation/PrintInlining output for each of these?
I shall, if I can reproduce it again. I've moved on
Charles Oliver Nutter wrote:
> On Tue, Aug 16, 2011 at 8:46 AM, Jeroen Frijters
> wrote:
> > Hi everyone,
> >
> > I "finished" the initial JSR292 implementation. I haven't done any
> performance work and it shows:
>
> Oh very nice :) Only took about a month (since JVMLS) for you to have a
> worki
21 matches
Mail list logo
