Re: megamorphic lambda prevention

[Alexander Turner]

The simple answer is 'yes it is easy to go megamorphic'. The interesting
question is why does this matter. You already have a complex dispatch
system here and you are calling method off it. The cost of a well coded
megamorphic dispatch system under the covers is not likely to have any
significant impact on over all performance.

The key (from my experience so far) is to ensure that you fall over to mega
morphic dispatch cleanly with out letting fall back chains grow too long
and keep the dispatch system very fast.

- AJ

On 21 June 2012 11:37, Jochen Theodorou  wrote:

> Hi all,
>
> I was wondering... if I have code like this:
>
> list.each { x -> foo(x) }
> list.each { x -> bar(x) }
> list.each { x -> something(x) }
>
> then isn't it the a case where within the each method we easily get
> something megamorphic, since there are too many different kinds of
> lambdas involved? Isn't that a general problem with internal iterators
> and is there any plan to enhance hotspot to counter that problem?
>
> bye Jochen
>
> --
> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
> blog: http://blackdragsview.blogspot.com/
> german groovy discussion newsgroup: de.comp.lang.misc
> For Groovy programming sources visit http://groovy-lang.org
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: megamorphic lambda prevention

[Alexander Turner]

Duncan,

You do it gain! I worked on the very code you mention a few days ago and
yet I _still_ did not understand what you just said. For the benefit of the
mortals here present - it would be brilliant if you could explain it a
little more :)

Thanks  - AJ :)

On 21 June 2012 12:21, MacGregor, Duncan (GE Energy) <
duncan.macgre...@ge.com> wrote:

> Yes, it is very easy for those sites to become megamorphic. We work round
> this by using exactInvokers on function invocation call sites, and caching
> on the method type of the functions rather than the types.
>
> On 21/06/2012 11:37, "Jochen Theodorou"  wrote:
>
> >Hi all,
> >
> >I was wondering... if I have code like this:
> >
> >list.each { x -> foo(x) }
> >list.each { x -> bar(x) }
> >list.each { x -> something(x) }
> >
> >then isn't it the a case where within the each method we easily get
> >something megamorphic, since there are too many different kinds of
> >lambdas involved? Isn't that a general problem with internal iterators
> >and is there any plan to enhance hotspot to counter that problem?
> >
> >bye Jochen
> >
> >--
> >Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
> >blog: http://blackdragsview.blogspot.com/
> >german groovy discussion newsgroup: de.comp.lang.misc
> >For Groovy programming sources visit http://groovy-lang.org
> >
> >___
> >mlvm-dev mailing list
> >mlvm-dev@openjdk.java.net
> >http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: megamorphic lambda prevention

[Rémi Forax]

On 06/21/2012 09:17 PM, Jochen Theodorou wrote:
> Mark,
>
> can you explain what you mean with "depth"? if you mean the depth of a
> call path, then more than 20 is indeed more rare, but it depends on the
> circumstances. In Grails for example (web frame work in the Groovy
> world) a depth of 20 should be a much more commen case, simply because
> there is a framework around it, that already has the usual call path
> depth. As for seeing depth of the call path from the point the blokc is
> called to the point the iterator method is called, that is usually a
> quite short path of maybe depth <3. But maybe you something else by depth.

No, I think here depth means depth of the guardWithTest,
i.e. number of different receiver types.

> Anyway, the goal is inlining and inlining is something you get with a
> more or less constant call site. Invalidating it means to remove that
> attribute of being constant, the counter will start new. That's why you
> may be able to remove old cases from your call site structure that way,
> but for inlining it does not help at all. Well... I am sure Remi will
> correct me should I tell wrong things here ;)

adding a new GWT to a tree of GWTs or trashing the tree of GWTs
and use only one GWT is equivalent if the tree of GWTs is already JITed,
because the generated code will be deoptimized anyway.

A big tree of GWTs is really bad because it's a linear search so it's slow,
moreover a code with to many nodes will not be inlined at all.

Also trashing a tree of GWTs is not only a way remove path that
has not used but also a way to re-order a tree of GWTs.

