A better non-recursive gc + destroy
FascinatedBox opened this issue · comments
This concerns Lily's internals, and a fair amount of the work involved is already done. I'm filing this issue more as a "hey this is something to get all excited about".
From the beginning, Lily's gc mark pass and destroy functions have been recursive. Ordinarily this isn't a problem, because values don't get too deep in typical cases.
But then there are not-typical like the binary tree demo. The binary tree demo creates very deep values and destroys them. The work I have so far (unpolished, and not including fixing the sweep, just destroy), shows that there's a performance gain to be had. Which isn't surprising: It's better to avoid jumping into several thousand functions and out repeatedly. I think taking this atypical case in mind may help make the interpreter overall perform better.
The plan I have is that every markable value will be expanded to have a prev and a next pointer. So List, Hash, Tuple, and the like are going to get a hair bigger. During a destroy pass, values can unlink themselves from the gc through some pointer adjustments. That's important, because right now value destroy does NOT use the lily state.
I'll be adjusting the VAL flags because a lot of values that are different at parse time (like Option, List, Tuple, etc.) are exactly the same at vm time.
I have this mostly done but haven't gotten around to touching it up. Punting this to 1.4 just in case the new gc/deref breaks something that the tests don't somehow notice.
Before I committed the coroutine patch, I did some more testing of this idea. I noticed that the binary trees demo runs slower after implementing it, going from being faster on Lua on my machine to being slower than Lua. It's not a huge slowdown, but enough to make me think twice about putting in this patch now.
I'd like to have this idea merged into the interpreter eventually, assuming the basic premise of iterative deletion being faster than recursive deletion is true. For the time being, I'm not interested in putting in a patch that slows the interpreter as much as this does, considering that this patch isn't pleasant to look at.
For the time being, considering that the interpreter's internals don't seem ready for this, I'm going to say no to this idea.