Sorry about reviving an oldish thread, I hadn't seen it before.
On Wed, Jul 10, 2013 at 8:32 PM, Patrick Walton pwal...@mozilla.com wrote:
For generational GC, we must ensure that objects in the nursery pointed to
by the tenured generation are either added to a remembered set or tenured.
This
Even 4K is probably too large most card tables are 128 or 256 bytes . Im
pretty sure memory protection has been tried but i cant recall the paper.
I do know Azul pauseless/concurrent collector uses the MMU but this is more
for cocurrent mark/sweep reasons. They had an issue because which pages to
/4437567/
[2] http://en.wikipedia.org/wiki/Memory_barrier
- Original Message -
From: Thad Guidry thadgui...@gmail.com
To: Niko Matsakis n...@alum.mit.edu
Cc: rust-dev@mozilla.org, Patrick Walton pwal...@mozilla.com
Sent: Thursday, July 11, 2013 9:28:27 PM
Subject: Re: [rust-dev] Incremental
No cardtable ? Most generational GCs use a write barrier to mark pages
accessed that way only objects in accessed pages need to be checked for
higher to lower generation references
http://blogs.msdn.com/b/abhinaba/archive/2009/03/02/back-to-basics-generational-garbage-collection.aspx
Java
The descriptions we've been using are quite abstract but I assume
we'll use a card table or similar abstraction. Adding to the
remembered set or borrowed set probably means, in practice,
flagging the relevant card.
Niko
On Fri, Jul 12, 2013 at 04:33:55PM +0800, Bennie Kloosteman wrote:
No
On 10/07/2013 22:04, Graydon Hoare wrote:
On 13-07-10 11:32 AM, Patrick Walton wrote:
I've been thinking about what will be needed to support incremental and
generational GC in Rust. To be clear, I don't think we should block on
it now, but we should not make it unduly difficult for us to
On 11/07/2013 13:30, Felix S. Klock II wrote:
On 10/07/2013 22:04, Graydon Hoare wrote:
I assume you've read this:
http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-91-8.pdf
This is also relevant, I think (and more recent):
Antony L. Hosking. 2006. Portable, mostly-concurrent, mostly-copying
OK, after talking with Felix and Niko (thanks!) here's a proposal.
* Whenever we borrow an `@mut` to `mut`, add it to a borrowed set for
the duration of the borrow.
* Objects in the borrowed set are grayed before each incremental GC slice.
* Objects in the borrowed set are scanned during
Some comments inline (mostly for my own clarification).
* Whenever we borrow an `@mut` to `mut`, add it to a borrowed set
for the duration of the borrow.
Presuming we adopt `Cell` in place of `@mut`, then this changes to
when borrowing a Cell as mutable, check if the cell is located within
* Objects in the borrowed set are grayed before each incremental GC slice.
*mutator*
In a
garbage-collectedhttp://www.memorymanagement.org/glossary/g.html#garbage.collection
system,
the part that executes the user code, which
allocateshttp://www.memorymanagement.org/glossary/a.html#allocate
- Original Message -
From: Niko Matsakis n...@alum.mit.edu
To: Patrick Walton pwal...@mozilla.com
Cc: rust-dev@mozilla.org
Sent: Thursday, July 11, 2013 9:12:45 PM
Subject: Re: [rust-dev] Incremental and generational GC
Some comments inline (mostly for my own clarification).
* Whenever we
Walton pwal...@mozilla.com
Cc: rust-dev@mozilla.org
Sent: Thursday, July 11, 2013 9:12:45 PM
Subject: Re: [rust-dev] Incremental and generational GC
Some comments inline (mostly for my own clarification).
* Whenever we borrow an `@mut` to `mut`, add it to a borrowed set
for the duration
Still chewing on this. Two questions below and one preliminary thought
below.
On Wed, Jul 10, 2013 at 11:32:08AM -0700, Patrick Walton wrote:
This does mean that we need to make sure that all contents of `@mut`
are Freeze; otherwise, we won't trip the barrier.
This seems stricter than
Argh. This is not the message I meant to send. I got a bit too clever
with my mail client. Anyway, here is a somewhat more full response.
This is a very good point that you raise. We have to be aware of the
impact of our decisions on garbage collection; for whatever reason, it
seems to be one of
Also, to spell out a bit of background that may not be clear, if I
understand pcwalton correctly, the problem scenario he is envisioning
is as follows. Imagine that you have a function `modify` that takes a
borrowed pointer to a cell and mutates its contents:
fn modify(x: Cell@T, y: @T) {
Hmm, on IRC strcat pointed out another option. Imagine that we pushed
all mutability into `Cell`. Then when `Cell` borrows as mut, it could
have some code like this:
if contains_managed::T() {
// contains_managed is an intrinsic test of the type T
write_barrier();
}
We
On 7/10/13 1:55 PM, Niko Matsakis wrote:
Technically, this design does not require pushing mutability into
`Cell`, but if we do that we gain the advantage that Cell is the only
one who has to worry about tripping write barriers.
That's genius. +1.
Patrick
On Wed, Jul 10, 2013 at 1:55 PM, Niko Matsakis n...@alum.mit.edu wrote:
We would have to design the write barrier code to be able to cheaply
check whether a given pointer is managed or not, but that's not a big
deal (this requirement is already present).
This may be treading into
On Wed, Jul 10, 2013 at 5:25 PM, Erick Tryzelaar
erick.tryzel...@gmail.com wrote:
On Wed, Jul 10, 2013 at 1:55 PM, Niko Matsakis n...@alum.mit.edu wrote:
We would have to design the write barrier code to be able to cheaply
check whether a given pointer is managed or not, but that's not a big
Yes
Niko
(Sent from a cramped, unreliable keyboard)
Original message
Subject: Re: [rust-dev] Incremental and generational GC
From: Erick Tryzelaar erick.tryzel...@gmail.com
To: Niko Matsakis n...@alum.mit.edu
CC: Patrick Walton pwal...@mozilla.com,rust-dev@mozilla.org
20 matches
Mail list logo
