again on megamorphic problems

[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 megamorphic call
>> sites internally and if so
>> then creating new methods during my lookup rather than caching the
>> existing ones.  This would move
>> the specialization up one level but the internal sites would now be
>> monomorphic
> ignoring that I cannot easily do that, this surely is an approach, but I
> am worried about memory here. For one you would have a tendency to keep
> references to class you may garbage collect otherwise, for the other
> your class would grow and grow...

The real solution is to have a way to say, I want a method handle on a 
method but with a fresh profile.
John and I discuss about that after the last JVM Summit, he says that 
being able to separate the profile from the method will be hard to do in 
Hotspot.

The main issue with the duplication of methods at bytecode level to have 
several profiles is that the freshly generated bytecode have the wrong 
performance counter and can be considered by the JIT has never been 
called or at least not called enough to be JITed.
This is a known issue of the current implementation of JDart.

A compromise can be to have a way to read/write the profile and the perf 
counter of any methods,
Graal already provides these features.
It will be also very useful when you want to test a Java code to be able 
to inject a profile artificially.

>
> bye Jochen

cheers,
Rémi