Replies: 1 comment
-
|
At least for the JVM and other garbage-collected runtimes, we could have an object that to the frontend acts as a deterministic allocator, but to the backend acts as a mechanism for marking resources as garbage-collectable. I'm thinking of doing something similar in a TypeScript library. We can then assert that users can never access garbage-collectable resources and enforce that in our allocator implementation, which all allocation calls will have to go through. As for the question overall, I'd like to selfishly say that we should support MacOS and whatever Linux distro you use, as well as a common distro for containers to use as their base layer. I'd also like to lazily say that we should support the JVM since I have very good resources on Java memory allocation. However, I think the right answer is we should support as many as we can in the long run, hopefully achieving parity with at least, in order of levels of perceived support:
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
There are multiple architectures that are commonly used. Do we want to support all of them? Do we want to support just one to start?
In past projects, I've only managed to write code generation for Linux on x86-64 (System V ABI).
One possibility for good cross-platform compatibility is LLVM. Another intriguing possibility is JVM.
With any choice we make regarding this, considerations should be made about what features we want to have that may not be supported by the target architecture.
For example, the JVM has built-in garbage collection, which may cause complications with our Allocator memory model.
Beta Was this translation helpful? Give feedback.
All reactions