Allocate memory from the parser in "pspace", not GC space #205
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Two major TODOs: - Resolve TODOs in gc.c - Fix the extremely sneaky memory bug hiding somewhere
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change itself does not change anything for the user -- as far as I can tell, it doesn't even have a noticeable performance or memory-use impact to speak of. It does add some code complexity, but I believe it's worth it.
The upside of this change is that it removes the major technical blocker for running es functions while fetching input -- meaning that things like programmable key bindings, completions, line-by-line history-writing (as opposed to the per-command history writing after #65), and more (see #178) are all now possible with this change.
How it works is that it defines a new memory "space" called "pspace", where any parser-related GC-like memory allocations go. Unlike normal GC space, pspace is never automatically collected, and is in fact manually collected at the end of a parse run. Live data during pspace collection (called
psealin the codebase) is copied into GC space where it begins to act like any other GC'd data. This makes "pspace" into a sort of special-purpose "nursery" like for a generational GC.The next follow-up to this will be making it possible to run more than one parser at a time, such that es code that needs to be parsed from a string before running can do so when the parser is already active. After that, the sky is the limit.