On 21/12/2012 11:42, "Jochen Theodorou" wrote:
>Am 21.12.2012 12:28, schrieb MacGregor, Duncan (GE Energy Management):
>>For example, Charles, how do you handle the creation of literals /
>> constants when building specialised methods? Are the literals
>>instantiated
>> by two specialised versio
Am 21.12.2012 12:28, schrieb MacGregor, Duncan (GE Energy Management):
> I've been thinking about this due to the extensive mixin hierarchy in our
> runtime presenting some potential problems with the number of types being
> seen by some areas of code in some applications. It's going to be hard to
I've been thinking about this due to the extensive mixin hierarchy in our
runtime presenting some potential problems with the number of types being
seen by some areas of code in some applications. It's going to be hard to
magic this problem away at the JVM level due to the restrictions stated in
th
Am 21.12.2012 06:03, schrieb Charles Oliver Nutter:
> On Thu, Dec 20, 2012 at 7:10 AM, Jochen Theodorou wrote:
>> let us assume the following example... I have a method foo
>>
>> public Object foo(Object arg){return bar(arg)}
>>
>> nothing fancy, quite simple... and let us assume foo is called fro
On Thu, Dec 20, 2012 at 7:10 AM, Jochen Theodorou wrote:
> let us assume the following example... I have a method foo
>
> public Object foo(Object arg){return bar(arg)}
>
> nothing fancy, quite simple... and let us assume foo is called from
> dozens of places with differing argument types.
>
> If
>From Jochen
How many targets do you usually keep in the chain before dropping?
I currently set the max to 10. As most( > 98%) of my callsites are 10 or
less most of the
time there is no effect. I have not looked into if this is too deep for
the inliner or not. I have
been told that between 5
Hi Remi,
yes, I remember the discussion you had with John. I was there too ;)
Am 21.12.2012 00:32, schrieb Remi Forax:
> On 12/20/2012 11:44 PM, Jochen Theodorou wrote:
>> Am 20.12.2012 22:35, schrieb Mark Roos:
>> [...]
>>
> [...]
>
>>
>>> Another thought I had was to determine if a method has
On 12/20/2012 11:44 PM, Jochen Theodorou wrote:
> Am 20.12.2012 22:35, schrieb Mark Roos:
> [...]
>
[...]
>
>> Another thought I had was to determine if a method has megamorphic call
>> sites internally and if so
>> then creating new methods during my lookup rather than caching the
>> existing one
Am 20.12.2012 22:35, schrieb Mark Roos:
[...]
> I see the same for my Smalltalk implementation. In looking at my
> problem it seems that the
> megamorphic problem is temporal. In other words over a short time
> period the site is monomorphic
> then becomes megamorphic as more code runs.
yes, th
>From Jochen
If I understood right, then the call site in foo will become
megamorphic, making it impossible to inline bar into the place from
where foo is called. foo becomes like a inlining barrier so to say.
I see the same for my Smalltalk implementation. In looking at my problem
it seems t
ok, but what would a a more generic linkage in this case here?
Actually... maybe I am wrong with seeing bar as megamorphic in terms of
indy. In the shown case it is most probably enough to not to test the
argument at all, since the receiver has an Object parameter and is not
overloaded. I won't
I will just toot my own horn and say that Dynalink handles this - Nashorn
actually leverages this feature to detect megamorphic sites and relink them
differently. Dynalink keeps track of number of times a call site is
relinked, and if it reaches a configurable threshold [1], it'll start
returning t
12 matches
Mail list logo
