I’m looking at the way the kotlin wasm compiler encodes types and wondering if it can be optimised. ...

# webassembly

[Charlie Tapping]

I’m looking at the way the kotlin wasm compiler encodes types and wondering if it can be optimised. Currently it creates one large recursive type tree that encompasses everything from kotlin.Any upwards, so all the stdlib structures like arrays, lists plus any new types defined in the users program. This leads to some pretty deeply nested type structures. Would it be possible to instead leverage the type ref null any, which is baked into the gc type system as the root, and that way you can encode multiple trees representing distinct hierarchies rather than one large one? You could replace calls to ref.test and ref.cast where you comparing against kotlin.Any to ref null any instead?

[Charlie Tapping]

I guess theres some considerations when working with modules in different languages where for example kotlins any is the same as pythons any

[bashor]

I’m wondering why do you ask about it.

[bashor]

Anyway, in the master, kotlin toolchain generates many smaller recursion groups instead of one big.

[bashor]

Important fact is that structurally equal types from different rec groups could be “merged” for structurally equal rec groups. Which means that either
• we need implement own type casts
• or somehow prevent merging types (using one big rec gorup is easest solution)

[bashor]

Re kotlin.Any vs ref null any
I doubt it will help with rec groups, but I thought about it in context of interop (spec with JS) and where it may simplify some things but complicate others, e.g. calling Any’s members (hashCode, equals, toString).

[Charlie Tapping]

I came across this while debugging a bug in chasms casting logic, when I printed the definedtype to stdout it was enormous hence why I was looking into the encoding

[Charlie Tapping]

@bashor Is there a way to consistently produce names on functions when using the kotlin wasm compiler? For example I have one function like this: (func $"#func293 main$lambda.invoke" (@name "main$lambda.invoke") (;293;) and another lacks the name tag (func $main$lambda.invoke (;292;)

[bashor]

@Charlie Tapping I don’t know why there is no name, to understand that we need to debug compiler with a specific pice of code. Anyway in both cases it looks like they were some kind of anonymous declarations so I doubt the names would help much.

[Charlie Tapping]

I’m building instrumentation into chasm that rewrites the bytecodes and add probes in places to help debug things, I’m working on probes for function entrance and exit and would like to print the function names rather than their indices. So I wondering if there is a flag for the kotlin compiler to produce debug symbols like these names but consistently for all functions

[Charlie Tapping]

I can use the actual function name its not a problem really I just was wondering why some had name tags

[bashor]

A name annotation in text representation is based on information from name section.

[bashor]

When you call compiler directly you need to provide -Xwasm-debug-info to get them generated, in kotlin gradle plugin the option is always provided.