.)
— John
https://bugs.openjdk.java.net/browse/JDK-8188790
allow invokedynamic BSM to return MethodHandle instead of CallSite
Invokedynamic is defined to return a CallSite in order to allow a CallSite
object to support per-call-site mutability, which enables certain advanced
optimizations based on
invokeExact and invokeDynamic.
The meat of the MethodHandle implementation is here:
https://android.googlesource.com/platform/libcore/+/168dfc7fcb7594933af3bd4a66651f1eb2f09f7f/ojluni/src/main/java/java/lang/invoke/Transformers.java
As far as i understand, it's implemented by reifying thin
, Remi and Brian!
I'm working to plug this hole, and thought I'd share the technique in case
it
if of interest beyond scalac:
SD-193 Lock down lambda deserialization
https://github.com/scala/scala/pull/5321
The body of $deserializeLambda$ is now a single invokedynamic. Its
bootstrap argu
;mlvm-dev"
wrote on 07/29/2016 08:08:56 AM:
> From: Remi Forax
> To: Da Vinci Machine Project
> Date: 07/29/2016 08:09 AM
> Subject: Re: EXT: Re: InvokeDynamic PIC Slowdown
(deopt issue?) need advice
> Sent by: "mlvm-dev"
>
> In fact, you don
nly test() see a new receiver,
test2 is not make non re-entrant by the VM.
cheers,
Rémi
- Mail original -
> De: "MacGregor, Duncan (GE Energy Connections)"
> À: "Da Vinci Machine Project"
> Envoyé: Mardi 26 Juillet 2016 12:29:59
> Objet: Re: EXT: Re: I
gt;
>Rémi
>
>- Mail original -
>> De: "MacGregor, Duncan (GE Energy Connections)"
>>
>> À: "Da Vinci Machine Project"
>> Envoyé: Lundi 25 Juillet 2016 11:40:51
>> Objet: Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need
>
In my perfect world a pic looks like this
at the lowest level
mov
object field ==> eax
je
eax=test1 to implementation1 " the special GWT you mention
"
je
eax=test2 to implementation2
...
handle
miss
I would want to move the testN order
to optimize, rep
yes,
an array of a special kind of GWT, which unlike a GWT doesn't have a fallback,
only a test and a target.
Rémi
> De: "Mark Roos"
> À: "Da Vinci Machine Project"
> Envoyé: Lundi 25 Juillet 2016 18:12:25
> Objet: Re: EXT: Re: InvokeDynamic PIC Slow
; De: "MacGregor, Duncan (GE Energy Connections)"
>> À: "Da Vinci Machine Project"
>> Envoyé: Lundi 25 Juillet 2016 11:40:51
>> Objet: Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice
>
>> I like the idea of this, but I¹m not
e, it should be implemented with an array of couples instead with a couple
of arrays.
Rémi
- Mail original -
> De: "MacGregor, Duncan (GE Energy Connections)"
> À: "Da Vinci Machine Project"
> Envoyé: Lundi 25 Juillet 2016 11:40:51
> Objet: Re: EXT: Re: In
I like the idea of this, but I¹m not sure it can be applied to Magik due
to the ability for methods to redefined and hence our PICs to be
invalidated. I¹ll have a look though, there might be a couple of places I
could try prototyping this.
Duncan.
On 23/07/2016, 00:25, "mlvm-dev on behalf of John
On Jul 24, 2016, at 3:41 PM, Mark Roos wrote:
>
> A few questions on implementation.
>
> My old prototype looks like:
> private RtObject[] _mDicts = new RtObject[8]; // array of
> method dicts
> private MethodHandle[] _methods = new MethodHandle[8]; // the
>
A few questions on implementation.
My old prototype looks like:
private
RtObject[] _mDicts
= new
RtObject[8]; // array
of method dicts
private
MethodHandle[] _methods
= new
MethodHandle[8]; //
the code MH
MethodHandle lookupSelf(RtObject rcvr,
RtCal
0
- Mail original -
> De: "Remi Forax"
> À: "Da Vinci Machine Project"
> Envoyé: Samedi 23 Juillet 2016 12:39:08
> Objet: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice
> At least the PIC usual test seems to work :)
>
> https://gi
e: "John Rose"
> À: "Da Vinci Machine Project"
> Envoyé: Samedi 23 Juillet 2016 01:25:32
> Objet: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice
> On May 31, 2016, at 12:41 PM, Mark Roos wrote:
>>
>> It looks like, from some fine timing, tha
annotations that influence
invokedynamic and inlining? And how likely is it that some of them get
promoted to official API? And will they be available in JDK9 to non-JDK
modules?
The effect would be to preserve existing inlinings of the PIC site (unless they
self-invalidate) but allow the PIC
t; From: John Rose
> To: Da Vinci Machine Project
> Date: 07/22/2016 04:26 PM
> Subject: Re: InvokeDynamic PIC Slowdown (deopt
issue?) need advice
> Sent by: "mlvm-dev"
>
> On May 31, 2016, at 12:41 PM, Mark Roos wrote:
> >
> > It looks like
On May 31, 2016, at 12:41 PM, Mark Roos wrote:
>
> It looks like, from some fine timing, that each time the Smalltalk class
> changes there is a large amount
> of time added to the call. Which I would expect if there was a deopt
> whenever a different GWT triggered.
> There are 6 GWTs in thi
Thx Vladimir
Turns out this was self inflicted by
the means I was using for PIC invalidation. There
is an interesting case when only one
class returns false and all others true ( isNil). Since
this is often in a loop the impact is
severe. I see how to handle this corner case but
it does reopen
Never-taken GWT branches (on per-MH instance basis) are aggressively
pruned during JIT-compilation.
So, in the worst case, a MH chain containing 6 GWT can experience 6
recompilations.
I don't know what Java version you use, but there were a number of bugs
fixed in HotSpot, which manifested a
I have been implementing a Smalltalk on
the JVM (Rtalk) which has gone quite well. But recently
I was told that one of our key benchmarks
had suffered a large slowdown, from a few hundred
mS to seconds. And strangely it
gets slower the more its executed until we reset all of the call sites.
Lo
lable anymore *and*
emit a warning (like when the code cache is full) to not hide the root cause of
the bug.
Rémi
- Mail original -
> De: "Hannes Wallnöfer"
> À: [email protected]
> Envoyé: Mercredi 16 Mars 2016 11:52:42
> Objet: Re: [jvm-l] slow do
>
> --
>
> *De: *"Hannes Wallnöfer"
> *À: *[email protected]
> *Envoyé: *Mercredi 16 Mars 2016 11:52:42
> *Objet: *Re: [jvm-l] slow downs in invokedynamic native code
>
> I've filed a bug for this:
>
> https:
Hi Benjamin,
- Mail original -
> De: "Benjamin Sieffert"
> À: "Da Vinci Machine Project"
> Cc: "Nick Houghton" , [email protected]
> Envoyé: Mercredi 16 Mars 2016 13:59:58
> Objet: Re: [jvm-l] slow downs in invokedynamic na
mall list of patterns,
> https://code.google.com/p/jsr292-cookbook/
>
> take a look to the first inlining cache example.
>
> cheers,
> Rémi
>
> Le 24 juin 2015 14:19:32 CEST, Mike Jarmy a écrit :
> >I've been experimenting with invokedynamic in a compiler for a
JRuby also chains the bootstraps, you might find inspiration here:
https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/runtime/invokedynamic/InvokeDynamicSupport.java
On Wed, Jun 24, 2015 at 11:25 AM, Mike Jarmy wrote:
> Jochen -- that comes tantalizingly close to mak
rse the callsite will have to be mutable then
>
> Does this help you out? It works quite good for Groovy.
>
> bye blackdrag
>
>
> Am 24.06.2015 14:19, schrieb Mike Jarmy:
>
>> I've been experimenting with invokedynamic in a compiler for a dynamic
>> language
&
field foo). We use (part of) the produced method handle for
this. And of course the callsite will have to be mutable then
Does this help you out? It works quite good for Groovy.
bye blackdrag
Am 24.06.2015 14:19, schrieb Mike Jarmy:
I've been experimenting with invokedynamic in a comp
.
>
> cheers,
> Rémi
>
> Le 24 juin 2015 14:19:32 CEST, Mike Jarmy a écrit :
> >I've been experimenting with invokedynamic in a compiler for a dynamic
> >language
> >that I'm working on, and I've run into a problem that I'm having
> >diffic
Hi Mike,
i've compiled a small list of patterns,
https://code.google.com/p/jsr292-cookbook/
take a look to the first inlining cache example.
cheers,
Rémi
Le 24 juin 2015 14:19:32 CEST, Mike Jarmy a écrit :
>I've been experimenting with invokedynamic in a compiler for a dyna
Okay, this is just the sort of thing invokeDynamic is designed for.
Where you want to call get_foo() you should use an invokeDynaimc instruction
that will create a MutableCallSite. You should set the target of this to be a
lookup method that can find the appropriate get_foo() method, and
I've been experimenting with invokedynamic in a compiler for a dynamic
language
that I'm working on, and I've run into a problem that I'm having difficulty
solving.
Let's say I have a class called A (Java syntax used for clarity):
public class A {
}
And an
:
On Jan 7, 2015, at 8:13 AM, Remi Forax mailto:[email protected]>> wrote:
But if fibo is called through an invokedynamic, instead of emitting a
direct call to fibo,
the JIT generates a code that push the method handle on stack and
execute it
like if the metod handle was not constant
(the
wrote:
But if fibo is called through an invokedynamic, instead of emitting a
direct call to fibo,
the JIT generates a code that push the method handle on stack and
execute it
like if the metod handle was not constant
(the method handle is constant because the call at depth=1 is inlined !).
Invocat
On 01/30/2015 01:48 AM, John Rose wrote:
On Jan 7, 2015, at 8:13 AM, Remi Forax <mailto:[email protected]>> wrote:
But if fibo is called through an invokedynamic, instead of emitting a
direct call to fibo,
the JIT generates a code that push the method handle on stack and
execute it
> On Jan 29, 2015, at 4:48 PM, John Rose wrote:
>
> On Jan 7, 2015, at 8:13 AM, Remi Forax <mailto:[email protected]>> wrote:
>>
>> But if fibo is called through an invokedynamic, instead of emitting a direct
>> call to fibo,
>> the JIT generates a
On Jan 7, 2015, at 8:13 AM, Remi Forax wrote:
>
> But if fibo is called through an invokedynamic, instead of emitting a direct
> call to fibo,
> the JIT generates a code that push the method handle on stack and execute it
> like if the metod handle was not constant
> (th
cursive call is
>> inlined only once,
>> so the call at depth=2 can not be inlined but should be a classical direct
>> call.
>>
>> But if fibo is called through an invokedynamic, instead of emitting a direct
>> call to fibo,
>> the JIT generates a code that
all is
> inlined only once,
> so the call at depth=2 can not be inlined but should be a classical direct
> call.
>
> But if fibo is called through an invokedynamic, instead of emitting a direct
> call to fibo,
> the JIT generates a code that push the method handle on stack and ex
ect
> call.
>
> But if fibo is called through an invokedynamic, instead of emitting a direct
> call to fibo,
> the JIT generates a code that push the method handle on stack and execute it
> like if the metod handle was not constant
> (the method handle is constant because the call
is inlined only once,
so the call at depth=2 can not be inlined but should be a classical
direct call.
But if fibo is called through an invokedynamic, instead of emitting a
direct call to fibo,
the JIT generates a code that push the method handle on stack and execute it
like if the metod handle
Remi, I tried to reproduce your problem with jdk9 b44. It runs decently fast.
When did it start to regress?
Regards
Marcus
> On 30 Dec 2014, at 20:48, Remi Forax wrote:
>
> Hi guys,
> I've found a bug in the interaction between the lambda form and inlining
> algorithm,
> basically if the inli
ping ?
Rémi
On 12/30/2014 08:48 PM, Remi Forax wrote:
Hi guys,
I've found a bug in the interaction between the lambda form and
inlining algorithm,
basically if the inlining heuristic bailout because the method is
recursive and already inlined once,
instead to emit a code to do a direct call,
Hi guys,
I've found a bug in the interaction between the lambda form and inlining
algorithm,
basically if the inlining heuristic bailout because the method is
recursive and already inlined once,
instead to emit a code to do a direct call, it revert to do call to
linkStatic with the method
as M
Hi Charles, hi all.
> If it's not too late...I'd like to see the paper too :-)
[Sent by private mail]
> And I also wonder whether we should start consolidating approaches a
> bit. InvokeBinder has become very feature-rich, now providing the
> ability to track arguments by name through the MH cha
re and do a new release soon, but I'm using it for just
about all my MH wrangling.
- Charlie
On Tue, Feb 19, 2013 at 7:37 AM, Eric Bodden wrote:
> Hi all.
>
> Kamil Erhard, a student of mine, and myself have prepared a paper
> draft on a novel framework for invokedynamic dispa
On Tue, Feb 19, 2013 at 02:37:12PM +0100, Eric Bodden wrote:
> So please let me know if you are interested in obtaining a copy of the
> draft to then provide us with feedback. In this case I would email you
> the PDF some time this week.
I am interested too!
--
qmx
___
den wrote:
>>
>>> Hi all.
>>>
>>> Kamil Erhard, a student of mine, and myself have prepared a paper
>>> draft on a novel framework for invokedynamic dispatch that we call
>>> DynaMate. The framework is meant to aid language developers in using
&
Hi John, hi all.
Thanks for all the feedback I got so far. I am glad to see so much
interest in this!
> Excellent! We do need EOU layers for indy & MHs. Building and evolving
> dispatch sites is a tricky business.
>
> I assume you already saw Charlie Nutter's InvokeBinder. Can dynamate
> syner
On Feb 19, 2013, at 5:37 AM, Eric Bodden wrote:
> Kamil Erhard, a student of mine, and myself have prepared a paper
> draft on a novel framework for invokedynamic dispatch that we call
> DynaMate.
Excellent! We do need EOU layers for indy & MHs. Building and evolving
dispat
Bodden
> To:Da Vinci Machine Project
> Date:02/19/2013 05:39 AM
> Subject:Looking for comments on paper draft "DynaMate: Simplified
> andoptimized invokedynamic dispatch"
> Sent by:[email protected]
> ---
I would be interested as well
mark
From: Eric Bodden
To: Da Vinci Machine Project
Date: 02/19/2013 05:39 AM
Subject:Looking for comments on paper draft "DynaMate: Simplified
and optimized invokedynamic dispatch"
Sent by:[email protected]
epared a paper
>> draft on a novel framework for invokedynamic dispatch that we call
>> DynaMate. The framework is meant to aid language developers in using
>> java.lang.invoke more easily by automatically taking care of common
>> concerns like guarding and caching of
Sure, I'd be interested in reading this.
Thanks,
Attila.
On Feb 19, 2013, at 2:37 PM, Eric Bodden wrote:
> Hi all.
>
> Kamil Erhard, a student of mine, and myself have prepared a paper
> draft on a novel framework for invokedynamic dispatch that we call
> DynaMate. The f
I'd certainly be interested in having a read of it.
On 19/02/2013 13:37, "Eric Bodden" wrote:
>Hi all.
>
>Kamil Erhard, a student of mine, and myself have prepared a paper
>draft on a novel framework for invokedynamic dispatch that we call
>DynaMate. The fram
I would be very interested in reading that
Am 19.02.2013 14:37, schrieb Eric Bodden:
> Hi all.
>
> Kamil Erhard, a student of mine, and myself have prepared a paper
> draft on a novel framework for invokedynamic dispatch that we call
> DynaMate. The framework is meant to aid lang
Hi all.
Kamil Erhard, a student of mine, and myself have prepared a paper
draft on a novel framework for invokedynamic dispatch that we call
DynaMate. The framework is meant to aid language developers in using
java.lang.invoke more easily by automatically taking care of common
concerns like
Changeset: e3ce088d7958
Author:jrose
Date: 2012-07-11 04:52 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/e3ce088d7958
meth: simplify invokedynamic linkage paths
! meth-lazy-7023639.patch
___
mlvm-dev mailing list
mlvm-dev
Changeset: 89687e50c4e9
Author:jrose
Date: 2012-07-11 04:51 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/89687e50c4e9
meth: simplify invokedynamic linkage paths; remove cpCache entry race condition
! meth-lazy-7023639.patch
Am 27.06.2012 17:47, schrieb Attila Szegedi:
> Just out of curiosity, in what situation would you need to have an
> invokedynamic vs. invokespecial call to super ? Need invocation
> time overloaded constructor resolution?
yes ;)
bye blackdrag
--
Jochen "blackdrag" Theodor
Just out of curiosity, in what situation would you need to have an
invokedynamic vs. invokespecial call to super ? Need invocation time
overloaded constructor resolution?
Attila.
2012.06.26. dátummal, 12:37 időpontban Jochen Theodorou
írta:
> Am 26.06.2012 11:59, schrieb Rémi Forax:
&g
On 06/26/2012 02:24 PM, Jochen Theodorou wrote:
> Am 26.06.2012 13:37, schrieb Julien Ponge:
>> You may bypass the invokespecial (…)V as a first method
>> invocation within a constructor requirement by launching the JVM with
>> -noverify. As long as you don't do anything stupid in the bytecode it
>
Am 26.06.2012 13:37, schrieb Julien Ponge:
> You may bypass the invokespecial (…)V as a first method
> invocation within a constructor requirement by launching the JVM with
> -noverify. As long as you don't do anything stupid in the bytecode it
> will be just ok and you can call a constructor using
emit those, so we don't depend on
an agent... but of course it means the bytecode is quite a bit larger
than needed. Ah well..
[...]
> For Dart, I don't generate Dart constructor as Java constructor,
> I create public default Java constructor that just call super()
> and transla
bling verification is probably not what you want ;-)
- Julien
On Tuesday, June 26, 2012 at 11:59 AM, Rémi Forax wrote:
> On 06/26/2012 11:40 AM, Jochen Theodorou wrote:
> > Hi all,
> >
> > just to be sure I understand correctly... afaik there are two things
> > invok
On 06/26/2012 12:37 PM, Jochen Theodorou wrote:
> Am 26.06.2012 11:59, schrieb Rémi Forax:
>> On 06/26/2012 11:40 AM, Jochen Theodorou wrote:
>>> Hi all,
>>>
>>> just to be sure I understand correctly... afaik there are two things
>>> invokedynamic c
Am 26.06.2012 11:59, schrieb Rémi Forax:
> On 06/26/2012 11:40 AM, Jochen Theodorou wrote:
>> Hi all,
>>
>> just to be sure I understand correctly... afaik there are two things
>> invokedynamic cannot do.
>>
>> (1) calling private methods
>> actually
ust to be sure I understand correctly... afaik there are two things
> invokedynamic cannot do.
>
> (1) calling private methods
> actually I am not sure this is really true. There is a Lookup instance I
> can use to get handles to private methods (afaik), therefore it should
>
On 06/26/2012 11:40 AM, Jochen Theodorou wrote:
> Hi all,
>
> just to be sure I understand correctly... afaik there are two things
> invokedynamic cannot do.
>
> (1) calling private methods
> actually I am not sure this is really true. There is a Lookup instance I
> c
Hi all,
just to be sure I understand correctly... afaik there are two things
invokedynamic cannot do.
(1) calling private methods
actually I am not sure this is really true. There is a Lookup instance I
can use to get handles to private methods (afaik), therefore it should
be possible. Or is
t and work around the limitations, making my runtime more
>> complex. And with the next JVM update all that work might be for nothing.
>
> This is a key point you will have to weigh.
>
> You want to have Groovy 2.0 released by this fall, with invokedynamic
> support.
This fa
ex. And with the next JVM update all that work might be for nothing.
This is a key point you will have to weigh.
You want to have Groovy 2.0 released by this fall, with invokedynamic
support. It's certainly possible that your uses of invokedynamic have
not gotten the optimization love they ne
he length of polymorphic GWT chains, and made heavy
use of SwitchPoint to reduce guard costs.
Here's the red/black bench that's been going around...the
compiler-level optimizations are the same in both cases, but the
latter numbers are with invokedynamic.
(higher is better...iterations/sec)
N
Am 14.05.2012 08:55, schrieb Rémi Forax:
[...]
>> so you mean to tell me that I have first to convert the Object to an
>> Integer and that Integer to int, instead of directly converting the
>> Object to an int? I see, I will try that out.
>
> Yes.
> You should not have to do that because you first
Am 14.05.2012 01:16, schrieb Mark Roos:
[...]
> So I decided that all my ints will be boxed (references), added a cache
> and some special prim
> methods for now and then follow Charles approach of a good indy design
> to take advantage
> of the optimization efforts. Based on my large scale benchma
On 05/13/2012 10:21 PM, Jochen Theodorou wrote:
> Am 13.05.2012 19:55, schrieb Rémi Forax:
> [...]
>> I think currently Groovy allows to replace + by a method
>> that will return everything you want.
>> But here, I think the spec of Groovy (if it means something)
>> should be changed to say that wh
Hi Jochen;
I also spent some time being concerned about the integer performance but
then decided
that this concern is probably premature based on the current state of
indy. One big unknown
to me is whether EA would ever recognize my holder for the prim int or if
it would only recognize
java In
Inline...
On May 13, 2012 3:15 PM, "Jochen Theodorou" wrote:
>
> Am 13.05.2012 19:21, schrieb Charles Oliver Nutter:
> [...]
> > You could also encode "a+b-c" as a single invokedynamic operation, but
> > I guess you're looking for a general s
Am 13.05.2012 19:55, schrieb Rémi Forax:
[...]
> I think currently Groovy allows to replace + by a method
> that will return everything you want.
> But here, I think the spec of Groovy (if it means something)
> should be changed to say that when your replace a method
> by another, the return type m
Am 13.05.2012 19:21, schrieb Charles Oliver Nutter:
[...]
> You could also encode "a+b-c" as a single invokedynamic operation, but
> I guess you're looking for a general solution...
yes, I am looking for a general solution. I was thinking of making the
whole express
ll be really the primtives too, then this means I will most
>> probably compile it like this:
>>
>> invokedynamic("minus", invokedynamic("plus",a,b), c)
>>
>> meaning the result of a+b will be an Object (since I won't know it is a
>> prim
obably compile it like this:
>
> invokedynamic("minus", invokedynamic("plus",a,b), c)
>
> meaning the result of a+b will be an Object (since I won't know it is a
> primitive) and then there will be one boxing for that, just to unbox
> again for the minus
Hi all,
I wanted to ask you of your opinion. If I am going to compile something
like a+b-c and a,b,c are all primtives, but I won't know that the
results will be really the primtives too, then this means I will most
probably compile it like this:
invokedynamic("minus", invoked
thod to f2Oop; use
> from_interpreted_offset instead of interpreter_entry_offset in
> TemplateTable::invokedynamic
>
> ! meth-lazy-7023639.patch
Hi Christian,
You forget to rename the name 'vfinal' in the comment
+ // Preserve the value of the vfinal flag on invokevirtual byt
::invokedynamic
! meth-lazy-7023639.patch
___
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Maybe I'm a bit late into the game, but we demoed with Frederic Le
Mouel at Devoxx France an early prototype of a dynamic AOP JVM agent
called JooFlux that takes advantage of invokedynamic. It's still a
research project at this stage, but we will eventually publish this
and release the
I thought this might be interesting to some folks on these lists, and
I am also interested in input on ways to improve this talk. I think it
will make a good "intro to invokedynamic" talk for other confs, so
I'll probably do it again.
I'm also *finally* going to do an epic b
That reminds me...I should hook up the (little used) globals in JRuby to indy.
Thanks!
- Charlie
On Fri, Apr 20, 2012 at 11:23 AM, MacGregor, Duncan (GE Energy)
wrote:
> Really it's similar to lazy constants, but we use invokeDynamic for
> global variable access which we have a l
Really it's similar to lazy constants, but we use invokeDynamic for
global variable access which we have a lot of since our language is
exemplar based we have a lot of globals that hold those exemplars. The
name of the global is passed as an argument to the bootstrap and this
returns a con
I'm filling out the remaining slides in my JAX keynote on
InvokeDynamic, and I'm interested in additional "clever" uses of
invokedynamic folks have discovered.
I have included the following, which we make use of in JRuby:
* Dynamic invocation (obviously)
* Lazy constants
Am 06.01.2012 17:22, schrieb John Rose:
> On Jan 6, 2012, at 4:57 AM, Jochen Theodorou wrote:
>
>> I see where it comes from, but "reusing" that instead of making a new if
>> is not really needed, is it?
>>
>> Do people here agree this should be improved?
>
> The javadoc for this throw is:
> * @thr
On Jan 6, 2012, at 4:57 AM, Jochen Theodorou wrote:
> I see where it comes from, but "reusing" that instead of making a new if
> is not really needed, is it?
>
> Do people here agree this should be improved?
The javadoc for this throw is:
* @throws IllegalArgumentException if the target do
Hi all,
I noticed some of the error message are a bit strange. For example I was
going to use bindTo for a boolean, but primitives are not allowed. The
error message I then get is:
no leading reference parameter
Which makes no sense at all. Looking at the code:
if (type().parameterCo
Changeset: b093159bbe19
Author:jrose
Date: 2012-01-06 01:45 -0800
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b093159bbe19
meth-lazy: correct invokedynamic argument stacking (now runs JRuby tests with
indy)
! meth-lazy-7023639.patch
On Thu, Dec 1, 2011 at 9:47 AM, Stephen Bannasch
wrote:
> At 3:29 AM -0600 12/1/11, Charles Oliver Nutter wrote:
>>This is a pretty disappointing finding. I'm not yet sure whether it's
>>a bug in SwitchPoint optimization or in JRuby's use of SwitchPoint,
>>but I'd like to see your numbers with and
At 3:29 AM -0600 12/1/11, Charles Oliver Nutter wrote:
>This is a pretty disappointing finding. I'm not yet sure whether it's
>a bug in SwitchPoint optimization or in JRuby's use of SwitchPoint,
>but I'd like to see your numbers with and without this flag.
Latest JRuby master, on Java 1.6.0_27, ma
On Thu, Dec 1, 2011 at 2:23 AM, Charles Oliver Nutter
wrote:
> I am still seeing rebinding in profiles of some of the remaining slow
> benchmarks, so I'm missing something.
Bleah, I seem to have found the problem.
If I disable the use of SwitchPoint for class-mutation-originated call
site invali
On Wed, Nov 30, 2011 at 9:52 PM, Stephen Bannasch
wrote:
> At 3:03 PM -0500 11/30/11, Stephen Bannasch wrote:
>>Benchmark code here: https://gist.github.com/1410423
>
> The hpricot benchmark is also slowed down consdierably.
I have found more issues in my invokedynamic binding
At 5:25 PM -0600 11/30/11, Charles Oliver Nutter wrote:
>On Wed, Nov 30, 2011 at 3:27 PM, Stephen Bannasch
> wrote:
>> user system totalreal
>> rexml 73.54 0.00 73.54 ( 73.54)
>> hpricot 6.483000 0.
I may have found one big problem, using some rexml benchmarks I found.
The instance-variable logic I just added seems like it might not be
working right. It was supposed to be experimental and turned off, but
I used the wrong flag.
Invokedynamic disabled (-Xcompile.invokedynamic=false)
Parsing
1 - 100 of 409 matches
Mail list logo
