On Mon, 29 May 2023 07:33:36 GMT, Francesco Nigro <d...@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
