Heavily abstracted rewerite of the zerogc API for version 0.3 #34
Conversation
This file contains 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
This is intended to be a replacement/redesign for zerogc
Simplifies size calculation. Use bumpalo for young-gen alloc
The oldgen collector is going to use a mimalloc heap for its internal allocations.
Some strange errors with invalid Layout alignment (when using miri)
These address calculations can't really be avoided :/ This reverts commit 2f0926f95db863829159608e82bf7c5f4c98adf2
Allows using AddressSanitizer
Triggers errors earlier in AddressSanitizer
Because FFI is forbidden
This causes the to pass miri (onlt with tree borrows, not stacked borrows)
This emulates bumpalo::Bump behavior and avoids a slow HashMap
Unfortunately, miri still reports leaks
This adds some extra overhead in young-gen, but not much in old
In the v0.3 API, the context crate will no longer exist and the simple crate needs to be rewritten.
The new version drops support for most features in v0.2
Will not be used with initial version of v0.3 API
Will be handled differently in v0.3 API
Doesn't delete any code right now
Reduces some features for derive macros (specifically warnings), but is not really needed for the main crate.
Very unsafe
Remove unused dependencies.
Only offered with special extension trait `MutableKeys`. Drop unused `deserialize` option for macro (GcDeserialize removed). Drop unused dependencies.
The GcHeader api allows access to an object's internal header, which contains the CollectorId. For an array, the header also contains the length. Implmentations can (and will) add extra metadata to their header like mark bits and type info. Make methods on Gc associated functions instead of methods in order to avoid conflicts with the Deref trait. This is what Arc and Box both do.
Techcable
changed the title
Currently doesn't compile
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.
I fell victim to one of the most classic programming blunders, wasting time with excessive abstraction.
Unfortunately, I don't think abstracting over multiple GC implementations is very necessary right now. It's a waste of time when I'm only planning on a single implementation.
It is true that language virtual machines are likely to have their own garbage collection implementations. However, there are better abstractions for that like mmtk.
A future version may add back in some of this abstraction, but for now the concrete implementation I have prototyped in Techcable/zerogc-next0.3 will work fine with some improvements.