> bye Jochen

cheers,
Rémi

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: megamorphic lambda prevention

[Rémi Forax]

On 06/21/2012 04:38 PM, Matt Fowles wrote:
> All~
>
> Couldn't the VM detect hot mega-morphic methods and have them bestow 
> some of their hotness upon the callers.

Yes, that's basically the idea when I say the VM can create a path backward.

>  Making their callers more likely to inline them.

only if the receiver of the call depends on parameters.
Also, the VM should not trust the profile but the propagated types from 
the parameters.

>  Then you have a different call site for the each which is likely to 
> be monomorphic.

yes;
Also in case of OSR, the VM has more info because it knows the call 
stack, so going backward can be easier.

>
> Matt

Rémi

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: megamorphic lambda prevention

[Jochen Theodorou]

Mark,

can you explain what you mean with "depth"? if you mean the depth of a 
call path, then more than 20 is indeed more rare, but it depends on the 
circumstances. In Grails for example (web frame work in the Groovy 
world) a depth of 20 should be a much more commen case, simply because 
there is a framework around it, that already has the usual call path 
depth. As for seeing depth of the call path from the point the blokc is 
called to the point the iterator method is called, that is usually a 
quite short path of maybe depth <3. But maybe you something else by depth.

Anyway, the goal is inlining and inlining is something you get with a 
more or less constant call site. Invalidating it means to remove that 
attribute of being constant, the counter will start new. That's why you 
may be able to remove old cases from your call site structure that way, 
but for inlining it does not help at all. Well... I am sure Remi will 
correct me should I tell wrong things here ;)

bye Jochen

Am 21.06.2012 20:27, schrieb Mark Roos:
> Hi Jochen
>
> I was wondering at what depth you would consider a call site to be
> megamorphic?
>
> I have done quite a bit of profiling on Smalltalk ( which uses lots of
> blocks as iterators)
> and rarely see depths > 20.
 >
> As this depth seems to be time dependent ( at any one time its < 3 but
> over time it grows)
> I just invalidate the site when it gets past 20. But I am wondering what
> the best approach
> would be.
>
> I would like to do real time gwt chain inspection and modification but I
> don't think that is possible.
>
> regards
> mark
>
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: megamorphic lambda prevention

[Mark Roos]

Hi Jochen

I was wondering at what depth you would consider a call site to be 
megamorphic?

I have done quite a bit of profiling on Smalltalk ( which uses lots of 
blocks as iterators)
and rarely see depths > 20.

As this depth seems to be time dependent ( at any one time its < 3 but 
over time it grows)
I just invalidate the site when it gets past 20. But I am wondering what 
the best approach
would be.

I would like to do real time gwt chain inspection and modification but I 
don't think that is possible.

regards
mark___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: megamorphic lambda prevention

[Rémi Forax]

On 06/21/2012 04:38 PM, Matt Fowles wrote:
> All~
>
> Couldn't the VM detect hot mega-morphic methods and have them bestow 
> some of their hotness upon the callers.  Making their callers more 
> likely to inline them.  Then you have a different call site for the 
> each which is likely to be monomorphic.
>
> Matt

yes, that the idea when i said the the VM can go backward.
Note that it works only for callsites that are megamorphic because of a 
value
that comes from the parameters of the high order method.

There is also a special case for OSR because in that case you may have 
the stack
so it can be easier to go backward.

Rémi

