Unionize actor heap large and small chunks #4568
Conversation
ponylang-main
added
the
discuss during sync
|
Looks like the CI failure is unrelated. It seems we need to update some GitHub Actions versions in our CI workflows. |
|
@dipinhora please rebase this against main when you have a chance. |
So they can better fight for their rights.. Prior to this commit, small_chunk_t and large_chunk_t were distinct types. This was great for correctness but prevented a useful optimization. This commit changes things so that small_chunk_t and large_chunk_t have been combined into chunk_t which has a union in it for the small/large chunk specific fields. There are now a lot of assertions added in the relevant functions that deal with small and large chunks to ensure that the received chunk is of the right type because the compiler can no longer help enforce correctness. This allows for small and large chunk recycling to take advantage of the fact that the block backing a small chunk is the same size as the block backing the smallest large chunk size allowed so they both now use the same recycled chunk list. The large chunk recycling has also been enhanced to take advantage of the long tail distribution of allocation sizes and there are now multiple size specific chunk lists for large chunk recycling with one extra large chunk list for recycling that has all chunks bigger than the largest size specific list that is kept sorted and searched/used as the old large chunk recycling list was.
dipinhora
force-pushed
the
unionize_chunks
branch
from
9faf2d0 to
e5c1692
Compare
|
rebased |
|
Sorry that nobody has carved out the time to give this a meaningful review yet. Sean and I both feel this requires attention. Sorry for the delay. |
no worries.. and no need to apologize.. folks should be holidaying at this time of the year after all.. |
|
@dipinhora what would you imagine the impact of this change would be on "the average" pony program? |
same as #4531 but more efficient as this enhances the previous work to better exploit the fact that the memory chunk backing a small chunk is the same size as that backing the smallest allowed large chunk along with allowing for some per-size recyclable large chunk lists trading some more memory to computation savings (if desired).. |
|
I have some worries about the "compiler used to help us, now asserts". This feels easier to break. But I am mostly ignorant about this code. It's been a long time since I worked closely with it. Do you have suggestions for tests we can do in CI to add an additional level of assurance that nothing gets broken in the future? |
note: this more closely matches how this code used to be before small_chunk_t/large_chunk_t were split for memory efficiency purposes a while back.. back then, the compiler also wasn't able to help enforce correctness but there also didn't used to be any type punning with
i'm not sure what you're looking for here.. pony already has a comprehensive test suite of pony programs ( |
|
@dipinhora I was thinking something that could point to "someone f'd up memory". I doubt there is anything but I wanted to see if asking shook something free as a thought. |
that's what the assertions are for... 8*/ |
So they can better fight for their rights..
Prior to this commit, small_chunk_t and large_chunk_t were distinct types. This was great for correctness but prevented a useful optimization.
This commit changes things so that small_chunk_t and large_chunk_t have been combined into chunk_t which has a union in it for the small/large chunk specific fields. There are now a lot of assertions added in the relevant functions that deal with small and large chunks to ensure that the received chunk is of the right type because the compiler can no longer help enforce correctness.
This allows for small and large chunk recycling to take advantage of the fact that the block backing a small chunk is the same size as the block backing the smallest large chunk size allowed so they both now use the same recycled chunk list.
The large chunk recycling has also been enhanced to take advantage of the long tail distribution of allocation sizes and there are now multiple size specific chunk lists for large chunk recycling with one extra large chunk list for recycling that has all chunks bigger than the largest size specific list that is kept sorted and searched/used as the old large chunk recycling list was.