On Tue, 2 May 2023 13:57:37 GMT, Rémi Forax <fo...@openjdk.org> wrote:
>> Jan Lahoda has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains four additional >> commits since the last revision: >> >> - Adding comments >> - Improving performance >> - Merge branch 'master' into JDK-8291966 >> - 8291966: SwitchBootstrap.typeSwitch could be faster > > 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! ------------- PR Comment: https://git.openjdk.org/jdk/pull/9779#issuecomment-1566691245
