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.

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

Read barriers #19

Open
Techcable opened this issue Jan 10, 2021 · 1 comment
Open

Read barriers #19

Techcable opened this issue Jan 10, 2021 · 1 comment
Labels
far future Wishlist items that will take a long time

Comments

@Techcable
Copy link
Member

This is needed for collectors that use concurrent marking or forwarding pointers, like Java's ZGC and Shenandoah.

I used to think this was impossible, but now I think it is not.

I think we could insert them in the deref implementation of Gc. We could guarantee the pointers are updated at least once after each safe point. Is this good enough?

TODO: Consult The GC Handbook

@Techcable Techcable added the far future Wishlist items that will take a long time label Jan 10, 2021
@Techcable Techcable changed the title [FAR FUTURE] Read barriers Read barriers Jan 10, 2021
@playXE
Copy link

playXE commented Jan 10, 2021

I've implemented concurrent copying in Rust but it was based on C4: cgc. It's object header is quite large as it has 2 words: pointer to vtable and pointer to forwarding word. Forwarding word by default points to object itself and read barrier is as simpel as this:

pub(crate) unsafe fn read_barrier_impl<T: Trace>(src_: *mut HeapInner<T>) -> *mut HeapInner<T> {
    let src = &*src_;

    // src.forward points to fromspace or to tospace.
    let r = src.forward.load(Ordering::Acquire) as *mut _;
    log::trace!("Read barrier: From {:p} to {:p}", src_, r);
    r
}

This barrier means always doing two loads but it is much better than read barriers with conditions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
far future Wishlist items that will take a long time
Projects
None yet
Development

No branches or pull requests

2 participants