On Tue, 30 May 2023 09:32:02 GMT, Jan Lahoda <jlah...@openjdk.org> wrote:
>> @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. @lahodaj > So, this patch still seems useful to me, with a potential for future > improvements, both inside and outside type switch bootstrap itself. Yep, it is indeed still valuable: sorry if I didn't make it clear. My point is more related the need of the amount of type checks in some cases (reducing the impact of JDK-8180450); if a typecheck-like op is still required to route to some case (and which cost depends by many factors really), any target `checkcast` could be maybe saved. I'm currently unaware if the current state of this PR bring any improvement on this front too (or if is even possible), but this would be welcome regardless JDK-8180450 and much more if considering the mentioned issue too. This can be left for a follow-up PR too, obviously. I'm bringing the attention to this exactly because regardless JDK-8180450, secondary supers negative type check still have costs that would be awesome if could be addressed while exposing this feature to final users. ------------- PR Comment: https://git.openjdk.org/jdk/pull/9779#issuecomment-1570214110