>
> On Thu, Jun 21, 2012 at 10:30 AM, Rémi Forax  > wrote:
>
> On 06/21/2012 04:12 PM, Jochen Theodorou wrote:
> > Am 21.06.2012 16 :00, schrieb Rémi Forax:
> >> On 06/21/2012 03:52 PM, Jochen Theodorou wrote:
> >>> Am 21.06.2012 13 :57, schrieb Krystal Mok:
> > [...]
>  I wonder how well the new interpreter design in Graal would
> handle this
>  kind of case, since it's supposed to have picked the good
> parts from
>  trace-based compilation, but without actually having to do
> tracing.
>  Can't wait to see more details of it at this year's JVM
> Language Summit.
> >>> If I understood Thomas right, then Graal doesn't have that
> problem.
> >>> Afaik hotspot doesn't have to have that problem too. It just was a
> >>> design decision not to make call site caching per execution
> path. Afaik
> >>> chaning that now would take quite some effort, but is not
> impossible.
> >> You can create the execution path backward, when it's needed.
>
> I was thinking that the VM can create the path backward.
>
> > you can in PHP.reboot, but in Groovy I don't have access to the full
> > execution path. Inside "each" I don't know what did call me and
> at the
> > point of where I call each, I don't see what each will actually do.
>
> yes, but you can detect that 'each' is a special method because
> it takes a closure (Closure) as parameter and try to do some magic.
>
> >
> > bye blackdrag
> >
>
> Rémi
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net 
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
>
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: megamorphic lambda prevention

[Rémi Forax]

On 06/21/2012 04:38 PM, Matt Fowles wrote:
> All~
>
> Couldn't the VM detect hot mega-morphic methods and have them bestow 
> some of their hotness upon the callers.  Making their callers more 
> likely to inline them.  Then you have a different call site for the 
> each which is likely to be monomorphic.
>
> Matt

yes, that the idea when i said the the VM can go backward.
Note that it works only for callsites that are megamorphic because of a 
value
that comes from the parameters of the high order method.

There is also a special case for OSR because in that case you may have 
the stack
so it can be easier to go backward.

Rémi

>
> On Thu, Jun 21, 2012 at 10:30 AM, Rémi Forax  > wrote:
>
> On 06/21/2012 04:12 PM, Jochen Theodorou wrote:
> > Am 21.06.2012 16 :00, schrieb Rémi Forax:
> >> On 06/21/2012 03:52 PM, Jochen Theodorou wrote:
> >>> Am 21.06.2012 13 :57, schrieb Krystal Mok:
> > [...]
>  I wonder how well the new interpreter design in Graal would
> handle this
>  kind of case, since it's supposed to have picked the good
> parts from
>  trace-based compilation, but without actually having to do
> tracing.
>  Can't wait to see more details of it at this year's JVM
> Language Summit.
> >>> If I understood Thomas right, then Graal doesn't have that
> problem.
> >>> Afaik hotspot doesn't have to have that problem too. It just was a
> >>> design decision not to make call site caching per execution
> path. Afaik
> >>> chaning that now would take quite some effort, but is not
> impossible.
> >> You can create the execution path backward, when it's needed.
>
> I was thinking that the VM can create the path backward.
>
> > you can in PHP.reboot, but in Groovy I don't have access to the full
> > execution path. Inside "each" I don't know what did call me and
> at the
> > point of where I call each, I don't see what each will actually do.
>
> yes, but you can detect that 'each' is a special method because
> it takes a closure (Closure) as parameter and try to do some magic.
>
> >
> > bye blackdrag
> >
>
> Rémi
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net 
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
>
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: megamorphic lambda prevention

[Matt Fowles]

All~

Couldn't the VM detect hot mega-morphic methods and have them bestow some
of their hotness upon the callers.  Making their callers more likely to
inline them.  Then you have a different call site for the each which is
likely to be monomorphic.

Matt

On Thu, Jun 21, 2012 at 10:30 AM, Rémi Forax  wrote:

> On 06/21/2012 04:12 PM, Jochen Theodorou wrote:
> > Am 21.06.2012 16:00, schrieb Rémi Forax:
> >> On 06/21/2012 03:52 PM, Jochen Theodorou wrote:
> >>> Am 21.06.2012 13:57, schrieb Krystal Mok:
> > [...]
>  I wonder how well the new interpreter design in Graal would handle
> this
>  kind of case, since it's supposed to have picked the good parts from
>  trace-based compilation, but without actually having to do tracing.
>  Can't wait to see more details of it at this year's JVM Language
> Summit.
> >>> If I understood Thomas right, then Graal doesn't have that problem.
> >>> Afaik hotspot doesn't have to have that problem too. It just was a
> >>> design decision not to make call site caching per execution path. Afaik
> >>> chaning that now would take quite some effort, but is not impossible.
> >> You can create the execution path backward, when it's needed.
>
> I was thinking that the VM can create the path backward.
>
> > you can in PHP.reboot, but in Groovy I don't have access to the full
> > execution path. Inside "each" I don't know what did call me and at the
> > point of where I call each, I don't see what each will actually do.
>
> yes, but you can detect that 'each' is a special method because
> it takes a closure (Closure) as parameter and try to do some magic.
>
> >
> > bye blackdrag
> >
>
> Rémi
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: megamorphic lambda prevention

