Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Implement a Generational Garbage Collector #14

Open
5 tasks
Techcable opened this issue Jun 22, 2020 · 0 comments
Open
5 tasks

Implement a Generational Garbage Collector #14

Techcable opened this issue Jun 22, 2020 · 0 comments
Assignees
@Techcable
Labels
impl-generational The heavy-duty generational collector
Milestone
0.2.0

Comments

@Techcable
Copy link
Member

Implement a heavy-duty generational garbage collector. This should significantly improve performance for applications where allocations are frequent. It is intended primarily for use in language VMs and JITs (#12).

Tasks

  • Basic Implementation
  • Use card tables for efficient write barriers
  • Extremely efficent bump-pointer allocation for new generation
    • Properly relocate pointers
  • Handle "humongous objects" properly
    • Most GCs allocate very large objects (4KB+) directly into a dedicated space, bypassing the new generation
@Techcable Techcable added the impl-generational The heavy-duty generational collector label Jun 22, 2020
@Techcable Techcable added this to the 0.2.0 milestone Jun 22, 2020
@Techcable Techcable self-assigned this Jun 22, 2020
@Techcable Techcable pinned this issue Jun 22, 2020
Techcable added a commit that referenced this issue Aug 10, 2020
@Techcable
[simple] Add a "simple" single-threaded context implementation
21a5e21 
This is much simpler, because it assumes there is only one active context.
There is no need to lock because only a single active thread can use the
garbage collector at a time.

The most important outcome of this change is that it starts to seperate
the implementation of contexts from the mark/sweep collector internals.
Eventually I'd like to seperate out the context implementation for
indpendent use. Ideally it would be shared alongside the generational
collector (#14).

There is no real performance change (for the single threaded benchmark):

Standard "sync" contexts:
binary_trees 21   46.5 sec, 385 MB

New "simple" contexts:
binary_trees 21   45.4 sec, 385 MB
Techcable added a commit that referenced this issue Jan 19, 2021
@Techcable
[alloc] Start to seperate allocation logic into its own crate
58f44aa 
GC now has a seperate and customizable allocator interface.
This should allow the tracing and compacting code tight implementation
with the internals, while still maintaining some flexibility and code reuse.

This is the first step towards seperating `zerogc-simple` into
multiple different implementations. I am planning to re-use much
of this code when I implement generational gc (#14)
@Techcable Techcable mentioned this issue Jan 19, 2021
Closed
11 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Techcable Techcable

Labels
impl-generational The heavy-duty generational collector
Projects
None yet
Milestone
0.2.0
Development

No branches or pull requests
1 participant
@Techcable