RFR: 8291966: SwitchBootstrap.typeSwitch could be faster [v2]

[Jan Lahoda]

On Mon, 29 May 2023 07:33:36 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> Also there is a lot of use cases where the type switch is called only with instances of the same class, for those scenarii, the VM should be able to fully remove the type switch and inline the body of the corresponding case like this is done with a virtual call.
>> 
>> I don't think there is a way currently to explain to the VM that the a hash map really acts as a cache so if the key is a constant then the value is a constant too (this optimization is also missing when JITing ClassValue.get()).
>
> @forax 
> 
> Hi! Sorry for this sudden message, but this one captured my attention
> 
>> and subtype checks are usually fast.
> 
> And I hope this PR to be the right place to raise this.
> 
> I was looking this PR to better understand how it applies to secondary supers and https://bugs.openjdk.org/browse/JDK-8180450 (that's still WIP) doesn't look like subtype checks are yet fast nor scalable (with multiple interfaces and > 1 receiver types observed) - see https://ionutbalosin.com/2023/03/jvm-performance-comparison-for-jdk-17/#typecheckscalabilitybenchmark that can be modified to use type switch too.
>  
> In addition, at least for secondary types, a missed `IsInstance` (ie which type isn't implemented) can cost O(n) over the secondary supers types (see https://ionutbalosin.com/2023/03/jvm-performance-comparison-for-jdk-17/#typecheckslowpathbenchmark) that's still not ideal, due to the high bootstrapping cost of `prnz scas`.
> 
> Hence, the implementation of type switch is likely to account for the existing (performance) deficiencies of the secondary supers type check or is relying on the fix https://bugs.openjdk.org/browse/JDK-8180450 that will appear at some point?
> 
> Hope to have interacted in the right way with this with the JDK dev community, and thanks again for your hard work on this wonderful piece of engineering!

@franz1981, thanks for your comment. I am afraid I don't know much about JDK-8180450, but I suspect that it will affect the (type) switch lookup. Please correct me if I am wrong, but it seems this patch is still an improvement over the current state, and when JDK-8180450 is resolved, it should automatically improve the type switch lookup as well. So, this patch still seems useful to me, with a potential for future improvements, both inside and outside type switch bootstrap itself.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/9779#issuecomment-1568108121