[Rémi Forax]

On 06/21/2012 04:12 PM, Jochen Theodorou wrote:
> Am 21.06.2012 16:00, schrieb Rémi Forax:
>> On 06/21/2012 03:52 PM, Jochen Theodorou wrote:
>>> Am 21.06.2012 13:57, schrieb Krystal Mok:
> [...]
 I wonder how well the new interpreter design in Graal would handle this
 kind of case, since it's supposed to have picked the good parts from
 trace-based compilation, but without actually having to do tracing.
 Can't wait to see more details of it at this year's JVM Language Summit.
>>> If I understood Thomas right, then Graal doesn't have that problem.
>>> Afaik hotspot doesn't have to have that problem too. It just was a
>>> design decision not to make call site caching per execution path. Afaik
>>> chaning that now would take quite some effort, but is not impossible.
>> You can create the execution path backward, when it's needed.

I was thinking that the VM can create the path backward.

> you can in PHP.reboot, but in Groovy I don't have access to the full
> execution path. Inside "each" I don't know what did call me and at the
> point of where I call each, I don't see what each will actually do.

yes, but you can detect that 'each' is a special method because
it takes a closure (Closure) as parameter and try to do some magic.

>
> bye blackdrag
>

Rémi

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: megamorphic lambda prevention

[Rémi Forax]

On 06/21/2012 03:55 PM, Jochen Theodorou wrote:
> Am 21.06.2012 13:21, schrieb MacGregor, Duncan (GE Energy):
>> Yes, it is very easy for those sites to become megamorphic. We work round
>> this by using exactInvokers on function invocation call sites, and caching
>> on the method type of the functions rather than the types.
> So in my own words... you don't check on the type of the lambda, but on
> what it takes as input, thus you get no changes for differing lambdas.
> Is that about right? That's a nice idea, indeed
>
> bye blackdrag
>

at least you will not change the inlining cache too often and
you can adapt arguments for several method handles
but the VM will not consider the method handle as constant
so it will not be inlined with the code of the loop.

Another way is to transform the high order function (each() in your example)
as a method handle tree but the JSR 292 lacks a loop combiner.

In Groovy, you can also duplicate the bytecode of the high order function
when you are able to emit bytecode at runtime, see [1].

Said differently and with Hotspot in mind, an idea is that you can 
execute a code but
with another profile metadata object that the usual one.
Because Hotspot is already able to generate code with a profile object
created by the interpreter (for tiered compilation), having a way to ask
for a specialized version of a method with a fresh profile doesn't seem 
too hard
but it's more a hack than a real answer.

Rémi
[1] 
http://weblogs.java.net/blog/forax/archive/2011/04/08/fixing-inlining-%E2%80%9Cproblem%E2%80%9D-prototype


___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: megamorphic lambda prevention

[Jochen Theodorou]

Am 21.06.2012 15:58, schrieb Rémi Forax:
[...]
> I spend a couple of days in Linz last month with the Autrian part of the
> Graal team (Thomas, Lukas and Gilles)
> and we discuss about this issue (among other things).
> I think we should book a room during the Summit to try to see if
> something can be done in Hotspot.

cool, I would like to take part in that... even if I may not be of help 
since I am surely not hotspot internals expert

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: megamorphic lambda prevention

[Jochen Theodorou]

