-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Portability hazards of i31ref with non-native engines #543
Comments
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 |
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?
The text was updated successfully, but these errors were encountered: