Fcalva/cyclone
1
0
Fork 0
mirror of https://github.com/justinethier/cyclone.git synced 2025-07-08 05:27:33 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

Adding an experimental safety check

Browse source
This commit is contained in:
Justin Ethier 2015-12-08 03:02:30 -05:00
parent c4554c5af6
commit 598c981ecb
1 changed files with 19 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
gc.c
View file

@ -976,13 +976,13 @@ void gc_collector_trace()
// TODO: ideally, want to use a lock-free data structure to prevent
// having to use a mutex here. see corresponding code in gc_mark_gray
TODO: I think this locking is too coarse. observing immediate failures with the recent change to g_mark_gray locking and
wonder if the problem is that this locking will prevent a batch of changes from being seen.
you know, do we really need locking here? the last read/write can be made atomic, and any reads/writes to mark buffer can
be made atomic as well. I think we may need a dirty flag to let the collector know something is happening when the mark buffer
needs to be resized, but other than that it this good enough?
on the other hand, a central issue with this collector is when can we be sure that we are existing tracing at the right time, and
not too early? because an early exit here will surely mean that objects are incorrectly freed
//TODO: I think this locking is too coarse. observing immediate failures with the recent change to g_mark_gray locking and
//wonder if the problem is that this locking will prevent a batch of changes from being seen.
//you know, do we really need locking here? the last read/write can be made atomic, and any reads/writes to mark buffer can
//be made atomic as well. I think we may need a dirty flag to let the collector know something is happening when the mark buffer
//needs to be resized, but other than that it this good enough?
//on the other hand, a central issue with this collector is when can we be sure that we are existing tracing at the right time, and
//not too early? because an early exit here will surely mean that objects are incorrectly freed
pthread_mutex_lock(&(m->lock));
while (m->last_read < m->last_write) {
clean = 0;
@ -996,6 +996,18 @@ not too early? because an early exit here will surely mean that objects are inco
(m->last_read)++; // Inc here to prevent off-by-one error
}
pthread_mutex_unlock(&(m->lock));
// Try checking the condition once more after giving the
// mutator a chance to respond, to prevent exiting early.
// This is experimental, not sure if it is necessary
if (clean) {
pthread_mutex_lock(&(m->lock));
if (m->last_read < m->last_write) {
printf("JAE DEBUG - might have exited trace early\n");
clean = 0;
}
pthread_mutex_unlock(&(m->lock));
}
}
}
}