Am 21.06.2012 15:55, schrieb Jochen Theodorou:
> Am 21.06.2012 13:21, schrieb MacGregor, Duncan (GE Energy):
>> Yes, it is very easy for those sites to become megamorphic. We work round
>> this by using exactInvokers on function invocation call sites, and caching
>> on the method type of the functions rather than the types.
>
> So in my own words... you don't check on the type of the lambda, but on
> what it takes as input, thus you get no changes for differing lambdas.
> Is that about right? That's a nice idea, indeed

actually I am wondering... I guess I didn't fully understand yet, since 
even if you avoid the call site invalidation that way, you still have 
kind of a "branch point" the JIT will not inline. What it can inline is 
everything till the actual invocation, then it ends, since there are 
different MethodHandles involved.

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: megamorphic lambda prevention

[Jochen Theodorou]

Am 21.06.2012 16:00, schrieb Rémi Forax:
> On 06/21/2012 03:52 PM, Jochen Theodorou wrote:
>> Am 21.06.2012 13:57, schrieb Krystal Mok:
[...]
>>> I wonder how well the new interpreter design in Graal would handle this
>>> kind of case, since it's supposed to have picked the good parts from
>>> trace-based compilation, but without actually having to do tracing.
>>> Can't wait to see more details of it at this year's JVM Language Summit.
>> If I understood Thomas right, then Graal doesn't have that problem.
>> Afaik hotspot doesn't have to have that problem too. It just was a
>> design decision not to make call site caching per execution path. Afaik
>> chaning that now would take quite some effort, but is not impossible.
>
> You can create the execution path backward, when it's needed.

you can in PHP.reboot, but in Groovy I don't have access to the full 
execution path. Inside "each" I don't know what did call me and at the 
point of where I call each, I don't see what each will actually do.

bye blackdrag

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: megamorphic lambda prevention

[Rémi Forax]

On 06/21/2012 03:52 PM, Jochen Theodorou wrote:
> Am 21.06.2012 13:57, schrieb Krystal Mok:
>> That's "the inlining problem" that Cliff Click was talking about [1], right?
> yes, the issue was actually mentioned more than once on this list already
>
>> I wonder how well the new interpreter design in Graal would handle this
>> kind of case, since it's supposed to have picked the good parts from
>> trace-based compilation, but without actually having to do tracing.
>> Can't wait to see more details of it at this year's JVM Language Summit.
> If I understood Thomas right, then Graal doesn't have that problem.
> Afaik hotspot doesn't have to have that problem too. It just was a
> design decision not to make call site caching per execution path. Afaik
> chaning that now would take quite some effort, but is not impossible.

You can create the execution path backward, when it's needed.

>
> bye blackdrag
>

Rémi

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: megamorphic lambda prevention

[Jochen Theodorou]

Am 21.06.2012 13:21, schrieb MacGregor, Duncan (GE Energy):
> Yes, it is very easy for those sites to become megamorphic. We work round
> this by using exactInvokers on function invocation call sites, and caching
> on the method type of the functions rather than the types.

So in my own words... you don't check on the type of the lambda, but on 
what it takes as input, thus you get no changes for differing lambdas. 
Is that about right? That's a nice idea, indeed

bye blackdrag

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: megamorphic lambda prevention

[Rémi Forax]

On 06/21/2012 01:57 PM, Krystal Mok wrote:
> That's "the inlining problem" that Cliff Click was talking about [1], 
> right?

yes,

>
> I wonder how well the new interpreter design in Graal would handle 
> this kind of case, since it's supposed to have picked the good parts 
> from trace-based compilation, but without actually having to do 
> tracing. Can't wait to see more details of it at this year's JVM 
> Language Summit.

I spend a couple of days in Linz last month with the Autrian part of the 
Graal team (Thomas, Lukas and Gilles)
and we discuss about this issue (among other things).
I think we should book a room during the Summit to try to see if 
something can be done in Hotspot.

>
> - Kris

Rémi

