Github/emacs
2
0
Fork 1
mirror of git://git.sv.gnu.org/emacs.git synced 2026-02-17 01:34:21 +00:00
Code Issues Projects Releases Packages Wiki Activity

Responding to review by nb <https://info.ravenbrook.com/mail/2016/03/22/17-19-03/0/>.

Browse source 
Copied from Perforce
 Change: 190349
 ServerID: perforce.ravenbrook.com
This commit is contained in:
Richard Brooksby 2016-03-23 17:31:59 +00:00
parent d161c0e4ee
commit 33b28efbdb
3 changed files with 30 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
mps/code/seg.c
View file

@ -686,7 +686,8 @@ Bool SegCheck(Seg seg)
CHECKL(AddrIsArenaGrain(TractBase(seg->firstTract), arena));
CHECKL(AddrIsArenaGrain(seg->limit, arena));
CHECKL(seg->limit > TractBase(seg->firstTract));
CHECKL(BoolCheck(seg->queued));
/* Can't BoolCheck seg->queued because compilers warn about that on
single-bit fields. */
/* Each tract of the segment must agree about white traces. Note
* that even if the CHECKs are compiled away there is still a

6
mps/code/shield.c
View file

@ -466,9 +466,7 @@ static void shieldQueue(Arena arena, Seg seg)
return;
}
/* Allocate shield queue if necessary. */
/* TODO: This will try to extend the queue on every attempt, even
if it failed last time. That might be slow. */
/* Allocate or extend the shield queue if necessary. */
if (shield->next >= shield->length) {
void *p;
Res res;
@ -509,6 +507,8 @@ static void shieldQueue(Arena arena, Seg seg)
AVER_CRITICAL(shield->limit <= shield->length);
AVER_CRITICAL(shield->next <= shield->limit);
/* If we failed to extend the shield queue array, degrade to an LRU
circular buffer. */
if (shield->next >= shield->length)
shield->next = 0;
AVER_CRITICAL(shield->next < shield->length);

25
mps/design/shield.txt
View file

@ -342,6 +342,31 @@ to suspend it again (no more calls to ``ShieldRaise`` or
``ShieldExpose`` on shielded segments).
Expose modes
............
.improv.expose-modes: Would it be a good idea for ShieldExpose() to
take an AccessSet? It might be good if we didn't have to raise a write
barrier unless we want to write. When scanning (for instance), we may
not need to write, so when scanning a segment behind a write barrier
we shouldn't have to call mprotect(). That's a bit speculative: how
often do we scan a segment and not write to it. Alternatively, and
more speculatively, we could keep the write barrier up, handle the
(possibly nested) trap and *then* expose the shield. I'm just
scraping around for ways to reduce calls to mprotect().
Theoretically we can do this, but:
1. We're mostly a moving collector so we'll almost always want to
write to segments we scan. That could change if we do more
non-moving collection.
2. The main cost of protection is changing it at all, not whether we
change just read or write. On OS X, the main cost seems to be the
TLB flush, which affects wall-clock time of everything on the
processor!
References
----------