[ilasm] Lazily allocate memory in Indx256 #76590
Conversation
|
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsIndx256 is a trie (or prefix tree) used to map labels to instructions. It is very space-intensive because it allocates 256-element arrays for child nodes. This is a localized fix to lazily allocate the child arrays and to split them into two 128-element arrays to handle common cases such as ildasm's output (IL_). A more aggressive change to a different data structure would save much more memory but should probably include an analysis of why a trie was originally used. Fixes #38515, #38529, #43818, and #73139. I don't think hugeExpr1 (#38515) is going to get picked up by our current testing since the ilasmroundtrip run doesn't turn off tiered compilation, but I did check its behavior on x86 locally.
|
|
/azp run runtime-coreclr ilasmroundtrip |
|
No pipelines are associated with this pull request. |
|
|
||
| // Indx256 implements a trie (or prefix tree) on null-terminated sequences of BYTEs. | ||
| // | ||
| // It is very memory intensive because it allocates dense arrays for every node |
TIHan
left a comment
TIHan
left a comment
There was a problem hiding this comment.
Changes make sense to me. Only thing left to do is run ilasmroundtrip pipeline, which, we will need to run it manually in azure devops.
|
ilasmroundtrip had one failure that matches #76280 |
|
Other failures were two builds and a non-ilasm instance of #76280. Retrying. |
ghost
locked as resolved and limited conversation to collaborators
2 participants
Indx256 is a trie (or prefix tree) used to map labels to instructions. It is very space-intensive because it allocates 256-element arrays for child nodes. This is a localized fix to lazily allocate the child arrays and to split them into two 128-element arrays to handle common cases such as ildasm's output (IL_). A more aggressive change to a different data structure would save much more memory but should probably include an analysis of why a trie was originally used.
Fixes #38515, #38529, #43818, and #73139. I don't think hugeExpr1 (#38515) is going to get picked up by our current testing since the ilasmroundtrip run doesn't turn off tiered compilation, but I did check its behavior on x86 locally.