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

[Tom Rodriguez]

>> 
>>> 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.

Collections.java by itself contains 3 unique implementors of the each of the core collection interface to support checked, unmodifiable and synchronized variants.  These are unrelated to the abstract classes you mention above.  java.util.concurrent includes yet more unrelated variants.  So looking at the hierarchy is of little use for most of those interface types.  Anyway we can obviously do better than we are currently doing.

tom

> 
>>  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