You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, SOMStack does not overwrite Vals when they are popped/truncated (instead it simply adjusts the list's length), so rboehm probably ends up keeping alive otherwise-dead objects in some cases. We could overwrite values with Val::illegal but the nicest way of doing things would be to define a custom trace function for SOMStack. CC/@jacob-hughes
[I also wonder if Vecs have the same issue?]
The text was updated successfully, but these errors were encountered:
Are there many place you use Vec? SOM doesn't have a dynamically sized data structure, I think. Except perhaps in the implementation. A quick search shows you're using it for Array
The comment about Vec isn't really very yksom related: it's more something we need to think of with rboehm and friends in general. So I'm arguably guilty of raising that aspect of the problem in the wrong repo!
I have a local branch which gets rid of the Vec in Array, but we first have to convince ourselves that #172 is a good idea.
At the moment,
SOMStack
does not overwriteVal
s when they are popped/truncated (instead it simply adjusts the list's length), so rboehm probably ends up keeping alive otherwise-dead objects in some cases. We could overwrite values withVal::illegal
but the nicest way of doing things would be to define a custom trace function forSOMStack
. CC/@jacob-hughes[I also wonder if
Vec
s have the same issue?]The text was updated successfully, but these errors were encountered: