Portability hazards of i31ref with non-native engines

[kb-1000]

If I understand this right, i31ref is supposed to be implemented by the engine as a tagged pointer.

As mentioned in https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md#unboxed-scalars, a larger type could cause portability hazards by forcing the engine to do hidden allocations or use inefficient representations on some platforms.

However, something that was apparently missed (at least, my search in this repo's discussions did not reveal anything, forgive me if I'm mistaken) is the possibility of the runtime itself not having a concept of pointers or tagged pointers as native code does. Java for example has "pointers" as in object references, but those cannot encode integers without boxing into an Integer object, so a WASM engine written in and/or targeting Java would probably have to do that.

Similarly, .NET has reference types, which as far as I'm aware also cannot encode integers without boxing. Unlike Java, it has actual pointers too, but those are not tracked by the .NET GC.

(for somewhat related reasons I'm also not a fan of how the wasm test suite handles externref, but that's a different topic)

I'm not sure how to proceed from there... Is this an acceptable price to pay? What would alternatives look like?

[titzer]

I think this is a fair point. One option on such platforms is to have a limited number, say < 2^20, pre-allocated, cached boxes. Thus for "really small" integers, no allocation would happen. While the performance hit of boxing on these underlying platforms is not ideal, it is at least "no worse" than what these languages would have paid targeting those platforms independent of WebAssembly. For the JVM, in the long run it might force more efficient value types. Incidentally, the Java platform does cache a small number of boxed integers if one does Integer.valueOf (https://docs.oracle.com/javase/8/docs/api/java/lang/Integer.html#valueOf-int-).