More on: Small static method marked not entrant, inlining reversed?

[Rémi Forax]

Le 22/09/2010 19:36, Tom Rodriguez a écrit :
> On Sep 22, 2010, at 2:30 AM, Rémi Forax wrote:
>
>    
>> Le 21/09/2010 21:48, Tom Rodriguez a écrit :
>>      
>>> Thanks for the test case.  The reason it works well for C1 is that we have an explicit check for single implementor interfaces and insert an extra checkcast to confirm that the type really is the type we expect.  The extra check is needed since interface types aren't actually checked by the verifier.  In your example the extra check isn't actually needed since all array stores are actually type checked so any type loaded from the array must actually implement the interface.  C2 generally relies on type profiling to get cases like this but since type profiling is tracking the type of the receiver instead of the actual method being invoked it doesn't handle this case that well.  It's not hard to do something better for this case.  I filed 6986483 for this.
>>>
>>> tom
>>>
>>>        
>> Thanks Tom,
>> I know since a long time that the verifier doesn't check interface but
>> I have discovered recently the runtime implication.
>>      
> Yes it's a bummer.  We've discussed improving C2s type system to handle interface types better since in some cases interfaces type can be trusted.  Adding some static verification of interfaces would also allow us to trust them more which could help.
>
>    
>> I wonder if the fix can improve performance of benchmarks that use java.util collection,
>> because this API uses a similar class hierarchy scheme.
>>      
> There are normally more than 1 or 2 implementors of the collection interfaces so static information isn't as useful.  Much of the time the existing type profiling works great because we're only seeing a single type but of course there are cases where it falls down.

Yes but most of collections inherits from an abstract class, 
AbstractList, AbstractCollection etc,
so even if there are more than 2 implementors, they can inherits from 
the same abstract class.

>   Analyzing the hierarchy of the types that show up in the type profile might allow us to do a slightly better job but I suspect we'd have to modify our profile collection to record more types or to record methods instead of classes if we want to handle more complex call sites.
>    

You don't have to record methods if you maintain pointers from an 
abstract method and their
implementations. If there is only one implementation, you even don't 
need to use
type profiles.

You can also improve type profiling if there are more than 2 types
by trying to find if all types have a common supertype which is more
precise that the receiver type.
As I previously said, this is a common pattern when using collection.

And when JITing, if all loaded subtypes of the common supertype
have one implementation for the method declared at callsite,
you can install an instanceof guard on that common supertype
and safely inline the implementation. You also need to deopt
if a new subtype is loaded with a new method implementation.

> tom
>
>    

Rémi