Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
WIP/RFC unbox more immutables #18632
The codegen/gc part of this is basically working.
This patch allows us to unbox most immutables. By unbox I mean : allocate/store them on the stack, inline them in other objects and inline them in arrays.
Cycles are a fundamental problem, if A has a field of type B and B of type A, we obviously can't inline them into each other. The cycle needs to be broken, the annoying part is that it should be done in a predictable way. For now, on this PR, it's done in DFS order which means that for example the layout of B will differ if we ever instantiated an A before. Not good. Proposal I remember about that (Jameson @ juliacon iirc) was to make types boxed iff they are part of any field cycle.
So if A has a pointer field and we make, e.g., an uninitialized array of A, this branch uses the nullity of the field of A as a marker that the corresponding slot in the array is #undef. This only works if the field of a valid instance of A can never be null, i.e., if
This makes most code (at least all the test suite :-)) work but I think the following rules are really weird :
The only difference between a type that is boxed or not is memory layout, but I'd assume that we want that to be easily predictable since for example people routinely interface with C.
A proposed alternative by Yichao was to make it entierly opt-in and error out if inlining was not possible. I'm worried this will lead to yet-another-annotation that people will sprinkle everywhere.
For performance, specially crafted tests (like summing lines of a very skinny matrix using subarrays) show some improvements by avoiding gc allocation. Not super satisfying for now and casual inspection of generated asm shows a lot of stack movement. We can work on that though, probably by improving llvm's visibility of our rooting mechanism and/or just using statepoints.
(to sweeten the deal I've thrown in improved undef ref errors)
Yeah I'm just afraid that it'll make things worse since everytime the immutable will go in/out of local scope it'll have to be unboxed/boxed so we may end up making more boxes than today.
The gc objects on the stack have a pointer to them in the gc frame and the special treatment in gc is done by checking if they are inside the task stack's bounds.
My argument for opt-in is also (local) predictability.
The question is that for given types
I would have liked to see this in 0.6 since I think this is a very valuable optimisation especially for
It would be awesome to have this early on for the next release cycle!
Just thought I'd drop by to point out that this PR won't alter