>
> [1]: 
> http://www.azulsystems.com/blog/cliff/2011-04-04-fixing-the-inlining-problem 
>
>
> On Thu, Jun 21, 2012 at 6:37 PM, Jochen Theodorou  > wrote:
>
> Hi all,
>
> I was wondering... if I have code like this:
>
> list.each { x -> foo(x) }
> list.each { x -> bar(x) }
> list.each { x -> something(x) }
>
> then isn't it the a case where within the each method we easily get
> something megamorphic, since there are too many different kinds of
> lambdas involved? Isn't that a general problem with internal iterators
> and is there any plan to enhance hotspot to counter that problem?
>
> bye Jochen
>
> --
> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
> blog: http://blackdragsview.blogspot.com/
> german groovy discussion newsgroup: de.comp.lang.misc
> For Groovy programming sources visit http://groovy-lang.org
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net 
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>


___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: megamorphic lambda prevention

[Jochen Theodorou]

Am 21.06.2012 13:57, schrieb Krystal Mok:
> That's "the inlining problem" that Cliff Click was talking about [1], right?

yes, the issue was actually mentioned more than once on this list already

> I wonder how well the new interpreter design in Graal would handle this
> kind of case, since it's supposed to have picked the good parts from
> trace-based compilation, but without actually having to do tracing.
> Can't wait to see more details of it at this year's JVM Language Summit.

If I understood Thomas right, then Graal doesn't have that problem. 
Afaik hotspot doesn't have to have that problem too. It just was a 
design decision not to make call site caching per execution path. Afaik 
chaning that now would take quite some effort, but is not impossible.

bye blackdrag

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: megamorphic lambda prevention

[Krystal Mok]

That's "the inlining problem" that Cliff Click was talking about [1], right?

I wonder how well the new interpreter design in Graal would handle this
kind of case, since it's supposed to have picked the good parts from
trace-based compilation, but without actually having to do tracing. Can't
wait to see more details of it at this year's JVM Language Summit.

- Kris

[1]:
http://www.azulsystems.com/blog/cliff/2011-04-04-fixing-the-inlining-problem


On Thu, Jun 21, 2012 at 6:37 PM, Jochen Theodorou  wrote:

> Hi all,
>
> I was wondering... if I have code like this:
>
> list.each { x -> foo(x) }
> list.each { x -> bar(x) }
> list.each { x -> something(x) }
>
> then isn't it the a case where within the each method we easily get
> something megamorphic, since there are too many different kinds of
> lambdas involved? Isn't that a general problem with internal iterators
> and is there any plan to enhance hotspot to counter that problem?
>
> bye Jochen
>
> --
> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
> blog: http://blackdragsview.blogspot.com/
> german groovy discussion newsgroup: de.comp.lang.misc
> For Groovy programming sources visit http://groovy-lang.org
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: megamorphic lambda prevention

[MacGregor, Duncan (GE Energy)]

Yes, it is very easy for those sites to become megamorphic. We work round
this by using exactInvokers on function invocation call sites, and caching
on the method type of the functions rather than the types.

On 21/06/2012 11:37, "Jochen Theodorou"  wrote:

>Hi all,
>
>I was wondering... if I have code like this:
>
>list.each { x -> foo(x) }
>list.each { x -> bar(x) }
>list.each { x -> something(x) }
>
>then isn't it the a case where within the each method we easily get
>something megamorphic, since there are too many different kinds of
>lambdas involved? Isn't that a general problem with internal iterators
>and is there any plan to enhance hotspot to counter that problem?
>
>bye Jochen
>
>-- 
>Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
>blog: http://blackdragsview.blogspot.com/
>german groovy discussion newsgroup: de.comp.lang.misc
>For Groovy programming sources visit http://groovy-lang.org
>
>___
>mlvm-dev mailing list
>mlvm-dev@openjdk.java.net
>http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

megamorphic lambda prevention

[Jochen Theodorou]

Hi all,

I was wondering... if I have code like this:

list.each { x -> foo(x) }
list.each { x -> bar(x) }
list.each { x -> something(x) }

then isn't it the a case where within the each method we easily get 
something megamorphic, since there are too many different kinds of 
lambdas involved? Isn't that a general problem with internal iterators 
and is there any plan to enhance hotspot to counter that problem?

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev