diff --git a/mps/.travis.yml b/mps/.travis.yml index 07a0dd66528..bc1dfd5bfb1 100644 --- a/mps/.travis.yml +++ b/mps/.travis.yml @@ -9,3 +9,5 @@ notifications: email: - mps-travis@ravenbrook.com irc: "irc.freenode.net#memorypoolsystem" +script: + - ./configure --prefix=$PWD/prefix && make install && make test diff --git a/mps/Makefile.in b/mps/Makefile.in index 396b385761b..1495a0fc313 100644 --- a/mps/Makefile.in +++ b/mps/Makefile.in @@ -37,12 +37,12 @@ install-make-build: make-install-dirs build-via-make $(INSTALL_PROGRAM) $(addprefix code/$(MPS_TARGET_NAME)/hot/,$(EXTRA_TARGETS)) $(prefix)/bin build-via-xcode: - $(XCODEBUILD) -config Release $(XCODEBUILD) -config Debug + $(XCODEBUILD) -config Release clean-xcode-build: - $(XCODEBUILD) -config Release clean $(XCODEBUILD) -config Debug clean + $(XCODEBUILD) -config Release clean install-xcode-build: make-install-dirs build-via-xcode $(INSTALL_DATA) code/mps*.h $(prefix)/include/ @@ -76,7 +76,7 @@ test-make-build: $(MAKE) -C code -f anan$(MPS_BUILD_NAME).gmk VARIETY=cool CFLAGS="-DCONFIG_POLL_NONE" clean testpoll test-xcode-build: - $(XCODEBUILD) -config Release -target testci $(XCODEBUILD) -config Debug -target testci + $(XCODEBUILD) -config Release -target testci test: @TEST_TARGET@ diff --git a/mps/code/abqtest.c b/mps/code/abqtest.c index 367bafe730b..9aad3351cb6 100644 --- a/mps/code/abqtest.c +++ b/mps/code/abqtest.c @@ -96,6 +96,7 @@ static Bool TestDeleteCallback(Bool *deleteReturn, void *element, { TestBlock *a = (TestBlock *)element; TestClosure cl = (TestClosure)closureP; + AVER(closureS == UNUSED_SIZE); UNUSED(closureS); if (*a == cl->b) { *deleteReturn = TRUE; @@ -144,7 +145,7 @@ static void step(void) cdie(b != NULL, "found to delete"); cl.b = b; cl.res = ResFAIL; - ABQIterate(&abq, TestDeleteCallback, &cl, 0); + ABQIterate(&abq, TestDeleteCallback, &cl, UNUSED_SIZE); cdie(cl.res == ResOK, "ABQIterate"); } } diff --git a/mps/code/arena.c b/mps/code/arena.c index 30f7687ce81..d270adf7499 100644 --- a/mps/code/arena.c +++ b/mps/code/arena.c @@ -19,7 +19,7 @@ SRCID(arena, "$Id$"); #define ArenaControlPool(arena) MV2Pool(&(arena)->controlPoolStruct) #define ArenaCBSBlockPool(arena) (&(arena)->freeCBSBlockPoolStruct.poolStruct) -#define ArenaFreeCBS(arena) (&(arena)->freeCBSStruct) +#define ArenaFreeLand(arena) (&(arena)->freeLandStruct.landStruct) /* Forward declarations */ @@ -153,9 +153,9 @@ Bool ArenaCheck(Arena arena) CHECKL(LocusCheck(arena)); - CHECKL(BoolCheck(arena->hasFreeCBS)); - if (arena->hasFreeCBS) - CHECKD(CBS, ArenaFreeCBS(arena)); + CHECKL(BoolCheck(arena->hasFreeLand)); + if (arena->hasFreeLand) + CHECKD(Land, ArenaFreeLand(arena)); CHECKL(BoolCheck(arena->zoned)); @@ -200,7 +200,7 @@ Res ArenaInit(Arena arena, ArenaClass class, Align alignment, ArgList args) arena->poolReady = FALSE; /* */ arena->lastTract = NULL; arena->lastTractBase = NULL; - arena->hasFreeCBS = FALSE; + arena->hasFreeLand = FALSE; arena->freeZones = ZoneSetUNIV; arena->zoned = zoned; @@ -216,14 +216,15 @@ Res ArenaInit(Arena arena, ArenaClass class, Align alignment, ArgList args) goto failGlobalsInit; arena->sig = ArenaSig; + AVERT(Arena, arena); /* Initialise a pool to hold the arena's CBS blocks. This pool can't be allowed to extend itself using ArenaAlloc because it is used during ArenaAlloc, so MFSExtendSelf is set to FALSE. Failures to extend are - handled where the CBS is used. */ + handled where the Land is used. */ MPS_ARGS_BEGIN(piArgs) { - MPS_ARGS_ADD(piArgs, MPS_KEY_MFS_UNIT_SIZE, sizeof(CBSBlockStruct)); + MPS_ARGS_ADD(piArgs, MPS_KEY_MFS_UNIT_SIZE, sizeof(CBSZonedBlockStruct)); MPS_ARGS_ADD(piArgs, MPS_KEY_EXTEND_BY, arena->alignment); MPS_ARGS_ADD(piArgs, MFSExtendSelf, FALSE); res = PoolInit(ArenaCBSBlockPool(arena), arena, PoolClassMFS(), piArgs); @@ -232,17 +233,17 @@ Res ArenaInit(Arena arena, ArenaClass class, Align alignment, ArgList args) if (res != ResOK) goto failMFSInit; - /* Initialise the freeCBS. */ - MPS_ARGS_BEGIN(cbsiArgs) { - MPS_ARGS_ADD(cbsiArgs, CBSBlockPool, ArenaCBSBlockPool(arena)); - res = CBSInit(ArenaFreeCBS(arena), arena, arena, alignment, - /* fastFind */ TRUE, arena->zoned, cbsiArgs); - } MPS_ARGS_END(cbsiArgs); + /* Initialise the freeLand. */ + MPS_ARGS_BEGIN(liArgs) { + MPS_ARGS_ADD(liArgs, CBSBlockPool, ArenaCBSBlockPool(arena)); + res = LandInit(ArenaFreeLand(arena), CBSZonedLandClassGet(), arena, + alignment, arena, liArgs); + } MPS_ARGS_END(liArgs); AVER(res == ResOK); /* no allocation, no failure expected */ if (res != ResOK) - goto failCBSInit; - /* Note that although freeCBS is initialised, it doesn't have any memory - for its blocks, so hasFreeCBS remains FALSE until later. */ + goto failLandInit; + /* Note that although freeLand is initialised, it doesn't have any memory + for its blocks, so hasFreeLand remains FALSE until later. */ /* initialize the reservoir, */ res = ReservoirInit(&arena->reservoirStruct, arena); @@ -253,8 +254,8 @@ Res ArenaInit(Arena arena, ArenaClass class, Align alignment, ArgList args) return ResOK; failReservoirInit: - CBSFinish(ArenaFreeCBS(arena)); -failCBSInit: + LandFinish(ArenaFreeLand(arena)); +failLandInit: PoolFinish(ArenaCBSBlockPool(arena)); failMFSInit: GlobalsFinish(ArenaGlobals(arena)); @@ -304,15 +305,15 @@ Res ArenaCreate(Arena *arenaReturn, ArenaClass class, ArgList args) goto failStripeSize; } - /* With the primary chunk initialised we can add page memory to the freeCBS + /* With the primary chunk initialised we can add page memory to the freeLand that describes the free address space in the primary chunk. */ - arena->hasFreeCBS = TRUE; - res = ArenaFreeCBSInsert(arena, - PageIndexBase(arena->primary, - arena->primary->allocBase), - arena->primary->limit); + arena->hasFreeLand = TRUE; + res = ArenaFreeLandInsert(arena, + PageIndexBase(arena->primary, + arena->primary->allocBase), + arena->primary->limit); if (res != ResOK) - goto failPrimaryCBS; + goto failPrimaryLand; res = ControlInit(arena); if (res != ResOK) @@ -329,7 +330,7 @@ Res ArenaCreate(Arena *arenaReturn, ArenaClass class, ArgList args) failGlobalsCompleteCreate: ControlFinish(arena); failControlInit: -failPrimaryCBS: +failPrimaryLand: failStripeSize: (*class->finish)(arena); failInit: @@ -359,6 +360,8 @@ static void arenaMFSPageFreeVisitor(Pool pool, Addr base, Size size, void *closureP, Size closureS) { AVERT(Pool, pool); + AVER(closureP == UNUSED_POINTER); + AVER(closureS == UNUSED_SIZE); UNUSED(closureP); UNUSED(closureS); UNUSED(size); @@ -378,16 +381,16 @@ void ArenaDestroy(Arena arena) arena->poolReady = FALSE; ControlFinish(arena); - /* We must tear down the freeCBS before the chunks, because pages + /* We must tear down the freeLand before the chunks, because pages containing CBS blocks might be allocated in those chunks. */ - AVER(arena->hasFreeCBS); - arena->hasFreeCBS = FALSE; - CBSFinish(ArenaFreeCBS(arena)); + AVER(arena->hasFreeLand); + arena->hasFreeLand = FALSE; + LandFinish(ArenaFreeLand(arena)); /* The CBS block pool can't free its own memory via ArenaFree because - that would use the ZonedCBS. */ - MFSFinishTracts(ArenaCBSBlockPool(arena), - arenaMFSPageFreeVisitor, NULL, 0); + that would use the freeLand. */ + MFSFinishTracts(ArenaCBSBlockPool(arena), arenaMFSPageFreeVisitor, + UNUSED_POINTER, UNUSED_SIZE); PoolFinish(ArenaCBSBlockPool(arena)); /* Call class-specific finishing. This will call ArenaFinish. */ @@ -601,9 +604,10 @@ Res ControlDescribe(Arena arena, mps_lib_FILE *stream) /* arenaAllocPage -- allocate one page from the arena * - * This is a primitive allocator used to allocate pages for the arena CBS. - * It is called rarely and can use a simple search. It may not use the - * CBS or any pool, because it is used as part of the bootstrap. + * This is a primitive allocator used to allocate pages for the arena + * Land. It is called rarely and can use a simple search. It may not + * use the Land or any pool, because it is used as part of the + * bootstrap. */ static Res arenaAllocPageInChunk(Addr *baseReturn, Chunk chunk, Pool pool) @@ -685,7 +689,7 @@ static Res arenaExtendCBSBlockPool(Range pageRangeReturn, Arena arena) return ResOK; } -/* arenaExcludePage -- exclude CBS block pool's page from CBSs +/* arenaExcludePage -- exclude CBS block pool's page from free land * * Exclude the page we specially allocated for the CBS block pool * so that it doesn't get reallocated. @@ -696,20 +700,20 @@ static void arenaExcludePage(Arena arena, Range pageRange) RangeStruct oldRange; Res res; - res = CBSDelete(&oldRange, ArenaFreeCBS(arena), pageRange); - AVER(res == ResOK); /* we just gave memory to the CBSs */ + res = LandDelete(&oldRange, ArenaFreeLand(arena), pageRange); + AVER(res == ResOK); /* we just gave memory to the Land */ } -/* arenaCBSInsert -- add a block to an arena CBS, extending pool if necessary +/* arenaLandInsert -- add range to arena's land, maybe extending block pool * - * The arena's CBSs can't get memory in the usual way because they are used - * in the basic allocator, so we allocate pages specially. + * The arena's land can't get memory in the usual way because it is + * used in the basic allocator, so we allocate pages specially. * * Only fails if it can't get a page for the block pool. */ -static Res arenaCBSInsert(Range rangeReturn, Arena arena, Range range) +static Res arenaLandInsert(Range rangeReturn, Arena arena, Range range) { Res res; @@ -717,17 +721,17 @@ static Res arenaCBSInsert(Range rangeReturn, Arena arena, Range range) AVERT(Arena, arena); AVERT(Range, range); - res = CBSInsert(rangeReturn, ArenaFreeCBS(arena), range); + res = LandInsert(rangeReturn, ArenaFreeLand(arena), range); - if (res == ResLIMIT) { /* freeCBS MFS pool ran out of blocks */ + if (res == ResLIMIT) { /* CBS block pool ran out of blocks */ RangeStruct pageRange; res = arenaExtendCBSBlockPool(&pageRange, arena); if (res != ResOK) return res; /* .insert.exclude: Must insert before exclude so that we can bootstrap when the zoned CBS is empty. */ - res = CBSInsert(rangeReturn, ArenaFreeCBS(arena), range); - AVER(res == ResOK); /* we just gave memory to the CBSs */ + res = LandInsert(rangeReturn, ArenaFreeLand(arena), range); + AVER(res == ResOK); /* we just gave memory to the CBS block pool */ arenaExcludePage(arena, &pageRange); } @@ -735,16 +739,16 @@ static Res arenaCBSInsert(Range rangeReturn, Arena arena, Range range) } -/* ArenaFreeCBSInsert -- add a block to arena CBS, maybe stealing memory +/* ArenaFreeLandInsert -- add range to arena's land, maybe stealing memory * - * See arenaCBSInsert. This function may only be applied to mapped pages - * and may steal them to store CBS nodes if it's unable to allocate - * space for CBS nodes. + * See arenaLandInsert. This function may only be applied to mapped + * pages and may steal them to store Land nodes if it's unable to + * allocate space for CBS blocks. * * IMPORTANT: May update rangeIO. */ -static void arenaCBSInsertSteal(Range rangeReturn, Arena arena, Range rangeIO) +static void arenaLandInsertSteal(Range rangeReturn, Arena arena, Range rangeIO) { Res res; @@ -752,7 +756,7 @@ static void arenaCBSInsertSteal(Range rangeReturn, Arena arena, Range rangeIO) AVERT(Arena, arena); AVERT(Range, rangeIO); - res = arenaCBSInsert(rangeReturn, arena, rangeIO); + res = arenaLandInsert(rangeReturn, arena, rangeIO); if (res != ResOK) { Addr pageBase; @@ -773,22 +777,22 @@ static void arenaCBSInsertSteal(Range rangeReturn, Arena arena, Range rangeIO) MFSExtend(ArenaCBSBlockPool(arena), pageBase, ArenaAlign(arena)); /* Try again. */ - res = CBSInsert(rangeReturn, ArenaFreeCBS(arena), rangeIO); - AVER(res == ResOK); /* we just gave memory to the CBS */ + res = LandInsert(rangeReturn, ArenaFreeLand(arena), rangeIO); + AVER(res == ResOK); /* we just gave memory to the CBS block pool */ } - AVER(res == ResOK); /* not expecting other kinds of error from the CBS */ + AVER(res == ResOK); /* not expecting other kinds of error from the Land */ } -/* ArenaFreeCBSInsert -- add block to free CBS, extending pool if necessary +/* ArenaFreeLandInsert -- add range to arena's land, maybe extending block pool * * The inserted block of address space may not abut any existing block. * This restriction ensures that we don't coalesce chunks and allocate * object across the boundary, preventing chunk deletion. */ -Res ArenaFreeCBSInsert(Arena arena, Addr base, Addr limit) +Res ArenaFreeLandInsert(Arena arena, Addr base, Addr limit) { RangeStruct range, oldRange; Res res; @@ -796,7 +800,7 @@ Res ArenaFreeCBSInsert(Arena arena, Addr base, Addr limit) AVERT(Arena, arena); RangeInit(&range, base, limit); - res = arenaCBSInsert(&oldRange, arena, &range); + res = arenaLandInsert(&oldRange, arena, &range); if (res != ResOK) return res; @@ -809,7 +813,7 @@ Res ArenaFreeCBSInsert(Arena arena, Addr base, Addr limit) } -/* ArenaFreeCBSDelete -- remove a block from free CBS, extending pool if necessary +/* ArenaFreeLandDelete -- remove range from arena's land, maybe extending block pool * * This is called from ChunkFinish in order to remove address space from * the arena. @@ -820,13 +824,13 @@ Res ArenaFreeCBSInsert(Arena arena, Addr base, Addr limit) * so we can't test that path. */ -void ArenaFreeCBSDelete(Arena arena, Addr base, Addr limit) +void ArenaFreeLandDelete(Arena arena, Addr base, Addr limit) { RangeStruct range, oldRange; Res res; RangeInit(&range, base, limit); - res = CBSDelete(&oldRange, ArenaFreeCBS(arena), &range); + res = LandDelete(&oldRange, ArenaFreeLand(arena), &range); /* Shouldn't be any other kind of failure because we were only deleting a non-coalesced block. See .chunk.no-coalesce and @@ -835,13 +839,13 @@ void ArenaFreeCBSDelete(Arena arena, Addr base, Addr limit) } -static Res arenaAllocFromCBS(Tract *tractReturn, ZoneSet zones, Bool high, +static Res arenaAllocFromLand(Tract *tractReturn, ZoneSet zones, Bool high, Size size, Pool pool) { Arena arena; RangeStruct range, oldRange; Chunk chunk; - Bool b; + Bool found, b; Index baseIndex; Count pages; Res res; @@ -858,8 +862,8 @@ static Res arenaAllocFromCBS(Tract *tractReturn, ZoneSet zones, Bool high, /* Step 1. Find a range of address space. */ - res = CBSFindInZones(&range, &oldRange, ArenaFreeCBS(arena), - size, zones, high); + res = LandFindInZones(&found, &range, &oldRange, ArenaFreeLand(arena), + size, zones, high); if (res == ResLIMIT) { /* found block, but couldn't store info */ RangeStruct pageRange; @@ -867,17 +871,17 @@ static Res arenaAllocFromCBS(Tract *tractReturn, ZoneSet zones, Bool high, if (res != ResOK) /* disastrously short on memory */ return res; arenaExcludePage(arena, &pageRange); - res = CBSFindInZones(&range, &oldRange, ArenaFreeCBS(arena), - size, zones, high); + res = LandFindInZones(&found, &range, &oldRange, ArenaFreeLand(arena), + size, zones, high); AVER(res != ResLIMIT); } - if (res == ResFAIL) /* out of address space */ - return ResRESOURCE; - AVER(res == ResOK); /* unexpected error from ZoneCBS */ if (res != ResOK) /* defensive return */ return res; + + if (!found) /* out of address space */ + return ResRESOURCE; /* Step 2. Make memory available in the address space range. */ @@ -901,7 +905,7 @@ static Res arenaAllocFromCBS(Tract *tractReturn, ZoneSet zones, Bool high, failMark: { - Res insertRes = arenaCBSInsert(&oldRange, arena, &range); + Res insertRes = arenaLandInsert(&oldRange, arena, &range); AVER(insertRes == ResOK); /* We only just deleted it. */ /* If the insert does fail, we lose some address space permanently. */ } @@ -942,10 +946,10 @@ static Res arenaAllocPolicy(Tract *tractReturn, Arena arena, SegPref pref, } } - /* Plan A: allocate from the free CBS in the requested zones */ + /* Plan A: allocate from the free Land in the requested zones */ zones = ZoneSetDiff(pref->zones, pref->avoid); if (zones != ZoneSetEMPTY) { - res = arenaAllocFromCBS(&tract, zones, pref->high, size, pool); + res = arenaAllocFromLand(&tract, zones, pref->high, size, pool); if (res == ResOK) goto found; } @@ -957,7 +961,7 @@ static Res arenaAllocPolicy(Tract *tractReturn, Arena arena, SegPref pref, See also job003384. */ moreZones = ZoneSetUnion(pref->zones, ZoneSetDiff(arena->freeZones, pref->avoid)); if (moreZones != zones) { - res = arenaAllocFromCBS(&tract, moreZones, pref->high, size, pool); + res = arenaAllocFromLand(&tract, moreZones, pref->high, size, pool); if (res == ResOK) goto found; } @@ -968,13 +972,13 @@ static Res arenaAllocPolicy(Tract *tractReturn, Arena arena, SegPref pref, if (res != ResOK) return res; if (zones != ZoneSetEMPTY) { - res = arenaAllocFromCBS(&tract, zones, pref->high, size, pool); + res = arenaAllocFromLand(&tract, zones, pref->high, size, pool); if (res == ResOK) goto found; } if (moreZones != zones) { zones = ZoneSetUnion(zones, ZoneSetDiff(arena->freeZones, pref->avoid)); - res = arenaAllocFromCBS(&tract, moreZones, pref->high, size, pool); + res = arenaAllocFromLand(&tract, moreZones, pref->high, size, pool); if (res == ResOK) goto found; } @@ -986,7 +990,7 @@ static Res arenaAllocPolicy(Tract *tractReturn, Arena arena, SegPref pref, /* TODO: log an event for this */ evenMoreZones = ZoneSetDiff(ZoneSetUNIV, pref->avoid); if (evenMoreZones != moreZones) { - res = arenaAllocFromCBS(&tract, evenMoreZones, pref->high, size, pool); + res = arenaAllocFromLand(&tract, evenMoreZones, pref->high, size, pool); if (res == ResOK) goto found; } @@ -995,7 +999,7 @@ static Res arenaAllocPolicy(Tract *tractReturn, Arena arena, SegPref pref, common ambiguous bit patterns pin them down, causing the zone check to give even more false positives permanently, and possibly retaining garbage indefinitely. */ - res = arenaAllocFromCBS(&tract, ZoneSetUNIV, pref->high, size, pool); + res = arenaAllocFromLand(&tract, ZoneSetUNIV, pref->high, size, pool); if (res == ResOK) goto found; @@ -1113,7 +1117,7 @@ void ArenaFree(Addr base, Size size, Pool pool) RangeInit(&range, base, limit); - arenaCBSInsertSteal(&oldRange, arena, &range); /* may update range */ + arenaLandInsertSteal(&oldRange, arena, &range); /* may update range */ (*arena->class->free)(RangeBase(&range), RangeSize(&range), pool); diff --git a/mps/code/cbs.c b/mps/code/cbs.c index 399f3e22ef5..6f0350d0519 100644 --- a/mps/code/cbs.c +++ b/mps/code/cbs.c @@ -26,55 +26,34 @@ SRCID(cbs, "$Id$"); #define CBSBlockSize(block) AddrOffset((block)->base, (block)->limit) +#define cbsLand(cbs) (&((cbs)->landStruct)) +#define cbsOfLand(land) PARENT(CBSStruct, landStruct, land) #define cbsSplay(cbs) (&((cbs)->splayTreeStruct)) #define cbsOfSplay(_splay) PARENT(CBSStruct, splayTreeStruct, _splay) #define cbsBlockTree(block) (&((block)->treeStruct)) #define cbsBlockOfTree(_tree) TREE_ELT(CBSBlock, treeStruct, _tree) +#define cbsFastBlockOfTree(_tree) \ + PARENT(CBSFastBlockStruct, cbsBlockStruct, cbsBlockOfTree(_tree)) +#define cbsZonedBlockOfTree(_tree) \ + PARENT(CBSZonedBlockStruct, cbsFastBlockStruct, cbsFastBlockOfTree(_tree)) #define cbsBlockKey(block) (&((block)->base)) #define cbsBlockPool(cbs) RVALUE((cbs)->blockPool) -/* cbsEnter, cbsLeave -- Avoid re-entrance - * - * .enter-leave: The callbacks are restricted in what they may call. - * These functions enforce this. - * - * .enter-leave.simple: Simple queries may be called from callbacks. - */ - -static void cbsEnter(CBS cbs) -{ - /* Don't need to check as always called from interface function. */ - AVER(!cbs->inCBS); - cbs->inCBS = TRUE; - return; -} - -static void cbsLeave(CBS cbs) -{ - /* Don't need to check as always called from interface function. */ - AVER(cbs->inCBS); - cbs->inCBS = FALSE; - return; -} - - /* CBSCheck -- Check CBS */ Bool CBSCheck(CBS cbs) { /* See .enter-leave.simple. */ + Land land; CHECKS(CBS, cbs); - CHECKL(cbs != NULL); + land = cbsLand(cbs); + CHECKD(Land, land); CHECKD(SplayTree, cbsSplay(cbs)); - /* nothing to check about treeSize */ CHECKD(Pool, cbs->blockPool); - CHECKU(Arena, cbs->arena); - CHECKL(BoolCheck(cbs->fastFind)); - CHECKL(BoolCheck(cbs->inCBS)); CHECKL(BoolCheck(cbs->ownPool)); - CHECKL(BoolCheck(cbs->zoned)); - /* No MeterCheck */ + CHECKL(SizeIsAligned(cbs->size, LandAlignment(land))); + CHECKL((cbs->size == 0) == (cbs->treeSize == 0)); return TRUE; } @@ -83,7 +62,6 @@ Bool CBSCheck(CBS cbs) ATTRIBUTE_UNUSED static Bool CBSBlockCheck(CBSBlock block) { - /* See .enter-leave.simple. */ UNUSED(block); /* Required because there is no signature */ CHECKL(block != NULL); /* Can't use CHECKD_NOSIG because TreeEMPTY is NULL. */ @@ -140,7 +118,7 @@ static Bool cbsTestNode(SplayTree splay, Tree tree, AVERT(Tree, tree); AVER(closureP == NULL); AVER(size > 0); - AVER(cbsOfSplay(splay)->fastFind); + AVER(IsLandSubclass(cbsLand(cbsOfSplay(splay)), CBSFastLandClass)); block = cbsBlockOfTree(tree); @@ -150,51 +128,45 @@ static Bool cbsTestNode(SplayTree splay, Tree tree, static Bool cbsTestTree(SplayTree splay, Tree tree, void *closureP, Size size) { - CBSBlock block; + CBSFastBlock block; AVERT(SplayTree, splay); AVERT(Tree, tree); -#if 0 AVER(closureP == NULL); AVER(size > 0); -#endif - UNUSED(closureP); - UNUSED(size); - AVER(cbsOfSplay(splay)->fastFind); + AVER(IsLandSubclass(cbsLand(cbsOfSplay(splay)), CBSFastLandClass)); - block = cbsBlockOfTree(tree); + block = cbsFastBlockOfTree(tree); return block->maxSize >= size; } -/* cbsUpdateNode -- update size info after restructuring */ +/* cbsUpdateFastNode -- update size info after restructuring */ -static void cbsUpdateNode(SplayTree splay, Tree tree) +static void cbsUpdateFastNode(SplayTree splay, Tree tree) { Size maxSize; - CBSBlock block; AVERT_CRITICAL(SplayTree, splay); AVERT_CRITICAL(Tree, tree); - AVER_CRITICAL(cbsOfSplay(splay)->fastFind); + AVER_CRITICAL(IsLandSubclass(cbsLand(cbsOfSplay(splay)), CBSFastLandClass)); - block = cbsBlockOfTree(tree); - maxSize = CBSBlockSize(block); + maxSize = CBSBlockSize(cbsBlockOfTree(tree)); if (TreeHasLeft(tree)) { - Size size = cbsBlockOfTree(TreeLeft(tree))->maxSize; + Size size = cbsFastBlockOfTree(TreeLeft(tree))->maxSize; if (size > maxSize) maxSize = size; } if (TreeHasRight(tree)) { - Size size = cbsBlockOfTree(TreeRight(tree))->maxSize; + Size size = cbsFastBlockOfTree(TreeRight(tree))->maxSize; if (size > maxSize) maxSize = size; } - block->maxSize = maxSize; + cbsFastBlockOfTree(tree)->maxSize = maxSize; } @@ -203,62 +175,57 @@ static void cbsUpdateNode(SplayTree splay, Tree tree) static void cbsUpdateZonedNode(SplayTree splay, Tree tree) { ZoneSet zones; + CBSZonedBlock zonedBlock; CBSBlock block; Arena arena; AVERT_CRITICAL(SplayTree, splay); AVERT_CRITICAL(Tree, tree); - AVER_CRITICAL(cbsOfSplay(splay)->fastFind); - AVER_CRITICAL(cbsOfSplay(splay)->zoned); + AVER_CRITICAL(IsLandSubclass(cbsLand(cbsOfSplay(splay)), CBSZonedLandClass)); - cbsUpdateNode(splay, tree); + cbsUpdateFastNode(splay, tree); - block = cbsBlockOfTree(tree); - arena = cbsOfSplay(splay)->arena; + zonedBlock = cbsZonedBlockOfTree(tree); + block = &zonedBlock->cbsFastBlockStruct.cbsBlockStruct; + arena = LandArena(cbsLand(cbsOfSplay(splay))); zones = ZoneSetOfRange(arena, CBSBlockBase(block), CBSBlockLimit(block)); if (TreeHasLeft(tree)) - zones = ZoneSetUnion(zones, cbsBlockOfTree(TreeLeft(tree))->zones); + zones = ZoneSetUnion(zones, cbsZonedBlockOfTree(TreeLeft(tree))->zones); if (TreeHasRight(tree)) - zones = ZoneSetUnion(zones, cbsBlockOfTree(TreeRight(tree))->zones); + zones = ZoneSetUnion(zones, cbsZonedBlockOfTree(TreeRight(tree))->zones); - block->zones = zones; + zonedBlock->zones = zones; } -/* CBSInit -- Initialise a CBS structure +/* cbsInit -- Initialise a CBS structure * - * See . + * See . */ ARG_DEFINE_KEY(cbs_block_pool, Pool); -Res CBSInit(CBS cbs, Arena arena, void *owner, Align alignment, - Bool fastFind, Bool zoned, ArgList args) +static Res cbsInitComm(Land land, ArgList args, SplayUpdateNodeMethod update, + Size blockStructSize) { + CBS cbs; + LandClass super; ArgStruct arg; Res res; Pool blockPool = NULL; - SplayUpdateNodeMethod update; - AVERT(Arena, arena); - AVER(cbs != NULL); - AVERT(Align, alignment); - AVERT(Bool, fastFind); - AVERT(Bool, zoned); + AVERT(Land, land); + super = LAND_SUPERCLASS(CBSLandClass); + res = (*super->init)(land, args); + if (res != ResOK) + return res; if (ArgPick(&arg, args, CBSBlockPool)) blockPool = arg.val.pool; - update = SplayTrivUpdate; - if (fastFind) - update = cbsUpdateNode; - if (zoned) { - AVER(fastFind); - update = cbsUpdateZonedNode; - } - + cbs = cbsOfLand(land); SplayTreeInit(cbsSplay(cbs), cbsCompare, cbsKey, update); if (blockPool != NULL) { @@ -266,41 +233,57 @@ Res CBSInit(CBS cbs, Arena arena, void *owner, Align alignment, cbs->ownPool = FALSE; } else { MPS_ARGS_BEGIN(pcArgs) { - MPS_ARGS_ADD(pcArgs, MPS_KEY_MFS_UNIT_SIZE, sizeof(CBSBlockStruct)); - res = PoolCreate(&cbs->blockPool, arena, PoolClassMFS(), pcArgs); + MPS_ARGS_ADD(pcArgs, MPS_KEY_MFS_UNIT_SIZE, blockStructSize); + res = PoolCreate(&cbs->blockPool, LandArena(land), PoolClassMFS(), pcArgs); } MPS_ARGS_END(pcArgs); if (res != ResOK) return res; cbs->ownPool = TRUE; } cbs->treeSize = 0; + cbs->size = 0; - cbs->arena = arena; - cbs->fastFind = fastFind; - cbs->zoned = zoned; - cbs->alignment = alignment; - cbs->inCBS = TRUE; + cbs->blockStructSize = blockStructSize; METER_INIT(cbs->treeSearch, "size of tree", (void *)cbs); cbs->sig = CBSSig; AVERT(CBS, cbs); - EVENT2(CBSInit, cbs, owner); - cbsLeave(cbs); return ResOK; } +static Res cbsInit(Land land, ArgList args) +{ + return cbsInitComm(land, args, SplayTrivUpdate, + sizeof(CBSBlockStruct)); +} -/* CBSFinish -- Finish a CBS structure +static Res cbsInitFast(Land land, ArgList args) +{ + return cbsInitComm(land, args, cbsUpdateFastNode, + sizeof(CBSFastBlockStruct)); +} + +static Res cbsInitZoned(Land land, ArgList args) +{ + return cbsInitComm(land, args, cbsUpdateZonedNode, + sizeof(CBSZonedBlockStruct)); +} + + +/* cbsFinish -- Finish a CBS structure * - * See . + * See . */ -void CBSFinish(CBS cbs) +static void cbsFinish(Land land) { + CBS cbs; + + AVERT(Land, land); + cbs = cbsOfLand(land); AVERT(CBS, cbs); - cbsEnter(cbs); METER_EMIT(&cbs->treeSearch); @@ -312,6 +295,23 @@ void CBSFinish(CBS cbs) } +/* cbsSize -- total size of ranges in CBS + * + * See . + */ + +static Size cbsSize(Land land) +{ + CBS cbs; + + AVERT(Land, land); + cbs = cbsOfLand(land); + AVERT(CBS, cbs); + + return cbs->size; +} + + /* Node change operators * * These four functions are called whenever blocks are created, @@ -322,19 +322,23 @@ void CBSFinish(CBS cbs) static void cbsBlockDelete(CBS cbs, CBSBlock block) { Bool b; + Size size; AVERT(CBS, cbs); AVERT(CBSBlock, block); + size = CBSBlockSize(block); METER_ACC(cbs->treeSearch, cbs->treeSize); b = SplayTreeDelete(cbsSplay(cbs), cbsBlockTree(block)); AVER(b); /* expect block to be in the tree */ STATISTIC(--cbs->treeSize); + AVER(cbs->size >= size); + cbs->size -= size; /* make invalid */ block->limit = block->base; - PoolFree(cbsBlockPool(cbs), (Addr)block, sizeof(CBSBlockStruct)); + PoolFree(cbsBlockPool(cbs), (Addr)block, cbs->blockStructSize); } static void cbsBlockShrunk(CBS cbs, CBSBlock block, Size oldSize) @@ -346,11 +350,10 @@ static void cbsBlockShrunk(CBS cbs, CBSBlock block, Size oldSize) newSize = CBSBlockSize(block); AVER(oldSize > newSize); + AVER(cbs->size >= oldSize - newSize); - if (cbs->fastFind) { - SplayNodeRefresh(cbsSplay(cbs), cbsBlockTree(block)); - AVER(CBSBlockSize(block) <= block->maxSize); - } + SplayNodeRefresh(cbsSplay(cbs), cbsBlockTree(block)); + cbs->size -= oldSize - newSize; } static void cbsBlockGrew(CBS cbs, CBSBlock block, Size oldSize) @@ -363,10 +366,8 @@ static void cbsBlockGrew(CBS cbs, CBSBlock block, Size oldSize) newSize = CBSBlockSize(block); AVER(oldSize < newSize); - if (cbs->fastFind) { - SplayNodeRefresh(cbsSplay(cbs), cbsBlockTree(block)); - AVER(CBSBlockSize(block) <= block->maxSize); - } + SplayNodeRefresh(cbsSplay(cbs), cbsBlockTree(block)); + cbs->size += newSize - oldSize; } /* cbsBlockAlloc -- allocate a new block and set its base and limit, @@ -382,7 +383,7 @@ static Res cbsBlockAlloc(CBSBlock *blockReturn, CBS cbs, Range range) AVERT(CBS, cbs); AVERT(Range, range); - res = PoolAlloc(&p, cbsBlockPool(cbs), sizeof(CBSBlockStruct), + res = PoolAlloc(&p, cbsBlockPool(cbs), cbs->blockStructSize, /* withReservoirPermit */ FALSE); if (res != ResOK) goto failPoolAlloc; @@ -391,7 +392,8 @@ static Res cbsBlockAlloc(CBSBlock *blockReturn, CBS cbs, Range range) TreeInit(cbsBlockTree(block)); block->base = RangeBase(range); block->limit = RangeLimit(range); - block->maxSize = CBSBlockSize(block); + + SplayNodeInit(cbsSplay(cbs), cbsBlockTree(block)); AVERT(CBSBlock, block); *blockReturn = block; @@ -415,13 +417,21 @@ static void cbsBlockInsert(CBS cbs, CBSBlock block) b = SplayTreeInsert(cbsSplay(cbs), cbsBlockTree(block)); AVER(b); STATISTIC(++cbs->treeSize); + cbs->size += CBSBlockSize(block); } -/* cbsInsertIntoTree -- Insert a range into the tree */ +/* cbsInsert -- Insert a range into the CBS + * + * See . + * + * .insert.alloc: Will only allocate a block if the range does not + * abut an existing range. + */ -static Res cbsInsertIntoTree(Range rangeReturn, CBS cbs, Range range) +static Res cbsInsert(Range rangeReturn, Land land, Range range) { + CBS cbs; Bool b; Res res; Addr base, limit, newBase, newLimit; @@ -431,10 +441,11 @@ static Res cbsInsertIntoTree(Range rangeReturn, CBS cbs, Range range) Size oldSize; AVER(rangeReturn != NULL); - AVERT(CBS, cbs); + AVERT(Land, land); AVERT(Range, range); - AVER(RangeIsAligned(range, cbs->alignment)); + AVER(RangeIsAligned(range, LandAlignment(land))); + cbs = cbsOfLand(land); base = RangeBase(range); limit = RangeLimit(range); @@ -515,46 +526,28 @@ static Res cbsInsertIntoTree(Range rangeReturn, CBS cbs, Range range) } -/* CBSInsert -- Insert a range into the CBS +/* cbsDelete -- Remove a range from a CBS * - * See . + * See . * - * .insert.alloc: Will only allocate a block if the range does not - * abut an existing range. + * .delete.alloc: Will only allocate a block if the range splits + * an existing range. */ -Res CBSInsert(Range rangeReturn, CBS cbs, Range range) -{ - Res res; - - AVERT(CBS, cbs); - cbsEnter(cbs); - - AVER(rangeReturn != NULL); - AVERT(Range, range); - AVER(RangeIsAligned(range, cbs->alignment)); - - res = cbsInsertIntoTree(rangeReturn, cbs, range); - - cbsLeave(cbs); - return res; -} - - -/* cbsDeleteFromTree -- delete blocks from the tree */ - -static Res cbsDeleteFromTree(Range rangeReturn, CBS cbs, Range range) +static Res cbsDelete(Range rangeReturn, Land land, Range range) { + CBS cbs; Res res; CBSBlock cbsBlock; Tree tree; Addr base, limit, oldBase, oldLimit; Size oldSize; + AVERT(Land, land); + cbs = cbsOfLand(land); AVER(rangeReturn != NULL); - AVERT(CBS, cbs); AVERT(Range, range); - AVER(RangeIsAligned(range, cbs->alignment)); + AVER(RangeIsAligned(range, LandAlignment(land))); base = RangeBase(range); limit = RangeLimit(range); @@ -619,32 +612,6 @@ static Res cbsDeleteFromTree(Range rangeReturn, CBS cbs, Range range) } -/* CBSDelete -- Remove a range from a CBS - * - * See . - * - * .delete.alloc: Will only allocate a block if the range splits - * an existing range. - */ - -Res CBSDelete(Range rangeReturn, CBS cbs, Range range) -{ - Res res; - - AVERT(CBS, cbs); - cbsEnter(cbs); - - AVER(rangeReturn != NULL); - AVERT(Range, range); - AVER(RangeIsAligned(range, cbs->alignment)); - - res = cbsDeleteFromTree(rangeReturn, cbs, range); - - cbsLeave(cbs); - return res; -} - - static Res cbsBlockDescribe(CBSBlock block, mps_lib_FILE *stream) { Res res; @@ -653,11 +620,9 @@ static Res cbsBlockDescribe(CBSBlock block, mps_lib_FILE *stream) return ResFAIL; res = WriteF(stream, - "[$P,$P) {$U, $B}", + "[$P,$P)", (WriteFP)block->base, (WriteFP)block->limit, - (WriteFU)block->maxSize, - (WriteFB)block->zones, NULL); return res; } @@ -675,25 +640,74 @@ static Res cbsSplayNodeDescribe(Tree tree, mps_lib_FILE *stream) return res; } +static Res cbsFastBlockDescribe(CBSFastBlock block, mps_lib_FILE *stream) +{ + Res res; -/* CBSIterate -- iterate over all blocks in CBS + if (stream == NULL) + return ResFAIL; + + res = WriteF(stream, + "[$P,$P) {$U}", + (WriteFP)block->cbsBlockStruct.base, + (WriteFP)block->cbsBlockStruct.limit, + (WriteFU)block->maxSize, + NULL); + return res; +} + +static Res cbsFastSplayNodeDescribe(Tree tree, mps_lib_FILE *stream) +{ + Res res; + + if (tree == TreeEMPTY) + return ResFAIL; + if (stream == NULL) + return ResFAIL; + + res = cbsFastBlockDescribe(cbsFastBlockOfTree(tree), stream); + return res; +} + +static Res cbsZonedBlockDescribe(CBSZonedBlock block, mps_lib_FILE *stream) +{ + Res res; + + if (stream == NULL) + return ResFAIL; + + res = WriteF(stream, + "[$P,$P) {$U, $B}", + (WriteFP)block->cbsFastBlockStruct.cbsBlockStruct.base, + (WriteFP)block->cbsFastBlockStruct.cbsBlockStruct.limit, + (WriteFU)block->cbsFastBlockStruct.maxSize, + (WriteFB)block->zones, + NULL); + return res; +} + +static Res cbsZonedSplayNodeDescribe(Tree tree, mps_lib_FILE *stream) +{ + Res res; + + if (tree == TreeEMPTY) + return ResFAIL; + if (stream == NULL) + return ResFAIL; + + res = cbsZonedBlockDescribe(cbsZonedBlockOfTree(tree), stream); + return res; +} + + +/* cbsIterate -- iterate over all blocks in CBS * - * Applies a visitor to all isolated contiguous ranges in a CBS. - * It receives a pointer, ``Size`` closure pair to pass on to the - * visitor function, and an visitor function to invoke on every range - * in address order. If the visitor returns ``FALSE``, then the iteration - * is terminated. - * - * The visitor function may not modify the CBS during the iteration. - * This is because CBSIterate uses TreeTraverse, which does not permit - * modification, for speed and to avoid perturbing the splay tree balance. - * - * See . + * See . */ typedef struct CBSIterateClosure { - CBS cbs; - CBSVisitor iterate; + Land land; + LandVisitor visitor; void *closureP; Size closureS; } CBSIterateClosure; @@ -703,26 +717,32 @@ static Bool cbsIterateVisit(Tree tree, void *closureP, Size closureS) CBSIterateClosure *closure = closureP; RangeStruct range; CBSBlock cbsBlock; - CBS cbs = closure->cbs; + Land land = closure->land; + CBS cbs = cbsOfLand(land); + Bool cont = TRUE; + AVER(closureS == UNUSED_SIZE); UNUSED(closureS); cbsBlock = cbsBlockOfTree(tree); RangeInit(&range, CBSBlockBase(cbsBlock), CBSBlockLimit(cbsBlock)); - if (!closure->iterate(cbs, &range, closure->closureP, closure->closureS)) + cont = (*closure->visitor)(land, &range, closure->closureP, closure->closureS); + if (!cont) return FALSE; METER_ACC(cbs->treeSearch, cbs->treeSize); return TRUE; } -void CBSIterate(CBS cbs, CBSVisitor visitor, - void *closureP, Size closureS) +static Bool cbsIterate(Land land, LandVisitor visitor, + void *closureP, Size closureS) { + CBS cbs; SplayTree splay; CBSIterateClosure closure; + AVERT(Land, land); + cbs = cbsOfLand(land); AVERT(CBS, cbs); - cbsEnter(cbs); AVER(FUNCHECK(visitor)); splay = cbsSplay(cbs); @@ -730,36 +750,19 @@ void CBSIterate(CBS cbs, CBSVisitor visitor, /* searches and meter it. */ METER_ACC(cbs->treeSearch, cbs->treeSize); - closure.cbs = cbs; - closure.iterate = visitor; + closure.land = land; + closure.visitor = visitor; closure.closureP = closureP; closure.closureS = closureS; - (void)TreeTraverse(SplayTreeRoot(splay), splay->compare, splay->nodeKey, - cbsIterateVisit, &closure, 0); - - cbsLeave(cbs); - return; -} - - -/* FindDeleteCheck -- check method for a FindDelete value */ - -Bool FindDeleteCheck(FindDelete findDelete) -{ - CHECKL(findDelete == FindDeleteNONE - || findDelete == FindDeleteLOW - || findDelete == FindDeleteHIGH - || findDelete == FindDeleteENTIRE); - UNUSED(findDelete); /* */ - - return TRUE; + return TreeTraverse(SplayTreeRoot(splay), splay->compare, splay->nodeKey, + cbsIterateVisit, &closure, UNUSED_SIZE); } /* cbsFindDeleteRange -- delete appropriate range of block found */ static void cbsFindDeleteRange(Range rangeReturn, Range oldRangeReturn, - CBS cbs, Range range, Size size, + Land land, Range range, Size size, FindDelete findDelete) { Bool callDelete = TRUE; @@ -767,11 +770,11 @@ static void cbsFindDeleteRange(Range rangeReturn, Range oldRangeReturn, AVER(rangeReturn != NULL); AVER(oldRangeReturn != NULL); - AVERT(CBS, cbs); + AVERT(Land, land); AVERT(Range, range); - AVER(RangeIsAligned(range, cbs->alignment)); + AVER(RangeIsAligned(range, LandAlignment(land))); AVER(size > 0); - AVER(SizeIsAligned(size, cbs->alignment)); + AVER(SizeIsAligned(size, LandAlignment(land))); AVER(RangeSize(range) >= size); AVERT(FindDelete, findDelete); @@ -805,10 +808,10 @@ static void cbsFindDeleteRange(Range rangeReturn, Range oldRangeReturn, if (callDelete) { Res res; - res = cbsDeleteFromTree(oldRangeReturn, cbs, rangeReturn); + res = cbsDelete(oldRangeReturn, land, rangeReturn); /* Can't have run out of memory, because all our callers pass in blocks that were just found in the tree, and we only - deleted from one end of the block, so cbsDeleteFromTree did not + deleted from one end of the block, so cbsDelete did not need to allocate a new block. */ AVER(res == ResOK); } else { @@ -819,20 +822,22 @@ static void cbsFindDeleteRange(Range rangeReturn, Range oldRangeReturn, /* CBSFindFirst -- find the first block of at least the given size */ -Bool CBSFindFirst(Range rangeReturn, Range oldRangeReturn, - CBS cbs, Size size, FindDelete findDelete) +static Bool cbsFindFirst(Range rangeReturn, Range oldRangeReturn, + Land land, Size size, FindDelete findDelete) { + CBS cbs; Bool found; Tree tree; + AVERT(Land, land); + cbs = cbsOfLand(land); AVERT(CBS, cbs); - cbsEnter(cbs); + AVER(IsLandSubclass(cbsLand(cbs), CBSFastLandClass)); AVER(rangeReturn != NULL); AVER(oldRangeReturn != NULL); AVER(size > 0); - AVER(SizeIsAligned(size, cbs->alignment)); - AVER(cbs->fastFind); + AVER(SizeIsAligned(size, LandAlignment(land))); AVERT(FindDelete, findDelete); METER_ACC(cbs->treeSearch, cbs->treeSize); @@ -845,16 +850,17 @@ Bool CBSFindFirst(Range rangeReturn, Range oldRangeReturn, AVER(CBSBlockSize(block) >= size); RangeInit(&range, CBSBlockBase(block), CBSBlockLimit(block)); AVER(RangeSize(&range) >= size); - cbsFindDeleteRange(rangeReturn, oldRangeReturn, cbs, &range, + cbsFindDeleteRange(rangeReturn, oldRangeReturn, land, &range, size, findDelete); } - cbsLeave(cbs); return found; } -/* CBSFindFirstInZones -- find the first block of at least the given size - that lies entirely within a zone set */ +/* cbsFindInZones -- find a block of at least the given size that lies + * entirely within a zone set. (The first such block, if high is + * FALSE, or the last, if high is TRUE.) + */ typedef struct cbsTestNodeInZonesClosureStruct { Size size; @@ -866,15 +872,15 @@ typedef struct cbsTestNodeInZonesClosureStruct { } cbsTestNodeInZonesClosureStruct, *cbsTestNodeInZonesClosure; static Bool cbsTestNodeInZones(SplayTree splay, Tree tree, - void *closureP, Size closureSize) + void *closureP, Size closureS) { CBSBlock block = cbsBlockOfTree(tree); cbsTestNodeInZonesClosure closure = closureP; RangeInZoneSet search; UNUSED(splay); - AVER(closureSize == sizeof(cbsTestNodeInZonesClosureStruct)); - UNUSED(closureSize); + AVER(closureS == UNUSED_SIZE); + UNUSED(closureS); search = closure->high ? RangeInZoneSetLast : RangeInZoneSetFirst; @@ -884,104 +890,39 @@ static Bool cbsTestNodeInZones(SplayTree splay, Tree tree, } static Bool cbsTestTreeInZones(SplayTree splay, Tree tree, - void *closureP, Size closureSize) + void *closureP, Size closureS) { - CBSBlock block = cbsBlockOfTree(tree); + CBSFastBlock fastBlock = cbsFastBlockOfTree(tree); + CBSZonedBlock zonedBlock = cbsZonedBlockOfTree(tree); cbsTestNodeInZonesClosure closure = closureP; UNUSED(splay); - AVER(closureSize == sizeof(cbsTestNodeInZonesClosureStruct)); - UNUSED(closureSize); + AVER(closureS == UNUSED_SIZE); + UNUSED(closureS); - return block->maxSize >= closure->size && - ZoneSetInter(block->zones, closure->zoneSet) != ZoneSetEMPTY; -} - -Res CBSFindInZones(Range rangeReturn, Range oldRangeReturn, - CBS cbs, Size size, - ZoneSet zoneSet, Bool high) -{ - Tree tree; - cbsTestNodeInZonesClosureStruct closure; - Res res; - CBSFindMethod cbsFind; - SplayFindMethod splayFind; - - AVER(rangeReturn != NULL); - AVER(oldRangeReturn != NULL); - AVERT(CBS, cbs); - /* AVERT(ZoneSet, zoneSet); */ - AVERT(Bool, high); - - cbsFind = high ? CBSFindLast : CBSFindFirst; - splayFind = high ? SplayFindLast : SplayFindFirst; - - if (zoneSet == ZoneSetEMPTY) - return ResFAIL; - if (zoneSet == ZoneSetUNIV) { - FindDelete fd = high ? FindDeleteHIGH : FindDeleteLOW; - if (cbsFind(rangeReturn, oldRangeReturn, cbs, size, fd)) - return ResOK; - else - return ResFAIL; - } - if (ZoneSetIsSingle(zoneSet) && size > ArenaStripeSize(cbs->arena)) - return ResFAIL; - - /* It would be nice if there were a neat way to eliminate all runs of - zones in zoneSet too small for size.*/ - - cbsEnter(cbs); - - closure.arena = cbs->arena; - closure.zoneSet = zoneSet; - closure.size = size; - closure.high = high; - if (splayFind(&tree, cbsSplay(cbs), - cbsTestNodeInZones, - cbsTestTreeInZones, - &closure, sizeof(closure))) { - CBSBlock block = cbsBlockOfTree(tree); - RangeStruct rangeStruct, oldRangeStruct; - - AVER(CBSBlockBase(block) <= closure.base); - AVER(AddrOffset(closure.base, closure.limit) >= size); - AVER(ZoneSetSub(ZoneSetOfRange(cbs->arena, closure.base, closure.limit), zoneSet)); - AVER(closure.limit <= CBSBlockLimit(block)); - - if (!high) - RangeInit(&rangeStruct, closure.base, AddrAdd(closure.base, size)); - else - RangeInit(&rangeStruct, AddrSub(closure.limit, size), closure.limit); - res = cbsDeleteFromTree(&oldRangeStruct, cbs, &rangeStruct); - if (res == ResOK) { /* enough memory to split block */ - RangeCopy(rangeReturn, &rangeStruct); - RangeCopy(oldRangeReturn, &oldRangeStruct); - } - } else - res = ResFAIL; - - cbsLeave(cbs); - return res; + return fastBlock->maxSize >= closure->size + && ZoneSetInter(zonedBlock->zones, closure->zoneSet) != ZoneSetEMPTY; } -/* CBSFindLast -- find the last block of at least the given size */ +/* cbsFindLast -- find the last block of at least the given size */ -Bool CBSFindLast(Range rangeReturn, Range oldRangeReturn, - CBS cbs, Size size, FindDelete findDelete) +static Bool cbsFindLast(Range rangeReturn, Range oldRangeReturn, + Land land, Size size, FindDelete findDelete) { + CBS cbs; Bool found; Tree tree; + AVERT(Land, land); + cbs = cbsOfLand(land); AVERT(CBS, cbs); - cbsEnter(cbs); + AVER(IsLandSubclass(cbsLand(cbs), CBSFastLandClass)); AVER(rangeReturn != NULL); AVER(oldRangeReturn != NULL); AVER(size > 0); - AVER(SizeIsAligned(size, cbs->alignment)); - AVER(cbs->fastFind); + AVER(SizeIsAligned(size, LandAlignment(land))); AVERT(FindDelete, findDelete); METER_ACC(cbs->treeSearch, cbs->treeSize); @@ -994,39 +935,40 @@ Bool CBSFindLast(Range rangeReturn, Range oldRangeReturn, AVER(CBSBlockSize(block) >= size); RangeInit(&range, CBSBlockBase(block), CBSBlockLimit(block)); AVER(RangeSize(&range) >= size); - cbsFindDeleteRange(rangeReturn, oldRangeReturn, cbs, &range, + cbsFindDeleteRange(rangeReturn, oldRangeReturn, land, &range, size, findDelete); } - cbsLeave(cbs); return found; } -/* CBSFindLargest -- find the largest block in the CBS */ +/* cbsFindLargest -- find the largest block in the CBS */ -Bool CBSFindLargest(Range rangeReturn, Range oldRangeReturn, - CBS cbs, Size size, FindDelete findDelete) +static Bool cbsFindLargest(Range rangeReturn, Range oldRangeReturn, + Land land, Size size, FindDelete findDelete) { + CBS cbs; Bool found = FALSE; + AVERT(Land, land); + cbs = cbsOfLand(land); AVERT(CBS, cbs); - cbsEnter(cbs); + AVER(IsLandSubclass(cbsLand(cbs), CBSFastLandClass)); AVER(rangeReturn != NULL); AVER(oldRangeReturn != NULL); - AVER(cbs->fastFind); AVER(size > 0); AVERT(FindDelete, findDelete); if (!SplayTreeIsEmpty(cbsSplay(cbs))) { RangeStruct range; - CBSBlock block; Tree tree = TreeEMPTY; /* suppress "may be used uninitialized" */ Size maxSize; - maxSize = cbsBlockOfTree(SplayTreeRoot(cbsSplay(cbs)))->maxSize; + maxSize = cbsFastBlockOfTree(SplayTreeRoot(cbsSplay(cbs)))->maxSize; if (maxSize >= size) { + CBSBlock block; METER_ACC(cbs->treeSearch, cbs->treeSize); found = SplayFindFirst(&tree, cbsSplay(cbs), &cbsTestNode, &cbsTestTree, NULL, maxSize); @@ -1035,25 +977,103 @@ Bool CBSFindLargest(Range rangeReturn, Range oldRangeReturn, AVER(CBSBlockSize(block) >= maxSize); RangeInit(&range, CBSBlockBase(block), CBSBlockLimit(block)); AVER(RangeSize(&range) >= maxSize); - cbsFindDeleteRange(rangeReturn, oldRangeReturn, cbs, &range, + cbsFindDeleteRange(rangeReturn, oldRangeReturn, land, &range, size, findDelete); } } - cbsLeave(cbs); return found; } -/* CBSDescribe -- describe a CBS +static Res cbsFindInZones(Bool *foundReturn, Range rangeReturn, + Range oldRangeReturn, Land land, Size size, + ZoneSet zoneSet, Bool high) +{ + CBS cbs; + CBSBlock block; + Tree tree; + cbsTestNodeInZonesClosureStruct closure; + Res res; + LandFindMethod landFind; + SplayFindMethod splayFind; + RangeStruct rangeStruct, oldRangeStruct; + + AVER(foundReturn != NULL); + AVER(rangeReturn != NULL); + AVER(oldRangeReturn != NULL); + AVERT(Land, land); + cbs = cbsOfLand(land); + AVERT(CBS, cbs); + AVER(IsLandSubclass(cbsLand(cbs), CBSZonedLandClass)); + /* AVERT(ZoneSet, zoneSet); */ + AVER(BoolCheck(high)); + + landFind = high ? cbsFindLast : cbsFindFirst; + splayFind = high ? SplayFindLast : SplayFindFirst; + + if (zoneSet == ZoneSetEMPTY) + goto fail; + if (zoneSet == ZoneSetUNIV) { + FindDelete fd = high ? FindDeleteHIGH : FindDeleteLOW; + *foundReturn = (*landFind)(rangeReturn, oldRangeReturn, land, size, fd); + return ResOK; + } + if (ZoneSetIsSingle(zoneSet) && size > ArenaStripeSize(LandArena(land))) + goto fail; + + /* It would be nice if there were a neat way to eliminate all runs of + zones in zoneSet too small for size.*/ + + closure.arena = LandArena(land); + closure.zoneSet = zoneSet; + closure.size = size; + closure.high = high; + if (!(*splayFind)(&tree, cbsSplay(cbs), + cbsTestNodeInZones, cbsTestTreeInZones, + &closure, UNUSED_SIZE)) + goto fail; + + block = cbsBlockOfTree(tree); + + AVER(CBSBlockBase(block) <= closure.base); + AVER(AddrOffset(closure.base, closure.limit) >= size); + AVER(ZoneSetSub(ZoneSetOfRange(LandArena(land), closure.base, closure.limit), zoneSet)); + AVER(closure.limit <= CBSBlockLimit(block)); + + if (!high) + RangeInit(&rangeStruct, closure.base, AddrAdd(closure.base, size)); + else + RangeInit(&rangeStruct, AddrSub(closure.limit, size), closure.limit); + res = cbsDelete(&oldRangeStruct, land, &rangeStruct); + if (res != ResOK) + /* not enough memory to split block */ + return res; + RangeCopy(rangeReturn, &rangeStruct); + RangeCopy(oldRangeReturn, &oldRangeStruct); + *foundReturn = TRUE; + return ResOK; + +fail: + *foundReturn = FALSE; + return ResOK; +} + + +/* cbsDescribe -- describe a CBS * - * See . + * See . */ -Res CBSDescribe(CBS cbs, mps_lib_FILE *stream) +static Res cbsDescribe(Land land, mps_lib_FILE *stream) { + CBS cbs; Res res; + Res (*describe)(Tree, mps_lib_FILE *); + if (!TESTT(Land, land)) + return ResFAIL; + cbs = cbsOfLand(land); if (!TESTT(CBS, cbs)) return ResFAIL; if (stream == NULL) @@ -1061,15 +1081,20 @@ Res CBSDescribe(CBS cbs, mps_lib_FILE *stream) res = WriteF(stream, "CBS $P {\n", (WriteFP)cbs, - " alignment: $U\n", (WriteFU)cbs->alignment, " blockPool: $P\n", (WriteFP)cbsBlockPool(cbs), - " fastFind: $U\n", (WriteFU)cbs->fastFind, - " inCBS: $U\n", (WriteFU)cbs->inCBS, + " ownPool: $U\n", (WriteFU)cbs->ownPool, " treeSize: $U\n", (WriteFU)cbs->treeSize, NULL); if (res != ResOK) return res; - res = SplayTreeDescribe(cbsSplay(cbs), stream, &cbsSplayNodeDescribe); + if (IsLandSubclass(land, CBSZonedLandClass)) + describe = cbsZonedSplayNodeDescribe; + else if (IsLandSubclass(land, CBSFastLandClass)) + describe = cbsFastSplayNodeDescribe; + else + describe = cbsSplayNodeDescribe; + + res = SplayTreeDescribe(cbsSplay(cbs), stream, describe); if (res != ResOK) return res; METER_WRITE(cbs->treeSearch, stream); @@ -1078,6 +1103,41 @@ Res CBSDescribe(CBS cbs, mps_lib_FILE *stream) return res; } +DEFINE_LAND_CLASS(CBSLandClass, class) +{ + INHERIT_CLASS(class, LandClass); + class->name = "CBS"; + class->size = sizeof(CBSStruct); + class->init = cbsInit; + class->finish = cbsFinish; + class->sizeMethod = cbsSize; + class->insert = cbsInsert; + class->delete = cbsDelete; + class->iterate = cbsIterate; + class->findFirst = cbsFindFirst; + class->findLast = cbsFindLast; + class->findLargest = cbsFindLargest; + class->findInZones = cbsFindInZones; + class->describe = cbsDescribe; + AVERT(LandClass, class); +} + +DEFINE_LAND_CLASS(CBSFastLandClass, class) +{ + INHERIT_CLASS(class, CBSLandClass); + class->name = "FASTCBS"; + class->init = cbsInitFast; + AVERT(LandClass, class); +} + +DEFINE_LAND_CLASS(CBSZonedLandClass, class) +{ + INHERIT_CLASS(class, CBSFastLandClass); + class->name = "ZONEDCBS"; + class->init = cbsInitZoned; + AVERT(LandClass, class); +} + /* C. COPYRIGHT AND LICENSE * diff --git a/mps/code/cbs.h b/mps/code/cbs.h index e425bd80cf8..e6bc276f067 100644 --- a/mps/code/cbs.h +++ b/mps/code/cbs.h @@ -15,55 +15,37 @@ #include "range.h" #include "splay.h" - -/* TODO: There ought to be different levels of CBS block with inheritance - so that CBSs without fastFind don't allocate the maxSize and zones fields, - and CBSs without zoned don't allocate the zones field. */ - typedef struct CBSBlockStruct *CBSBlock; typedef struct CBSBlockStruct { TreeStruct treeStruct; Addr base; Addr limit; - Size maxSize; /* accurate maximum block size of sub-tree */ - ZoneSet zones; /* union zone set of all ranges in sub-tree */ } CBSBlockStruct; +typedef struct CBSFastBlockStruct *CBSFastBlock; +typedef struct CBSFastBlockStruct { + struct CBSBlockStruct cbsBlockStruct; + Size maxSize; /* accurate maximum block size of sub-tree */ +} CBSFastBlockStruct; + +typedef struct CBSZonedBlockStruct *CBSZonedBlock; +typedef struct CBSZonedBlockStruct { + struct CBSFastBlockStruct cbsFastBlockStruct; + ZoneSet zones; /* union zone set of all ranges in sub-tree */ +} CBSZonedBlockStruct; typedef struct CBSStruct *CBS; -typedef Bool (*CBSVisitor)(CBS cbs, Range range, - void *closureP, Size closureS); extern Bool CBSCheck(CBS cbs); +extern LandClass CBSLandClassGet(void); +extern LandClass CBSFastLandClassGet(void); +extern LandClass CBSZonedLandClassGet(void); + extern const struct mps_key_s _mps_key_cbs_block_pool; #define CBSBlockPool (&_mps_key_cbs_block_pool) #define CBSBlockPool_FIELD pool -/* TODO: Passing booleans to affect behaviour is ugly and error-prone. */ -extern Res CBSInit(CBS cbs, Arena arena, void *owner, Align alignment, - Bool fastFind, Bool zoned, ArgList args); -extern void CBSFinish(CBS cbs); - -extern Res CBSInsert(Range rangeReturn, CBS cbs, Range range); -extern Res CBSDelete(Range rangeReturn, CBS cbs, Range range); -extern void CBSIterate(CBS cbs, CBSVisitor visitor, - void *closureP, Size closureS); - -extern Res CBSDescribe(CBS cbs, mps_lib_FILE *stream); - -typedef Bool (*CBSFindMethod)(Range rangeReturn, Range oldRangeReturn, - CBS cbs, Size size, FindDelete findDelete); -extern Bool CBSFindFirst(Range rangeReturn, Range oldRangeReturn, - CBS cbs, Size size, FindDelete findDelete); -extern Bool CBSFindLast(Range rangeReturn, Range oldRangeReturn, - CBS cbs, Size size, FindDelete findDelete); -extern Bool CBSFindLargest(Range rangeReturn, Range oldRangeReturn, - CBS cbs, Size size, FindDelete findDelete); - -extern Res CBSFindInZones(Range rangeReturn, Range oldRangeReturn, - CBS cbs, Size size, ZoneSet zoneSet, Bool high); - #endif /* cbs_h */ diff --git a/mps/code/comm.gmk b/mps/code/comm.gmk index af5718c6caf..6e5adce14f5 100644 --- a/mps/code/comm.gmk +++ b/mps/code/comm.gmk @@ -163,12 +163,54 @@ FMTDYTST = fmtdy.c fmtno.c fmtdytst.c FMTHETST = fmthe.c fmtdy.c fmtno.c fmtdytst.c FMTSCM = fmtscheme.c PLINTH = mpsliban.c mpsioan.c -MPMCOMMON = abq.c arena.c arenacl.c arenavm.c arg.c boot.c bt.c \ - buffer.c cbs.c dbgpool.c dbgpooli.c event.c format.c freelist.c \ - global.c ld.c locus.c message.c meter.c mpm.c mpsi.c nailboard.c \ - pool.c poolabs.c poolmfs.c poolmrg.c poolmv.c protocol.c range.c \ - ref.c reserv.c ring.c root.c sa.c sac.c seg.c shield.c splay.c ss.c \ - table.c trace.c traceanc.c tract.c tree.c walk.c +MPMCOMMON = \ + abq.c \ + arena.c \ + arenacl.c \ + arenavm.c \ + arg.c \ + boot.c \ + bt.c \ + buffer.c \ + cbs.c \ + dbgpool.c \ + dbgpooli.c \ + event.c \ + failover.c \ + format.c \ + freelist.c \ + global.c \ + land.c \ + ld.c \ + locus.c \ + message.c \ + meter.c \ + mpm.c \ + mpsi.c \ + nailboard.c \ + pool.c \ + poolabs.c \ + poolmfs.c \ + poolmrg.c \ + poolmv.c \ + protocol.c \ + range.c \ + ref.c \ + reserv.c \ + ring.c \ + root.c \ + sa.c \ + sac.c \ + seg.c \ + shield.c \ + splay.c \ + ss.c \ + table.c \ + trace.c \ + traceanc.c \ + tract.c \ + tree.c \ + walk.c MPM = $(MPMCOMMON) $(MPMPF) $(AMC) $(AMS) $(AWL) $(LO) $(MV2) $(MVFF) $(PLINTH) @@ -221,11 +263,11 @@ TEST_TARGETS=\ djbench \ exposet0 \ expt825 \ - fbmtest \ finalcv \ finaltest \ fotest \ gcbench \ + landtest \ locbwcss \ lockcov \ lockut \ @@ -292,17 +334,25 @@ clean: phony $(ECHO) "$(PFM): $@" rm -rf "$(PFM)" -# "target" builds some varieties of the target named in the TARGET macro. +# "target" builds some varieties of the target named in the TARGET +# macro. +# # %%VARIETY: When adding a new target, optionally add a recursive make call # for the new variety, if it should be built by default. It probably # shouldn't without a product design decision and an update of the readme # and build manual! +# +# Note that we build VARIETY=cool before VARIETY=hot because +# the former doesn't need to optimize and so detects errors more +# quickly; and because the former uses file-at-a-time compilation and +# so can pick up where it left off instead of having to start from the +# beginning of mps.c ifdef TARGET ifndef VARIETY target: phony - $(MAKE) -f $(PFM).gmk VARIETY=hot variety $(MAKE) -f $(PFM).gmk VARIETY=cool variety + $(MAKE) -f $(PFM).gmk VARIETY=hot variety endif endif @@ -403,9 +453,6 @@ $(PFM)/$(VARIETY)/exposet0: $(PFM)/$(VARIETY)/exposet0.o \ $(PFM)/$(VARIETY)/expt825: $(PFM)/$(VARIETY)/expt825.o \ $(FMTDYTSTOBJ) $(TESTLIBOBJ) $(PFM)/$(VARIETY)/mps.a -$(PFM)/$(VARIETY)/fbmtest: $(PFM)/$(VARIETY)/fbmtest.o \ - $(TESTLIBOBJ) $(PFM)/$(VARIETY)/mps.a - $(PFM)/$(VARIETY)/finalcv: $(PFM)/$(VARIETY)/finalcv.o \ $(FMTDYTSTOBJ) $(TESTLIBOBJ) $(PFM)/$(VARIETY)/mps.a @@ -418,6 +465,9 @@ $(PFM)/$(VARIETY)/fotest: $(PFM)/$(VARIETY)/fotest.o \ $(PFM)/$(VARIETY)/gcbench: $(PFM)/$(VARIETY)/gcbench.o \ $(FMTDYTSTOBJ) $(TESTLIBOBJ) $(TESTTHROBJ) +$(PFM)/$(VARIETY)/landtest: $(PFM)/$(VARIETY)/landtest.o \ + $(TESTLIBOBJ) $(PFM)/$(VARIETY)/mps.a + $(PFM)/$(VARIETY)/locbwcss: $(PFM)/$(VARIETY)/locbwcss.o \ $(TESTLIBOBJ) $(PFM)/$(VARIETY)/mps.a diff --git a/mps/code/commpost.nmk b/mps/code/commpost.nmk index c4e7d8d7f1a..40beeb7fc58 100644 --- a/mps/code/commpost.nmk +++ b/mps/code/commpost.nmk @@ -39,8 +39,8 @@ clean: !IFDEF TARGET !IFNDEF VARIETY target: - $(MAKE) /nologo /f $(PFM).nmk VARIETY=hot variety $(MAKE) /nologo /f $(PFM).nmk VARIETY=cool variety + $(MAKE) /nologo /f $(PFM).nmk VARIETY=hot variety !ENDIF !ENDIF @@ -60,8 +60,8 @@ testrun testci testall testansi testpoll: $(TEST_TARGETS) !IFDEF VARIETY ..\tool\testrun.bat $(PFM) $(VARIETY) $@ !ELSE - $(MAKE) /nologo /f $(PFM).nmk VARIETY=hot $@ $(MAKE) /nologo /f $(PFM).nmk VARIETY=cool $@ + $(MAKE) /nologo /f $(PFM).nmk VARIETY=hot $@ !ENDIF @@ -165,9 +165,6 @@ $(PFM)\$(VARIETY)\exposet0.exe: $(PFM)\$(VARIETY)\exposet0.obj \ $(PFM)\$(VARIETY)\expt825.exe: $(PFM)\$(VARIETY)\expt825.obj \ $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) -$(PFM)\$(VARIETY)\fbmtest.exe: $(PFM)\$(VARIETY)\fbmtest.obj \ - $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) - $(PFM)\$(VARIETY)\finalcv.exe: $(PFM)\$(VARIETY)\finalcv.obj \ $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) @@ -180,6 +177,9 @@ $(PFM)\$(VARIETY)\fotest.exe: $(PFM)\$(VARIETY)\fotest.obj \ $(PFM)\$(VARIETY)\gcbench.exe: $(PFM)\$(VARIETY)\gcbench.obj \ $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) $(TESTTHROBJ) +$(PFM)\$(VARIETY)\landtest.exe: $(PFM)\$(VARIETY)\landtest.obj \ + $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) + $(PFM)\$(VARIETY)\locbwcss.exe: $(PFM)\$(VARIETY)\locbwcss.obj \ $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) diff --git a/mps/code/commpre.nmk b/mps/code/commpre.nmk index 7aa82b4eb79..dbb20936fea 100644 --- a/mps/code/commpre.nmk +++ b/mps/code/commpre.nmk @@ -72,11 +72,11 @@ TEST_TARGETS=\ djbench.exe \ exposet0.exe \ expt825.exe \ - fbmtest.exe \ finalcv.exe \ finaltest.exe \ fotest.exe \ gcbench.exe \ + landtest.exe \ locbwcss.exe \ lockcov.exe \ lockut.exe \ @@ -131,9 +131,11 @@ MPMCOMMON=\ \ \ \ + \ \ \ \ + \ \ \ \ diff --git a/mps/code/config.h b/mps/code/config.h index 081b3ffaeeb..e4db1be6423 100644 --- a/mps/code/config.h +++ b/mps/code/config.h @@ -292,6 +292,11 @@ /* Attribute for functions that may be unused in some build configurations. * GCC: + * + * This attribute must be applied to all Check functions, otherwise + * the RASH variety fails to compile with -Wunused-function. (It + * should not be applied to functions that are unused in all build + * configurations: these functions should not be compiled.) */ #if defined(MPS_BUILD_GC) || defined(MPS_BUILD_LL) #define ATTRIBUTE_UNUSED __attribute__((__unused__)) diff --git a/mps/code/eventdef.h b/mps/code/eventdef.h index d47e434b868..0c94da20cf4 100644 --- a/mps/code/eventdef.h +++ b/mps/code/eventdef.h @@ -95,7 +95,7 @@ EVENT(X, PoolFinish , 0x0016, TRUE, Pool) \ EVENT(X, PoolAlloc , 0x0017, TRUE, Object) \ EVENT(X, PoolFree , 0x0018, TRUE, Object) \ - EVENT(X, CBSInit , 0x0019, TRUE, Pool) \ + EVENT(X, LandInit , 0x0019, TRUE, Pool) \ EVENT(X, Intern , 0x001a, TRUE, User) \ EVENT(X, Label , 0x001b, TRUE, User) \ EVENT(X, TraceStart , 0x001c, TRUE, Trace) \ @@ -311,8 +311,8 @@ PARAM(X, 1, A, old) \ PARAM(X, 2, W, size) -#define EVENT_CBSInit_PARAMS(PARAM, X) \ - PARAM(X, 0, P, cbs) \ +#define EVENT_LandInit_PARAMS(PARAM, X) \ + PARAM(X, 0, P, land) \ PARAM(X, 1, P, owner) #define EVENT_Intern_PARAMS(PARAM, X) \ diff --git a/mps/code/failover.c b/mps/code/failover.c new file mode 100644 index 00000000000..7e9f07d7b8c --- /dev/null +++ b/mps/code/failover.c @@ -0,0 +1,360 @@ +/* failover.c: FAILOVER IMPLEMENTATION + * + * $Id$ + * Copyright (c) 2014 Ravenbrook Limited. See end of file for license. + * + * .design: + */ + +#include "failover.h" +#include "mpm.h" +#include "range.h" + +SRCID(failover, "$Id$"); + + +#define failoverOfLand(land) PARENT(FailoverStruct, landStruct, land) + + +ARG_DEFINE_KEY(failover_primary, Pointer); +ARG_DEFINE_KEY(failover_secondary, Pointer); + + +Bool FailoverCheck(Failover fo) +{ + CHECKS(Failover, fo); + CHECKD(Land, &fo->landStruct); + CHECKD(Land, fo->primary); + CHECKD(Land, fo->secondary); + return TRUE; +} + + +static Res failoverInit(Land land, ArgList args) +{ + Failover fo; + LandClass super; + Land primary, secondary; + ArgStruct arg; + Res res; + + AVERT(Land, land); + super = LAND_SUPERCLASS(FailoverLandClass); + res = (*super->init)(land, args); + if (res != ResOK) + return res; + + ArgRequire(&arg, args, FailoverPrimary); + primary = arg.val.p; + ArgRequire(&arg, args, FailoverSecondary); + secondary = arg.val.p; + + fo = failoverOfLand(land); + fo->primary = primary; + fo->secondary = secondary; + fo->sig = FailoverSig; + AVERT(Failover, fo); + return ResOK; +} + + +static void failoverFinish(Land land) +{ + Failover fo; + + AVERT(Land, land); + fo = failoverOfLand(land); + AVERT(Failover, fo); + + fo->sig = SigInvalid; +} + + +static Size failoverSize(Land land) +{ + Failover fo; + + AVERT(Land, land); + fo = failoverOfLand(land); + AVERT(Failover, fo); + + return LandSize(fo->primary) + LandSize(fo->secondary); +} + + +static Res failoverInsert(Range rangeReturn, Land land, Range range) +{ + Failover fo; + Res res; + + AVER(rangeReturn != NULL); + AVERT(Land, land); + fo = failoverOfLand(land); + AVERT(Failover, fo); + AVERT(Range, range); + + /* Provide more opportunities for coalescence. See + * . + */ + (void)LandFlush(fo->primary, fo->secondary); + + res = LandInsert(rangeReturn, fo->primary, range); + if (res != ResOK && res != ResFAIL) + res = LandInsert(rangeReturn, fo->secondary, range); + + return res; +} + + +static Res failoverDelete(Range rangeReturn, Land land, Range range) +{ + Failover fo; + Res res; + RangeStruct oldRange, dummyRange, left, right; + + AVER(rangeReturn != NULL); + AVERT(Land, land); + fo = failoverOfLand(land); + AVERT(Failover, fo); + AVERT(Range, range); + + /* Prefer efficient search in the primary. See + * . + */ + (void)LandFlush(fo->primary, fo->secondary); + + res = LandDelete(&oldRange, fo->primary, range); + + if (res == ResFAIL) { + /* Range not found in primary: try secondary. */ + return LandDelete(rangeReturn, fo->secondary, range); + } else if (res != ResOK) { + /* Range was found in primary, but couldn't be deleted. The only + * case we expect to encounter here is the case where the primary + * is out of memory. (In particular, we don't handle the case of a + * CBS returning ResLIMIT because its block pool has been + * configured not to automatically extend itself.) + */ + AVER(ResIsAllocFailure(res)); + + /* Delete the whole of oldRange, and re-insert the fragments + * (which might end up in the secondary). See + * . + */ + res = LandDelete(&dummyRange, fo->primary, &oldRange); + if (res != ResOK) + return res; + + AVER(RangesEqual(&oldRange, &dummyRange)); + RangeInit(&left, RangeBase(&oldRange), RangeBase(range)); + if (!RangeIsEmpty(&left)) { + /* Don't call LandInsert(..., land, ...) here: that would be + * re-entrant and fail the landEnter check. */ + res = LandInsert(&dummyRange, fo->primary, &left); + if (res != ResOK) { + /* The range was successful deleted from the primary above. */ + AVER(res != ResFAIL); + res = LandInsert(&dummyRange, fo->secondary, &left); + AVER(res == ResOK); + } + } + RangeInit(&right, RangeLimit(range), RangeLimit(&oldRange)); + if (!RangeIsEmpty(&right)) { + res = LandInsert(&dummyRange, fo->primary, &right); + if (res != ResOK) { + /* The range was successful deleted from the primary above. */ + AVER(res != ResFAIL); + res = LandInsert(&dummyRange, fo->secondary, &right); + AVER(res == ResOK); + } + } + } + if (res == ResOK) { + AVER(RangesNest(&oldRange, range)); + RangeCopy(rangeReturn, &oldRange); + } + return res; +} + + +static Bool failoverIterate(Land land, LandVisitor visitor, void *closureP, Size closureS) +{ + Failover fo; + + AVERT(Land, land); + fo = failoverOfLand(land); + AVERT(Failover, fo); + AVER(visitor != NULL); + + return LandIterate(fo->primary, visitor, closureP, closureS) + && LandIterate(fo->secondary, visitor, closureP, closureS); +} + + +static Bool failoverFindFirst(Range rangeReturn, Range oldRangeReturn, Land land, Size size, FindDelete findDelete) +{ + Failover fo; + + AVER(rangeReturn != NULL); + AVER(oldRangeReturn != NULL); + AVERT(Land, land); + fo = failoverOfLand(land); + AVERT(Failover, fo); + AVERT(FindDelete, findDelete); + + /* See . */ + (void)LandFlush(fo->primary, fo->secondary); + + return LandFindFirst(rangeReturn, oldRangeReturn, fo->primary, size, findDelete) + || LandFindFirst(rangeReturn, oldRangeReturn, fo->secondary, size, findDelete); +} + + +static Bool failoverFindLast(Range rangeReturn, Range oldRangeReturn, Land land, Size size, FindDelete findDelete) +{ + Failover fo; + + AVER(rangeReturn != NULL); + AVER(oldRangeReturn != NULL); + AVERT(Land, land); + fo = failoverOfLand(land); + AVERT(Failover, fo); + AVERT(FindDelete, findDelete); + + /* See . */ + (void)LandFlush(fo->primary, fo->secondary); + + return LandFindLast(rangeReturn, oldRangeReturn, fo->primary, size, findDelete) + || LandFindLast(rangeReturn, oldRangeReturn, fo->secondary, size, findDelete); +} + + +static Bool failoverFindLargest(Range rangeReturn, Range oldRangeReturn, Land land, Size size, FindDelete findDelete) +{ + Failover fo; + + AVER(rangeReturn != NULL); + AVER(oldRangeReturn != NULL); + AVERT(Land, land); + fo = failoverOfLand(land); + AVERT(Failover, fo); + AVERT(FindDelete, findDelete); + + /* See . */ + (void)LandFlush(fo->primary, fo->secondary); + + return LandFindLargest(rangeReturn, oldRangeReturn, fo->primary, size, findDelete) + || LandFindLargest(rangeReturn, oldRangeReturn, fo->secondary, size, findDelete); +} + + +static Bool failoverFindInZones(Bool *foundReturn, Range rangeReturn, Range oldRangeReturn, Land land, Size size, ZoneSet zoneSet, Bool high) +{ + Failover fo; + Bool found = FALSE; + Res res; + + AVER(FALSE); /* TODO: this code is completely untested! */ + AVER(foundReturn != NULL); + AVER(rangeReturn != NULL); + AVER(oldRangeReturn != NULL); + AVERT(Land, land); + fo = failoverOfLand(land); + AVERT(Failover, fo); + /* AVERT(ZoneSet, zoneSet); */ + AVERT(Bool, high); + + /* See . */ + (void)LandFlush(fo->primary, fo->secondary); + + res = LandFindInZones(&found, rangeReturn, oldRangeReturn, fo->primary, size, zoneSet, high); + if (res != ResOK || !found) + res = LandFindInZones(&found, rangeReturn, oldRangeReturn, fo->secondary, size, zoneSet, high); + + *foundReturn = found; + return res; +} + + +static Res failoverDescribe(Land land, mps_lib_FILE *stream) +{ + Failover fo; + Res res; + + if (!TESTT(Land, land)) return ResFAIL; + fo = failoverOfLand(land); + if (!TESTT(Failover, fo)) return ResFAIL; + if (stream == NULL) return ResFAIL; + + res = WriteF(stream, + "Failover $P {\n", (WriteFP)fo, + " primary = $P ($S)\n", (WriteFP)fo->primary, + fo->primary->class->name, + " secondary = $P ($S)\n", (WriteFP)fo->secondary, + fo->secondary->class->name, + "}\n", NULL); + + return res; +} + + +DEFINE_LAND_CLASS(FailoverLandClass, class) +{ + INHERIT_CLASS(class, LandClass); + class->name = "FAILOVER"; + class->size = sizeof(FailoverStruct); + class->init = failoverInit; + class->finish = failoverFinish; + class->sizeMethod = failoverSize; + class->insert = failoverInsert; + class->delete = failoverDelete; + class->iterate = failoverIterate; + class->findFirst = failoverFindFirst; + class->findLast = failoverFindLast; + class->findLargest = failoverFindLargest; + class->findInZones = failoverFindInZones; + class->describe = failoverDescribe; + AVERT(LandClass, class); +} + + +/* C. COPYRIGHT AND LICENSE + * + * Copyright (C) 2014 Ravenbrook Limited . + * All rights reserved. This is an open source license. Contact + * Ravenbrook for commercial licensing options. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions are + * met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Redistributions in any form must be accompanied by information on how + * to obtain complete source code for this software and any accompanying + * software that uses this software. The source code must either be + * included in the distribution or be available for no more than the cost + * of distribution plus a nominal fee, and must be freely redistributable + * under reasonable conditions. For an executable file, complete source + * code means the source code for all modules it contains. It does not + * include source code for modules or files that typically accompany the + * major components of the operating system on which the executable file + * runs. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS + * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED + * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR + * PURPOSE, OR NON-INFRINGEMENT, ARE DISCLAIMED. IN NO EVENT SHALL THE + * COPYRIGHT HOLDERS AND CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ diff --git a/mps/code/failover.h b/mps/code/failover.h new file mode 100644 index 00000000000..56e6149e05e --- /dev/null +++ b/mps/code/failover.h @@ -0,0 +1,69 @@ +/* failover.h: FAILOVER ALLOCATOR INTERFACE + * + * $Id$ + * Copyright (c) 2014 Ravenbrook Limited. See end of file for license. + * + * .source: . + */ + +#ifndef failover_h +#define failover_h + +#include "mpmtypes.h" + +typedef struct FailoverStruct *Failover; + +extern Bool FailoverCheck(Failover failover); + +extern LandClass FailoverLandClassGet(void); + +extern const struct mps_key_s _mps_key_failover_primary; +#define FailoverPrimary (&_mps_key_failover_primary) +#define FailoverPrimary_FIELD p +extern const struct mps_key_s _mps_key_failover_secondary; +#define FailoverSecondary (&_mps_key_failover_secondary) +#define FailoverSecondary_FIELD p + +#endif /* failover.h */ + + +/* C. COPYRIGHT AND LICENSE + * + * Copyright (C) 2014 Ravenbrook Limited . + * All rights reserved. This is an open source license. Contact + * Ravenbrook for commercial licensing options. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions are + * met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Redistributions in any form must be accompanied by information on how + * to obtain complete source code for this software and any accompanying + * software that uses this software. The source code must either be + * included in the distribution or be available for no more than the cost + * of distribution plus a nominal fee, and must be freely redistributable + * under reasonable conditions. For an executable file, complete source + * code means the source code for all modules it contains. It does not + * include source code for modules or files that typically accompany the + * major components of the operating system on which the executable file + * runs. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS + * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED + * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR + * PURPOSE, OR NON-INFRINGEMENT, ARE DISCLAIMED. IN NO EVENT SHALL THE + * COPYRIGHT HOLDERS AND CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ diff --git a/mps/code/fbmtest.c b/mps/code/fbmtest.c index 231d02482a7..e24fcc564ee 100644 --- a/mps/code/fbmtest.c +++ b/mps/code/fbmtest.c @@ -98,6 +98,7 @@ static Bool checkCallback(Range range, void *closureP, Size closureS) Addr base, limit; CheckFBMClosure cl = (CheckFBMClosure)closureP; + AVER(closureS == UNUSED_SIZE); UNUSED(closureS); Insist(cl != NULL); @@ -149,10 +150,10 @@ static void check(FBMState state) switch (state->type) { case FBMTypeCBS: - CBSIterate(state->the.cbs, checkCBSCallback, (void *)&closure, 0); + CBSIterate(state->the.cbs, checkCBSCallback, &closure, UNUSED_SIZE); break; case FBMTypeFreelist: - FreelistIterate(state->the.fl, checkFLCallback, (void *)&closure, 0); + FreelistIterate(state->the.fl, checkFLCallback, &closure, UNUSED_SIZE); break; default: cdie(0, "invalid state->type"); diff --git a/mps/code/fotest.c b/mps/code/fotest.c index 2e63d4e121b..788253b570d 100644 --- a/mps/code/fotest.c +++ b/mps/code/fotest.c @@ -38,28 +38,35 @@ /* Accessors for the CBS used to implement a pool. */ -extern CBS _mps_mvff_cbs(mps_pool_t); -extern CBS _mps_mvt_cbs(mps_pool_t); +extern Land _mps_mvff_cbs(Pool); +extern Land _mps_mvt_cbs(Pool); /* "OOM" pool class -- dummy alloc/free pool class whose alloc() - * method always returns ResMEMORY */ + * method always fails. */ -static Res OOMAlloc(Addr *pReturn, Pool pool, Size size, - Bool withReservoirPermit) +static Res oomAlloc(Addr *pReturn, Pool pool, Size size, + Bool withReservoirPermit) { UNUSED(pReturn); UNUSED(pool); UNUSED(size); UNUSED(withReservoirPermit); - return ResMEMORY; + switch (rnd() % 3) { + case 0: + return ResRESOURCE; + case 1: + return ResMEMORY; + default: + return ResCOMMIT_LIMIT; + } } -extern PoolClass PoolClassOOM(void); +extern PoolClass OOMPoolClassGet(void); DEFINE_POOL_CLASS(OOMPoolClass, this) { INHERIT_CLASS(this, AbstractAllocFreePoolClass); - this->alloc = OOMAlloc; + this->alloc = oomAlloc; this->size = sizeof(PoolStruct); AVERT(PoolClass, this); } @@ -83,16 +90,17 @@ static mps_res_t make(mps_addr_t *p, mps_ap_t ap, size_t size) /* set_oom -- set blockPool of CBS to OOM or MFS according to argument. */ -static void set_oom(CBS cbs, int oom) +static void set_oom(Land land, int oom) { - cbs->blockPool->class = oom ? EnsureOOMPoolClass() : PoolClassMFS(); + CBS cbs = PARENT(CBSStruct, landStruct, land); + cbs->blockPool->class = oom ? OOMPoolClassGet() : PoolClassMFS(); } /* stress -- create an allocation point and allocate in it */ static mps_res_t stress(size_t (*size)(unsigned long, mps_align_t), - mps_align_t alignment, mps_pool_t pool, CBS cbs) + mps_align_t alignment, mps_pool_t pool, Land cbs) { mps_res_t res = MPS_RES_OK; mps_ap_t ap; @@ -182,8 +190,8 @@ int main(int argc, char *argv[]) die(mps_pool_create_k(&pool, arena, mps_class_mvff(), args), "create MVFF"); } MPS_ARGS_END(args); { - CBS cbs = _mps_mvff_cbs(pool); - die(stress(randomSizeAligned, alignment, pool, cbs), "stress MVFF"); + die(stress(randomSizeAligned, alignment, pool, _mps_mvff_cbs(pool)), + "stress MVFF"); } mps_pool_destroy(pool); mps_arena_destroy(arena); @@ -201,8 +209,8 @@ int main(int argc, char *argv[]) die(mps_pool_create_k(&pool, arena, mps_class_mvt(), args), "create MVFF"); } MPS_ARGS_END(args); { - CBS cbs = _mps_mvt_cbs(pool); - die(stress(randomSizeAligned, alignment, pool, cbs), "stress MVT"); + die(stress(randomSizeAligned, alignment, pool, _mps_mvt_cbs(pool)), + "stress MVT"); } mps_pool_destroy(pool); mps_arena_destroy(arena); diff --git a/mps/code/freelist.c b/mps/code/freelist.c index 1abc3f73cc8..2be00189aa8 100644 --- a/mps/code/freelist.c +++ b/mps/code/freelist.c @@ -6,32 +6,65 @@ * .sources: . */ -#include "cbs.h" #include "freelist.h" #include "mpm.h" +#include "range.h" SRCID(freelist, "$Id$"); +#define freelistOfLand(land) PARENT(FreelistStruct, landStruct, land) +#define freelistAlignment(fl) LandAlignment(&(fl)->landStruct) + + typedef union FreelistBlockUnion { struct { FreelistBlock next; /* tagged with low bit 1 */ - /* limit is (char *)this + fl->alignment */ + /* limit is (char *)this + freelistAlignment(fl) */ } small; struct { - FreelistBlock next; + FreelistBlock next; /* not tagged (low bit 0) */ Addr limit; } large; } FreelistBlockUnion; -/* See */ +/* freelistEND -- the end of a list + * + * The end of a list should not be represented with NULL, as this is + * ambiguous. However, freelistEND is in fact a null pointer, for + * performance. To check whether you have it right, try temporarily + * defining freelistEND as ((FreelistBlock)2) or similar (it must be + * an even number because of the use of a tag). + */ + +#define freelistEND ((FreelistBlock)0) + + +/* freelistMinimumAlignment -- the minimum allowed alignment for the + * address ranges in a free list: see + */ + #define freelistMinimumAlignment ((Align)sizeof(FreelistBlock)) +/* FreelistTag -- return the tag of word */ + #define FreelistTag(word) ((word) & 1) + + +/* FreelistTagSet -- return word updated with the tag set */ + #define FreelistTagSet(word) ((FreelistBlock)((Word)(word) | 1)) + + +/* FreelistTagReset -- return word updated with the tag reset */ + #define FreelistTagReset(word) ((FreelistBlock)((Word)(word) & ~(Word)1)) + + +/* FreelistTagCopy -- return 'to' updated to have the same tag as 'from' */ + #define FreelistTagCopy(to, from) ((FreelistBlock)((Word)(to) | FreelistTag((Word)(from)))) @@ -51,7 +84,7 @@ static Addr FreelistBlockLimit(Freelist fl, FreelistBlock block) { AVERT(Freelist, fl); if (FreelistBlockIsSmall(block)) { - return AddrAdd(FreelistBlockBase(block), fl->alignment); + return AddrAdd(FreelistBlockBase(block), freelistAlignment(fl)); } else { return block->large.limit; } @@ -65,7 +98,7 @@ static Bool FreelistBlockCheck(FreelistBlock block) { CHECKL(block != NULL); /* block list is address-ordered */ - CHECKL(FreelistTagReset(block->small.next) == NULL + CHECKL(FreelistTagReset(block->small.next) == freelistEND || block < FreelistTagReset(block->small.next)); CHECKL(FreelistBlockIsSmall(block) || (Addr)block < block->large.limit); @@ -73,8 +106,8 @@ static Bool FreelistBlockCheck(FreelistBlock block) } -/* FreelistBlockNext -- return the next block in the list, or NULL if - * there are no more blocks. +/* FreelistBlockNext -- return the next block in the list, or + * freelistEND if there are no more blocks. */ static FreelistBlock FreelistBlockNext(FreelistBlock block) { @@ -106,7 +139,7 @@ static void FreelistBlockSetLimit(Freelist fl, FreelistBlock block, Addr limit) AVERT(Freelist, fl); AVERT(FreelistBlock, block); - AVER(AddrIsAligned(limit, fl->alignment)); + AVER(AddrIsAligned(limit, freelistAlignment(fl))); AVER(FreelistBlockBase(block) < limit); size = AddrOffset(block, limit); @@ -129,12 +162,12 @@ static FreelistBlock FreelistBlockInit(Freelist fl, Addr base, Addr limit) AVERT(Freelist, fl); AVER(base != NULL); - AVER(AddrIsAligned(base, fl->alignment)); + AVER(AddrIsAligned(base, freelistAlignment(fl))); AVER(base < limit); - AVER(AddrIsAligned(limit, fl->alignment)); + AVER(AddrIsAligned(limit, freelistAlignment(fl))); block = (FreelistBlock)base; - block->small.next = FreelistTagSet(NULL); + block->small.next = FreelistTagSet(freelistEND); FreelistBlockSetLimit(fl, block, limit); AVERT(FreelistBlock, block); return block; @@ -143,23 +176,39 @@ static FreelistBlock FreelistBlockInit(Freelist fl, Addr base, Addr limit) Bool FreelistCheck(Freelist fl) { + Land land; CHECKS(Freelist, fl); + land = &fl->landStruct; + CHECKD(Land, land); /* See */ - CHECKL(AlignIsAligned(fl->alignment, freelistMinimumAlignment)); - CHECKL((fl->list == NULL) == (fl->listSize == 0)); + CHECKL(AlignIsAligned(freelistAlignment(fl), freelistMinimumAlignment)); + CHECKL((fl->list == freelistEND) == (fl->listSize == 0)); + CHECKL((fl->list == freelistEND) == (fl->size == 0)); + CHECKL(SizeIsAligned(fl->size, freelistAlignment(fl))); + return TRUE; } -Res FreelistInit(Freelist fl, Align alignment) +static Res freelistInit(Land land, ArgList args) { - /* See */ - if (!AlignIsAligned(alignment, freelistMinimumAlignment)) - return ResPARAM; + Freelist fl; + LandClass super; + Res res; - fl->alignment = alignment; - fl->list = NULL; + AVERT(Land, land); + super = LAND_SUPERCLASS(FreelistLandClass); + res = (*super->init)(land, args); + if (res != ResOK) + return res; + + /* See */ + AVER(AlignIsAligned(LandAlignment(land), freelistMinimumAlignment)); + + fl = freelistOfLand(land); + fl->list = freelistEND; fl->listSize = 0; + fl->size = 0; fl->sig = FreelistSig; AVERT(Freelist, fl); @@ -167,31 +216,56 @@ Res FreelistInit(Freelist fl, Align alignment) } -void FreelistFinish(Freelist fl) +static void freelistFinish(Land land) { + Freelist fl; + + AVERT(Land, land); + fl = freelistOfLand(land); AVERT(Freelist, fl); fl->sig = SigInvalid; - fl->list = NULL; + fl->list = freelistEND; +} + + +static Size freelistSize(Land land) +{ + Freelist fl; + + AVERT(Land, land); + fl = freelistOfLand(land); + AVERT(Freelist, fl); + return fl->size; } /* freelistBlockSetPrevNext -- update list of blocks - * If prev and next are both NULL, make the block list empty. - * Otherwise, if prev is NULL, make next the first block in the list. - * Otherwise, if next is NULL, make prev the last block in the list. + * + * If prev and next are both freelistEND, make the block list empty. + * Otherwise, if prev is freelistEND, make next the first block in the list. + * Otherwise, if next is freelistEND, make prev the last block in the list. * Otherwise, make next follow prev in the list. * Update the count of blocks by 'delta'. + + * It is tempting to try to simplify this code by putting a + * FreelistBlockUnion into the FreelistStruct and so avoiding the + * special case on prev. But the problem with that idea is that we + * can't guarantee that such a sentinel would respect the isolated + * range invariant, and so it would still have to be special-cases. */ + static void freelistBlockSetPrevNext(Freelist fl, FreelistBlock prev, FreelistBlock next, int delta) { AVERT(Freelist, fl); - if (prev) { - AVER(next == NULL || FreelistBlockLimit(fl, prev) < FreelistBlockBase(next)); - FreelistBlockSetNext(prev, next); - } else { + if (prev == freelistEND) { fl->list = next; + } else { + /* Isolated range invariant (design.mps.freelist.impl.invariant). */ + AVER(next == freelistEND + || FreelistBlockLimit(fl, prev) < FreelistBlockBase(next)); + FreelistBlockSetNext(prev, next); } if (delta < 0) { AVER(fl->listSize >= (Count)-delta); @@ -202,29 +276,32 @@ static void freelistBlockSetPrevNext(Freelist fl, FreelistBlock prev, } -Res FreelistInsert(Range rangeReturn, Freelist fl, Range range) +static Res freelistInsert(Range rangeReturn, Land land, Range range) { + Freelist fl; FreelistBlock prev, cur, next, new; Addr base, limit; Bool coalesceLeft, coalesceRight; AVER(rangeReturn != NULL); + AVERT(Land, land); + fl = freelistOfLand(land); AVERT(Freelist, fl); AVERT(Range, range); - AVER(RangeIsAligned(range, fl->alignment)); + AVER(RangeIsAligned(range, freelistAlignment(fl))); base = RangeBase(range); limit = RangeLimit(range); - prev = NULL; + prev = freelistEND; cur = fl->list; - while (cur) { + while (cur != freelistEND) { if (base < FreelistBlockLimit(fl, cur) && FreelistBlockBase(cur) < limit) return ResFAIL; /* range overlaps with cur */ if (limit <= FreelistBlockBase(cur)) break; next = FreelistBlockNext(cur); - if (next) + if (next != freelistEND) /* Isolated range invariant (design.mps.freelist.impl.invariant). */ AVER(FreelistBlockLimit(fl, cur) < FreelistBlockBase(next)); prev = cur; @@ -235,8 +312,8 @@ Res FreelistInsert(Range rangeReturn, Freelist fl, Range range) * coalesces then it does so with prev on the left, and cur on the * right. */ - coalesceLeft = (prev && base == FreelistBlockLimit(fl, prev)); - coalesceRight = (cur && limit == FreelistBlockBase(cur)); + coalesceLeft = (prev != freelistEND && base == FreelistBlockLimit(fl, prev)); + coalesceRight = (cur != freelistEND && limit == FreelistBlockBase(cur)); if (coalesceLeft && coalesceRight) { base = FreelistBlockBase(prev); @@ -262,17 +339,20 @@ Res FreelistInsert(Range rangeReturn, Freelist fl, Range range) freelistBlockSetPrevNext(fl, prev, new, +1); } + fl->size += RangeSize(range); RangeInit(rangeReturn, base, limit); return ResOK; } -/* freelistDeleteFromBlock -- delete 'range' from 'block' (it is known - * to be a subset of that block); update 'rangeReturn' to the original - * range of 'block' and update the block list accordingly: 'prev' is - * the block on the list just before 'block', or NULL if 'block' is - * the first block on the list. +/* freelistDeleteFromBlock -- delete range from block + * + * range must be a subset of block. Update rangeReturn to be the + * original range of block and update the block list accordingly: prev + * is on the list just before block, or freelistEND if block is the + * first block on the list. */ + static void freelistDeleteFromBlock(Range rangeReturn, Freelist fl, Range range, FreelistBlock prev, FreelistBlock block) @@ -283,8 +363,8 @@ static void freelistDeleteFromBlock(Range rangeReturn, Freelist fl, AVER(rangeReturn != NULL); AVERT(Freelist, fl); AVERT(Range, range); - AVER(RangeIsAligned(range, fl->alignment)); - AVER(prev == NULL || FreelistBlockNext(prev) == block); + AVER(RangeIsAligned(range, freelistAlignment(fl))); + AVER(prev == freelistEND || FreelistBlockNext(prev) == block); AVERT(FreelistBlock, block); AVER(FreelistBlockBase(block) <= RangeBase(range)); AVER(RangeLimit(range) <= FreelistBlockLimit(fl, block)); @@ -317,25 +397,30 @@ static void freelistDeleteFromBlock(Range rangeReturn, Freelist fl, freelistBlockSetPrevNext(fl, block, new, +1); } + AVER(fl->size >= RangeSize(range)); + fl->size -= RangeSize(range); RangeInit(rangeReturn, blockBase, blockLimit); } -Res FreelistDelete(Range rangeReturn, Freelist fl, Range range) +static Res freelistDelete(Range rangeReturn, Land land, Range range) { + Freelist fl; FreelistBlock prev, cur, next; Addr base, limit; AVER(rangeReturn != NULL); + AVERT(Land, land); + fl = freelistOfLand(land); AVERT(Freelist, fl); AVERT(Range, range); base = RangeBase(range); limit = RangeLimit(range); - prev = NULL; + prev = freelistEND; cur = fl->list; - while (cur) { + while (cur != freelistEND) { Addr blockBase, blockLimit; blockBase = FreelistBlockBase(cur); blockLimit = FreelistBlockLimit(fl, cur); @@ -359,43 +444,78 @@ Res FreelistDelete(Range rangeReturn, Freelist fl, Range range) } -void FreelistIterate(Freelist fl, FreelistIterateMethod iterate, - void *closureP, Size closureS) +static Bool freelistIterate(Land land, LandVisitor visitor, + void *closureP, Size closureS) { + Freelist fl; + FreelistBlock cur; + + AVERT(Land, land); + fl = freelistOfLand(land); + AVERT(Freelist, fl); + AVER(FUNCHECK(visitor)); + /* closureP and closureS are arbitrary */ + + for (cur = fl->list; cur != freelistEND; cur = FreelistBlockNext(cur)) { + RangeStruct range; + Bool cont; + RangeInit(&range, FreelistBlockBase(cur), FreelistBlockLimit(fl, cur)); + cont = (*visitor)(land, &range, closureP, closureS); + if (!cont) + return FALSE; + } + return TRUE; +} + + +static Bool freelistIterateAndDelete(Land land, LandDeleteVisitor visitor, + void *closureP, Size closureS) +{ + Freelist fl; FreelistBlock prev, cur, next; + AVERT(Land, land); + fl = freelistOfLand(land); AVERT(Freelist, fl); - AVER(FUNCHECK(iterate)); + AVER(FUNCHECK(visitor)); + /* closureP and closureS are arbitrary */ - prev = NULL; + prev = freelistEND; cur = fl->list; - while (cur) { + while (cur != freelistEND) { Bool delete = FALSE; RangeStruct range; Bool cont; RangeInit(&range, FreelistBlockBase(cur), FreelistBlockLimit(fl, cur)); - cont = (*iterate)(&delete, &range, closureP, closureS); + cont = (*visitor)(&delete, land, &range, closureP, closureS); next = FreelistBlockNext(cur); if (delete) { + Size size = FreelistBlockSize(fl, cur); freelistBlockSetPrevNext(fl, prev, next, -1); + AVER(fl->size >= size); + fl->size -= size; } else { prev = cur; } cur = next; if (!cont) - break; + return FALSE; } + return TRUE; } -/* freelistFindDeleteFromBlock -- Find a chunk of 'size' bytes in - * 'block' (which is known to be at least that big) and possibly - * delete that chunk according to the instruction in 'findDelete'. - * Return the range of that chunk in 'rangeReturn'. Return the - * original range of the block in 'oldRangeReturn'. Update the block - * list accordingly, using 'prev' which is the previous block in the - * list, or NULL if 'block' is the first block in the list. +/* freelistFindDeleteFromBlock -- delete size bytes from block + * + * Find a chunk of size bytes in block (which is known to be at least + * that big) and possibly delete that chunk according to the + * instruction in findDelete. Return the range of that chunk in + * rangeReturn. Return the original range of the block in + * oldRangeReturn. Update the block list accordingly, using prev, + * which is previous in list or freelistEND if block is the first + * block in the list. */ + static void freelistFindDeleteFromBlock(Range rangeReturn, Range oldRangeReturn, Freelist fl, Size size, FindDelete findDelete, @@ -407,9 +527,9 @@ static void freelistFindDeleteFromBlock(Range rangeReturn, Range oldRangeReturn, AVER(rangeReturn != NULL); AVER(oldRangeReturn != NULL); AVERT(Freelist, fl); - AVER(SizeIsAligned(size, fl->alignment)); + AVER(SizeIsAligned(size, freelistAlignment(fl))); AVERT(FindDelete, findDelete); - AVER(prev == NULL || FreelistBlockNext(prev) == block); + AVER(prev == freelistEND || FreelistBlockNext(prev) == block); AVERT(FreelistBlock, block); AVER(FreelistBlockSize(fl, block) >= size); @@ -447,20 +567,23 @@ static void freelistFindDeleteFromBlock(Range rangeReturn, Range oldRangeReturn, } -Bool FreelistFindFirst(Range rangeReturn, Range oldRangeReturn, - Freelist fl, Size size, FindDelete findDelete) +static Bool freelistFindFirst(Range rangeReturn, Range oldRangeReturn, + Land land, Size size, FindDelete findDelete) { + Freelist fl; FreelistBlock prev, cur, next; AVER(rangeReturn != NULL); AVER(oldRangeReturn != NULL); + AVERT(Land, land); + fl = freelistOfLand(land); AVERT(Freelist, fl); - AVER(SizeIsAligned(size, fl->alignment)); + AVER(SizeIsAligned(size, freelistAlignment(fl))); AVERT(FindDelete, findDelete); - prev = NULL; + prev = freelistEND; cur = fl->list; - while (cur) { + while (cur != freelistEND) { if (FreelistBlockSize(fl, cur) >= size) { freelistFindDeleteFromBlock(rangeReturn, oldRangeReturn, fl, size, findDelete, prev, cur); @@ -475,22 +598,25 @@ Bool FreelistFindFirst(Range rangeReturn, Range oldRangeReturn, } -Bool FreelistFindLast(Range rangeReturn, Range oldRangeReturn, - Freelist fl, Size size, FindDelete findDelete) +static Bool freelistFindLast(Range rangeReturn, Range oldRangeReturn, + Land land, Size size, FindDelete findDelete) { + Freelist fl; Bool found = FALSE; FreelistBlock prev, cur, next; - FreelistBlock foundPrev = NULL, foundCur = NULL; + FreelistBlock foundPrev = freelistEND, foundCur = freelistEND; AVER(rangeReturn != NULL); AVER(oldRangeReturn != NULL); + AVERT(Land, land); + fl = freelistOfLand(land); AVERT(Freelist, fl); - AVER(SizeIsAligned(size, fl->alignment)); + AVER(SizeIsAligned(size, freelistAlignment(fl))); AVERT(FindDelete, findDelete); - prev = NULL; + prev = freelistEND; cur = fl->list; - while (cur) { + while (cur != freelistEND) { if (FreelistBlockSize(fl, cur) >= size) { found = TRUE; foundPrev = prev; @@ -509,21 +635,24 @@ Bool FreelistFindLast(Range rangeReturn, Range oldRangeReturn, } -Bool FreelistFindLargest(Range rangeReturn, Range oldRangeReturn, - Freelist fl, Size size, FindDelete findDelete) +static Bool freelistFindLargest(Range rangeReturn, Range oldRangeReturn, + Land land, Size size, FindDelete findDelete) { + Freelist fl; Bool found = FALSE; FreelistBlock prev, cur, next; - FreelistBlock bestPrev = NULL, bestCur = NULL; + FreelistBlock bestPrev = freelistEND, bestCur = freelistEND; AVER(rangeReturn != NULL); AVER(oldRangeReturn != NULL); + AVERT(Land, land); + fl = freelistOfLand(land); AVERT(Freelist, fl); AVERT(FindDelete, findDelete); - prev = NULL; + prev = freelistEND; cur = fl->list; - while (cur) { + while (cur != freelistEND) { if (FreelistBlockSize(fl, cur) >= size) { found = TRUE; size = FreelistBlockSize(fl, cur); @@ -543,20 +672,90 @@ Bool FreelistFindLargest(Range rangeReturn, Range oldRangeReturn, } -/* freelistDescribeIterateMethod -- Iterate method for - * FreelistDescribe. Writes a decription of the range into the stream - * pointed to by 'closureP'. +static Res freelistFindInZones(Bool *foundReturn, Range rangeReturn, + Range oldRangeReturn, Land land, Size size, + ZoneSet zoneSet, Bool high) +{ + Freelist fl; + LandFindMethod landFind; + RangeInZoneSet search; + Bool found = FALSE; + FreelistBlock prev, cur, next; + FreelistBlock foundPrev = freelistEND, foundCur = freelistEND; + RangeStruct foundRange; + + AVER(FALSE); /* TODO: this code is completely untested! */ + AVER(rangeReturn != NULL); + AVER(oldRangeReturn != NULL); + AVERT(Land, land); + fl = freelistOfLand(land); + AVERT(Freelist, fl); + /* AVERT(ZoneSet, zoneSet); */ + AVERT(Bool, high); + + landFind = high ? freelistFindLast : freelistFindFirst; + search = high ? RangeInZoneSetLast : RangeInZoneSetFirst; + + if (zoneSet == ZoneSetEMPTY) + goto fail; + if (zoneSet == ZoneSetUNIV) { + FindDelete fd = high ? FindDeleteHIGH : FindDeleteLOW; + *foundReturn = (*landFind)(rangeReturn, oldRangeReturn, land, size, fd); + return ResOK; + } + if (ZoneSetIsSingle(zoneSet) && size > ArenaStripeSize(LandArena(land))) + goto fail; + + prev = freelistEND; + cur = fl->list; + while (cur != freelistEND) { + Addr base, limit; + if ((*search)(&base, &limit, FreelistBlockBase(cur), + FreelistBlockLimit(fl, cur), + LandArena(land), zoneSet, size)) + { + found = TRUE; + foundPrev = prev; + foundCur = cur; + RangeInit(&foundRange, base, limit); + if (!high) + break; + } + next = FreelistBlockNext(cur); + prev = cur; + cur = next; + } + + if (!found) + goto fail; + + freelistDeleteFromBlock(oldRangeReturn, fl, &foundRange, foundPrev, foundCur); + RangeCopy(rangeReturn, &foundRange); + *foundReturn = TRUE; + return ResOK; + +fail: + *foundReturn = FALSE; + return ResOK; +} + + +/* freelistDescribeVisitor -- visitor method for freelistDescribe + * + * Writes a decription of the range into the stream pointed to by + * closureP. */ -static Bool freelistDescribeIterateMethod(Bool *deleteReturn, Range range, - void *closureP, Size closureS) + +static Bool freelistDescribeVisitor(Land land, Range range, + void *closureP, Size closureS) { Res res; mps_lib_FILE *stream = closureP; - AVER(deleteReturn != NULL); - AVERT(Range, range); - AVER(stream != NULL); - UNUSED(closureS); + if (!TESTT(Land, land)) return FALSE; + if (!RangeCheck(range)) return FALSE; + if (stream == NULL) return FALSE; + if (closureS != UNUSED_SIZE) return FALSE; res = WriteF(stream, " [$P,", (WriteFP)RangeBase(range), @@ -564,64 +763,52 @@ static Bool freelistDescribeIterateMethod(Bool *deleteReturn, Range range, " {$U}\n", (WriteFU)RangeSize(range), NULL); - *deleteReturn = FALSE; return res == ResOK; } -Res FreelistDescribe(Freelist fl, mps_lib_FILE *stream) +static Res freelistDescribe(Land land, mps_lib_FILE *stream) { + Freelist fl; Res res; + Bool b; + if (!TESTT(Land, land)) return ResFAIL; + fl = freelistOfLand(land); if (!TESTT(Freelist, fl)) return ResFAIL; if (stream == NULL) return ResFAIL; res = WriteF(stream, "Freelist $P {\n", (WriteFP)fl, - " alignment = $U\n", (WriteFU)fl->alignment, " listSize = $U\n", (WriteFU)fl->listSize, NULL); - FreelistIterate(fl, freelistDescribeIterateMethod, stream, 0); + b = LandIterate(land, freelistDescribeVisitor, stream, UNUSED_SIZE); + if (!b) return ResFAIL; res = WriteF(stream, "}\n", NULL); return res; } -/* freelistFlushIterateMethod -- Iterate method for - * FreelistFlushToCBS. Attempst to insert the range into the CBS. - */ -static Bool freelistFlushIterateMethod(Bool *deleteReturn, Range range, - void *closureP, Size closureS) +DEFINE_LAND_CLASS(FreelistLandClass, class) { - Res res; - RangeStruct newRange; - CBS cbs; - - AVER(deleteReturn != NULL); - AVERT(Range, range); - AVER(closureP != NULL); - UNUSED(closureS); - - cbs = closureP; - res = CBSInsert(&newRange, cbs, range); - if (res == ResOK) { - *deleteReturn = TRUE; - return TRUE; - } else { - *deleteReturn = FALSE; - return FALSE; - } -} - - -void FreelistFlushToCBS(Freelist fl, CBS cbs) -{ - AVERT(Freelist, fl); - AVERT(CBS, cbs); - - FreelistIterate(fl, freelistFlushIterateMethod, cbs, 0); + INHERIT_CLASS(class, LandClass); + class->name = "FREELIST"; + class->size = sizeof(FreelistStruct); + class->init = freelistInit; + class->finish = freelistFinish; + class->sizeMethod = freelistSize; + class->insert = freelistInsert; + class->delete = freelistDelete; + class->iterate = freelistIterate; + class->iterateAndDelete = freelistIterateAndDelete; + class->findFirst = freelistFindFirst; + class->findLast = freelistFindLast; + class->findLargest = freelistFindLargest; + class->findInZones = freelistFindInZones; + class->describe = freelistDescribe; + AVERT(LandClass, class); } diff --git a/mps/code/freelist.h b/mps/code/freelist.h index 1bb9840c8c9..c46ab57bc15 100644 --- a/mps/code/freelist.h +++ b/mps/code/freelist.h @@ -9,44 +9,13 @@ #ifndef freelist_h #define freelist_h -#include "cbs.h" #include "mpmtypes.h" -#include "range.h" - -#define FreelistSig ((Sig)0x519F6331) /* SIGnature FREEL */ typedef struct FreelistStruct *Freelist; -typedef union FreelistBlockUnion *FreelistBlock; -typedef Bool (*FreelistIterateMethod)(Bool *deleteReturn, Range range, - void *closureP, Size closureS); +extern Bool FreelistCheck(Freelist freelist); -typedef struct FreelistStruct { - Sig sig; - Align alignment; - FreelistBlock list; - Count listSize; -} FreelistStruct; - -extern Bool FreelistCheck(Freelist fl); -extern Res FreelistInit(Freelist fl, Align alignment); -extern void FreelistFinish(Freelist fl); - -extern Res FreelistInsert(Range rangeReturn, Freelist fl, Range range); -extern Res FreelistDelete(Range rangeReturn, Freelist fl, Range range); -extern Res FreelistDescribe(Freelist fl, mps_lib_FILE *stream); - -extern void FreelistIterate(Freelist abq, FreelistIterateMethod iterate, - void *closureP, Size closureS); - -extern Bool FreelistFindFirst(Range rangeReturn, Range oldRangeReturn, - Freelist fl, Size size, FindDelete findDelete); -extern Bool FreelistFindLast(Range rangeReturn, Range oldRangeReturn, - Freelist fl, Size size, FindDelete findDelete); -extern Bool FreelistFindLargest(Range rangeReturn, Range oldRangeReturn, - Freelist fl, Size size, FindDelete findDelete); - -extern void FreelistFlushToCBS(Freelist fl, CBS cbs); +extern LandClass FreelistLandClassGet(void); #endif /* freelist.h */ diff --git a/mps/code/land.c b/mps/code/land.c new file mode 100644 index 00000000000..19f26057623 --- /dev/null +++ b/mps/code/land.c @@ -0,0 +1,642 @@ +/* land.c: LAND (COLLECTION OF ADDRESS RANGES) IMPLEMENTATION + * + * $Id: //info.ravenbrook.com/project/mps/branch/2014-03-30/land/code/land.c#1 $ + * Copyright (c) 2014 Ravenbrook Limited. See end of file for license. + * + * .design: + */ + +#include "mpm.h" +#include "range.h" + +SRCID(land, "$Id$"); + + +/* FindDeleteCheck -- check method for a FindDelete value */ + +Bool FindDeleteCheck(FindDelete findDelete) +{ + CHECKL(findDelete == FindDeleteNONE + || findDelete == FindDeleteLOW + || findDelete == FindDeleteHIGH + || findDelete == FindDeleteENTIRE); + UNUSED(findDelete); /* */ + + return TRUE; +} + + +/* landEnter, landLeave -- Avoid re-entrance + * + * .enter-leave: The visitor functions passed to LandIterate and + * LandIterateAndDelete are not allowed to call methods of that land. + * These functions enforce this. + * + * .enter-leave.simple: Some simple queries are fine to call from + * visitor functions. These are marked with the tag of this comment. + */ + +static void landEnter(Land land) +{ + /* Don't need to check as always called from interface function. */ + AVER(!land->inLand); + land->inLand = TRUE; + return; +} + +static void landLeave(Land land) +{ + /* Don't need to check as always called from interface function. */ + AVER(land->inLand); + land->inLand = FALSE; + return; +} + + +/* LandCheck -- check land */ + +Bool LandCheck(Land land) +{ + /* .enter-leave.simple */ + CHECKS(Land, land); + CHECKD(LandClass, land->class); + CHECKU(Arena, land->arena); + CHECKL(AlignCheck(land->alignment)); + return TRUE; +} + + +/* LandInit -- initialize land + * + * See + */ + +Res LandInit(Land land, LandClass class, Arena arena, Align alignment, void *owner, ArgList args) +{ + Res res; + + AVER(land != NULL); + AVERT(LandClass, class); + AVERT(Align, alignment); + + land->inLand = TRUE; + land->alignment = alignment; + land->arena = arena; + land->class = class; + land->sig = LandSig; + + AVERT(Land, land); + + res = (*class->init)(land, args); + if (res != ResOK) + goto failInit; + + EVENT2(LandInit, land, owner); + landLeave(land); + return ResOK; + + failInit: + land->sig = SigInvalid; + return res; +} + + +/* LandCreate -- allocate and initialize land + * + * See + */ + +Res LandCreate(Land *landReturn, Arena arena, LandClass class, Align alignment, void *owner, ArgList args) +{ + Res res; + Land land; + void *p; + + AVER(landReturn != NULL); + AVERT(Arena, arena); + AVERT(LandClass, class); + + res = ControlAlloc(&p, arena, class->size, + /* withReservoirPermit */ FALSE); + if (res != ResOK) + goto failAlloc; + land = p; + + res = LandInit(land, class, arena, alignment, owner, args); + if (res != ResOK) + goto failInit; + + *landReturn = land; + return ResOK; + +failInit: + ControlFree(arena, land, class->size); +failAlloc: + return res; +} + + +/* LandDestroy -- finish and deallocate land + * + * See + */ + +void LandDestroy(Land land) +{ + Arena arena; + LandClass class; + + AVERT(Land, land); + arena = land->arena; + class = land->class; + AVERT(LandClass, class); + LandFinish(land); + ControlFree(arena, land, class->size); +} + + +/* LandFinish -- finish land + * + * See + */ + +void LandFinish(Land land) +{ + AVERT(Land, land); + landEnter(land); + + (*land->class->finish)(land); + + land->sig = SigInvalid; +} + + +/* LandSize -- return the total size of ranges in land + * + * See + */ + +Size LandSize(Land land) +{ + /* .enter-leave.simple */ + AVERT(Land, land); + + return (*land->class->sizeMethod)(land); +} + + +/* LandInsert -- insert range of addresses into land + * + * See + */ + +Res LandInsert(Range rangeReturn, Land land, Range range) +{ + Res res; + + AVER(rangeReturn != NULL); + AVERT(Land, land); + AVERT(Range, range); + AVER(RangeIsAligned(range, land->alignment)); + landEnter(land); + + res = (*land->class->insert)(rangeReturn, land, range); + + landLeave(land); + return res; +} + + +/* LandDelete -- delete range of addresses from land + * + * See + */ + +Res LandDelete(Range rangeReturn, Land land, Range range) +{ + Res res; + + AVER(rangeReturn != NULL); + AVERT(Land, land); + AVERT(Range, range); + AVER(RangeIsAligned(range, land->alignment)); + landEnter(land); + + res = (*land->class->delete)(rangeReturn, land, range); + + landLeave(land); + return res; +} + + +/* LandIterate -- iterate over isolated ranges of addresses in land + * + * See + */ + +Bool LandIterate(Land land, LandVisitor visitor, void *closureP, Size closureS) +{ + Bool b; + AVERT(Land, land); + AVER(FUNCHECK(visitor)); + landEnter(land); + + b = (*land->class->iterate)(land, visitor, closureP, closureS); + + landLeave(land); + return b; +} + + +/* LandIterateAndDelete -- iterate over isolated ranges of addresses + * in land, deleting some of them + * + * See + */ + +Bool LandIterateAndDelete(Land land, LandDeleteVisitor visitor, void *closureP, Size closureS) +{ + Bool b; + AVERT(Land, land); + AVER(FUNCHECK(visitor)); + landEnter(land); + + b = (*land->class->iterateAndDelete)(land, visitor, closureP, closureS); + + landLeave(land); + return b; +} + + +/* LandFindFirst -- find first range of given size + * + * See + */ + +Bool LandFindFirst(Range rangeReturn, Range oldRangeReturn, Land land, Size size, FindDelete findDelete) +{ + Bool b; + + AVER(rangeReturn != NULL); + AVER(oldRangeReturn != NULL); + AVERT(Land, land); + AVER(SizeIsAligned(size, land->alignment)); + AVER(FindDeleteCheck(findDelete)); + landEnter(land); + + b = (*land->class->findFirst)(rangeReturn, oldRangeReturn, land, size, + findDelete); + + landLeave(land); + return b; +} + + +/* LandFindLast -- find last range of given size + * + * See + */ + +Bool LandFindLast(Range rangeReturn, Range oldRangeReturn, Land land, Size size, FindDelete findDelete) +{ + Bool b; + + AVER(rangeReturn != NULL); + AVER(oldRangeReturn != NULL); + AVERT(Land, land); + AVER(SizeIsAligned(size, land->alignment)); + AVER(FindDeleteCheck(findDelete)); + landEnter(land); + + b = (*land->class->findLast)(rangeReturn, oldRangeReturn, land, size, + findDelete); + + landLeave(land); + return b; +} + + +/* LandFindLargest -- find largest range of at least given size + * + * See + */ + +Bool LandFindLargest(Range rangeReturn, Range oldRangeReturn, Land land, Size size, FindDelete findDelete) +{ + Bool b; + + AVER(rangeReturn != NULL); + AVER(oldRangeReturn != NULL); + AVERT(Land, land); + AVER(SizeIsAligned(size, land->alignment)); + AVER(FindDeleteCheck(findDelete)); + landEnter(land); + + b = (*land->class->findLargest)(rangeReturn, oldRangeReturn, land, size, + findDelete); + + landLeave(land); + return b; +} + + +/* LandFindInSize -- find range of given size in set of zones + * + * See + */ + +Res LandFindInZones(Bool *foundReturn, Range rangeReturn, Range oldRangeReturn, Land land, Size size, ZoneSet zoneSet, Bool high) +{ + Res res; + + AVER(foundReturn != NULL); + AVER(rangeReturn != NULL); + AVER(oldRangeReturn != NULL); + AVERT(Land, land); + AVER(SizeIsAligned(size, land->alignment)); + /* AVER(ZoneSet, zoneSet); */ + AVERT(Bool, high); + landEnter(land); + + res = (*land->class->findInZones)(foundReturn, rangeReturn, oldRangeReturn, + land, size, zoneSet, high); + + landLeave(land); + return res; +} + + +/* LandDescribe -- describe land for debugging + * + * See + */ + +Res LandDescribe(Land land, mps_lib_FILE *stream) +{ + Res res; + + if (!TESTT(Land, land)) return ResFAIL; + if (stream == NULL) return ResFAIL; + + res = WriteF(stream, + "Land $P {\n", (WriteFP)land, + " class $P", (WriteFP)land->class, + " (\"$S\")\n", land->class->name, + " arena $P\n", (WriteFP)land->arena, + " align $U\n", (WriteFU)land->alignment, + " inLand: $U\n", (WriteFU)land->inLand, + NULL); + if (res != ResOK) + return res; + + res = (*land->class->describe)(land, stream); + if (res != ResOK) + return res; + + res = WriteF(stream, "} Land $P\n", (WriteFP)land, NULL); + return ResOK; +} + + +/* landFlushVisitor -- visitor for LandFlush. + * + * closureP argument is the destination Land. Attempt to insert the + * range into the destination. + */ +static Bool landFlushVisitor(Bool *deleteReturn, Land land, Range range, + void *closureP, Size closureS) +{ + Res res; + RangeStruct newRange; + Land dest; + + AVER(deleteReturn != NULL); + AVERT(Land, land); + AVERT(Range, range); + AVER(closureP != NULL); + AVER(closureS == UNUSED_SIZE); + UNUSED(closureS); + + dest = closureP; + res = LandInsert(&newRange, dest, range); + if (res == ResOK) { + *deleteReturn = TRUE; + return TRUE; + } else { + *deleteReturn = FALSE; + return FALSE; + } +} + + +/* LandFlush -- move ranges from src to dest + * + * See + */ + +Bool LandFlush(Land dest, Land src) +{ + AVERT(Land, dest); + AVERT(Land, src); + + return LandIterateAndDelete(src, landFlushVisitor, dest, UNUSED_SIZE); +} + + +/* LandClassCheck -- check land class */ + +Bool LandClassCheck(LandClass class) +{ + CHECKL(ProtocolClassCheck(&class->protocol)); + CHECKL(class->name != NULL); /* Should be <=6 char C identifier */ + CHECKL(class->size >= sizeof(LandStruct)); + CHECKL(FUNCHECK(class->init)); + CHECKL(FUNCHECK(class->finish)); + CHECKL(FUNCHECK(class->insert)); + CHECKL(FUNCHECK(class->delete)); + CHECKL(FUNCHECK(class->findFirst)); + CHECKL(FUNCHECK(class->findLast)); + CHECKL(FUNCHECK(class->findLargest)); + CHECKL(FUNCHECK(class->findInZones)); + CHECKL(FUNCHECK(class->describe)); + CHECKS(LandClass, class); + return TRUE; +} + + +static Res landTrivInit(Land land, ArgList args) +{ + AVERT(Land, land); + AVER(ArgListCheck(args)); + UNUSED(args); + return ResOK; +} + +static void landTrivFinish(Land land) +{ + AVERT(Land, land); + NOOP; +} + +static Size landNoSize(Land land) +{ + UNUSED(land); + NOTREACHED; + return 0; +} + +/* LandSlowSize -- generic size method but slow */ + +static Bool landSizeVisitor(Land land, Range range, + void *closureP, Size closureS) +{ + Size *size; + + AVERT(Land, land); + AVERT(Range, range); + AVER(closureP != NULL); + AVER(closureS == UNUSED_SIZE); + UNUSED(closureS); + + size = closureP; + *size += RangeSize(range); + + return TRUE; +} + +Size LandSlowSize(Land land) +{ + Size size = 0; + Bool b = LandIterate(land, landSizeVisitor, &size, UNUSED_SIZE); + AVER(b); + return size; +} + +static Res landNoInsert(Range rangeReturn, Land land, Range range) +{ + AVER(rangeReturn != NULL); + AVERT(Land, land); + AVERT(Range, range); + return ResUNIMPL; +} + +static Res landNoDelete(Range rangeReturn, Land land, Range range) +{ + AVER(rangeReturn != NULL); + AVERT(Land, land); + AVERT(Range, range); + return ResUNIMPL; +} + +static Bool landNoIterate(Land land, LandVisitor visitor, void *closureP, Size closureS) +{ + AVERT(Land, land); + AVER(visitor != NULL); + UNUSED(closureP); + UNUSED(closureS); + return FALSE; +} + +static Bool landNoIterateAndDelete(Land land, LandDeleteVisitor visitor, void *closureP, Size closureS) +{ + AVERT(Land, land); + AVER(visitor != NULL); + UNUSED(closureP); + UNUSED(closureS); + return FALSE; +} + +static Bool landNoFind(Range rangeReturn, Range oldRangeReturn, Land land, Size size, FindDelete findDelete) +{ + AVER(rangeReturn != NULL); + AVER(oldRangeReturn != NULL); + AVERT(Land, land); + UNUSED(size); + AVER(FindDeleteCheck(findDelete)); + return ResUNIMPL; +} + +static Res landNoFindInZones(Bool *foundReturn, Range rangeReturn, Range oldRangeReturn, Land land, Size size, ZoneSet zoneSet, Bool high) +{ + AVER(foundReturn != NULL); + AVER(rangeReturn != NULL); + AVER(oldRangeReturn != NULL); + AVERT(Land, land); + UNUSED(size); + UNUSED(zoneSet); + AVER(BoolCheck(high)); + return ResUNIMPL; +} + +static Res landTrivDescribe(Land land, mps_lib_FILE *stream) +{ + if (!TESTT(Land, land)) + return ResFAIL; + if (stream == NULL) + return ResFAIL; + /* dispatching function does it all */ + return ResOK; +} + +DEFINE_CLASS(LandClass, class) +{ + INHERIT_CLASS(&class->protocol, ProtocolClass); + class->name = "LAND"; + class->size = sizeof(LandStruct); + class->init = landTrivInit; + class->sizeMethod = landNoSize; + class->finish = landTrivFinish; + class->insert = landNoInsert; + class->delete = landNoDelete; + class->iterate = landNoIterate; + class->iterateAndDelete = landNoIterateAndDelete; + class->findFirst = landNoFind; + class->findLast = landNoFind; + class->findLargest = landNoFind; + class->findInZones = landNoFindInZones; + class->describe = landTrivDescribe; + class->sig = LandClassSig; + AVERT(LandClass, class); +} + + +/* C. COPYRIGHT AND LICENSE + * + * Copyright (C) 2014 Ravenbrook Limited . + * All rights reserved. This is an open source license. Contact + * Ravenbrook for commercial licensing options. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions are + * met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Redistributions in any form must be accompanied by information on how + * to obtain complete source code for this software and any accompanying + * software that uses this software. The source code must either be + * included in the distribution or be available for no more than the cost + * of distribution plus a nominal fee, and must be freely redistributable + * under reasonable conditions. For an executable file, complete source + * code means the source code for all modules it contains. It does not + * include source code for modules or files that typically accompany the + * major components of the operating system on which the executable file + * runs. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS + * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED + * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR + * PURPOSE, OR NON-INFRINGEMENT, ARE DISCLAIMED. IN NO EVENT SHALL THE + * COPYRIGHT HOLDERS AND CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ diff --git a/mps/code/landtest.c b/mps/code/landtest.c new file mode 100644 index 00000000000..af6beff29ac --- /dev/null +++ b/mps/code/landtest.c @@ -0,0 +1,637 @@ +/* landtest.c: LAND TEST + * + * $Id$ + * Copyright (c) 2001-2014 Ravenbrook Limited. See end of file for license. + * + * The MPS contains three land implementations: + * + * 1. the CBS (Coalescing Block Structure) module maintains blocks in + * a splay tree for fast access with a cost in storage; + * + * 2. the Freelist module maintains blocks in an address-ordered + * singly linked list for zero storage overhead with a cost in + * performance. + * + * 3. the Failover module implements a mechanism for using CBS until + * it fails, then falling back to a Freelist. + */ + +#include "cbs.h" +#include "failover.h" +#include "freelist.h" +#include "mpm.h" +#include "mps.h" +#include "mpsavm.h" +#include "mpstd.h" +#include "poolmfs.h" +#include "testlib.h" + +#include /* printf */ + +SRCID(landtest, "$Id$"); + + +#define ArraySize ((Size)123456) + +/* CBS is much faster than Freelist, so we apply more operations to + * the former. */ +#define nCBSOperations ((Size)125000) +#define nFLOperations ((Size)12500) +#define nFOOperations ((Size)12500) + +static Count NAllocateTried, NAllocateSucceeded, NDeallocateTried, + NDeallocateSucceeded; + +static int verbose = 0; + +typedef struct TestStateStruct { + Align align; + BT allocTable; + Addr block; + Land land; +} TestStateStruct, *TestState; + +typedef struct CheckTestClosureStruct { + TestState state; + Addr limit; + Addr oldLimit; +} CheckTestClosureStruct, *CheckTestClosure; + + +static Addr (addrOfIndex)(TestState state, Index i) +{ + return AddrAdd(state->block, (i * state->align)); +} + + +static Index (indexOfAddr)(TestState state, Addr a) +{ + return (Index)(AddrOffset(state->block, a) / state->align); +} + + +static void describe(TestState state) { + die(LandDescribe(state->land, mps_lib_get_stdout()), "LandDescribe"); +} + + +static Bool checkVisitor(Land land, Range range, void *closureP, Size closureS) +{ + Addr base, limit; + CheckTestClosure cl = closureP; + + testlib_unused(land); + Insist(closureS == UNUSED_SIZE); + Insist(cl != NULL); + + base = RangeBase(range); + limit = RangeLimit(range); + + if (base > cl->oldLimit) { + Insist(BTIsSetRange(cl->state->allocTable, + indexOfAddr(cl->state, cl->oldLimit), + indexOfAddr(cl->state, base))); + } else { /* must be at start of table */ + Insist(base == cl->oldLimit); + Insist(cl->oldLimit == cl->state->block); + } + + Insist(BTIsResRange(cl->state->allocTable, + indexOfAddr(cl->state, base), + indexOfAddr(cl->state, limit))); + + cl->oldLimit = limit; + + return TRUE; +} + +static void check(TestState state) +{ + CheckTestClosureStruct closure; + Bool b; + + closure.state = state; + closure.limit = addrOfIndex(state, ArraySize); + closure.oldLimit = state->block; + + b = LandIterate(state->land, checkVisitor, &closure, UNUSED_SIZE); + Insist(b); + + if (closure.oldLimit == state->block) + Insist(BTIsSetRange(state->allocTable, 0, + indexOfAddr(state, closure.limit))); + else if (closure.limit > closure.oldLimit) + Insist(BTIsSetRange(state->allocTable, + indexOfAddr(state, closure.oldLimit), + indexOfAddr(state, closure.limit))); + else + Insist(closure.oldLimit == closure.limit); +} + + +static Word fbmRnd(Word limit) +{ + /* Not very uniform, but never mind. */ + return (Word)rnd() % limit; +} + + +/* nextEdge -- Finds the next transition in the bit table + * + * Returns the index greater than such that the + * range [, ) has the same value in the bit table, + * and has a different value or does not exist. + */ + +static Index nextEdge(BT bt, Size size, Index base) +{ + Index end; + Bool baseValue; + + Insist(bt != NULL); + Insist(base < size); + + baseValue = BTGet(bt, base); + + for(end = base + 1; end < size && BTGet(bt, end) == baseValue; end++) + NOOP; + + return end; +} + + +/* lastEdge -- Finds the previous transition in the bit table + * + * Returns the index less than such that the range + * [, ] has the same value in the bit table, + * and -1 has a different value or does not exist. + */ + +static Index lastEdge(BT bt, Size size, Index base) +{ + Index end; + Bool baseValue; + + Insist(bt != NULL); + Insist(base < size); + + baseValue = BTGet(bt, base); + + for(end = base; end > (Index)0 && BTGet(bt, end - 1) == baseValue; end--) + NOOP; + + return end; +} + + +/* randomRange -- picks random range within table + * + * The function first picks a uniformly distributed within the table. + * + * It then scans forward a binary exponentially distributed + * number of "edges" in the table (that is, transitions between set and + * reset) to get . Note that there is a 50% chance that will + * be the next edge, a 25% chance it will be the edge after, etc., until + * the end of the table. + * + * Finally it picks a uniformly distributed in the range + * [base+1, limit]. + * + * Hence there is a somewhat better than 50% chance that the range will be + * all either set or reset. + */ + +static void randomRange(Addr *baseReturn, Addr *limitReturn, TestState state) +{ + Index base; /* the start of our range */ + Index end; /* an edge (i.e. different from its predecessor) */ + /* after base */ + Index limit; /* a randomly chosen value in (base, limit]. */ + + base = fbmRnd(ArraySize); + + do { + end = nextEdge(state->allocTable, ArraySize, base); + } while(end < ArraySize && fbmRnd(2) == 0); /* p=0.5 exponential */ + + Insist(end > base); + + limit = base + 1 + fbmRnd(end - base); + + *baseReturn = addrOfIndex(state, base); + *limitReturn = addrOfIndex(state, limit); +} + + +static void allocate(TestState state, Addr base, Addr limit) +{ + Res res; + Index ib, il; /* Indexed for base and limit */ + Bool isFree; + RangeStruct range, oldRange; + Addr outerBase, outerLimit; /* interval containing [ib, il) */ + + ib = indexOfAddr(state, base); + il = indexOfAddr(state, limit); + + isFree = BTIsResRange(state->allocTable, ib, il); + + NAllocateTried++; + + if (isFree) { + Size left, right, total; /* Sizes of block and two fragments */ + + outerBase = + addrOfIndex(state, lastEdge(state->allocTable, ArraySize, ib)); + outerLimit = + addrOfIndex(state, nextEdge(state->allocTable, ArraySize, il - 1)); + + left = AddrOffset(outerBase, base); + right = AddrOffset(limit, outerLimit); + total = AddrOffset(outerBase, outerLimit); + + /* TODO: check these values */ + testlib_unused(left); + testlib_unused(right); + testlib_unused(total); + } else { + outerBase = outerLimit = NULL; + } + + RangeInit(&range, base, limit); + res = LandDelete(&oldRange, state->land, &range); + + if (verbose) { + printf("allocate: [%p,%p) -- %s\n", + (void *)base, (void *)limit, isFree ? "succeed" : "fail"); + describe(state); + } + + if (!isFree) { + die_expect((mps_res_t)res, MPS_RES_FAIL, + "Succeeded in deleting allocated block"); + } else { /* isFree */ + die_expect((mps_res_t)res, MPS_RES_OK, + "failed to delete free block"); + Insist(RangeBase(&oldRange) == outerBase); + Insist(RangeLimit(&oldRange) == outerLimit); + NAllocateSucceeded++; + BTSetRange(state->allocTable, ib, il); + } +} + + +static void deallocate(TestState state, Addr base, Addr limit) +{ + Res res; + Index ib, il; + Bool isAllocated; + Addr outerBase = base, outerLimit = limit; /* interval containing [ib, il) */ + RangeStruct range, freeRange; /* interval returned by the manager */ + + ib = indexOfAddr(state, base); + il = indexOfAddr(state, limit); + + isAllocated = BTIsSetRange(state->allocTable, ib, il); + + NDeallocateTried++; + + if (isAllocated) { + Size left, right, total; /* Sizes of block and two fragments */ + + /* Find the free blocks adjacent to the allocated block */ + if (ib > 0 && !BTGet(state->allocTable, ib - 1)) { + outerBase = + addrOfIndex(state, lastEdge(state->allocTable, ArraySize, ib - 1)); + } else { + outerBase = base; + } + + if (il < ArraySize && !BTGet(state->allocTable, il)) { + outerLimit = + addrOfIndex(state, nextEdge(state->allocTable, ArraySize, il)); + } else { + outerLimit = limit; + } + + left = AddrOffset(outerBase, base); + right = AddrOffset(limit, outerLimit); + total = AddrOffset(outerBase, outerLimit); + + /* TODO: check these values */ + testlib_unused(left); + testlib_unused(right); + testlib_unused(total); + } + + RangeInit(&range, base, limit); + res = LandInsert(&freeRange, state->land, &range); + + if (verbose) { + printf("deallocate: [%p,%p) -- %s\n", + (void *)base, (void *)limit, isAllocated ? "succeed" : "fail"); + describe(state); + } + + if (!isAllocated) { + die_expect((mps_res_t)res, MPS_RES_FAIL, + "succeeded in inserting non-allocated block"); + } else { /* isAllocated */ + die_expect((mps_res_t)res, MPS_RES_OK, + "failed to insert allocated block"); + + NDeallocateSucceeded++; + BTResRange(state->allocTable, ib, il); + Insist(RangeBase(&freeRange) == outerBase); + Insist(RangeLimit(&freeRange) == outerLimit); + } +} + + +static void find(TestState state, Size size, Bool high, FindDelete findDelete) +{ + Bool expected, found; + Index expectedBase, expectedLimit; + RangeStruct foundRange, oldRange; + Addr remainderBase, remainderLimit; + Addr origBase, origLimit; + Size oldSize, newSize; + + origBase = origLimit = NULL; + expected = (high ? BTFindLongResRangeHigh : BTFindLongResRange) + (&expectedBase, &expectedLimit, state->allocTable, + (Index)0, (Index)ArraySize, (Count)size); + + if (expected) { + oldSize = (expectedLimit - expectedBase) * state->align; + remainderBase = origBase = addrOfIndex(state, expectedBase); + remainderLimit = origLimit = addrOfIndex(state, expectedLimit); + + switch(findDelete) { + case FindDeleteNONE: + /* do nothing */ + break; + case FindDeleteENTIRE: + remainderBase = remainderLimit; + break; + case FindDeleteLOW: + expectedLimit = expectedBase + size; + remainderBase = addrOfIndex(state, expectedLimit); + break; + case FindDeleteHIGH: + expectedBase = expectedLimit - size; + remainderLimit = addrOfIndex(state, expectedBase); + break; + default: + cdie(0, "invalid findDelete"); + break; + } + + if (findDelete != FindDeleteNONE) { + newSize = AddrOffset(remainderBase, remainderLimit); + } + + /* TODO: check these values */ + testlib_unused(oldSize); + testlib_unused(newSize); + } + + found = (high ? LandFindLast : LandFindFirst) + (&foundRange, &oldRange, state->land, size * state->align, findDelete); + + if (verbose) { + printf("find %s %lu: ", high ? "last" : "first", + (unsigned long)(size * state->align)); + if (expected) { + printf("expecting [%p,%p)\n", + (void *)addrOfIndex(state, expectedBase), + (void *)addrOfIndex(state, expectedLimit)); + } else { + printf("expecting this not to be found\n"); + } + if (found) { + printf(" found [%p,%p)\n", (void *)RangeBase(&foundRange), + (void *)RangeLimit(&foundRange)); + } else { + printf(" not found\n"); + } + } + + Insist(found == expected); + + if (found) { + Insist(expectedBase == indexOfAddr(state, RangeBase(&foundRange))); + Insist(expectedLimit == indexOfAddr(state, RangeLimit(&foundRange))); + + if (findDelete != FindDeleteNONE) { + Insist(RangeBase(&oldRange) == origBase); + Insist(RangeLimit(&oldRange) == origLimit); + BTSetRange(state->allocTable, expectedBase, expectedLimit); + } + } + + return; +} + +static void test(TestState state, unsigned n) { + Addr base, limit; + unsigned i; + Size size; + Bool high; + FindDelete findDelete = FindDeleteNONE; + + BTSetRange(state->allocTable, 0, ArraySize); /* Initially all allocated */ + check(state); + for(i = 0; i < n; i++) { + switch(fbmRnd(3)) { + case 0: + randomRange(&base, &limit, state); + allocate(state, base, limit); + break; + case 1: + randomRange(&base, &limit, state); + deallocate(state, base, limit); + break; + case 2: + size = fbmRnd(ArraySize / 10) + 1; + high = fbmRnd(2) ? TRUE : FALSE; + switch(fbmRnd(6)) { + default: findDelete = FindDeleteNONE; break; + case 3: findDelete = FindDeleteLOW; break; + case 4: findDelete = FindDeleteHIGH; break; + case 5: findDelete = FindDeleteENTIRE; break; + } + find(state, size, high, findDelete); + break; + default: + cdie(0, "invalid rnd(3)"); + return; + } + if ((i + 1) % 1000 == 0) + check(state); + } +} + +#define testArenaSIZE (((size_t)4)<<20) + +extern int main(int argc, char *argv[]) +{ + mps_arena_t mpsArena; + Arena arena; + TestStateStruct state; + void *p; + Addr dummyBlock; + BT allocTable; + MFSStruct blockPool; + CBSStruct cbsStruct; + FreelistStruct flStruct; + FailoverStruct foStruct; + Land cbs = &cbsStruct.landStruct; + Land fl = &flStruct.landStruct; + Land fo = &foStruct.landStruct; + Pool mfs = &blockPool.poolStruct; + Align align; + int i; + + testlib_init(argc, argv); + align = (1 << rnd() % 4) * MPS_PF_ALIGN; + + NAllocateTried = NAllocateSucceeded = NDeallocateTried = + NDeallocateSucceeded = 0; + + die(mps_arena_create(&mpsArena, mps_arena_class_vm(), testArenaSIZE), + "mps_arena_create"); + arena = (Arena)mpsArena; /* avoid pun */ + + die((mps_res_t)BTCreate(&allocTable, arena, ArraySize), + "failed to create alloc table"); + + /* We're not going to use this block, but I feel unhappy just */ + /* inventing addresses. */ + die((mps_res_t)ControlAlloc(&p, arena, ArraySize * align, + /* withReservoirPermit */ FALSE), + "failed to allocate block"); + dummyBlock = p; /* avoid pun */ + + if (verbose) { + printf("Allocated block [%p,%p)\n", (void*)dummyBlock, + (char *)dummyBlock + ArraySize); + } + + /* 1. Test CBS */ + + MPS_ARGS_BEGIN(args) { + die((mps_res_t)LandInit(cbs, CBSFastLandClassGet(), arena, align, NULL, args), + "failed to initialise CBS"); + } MPS_ARGS_END(args); + state.align = align; + state.block = dummyBlock; + state.allocTable = allocTable; + state.land = cbs; + test(&state, nCBSOperations); + LandFinish(cbs); + + /* 2. Test Freelist */ + + die((mps_res_t)LandInit(fl, FreelistLandClassGet(), arena, align, NULL, + mps_args_none), + "failed to initialise Freelist"); + state.land = fl; + test(&state, nFLOperations); + LandFinish(fl); + + /* 3. Test CBS-failing-over-to-Freelist (always failing over on + * first iteration, never failing over on second; see fotest.c for a + * test case that randomly switches fail-over on and off) + */ + + for (i = 0; i < 2; ++i) { + MPS_ARGS_BEGIN(piArgs) { + MPS_ARGS_ADD(piArgs, MPS_KEY_MFS_UNIT_SIZE, sizeof(CBSFastBlockStruct)); + MPS_ARGS_ADD(piArgs, MPS_KEY_EXTEND_BY, ArenaAlign(arena)); + MPS_ARGS_ADD(piArgs, MFSExtendSelf, i); + MPS_ARGS_DONE(piArgs); + die(PoolInit(mfs, arena, PoolClassMFS(), piArgs), "PoolInit"); + } MPS_ARGS_END(piArgs); + + MPS_ARGS_BEGIN(args) { + MPS_ARGS_ADD(args, CBSBlockPool, mfs); + die((mps_res_t)LandInit(cbs, CBSFastLandClassGet(), arena, align, NULL, + args), + "failed to initialise CBS"); + } MPS_ARGS_END(args); + + die((mps_res_t)LandInit(fl, FreelistLandClassGet(), arena, align, NULL, + mps_args_none), + "failed to initialise Freelist"); + MPS_ARGS_BEGIN(args) { + MPS_ARGS_ADD(args, FailoverPrimary, cbs); + MPS_ARGS_ADD(args, FailoverSecondary, fl); + die((mps_res_t)LandInit(fo, FailoverLandClassGet(), arena, align, NULL, + args), + "failed to initialise Failover"); + } MPS_ARGS_END(args); + + state.land = fo; + test(&state, nFOOperations); + LandFinish(fo); + LandFinish(fl); + LandFinish(cbs); + PoolFinish(mfs); + } + + mps_arena_destroy(arena); + + printf("\nNumber of allocations attempted: %"PRIuLONGEST"\n", + (ulongest_t)NAllocateTried); + printf("Number of allocations succeeded: %"PRIuLONGEST"\n", + (ulongest_t)NAllocateSucceeded); + printf("Number of deallocations attempted: %"PRIuLONGEST"\n", + (ulongest_t)NDeallocateTried); + printf("Number of deallocations succeeded: %"PRIuLONGEST"\n", + (ulongest_t)NDeallocateSucceeded); + printf("%s: Conclusion: Failed to find any defects.\n", argv[0]); + return 0; +} + + +/* C. COPYRIGHT AND LICENSE + * + * Copyright (c) 2001-2014 Ravenbrook Limited . + * All rights reserved. This is an open source license. Contact + * Ravenbrook for commercial licensing options. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions are + * met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * 3. Redistributions in any form must be accompanied by information on how + * to obtain complete source code for this software and any accompanying + * software that uses this software. The source code must either be + * included in the distribution or be available for no more than the cost + * of distribution plus a nominal fee, and must be freely redistributable + * under reasonable conditions. For an executable file, complete source + * code means the source code for all modules it contains. It does not + * include source code for modules or files that typically accompany the + * major components of the operating system on which the executable file + * runs. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS + * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED + * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR + * PURPOSE, OR NON-INFRINGEMENT, ARE DISCLAIMED. IN NO EVENT SHALL THE + * COPYRIGHT HOLDERS AND CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ diff --git a/mps/code/locus.c b/mps/code/locus.c index 4a7de2a51d5..6c0b7776ee4 100644 --- a/mps/code/locus.c +++ b/mps/code/locus.c @@ -643,6 +643,7 @@ void LocusInit(Arena arena) gen->mortality = 0.51; RingInit(&gen->locusRing); gen->sig = GenDescSig; + AVERT(GenDesc, gen); } diff --git a/mps/code/misc.h b/mps/code/misc.h index 7380421d5c5..853903b58fa 100644 --- a/mps/code/misc.h +++ b/mps/code/misc.h @@ -152,6 +152,15 @@ typedef const struct SrcIdStruct { #define UNUSED(param) ((void)param) +/* UNUSED_POINTER, UNUSED_SIZE -- values for unused arguments + * + * Use these values for unused pointer, size closure arguments and + * check them in the callback or visitor. + */ +#define UNUSED_POINTER ((Pointer)0xB60405ED) /* PointeR UNUSED */ +#define UNUSED_SIZE ((Size)0x520405ED) /* SiZe UNUSED */ + + /* PARENT -- parent structure * * Given a pointer to a field of a structure this returns a pointer to diff --git a/mps/code/mpm.h b/mps/code/mpm.h index e6a0da4e834..43110467be2 100644 --- a/mps/code/mpm.h +++ b/mps/code/mpm.h @@ -495,8 +495,8 @@ extern void ArenaFinish(Arena arena); extern Res ArenaDescribe(Arena arena, mps_lib_FILE *stream); extern Res ArenaDescribeTracts(Arena arena, mps_lib_FILE *stream); extern Bool ArenaAccess(Addr addr, AccessSet mode, MutatorFaultContext context); -extern Res ArenaFreeCBSInsert(Arena arena, Addr base, Addr limit); -extern void ArenaFreeCBSDelete(Arena arena, Addr base, Addr limit); +extern Res ArenaFreeLandInsert(Arena arena, Addr base, Addr limit); +extern void ArenaFreeLandDelete(Arena arena, Addr base, Addr limit); extern Bool GlobalsCheck(Globals arena); @@ -815,7 +815,7 @@ extern AllocPattern AllocPatternRamp(void); extern AllocPattern AllocPatternRampCollectAll(void); -/* FindDelete -- see and */ +/* FindDelete -- see */ extern Bool FindDeleteCheck(FindDelete findDelete); @@ -1002,6 +1002,37 @@ extern Size VMReserved(VM vm); extern Size VMMapped(VM vm); +/* Land Interface -- see */ + +extern Bool LandCheck(Land land); +#define LandArena(land) ((land)->arena) +#define LandAlignment(land) ((land)->alignment) +extern Size LandSize(Land land); +extern Res LandInit(Land land, LandClass class, Arena arena, Align alignment, void *owner, ArgList args); +extern Res LandCreate(Land *landReturn, Arena arena, LandClass class, Align alignment, void *owner, ArgList args); +extern void LandDestroy(Land land); +extern void LandFinish(Land land); +extern Res LandInsert(Range rangeReturn, Land land, Range range); +extern Res LandDelete(Range rangeReturn, Land land, Range range); +extern Bool LandIterate(Land land, LandVisitor visitor, void *closureP, Size closureS); +extern Bool LandIterateAndDelete(Land land, LandDeleteVisitor visitor, void *closureP, Size closureS); +extern Bool LandFindFirst(Range rangeReturn, Range oldRangeReturn, Land land, Size size, FindDelete findDelete); +extern Bool LandFindLast(Range rangeReturn, Range oldRangeReturn, Land land, Size size, FindDelete findDelete); +extern Bool LandFindLargest(Range rangeReturn, Range oldRangeReturn, Land land, Size size, FindDelete findDelete); +extern Res LandFindInZones(Bool *foundReturn, Range rangeReturn, Range oldRangeReturn, Land land, Size size, ZoneSet zoneSet, Bool high); +extern Res LandDescribe(Land land, mps_lib_FILE *stream); +extern Bool LandFlush(Land dest, Land src); + +extern Size LandSlowSize(Land land); +extern Bool LandClassCheck(LandClass class); +extern LandClass LandClassGet(void); +#define LAND_SUPERCLASS(className) ((LandClass)SUPERCLASS(className)) +#define DEFINE_LAND_CLASS(className, var) \ + DEFINE_ALIAS_CLASS(className, LandClass, var) +#define IsLandSubclass(land, className) \ + IsSubclassPoly((land)->class, className ## Get()) + + /* Stack Probe */ extern void StackProbe(Size depth); diff --git a/mps/code/mpmst.h b/mps/code/mpmst.h index 5d38f3a3319..86087a31102 100644 --- a/mps/code/mpmst.h +++ b/mps/code/mpmst.h @@ -604,7 +604,53 @@ typedef struct GlobalsStruct { } GlobalsStruct; +/* LandClassStruct -- land class structure + * + * See . + */ + +#define LandClassSig ((Sig)0x5197A4DC) /* SIGnature LAND Class */ + +typedef struct LandClassStruct { + ProtocolClassStruct protocol; + const char *name; /* class name string */ + size_t size; /* size of outer structure */ + LandSizeMethod sizeMethod; /* total size of ranges in land */ + LandInitMethod init; /* initialize the land */ + LandFinishMethod finish; /* finish the land */ + LandInsertMethod insert; /* insert a range into the land */ + LandDeleteMethod delete; /* delete a range from the land */ + LandIterateMethod iterate; /* iterate over ranges in the land */ + LandIterateAndDeleteMethod iterateAndDelete; /* iterate and maybe delete */ + LandFindMethod findFirst; /* find first range of given size */ + LandFindMethod findLast; /* find last range of given size */ + LandFindMethod findLargest; /* find largest range */ + LandFindInZonesMethod findInZones; /* find first range of given size in zone set */ + LandDescribeMethod describe; /* describe the land */ + Sig sig; /* .class.end-sig */ +} LandClassStruct; + + +/* LandStruct -- generic land structure + * + * See , + */ + +#define LandSig ((Sig)0x5197A4D9) /* SIGnature LAND */ + +typedef struct LandStruct { + Sig sig; /* */ + LandClass class; /* land class structure */ + Arena arena; /* owning arena */ + Align alignment; /* alignment of addresses */ + Bool inLand; /* prevent reentrance */ +} LandStruct; + + /* CBSStruct -- coalescing block structure + * + * CBS is a Land implementation that maintains a collection of + * disjoint ranges in a splay tree. * * See . */ @@ -612,21 +658,58 @@ typedef struct GlobalsStruct { #define CBSSig ((Sig)0x519CB599) /* SIGnature CBS */ typedef struct CBSStruct { + LandStruct landStruct; /* superclass fields come first */ SplayTreeStruct splayTreeStruct; STATISTIC_DECL(Count treeSize); - Arena arena; - Pool blockPool; - Align alignment; - Bool fastFind; /* maintain and use size property? */ - Bool zoned; /* maintain and use zone property? */ - Bool inCBS; /* prevent reentrance */ + Pool blockPool; /* pool that manages blocks */ + Size blockStructSize; /* size of block structure */ Bool ownPool; /* did we create blockPool? */ + Size size; /* total size of ranges in CBS */ /* meters for sizes of search structures at each op */ METER_DECL(treeSearch); - Sig sig; /* sig at end because embeded */ + Sig sig; /* .class.end-sig */ } CBSStruct; +/* FailoverStruct -- fail over from one land to another + * + * Failover is a Land implementation that combines two other Lands, + * using primary until it fails, and then using secondary. + * + * See . + */ + +#define FailoverSig ((Sig)0x519FA170) /* SIGnature FAILOver */ + +typedef struct FailoverStruct { + LandStruct landStruct; /* superclass fields come first */ + Land primary; /* use this land normally */ + Land secondary; /* but use this one if primary fails */ + Sig sig; /* .class.end-sig */ +} FailoverStruct; + + +/* FreelistStruct -- address-ordered freelist + * + * Freelist is a subclass of Land that maintains a collection of + * disjoint ranges in an address-ordered freelist. + * + * See . + */ + +#define FreelistSig ((Sig)0x519F6331) /* SIGnature FREEL */ + +typedef union FreelistBlockUnion *FreelistBlock; + +typedef struct FreelistStruct { + LandStruct landStruct; /* superclass fields come first */ + FreelistBlock list; /* first block in list or NULL if empty */ + Count listSize; /* number of blocks in list */ + Size size; /* total size of ranges in list */ + Sig sig; /* .class.end-sig */ +} FreelistStruct; + + /* ArenaStruct -- generic arena * * See . */ @@ -661,9 +744,9 @@ typedef struct mps_arena_s { Serial chunkSerial; /* next chunk number */ ChunkCacheEntryStruct chunkCache; /* just one entry */ - Bool hasFreeCBS; /* Is freeCBS available? */ + Bool hasFreeLand; /* Is freeLand available? */ MFSStruct freeCBSBlockPoolStruct; - CBSStruct freeCBSStruct; + CBSStruct freeLandStruct; ZoneSet freeZones; /* zones not yet allocated */ Bool zoned; /* use zoned allocation? */ diff --git a/mps/code/mpmtypes.h b/mps/code/mpmtypes.h index e22e77d8f69..c9c5b029c4a 100644 --- a/mps/code/mpmtypes.h +++ b/mps/code/mpmtypes.h @@ -108,7 +108,10 @@ typedef struct AllocPatternStruct *AllocPattern; typedef struct AllocFrameStruct *AllocFrame; /* */ typedef struct ReservoirStruct *Reservoir; /* */ typedef struct StackContextStruct *StackContext; -typedef unsigned FindDelete; /* */ +typedef struct RangeStruct *Range; /* */ +typedef struct LandStruct *Land; /* */ +typedef struct LandClassStruct *LandClass; /* */ +typedef unsigned FindDelete; /* */ /* Arena*Method -- see */ @@ -261,6 +264,22 @@ typedef struct TraceStartMessageStruct *TraceStartMessage; typedef struct TraceMessageStruct *TraceMessage; /* trace end */ +/* Land*Method -- see */ + +typedef Res (*LandInitMethod)(Land land, ArgList args); +typedef void (*LandFinishMethod)(Land land); +typedef Size (*LandSizeMethod)(Land land); +typedef Res (*LandInsertMethod)(Range rangeReturn, Land land, Range range); +typedef Res (*LandDeleteMethod)(Range rangeReturn, Land land, Range range); +typedef Bool (*LandVisitor)(Land land, Range range, void *closureP, Size closureS); +typedef Bool (*LandDeleteVisitor)(Bool *deleteReturn, Land land, Range range, void *closureP, Size closureS); +typedef Bool (*LandIterateMethod)(Land land, LandVisitor visitor, void *closureP, Size closureS); +typedef Bool (*LandIterateAndDeleteMethod)(Land land, LandDeleteVisitor visitor, void *closureP, Size closureS); +typedef Bool (*LandFindMethod)(Range rangeReturn, Range oldRangeReturn, Land land, Size size, FindDelete findDelete); +typedef Res (*LandFindInZonesMethod)(Bool *foundReturn, Range rangeReturn, Range oldRangeReturn, Land land, Size size, ZoneSet zoneSet, Bool high); +typedef Res (*LandDescribeMethod)(Land land, mps_lib_FILE *stream); + + /* CONSTANTS */ @@ -407,7 +426,7 @@ enum { }; -/* FindDelete operations -- see and */ +/* FindDelete operations -- see */ enum { FindDeleteNONE = 1, /* don't delete after finding */ diff --git a/mps/code/mps.c b/mps/code/mps.c index 9f217c15791..115996ba7a0 100644 --- a/mps/code/mps.c +++ b/mps/code/mps.c @@ -76,6 +76,8 @@ #include "freelist.c" #include "sa.c" #include "nailboard.c" +#include "land.c" +#include "failover.c" /* Additional pool classes */ diff --git a/mps/code/mps.xcodeproj/project.pbxproj b/mps/code/mps.xcodeproj/project.pbxproj index 60bd70789ac..39a2d76f8ea 100644 --- a/mps/code/mps.xcodeproj/project.pbxproj +++ b/mps/code/mps.xcodeproj/project.pbxproj @@ -91,11 +91,11 @@ 22B2BC3D18B643B300C33E63 /* PBXTargetDependency */, 2291A5E6175CB207001D4920 /* PBXTargetDependency */, 2291A5E8175CB20E001D4920 /* PBXTargetDependency */, - 3114A65B156E95B4001E0AA3 /* PBXTargetDependency */, 3114A5CC156E932C001E0AA3 /* PBXTargetDependency */, 3114A5EA156E93C4001E0AA3 /* PBXTargetDependency */, 224CC79D175E187C002FF81B /* PBXTargetDependency */, 22B2BC3F18B643B700C33E63 /* PBXTargetDependency */, + 3114A65B156E95B4001E0AA3 /* PBXTargetDependency */, 2231BB6D18CA986B002D6322 /* PBXTargetDependency */, 31D60034156D3D5A00337B26 /* PBXTargetDependency */, 2286E4C918F4389E004111E2 /* PBXTargetDependency */, @@ -161,7 +161,7 @@ 2291A5DB175CB05F001D4920 /* testlib.c in Sources */ = {isa = PBXBuildFile; fileRef = 31EEAC9E156AB73400714D05 /* testlib.c */; }; 2291A5DD175CB05F001D4920 /* libmps.a in Frameworks */ = {isa = PBXBuildFile; fileRef = 31EEABFB156AAF9D00714D05 /* libmps.a */; }; 2291A5E4175CB076001D4920 /* exposet0.c in Sources */ = {isa = PBXBuildFile; fileRef = 2291A5AA175CAA9B001D4920 /* exposet0.c */; }; - 2291A5ED175CB5E2001D4920 /* fbmtest.c in Sources */ = {isa = PBXBuildFile; fileRef = 2291A5E9175CB4EC001D4920 /* fbmtest.c */; }; + 2291A5ED175CB5E2001D4920 /* landtest.c in Sources */ = {isa = PBXBuildFile; fileRef = 2291A5E9175CB4EC001D4920 /* landtest.c */; }; 22B2BC2E18B6434F00C33E63 /* mps.c in Sources */ = {isa = PBXBuildFile; fileRef = 31A47BA3156C1E130039B1C2 /* mps.c */; }; 22B2BC3718B6437C00C33E63 /* scheme-advanced.c in Sources */ = {isa = PBXBuildFile; fileRef = 22B2BC2B18B6434000C33E63 /* scheme-advanced.c */; }; 22C2ACA718BE400A006B3677 /* testlib.c in Sources */ = {isa = PBXBuildFile; fileRef = 31EEAC9E156AB73400714D05 /* testlib.c */; }; @@ -796,7 +796,7 @@ containerPortal = 31EEABDA156AAE9E00714D05 /* Project object */; proxyType = 1; remoteGlobalIDString = 3114A64B156E9596001E0AA3; - remoteInfo = fbmtest; + remoteInfo = landtest; }; 3114A674156E9619001E0AA3 /* PBXContainerItemProxy */ = { isa = PBXContainerItemProxy; @@ -1415,7 +1415,7 @@ 2291A5BD175CAB2F001D4920 /* awlutth */ = {isa = PBXFileReference; explicitFileType = "compiled.mach-o.executable"; includeInIndex = 0; path = awlutth; sourceTree = BUILT_PRODUCTS_DIR; }; 2291A5D1175CAFCA001D4920 /* expt825 */ = {isa = PBXFileReference; explicitFileType = "compiled.mach-o.executable"; includeInIndex = 0; path = expt825; sourceTree = BUILT_PRODUCTS_DIR; }; 2291A5E3175CB05F001D4920 /* exposet0 */ = {isa = PBXFileReference; explicitFileType = "compiled.mach-o.executable"; includeInIndex = 0; path = exposet0; sourceTree = BUILT_PRODUCTS_DIR; }; - 2291A5E9175CB4EC001D4920 /* fbmtest.c */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.c; path = fbmtest.c; sourceTree = ""; }; + 2291A5E9175CB4EC001D4920 /* landtest.c */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.c; path = landtest.c; sourceTree = ""; }; 2291A5EA175CB503001D4920 /* abq.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = abq.h; sourceTree = ""; }; 2291A5EB175CB53E001D4920 /* range.c */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.c; path = range.c; sourceTree = ""; }; 2291A5EC175CB53E001D4920 /* range.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = range.h; sourceTree = ""; }; @@ -1430,6 +1430,11 @@ 22E30E831886FF1400D98EA9 /* nailboard.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = nailboard.h; sourceTree = ""; }; 22F846AF18F4379C00982BA7 /* lockut.c */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.c; path = lockut.c; sourceTree = ""; }; 22F846BD18F437B900982BA7 /* lockut */ = {isa = PBXFileReference; explicitFileType = "compiled.mach-o.executable"; includeInIndex = 0; path = lockut; sourceTree = BUILT_PRODUCTS_DIR; }; + 22C5C99A18EC6AEC004C63D4 /* failover.c */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.c; path = failover.c; sourceTree = ""; }; + 22C5C99B18EC6AEC004C63D4 /* failover.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = failover.h; sourceTree = ""; }; + 22C5C99C18EC6AEC004C63D4 /* land.c */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.c; path = land.c; sourceTree = ""; }; + 22DD93E118ED815F00240DD2 /* failover.txt */ = {isa = PBXFileReference; lastKnownFileType = text; name = failover.txt; path = ../design/failover.txt; sourceTree = ""; }; + 22DD93E218ED815F00240DD2 /* land.txt */ = {isa = PBXFileReference; lastKnownFileType = text; name = land.txt; path = ../design/land.txt; sourceTree = ""; }; 22FA177516E8D6FC0098B23F /* amcssth */ = {isa = PBXFileReference; explicitFileType = "compiled.mach-o.executable"; includeInIndex = 0; path = amcssth; sourceTree = BUILT_PRODUCTS_DIR; }; 22FA177616E8D7A80098B23F /* amcssth.c */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.c; path = amcssth.c; sourceTree = ""; }; 22FACED1188807FF000FDBC1 /* airtest.c */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.c; path = airtest.c; sourceTree = ""; }; @@ -1485,7 +1490,7 @@ 3114A633156E94DB001E0AA3 /* abqtest */ = {isa = PBXFileReference; explicitFileType = "compiled.mach-o.executable"; includeInIndex = 0; path = abqtest; sourceTree = BUILT_PRODUCTS_DIR; }; 3114A63D156E94EA001E0AA3 /* abqtest.c */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.c; path = abqtest.c; sourceTree = ""; }; 3114A645156E9525001E0AA3 /* abq.c */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.c; path = abq.c; sourceTree = ""; }; - 3114A64C156E9596001E0AA3 /* fbmtest */ = {isa = PBXFileReference; explicitFileType = "compiled.mach-o.executable"; includeInIndex = 0; path = fbmtest; sourceTree = BUILT_PRODUCTS_DIR; }; + 3114A64C156E9596001E0AA3 /* landtest */ = {isa = PBXFileReference; explicitFileType = "compiled.mach-o.executable"; includeInIndex = 0; path = landtest; sourceTree = BUILT_PRODUCTS_DIR; }; 3114A662156E95D9001E0AA3 /* btcv */ = {isa = PBXFileReference; explicitFileType = "compiled.mach-o.executable"; includeInIndex = 0; path = btcv; sourceTree = BUILT_PRODUCTS_DIR; }; 3114A66C156E95EB001E0AA3 /* btcv.c */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.c; path = btcv.c; sourceTree = ""; }; 3114A67C156E9668001E0AA3 /* mv2test */ = {isa = PBXFileReference; explicitFileType = "compiled.mach-o.executable"; includeInIndex = 0; path = mv2test; sourceTree = BUILT_PRODUCTS_DIR; }; @@ -2137,6 +2142,7 @@ 31160D9C1899540D0071EB17 /* config.txt */, 31160D9D1899540D0071EB17 /* critical-path.txt */, 31160D9E1899540D0071EB17 /* diag.txt */, + 22DD93E118ED815F00240DD2 /* failover.txt */, 31160D9F1899540D0071EB17 /* finalize.txt */, 31160DA01899540D0071EB17 /* fix.txt */, 31160DA11899540D0071EB17 /* freelist.txt */, @@ -2146,6 +2152,7 @@ 31160DA51899540D0071EB17 /* interface-c.txt */, 31160DA61899540D0071EB17 /* io.txt */, 31160DA71899540D0071EB17 /* keyword-arguments.txt */, + 22DD93E218ED815F00240DD2 /* land.txt */, 31160DA81899540D0071EB17 /* lib.txt */, 31160DA91899540D0071EB17 /* lock.txt */, 31160DAA1899540D0071EB17 /* locus.txt */, @@ -2216,7 +2223,6 @@ 3114A613156E944A001E0AA3 /* bttest.c */, 2291A5AA175CAA9B001D4920 /* exposet0.c */, 2291A5AB175CAA9B001D4920 /* expt825.c */, - 2291A5E9175CB4EC001D4920 /* fbmtest.c */, 3114A5CD156E9369001E0AA3 /* finalcv.c */, 3114A5E5156E93B9001E0AA3 /* finaltest.c */, 3124CAC6156BE48D00753214 /* fmtdy.c */, @@ -2230,6 +2236,7 @@ 22FACED6188807FF000FDBC1 /* fmtscheme.c */, 22FACED7188807FF000FDBC1 /* fmtscheme.h */, 224CC79E175E3202002FF81B /* fotest.c */, + 2291A5E9175CB4EC001D4920 /* landtest.c */, 2231BB6818CA9834002D6322 /* locbwcss.c */, 31D60036156D3E0200337B26 /* lockcov.c */, 2231BB6918CA983C002D6322 /* locusss.c */, @@ -2321,7 +2328,7 @@ 3114A605156E9430001E0AA3 /* bttest */, 3114A61C156E9485001E0AA3 /* teletest */, 3114A633156E94DB001E0AA3 /* abqtest */, - 3114A64C156E9596001E0AA3 /* fbmtest */, + 3114A64C156E9596001E0AA3 /* landtest */, 3114A662156E95D9001E0AA3 /* btcv */, 3114A67C156E9668001E0AA3 /* mv2test */, 3114A695156E971B001E0AA3 /* messtest */, @@ -2376,10 +2383,13 @@ 311F2F5917398AE900C15B6A /* eventcom.h */, 311F2F5A17398AE900C15B6A /* eventdef.h */, 311F2F5C17398AE900C15B6A /* eventrep.h */, + 22C5C99A18EC6AEC004C63D4 /* failover.c */, + 22C5C99B18EC6AEC004C63D4 /* failover.h */, 31EEAC1A156AB2B200714D05 /* format.c */, 2291A5EE175CB768001D4920 /* freelist.c */, 2291A5EF175CB768001D4920 /* freelist.h */, 31EEAC07156AB27B00714D05 /* global.c */, + 22C5C99C18EC6AEC004C63D4 /* land.c */, 31EEAC2B156AB2F200714D05 /* ld.c */, 311F2F5E17398B0E00C15B6A /* lock.h */, 31EEAC08156AB27B00714D05 /* locus.c */, @@ -3011,9 +3021,9 @@ productReference = 3114A633156E94DB001E0AA3 /* abqtest */; productType = "com.apple.product-type.tool"; }; - 3114A64B156E9596001E0AA3 /* fbmtest */ = { + 3114A64B156E9596001E0AA3 /* landtest */ = { isa = PBXNativeTarget; - buildConfigurationList = 3114A653156E9596001E0AA3 /* Build configuration list for PBXNativeTarget "fbmtest" */; + buildConfigurationList = 3114A653156E9596001E0AA3 /* Build configuration list for PBXNativeTarget "landtest" */; buildPhases = ( 3114A648156E9596001E0AA3 /* Sources */, 3114A649156E9596001E0AA3 /* Frameworks */, @@ -3024,9 +3034,9 @@ dependencies = ( 3114A659156E95B1001E0AA3 /* PBXTargetDependency */, ); - name = fbmtest; - productName = fbmtest; - productReference = 3114A64C156E9596001E0AA3 /* fbmtest */; + name = landtest; + productName = landtest; + productReference = 3114A64C156E9596001E0AA3 /* landtest */; productType = "com.apple.product-type.tool"; }; 3114A661156E95D9001E0AA3 /* btcv */ = { @@ -3411,11 +3421,11 @@ 318DA8C31892B0F30089718C /* djbench */, 2291A5D3175CB05F001D4920 /* exposet0 */, 2291A5C1175CAFCA001D4920 /* expt825 */, - 3114A64B156E9596001E0AA3 /* fbmtest */, 3114A5BC156E9315001E0AA3 /* finalcv */, 3114A5D5156E93A0001E0AA3 /* finaltest */, 224CC78C175E1821002FF81B /* fotest */, 6313D46718A400B200EB03EF /* gcbench */, + 3114A64B156E9596001E0AA3 /* landtest */, 2231BB4C18CA97D8002D6322 /* locbwcss */, 31D60026156D3D3E00337B26 /* lockcov */, 2231BB5A18CA97DC002D6322 /* locusss */, @@ -3801,7 +3811,7 @@ isa = PBXSourcesBuildPhase; buildActionMask = 2147483647; files = ( - 2291A5ED175CB5E2001D4920 /* fbmtest.c in Sources */, + 2291A5ED175CB5E2001D4920 /* landtest.c in Sources */, 3114A672156E95F6001E0AA3 /* testlib.c in Sources */, ); runOnlyForDeploymentPostprocessing = 0; @@ -4341,7 +4351,7 @@ }; 3114A65B156E95B4001E0AA3 /* PBXTargetDependency */ = { isa = PBXTargetDependency; - target = 3114A64B156E9596001E0AA3 /* fbmtest */; + target = 3114A64B156E9596001E0AA3 /* landtest */; targetProxy = 3114A65A156E95B4001E0AA3 /* PBXContainerItemProxy */; }; 3114A675156E9619001E0AA3 /* PBXTargetDependency */ = { @@ -6104,7 +6114,7 @@ defaultConfigurationIsVisible = 0; defaultConfigurationName = Release; }; - 3114A653156E9596001E0AA3 /* Build configuration list for PBXNativeTarget "fbmtest" */ = { + 3114A653156E9596001E0AA3 /* Build configuration list for PBXNativeTarget "landtest" */ = { isa = XCConfigurationList; buildConfigurations = ( 3114A654156E9596001E0AA3 /* Debug */, diff --git a/mps/code/poolamc.c b/mps/code/poolamc.c index 0a9ccdd759f..313e6a9dde0 100644 --- a/mps/code/poolamc.c +++ b/mps/code/poolamc.c @@ -673,7 +673,6 @@ static Res amcGenCreate(amcGen *genReturn, AMC amc, GenDesc gen) if(res != ResOK) goto failGenInit; RingInit(&amcgen->amcRing); - amcgen->segs = 0; amcgen->forward = buffer; amcgen->sig = amcGenSig; @@ -714,11 +713,11 @@ static void amcGenDestroy(amcGen gen) /* amcGenDescribe -- describe an AMC generation */ -static Res amcGenDescribe(amcGen amcgen, mps_lib_FILE *stream) +static Res amcGenDescribe(amcGen gen, mps_lib_FILE *stream) { Res res; - if(!TESTT(amcGen, amcgen)) + if(!TESTT(amcGen, gen)) return ResFAIL; res = WriteF(stream, diff --git a/mps/code/poolmfs.c b/mps/code/poolmfs.c index b40094d839c..c203c5697b6 100644 --- a/mps/code/poolmfs.c +++ b/mps/code/poolmfs.c @@ -151,6 +151,8 @@ void MFSFinishTracts(Pool pool, MFSTractVisitor visitor, static void MFSTractFreeVisitor(Pool pool, Addr base, Size size, void *closureP, Size closureS) { + AVER(closureP == UNUSED_POINTER); + AVER(closureS == UNUSED_SIZE); UNUSED(closureP); UNUSED(closureS); ArenaFree(base, size, pool); @@ -165,7 +167,7 @@ static void MFSFinish(Pool pool) mfs = PoolPoolMFS(pool); AVERT(MFS, mfs); - MFSFinishTracts(pool, MFSTractFreeVisitor, NULL, 0); + MFSFinishTracts(pool, MFSTractFreeVisitor, UNUSED_POINTER, UNUSED_SIZE); mfs->sig = SigInvalid; } diff --git a/mps/code/poolmv2.c b/mps/code/poolmv2.c index 72774063ed2..4dd85c184e5 100644 --- a/mps/code/poolmv2.c +++ b/mps/code/poolmv2.c @@ -14,6 +14,7 @@ #include "mpscmvt.h" #include "abq.h" #include "cbs.h" +#include "failover.h" #include "freelist.h" #include "meter.h" #include "range.h" @@ -51,8 +52,9 @@ static Res MVTContingencySearch(Addr *baseReturn, Addr *limitReturn, MVT mvt, Size min); static Bool MVTCheckFit(Addr base, Addr limit, Size min, Arena arena); static ABQ MVTABQ(MVT mvt); -static CBS MVTCBS(MVT mvt); -static Freelist MVTFreelist(MVT mvt); +static Land MVTCBS(MVT mvt); +static Land MVTFreelist(MVT mvt); +static Land MVTFailover(MVT mvt); /* Types */ @@ -62,6 +64,7 @@ typedef struct MVTStruct PoolStruct poolStruct; CBSStruct cbsStruct; /* The coalescing block structure */ FreelistStruct flStruct; /* The emergency free list structure */ + FailoverStruct foStruct; /* The fail-over mechanism */ ABQStruct abqStruct; /* The available block queue */ /* */ Size minSize; /* Pool parameter */ @@ -162,15 +165,21 @@ static ABQ MVTABQ(MVT mvt) } -static CBS MVTCBS(MVT mvt) +static Land MVTCBS(MVT mvt) { - return &mvt->cbsStruct; + return &mvt->cbsStruct.landStruct; } -static Freelist MVTFreelist(MVT mvt) +static Land MVTFreelist(MVT mvt) { - return &mvt->flStruct; + return &mvt->flStruct.landStruct; +} + + +static Land MVTFailover(MVT mvt) +{ + return &mvt->foStruct.landStruct; } @@ -263,19 +272,29 @@ static Res MVTInit(Pool pool, ArgList args) if (abqDepth < 3) abqDepth = 3; - res = CBSInit(MVTCBS(mvt), arena, (void *)mvt, align, - /* fastFind */ FALSE, /* zoned */ FALSE, args); + res = LandInit(MVTCBS(mvt), CBSFastLandClassGet(), arena, align, mvt, + mps_args_none); if (res != ResOK) goto failCBS; + res = LandInit(MVTFreelist(mvt), FreelistLandClassGet(), arena, align, mvt, + mps_args_none); + if (res != ResOK) + goto failFreelist; + + MPS_ARGS_BEGIN(foArgs) { + MPS_ARGS_ADD(foArgs, FailoverPrimary, MVTCBS(mvt)); + MPS_ARGS_ADD(foArgs, FailoverSecondary, MVTFreelist(mvt)); + res = LandInit(MVTFailover(mvt), FailoverLandClassGet(), arena, align, mvt, + foArgs); + } MPS_ARGS_END(foArgs); + if (res != ResOK) + goto failFailover; + res = ABQInit(arena, MVTABQ(mvt), (void *)mvt, abqDepth, sizeof(RangeStruct)); if (res != ResOK) goto failABQ; - res = FreelistInit(MVTFreelist(mvt), align); - if (res != ResOK) - goto failFreelist; - pool->alignment = align; mvt->reuseSize = reuseSize; mvt->fillSize = fillSize; @@ -338,10 +357,12 @@ static Res MVTInit(Pool pool, ArgList args) reserveDepth, fragLimit); return ResOK; -failFreelist: - ABQFinish(arena, MVTABQ(mvt)); failABQ: - CBSFinish(MVTCBS(mvt)); + LandFinish(MVTFailover(mvt)); +failFailover: + LandFinish(MVTFreelist(mvt)); +failFreelist: + LandFinish(MVTCBS(mvt)); failCBS: AVER(res != ResOK); return res; @@ -359,6 +380,7 @@ static Bool MVTCheck(MVT mvt) CHECKD(CBS, &mvt->cbsStruct); CHECKD(ABQ, &mvt->abqStruct); CHECKD(Freelist, &mvt->flStruct); + CHECKD(Failover, &mvt->foStruct); CHECKL(mvt->reuseSize >= 2 * mvt->fillSize); CHECKL(mvt->fillSize >= mvt->maxSize); CHECKL(mvt->maxSize >= mvt->meanSize); @@ -408,10 +430,11 @@ static void MVTFinish(Pool pool) SegFree(SegOfPoolRing(node)); } - /* Finish the Freelist, ABQ and CBS structures */ - FreelistFinish(MVTFreelist(mvt)); + /* Finish the ABQ, Failover, Freelist and CBS structures */ ABQFinish(arena, MVTABQ(mvt)); - CBSFinish(MVTCBS(mvt)); + LandFinish(MVTFailover(mvt)); + LandFinish(MVTFreelist(mvt)); + LandFinish(MVTCBS(mvt)); } @@ -601,14 +624,7 @@ static Bool MVTABQFill(Addr *baseReturn, Addr *limitReturn, } -/* MVTContingencyFill -- try to fill a request from the CBS or Freelist - * - * (The CBS and Freelist are lumped together under the heading of - * "contingency" for historical reasons: the Freelist used to be part - * of the CBS. There is no principled reason why these two are - * searched at the same time: if it should prove convenient to - * separate them, go ahead.) - */ +/* MVTContingencyFill -- try to fill a request from the free lists */ static Bool MVTContingencyFill(Addr *baseReturn, Addr *limitReturn, MVT mvt, Size minSize) { @@ -697,8 +713,7 @@ static Res MVTBufferFill(Addr *baseReturn, Addr *limitReturn, METER_ACC(mvt->underflows, minSize); /* If fragmentation is acceptable, attempt to find a free block from - the CBS or Freelist. - */ + the free lists. */ if (mvt->available >= mvt->availLimit) { METER_ACC(mvt->fragLimitContingencies, minSize); if (MVTContingencyFill(baseReturn, limitReturn, mvt, minSize)) @@ -739,6 +754,7 @@ static Bool MVTDeleteOverlapping(Bool *deleteReturn, void *element, AVER(deleteReturn != NULL); AVER(element != NULL); AVER(closureP != NULL); + AVER(closureS == UNUSED_SIZE); UNUSED(closureS); oldRange = element; @@ -784,8 +800,8 @@ static Bool MVTReserve(MVT mvt, Range range) } -/* MVTInsert -- insert an address range into the CBS (or the Freelist - * if that fails) and update the ABQ accordingly. +/* MVTInsert -- insert an address range into the free lists and update + * the ABQ accordingly. */ static Res MVTInsert(MVT mvt, Addr base, Addr limit) { @@ -794,18 +810,9 @@ static Res MVTInsert(MVT mvt, Addr base, Addr limit) AVERT(MVT, mvt); AVER(base < limit); - - /* Attempt to flush the Freelist to the CBS to give maximum - * opportunities for coalescence. */ - FreelistFlushToCBS(MVTFreelist(mvt), MVTCBS(mvt)); RangeInit(&range, base, limit); - res = CBSInsert(&newRange, MVTCBS(mvt), &range); - if (ResIsAllocFailure(res)) { - /* CBS ran out of memory for splay nodes: add range to emergency - * free list instead. */ - res = FreelistInsert(&newRange, MVTFreelist(mvt), &range); - } + res = LandInsert(&newRange, MVTFailover(mvt), &range); if (res != ResOK) return res; @@ -814,7 +821,7 @@ static Res MVTInsert(MVT mvt, Addr base, Addr limit) * with ranges on the ABQ, so ensure that the corresponding ranges * are coalesced on the ABQ. */ - ABQIterate(MVTABQ(mvt), MVTDeleteOverlapping, &newRange, 0); + ABQIterate(MVTABQ(mvt), MVTDeleteOverlapping, &newRange, UNUSED_SIZE); (void)MVTReserve(mvt, &newRange); } @@ -822,8 +829,8 @@ static Res MVTInsert(MVT mvt, Addr base, Addr limit) } -/* MVTDelete -- delete an address range from the CBS and the Freelist, - * and update the ABQ accordingly. +/* MVTDelete -- delete an address range from the free lists, and + * update the ABQ accordingly. */ static Res MVTDelete(MVT mvt, Addr base, Addr limit) { @@ -834,27 +841,7 @@ static Res MVTDelete(MVT mvt, Addr base, Addr limit) AVER(base < limit); RangeInit(&range, base, limit); - res = CBSDelete(&rangeOld, MVTCBS(mvt), &range); - if (ResIsAllocFailure(res)) { - /* CBS ran out of memory for splay nodes, which must mean that - * there were fragments on both sides: see - * . Handle this by - * deleting the whole of rangeOld (which requires no - * allocation) and re-inserting the fragments. */ - RangeStruct rangeOld2; - res = CBSDelete(&rangeOld2, MVTCBS(mvt), &rangeOld); - AVER(res == ResOK); - AVER(RangesEqual(&rangeOld2, &rangeOld)); - AVER(RangeBase(&rangeOld) != base); - res = MVTInsert(mvt, RangeBase(&rangeOld), base); - AVER(res == ResOK); - AVER(RangeLimit(&rangeOld) != limit); - res = MVTInsert(mvt, limit, RangeLimit(&rangeOld)); - AVER(res == ResOK); - } else if (res == ResFAIL) { - /* Not found in the CBS: try the Freelist. */ - res = FreelistDelete(&rangeOld, MVTFreelist(mvt), &range); - } + res = LandDelete(&rangeOld, MVTFailover(mvt), &range); if (res != ResOK) return res; AVER(RangesNest(&rangeOld, &range)); @@ -863,7 +850,7 @@ static Res MVTDelete(MVT mvt, Addr base, Addr limit) * might be on the ABQ, so ensure it is removed. */ if (RangeSize(&rangeOld) >= mvt->reuseSize) - ABQIterate(MVTABQ(mvt), MVTDeleteOverlapping, &rangeOld, 0); + ABQIterate(MVTABQ(mvt), MVTDeleteOverlapping, &rangeOld, UNUSED_SIZE); /* There might be fragments at the left or the right of the deleted * range, and either might be big enough to go back on the ABQ. @@ -1028,15 +1015,15 @@ static Res MVTDescribe(Pool pool, mps_lib_FILE *stream) NULL); if(res != ResOK) return res; - res = CBSDescribe(MVTCBS(mvt), stream); + res = LandDescribe(MVTCBS(mvt), stream); + if(res != ResOK) return res; + res = LandDescribe(MVTFreelist(mvt), stream); + if(res != ResOK) return res; + res = LandDescribe(MVTFailover(mvt), stream); if(res != ResOK) return res; - res = ABQDescribe(MVTABQ(mvt), (ABQDescribeElement)RangeDescribe, stream); if(res != ResOK) return res; - res = FreelistDescribe(MVTFreelist(mvt), stream); - if(res != ResOK) return res; - METER_WRITE(mvt->segAllocs, stream); METER_WRITE(mvt->segFrees, stream); METER_WRITE(mvt->bufferFills, stream); @@ -1213,13 +1200,20 @@ static Bool MVTReturnSegs(MVT mvt, Range range, Arena arena) } -/* MVTRefillCallback -- called from CBSIterate or FreelistIterate at - * the behest of MVTRefillABQIfEmpty +/* MVTRefillABQIfEmpty -- refill the ABQ from the free lists if it is + * empty. */ -static Bool MVTRefillCallback(MVT mvt, Range range) + +static Bool MVTRefillVisitor(Land land, Range range, + void *closureP, Size closureS) { - AVERT(ABQ, MVTABQ(mvt)); - AVERT(Range, range); + MVT mvt; + + AVERT(Land, land); + mvt = closureP; + AVERT(MVT, mvt); + AVER(closureS == UNUSED_SIZE); + UNUSED(closureS); if (RangeSize(range) < mvt->reuseSize) return TRUE; @@ -1228,80 +1222,54 @@ static Bool MVTRefillCallback(MVT mvt, Range range) return MVTReserve(mvt, range); } -static Bool MVTCBSRefillCallback(CBS cbs, Range range, - void *closureP, Size closureS) -{ - MVT mvt; - AVERT(CBS, cbs); - mvt = closureP; - AVERT(MVT, mvt); - UNUSED(closureS); - return MVTRefillCallback(mvt, range); -} - -static Bool MVTFreelistRefillCallback(Bool *deleteReturn, Range range, - void *closureP, Size closureS) -{ - MVT mvt; - mvt = closureP; - AVERT(MVT, mvt); - UNUSED(closureS); - AVER(deleteReturn != NULL); - *deleteReturn = FALSE; - return MVTRefillCallback(mvt, range); -} - -/* MVTRefillABQIfEmpty -- refill the ABQ from the CBS and the Freelist if - * it is empty - */ static void MVTRefillABQIfEmpty(MVT mvt, Size size) { AVERT(MVT, mvt); AVER(size > 0); /* If there have never been any overflows from the ABQ back to the - * CBS/Freelist, then there cannot be any blocks in the CBS/Freelist + * free lists, then there cannot be any blocks in the free lists * that are worth adding to the ABQ. So as an optimization, we don't * bother to look. */ if (mvt->abqOverflow && ABQIsEmpty(MVTABQ(mvt))) { mvt->abqOverflow = FALSE; METER_ACC(mvt->refills, size); - CBSIterate(MVTCBS(mvt), &MVTCBSRefillCallback, mvt, 0); - FreelistIterate(MVTFreelist(mvt), &MVTFreelistRefillCallback, mvt, 0); + /* The iteration stops if the ABQ overflows, so may finish or not. */ + (void)LandIterate(MVTFailover(mvt), MVTRefillVisitor, mvt, UNUSED_SIZE); } } -/* Closure for MVTContingencySearch */ -typedef struct MVTContigencyStruct *MVTContigency; +/* MVTContingencySearch -- search free lists for a block of a given size */ -typedef struct MVTContigencyStruct +typedef struct MVTContigencyClosureStruct { MVT mvt; - Bool found; RangeStruct range; Arena arena; Size min; /* meters */ Count steps; Count hardSteps; -} MVTContigencyStruct; +} MVTContigencyClosureStruct, *MVTContigencyClosure; - -/* MVTContingencyCallback -- called from CBSIterate or FreelistIterate - * at the behest of MVTContingencySearch. - */ -static Bool MVTContingencyCallback(MVTContigency cl, Range range) +static Bool MVTContingencyVisitor(Land land, Range range, + void *closureP, Size closureS) { MVT mvt; Size size; Addr base, limit; + MVTContigencyClosure cl; - AVER(cl != NULL); + AVERT(Land, land); + AVERT(Range, range); + AVER(closureP != NULL); + cl = closureP; mvt = cl->mvt; AVERT(MVT, mvt); - AVERT(Range, range); + AVER(closureS == UNUSED_SIZE); + UNUSED(closureS); base = RangeBase(range); limit = RangeLimit(range); @@ -1314,7 +1282,6 @@ static Bool MVTContingencyCallback(MVTContigency cl, Range range) /* verify that min will fit when seg-aligned */ if (size >= 2 * cl->min) { RangeInit(&cl->range, base, limit); - cl->found = TRUE; return FALSE; } @@ -1322,7 +1289,6 @@ static Bool MVTContingencyCallback(MVTContigency cl, Range range) cl->hardSteps++; if (MVTCheckFit(base, limit, cl->min, cl->arena)) { RangeInit(&cl->range, base, limit); - cl->found = TRUE; return FALSE; } @@ -1330,46 +1296,18 @@ static Bool MVTContingencyCallback(MVTContigency cl, Range range) return TRUE; } -static Bool MVTCBSContingencyCallback(CBS cbs, Range range, - void *closureP, Size closureS) -{ - MVTContigency cl = closureP; - UNUSED(cbs); - UNUSED(closureS); - return MVTContingencyCallback(cl, range); -} - -static Bool MVTFreelistContingencyCallback(Bool *deleteReturn, Range range, - void *closureP, Size closureS) -{ - MVTContigency cl = closureP; - UNUSED(closureS); - AVER(deleteReturn != NULL); - *deleteReturn = FALSE; - return MVTContingencyCallback(cl, range); -} - -/* MVTContingencySearch -- search the CBS and the Freelist for a block - * of size min */ - static Bool MVTContingencySearch(Addr *baseReturn, Addr *limitReturn, MVT mvt, Size min) { - MVTContigencyStruct cls; + MVTContigencyClosureStruct cls; cls.mvt = mvt; - cls.found = FALSE; cls.arena = PoolArena(MVT2Pool(mvt)); cls.min = min; cls.steps = 0; cls.hardSteps = 0; - FreelistFlushToCBS(MVTFreelist(mvt), MVTCBS(mvt)); - - CBSIterate(MVTCBS(mvt), MVTCBSContingencyCallback, (void *)&cls, 0); - FreelistIterate(MVTFreelist(mvt), MVTFreelistContingencyCallback, - (void *)&cls, 0); - if (!cls.found) + if (LandIterate(MVTFailover(mvt), MVTContingencyVisitor, &cls, UNUSED_SIZE)) return FALSE; AVER(RangeSize(&cls.range) >= min); @@ -1386,6 +1324,7 @@ static Bool MVTContingencySearch(Addr *baseReturn, Addr *limitReturn, /* MVTCheckFit -- verify that segment-aligned block of size min can * fit in a candidate address range. */ + static Bool MVTCheckFit(Addr base, Addr limit, Size min, Arena arena) { Seg seg; @@ -1415,12 +1354,10 @@ static Bool MVTCheckFit(Addr base, Addr limit, Size min, Arena arena) /* Return the CBS of an MVT pool for the benefit of fotest.c. */ -extern CBS _mps_mvt_cbs(mps_pool_t); -CBS _mps_mvt_cbs(mps_pool_t mps_pool) { - Pool pool; +extern Land _mps_mvt_cbs(Pool); +Land _mps_mvt_cbs(Pool pool) { MVT mvt; - pool = (Pool)mps_pool; AVERT(Pool, pool); mvt = Pool2MVT(pool); AVERT(MVT, mvt); diff --git a/mps/code/poolmvff.c b/mps/code/poolmvff.c index 3d569058697..7b1f435944c 100644 --- a/mps/code/poolmvff.c +++ b/mps/code/poolmvff.c @@ -21,6 +21,7 @@ #include "mpscmvff.h" #include "dbgpool.h" #include "cbs.h" +#include "failover.h" #include "freelist.h" #include "mpm.h" @@ -47,9 +48,9 @@ typedef struct MVFFStruct { /* MVFF pool outer structure */ Size minSegSize; /* minimum size of segment */ Size avgSize; /* client estimate of allocation size */ Size total; /* total bytes in pool */ - Size free; /* total free bytes in pool */ CBSStruct cbsStruct; /* free list */ FreelistStruct flStruct; /* emergency free list */ + FailoverStruct foStruct; /* fail-over mechanism */ Bool firstFit; /* as opposed to last fit */ Bool slotHigh; /* prefers high part of large block */ Sig sig; /* */ @@ -58,10 +59,9 @@ typedef struct MVFFStruct { /* MVFF pool outer structure */ #define Pool2MVFF(pool) PARENT(MVFFStruct, poolStruct, pool) #define MVFF2Pool(mvff) (&((mvff)->poolStruct)) -#define CBSOfMVFF(mvff) (&((mvff)->cbsStruct)) -#define MVFFOfCBS(cbs) PARENT(MVFFStruct, cbsStruct, cbs) -#define FreelistOfMVFF(mvff) (&((mvff)->flStruct)) -#define MVFFOfFreelist(fl) PARENT(MVFFStruct, flStruct, fl) +#define CBSOfMVFF(mvff) (&((mvff)->cbsStruct.landStruct)) +#define FreelistOfMVFF(mvff) (&((mvff)->flStruct.landStruct)) +#define FailoverOfMVFF(mvff) (&((mvff)->foStruct.landStruct)) static Bool MVFFCheck(MVFF mvff); @@ -80,48 +80,29 @@ typedef MVFFDebugStruct *MVFFDebug; #define MVFFDebug2MVFF(mvffd) (&((mvffd)->mvffStruct)) -/* MVFFAddToFreeList -- Add given range to free list +/* MVFFInsert -- add given range to free lists * - * Updates MVFF counters for additional free space. Returns maximally - * coalesced range containing given range. Does not attempt to free - * segments (see MVFFFreeSegs). + * Updates rangeIO to be maximally coalesced range containing given + * range. Does not attempt to free segments (see MVFFFreeSegs). */ -static Res MVFFAddToFreeList(Addr *baseIO, Addr *limitIO, MVFF mvff) { - Res res; - RangeStruct range, newRange; - - AVER(baseIO != NULL); - AVER(limitIO != NULL); +static Res MVFFInsert(Range rangeIO, MVFF mvff) { + AVERT(Range, rangeIO); AVERT(MVFF, mvff); - RangeInit(&range, *baseIO, *limitIO); - res = CBSInsert(&newRange, CBSOfMVFF(mvff), &range); - if (ResIsAllocFailure(res)) { - /* CBS ran out of memory for splay nodes: add range to emergency - * free list instead. */ - res = FreelistInsert(&newRange, FreelistOfMVFF(mvff), &range); - } - - if (res == ResOK) { - mvff->free += RangeSize(&range); - *baseIO = RangeBase(&newRange); - *limitIO = RangeLimit(&newRange); - } - - return res; + return LandInsert(rangeIO, FailoverOfMVFF(mvff), rangeIO); } -/* MVFFFreeSegs -- Free segments from given range +/* MVFFFreeSegs -- free segments from given range * - * Given a free range, attempts to find entire segments within - * it, and returns them to the arena, updating total size counter. + * Given a free range, attempts to find entire segments within it, and + * returns them to the arena, updating total size counter. * - * This is usually called immediately after MVFFAddToFreeList. - * It is not combined with MVFFAddToFreeList because the latter - * is also called when new segments are added under MVFFAlloc. + * This is usually called immediately after MVFFInsert. It is not + * combined with MVFFInsert because the latter is also called when new + * segments are added under MVFFAlloc. */ -static void MVFFFreeSegs(MVFF mvff, Addr base, Addr limit) +static void MVFFFreeSegs(MVFF mvff, Range range) { Seg seg = NULL; /* suppress "may be used uninitialized" */ Arena arena; @@ -131,72 +112,42 @@ static void MVFFFreeSegs(MVFF mvff, Addr base, Addr limit) Res res; AVERT(MVFF, mvff); - AVER(base < limit); + AVERT(Range, range); /* Could profitably AVER that the given range is free, */ /* but the CBS doesn't provide that facility. */ - if (AddrOffset(base, limit) < mvff->minSegSize) + if (RangeSize(range) < mvff->minSegSize) return; /* not large enough for entire segments */ arena = PoolArena(MVFF2Pool(mvff)); - b = SegOfAddr(&seg, arena, base); + b = SegOfAddr(&seg, arena, RangeBase(range)); AVER(b); segBase = SegBase(seg); segLimit = SegLimit(seg); - while(segLimit <= limit) { /* segment ends in range */ - if (segBase >= base) { /* segment starts in range */ - RangeStruct range, oldRange; - RangeInit(&range, segBase, segLimit); - - res = CBSDelete(&oldRange, CBSOfMVFF(mvff), &range); - if (res == ResOK) { - mvff->free -= RangeSize(&range); - } else if (ResIsAllocFailure(res)) { - /* CBS ran out of memory for splay nodes, which must mean that - * there were fragments on both sides: see - * . Handle this by - * deleting the whole of oldRange (which requires no - * allocation) and re-inserting the fragments. */ - RangeStruct oldRange2; - res = CBSDelete(&oldRange2, CBSOfMVFF(mvff), &oldRange); - AVER(res == ResOK); - AVER(RangesEqual(&oldRange2, &oldRange)); - mvff->free -= RangeSize(&oldRange); - AVER(RangeBase(&oldRange) != segBase); - { - Addr leftBase = RangeBase(&oldRange); - Addr leftLimit = segBase; - res = MVFFAddToFreeList(&leftBase, &leftLimit, mvff); - } - AVER(RangeLimit(&oldRange) != segLimit); - { - Addr rightBase = segLimit; - Addr rightLimit = RangeLimit(&oldRange); - res = MVFFAddToFreeList(&rightBase, &rightLimit, mvff); - } - } else if (res == ResFAIL) { - /* Not found in the CBS: must be found in the Freelist. */ - res = FreelistDelete(&oldRange, FreelistOfMVFF(mvff), &range); - AVER(res == ResOK); - mvff->free -= RangeSize(&range); - } + while(segLimit <= RangeLimit(range)) { /* segment ends in range */ + if (segBase >= RangeBase(range)) { /* segment starts in range */ + RangeStruct delRange, oldRange; + RangeInit(&delRange, segBase, segLimit); + res = LandDelete(&oldRange, FailoverOfMVFF(mvff), &delRange); AVER(res == ResOK); - AVER(RangesNest(&oldRange, &range)); + AVER(RangesNest(&oldRange, &delRange)); /* Can't free the segment earlier, because if it was on the * Freelist rather than the CBS then it likely contains data * that needs to be read in order to update the Freelist. */ SegFree(seg); - mvff->total -= RangeSize(&range); + + AVER(mvff->total >= RangeSize(&delRange)); + mvff->total -= RangeSize(&delRange); } /* Avoid calling SegNext if the next segment would fail */ /* the loop test, mainly because there might not be a */ /* next segment. */ - if (segLimit == limit) /* segment ends at end of range */ + if (segLimit == RangeLimit(range)) /* segment ends at end of range */ break; b = SegFindAboveAddr(&seg, arena, segBase); @@ -212,8 +163,8 @@ static void MVFFFreeSegs(MVFF mvff, Addr base, Addr limit) /* MVFFAddSeg -- Allocates a new segment from the arena * * Allocates a new segment from the arena (with the given - * withReservoirPermit flag) of at least the specified size. The - * specified size should be pool-aligned. Adds it to the free list. + * withReservoirPermit flag) of at least the specified size. The + * specified size should be pool-aligned. Adds it to the free lists. */ static Res MVFFAddSeg(Seg *segReturn, MVFF mvff, Size size, Bool withReservoirPermit) @@ -224,7 +175,7 @@ static Res MVFFAddSeg(Seg *segReturn, Seg seg; Res res; Align align; - Addr base, limit; + RangeStruct range; AVERT(MVFF, mvff); AVER(size > 0); @@ -259,12 +210,11 @@ static Res MVFFAddSeg(Seg *segReturn, } mvff->total += segSize; - base = SegBase(seg); - limit = AddrAdd(base, segSize); - DebugPoolFreeSplat(pool, base, limit); - res = MVFFAddToFreeList(&base, &limit, mvff); + RangeInitSize(&range, SegBase(seg), segSize); + DebugPoolFreeSplat(pool, RangeBase(&range), RangeLimit(&range)); + res = MVFFInsert(&range, mvff); AVER(res == ResOK); - AVER(base <= SegBase(seg)); + AVER(RangeBase(&range) <= SegBase(seg)); if (mvff->minSegSize > segSize) mvff->minSegSize = segSize; /* Don't call MVFFFreeSegs; that would be silly. */ @@ -274,50 +224,32 @@ static Res MVFFAddSeg(Seg *segReturn, } -/* MVFFFindFirstFree -- Finds the first (or last) suitable free block +/* MVFFFindFree -- find the first (or last) suitable free block * * Finds a free block of the given (pool aligned) size, according * to a first (or last) fit policy controlled by the MVFF fields * firstFit, slotHigh (for whether to allocate the top or bottom * portion of a larger block). * - * Will return FALSE if the free list has no large enough block. - * In particular, will not attempt to allocate a new segment. + * Will return FALSE if the free lists have no large enough block. In + * particular, will not attempt to allocate a new segment. */ -static Bool MVFFFindFirstFree(Addr *baseReturn, Addr *limitReturn, - MVFF mvff, Size size) +static Bool MVFFFindFree(Range rangeReturn, MVFF mvff, Size size) { Bool foundBlock; FindDelete findDelete; - RangeStruct range, oldRange; + RangeStruct oldRange; - AVER(baseReturn != NULL); - AVER(limitReturn != NULL); + AVER(rangeReturn != NULL); AVERT(MVFF, mvff); AVER(size > 0); AVER(SizeIsAligned(size, PoolAlignment(MVFF2Pool(mvff)))); - FreelistFlushToCBS(FreelistOfMVFF(mvff), CBSOfMVFF(mvff)); - findDelete = mvff->slotHigh ? FindDeleteHIGH : FindDeleteLOW; foundBlock = - (mvff->firstFit ? CBSFindFirst : CBSFindLast) - (&range, &oldRange, CBSOfMVFF(mvff), size, findDelete); - - if (!foundBlock) { - /* Failed to find a block in the CBS: try the emergency free list - * as well. */ - foundBlock = - (mvff->firstFit ? FreelistFindFirst : FreelistFindLast) - (&range, &oldRange, FreelistOfMVFF(mvff), size, findDelete); - } - - if (foundBlock) { - *baseReturn = RangeBase(&range); - *limitReturn = RangeLimit(&range); - mvff->free -= size; - } + (mvff->firstFit ? LandFindFirst : LandFindLast) + (rangeReturn, &oldRange, FailoverOfMVFF(mvff), size, findDelete); return foundBlock; } @@ -330,7 +262,7 @@ static Res MVFFAlloc(Addr *aReturn, Pool pool, Size size, { Res res; MVFF mvff; - Addr base, limit; + RangeStruct range; Bool foundBlock; AVERT(Pool, pool); @@ -343,29 +275,28 @@ static Res MVFFAlloc(Addr *aReturn, Pool pool, Size size, size = SizeAlignUp(size, PoolAlignment(pool)); - foundBlock = MVFFFindFirstFree(&base, &limit, mvff, size); + foundBlock = MVFFFindFree(&range, mvff, size); if (!foundBlock) { Seg seg; res = MVFFAddSeg(&seg, mvff, size, withReservoirPermit); if (res != ResOK) return res; - foundBlock = MVFFFindFirstFree(&base, &limit, mvff, size); + foundBlock = MVFFFindFree(&range, mvff, size); /* We know that the found range must intersect the new segment. */ /* In particular, it doesn't necessarily lie entirely within it. */ - /* The next three AVERs test for intersection of two intervals. */ - AVER(base >= SegBase(seg) || limit <= SegLimit(seg)); - AVER(base < SegLimit(seg)); - AVER(SegBase(seg) < limit); + /* The next two AVERs test for intersection of two intervals. */ + AVER(RangeBase(&range) < SegLimit(seg)); + AVER(SegBase(seg) < RangeLimit(&range)); /* We also know that the found range is no larger than the segment. */ - AVER(SegSize(seg) >= AddrOffset(base, limit)); + AVER(SegSize(seg) >= RangeSize(&range)); } AVER(foundBlock); - AVER(AddrOffset(base, limit) == size); + AVER(RangeSize(&range) == size); - *aReturn = base; + *aReturn = RangeBase(&range); return ResOK; } @@ -376,7 +307,7 @@ static Res MVFFAlloc(Addr *aReturn, Pool pool, Size size, static void MVFFFree(Pool pool, Addr old, Size size) { Res res; - Addr base, limit; + RangeStruct range; MVFF mvff; AVERT(Pool, pool); @@ -387,42 +318,16 @@ static void MVFFFree(Pool pool, Addr old, Size size) AVER(AddrIsAligned(old, PoolAlignment(pool))); AVER(size > 0); - size = SizeAlignUp(size, PoolAlignment(pool)); - base = old; - limit = AddrAdd(base, size); + RangeInitSize(&range, old, SizeAlignUp(size, PoolAlignment(pool))); - res = MVFFAddToFreeList(&base, &limit, mvff); + res = MVFFInsert(&range, mvff); AVER(res == ResOK); if (res == ResOK) - MVFFFreeSegs(mvff, base, limit); + MVFFFreeSegs(mvff, &range); return; } -/* MVFFFindLargest -- call CBSFindLargest and then fall back to - * FreelistFindLargest if no block in the CBS was big enough. */ - -static Bool MVFFFindLargest(Range range, Range oldRange, MVFF mvff, - Size size, FindDelete findDelete) -{ - AVER(range != NULL); - AVER(oldRange != NULL); - AVERT(MVFF, mvff); - AVER(size > 0); - AVERT(FindDelete, findDelete); - - FreelistFlushToCBS(FreelistOfMVFF(mvff), CBSOfMVFF(mvff)); - - if (CBSFindLargest(range, oldRange, CBSOfMVFF(mvff), size, findDelete)) - return TRUE; - - if (FreelistFindLargest(range, oldRange, FreelistOfMVFF(mvff), - size, findDelete)) - return TRUE; - - return FALSE; -} - /* MVFFBufferFill -- Fill the buffer * @@ -447,18 +352,17 @@ static Res MVFFBufferFill(Addr *baseReturn, Addr *limitReturn, AVER(SizeIsAligned(size, PoolAlignment(pool))); AVERT(Bool, withReservoirPermit); - found = MVFFFindLargest(&range, &oldRange, mvff, size, FindDeleteENTIRE); + found = LandFindLargest(&range, &oldRange, FailoverOfMVFF(mvff), size, FindDeleteENTIRE); if (!found) { - /* Add a new segment to the free list and try again. */ + /* Add a new segment to the free lists and try again. */ res = MVFFAddSeg(&seg, mvff, size, withReservoirPermit); if (res != ResOK) return res; - found = MVFFFindLargest(&range, &oldRange, mvff, size, FindDeleteENTIRE); + found = LandFindLargest(&range, &oldRange, FailoverOfMVFF(mvff), size, FindDeleteENTIRE); } AVER(found); AVER(RangeSize(&range) >= size); - mvff->free -= RangeSize(&range); *baseReturn = RangeBase(&range); *limitReturn = RangeLimit(&range); @@ -473,21 +377,22 @@ static void MVFFBufferEmpty(Pool pool, Buffer buffer, { Res res; MVFF mvff; + RangeStruct range; AVERT(Pool, pool); mvff = Pool2MVFF(pool); AVERT(MVFF, mvff); AVERT(Buffer, buffer); AVER(BufferIsReady(buffer)); - AVER(base <= limit); + RangeInit(&range, base, limit); - if (base == limit) + if (RangeIsEmpty(&range)) return; - res = MVFFAddToFreeList(&base, &limit, mvff); + res = MVFFInsert(&range, mvff); AVER(res == ResOK); if (res == ResOK) - MVFFFreeSegs(mvff, base, limit); + MVFFFreeSegs(mvff, &range); return; } @@ -596,16 +501,25 @@ static Res MVFFInit(Pool pool, ArgList args) SegPrefExpress(mvff->segPref, arenaHigh ? SegPrefHigh : SegPrefLow, NULL); mvff->total = 0; - mvff->free = 0; - res = FreelistInit(FreelistOfMVFF(mvff), align); + res = LandInit(FreelistOfMVFF(mvff), FreelistLandClassGet(), arena, align, + mvff, mps_args_none); if (res != ResOK) - goto failInit; + goto failFreelistInit; - res = CBSInit(CBSOfMVFF(mvff), arena, (void *)mvff, align, - /* fastFind */ TRUE, /* zoned */ FALSE, args); + res = LandInit(CBSOfMVFF(mvff), CBSFastLandClassGet(), arena, align, mvff, + mps_args_none); if (res != ResOK) - goto failInit; + goto failCBSInit; + + MPS_ARGS_BEGIN(foArgs) { + MPS_ARGS_ADD(foArgs, FailoverPrimary, CBSOfMVFF(mvff)); + MPS_ARGS_ADD(foArgs, FailoverSecondary, FreelistOfMVFF(mvff)); + res = LandInit(FailoverOfMVFF(mvff), FailoverLandClassGet(), arena, align, + mvff, foArgs); + } MPS_ARGS_END(foArgs); + if (res != ResOK) + goto failFailoverInit; mvff->sig = MVFFSig; AVERT(MVFF, mvff); @@ -613,7 +527,11 @@ static Res MVFFInit(Pool pool, ArgList args) BOOLOF(slotHigh), BOOLOF(arenaHigh), BOOLOF(firstFit)); return ResOK; -failInit: +failFailoverInit: + LandFinish(CBSOfMVFF(mvff)); +failCBSInit: + LandFinish(FreelistOfMVFF(mvff)); +failFreelistInit: ControlFree(arena, p, sizeof(SegPrefStruct)); return res; } @@ -625,7 +543,6 @@ static void MVFFFinish(Pool pool) { MVFF mvff; Arena arena; - Seg seg; Ring ring, node, nextNode; AVERT(Pool, pool); @@ -634,20 +551,24 @@ static void MVFFFinish(Pool pool) ring = PoolSegRing(pool); RING_FOR(node, ring, nextNode) { + Size size; + Seg seg; seg = SegOfPoolRing(node); AVER(SegPool(seg) == pool); + size = AddrOffset(SegBase(seg), SegLimit(seg)); + AVER(size <= mvff->total); + mvff->total -= size; SegFree(seg); } - /* Could maintain mvff->total here and check it falls to zero, */ - /* but that would just make the function slow. If only we had */ - /* a way to do operations only if AVERs are turned on. */ + AVER(mvff->total == 0); arena = PoolArena(pool); ControlFree(arena, mvff->segPref, sizeof(SegPrefStruct)); - CBSFinish(CBSOfMVFF(mvff)); - FreelistFinish(FreelistOfMVFF(mvff)); + LandFinish(FailoverOfMVFF(mvff)); + LandFinish(FreelistOfMVFF(mvff)); + LandFinish(CBSOfMVFF(mvff)); mvff->sig = SigInvalid; } @@ -686,16 +607,15 @@ static Res MVFFDescribe(Pool pool, mps_lib_FILE *stream) " extendBy $W\n", (WriteFW)mvff->extendBy, " avgSize $W\n", (WriteFW)mvff->avgSize, " total $U\n", (WriteFU)mvff->total, - " free $U\n", (WriteFU)mvff->free, NULL); if (res != ResOK) return res; - res = CBSDescribe(CBSOfMVFF(mvff), stream); + res = LandDescribe(CBSOfMVFF(mvff), stream); if (res != ResOK) return res; - res = FreelistDescribe(FreelistOfMVFF(mvff), stream); + res = LandDescribe(FreelistOfMVFF(mvff), stream); if (res != ResOK) return res; @@ -764,13 +684,15 @@ size_t mps_mvff_free_size(mps_pool_t mps_pool) { Pool pool; MVFF mvff; + Land land; pool = (Pool)mps_pool; AVERT(Pool, pool); mvff = Pool2MVFF(pool); AVERT(MVFF, mvff); + land = FailoverOfMVFF(mvff); - return (size_t)mvff->free; + return (size_t)LandSize(land); } /* Total owned bytes. See */ @@ -802,11 +724,11 @@ static Bool MVFFCheck(MVFF mvff) CHECKL(mvff->minSegSize >= ArenaAlign(PoolArena(MVFF2Pool(mvff)))); CHECKL(mvff->avgSize > 0); /* see .arg.check */ CHECKL(mvff->avgSize <= mvff->extendBy); /* see .arg.check */ - CHECKL(mvff->total >= mvff->free); - CHECKL(SizeIsAligned(mvff->free, PoolAlignment(MVFF2Pool(mvff)))); CHECKL(SizeIsAligned(mvff->total, ArenaAlign(PoolArena(MVFF2Pool(mvff))))); - CHECKD(CBS, CBSOfMVFF(mvff)); - CHECKD(Freelist, FreelistOfMVFF(mvff)); + CHECKD(CBS, &mvff->cbsStruct); + CHECKD(Freelist, &mvff->flStruct); + CHECKD(Failover, &mvff->foStruct); + CHECKL(mvff->total >= LandSize(FailoverOfMVFF(mvff))); CHECKL(BoolCheck(mvff->slotHigh)); CHECKL(BoolCheck(mvff->firstFit)); return TRUE; @@ -815,12 +737,10 @@ static Bool MVFFCheck(MVFF mvff) /* Return the CBS of an MVFF pool for the benefit of fotest.c. */ -extern CBS _mps_mvff_cbs(mps_pool_t); -CBS _mps_mvff_cbs(mps_pool_t mps_pool) { - Pool pool; +extern Land _mps_mvff_cbs(Pool); +Land _mps_mvff_cbs(Pool pool) { MVFF mvff; - pool = (Pool)mps_pool; AVERT(Pool, pool); mvff = Pool2MVFF(pool); AVERT(MVFF, mvff); diff --git a/mps/code/range.c b/mps/code/range.c index b54a001db2f..1c7f297c46d 100644 --- a/mps/code/range.c +++ b/mps/code/range.c @@ -15,7 +15,6 @@ SRCID(range, "$Id$"); Bool RangeCheck(Range range) { - CHECKS(Range, range); CHECKL(range->base <= range->limit); return TRUE; @@ -29,14 +28,17 @@ void RangeInit(Range range, Addr base, Addr limit) range->base = base; range->limit = limit; - range->sig = RangeSig; AVERT(Range, range); } +void RangeInitSize(Range range, Addr base, Size size) +{ + RangeInit(range, base, AddrAdd(base, size)); +} + void RangeFinish(Range range) { AVERT(Range, range); - range->sig = SigInvalid; } Res RangeDescribe(Range range, mps_lib_FILE *stream) diff --git a/mps/code/range.h b/mps/code/range.h index 0ff105f7f20..c6fd41bad5e 100644 --- a/mps/code/range.h +++ b/mps/code/range.h @@ -14,15 +14,8 @@ #include "mpmtypes.h" -/* Signatures */ - -#define RangeSig ((Sig)0x5196A493) /* SIGnature RANGE */ - - /* Prototypes */ -typedef struct RangeStruct *Range; - #define RangeBase(range) ((range)->base) #define RangeLimit(range) ((range)->limit) #define RangeSize(range) (AddrOffset(RangeBase(range), RangeLimit(range))) @@ -30,6 +23,7 @@ typedef struct RangeStruct *Range; #define RangeIsEmpty(range) (RangeSize(range) == 0) extern void RangeInit(Range range, Addr base, Addr limit); +extern void RangeInitSize(Range range, Addr base, Size size); extern void RangeFinish(Range range); extern Res RangeDescribe(Range range, mps_lib_FILE *stream); extern Bool RangeCheck(Range range); @@ -46,7 +40,6 @@ extern void RangeCopy(Range to, Range from); /* Types */ typedef struct RangeStruct { - Sig sig; Addr base; Addr limit; } RangeStruct; diff --git a/mps/code/splay.c b/mps/code/splay.c index 7e061cd14f4..1b0e8afb8fd 100644 --- a/mps/code/splay.c +++ b/mps/code/splay.c @@ -945,13 +945,12 @@ Bool SplayTreeNeighbours(Tree *leftReturn, Tree *rightReturn, /* SplayTreeFirst, SplayTreeNext -- iterators * - * SplayTreeFirst receives a key that must precede all - * nodes in the tree. It returns TreeEMPTY if the tree is empty. - * Otherwise, it splays the tree to the first node, and returns the - * new root. + * SplayTreeFirst returns TreeEMPTY if the tree is empty. Otherwise, + * it splays the tree to the first node, and returns the new root. * * SplayTreeNext takes a tree and splays it to the successor of a key - * and returns the new root. Returns TreeEMPTY is there are no successors. + * and returns the new root. Returns TreeEMPTY is there are no + * successors. * * SplayTreeFirst and SplayTreeNext do not require the tree to remain * unmodified. @@ -1006,7 +1005,7 @@ Tree SplayTreeNext(SplayTree splay, TreeKey oldKey) { */ static Res SplayNodeDescribe(Tree node, mps_lib_FILE *stream, - SplayNodeDescribeMethod nodeDescribe) { + TreeDescribeMethod nodeDescribe) { Res res; #if defined(AVER_AND_CHECK) @@ -1318,13 +1317,27 @@ void SplayNodeRefresh(SplayTree splay, Tree node) } +/* SplayNodeInit -- initialize client property without splaying */ + +void SplayNodeInit(SplayTree splay, Tree node) +{ + AVERT(SplayTree, splay); + AVERT(Tree, node); + AVER(!TreeHasLeft(node)); /* otherwise, call SplayNodeRefresh */ + AVER(!TreeHasRight(node)); /* otherwise, call SplayNodeRefresh */ + AVER(SplayHasUpdate(splay)); /* otherwise, why call? */ + + splay->updateNode(splay, node); +} + + /* SplayTreeDescribe -- Describe a splay tree * * See . */ Res SplayTreeDescribe(SplayTree splay, mps_lib_FILE *stream, - SplayNodeDescribeMethod nodeDescribe) { + TreeDescribeMethod nodeDescribe) { Res res; #if defined(AVER_AND_CHECK) diff --git a/mps/code/splay.h b/mps/code/splay.h index 86f7f470482..24b97c4b055 100644 --- a/mps/code/splay.h +++ b/mps/code/splay.h @@ -19,7 +19,6 @@ typedef Bool (*SplayTestNodeMethod)(SplayTree splay, Tree node, void *closureP, Size closureS); typedef Bool (*SplayTestTreeMethod)(SplayTree splay, Tree node, void *closureP, Size closureS); -typedef Res (*SplayNodeDescribeMethod)(Tree node, mps_lib_FILE *stream); typedef void (*SplayUpdateNodeMethod)(SplayTree splay, Tree node); extern void SplayTrivUpdate(SplayTree splay, Tree node); @@ -70,9 +69,10 @@ extern Bool SplayFindLast(Tree *nodeReturn, SplayTree splay, void *closureP, Size closureS); extern void SplayNodeRefresh(SplayTree splay, Tree node); +extern void SplayNodeInit(SplayTree splay, Tree node); extern Res SplayTreeDescribe(SplayTree splay, mps_lib_FILE *stream, - SplayNodeDescribeMethod nodeDescribe); + TreeDescribeMethod nodeDescribe); extern void SplayDebugUpdate(SplayTree splay, Tree tree); diff --git a/mps/code/tract.c b/mps/code/tract.c index 2468887bc17..5ca5ab6f040 100644 --- a/mps/code/tract.c +++ b/mps/code/tract.c @@ -210,25 +210,25 @@ Res ChunkInit(Chunk chunk, Arena arena, /* Add the chunk's free address space to the arena's freeCBS, so that we can allocate from it. */ - if (arena->hasFreeCBS) { - res = ArenaFreeCBSInsert(arena, - PageIndexBase(chunk, chunk->allocBase), - chunk->limit); + if (arena->hasFreeLand) { + res = ArenaFreeLandInsert(arena, + PageIndexBase(chunk, chunk->allocBase), + chunk->limit); if (res != ResOK) - goto failCBSInsert; + goto failLandInsert; } chunk->sig = ChunkSig; AVERT(Chunk, chunk); /* As part of the bootstrap, the first created chunk becomes the primary - chunk. This step allows AreaFreeCBSInsert to allocate pages. */ + chunk. This step allows AreaFreeLandInsert to allocate pages. */ if (arena->primary == NULL) arena->primary = chunk; return ResOK; -failCBSInsert: +failLandInsert: (arena->class->chunkFinish)(chunk); /* .no-clean: No clean-ups needed past this point for boot, as we will discard the chunk. */ @@ -248,10 +248,10 @@ void ChunkFinish(Chunk chunk) chunk->sig = SigInvalid; RingRemove(&chunk->chunkRing); - if (ChunkArena(chunk)->hasFreeCBS) - ArenaFreeCBSDelete(ChunkArena(chunk), - PageIndexBase(chunk, chunk->allocBase), - chunk->limit); + if (ChunkArena(chunk)->hasFreeLand) + ArenaFreeLandDelete(ChunkArena(chunk), + PageIndexBase(chunk, chunk->allocBase), + chunk->limit); if (chunk->arena->primary == chunk) chunk->arena->primary = NULL; diff --git a/mps/code/tree.h b/mps/code/tree.h index 69ee841d3c3..5d9a6206670 100644 --- a/mps/code/tree.h +++ b/mps/code/tree.h @@ -25,6 +25,8 @@ typedef struct TreeStruct { Tree left, right; } TreeStruct; +typedef Res (*TreeDescribeMethod)(Tree tree, mps_lib_FILE *stream); + /* TreeKey and TreeCompare -- ordered binary trees * diff --git a/mps/design/cbs.txt b/mps/design/cbs.txt index 3168c7f472d..496cc5ea246 100644 --- a/mps/design/cbs.txt +++ b/mps/design/cbs.txt @@ -20,7 +20,10 @@ eager coalescence. _`.readership`: This document is intended for any MM developer. -_`.source`: design.mps.poolmv2, design.mps.poolmvff. +_`.source`: design.mps.poolmvt_, design.mps.poolmvff_. + +.. _design.mps.poolmvt: poolmvt +.. _design.mps.poolmvff: poolmvff _`.overview`: The "coalescing block structure" is a set of addresses (or a subset of address space), with provision for efficient @@ -29,50 +32,27 @@ high level communication with the client about the size of contiguous ranges, and detection of protocol violations. -Definitions ------------ - -_`.def.range`: A (contiguous) *range* of addresses is a semi-open -interval on address space. - -_`.def.isolated`: A contiguous range is *isolated* with respect to -some property it has, if adjacent elements do not have that property. - - Requirements ------------ -_`.req.set`: Must maintain a set of addresses. +In addition to the generic land requirements (see +design.mps.land_), the CBS must satisfy: + +.. _design.mps.land: land _`.req.fast`: Common operations must have a low amortized cost. -_`.req.add`: Must be able to add address ranges to the set. - -_`.req.remove`: Must be able to remove address ranges from the set. - -_`.req.size`: Must report concisely to the client when isolated -contiguous ranges of at least a certain size appear and disappear. - -_`.req.iterate`: Must support the iteration of all isolated -contiguous ranges. This will not be a common operation. - -_`.req.protocol`: Must detect protocol violations. - -_`.req.debug`: Must support debugging of client code. - _`.req.small`: Must have a small space overhead for the storage of typical subsets of address space and not have abysmal overhead for the storage of any subset of address space. -_`.req.align`: Must support an alignment (the alignment of all -addresses specifying ranges) of down to ``sizeof(void *)`` without -losing memory. - Interface --------- -_`.header`: CBS is used through impl.h.cbs. +_`.land`: CBS is an implementation of the *land* abstract data type, +so the interface consists of the generic functions for lands. See +design.mps.land_. External types @@ -80,180 +60,111 @@ External types ``typedef struct CBSStruct *CBS`` -_`.type.cbs`: ``CBS`` is the main data structure for manipulating a -CBS. It is intended that a ``CBSStruct`` be embedded in another -structure. No convenience functions are provided for the allocation or -deallocation of the CBS. - -``typedef Bool (*CBSIterateMethod)(CBS cbs, Range range, void *closureP, Size closureS)`` - -_`.type.cbs.iterate.method`: Type ``CBSIterateMethod`` is a callback -function that may be passed to ``CBSIterate()``. It is called for -every isolated contiguous range in address order. The function must -returns a ``Bool`` indicating whether to continue with the iteration. +_`.type.cbs`: The type of coalescing block structures. A ``CBSStruct`` +may be embedded in another structure, or you can create it using +``LandCreate()``. External functions .................. -``Res CBSInit(Arena arena, CBS cbs, void *owner, Align alignment, Bool fastFind, ArgList args)`` +``LandClass CBSLandClassGet(void)`` -_`.function.cbs.init`: ``CBSInit()`` is the function that initialises -the CBS structure. It performs allocation in the supplied arena. The -parameter ``owner`` is passed to ``MeterInit()``, an ``alignment`` -indicates the alignment of ranges to be maintained. An initialised CBS -contains no ranges. +_`.function.class`: The function ``CBSLandClassGet()`` returns the CBS +class, a subclass of ``LandClass`` suitable for passing to +``LandCreate()`` or ``LandInit()``. -``fastFind``, if set, causes the CBS to maintain, for each subtree, -the size of the largest block in that subtree. This must be true if -any of the ``CBSFindFirst()``, ``CBSFindLast()``, or -``CBSFindLargest()`` functions are going to be used on the CBS. +``LandClass CBSFastLandClassGet(void)`` -``CBSInit()`` may take one keyword argument: +_`.function.class`: Returns a subclass of ``CBSLandClass`` that +maintains, for each subtree, the size of the largest block in that +subtree. This enables the ``LandFindFirst()``, ``LandFindLast()``, and +``LandFindLargest()`` generic functions. -* ``MPS_KEY_CBS_EXTEND_BY`` (type ``Size``; default 4096) is the size - of segment that the CBS will request from the arena in which to - allocate its ``CBSBlock`` structures. +``LandClass CBSZonedLandClassGet(void)`` -``void CBSFinish(CBS cbs)`` - -_`.function.cbs.finish`: ``CBSFinish()`` is the function that finishes -the CBS structure and discards any other resources associated with the -CBS. - -``Res CBSInsert(Range rangeReturn, CBS cbs, Range range)`` - -_`.function.cbs.insert`: If any part of ``range`` is already in the -CBS, then leave it unchanged and return ``ResFAIL``. Otherwise, -attempt to insert ``range`` into the CBS. If the insertion succeeds, -then update ``rangeReturn`` to describe the contiguous isolated range -containing the inserted range (this may differ from ``range`` if there -was coalescence on either side) and return ``ResOK``. If the insertion -fails, return a result code indicating allocation failure. - -_`.function.cbs.insert.fail`: Insertion of a valid range (that is, one -that does not overlap with any range in the CBS) can only fail if the -new range is isolated and the allocation of the necessary data -structure to represent it failed. +_`.function.class`: Returns a subclass of ``CBSFastLandClass`` that +maintains, for each subtree, the union of the zone sets of all ranges +in that subtree. This enables the ``LandFindInZones()`` generic +function. -``Res CBSDelete(Range rangeReturn, CBS cbs, Range range)`` -_`.function.cbs.delete`: If any part of the range is not in the CBS, -then leave the CBS unchanged and return ``ResFAIL``. Otherwise, update -``rangeReturn`` to describe the contiguous isolated range that -contains ``range`` (this may differ from ``range`` if there are -fragments on either side) and attempt to delete the range from the -CBS. If the deletion succeeds, return ``ResOK``. If the deletion -fails, return a result code indicating allocation failure. +Keyword arguments +................. -_`.function.cbs.delete.fail`: Deletion of a valid range (that is, one -that is wholly contained in the CBS) can only fail if there are -fragments on both sides and the allocation of the necessary data -structures to represent them fails. +When initializing a CBS, ``LandCreate()`` and ``LandInit()`` take the +following optional keyword arguments: -_`.function.cbs.delete.return`: ``CBSDelete()`` returns the contiguous -isolated range that contains ``range`` even if the deletion fails. -This is so that the caller can try deleting the whole block (which is -guaranteed to succeed) and managing the fragments using a fallback -strategy. +* ``CBSBlockPool`` (type ``Pool``) is the pool from which the CBS + block descriptors will be allocated. If omitted, a new MFS pool is + created for this purpose. -``void CBSIterate(CBS cbs, CBSIterateMethod iterate, void *closureP, Size closureS)`` +* ``MPS_KEY_CBS_EXTEND_BY`` (type ``Size``; default 4096) is passed as + the ``MPS_KEY_EXTEND_BY`` keyword argument to ``PoolCreate()`` if a + block descriptor pool is created. It specifies the size of segment + that the block descriptor pool will request from the arena. -_`.function.cbs.iterate`: ``CBSIterate()`` is the function used to -iterate all isolated contiguous ranges in a CBS. It receives a -pointer, ``Size`` closure pair to pass on to the iterator method, -and an iterator method to invoke on every range in address order. If -the iterator method returns ``FALSE``, then the iteration is -terminated. +* ``MFSExtendSelf`` (type ``Bool``; default ``TRUE``) is passed to + ``PoolCreate()`` if a block descriptor pool is created. If ``TRUE``, + the block descriptor pool automatically extends itself when out of + space; if ``FALSE``, the pool returns ``ResLIMIT`` in this case. + (This feature is used by the arena to bootstrap its own CBS of free + memory.) -``Res CBSDescribe(CBS cbs, mps_lib_FILE *stream)`` -_`.function.cbs.describe`: ``CBSDescribe()`` is a function that prints -a textual representation of the CBS to the given stream, indicating -the contiguous ranges in order, as well as the structure of the -underlying splay tree implementation. It is provided for debugging -purposes only. +Limitations +........... -``Bool CBSFindFirst(Range rangeReturn, Range oldRangeReturn, CBS cbs, Size size, FindDelete findDelete)`` +_`.limit.find`: ``CBSLandClass`` does not support the +``LandFindFirst()``, ``LandFindLast()``, and ``LandFindLargest()`` +generic functions (the subclasses do support these operations). -_`.function.cbs.find.first`: Locate the first block (in address order) -within the CBS of at least the specified size, update ``rangeReturn`` -to describe that range, and return ``TRUE``. If there is no such -block, it returns ``FALSE``. +_`.limit.zones`: ``CBSLandClass`` and ``CBSFastLandClass`` do not +support the ``LandFindInZones()`` generic function (the subclass +``CBSZonedLandClass`` does support this operation). -In addition, optionally delete the top, bottom, or all of the found -range, depending on the ``findDelete`` argument. This saves a separate -call to ``CBSDelete()``, and uses the knowledge of exactly where we -found the range. The value of ``findDelete`` must come from this -enumeration:: +_`.limit.iterate`: CBS does not provide an implementation for the +``LandIterateAndDelete()`` generic function. This is because +``TreeTraverse()`` does not permit modification, for speed and to +avoid perturbing the splay tree balance. - enum { - FindDeleteNONE, /* don't delete after finding */ - FindDeleteLOW, /* delete size bytes from low end of block */ - FindDeleteHIGH, /* delete size bytes from high end of block */ - FindDeleteENTIRE /* delete entire range */ - }; - -The original contiguous isolated range in which the range was found is -returned via the ``oldRangeReturn`` argument. (If ``findDelete`` is -``FindDeleteNONE`` or ``FindDeleteENTIRE``, then this will be -identical to the range returned via the ``rangeReturn`` argument.) - -``CBSFindFirst()`` requires that ``fastFind`` was true when -``CBSInit()`` was called. - -``Bool CBSFindLast(Range rangeReturn, Range oldRangeReturn, CBS cbs, Size size, FindDelete findDelete)`` - -_`.function.cbs.find.last`: Like ``CBSFindFirst()``, except that it -finds the last block in address order. - -``Bool CBSFindLargest(Range rangeReturn, Range oldRangeReturn, CBS cbs, Size size, FindDelete findDelete)`` - -_`.function.cbs.find.largest`: Locate the largest block within the -CBS, and if that block is at least as big as ``size``, return its -range via the ``rangeReturn`` argument, and return ``TRUE``. If there -are no blocks in the CBS at least as large as ``size``, return -``FALSE``. Pass 0 for ``size`` if you want the largest block -unconditionally. - -Like ``CBSFindFirst()``, optionally delete the range (specifying -``FindDeleteLOW`` or ``FindDeleteHIGH`` has the same effect as -``FindDeleteENTIRE``). This feature requires that ``fastFind`` was -true when ``CBSInit()`` was called. +_`.limit.flush`: CBS cannot be used as the source in a call to +``LandFlush()``. (Because of `.limit.iterate`_.) Implementation -------------- -_`.impl`: This section is concerned with describing various aspects of -the implementation. It does not form part of the interface definition. - - - Splay tree .......... -_`.impl.splay`: The CBS is principally implemented using a splay tree -(see design.mps.splay_). Each splay tree node is embedded in a -``CBSBlock`` that represents a semi-open address range. The key passed +_`.impl.splay`: The CBS is implemented using a splay tree (see +design.mps.splay_). Each splay tree node is embedded in a block +structure that represents a semi-open address range. The key passed for comparison is the base of another range. .. _design.mps.splay: splay -_`.impl.splay.fast-find`: ``CBSFindFirst()`` and ``CBSFindLast()`` use -the update/refresh facility of splay trees to store, in each -``CBSBlock``, an accurate summary of the maximum block size in the -tree rooted at the corresponding splay node. This allows rapid -location of the first or last suitable block, and very rapid failure -if there is no suitable block. +_`.impl.splay.fast-find`: In the ``CBSFastLandClass`` class, +``cbsFindFirst()`` and ``cbsFindLast()`` use the update/refresh +facility of splay trees to store, in each block, an accurate summary +of the maximum block size in the tree rooted at the corresponding +splay node. This allows rapid location of the first or last suitable +block, and very rapid failure if there is no suitable block. -_`.impl.find-largest`: ``CBSFindLargest()`` simply finds out the size +_`.impl.find-largest`: ``cbsFindLargest()`` simply finds out the size of the largest block in the CBS from the root of the tree, using ``SplayRoot()``, and does ``SplayFindFirst()`` for a block of that size. This takes time proportional to the logarithm of the size of the free list, so it's about the best you can do without maintaining a -separate priority queue, just to do ``CBSFindLargest()``. +separate priority queue, just to do ``cbsFindLargest()``. + +_`.impl.splay.zones`: In the ``CBSZonedLandClass`` class, +``cbsFindInZones()`` uses the update/refresh facility of splay trees +to store, in each block, the union of the zones of the ranges in the +tree rooted at the corresponding splay node. This allows rapid +location of a block in a set of zones. Low memory behaviour @@ -261,10 +172,10 @@ Low memory behaviour _`.impl.low-mem`: When the CBS tries to allocate a new ``CBSBlock`` structure for a new isolated range as a result of either -``CBSInsert()`` or ``CBSDelete()``, and there is insufficient memory -to allocation the ``CBSBlock`` structure, then the range is not added -to the CBS or deleted from it, and the call to ``CBSInsert()`` or -``CBSDelete()`` returns ``ResMEMORY``. +``LandInsert()`` or ``LandDelete()``, and there is insufficient memory +to allocate the block structure, then the range is not added to the +CBS or deleted from it, and the call to ``LandInsert()`` or +``LandDelete()`` returns ``ResMEMORY``. The CBS block @@ -285,19 +196,12 @@ Testing _`.test`: The following testing will be performed on this module: -_`.test.cbstest`: There is a stress test for this module in -impl.c.cbstest. This allocates a large block of memory and then -simulates the allocation and deallocation of ranges within this block -using both a ``CBS`` and a ``BT``. It makes both valid and invalid -requests, and compares the ``CBS`` response to the correct behaviour -as determined by the ``BT``. It also iterates the ranges in the -``CBS``, comparing them to the ``BT``. It also invokes the -``CBSDescribe()`` method, but makes no automatic test of the resulting -output. It does not currently test the callbacks. +_`.test.land`: A generic test for land implementations. See +design.mps.land.test. -_`.test.pool`: Several pools (currently MVT_ and MVFF_) are implemented -on top of a CBS. These pool are subject to testing in development, QA, -and are/will be heavily exercised by customers. +_`.test.pool`: The arena and two pools (MVT_ and MVFF_) are +implemented on top of a CBS. These are subject to testing in +development, QA, and are heavily exercised by customers. .. _MVT: poolmvt .. _MVFF: poolmvff @@ -306,9 +210,9 @@ and are/will be heavily exercised by customers. Notes for future development ---------------------------- -_`.future.not-splay`: The initial implementation of CBSs is based on -splay trees. It could be revised to use any other data structure that -meets the requirements (especially `.req.fast`_). +_`.future.not-splay`: The implementation of CBSs is based on splay +trees. It could be revised to use other data structures that meet the +requirements (especially `.req.fast`_). _`.future.hybrid`: It would be possible to attenuate the problem of `.risk.overhead`_ (below) by using a single word bit set to represent @@ -318,6 +222,11 @@ converting them when they reach all free in the bit set. Note that this would make coalescence slightly less eager, by up to ``(word-width - 1)``. +_`.future.iterate.and.delete`: It would be possible to provide an +implementation for the ``LandIterateAndDelete()`` generic function by +calling ``TreeToVine()`` first, and then iterating over the vine +(where deletion is straightforward). + Risks ----- @@ -330,7 +239,6 @@ the size of that area. [Four words per two grains.] The CBS structure is thus suitable only for managing large enough ranges. - Document History ---------------- @@ -359,6 +267,9 @@ Document History talking about the deleted "emergency" free list allocator. Documented ``fastFind`` argument to ``CBSInit()``. +- 2014-04-01 GDR_ Moved generic material to design.mps.land_. + Documented new keyword arguments. + .. _RB: http://www.ravenbrook.com/consultants/rb/ .. _GDR: http://www.ravenbrook.com/consultants/gdr/ diff --git a/mps/design/failover.txt b/mps/design/failover.txt new file mode 100644 index 00000000000..5fdb5a9b76d --- /dev/null +++ b/mps/design/failover.txt @@ -0,0 +1,150 @@ +.. mode: -*- rst -*- + +Fail-over allocator +=================== + +:Tag: design.mps.failover +:Author: Gareth Rees +:Date: 2014-04-01 +:Status: complete design +:Revision: $Id$ +:Copyright: See section `Copyright and License`_. + + +Introduction +------------ + +_`.intro`: This is the design of the fail-over allocator, a data +structure for the management of address ranges. + +_`.readership`: This document is intended for any MPS developer. + +_`.source`: design.mps.land_, design.mps.poolmvt_, design.mps.poolmvff_. + +_`.overview`: The fail-over allocator combines two *land* instances. +It stores address ranges in one of the lands (the *primary*) unless +insertion fails, in which case it falls back to the other (the +*secondary*). The purpose is to be able to combine two lands with +different properties: with a CBS_ for the primary and a Freelist_ for +the secondary, operations are fast so long as there is memory to +allocate new nodes in the CBS, but operations can continue using the +Freelist when memory is low. + +.. _CBS: cbs +.. _Freelist: freelist +.. _design.mps.land: land +.. _design.mps.poolmvt: poolmvt +.. _design.mps.poolmvff: poolmvff + + +Interface +--------- + +_`.land`: The fail-over allocator is an implementation of the *land* +abstract data type, so the interface consists of the generic functions +for lands. See design.mps.land_. + + +External types +.............. + +``typedef struct FailoverStruct *Failover`` + +_`.type.failover`: The type of fail-over allocator structures. A +``FailoverStruct`` may be embedded in another structure, or you can +create it using ``LandCreate()``. + + +External functions +.................. + +``LandClass FailoverLandClassGet(void)`` + +_`.function.class`: The function ``FailoverLandClassGet()`` returns +the fail-over allocator class, a subclass of ``LandClass`` suitable +for passing to ``LandCreate()`` or ``LandInit()``. + + +Keyword arguments +................. + +When initializing a fail-over allocator, ``LandCreate()`` and +``LandInit()`` require these two keyword arguments: + +* ``FailoverPrimary`` (type ``Land``) is the primary land. + +* ``FailoverSecondary`` (type ``Land``) is the secondary land. + + +Implementation +-------------- + +_`.impl.assume`: The implementation assumes that the primary is fast +but space-hungry (a CBS) and the secondary is slow but space-frugal (a +Freelist). This assumption is used in the following places: + +_`.impl.assume.flush`: The fail-over allocator attempts to flush the +secondary to the primary before any operation, in order to benefit +from the speed of the primary wherever possible. In the normal case +where the secondary is empty this is cheap. + +_`.impl.assume.delete`: When deletion of a range on the primary fails +due to lack of memory, we assume that this can only happen when there +are splinters on both sides of the deleted range, one of which needs +to be allocated a new node (this is the case for CBS), and that +therefore the following procedure will be effective: first, delete the +enclosing range from the primary (leaving no splinters and thus +requiring no allocation), and re-insert the splinters (failing over to +the secondary if necessary). + + + +Document History +---------------- + +- 2014-04-03 GDR_ Created. + +.. _GDR: http://www.ravenbrook.com/consultants/gdr/ + + +Copyright and License +--------------------- + +Copyright © 2014 Ravenbrook Limited. All rights reserved. +. This is an open source license. Contact +Ravenbrook for commercial licensing options. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions are +met: + +#. Redistributions of source code must retain the above copyright + notice, this list of conditions and the following disclaimer. + +#. Redistributions in binary form must reproduce the above copyright + notice, this list of conditions and the following disclaimer in the + documentation and/or other materials provided with the distribution. + +#. Redistributions in any form must be accompanied by information on how + to obtain complete source code for this software and any + accompanying software that uses this software. The source code must + either be included in the distribution or be available for no more than + the cost of distribution plus a nominal fee, and must be freely + redistributable under reasonable conditions. For an executable file, + complete source code means the source code for all modules it contains. + It does not include source code for modules or files that typically + accompany the major components of the operating system on which the + executable file runs. + +**This software is provided by the copyright holders and contributors +"as is" and any express or implied warranties, including, but not +limited to, the implied warranties of merchantability, fitness for a +particular purpose, or non-infringement, are disclaimed. In no event +shall the copyright holders and contributors be liable for any direct, +indirect, incidental, special, exemplary, or consequential damages +(including, but not limited to, procurement of substitute goods or +services; loss of use, data, or profits; or business interruption) +however caused and on any theory of liability, whether in contract, +strict liability, or tort (including negligence or otherwise) arising in +any way out of the use of this software, even if advised of the +possibility of such damage.** diff --git a/mps/design/freelist.txt b/mps/design/freelist.txt index badc4067f15..b0654468de1 100644 --- a/mps/design/freelist.txt +++ b/mps/design/freelist.txt @@ -41,174 +41,53 @@ When memory becomes available again to allocate control structures, the free lists can be "flushed" back into the more efficient data structures. -_`.bg`: The free list allocator was formerly part of the Coalescing -Block Structure module (see design.mps.cbs) but it was split into its -own module because this makes it: - -#. simpler (no need to interact with CBS) and thus more maintainable; -#. possible to test directly (no need to create a CBS and then force - its control pool to run out of memory); and -#. usable as a fallback allocator in other pools (not just in pools - that use CBS). - - -Definitions ------------ - -_`.def.range`: A (contiguous) *range* of addresses is a semi-open -interval on address space. - -_`.def.isolated`: A contiguous range is *isolated* with respect to -some property it has, if adjacent elements do not have that property. - Requirements ------------ -_`.req.set`: Must maintain a set of free address ranges. +In addition to the generic land requirements (see design.mps.land_), +free lists must satisfy: -_`.req.add`: Must be able to add free address ranges to the set. - -_`.req.remove`: Must be able to remove address ranges from the set (in -particular, when memory is allocated). - -_`.req.iterate`: Must support the iteration of all isolated contiguous -ranges. - -_`.req.protocol`: Must detect protocol violations. - -_`.req.align`: Must support an alignment (the alignment of all -addresses specifying ranges) of down to ``sizeof(void *)`` without -losing memory. +.. _design.mps.land: land _`.req.zero-overhead`: Must have zero space overhead for the storage of any set of free blocks, so that it can be used to manage memory when no memory can be allocated for control structures. -_`.req.source`: This set of requirements is derived from those of the -CBS module (see design.mps.cbs.req), except that there is no -equivalent of design.mps.cbs.req.fast, and design.mps.cbs.req.small -has been replaced with `.req.zero-overhead`_. - Interface --------- +_`.land`: Free lists are an implementation of the *land* abstract data +type, so the interface consists of the generic functions for lands. +See design.mps.land_. + Types ..... ``typedef struct FreelistStruct *Freelist`` -_`.type.freelist`: The type of free lists. The structure -``FreelistStruct`` is declared in the header so that it can be inlined -in other structures, but you should not depend on its details. - -``typedef Bool (*FreelistIterateMethod)(Bool *deleteReturn, Freelist fl, Range range, void *closureP, Size closureS)`` - -_`.type.iterate.method`: A callback function that may be passed to -``FreelistIterate()``. It is called for every isolated contiguous -range in address order, and with the closure arguments that were -originally passed to ``FreelistIterate()``. It must update -``*deleteReturn`` to ``TRUE`` if the range must be deleted from the -free lists, or ``FALSE`` if the range must be kept. The function must -return ``TRUE`` if the iteration must continue, and ``FALSE`` if the -iteration must stop (after possibly deleting the current range). +_`.type.freelist`: The type of free lists. A ``FreelistStruct`` may be +embedded in another structure, or you can create it using +``LandCreate()``. -Functions -......... +External functions +.................. -``Res FreelistInit(Freelist fl, Align alignment)`` +``LandClass FreelistLandClassGet(void)`` -_`.function.init`: Initialize the ``Freelist`` structure pointed to by -``fl``. The argument ``alignment`` is the alignment of address ranges -to be maintained. An initialised free list contains no address ranges. +_`.function.class`: The function ``FreelistLandClassGet()`` returns +the free list class, a subclass of ``LandClass`` suitable for passing +to ``LandCreate()`` or ``LandInit()``. -``void FreelistFinish(Freelist fl)`` -_`.function.finish`: Finish the free list pointed to by ``fl``. - -``Res FreelistInsert(Range rangeReturn, Freelist fl, Range range)`` - -_`.function.insert`: If any part of ``range`` is already in the free -list ``fl``, then leave the free list unchanged and return -``ResFAIL``. Otherwise, insert ``range`` into the free list ``fl``; -update ``rangeReturn`` to describe the contiguous isolated range -containing the inserted range (this may differ from ``range`` if there -was coalescence on either side) and return ``ResOK``. - -``Res FreelistDelete(Range rangeReturn, Freelist fl, Range range)`` - -_`.function.delete`: If any part of the range is not in the free list, -then leave the free list unchanged and return ``ResFAIL``. Otherwise, -remove ``range`` from the free list and update ``rangeReturn`` to -describe the contiguous isolated range that formerly contained the -deleted range (this may differ from ``range`` if there were fragments -left on either side), and return ``ResOK``. - -``void FreelistIterate(Freelist fl, FreelistIterateMethod iterate, void *closureP, Size closureS)`` - -_`.function.iterate`: Iterate all isolated contiguous ranges in the -free list ``fl`` in address order, calling ``iterate`` for each one. -See ``FreelistIterateMethod`` for details. - -``Bool FreelistFindFirst(Range rangeReturn, Range oldRangeReturn, Freelist fl, Size size, FindDelete findDelete)`` - -_`.function.find.first`: Locate the first isolated contiguous range in -address order, within the free list ``fl``, of at least ``size`` -bytes, update ``rangeReturn`` to that range, and return ``TRUE``. If -there is no such continuous range, return ``FALSE``. - -In addition, optionally delete the found range from the free list, -depending on the ``findDelete`` argument. This saves a separate call -to ``FreelistDelete()``, and uses the knowledge of exactly where we -found the range. The value of ``findDelete`` must come from this -enumeration:: - - enum { - FindDeleteNONE, /* don't delete after finding */ - FindDeleteLOW, /* delete size bytes from low end of block */ - FindDeleteHIGH, /* delete size bytes from high end of block */ - FindDeleteENTIRE /* delete entire range */ - }; - -The original contiguous isolated range in which the range was found is -returned via the ``oldRangeReturn`` argument. (If ``findDelete`` is -``FindDeleteNONE`` or ``FindDeleteENTIRE``, then this will be -identical to the range returned via the ``rangeReturn`` argument.) - -``Bool FreelistFindLast(Range rangeReturn, Range oldRangeReturn, Freelist fl, Size size, FindDelete findDelete)`` - -_`.function.find.last`: Like ``FreelistFindFirst()``, except that it -finds the last block in address order. - -``Bool FreelistFindLargest(Range rangeReturn, Range oldRangeReturn, Freelist fl, Size, size, FindDelete findDelete)`` - -_`.function.find.largest`: Locate the largest block within the free -list ``fl``, and if that block is at least as big as ``size``, return -its range via the ``rangeReturn`` argument, and return ``TRUE``. If -there are no blocks in the free list at least as large as ``size``, -return ``FALSE``. Pass 0 for ``size`` if you want the largest block -unconditionally. - -Like ``FreelistFindFirst()``, optionally delete the range from the -free list. (Always the whole range: specifying ``FindDeleteLOW`` or -``FindDeleteHIGH`` has the same effect as ``FindDeleteENTIRE``). - -``void FreelistFlushToCBS(Freelist fl, CBS cbs)`` - -Remove free address ranges from the free list ``fl`` and add them to -the Coalescing Block Structure ``cbs``. Continue until a call to -``CBSInsert()`` fails, or until the free list is empty, whichever -happens first. - -``Res FreelistDescribe(Freelist fl, mps_lib_FILE *stream)`` - -_`.function.describe`: Print a textual representation of the free -list ``fl`` to the given stream, indicating the contiguous ranges in -order. It is provided for debugging purposes only. +Keyword arguments +................. +When initializing a free list, ``LandCreate()`` and ``LandInit()`` +take no keyword arguments. Pass ``mps_args_none``. Implementation @@ -221,12 +100,13 @@ an address-ordered singly linked free list. (As in traditional _`.impl.block`: If the free address range is large enough to contain an inline block descriptor consisting of two pointers, then the two pointers stored are to the next free range in address order (or -``NULL`` if there are no more ranges), and to the limit of current -free address range, in that order. +``freelistEND`` if there are no more ranges), and to the limit of the +current free address range, in that order. _`.impl.grain`: Otherwise, the free address range must be large enough to contain a single pointer. The pointer stored is to the next free -range in address order, or ``NULL`` if there are no more ranges. +range in address order, or ``freelistEND`` if there are no more +ranges. _`.impl.tag`: Grains and blocks are distinguished by a one-bit tag in the low bit of the first word (the one containing the pointer to the @@ -239,14 +119,31 @@ _`.impl.merge`: When a free address range is added to the free list, it is merged with adjacent ranges so as to maintain `.impl.invariant`_. -_`.impl.rule.break`: The use of ``NULL`` to mark the end of the list -violates the rule that exceptional values should not be used to +_`.impl.rule.break`: The use of ``freelistEND`` to mark the end of the +list violates the rule that exceptional values should not be used to distinguish exeptional situations. This infraction allows the implementation to meet `.req.zero-overhead`_. (There are other ways to do this, such as using another tag to indicate the last block in the list, but these would be more complicated.) +Testing +------- + +_`.test`: The following testing will be performed on this module: + +_`.test.land`: A generic test for land implementations. See +design.mps.land.test. + +_`.test.pool`: Two pools (MVT_ and MVFF_) use free lists as a fallback +when low on memory. These are subject to testing in development, QA, +and are heavily exercised by customers. + +.. _MVT: poolmvt +.. _MVFF: poolmvff + + + Opportunities for improvement ----------------------------- @@ -256,7 +153,7 @@ exceed the recorded size of the list. _`.improve.maxsize`: We could maintain the maximum size of any range on the list, and use that to make an early exit from -``FreelistFindLargest()``. It's not clear that this would actually be +``freelistFindLargest()``. It's not clear that this would actually be an improvement. @@ -266,6 +163,8 @@ Document History - 2013-05-18 GDR_ Initial draft based on CBS "emergency block" design. +- 2014-04-01 GDR_ Moved generic material to design.mps.land_. + .. _GDR: http://www.ravenbrook.com/consultants/gdr/ diff --git a/mps/design/index.txt b/mps/design/index.txt index de5db6963fd..39594723074 100644 --- a/mps/design/index.txt +++ b/mps/design/index.txt @@ -45,21 +45,23 @@ arena_ The design of the MPS arena arenavm_ Virtual memory arena bt_ Bit tables buffer_ Allocation buffers and allocation points -cbs_ Coalescing block structures +cbs_ Coalescing Block Structure land implementation check_ Design of checking in MPS class-interface_ Design of the pool class interface collection_ The collection framework config_ The design of MPS configuration critical-path_ The critical path through the MPS diag_ The design of MPS diagnostic feedback +failover_ Fail-over land implementation finalize_ Finalization fix_ The Design of the Generic Fix Function -freelist_ Free list allocator +freelist_ Free list land implementation guide.hex.trans_ Guide to transliterating the alphabet into hexadecimal guide.impl.c.format_ Coding standard: conventions for the general format of C source code in the MPS interface-c_ The design of the Memory Pool System interface to C io_ The design of the MPS I/O subsystem keyword-arguments_ The design of the MPS mechanism for passing arguments by keyword. +land_ Lands (collections of address ranges) lib_ The design of the Memory Pool System library interface lock_ The design of the lock module locus_ The design for the locus manager @@ -68,15 +70,15 @@ message-gc_ Messages sent when garbage collection begins or ends nailboard_ Nailboards for ambiguously referenced segments object-debug_ Debugging Features for Client Objects pool_ The design of the pool and pool class mechanisms -poolamc_ The design of the automatic mostly-copying memory pool class -poolams_ The design of the automatic mark-and-sweep pool class -poolawl_ Automatic weak linked -poollo_ Leaf object pool class -poolmfs_ The design of the manual fixed small memory pool class -poolmrg_ Guardian poolclass -poolmv_ The design of the manual variable memory pool class -poolmvt_ The design of a new manual-variable memory pool class -poolmvff_ Design of the manually-managed variable-size first-fit pool +poolamc_ Automatic Mostly-Copying pool class +poolams_ Automatic Mark-and-Sweep pool class +poolawl_ Automatic Weak Linked pool class +poollo_ Leaf Object pool class +poolmfs_ Manual Fixed Small pool class +poolmrg_ Manual Rank Guardian pool class +poolmv_ Manual Variable pool class +poolmvt_ Manual Variable Temporal pool class +poolmvff_ Manual Variable First-Fit pool class prot_ Generic design of the protection module protan_ ANSI implementation of protection module protli_ Linux implementation of protection module @@ -122,6 +124,7 @@ writef_ The design of the MPS writef function .. _config: config .. _critical-path: critical-path .. _diag: diag +.. _failover: failover .. _finalize: finalize .. _fix: fix .. _freelist: freelist @@ -130,6 +133,7 @@ writef_ The design of the MPS writef function .. _interface-c: interface-c .. _io: io .. _keyword-arguments: keyword-arguments +.. _land: land .. _lib: lib .. _lock: lock .. _locus: locus diff --git a/mps/design/land.txt b/mps/design/land.txt new file mode 100644 index 00000000000..b4b8bd212a1 --- /dev/null +++ b/mps/design/land.txt @@ -0,0 +1,352 @@ +.. mode: -*- rst -*- + +Lands +===== + +:Tag: design.mps.land +:Author: Gareth Rees +:Date: 2014-04-01 +:Status: complete design +:Revision: $Id$ +:Copyright: See section `Copyright and License`_. + + +Introduction +------------ + +_`.intro`: This is the design of the *land* abstract data type, which +represents a collection of contiguous address ranges. + +_`.readership`: This document is intended for any MPS developer. + +_`.source`: design.mps.cbs_, design.mps.freelist_. + +_`.overview`: Collections of address ranges are used in several places +in the MPS: the arena stores a set of mapped address ranges; pools +store sets of address ranges which have been acquired from the arena +and sets of address ranges that are available for allocation. The +*land* abstract data type makes it easy to try out different +implementations with different performance characteristics and other +attributes. + +_`.name`: The name is inspired by *rangeland* meaning *group of +ranges* (where *ranges* is used in the sense *grazing areas*). + + +Definitions +----------- + +_`.def.range`: A (contiguous) *range* of addresses is a semi-open +interval on address space. + +_`.def.isolated`: A contiguous range is *isolated* with respect to +some property it has, if adjacent elements do not have that property. + + +Requirements +------------ + +_`.req.set`: Must maintain a set of addresses. + +_`.req.add`: Must be able to add address ranges to the set. + +_`.req.remove`: Must be able to remove address ranges from the set. + +_`.req.size`: Must report concisely to the client when isolated +contiguous ranges of at least a certain size appear and disappear. + +_`.req.iterate`: Must support the iteration of all isolated +contiguous ranges. + +_`.req.protocol`: Must detect protocol violations. + +_`.req.debug`: Must support debugging of client code. + +_`.req.align`: Must support an alignment (the alignment of all +addresses specifying ranges) of down to ``sizeof(void *)`` without +losing memory. + + +Interface +--------- + +Types +..... + +``typedef LandStruct *Land;`` + +_`.type.land`: The type of a generic land instance. + +``typedef Bool (*LandVisitor)(Land land, Range range, void *closureP, Size closureS);`` + +_`.type.visitor`: Type ``LandVisitor`` is a callback function that may +be passed to ``LandIterate()``. It is called for every isolated +contiguous range in address order. The function must return a ``Bool`` +indicating whether to continue with the iteration. + +``typedef Bool (*LandDeleteVisitor)(Bool *deleteReturn, Land land, Range range, void *closureP, Size closureS);`` + +_`.type.visitor`: Type ``LandDeleteVisitor`` is a callback function that may +be passed to ``LandIterateAndDelete()``. It is called for every isolated +contiguous range in address order. The function must return a ``Bool`` +indicating whether to continue with the iteration. It may additionally +update ``*deleteReturn`` to ``TRUE`` if the range must be deleted from +the land, or ``FALSE`` if the range must be kept. (The default is to +keep the range.) + + +Generic functions +................. + +``Res LandInit(Land land, LandClass class, Arena arena, Align alignment, void *owner, ArgList args)`` + +_`.function.init`: ``LandInit()`` initializes the land structure for +the given class. The land will perform allocation (if necessary -- not +all land classes need to allocate) in the supplied arena. The +``alignment`` parameter is the alignment of the address ranges that +will be stored and retrieved from the land. The parameter ``owner`` is +output as a parameter to the ``LandInit`` event. The newly initialized +land contains no ranges. + +``Res LandCreate(Land *landReturn, Arena arena, LandClass class, Align alignment, void *owner, ArgList args)`` + +_`.function.create`: ``LandCreate()`` allocates memory for a land +structure of the given class in ``arena``, and then passes all +parameters to ``LandInit()``. + +``void LandDestroy(Land land)`` + +_`.function.destroy`: ``LandDestroy()`` calls ``LandFinish()`` to +finish the land structure, and then frees its memory. + +``void LandFinish(Land land)`` + +_`.function.finish`: ``LandFinish()`` finishes the land structure and +discards any other resources associated with the land. + +``void LandSize(Land land)`` + +_`.function.size`: ``LandSize()`` returns the total size of the ranges +stored in the land. + +``Res LandInsert(Range rangeReturn, Land land, Range range)`` + +_`.function.insert`: If any part of ``range`` is already in the +land, then leave it unchanged and return ``ResFAIL``. Otherwise, +attempt to insert ``range`` into the land. If the insertion succeeds, +then update ``rangeReturn`` to describe the contiguous isolated range +containing the inserted range (this may differ from ``range`` if there +was coalescence on either side) and return ``ResOK``. If the insertion +fails, return a result code indicating allocation failure. + +_`.function.insert.fail`: Insertion of a valid range (that is, one +that does not overlap with any range in the land) can only fail if the +new range is isolated and the allocation of the necessary data +structure to represent it failed. + +_`.function.insert.alias`: It is acceptable for ``rangeReturn`` and +``range`` to share storage. + +``Res LandDelete(Range rangeReturn, Land land, Range range)`` + +_`.function.delete`: If any part of the range is not in the land, +then leave the land unchanged and return ``ResFAIL``. Otherwise, update +``rangeReturn`` to describe the contiguous isolated range that +contains ``range`` (this may differ from ``range`` if there are +fragments on either side) and attempt to delete the range from the +land. If the deletion succeeds, return ``ResOK``. If the deletion +fails, return a result code indicating allocation failure. + +_`.function.delete.fail`: Deletion of a valid range (that is, one +that is wholly contained in the land) can only fail if there are +fragments on both sides and the allocation of the necessary data +structures to represent them fails. + +_`.function.delete.return`: ``LandDelete()`` returns the contiguous +isolated range that contains ``range`` even if the deletion fails. +This is so that the caller can try deleting the whole block (which is +guaranteed to succeed) and managing the fragments using a fallback +strategy. + +_`.function.delete.alias`: It is acceptable for ``rangeReturn`` and +``range`` to share storage. + +``Bool LandIterate(Land land, LandVisitor visitor, void *closureP, Size closureS)`` + +_`.function.iterate`: ``LandIterate()`` is the function used to +iterate all isolated contiguous ranges in a land. It receives a +visitor function to invoke on every range, and a pointer, ``Size`` +closure pair to pass on to the visitor function. If the visitor +function returns ``FALSE``, then iteration is terminated and +``LandIterate()`` returns ``FALSE``. If all iterator method calls +return ``TRUE``, then ``LandIterate()`` returns ``TRUE`` + +``Bool LandIterateAndDelete(Land land, LandDeleteVisitor visitor, void *closureP, Size closureS)`` + +_`.function.iterate.and.delete`: As ``LandIterate()``, but the visitor +function additionally returns a Boolean indicating whether the range +should be deleted from the land. + +``Bool LandFindFirst(Range rangeReturn, Range oldRangeReturn, Land land, Size size, FindDelete findDelete)`` + +_`.function.find.first`: Locate the first block (in address order) +within the land of at least the specified size, update ``rangeReturn`` +to describe that range, and return ``TRUE``. If there is no such +block, it returns ``FALSE``. + +In addition, optionally delete the top, bottom, or all of the found +range, depending on the ``findDelete`` argument. This saves a separate +call to ``LandDelete()``, and uses the knowledge of exactly where we +found the range. The value of ``findDelete`` must come from this +enumeration:: + + enum { + FindDeleteNONE, /* don't delete after finding */ + FindDeleteLOW, /* delete size bytes from low end of block */ + FindDeleteHIGH, /* delete size bytes from high end of block */ + FindDeleteENTIRE /* delete entire range */ + }; + +The original contiguous isolated range in which the range was found is +returned via the ``oldRangeReturn`` argument. (If ``findDelete`` is +``FindDeleteNONE`` or ``FindDeleteENTIRE``, then this will be +identical to the range returned via the ``rangeReturn`` argument.) + +``Bool LandFindLast(Range rangeReturn, Range oldRangeReturn, Land land, Size size, FindDelete findDelete)`` + +_`.function.find.last`: Like ``LandFindFirst()``, except that it +finds the last block in address order. + +``Bool LandFindLargest(Range rangeReturn, Range oldRangeReturn, Land land, Size size, FindDelete findDelete)`` + +_`.function.find.largest`: Locate the largest block within the +land, and if that block is at least as big as ``size``, return its +range via the ``rangeReturn`` argument, and return ``TRUE``. If there +are no blocks in the land at least as large as ``size``, return +``FALSE``. Pass 0 for ``size`` if you want the largest block +unconditionally. + +Like ``LandFindFirst()``, optionally delete the range (specifying +``FindDeleteLOW`` or ``FindDeleteHIGH`` has the same effect as +``FindDeleteENTIRE``), and return the original contiguous isolated +range in which the range was found via the ``oldRangeReturn`` +argument. + +``Res LandFindInZones(Bool *foundReturn, Range rangeReturn, Range oldRangeReturn, Land land, Size size, ZoneSet zoneSet, Bool high)`` + +_`.function.find.zones`: Locate a block at least as big as ``size`` +that lies entirely within the ``zoneSet``, return its range via the +``rangeReturn`` argument, set ``*foundReturn`` to ``TRUE``, and return +``ResOK``. (The first such block, if ``high`` is ``FALSE``, or the +last, if ``high`` is ``TRUE``.) If there is no such block, set +``*foundReturn`` to ``TRUE``, and return ``ResOK``. + +Delete the range as for ``LandFindFirst()`` and ``LastFindLast()`` +(with the effect of ``FindDeleteLOW`` if ``high`` is ``FALSE`` and the +effect of ``FindDeleteHIGH`` if ``high`` is ``TRUE``), and return the +original contiguous isolated range in which the range was found via +the ``oldRangeReturn`` argument. + +_`.function.find.zones.fail`: It's possible that the range can't be +deleted from the land because that would require allocation, in which +case the result code indicates the cause of the failure. + +``Res LandDescribe(Land land, mps_lib_FILE *stream)`` + +_`.function.describe`: ``LandDescribe()`` prints a textual +representation of the land to the given stream, indicating the +contiguous ranges in order, as well as the structure of the underlying +splay tree implementation. It is provided for debugging purposes only. + +``void LandFlush(Land dest, Land src)`` + +_`.function.flush`: Delete ranges of addresses from ``src`` and insert +them into ``dest``, so long as ``LandInsert()`` remains successful. + + +Implementations +--------------- + +There are three land implementations: + +#. CBS (Coalescing Block Structure) stores ranges in a splay tree. It + has fast (logarithmic in the number of ranges) insertion, deletion + and searching, but has substantial space overhead. See + design.mps.cbs_. + +#. Freelist stores ranges in an address-ordered free list, as in + traditional ``malloc()`` implementations. Insertion, deletion, and + searching are slow (proportional to the number of ranges) but it + does not need to allocate. See design.mps.freelist_. + +#. Failover combines two lands, using one (the *primary*) until it + fails, and then falls back to the other (the *secondary*). See + design.mps.failover_. + +.. _design.mps.cbs: cbs +.. _design.mps.freelist: freelist +.. _design.mps.failover: failover + + +Testing +------- + +_`.test`: There is a stress test for implementations of this interface +in impl.c.landtest. This allocates a large block of memory and then +simulates the allocation and deallocation of ranges within this block +using both a ``Land`` and a ``BT``. It makes both valid and invalid +requests, and compares the ``Land`` response to the correct behaviour +as determined by the ``BT``. It iterates the ranges in the ``Land``, +comparing them to the ``BT``. It invokes the ``LandDescribe()`` +generic function, but makes no automatic test of the resulting output. + + +Document History +---------------- + +- 2014-04-01 GDR_ Created based on design.mps.cbs_. + +.. _GDR: http://www.ravenbrook.com/consultants/gdr/ + + +Copyright and License +--------------------- + +Copyright © 2014 Ravenbrook Limited. All rights reserved. +. This is an open source license. Contact +Ravenbrook for commercial licensing options. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions are +met: + +#. Redistributions of source code must retain the above copyright + notice, this list of conditions and the following disclaimer. + +#. Redistributions in binary form must reproduce the above copyright + notice, this list of conditions and the following disclaimer in the + documentation and/or other materials provided with the distribution. + +#. Redistributions in any form must be accompanied by information on how + to obtain complete source code for this software and any + accompanying software that uses this software. The source code must + either be included in the distribution or be available for no more than + the cost of distribution plus a nominal fee, and must be freely + redistributable under reasonable conditions. For an executable file, + complete source code means the source code for all modules it contains. + It does not include source code for modules or files that typically + accompany the major components of the operating system on which the + executable file runs. + +**This software is provided by the copyright holders and contributors +"as is" and any express or implied warranties, including, but not +limited to, the implied warranties of merchantability, fitness for a +particular purpose, or non-infringement, are disclaimed. In no event +shall the copyright holders and contributors be liable for any direct, +indirect, incidental, special, exemplary, or consequential damages +(including, but not limited to, procurement of substitute goods or +services; loss of use, data, or profits; or business interruption) +however caused and on any theory of liability, whether in contract, +strict liability, or tort (including negligence or otherwise) arising in +any way out of the use of this software, even if advised of the +possibility of such damage.** diff --git a/mps/design/poolmvff.txt b/mps/design/poolmvff.txt index 2c16b80c4a0..c842fe03a6c 100644 --- a/mps/design/poolmvff.txt +++ b/mps/design/poolmvff.txt @@ -120,11 +120,13 @@ Implementation -------------- _`.impl.free-list`: The pool stores its free list in a CBS (see -//gdr-peewit/info.ravenbrook.com/project/mps/branch/2013-05-17/emergency/design/poolmvff.txt -`design.mps.cbs `_), failing over in emergencies to a Freelist -(see design.mps.freelist) when the CBS cannot allocate new control +design.mps.cbs_), failing over in emergencies to a Freelist (see +design.mps.freelist_) when the CBS cannot allocate new control structures. This is the reason for the alignment restriction above. +.. _design.mps.cbs: cbs +.. _design.mps.freelist: freelist + Details ------- diff --git a/mps/design/range.txt b/mps/design/range.txt index 1b42d69ac22..9e6d4ce34a4 100644 --- a/mps/design/range.txt +++ b/mps/design/range.txt @@ -25,8 +25,8 @@ Requirements ------------ _`.req.range`: A range object must be able to represent an arbitrary -range of addresses that does not include the top grain of the address -space. +range of addresses that neither starts at ``NULL`` nor includes the +top grain of the address space. _`.req.empty`: A range object must be able to represent the empty range. @@ -55,6 +55,12 @@ empty. Initialize ``dest`` to be a copy of ``src``. +``void RangeInitSize(Range range, Addr base, Size size)`` + +Initialize a range object to represent the half-open address range +between ``base`` (inclusive) and ``base + size`` (exclusive). If +``size == 0`` then the range is empty. + ``void RangeFinish(Range range)`` Finish a range object. Because a range object uses no heap resources diff --git a/mps/design/splay-assemble.svg b/mps/design/splay-assemble.svg new file mode 100644 index 00000000000..45956b496ea --- /dev/null +++ b/mps/design/splay-assemble.svg @@ -0,0 +1,427 @@ + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + A + + B + + + R + + assemble + + x + y + + L + + + A + + B + + + R + x + + L + + + + diff --git a/mps/design/splay-link-left.svg b/mps/design/splay-link-left.svg new file mode 100644 index 00000000000..f94d145743a --- /dev/null +++ b/mps/design/splay-link-left.svg @@ -0,0 +1,437 @@ + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + B + + A + + + L + + linkleft + + x + y + + R + + + B + + A + + + L + + x + y + + R + + diff --git a/mps/design/splay-link-right.svg b/mps/design/splay-link-right.svg new file mode 100644 index 00000000000..95c8c31e0a0 --- /dev/null +++ b/mps/design/splay-link-right.svg @@ -0,0 +1,437 @@ + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + A + + B + + + R + + linkright + + x + y + + L + + + A + + B + + + R + + x + y + + L + + diff --git a/mps/design/splay-rotate-left.svg b/mps/design/splay-rotate-left.svg new file mode 100644 index 00000000000..f5e50922aa8 --- /dev/null +++ b/mps/design/splay-rotate-left.svg @@ -0,0 +1,405 @@ + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + A + + B + + + + C + + + + C + + B + + + + A + + rotateleft + + x + y + x + y + + diff --git a/mps/design/splay-rotate-right.svg b/mps/design/splay-rotate-right.svg new file mode 100644 index 00000000000..39fea1b2a20 --- /dev/null +++ b/mps/design/splay-rotate-right.svg @@ -0,0 +1,391 @@ + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + A + + B + + + + C + + + + C + + B + + + + A + + rotateright + + x + y + x + y + + diff --git a/mps/design/splay.txt b/mps/design/splay.txt index 8eb1a91c2a8..fefb40fe8a9 100644 --- a/mps/design/splay.txt +++ b/mps/design/splay.txt @@ -6,7 +6,7 @@ Splay trees :Tag: design.mps.splay :Author: Gavin Matthews :Date: 1998-05-01 -:Status: draft document +:Status: complete design :Revision: $Id$ :Copyright: See `Copyright and License`_. :Index terms: pair: splay trees; design @@ -22,9 +22,13 @@ implementation. _`.readership`: This document is intended for any MM developer. _`.source`: The primary sources for this design are [ST85]_ and -[Sleator96]_. Also as CBS is a client, design.mps.cbs. As -PoolMVFF is an indirect client, design.mps.poolmvff(1). Also, as -PoolMV2 is an (obsolescent?) indirect client, design.mps.poolmv2. +[Sleator96]_. As CBS is a client, design.mps.cbs_. As PoolMVFF is an +indirect client, design.mps.poolmvff_. Also, as PoolMVT is an indirect +client, design.mps.poolmvt_. + +.. _design.mps.cbs: cbs +.. _design.mps.poolmvt: poolmvt +.. _design.mps.poolmvff: poolmvff _`.background`: The following background documents influence the design: guide.impl.c.adt(0). @@ -43,42 +47,46 @@ usage patterns. Unused nodes have essentially no time overhead. Definitions ----------- -_`.def.splay-tree`: A "Splay Tree" is a self-adjusting binary tree as -described in paper.st85(0), paper.sleator96(0). +_`.def.splay-tree`: A *splay tree* is a self-adjusting binary tree as +described in [ST85]_ and [Sleator96]_. -_`.def.node`: A "node" is used in the typical datastructure sense to -mean an element of a tree (see also `.type.splay.node`_). +_`.def.node`: A *node* is used in the typical data structure sense to +mean an element of a tree (see also `.type.tree`_). -_`.def.key`: A "key" is a value associated with each node; the keys +_`.def.key`: A *key* is a value associated with each node; the keys are totally ordered by a client provided comparator. -_`.def.comparator`: A "comparator" is a function that compares keys to -determine their ordering (see also `.type.splay.compare.method`_). +_`.def.comparator`: A *comparator* is a function that compares keys to +determine their ordering (see also `.type.tree.compare.method`_). -_`.def.successor`: Node *N1* is the "successor" of node *N2* if *N1* -and *N2* are both in the same tree, and the key of *N1* immediately -follows the key of *N2* in the ordering of all keys for the tree. +_`.def.successor`: Node *N*\ :subscript:`2` is the *successor* of node +*N*\ :subscript:`1` if *N*\ :subscript:`1` and *N*\ :subscript:`2` are +both in the same tree, and the key of *N*\ :subscript:`2` immediately +follows the key of *N*\ :subscript:`1` in the ordering of all keys for +the tree. -_`.def.left-child`: Each node *N* contains a "left child", which is a +_`.def.left-child`: Each node *N* contains a *left child*, which is a (possibly empty) sub-tree of nodes. The key of *N* is ordered after the keys of all nodes in this sub-tree. -_`.def.right-child`: Each node *N* contains a "right child", which is +_`.def.right-child`: Each node *N* contains a *right child*, which is a (possibly empty) sub-tree of nodes. The key of *N* is ordered before the keys of all nodes in this sub-tree. -_`.def.neighbour`: A node *N* which has key *Kn* is a "neighbour" of a -key *K* if either *Kn* is the first key in the total order which -compares greater than *K* or if *Kn* is the last key in the total -order which compares less than *K*. +_`.def.neighbour`: The *left neighbour* of a key *K* is the node *N* +with the largest key that compares less than *K* in the total order. +The *right neighbour* of a key *K* is the node *N* with the smaller +key that compares greater than *K* in the total order. A node is a +*neighbour* of a key if it is either the left or right neighbour of +the key. -_`.def.first`: A node is the "first" node in a set of nodes if its key +_`.def.first`: A node is the *first* node in a set of nodes if its key compares less than the keys of all other nodes in the set. -_`.def.last`: A node is the "last" node in a set of nodes if its key +_`.def.last`: A node is the *last* node in a set of nodes if its key compares greater than the keys of all other nodes in the set. -_`.def.client-property`: A "client property" is a value that the +_`.def.client-property`: A *client property* is a value that the client may associate with each node in addition to the key (a block size, for example). This splay tree implementation provides support for efficiently finding the first or last nodes with suitably large @@ -89,32 +97,27 @@ Requirements ------------ _`.req`: These requirements are drawn from those implied by -design.mps.poolmv2, design.mps.poolmvff(1), design.mps.cbs(2) and +design.mps.poolmvt_, design.mps.poolmvff_, design.mps.cbs_, and general inferred MPS requirements. _`.req.order`: Must maintain a set of abstract keys which is totally ordered for a comparator. -_`.req.tree`: The keys must be associated with nodes arranged in a -Splay Tree. +_`.req.fast`: Common operations must have low amortized cost. -_`.req.splay`: Common operations must balance the tree by splaying it, -to achieve low amortized cost (see paper.st85(0)). - -_`.req.add`: Must be able to add new members. This is a common +_`.req.add`: Must be able to add new nodes. This is a common operation. -_`.req.remove`: Must be able to remove members. This is a common +_`.req.remove`: Must be able to remove nodes. This is a common operation. -_`.req.locate`: Must be able to locate a member, given a key. This is +_`.req.locate`: Must be able to locate a node, given a key. This is a common operation. -_`.req.neighbours`: Must be able to locate the neighbouring members -(in order) of a non-member, given a key (see `.def.neighbour`_). This -is a common operation. +_`.req.neighbours`: Must be able to locate the neighbouring nodes of a +key (see `.def.neighbour`_). This is a common operation. -_`.req.iterate`: Must be able to iterate over all members in order +_`.req.iterate`: Must be able to iterate over all nodes in key order with reasonable efficiency. _`.req.protocol`: Must support detection of protocol violations. @@ -141,10 +144,73 @@ _`.req.root`: Must be able to find the root of a splay tree (if one exists). -External types --------------- +Generic binary tree interface +----------------------------- + +Types +..... + +``typedef struct TreeStruct *Tree`` + +_`.type.tree`: ``Tree`` is the type of a node in a binary tree. +``Tree`` contains no fields to store the key associated with the node, +or the client property. Again, it is intended that the ``TreeStruct`` +can be embedded in another structure, and that this is how the +association will be made (see `.usage.client-node`_ for an example). +No convenience functions are provided for allocation or deallocation. + +``typedef void *TreeKey`` + +_`.type.treekey`: ``TreeKey`` is the type of a key associated with a +node in a binary tree. It is an alias for ``void *`` but expresses the +intention. + +``typedef TreeKey (*TreeKeyMethod)(Tree tree)`` + +_`.type.tree.key.method`: A function of type ``TreeKey`` returns the +key associated with a node in a binary tree. (Since there is no space +in a ``TreeStruct`` to store a key, it is expected that the +``TreeStruct`` is embedded in another structure from which the key can +be extracted.) + +``typedef Compare (*TreeCompare)(Tree tree, TreeKey key)`` + +_`.type.tree.compare.method`: A function of type ``TreeCompare`` is +required to compare ``key`` with the key the client associates with +that splay tree node ``tree``, and return the appropriate Compare +value (see `.usage.compare`_ for an example). The function compares a +key with a node, rather than a pair of keys or nodes as might seem +more obvious. This is because the details of the mapping between nodes +and keys is left to the client (see `.type.tree`_), and the splaying +operations compare keys with nodes (see `.impl.splay`_). + +``typedef Res (*TreeDescribeMethod)(Tree tree, mps_lib_FILE *stream)`` + +_`.type.tree.describe.method`: A function of type +``TreeDescribeMethod`` is required to write (via ``WriteF()``) a +client-oriented representation of the splay node. The output should be +non-empty, short, and without newline characters. This is provided for +debugging purposes only. + + +Functions +......... + +``Bool TreeCheck(Tree tree)`` + +_`.function.tree.check`: This is a check function for the +``Tree`` type (see guide.impl.c.adt.method.check and +design.mps.check_). + +.. _design.mps.check: check + + +Splay tree interface +-------------------- + +Types +..... -``typedef struct SplayTreeStruct SplayTreeStruct`` ``typedef struct SplayTreeStruct *SplayTree`` _`.type.splay.tree`: ``SplayTree`` is the type of the main object at @@ -153,39 +219,7 @@ the root of the splay tree. It is intended that the `.usage.client-tree`_ for an example). No convenience functions are provided for allocation or deallocation. -``typedef struct TreeStruct TreeStruct`` -``typedef struct TreeStruct *Tree`` - -_`.type.splay.node`: ``Tree`` is the type of a binary tree, used as the -representation of the nodes of the splay tree. -``Tree`` contains no fields to store the key -associated with the node, or the client property. Again, it is -intended that the ``TreeStruct`` can be embedded in another -structure, and that this is how the association will be made (see -`.usage.client-node`_ for an example). No convenience functions are -provided for allocation or deallocation. - -``typedef Compare (*TreeCompare)(Tree tree, TreeKey key)`` - -_`.type.splay.compare.method`: A function of type -``TreeCompare`` is required to compare ``key`` with the key the -client associates with that splay tree node ``tree``, and return the -appropriate Compare value (see `.usage.compare`_ for an example). The -function compares a key with a node, rather than a pair of keys or -nodes as might seem more obvious. This is because the details of the -mapping between nodes and keys is left to the client (see -`.type.splay.node`_), and the splaying operations compare keys with -nodes (see `.impl.splay`_). - -``typedef Res (*SplayNodeDescribeMethod)(Tree tree, mps_lib_FILE *stream)`` - -_`.type.splay.node.describe.method`: A function of type -``SplayNodeDescribeMethod`` is required to write (via ``WriteF()``) a -client-oriented representation of the splay node. The output should be -non-empty, short, and without return characters. This is provided for -debugging purposes only. - -``typedef Bool (*SplayTestNodeMethod)(SplayTree splay, Tree tree, void *closureP, unsigned long closureS)`` +``typedef Bool (*SplayTestNodeMethod)(SplayTree splay, Tree tree, void *closureP, Size closureS)`` _`.type.splay.test.node.method`: A function of type ``SplayTestNodeMethod`` required to determine whether the node itself @@ -194,7 +228,7 @@ meets some client determined property (see `.prop`_ and ``closureS`` describe the environment for the function (see `.function.splay.find.first`_ and `.function.splay.find.last`_). -``typedef Bool (*SplayTestTreeMethod)(SplayTree splay, Tree tree, void *closureP, unsigned long closureS)`` +``typedef Bool (*SplayTestTreeMethod)(SplayTree splay, Tree tree, void *closureP, Size closureS)`` _`.type.splay.test.tree.method`: A function of type ``SplayTestTreeMethod`` is required to determine whether any of the @@ -210,46 +244,39 @@ environment for the function (see `.function.splay.find.first`_ and ``typedef void (*SplayUpdateNodeMethod)(SplayTree splay, Tree tree)`` _`.type.splay.update.node.method`: A function of type -``SplayUpdateNodeMethod`` is required to update any client -datastructures associated with a node to maintain some client -determined property (see `.prop`_) given that the children of the node -have changed. (See -`.usage.callback`_ for an example) +``SplayUpdateNodeMethod`` is required to update any client data +structures associated with a node to maintain some client determined +property (see `.prop`_) given that the children of the node have +changed. (See `.usage.callback`_ for an example) -External functions ------------------- +Functions +......... _`.function.no-thread`: The interface functions are not designed to be either thread-safe or re-entrant. Clients of the interface are responsible for synchronization, and for ensuring that client-provided -methods invoked by the splay module (`.type.splay.compare.method`_, -`.type.splay.test.node.method`_, `.type.splay.test.tree.method`_, -`.type.splay.update.node.method`_) do not call functions of the splay -module. +methods invoked by the splay module (`.type.tree.compare.method`_, +`.type.tree.key.method`_, `.type.splay.test.node.method`_, +`.type.splay.test.tree.method`_, `.type.splay.update.node.method`_) do +not call functions of the splay module. ``Bool SplayTreeCheck(SplayTree splay)`` _`.function.splay.tree.check`: This is a check function for the -SplayTree type (see guide.impl.c.adt.method.check & -design.mps.check(0)). +``SplayTree`` type (see guide.impl.c.adt.method.check and +design.mps.check_). -``Bool SplayNodeCheck(Tree tree)`` - -_`.function.splay.node.check`: This is a check function for the -``Tree`` type (see guide.impl.c.adt.method.check & -design.mps.check(0)). - -``void SplayTreeInit(SplayTree splay, SplayCompareMethod compare, SplayUpdateNodeMethod updateNode)`` +``void SplayTreeInit(SplayTree splay, TreeCompareMethod compare, TreeKeyMethod nodeKey, SplayUpdateNodeMethod updateNode)`` _`.function.splay.tree.init`: This function initialises a -``SplayTree`` (see guide.impl.c.adt.method.init). It requires a -``compare`` method that defines a total ordering on nodes (see -`.req.order`_); the effect of supplying a compare method that does not -implement a total ordering is undefined. It also requires an -``updateNode`` method, which will be used to keep client properties up -to date when the tree structure changes; the value -``SplayTrivUpdate`` may be used for this method if there is no +``SplayTree`` (see guide.impl.c.adt.method.init). The ``nodeKey`` +function extracts a key from a tree node, and the ``compare`` function +defines a total ordering on keys of nodes (see `.req.order`_). The +effect of supplying a compare method that does not implement a total +ordering is undefined. The ``updateNode`` method is used to keep +client properties up to date when the tree structure changes; the +value ``SplayTrivUpdate`` may be used for this method if there is no need to maintain client properties. (See `.usage.initialization`_ for an example use). @@ -259,7 +286,7 @@ _`.function.splay.tree.finish`: This function clears the fields of a ``SplayTree`` (see guide.impl.c.adt.method.finish). Note that it does not attempt to finish or deallocate any associated ``Tree`` objects; clients wishing to destroy a non-empty ``SplayTree`` must -first explicitly descend the tree and call ``SplayNodeFinish()`` on +first explicitly descend the tree and call ``TreeFinish()`` on each node from the bottom up. ``Bool SplayTreeInsert(SplayTree splay, Tree tree, void *key)`` @@ -281,84 +308,75 @@ given node does not compare ``CompareEQUAL`` with the given key, then function first splays the tree at the given key. (See `.usage.delete`_ for an example use). -``Bool SplayTreeFind(Tree *nodeReturn, SplayTree splay, void *key)`` +``Bool SplayTreeFind(Tree *nodeReturn, SplayTree splay, TreeKey key)`` -_`.function.splay.tree.search`: This function searches the splay tree -for a node that compares ``CompareEQUAL`` to the given key (see -`.req.locate`_). It splays the tree at the key. It returns ``FALSE`` -if there is no such node in the tree, otherwise ``*nodeReturn`` will -be set to the node. +_`.function.splay.tree.find`: Search the splay tree for a node that +compares ``CompareEQUAL`` to the given key (see `.req.locate`_), and +splay the tree at the key. Return ``FALSE`` if there is no such node +in the tree, otherwise set ``*nodeReturn`` to the node and return +``TRUE``. -``Bool SplayTreeNeighbours(Tree *leftReturn, Tree *rightReturn, SplayTree splay, void *key)`` +``Bool SplayTreeNeighbours(Tree *leftReturn, Tree *rightReturn, SplayTree splay, TreeKey key)`` -_`.function.splay.tree.neighbours`: This function searches a splay -tree for the two nodes that are the neighbours of the given key (see -`.req.neighbours`_). It splays the tree at the key. ``*leftReturn`` -will be the neighbour which compares less than the key if such a -neighbour exists; otherwise it will be ``TreeEMPTY``. ``*rightReturn`` will -be the neighbour which compares greater than the key if such a -neighbour exists; otherwise it will be ``TreeEMPTY``. The function returns -``FALSE`` if any node in the tree compares ``CompareEQUAL`` with the -given key. (See `.usage.insert`_ for an example use). +_`.function.splay.tree.neighbours`: Search a splay tree for the two +nodes that are the neighbours of the given key (see +`.req.neighbours`_). Splay the tree at the key. If any node in the +tree compares ``CompareEQUAL`` with the given key, return ``FALSE``. +Otherwise return ``TRUE``, set ``*leftReturn`` to the left neighbour +of the key (or ``TreeEMPTY`` if the key has no left neighbour), and +set ``*rightReturn`` to the right neighbour of the key (or +``TreeEMPTY`` if the key has no right neighbour). See `.usage.insert`_ +for an example of use. -``Tree SplayTreeFirst(SplayTree splay, void *zeroKey)`` +``Tree SplayTreeFirst(SplayTree splay)`` -_`.function.splay.tree.first`: This function splays the tree at the -first node, and returns that node (see `.req.iterate`_). The supplied -key should compare ``CompareLESS`` with all nodes in the tree. It will -return ``TreeEMPTY`` if the tree has no nodes. +_`.function.splay.tree.first`: If the tree has no nodes, return +``TreeEMPTY``. Otherwise, splay the tree at the first node, and return +that node (see `.req.iterate`_). -``Tree SplayTreeNext(SplayTree splay, Tree oldNode, void *oldKey)`` +``Tree SplayTreeNext(SplayTree splay, TreeKey key)`` -_`.function.splay.tree.next`: This function receives a node and key -and returns the successor node to that node (see `.req.iterate`_). -This function is intended for use in iteration when the received node -will be the current root of the tree, but is robust against being -interspersed with other splay operations (provided the old node still -exists). The supplied key must compare ``CompareEQUAL`` to the -supplied node. Note that use of this function rebalances the tree for -each node accessed. If many nodes are accessed as a result of multiple -uses, the resultant tree will be generally well balanced. But if the -tree was previously beneficially balanced for a small working set of -accesses, then this local optimization will be lost. (see -`.future.parent`_). +_`.function.splay.tree.next`: If the tree contains a right neighbour +for ``key``, splay the tree at that node and return it. Otherwise +return ``TreeEMPTY``. See `.req.iterate`_. -``Res SplayTreeDescribe(SplayTree splay, mps_lib_FILE *stream, SplayNodeDescribeMethod nodeDescribe)`` +``Res SplayTreeDescribe(SplayTree splay, mps_lib_FILE *stream, TreeDescribeMethod nodeDescribe)`` -_`.function.splay.tree.describe`: This function prints (using -``WriteF``) to the stream a textual representation of the given splay -tree, using ``nodeDescribe`` to print client-oriented representations -of the nodes (see `.req.debug`_). +_`.function.splay.tree.describe`: Print (using ``WriteF``) a textual +representation of the given splay tree to the stream, using +``nodeDescribe`` to print client-oriented representations of the nodes +(see `.req.debug`_). -``Bool SplayFindFirst(Tree *nodeReturn, SplayTree splay, SplayTestNodeMethod testNode, SplayTestTreeMethod testTree, void *closureP, unsigned long closureS)`` +``Bool SplayFindFirst(Tree *nodeReturn, SplayTree splay, SplayTestNodeMethod testNode, SplayTestTreeMethod testTree, void *closureP, Size closureS)`` -_`.function.splay.find.first`: ``SplayFindFirst()`` finds the first node -in the tree that satisfies some client property (as determined by the -``testNode`` and ``testTree`` methods) (see `.req.property.find`_). -``closureP`` and ``closureS`` are arbitrary values, and are passed to -the ``testNode`` and ``testTree`` methods which may use the values as -closure environments. If there is no satisfactory node, then ``FALSE`` -is returned, otherwise ``*nodeReturn`` is set to the node. (See -`.usage.delete`_ for an example use). +_`.function.splay.find.first`: Find the first node in the tree that +satisfies some client property, as determined by the ``testNode`` and +``testTree`` methods (see `.req.property.find`_). ``closureP`` and +``closureS`` are arbitrary values, and are passed to the ``testNode`` +and ``testTree`` methods which may use the values as closure +environments. If there is no satisfactory node, return ``FALSE``; +otherwise set ``*nodeReturn`` to the node and return ``TRUE``. See +`.usage.delete`_ for an example. -``Bool SplayFindFirst(Tree *nodeReturn, SplayTree splay, SplayTestNodeMethod testNode, SplayTestTreeMethod testTree, void *closureP, unsigned long closureS)`` +``Bool SplayFindLast(Tree *nodeReturn, SplayTree splay, SplayTestNodeMethod testNode, SplayTestTreeMethod testTree, void *closureP, Size closureS)`` -_`.function.splay.find.last`: ``SplayFindLast()`` finds the last node -in the tree that satisfies some client property (as determined by the -``testNode`` and ``testTree`` methods) (see `.req.property.find`_). -``closureP`` and ``closureS`` are arbitrary values, and are passed to -the ``testNode`` and ``testTree`` methods which may use the values as -closure environments. If there is no satisfactory node, then ``FALSE`` -is returned, otherwise ``*nodeReturn`` is set to the node. +_`.function.splay.find.last`: As ``SplayFindFirst()``, but find the +last node in the tree that satisfies the client property. -``void SplayNodeRefresh(SplayTree splay, Tree tree, void *key)`` +``void SplayNodeRefresh(SplayTree splay, Tree tree, TreeKey key)`` -_`.function.splay.node.refresh`: ``SplayNodeRefresh()`` must be called -whenever the client property (see `.prop`_) at a node changes (see -`.req.property.change`_). It will call the ``updateNode`` method on -the given node, and any other nodes that may require update. The +_`.function.splay.node.refresh`: Call the ``updateNode`` method on the +given node, and on any other nodes that may require updating. The client key for the node must also be supplied; the function splays the -tree at this key. (See `.usage.insert`_ for an example use). +tree at this key. (See `.usage.insert`_ for an example use). This +function must be called whenever the client property (see `.prop`_) at +a node changes (see `.req.property.change`_). + +``void SplayNodeUpdate(SplayTree splay, Tree node)`` + +_`.function.splay.node.update`: Call the ``updateNode`` method on the +given node, but leave other nodes unchanged. This may be called when a +new node is created, to get the client property off the ground. Client-determined properties @@ -386,7 +404,7 @@ tree at the specified node, which may provoke calls to the ``updateNode`` method will also be called whenever a new splay node is inserted into the tree. -_`.prop.example`: For example, if implementing an address ordered tree +_`.prop.example`: For example, if implementing an address-ordered tree of free blocks using a splay tree, a client might choose to use the base address of each block as the key for each node, and the size of each block as the client property. The client can then maintain as a @@ -396,7 +414,7 @@ last block of at least a given size. See `.usage.callback`_ for an example ``updateNode`` method for such a client. _`.prop.ops`: The splay operations must cause client properties for -nodes to be updated in the following circumstances:- (see `.impl`_ for +nodes to be updated in the following circumstances (see `.impl`_ for details): _`.prop.ops.rotate`: rotate left, rotate right -- We need to update @@ -424,8 +442,7 @@ right trees. For the left tree, we traverse the right child line, reversing pointers, until we reach the node that was the last node prior to the transplantation of the root's children. Then we update from that node back to the left tree's root, restoring pointers. -Updating the right tree is the same, mutatis mutandis. (See -`.future.reverse`_ for an alternative approach). +Updating the right tree is the same, mutatis mutandis. Usage @@ -443,16 +460,16 @@ _`.usage.client-tree`: Tree structure to embed a ``SplayTree`` (see /* no obvious client fields for this simple example */ } FreeTreeStruct; -_`.usage.client-node`: Node structure to embed a Tree (see `.type.splay.node`_):: +_`.usage.client-node`: Node structure to embed a ``Tree`` (see `.type.tree`_):: typedef struct FreeBlockStruct { - TreeStruct treeStruct; /* embedded splay node */ - Addr base; /* base address of block is also the key */ - Size size; /* size of block is also the client property */ - Size maxSize; /* cached value for maximum size in subtree */ + TreeStruct treeStruct; /* embedded splay node */ + Addr base; /* base address of block is also the key */ + Size size; /* size of block is also the client property */ + Size maxSize; /* cached value for maximum size in subtree */ } FreeBlockStruct; -_`.usage.callback`: updateNode callback method (see +_`.usage.callback`: ``updateNode`` callback method (see `.type.splay.update.node.method`_):: void FreeBlockUpdateNode(SplayTree splay, Tree tree) @@ -462,18 +479,18 @@ _`.usage.callback`: updateNode callback method (see /* the cached value for the left subtree (if any) and the cached */ /* value of the right subtree (if any) */ - FreeBlock freeNode = FreeBlockOfSplayNode(tree); + FreeBlock freeNode = FreeBlockOfTree(tree); Size maxSize = freeNode.size; if (TreeHasLeft(tree)) { - FreeBlock leftNode = FreeBlockOfSplayNode(TreeLeft(tree)); + FreeBlock leftNode = FreeBlockOfTree(TreeLeft(tree)); if(leftNode.maxSize > maxSize) maxSize = leftNode->maxSize; } if (TreeHasRight(tree)) { - FreeBlock rightNode = FreeBlockOfSplayNode(TreeRight(tree)); + FreeBlock rightNode = FreeBlockOfTree(TreeRight(tree)); if(rightNode.maxSize > maxSize) maxSize = rightNode->maxSize; } @@ -481,13 +498,13 @@ _`.usage.callback`: updateNode callback method (see freeNode->maxSize = maxSize; } -_`.usage.compare`: Comparison function (see `.type.splay.compare.method`_):: +_`.usage.compare`: Comparison function (see `.type.tree.compare.method`_):: Compare FreeBlockCompare(Tree tree, TreeKey key) { Addr base1, base2, limit2; - FreeBlock freeNode = FreeBlockOfSplayNode(tree); + FreeBlock freeNode = FreeBlockOfTree(tree); - base1 = (Addr *)key; + base1 = (Addr)key; base2 = freeNode->base; limit2 = AddrAdd(base2, freeNode->size); @@ -503,13 +520,13 @@ _`.usage.test.tree`: Test tree function (see `.type.splay.test.tree.method`_):: Bool FreeBlockTestTree(SplayTree splay, Tree tree - void *closureP, unsigned long closureS) { + void *closureP, Size closureS) { /* Closure environment has wanted size as value of closureS. */ /* Look at the cached value for the node to see if any */ /* blocks in the subtree are big enough. */ - Size size = (Size)closureS; - FreeBlock freeNode = FreeBlockOfSplayNode(tree); + Size size = closureS; + FreeBlock freeNode = FreeBlockOfTree(tree); return freeNode->maxSize >= size; } @@ -517,30 +534,30 @@ _`.usage.test.node`: Test node function (see `.type.splay.test.node.method`_):: Bool FreeBlockTestNode(SplayTree splay, Tree tree - void *closureP, unsigned long closureS) { + void *closureP, Size closureS) { /* Closure environment has wanted size as value of closureS. */ /* Look at the size of the node to see if is big enough. */ - Size size = (Size)closureS; - FreeBlock freeNode = FreeBlockOfSplayNode(tree); + Size size = closureS; + FreeBlock freeNode = FreeBlockOfTree(tree); return freeNode->size >= size; } _`.usage.initialization`: Client's initialization function (see `.function.splay.tree.init`_):: - void FreeTreeInit(FreeTree tree) { + void FreeTreeInit(FreeTree freeTree) { /* Initialize the embedded splay tree. */ - SplayTreeInit(&tree->splayTree, FreeBlockCompare, FreeBlockUpdateNode); + SplayTreeInit(&freeTree->splayTree, FreeBlockCompare, FreeBlockUpdateNode); } _`.usage.insert`: Client function to add a new free block into the tree, merging it with an existing block if possible:: - void FreeTreeInsert(FreeTree tree, Addr base, Addr limit) { - SplayTree splayTree = &tree->splayTree; + void FreeTreeInsert(FreeTree freeTree, Addr base, Addr limit) { + SplayTree splayTree = &freeTree->splayTree; Tree leftNeighbour, rightNeighbour; - void *key = (void *)base; /* use the base of the block as the key */ + TreeKey key = base; /* use the base of the block as the key */ Res res; /* Look for any neighbouring blocks. (.function.splay.tree.neighbours) */ @@ -556,7 +573,7 @@ tree, merging it with an existing block if possible:: /* The client housekeeping is left as an exercise to the reader. */ /* This changes the size of a block, which is the client */ /* property of the splay node. See `.function.splay.node.refresh`_ */ - SplayNodeRefresh(tree, leftNeighbour, key); + SplayNodeRefresh(splayTree, leftNeighbour, key); } else if (rightNeighbour != TreeEMPTY && FreeBlockBaseOfSplayNode(rightNeighbour) == limit) { @@ -564,18 +581,19 @@ tree, merging it with an existing block if possible:: /* The client housekeeping is left as an exercise to the reader. */ /* This changes the size of a block, which is the client */ /* property of the splay node. See `.function.splay.node.refresh`_ */ - SplayNodeRefresh(tree, rightNeighbour, key); + SplayNodeRefresh(splayTree, rightNeighbour, key); } else { /* Not contiguous - so insert a new node */ FreeBlock newBlock = (FreeBlock)allocate(sizeof(FreeBlockStruct)); - splayNode = &newBlock->splayNode; + Tree newTree = &newBlock->treeStruct; newBlock->base = base; newBlock->size = AddrOffset(base, limit); - SplayNodeInit(splayNode); /* `.function.splay.node.init`_ */ + TreeInit(newTree); /* `.function.tree.init`_ */ + SplayNodeUpdate(splayTree, newTree); /* `.function.splay.node.update`_ */ /* `.function.splay.tree.insert`_ */ - res = SplayTreeInsert(splayTree, splayNode, key); + res = SplayTreeInsert(splayTree, newTree, key); AVER(res == ResOK); /* this client doesn't duplicate free blocks */ } } @@ -585,8 +603,8 @@ given size in address order. For simplicity, this allocates the entire block:: Bool FreeTreeAllocate(Addr *baseReturn, Size *sizeReturn, - FreeTree tree, Size size) { - SplayTree splayTree = &tree->splayTree; + FreeTree freeTree, Size size) { + SplayTree splayTree = &freeTree->splayTree; Tree splayNode; Bool found; @@ -594,10 +612,10 @@ block:: /* closureP parameter is not used. See `.function.splay.find.first.`_ */ found = SplayFindFirst(&splayNode, splayTree, FreeBlockTestNode, FreeBlockTestTree, - NULL, (unsigned long)size); + NULL, size); if (found) { - FreeBlock freeNode = FreeBlockOfSplayNode(splayNode); + FreeBlock freeNode = FreeBlockOfTree(splayNode); Void *key = (void *)freeNode->base; /* use base of block as the key */ Res res; @@ -605,7 +623,7 @@ block:: *baseReturn = freeNode->base; *sizeReturn = freeNode->size; - /* remove the node from the splay tree - `.function.splay.tree.delete`_ */ + /* `.function.splay.tree.delete`_ */ res = SplayTreeDelete(splayTree, splayNode, key); AVER(res == ResOK); /* Must be possible to delete node */ @@ -624,9 +642,9 @@ block:: Implementation -------------- -_`.impl`: For more details of how splay trees work, see paper.st85(0). +_`.impl`: For more details of how splay trees work, see [ST85]_. For more details of how to implement operations on splay trees, see -paper.sleator96(0). Here we describe the operations involved. +[Sleator96]_. Here we describe the operations involved. Top-down splaying @@ -634,22 +652,21 @@ Top-down splaying _`.impl.top-down`: The method chosen to implement the splaying operation is called "top-down splay". This is described as "procedure -top-down splay" in paper.st85(0) - although the implementation here -additionally permits attempts to access items which are not known to -be in the tree. Top-down splaying is particularly efficient for the -common case where the location of the node in a tree is not known at -the start of an operation. Tree restructuring happens as the tree is -descended, whilst looking for the node. +top-down splay" in [ST85]_, but the implementation here additionally +permits attempts to access items which are not known to be in the +tree. Top-down splaying is particularly efficient for the common case +where the location of the node in a tree is not known at the start of +an operation. Tree restructuring happens as the tree is descended, +whilst looking for the node. _`.impl.splay`: The key to the operation of the splay tree is the internal function ``SplaySplay()``. It searches the tree for a node -with a given key. In the process, it -brings the found node, or an arbitrary neighbour if not found, to the -root of the tree. This "bring-to-root" operation is performed top-down -during the search, and it is not the simplest possible bring-to-root -operation, but the resulting tree is well-balanced, and will give good -amortised cost for future calls to ``SplaySplay()``. (See -paper.st85(0)) +with a given key. In the process, it brings the found node, or an +arbitrary neighbour if not found, to the root of the tree. This +"bring-to-root" operation is performed top-down during the search, and +it is not the simplest possible bring-to-root operation, but the +resulting tree is well-balanced, and will give good amortised cost for +future calls to ``SplaySplay()``. See [ST85]_. _`.impl.splay.how`: To perform this top-down splay, the tree is broken into three parts, a left tree, a middle tree and a right tree. We @@ -663,25 +680,28 @@ they form a partition with the ordering left, middle, right. The splay is then performed by comparing the middle tree with the following six cases, and performing the indicated operations, until none apply. -_`.impl.splay.cases`: Note that paper.st85(0)(Fig. 3) describes only 3 -cases: zig, zig-zig and zig-zag. The additional cases described here -are the symmetric variants which are respectively called zag, zag-zag -and zag-zig. In the descriptions of these cases, ``root`` is the root -of the middle tree; ``node->left`` is the left child of ``node``; -``node->right`` is the right child of ``node``. The comparison -operators (``<``, ``>``, ``==``) are defined to compare a key and a -node in the obvious way by comparing the supplied key with the node's -associated key. +_`.impl.splay.cases`: Note that figure 3 of [ST85]_ describes only 3 +cases: *zig*, *zig-zig* and *zig-zag*. The additional cases described +here are the symmetric variants which are respectively called *zag*, +*zag-zag* and *zag-zig*. In the descriptions of these cases, ``root`` +is the root of the middle tree; ``node->left`` is the left child of +``node``; ``node->right`` is the right child of ``node``. The +comparison operators (``<``, ``>``, ``==``) are defined to compare a +key and a node in the obvious way by comparing the supplied key with +the node's associated key. -_`.impl.splay.zig`: The "zig" case is where ``key < root``, and either: +_`.impl.splay.zig`: The "zig" case is where ``key < root``, and +either: - ``key == root->left``; - ``key < root->left && root->left->left == NULL``; or - ``key > root->left && root->left->right == NULL``. -The operation for the zig case is: link right (see `.impl.link.right`_). +The operation for the zig case is: link right (see +`.impl.link.right`_). -_`.impl.splay.zag`: The "zag" case is where ``key > root``, and either: +_`.impl.splay.zag`: The "zag" case is where ``key > root``, and +either: - ``key == root->right``; - ``key < root->right && root->right->left == NULL``; or @@ -740,48 +760,58 @@ _`.impl.splay.terminal.not-found`: The other typical terminal cases are: - ``key < root && root->left == NULL``; and - ``key > root && root->right == NULL``. -In these cases, the splay operation is complete, the three trees are assembled -(see `.impl.assemble`_), and "not found" is returned. +In these cases, the splay operation is complete, the three trees are +assembled (see `.impl.assemble`_), and "not found" is returned. -_`.impl.rotate.left`: The "rotate left" operation (see paper.st85(0) -Fig. 1) rearranges the middle tree as follows (where any of sub-trees +_`.impl.rotate.left`: The "rotate left" operation (see [ST85]_ +figure 1) rearranges the middle tree as follows (where any of sub-trees A, B and C may be empty): -[missing diagram] +.. figure:: splay-rotate-left.svg + :align: center + :alt: Diagram: the rotate left operation. -_`.impl.rotate.right`: The "rotate right" operation (see paper.st85(0) -Fig. 1) rearranges the middle tree as follows (where any of sub-trees +_`.impl.rotate.right`: The "rotate right" operation (see [ST85]_ +figure 1) rearranges the middle tree as follows (where any of sub-trees A, B and C may be empty): -[missing diagram] +.. figure:: splay-rotate-right.svg + :align: center + :alt: Diagram: the rotate right operation. -_`.impl.link.left`: The "link left" operation (see paper.st85(0) Fig. +_`.impl.link.left`: The "link left" operation (see [ST85]_ figure 11a for symmetric variant) rearranges the left and middle trees as follows (where any of sub-trees A, B, L and R may be empty): -[missing diagram] +.. figure:: splay-link-left.svg + :align: center + :alt: Diagram: the link left operation. The last node of the left tree is now x. -_`.impl.link.right`: The "link right" operation (see paper.st85(0) -Fig. 11a) rearranges the middle and right trees as follows (where any -of sub-trees A, B, L and R may be empty): +_`.impl.link.right`: The "link right" operation (see [ST85]_ figure +11a) rearranges the middle and right trees as follows (where any of +sub-trees A, B, L and R may be empty): -[missing diagram] +.. figure:: splay-link-right.svg + :align: center + :alt: Diagram: the link left operation. The first node of the right tree is now x. -_`.impl.assemble`: The "assemble" operation (see paper.st85(0) -Fig. 12) merges the left and right trees with the middle tree as -follows (where any of sub-trees A, B, L and R may be empty): +_`.impl.assemble`: The "assemble" operation (see [ST85]_ figure 12) +merges the left and right trees with the middle tree as follows (where +any of sub-trees A, B, L and R may be empty): -[missing diagram] +.. figure:: splay-assemble.svg + :align: center + :alt: Diagram: the assemble operation. Top-level operations .................... -_`.impl.insert`: ``SplayTreeInsert()``: (See paper.sleator96(0), chapter +_`.impl.insert`: ``SplayTreeInsert()``: (See [Sleator96]_, chapter 4, function insert). If the tree has no nodes, [how does it smell?] add the inserted node and we're done; otherwise splay the tree around the supplied key. If the splay successfully found a matching node, @@ -790,7 +820,7 @@ the old (newly splayed, but non-matching) root as its left or right child as appropriate, and the opposite child of the old root as the other child of the new root. -_`.impl.delete`: ``SplayTreeDelete()``: (See paper.sleator96(0), chapter +_`.impl.delete`: ``SplayTreeDelete()``: (See [Sleator96]_, chapter 4, function delete). Splay the tree around the supplied key. Check that the newly splayed root is the same node as given by the caller, and that it matches the key; return failure if not. If the given node @@ -877,8 +907,8 @@ _`.future.parent`: The iterator could be made more efficient (in an amortized sense) if it didn't splay at each node. To implement this (whilst meeting `.req.stack`_) we really need parent pointers from the nodes. We could use the (first-child, right-sibling/parent) trick -described in paper.st85 to implement this, at a slight cost to all -other tree operations, and an increase in code complexity. paper.st85 +described in [ST85]_ to implement this, at a slight cost to all +other tree operations, and an increase in code complexity. [ST85]_ doesn't describe how to distinguish the first-child between left-child and right-child, and the right-sibling/parent between right-sibling and parent. One could either use the comparator to make these diff --git a/mps/manual/source/mmref/bib.rst b/mps/manual/source/bib.rst similarity index 72% rename from mps/manual/source/mmref/bib.rst rename to mps/manual/source/bib.rst index e330ad8a568..f32b6d33422 100644 --- a/mps/manual/source/mmref/bib.rst +++ b/mps/manual/source/bib.rst @@ -7,7 +7,7 @@ Bibliography Ole Agesen, David L. Detlefs. 1997. "`Finding References in Java Stacks `_". Sun Labs. OOPSLA97 Workshop on Garbage Collection and Memory Management. - .. abstract: ad97.html + .. admonition:: Abstract Exact garbage collection for the strongly-typed Java language may seem straightforward. Unfortunately, a single pair of bytecodes in @@ -22,7 +22,7 @@ Bibliography Ole Agesen, David L. Detlefs, J. Eliot B. Moss. 1998. "`Garbage Collection and Local Variable Type-precision and Liveness in Java Virtual Machines `_". ACM. Proceedings of the ACM SIGPLAN '98 conference on Programming language design and implementation, pp. 269--279. - .. abstract: adm98.html + .. admonition:: Abstract Full precision in garbage collection implies retaining only those heap allocated objects that will actually be used in the future. @@ -55,7 +55,7 @@ Bibliography Andrew Appel, John R. Ellis, Kai Li. 1988. "`Real-time Concurrent Collection on Stock Multiprocessors `_". ACM, SIGPLAN. ACM PLDI 88, SIGPLAN Notices 23, 7 (July 88), pp. 11--20. - .. abstract: ael88.html + .. admonition:: Abstract We've designed and implemented a copying garbage-collection algorithm that is efficient, real-time, concurrent, runs on @@ -73,9 +73,9 @@ Bibliography Apple Computer, Inc. 1994. *Inside Macintosh: Memory*. Addison-Wesley. ISBN 0-201-63240-3. - .. abstract: apple94.html + .. admonition:: Abstract - Inside Macintosh: Memory describes the parts of the Macintosh® + Inside Macintosh: Memory describes the parts of the Macintosh® Operating System that allow you to directly allocate, release, or otherwise manipulate memory. Everyone who programs Macintosh computers should read this book. @@ -90,7 +90,7 @@ Bibliography Giuseppe Attardi & Tito Flagella. 1994. "`A Customisable Memory Management Framework `_". TR-94-010. - .. abstract: attardi94.html + .. admonition:: Abstract Memory management is a critical issue for many large object-oriented applications, but in C++ only explicit memory @@ -114,7 +114,7 @@ Bibliography Giuseppe Attardi, Tito Flagella, Pietro Iglio. 1998. "`A customisable memory management framework for C++ `_". Software -- Practice and Experience. 28(11), 1143--1183. - .. abstract: afi98.html + .. admonition:: Abstract Automatic garbage collection relieves programmers from the burden of managing memory themselves and several techniques have been @@ -150,7 +150,7 @@ Bibliography Alain Azagury, Elliot K. Kolodner, Erez Petrank, Zvi Yehudai. 1998. "`Combining Card Marking with Remembered Sets: How to Save Scanning Time `_". ACM. ISMM'98 pp. 10--19. - .. abstract: akpy98.html + .. admonition:: Abstract We consider the combination of card marking with remembered sets for generational garbage collection as suggested by Hosking and @@ -167,7 +167,7 @@ Bibliography Henry G. Baker, Carl Hewitt. 1977. "`The Incremental Garbage Collection of Processes `_". ACM. SIGPLAN Notices 12, 8 (August 1977), pp. 55--59. - .. abstract: baker77.html + .. admonition:: Abstract This paper investigates some problems associated with an argument evaluation order that we call "future" order, which is different @@ -201,7 +201,7 @@ Bibliography Henry G. Baker. 1978. "`List Processing in Real Time on a Serial Computer `_". ACM. Communications of the ACM 21, 4 (April 1978), pp. 280--294. - .. abstract: baker78.html + .. admonition:: Abstract A real-time list processing system is one in which the time required by the elementary list operations (e.g. CONS, CAR, CDR, @@ -227,7 +227,7 @@ Bibliography Henry G. Baker. 1979. "`Optimizing Allocation and Garbage Collection of Spaces `_". In Winston and Brown, eds. *Artificial Intelligence: An MIT Perspective.* MIT Press. - .. abstract: baker79.html + .. admonition:: Abstract MACLISP, unlike some other implementations of LISP, allocates storage for different types of objects in noncontiguous areas @@ -258,7 +258,7 @@ Bibliography Henry G. Baker. 1991. "`Cache-Conscious Copying Collectors `_". OOPSLA'91/GC'91 Workshop on Garbage Collection. - .. abstract: baker91.html + .. admonition:: Abstract Garbage collectors must minimize the scarce resources of cache space and off-chip communications bandwidth to optimize @@ -272,7 +272,7 @@ Bibliography Henry G. Baker. 1992. "`Lively Linear Lisp -- 'Look Ma, No Garbage!' `_". ACM. SIGPLAN Notices 27, 8 (August 1992), pp. 89--98. - .. abstract: baker92a.html + .. admonition:: Abstract Linear logic has been proposed as one solution to the problem of garbage collection and providing efficient "update-in-place" @@ -297,7 +297,7 @@ Bibliography Henry G. Baker. 1992. "`The Treadmill: Real-Time Garbage Collection Without Motion Sickness `_". ACM. SIGPLAN Notices 27, 3 (March 1992), pp. 66--70. - .. abstract: baker92c.html + .. admonition:: Abstract A simple real-time garbage collection algorithm is presented which does not copy, thereby avoiding some of the problems caused by the @@ -312,7 +312,7 @@ Bibliography Henry G. Baker. 1992. "`CONS Should not CONS its Arguments, or, a Lazy Alloc is a Smart Alloc `_". ACM. SIGPLAN Notices 27, 3 (March 1992), 24--34. - .. abstract: baker92.html + .. admonition:: Abstract "Lazy allocation" is a model for allocating objects on the execution stack of a high-level language which does not create @@ -359,7 +359,7 @@ Bibliography Henry G. Baker. 1992. "`NREVERSAL of Fortune -- The Thermodynamics of Garbage Collection `_". Springer-Verlag. LNCS Vol. 637. - .. abstract: baker92b.html + .. admonition:: Abstract The need to *reverse* a computation arises in many contexts -- debugging, editor undoing, optimistic concurrency undoing, @@ -407,7 +407,7 @@ Bibliography Henry G. Baker. 1993. "`'Infant Mortality' and Generational Garbage Collection `_". ACM. SIGPLAN Notices 28, 4 (April 1993), pp. 55--57. - .. abstract: baker93.html + .. admonition:: Abstract Generation-based garbage collection has been advocated by appealing to the intuitive but vague notion that "young objects @@ -427,7 +427,7 @@ Bibliography Henry G. Baker. 1993. "`Equal Rights for Functional Objects or, The More Things Change, The More They Are the Same `_". ACM. OOPS Messenger 4, 4 (October 1993), pp. 2--27. - .. abstract: baker93a.html + .. admonition:: Abstract We argue that intensional object identity in object-oriented programming languages and databases is best defined operationally @@ -450,7 +450,7 @@ Bibliography Henry G. Baker. 1994. "`Minimizing Reference Count Updating with Deferred and Anchored Pointers for Functional Data Structures `_". ACM. SIGPLAN Notices 29, 9 (September 1994), pp. 38--43. - .. abstract: baker94.html + .. admonition:: Abstract "Reference counting" can be an attractive form of dynamic storage management. It recovers storage promptly and (with a garbage stack @@ -481,7 +481,7 @@ Bibliography Henry G. Baker. 1994. "`Thermodynamics and Garbage Collection `_". ACM. SIGPLAN Notices 29, 4 (April 1994), pp. 58--63. - .. abstract: baker94a.html + .. admonition:: Abstract We discuss the principles of statistical thermodynamics and their application to storage management problems. We point out problems @@ -492,7 +492,7 @@ Bibliography Henry G. Baker. 1995. "`'Use-Once' Variables and Linear Objects -- Storage Management, Reflection and Multi-Threading `_". ACM. SIGPLAN Notices 30, 1 (January 1995), pp. 45--52. - .. abstract: baker95a.html + .. admonition:: Abstract Programming languages should have 'use-once' variables in addition to the usual 'multiple-use' variables. 'Use-once' variables are @@ -532,23 +532,44 @@ Bibliography Henry G. Baker. 1995. *Memory Management: International Workshop IWMM'95*. Springer-Verlag. ISBN 3-540-60368-9. - .. abstract: baker95.html + .. admonition:: From the Preface - [from the preface] The International Workshop on Memory Management - 1995 (IWMM'95) is a continuation of the excellent series started - by Yves Bekkers and Jacques Cohen with IWMM'92. The present volume - assembles the refereed and invited technical papers which were - presented during this year's workshop. + The International Workshop on Memory Management 1995 (IWMM'95) is + a continuation of the excellent series started by Yves Bekkers and + Jacques Cohen with IWMM'92. The present volume assembles the + refereed and invited technical papers which were presented during + this year's workshop. * .. _BBW97: - Nick Barnes, Richard Brooksby, David Jones, Gavin Matthews, Pekka P. Pirinen, Nick Dalton, P. Tucker Withington. 1997. "`A Proposal for a Standard Memory Management Interface `_". OOPSLA97 Workshop on Garbage Collection and Memory Management. + Nick Barnes, Richard Brooksby, David Jones, Gavin Matthews, Pekka P. Pirinen, Nick Dalton, P. Tucker Withington. 1997. "`A Proposal for a Standard Memory Management Interface `_". OOPSLA97 Workshop on Garbage Collection and Memory Management. + + .. admonition:: From the notes + + There is no well-defined memory-management library API which would + allow programmers to easily choose the best memory management + implementation for their application. + + Some languages allow replacement of their memory management + functions, but usually only the program API is specified, hence + replacement of the entire program interface is required. + + Few languages support multiple memory management policies within a + single program. Those that do use proprietary memory management + policies. + + We believe that the design of an abstract program API is a + prerequisite to the design of a “server” API and eventually an API + that would permit multiple cooperating memory “servers”. If the + interface is simple yet powerful enough to encompass most memory + management systems, it stands a good chance of being widely + adopted. * .. _ZORN93B: David A. Barrett, Benjamin Zorn. 1993. "`Using Lifetime Predictors to Improve Memory Allocation Performance `_". ACM. SIGPLAN'93 Conference on Programming Language Design and Implementation, pp. 187--196. - .. abstract: zorn93b.html + .. admonition:: Abstract Dynamic storage allocation is used heavily in many application areas including interpreters, simulators, optimizers, and @@ -556,9 +577,9 @@ Bibliography the performance of dynamic storage allocation by predicting the lifetimes of short-lived objects when they are allocated. Using five significant, allocation-intensive C programs, we show that a - great fraction of all bytes allocated are short-lived (> 90% in + great fraction of all bytes allocated are short-lived (> 90% in all cases). Furthermore, we describe an algorithm for lifetime - prediction that accurately predicts the lifetimes of 42-99% of all + prediction that accurately predicts the lifetimes of 42--99% of all objects allocated. We describe and simulate a storage allocator that takes advantage of lifetime prediction of short-lived objects and show that it can significantly improve a program's memory @@ -569,7 +590,7 @@ Bibliography David A. Barrett, Benjamin Zorn. 1995. "`Garbage Collection using a Dynamic Threatening Boundary `_". ACM. SIGPLAN'95 Conference on Programming Language Design and Implementation, pp. 301--314. - .. abstract: barrett93.html + .. admonition:: Abstract Generational techniques have been very successful in reducing the impact of garbage collection algorithms upon the performance of @@ -604,7 +625,7 @@ Bibliography Joel F. Bartlett. 1988. "`Compacting Garbage Collection with Ambiguous Roots `_". Digital Equipment Corporation. - .. abstract: bartlett88.html + .. admonition:: Abstract This paper introduces a copying garbage collection algorithm which is able to compact most of the accessible storage in the heap @@ -644,7 +665,7 @@ Bibliography Joel F. Bartlett. 1989. "`Mostly-Copying Garbage Collection Picks Up Generations and C++ `_". Digital Equipment Corporation. - .. abstract: bartlett89.html + .. admonition:: Abstract The "mostly-copying" garbage collection algorithm provides a way to perform compacting garbage collection in spite of the presence @@ -665,7 +686,7 @@ Bibliography Emery D. Berger, Robert D. Blumofe. 1999. "`Hoard: A Fast, Scalable, and Memory-Efficient Allocator for Shared-Memory Multiprocessors `_". University of Texas at Austin. UTCS TR99-22. - .. abstract: bb99.html + .. admonition:: Abstract In this paper, we present Hoard, a memory allocator for shared-memory multiprocessors. We prove that its worst-case memory @@ -677,11 +698,39 @@ Bibliography Emery D. Berger, Benjamin G. Zorn, Kathryn S. McKinley. 2001. "`Composing high-performance memory allocators `_" ACM SIGPLAN Conference on Programming Language Design and Implementation 2001, pp. 114--124. + .. admonition:: Abstract + + Current general-purpose memory allocators do not provide + sufficient speed or flexibility for modern high-performance + applications. Highly-tuned general purpose allocators have + per-operation costs around one hundred cycles, while the cost of + an operation in a custom memory allocator can be just a handful of + cycles. To achieve high performance, programmers often write + custom memory allocators from scratch -- a difficult and + error-prone process. + + In this paper, we present a flexible and efficient infrastructure + for building memory allocators that is based on C++ templates and + inheritance. This novel approach allows programmers to build + custom and general-purpose allocators as “heap layers” that can be + composed without incurring any additional runtime overhead or + additional programming cost. We show that this infrastructure + simplifies allocator construction and results in allocators that + either match or improve the performance of heavily-tuned + allocators written in C, including the Kingsley allocator and the + GNU obstack library. We further show this infrastructure can be + used to rapidly build a general-purpose allocator that has + performance comparable to the Lea allocator, one of the best + uniprocessor allocators available. We thus demonstrate a clean, + easy-to-use allocator interface that seamlessly combines the power + and efficiency of any number of general and custom allocators + within a single application. + * .. _BW88: Hans-J. Boehm, Mark Weiser. 1988. "`Garbage collection in an uncooperative environment `_". Software -- Practice and Experience. 18(9):807--820. - .. abstract: bw88.html + .. admonition:: Abstract We describe a technique for storage allocation and garbage collection in the absence of significant co-operation from the @@ -699,7 +748,7 @@ Bibliography Hans-J. Boehm, Alan J. Demers, Scott Shenker. 1991. "`Mostly Parallel Garbage Collection `_". Xerox PARC. ACM PLDI 91, SIGPLAN Notices 26, 6 (June 1991), pp. 157--164. - .. abstract: bds91.html + .. admonition:: Abstract We present a method for adapting garbage collectors designed to run sequentially with the client, so that they may run @@ -712,13 +761,26 @@ Bibliography * .. _BC92A: - Hans-J. Boehm, David Chase. 1992. "A Proposal for Garbage-Collector-Safe C Compilation". *Journal of C Language Translation.* vol. 4, 2 (December 1992), pp. 126--141. + Hans-J. Boehm, David Chase. 1992. "`A Proposal for Garbage-Collector-Safe C Compilation `_". *Journal of C Language Translation.* vol. 4, 2 (December 1992), pp. 126--141. + + .. admonition:: Abstract + + Conservative garbage collectors are commonly used in combination + with conventional C programs. Empirically, this usually works + well. However, there are no guarantees that this is safe in the + presence of "improved" compiler optimization. We propose that C + compilers provide a facility to suppress optimizations that are + unsafe in the presence of conservative garbage collection. Such a + facility can be added to an existing compiler at very minimal + cost, provided the additional analysis is done in a + machine-independent source-to-source prepass. Such a prepass may + also check the source code for garbage-collector-safety. * .. _BOEHM93: Hans-J. Boehm. 1993. "`Space Efficient Conservative Garbage Collection `_". ACM, SIGPLAN. Proceedings of the ACM SIGPLAN '91 Conference on Programming Language Design and Implementation, SIGPLAN Notices 28, 6, pp 197--206. - .. abstract: boehm93.html + .. admonition:: Abstract We call a garbage collector conservative if it has only partial information about the location of pointers, and is thus forced to @@ -742,7 +804,7 @@ Bibliography Hans-J. Boehm. 2000. "`Reducing Garbage Collector Cache Misses `_". ACM. ISMM'00 pp. 59--64. - .. abstract: boehm00.html + .. admonition:: Abstract Cache misses are currently a major factor in the cost of garbage collection, and we expect them to dominate in the future. @@ -769,10 +831,57 @@ Bibliography Hans-J. Boehm. 2002. "`Destructors, Finalizers, and Synchronization `_". HP Labs technical report HPL-2002-335. + .. admonition:: Abstract + + We compare two different facilities for running cleanup actions + for objects that are about to reach the end of their life. + Destructors, such as we find in C++, are invoked synchronously + when an object goes out of scope. They make it easier to implement + cleanup actions for objects of well-known lifetime, especially in + the presence of exceptions. Languages like Java, Modula-3, and C# + provide a different kind of "finalization" facility: Cleanup + methods may be run when the garbage collector discovers a heap + object to be otherwise inaccessible. Unlike C++ destructors, such + methods run in a separate thread at some much less well-defined + time. We argue that these are fundamentally different, and + potentially complementary, language facilities. We also try to + resolve some common misunderstandings about finalization in the + process. In particular: 1. The asynchronous nature of finalizers + is not just an accident of implementation or a shortcoming of + tracing collectors; it is necessary for correctness of client + code, fundamentally affects how finalizers must be written, and + how finalization facilities should be presented to the user. 2. An + object may legitimately be finalized while one of its methods are + still running. This should and can be addressed by the language + specification and client code. + * .. _BM77: Robert S. Boyer and J. Strother Moore. 1977. "`A Fast String Searching Algorithm `_". *Communications of the ACM* 20(10):762--772. + .. admonition:: Abstract + + An algorithm is presented that searches for the location, "*i*," + of the first occurrence of a character string, "*pat*," in another + string, "*string*." During the search operation, the characters of + *pat* are matched starting with the last character of *pat*. The + information gained by starting the match at the end of the pattern + often allows the algorithm to proceed in large jumps through the + text being searched. Thus the algorithm has the unusual property + that, in most cases, not all of the first *i* characters of + *string* are inspected. The number of characters actually + inspected (on the average) decreases as a function of the length + of *pat*. For a random English pattern of length 5, the algorithm + will typically inspect *i*/4 characters of string before finding a + match at *i*. Furthermore, the algorithm has been implemented so + that (on the average) fewer than *i* + *patlen* machine + instructions are executed. These conclusions are supported with + empirical evidence and a theoretical analysis of the average + behavior of the algorithm. The worst case behavior of the + algorithm is linear in *i* + *patlen*, assuming the availability + of array space for tables linear in *patlen* plus the size of the + alphabet. + * .. _BL72: P. Branquart, J. Lewi. 1972. "A scheme of storage allocation and garbage collection for ALGOL 68". Elsevier/North-Holland. ALGOL 68 Implementation -- Proceedings of the IFIP Working Conference on ALGOL 68 Implementation, July 1970. @@ -781,6 +890,28 @@ Bibliography Richard Brooksby. 2002. "`The Memory Pool System: Thirty person-years of memory management development goes Open Source `_". ISMM'02. + .. admonition:: Abstract + + The Memory Pool System (MPS) is a very general, adaptable, + flexible, reliable, and efficient memory management system. It + permits the flexible combination of memory management techniques, + supporting manual and automatic memory management, in-line + allocation, finalization, weakness, and multiple simultaneous + co-operating incremental generational garbage collections. It also + includes a library of memory pool classes implementing specialized + memory management policies. + + Between 1994 and 2001, Harlequin (now part of Global Graphics) + invested about thirty person-years of effort developing the MPS. + The system contained many innovative techniques and abstractions + which were kept secret. In 1997 Richard Brooksby, the manager and + chief architect of the project, and Nicholas Barnes, a senior + developer, left Harlequin to form their own consultancy company, + Ravenbrook, and in 2001, Ravenbrook acquired the MPS technology + from Global Graphics. We are happy to announce that we are + publishing the source code and documentation under an open source + licence. This paper gives an overview of the system. + * .. _C1990: International Standard ISO/IEC 9899:1990. "Programming languages — C". @@ -793,7 +924,7 @@ Bibliography Brad Calder, Dirk Grunwald, Benjamin Zorn. 1994. "`Quantifying Behavioral Differences Between C and C++ Programs `_". *Journal of Programming Languages.* 2(4):313--351. - .. abstract: cgz94.html + .. admonition:: Abstract Improving the performance of C programs has been a topic of great interest for many years. Both hardware technology and compiler @@ -816,23 +947,89 @@ Bibliography Dante J. Cannarozzi, Michael P. Plezbert, Ron K. Cytron. 2000. "`Contaminated garbage collection `_". ACM. Proceedings of the ACM SIGPLAN '00 conference on on Programming language design and implementation, pp. 264--273. + .. admonition:: Abstract + + We describe a new method for determining when an object can be + garbage collected. The method does not require marking live + objects. Instead, each object *X* is *dynamically* associated with + a stack frame *M*, such that *X* is collectable when *M* pops. + Because *X* could have been dead earlier, our method is + conservative. Our results demonstrate that the methos nonetheless + idenitifies a large percentage of collectable objects. The method + has been implemented in Sun's Java™ Virtual Machine interpreter, + and results are presented based on this implementation. + * .. _CW86: Patrick J. Caudill, Allen Wirfs-Brock. 1986. "A Third-Generation Smalltalk-80 Implementation". ACM. SIGPLAN Notices. 21(11), OOPSLA'86 ACM Conference on Object-Oriented Systems, Languages and Applications. + .. admonition:: Abstract + + A new, high performance Smalltalk-80™ implementation is described + which builds directly upon two previous implementation efforts. + This implementation supports a large object space while retaining + compatibility with previous Smalltalk-80™ images. The + implementation utilizes a interpreter which incorporates a + generation based garbage collector and which does not have an + object table. This paper describes the design decisions which lead + to this implementation and reports preliminary performance + results. + * .. _CHENEY70: - C. J. Cheney. 1970. "A non-recursive list compacting algorithm". CACM. 13-11 pp. 677--678. + C. J. Cheney. 1970. "`A non-recursive list compacting algorithm `_". CACM. 13-11 pp. 677--678. + + .. admonition:: Abstract + + A simple nonrecursive list structure compacting scheme or garbage + collector suitable for both compact and LISP-like list structures + is presented. The algorithm avoids the need for recursion by using + the partial structure as it is built up to keep track of those + lists that have been copied. * .. _CHL98: Perry Cheng, Robert Harper, Peter Lee. 1998. "`Generational stack collection and profile-driven pretenuring `_". ACM. Proceedings of SIGPLAN'98 Conference on Programming Language Design and Implementation, pp. 162--173. + .. admonition:: Abstract + + This paper presents two techniques for improving garbage + collection performance: generational stack collection and + profile-driven pretenuring. The first is applicable to stack-based + implementations of functional languages while the second is useful + for any generational collector. We have implemented both + techniques in a generational collector used by the TIL compiler, + and have observed decreases in garbage collection times of as much + as 70% and 30%, respectively. + + Functional languages encourage the use of recursion which can lead + to a long chain of activation records. When a collection occurs, + these activation records must be scanned for roots. We show that + scanning many activation records can take so long as to become the + dominant cost of garbage collection. However, most deep stacks + unwind very infrequently, so most of the root information obtained + from the stack remains unchanged across successive garbage + collections. *Generational stack collection* greatly reduces the + stack scan cost by reusing information from previous scans. + + Generational techniques have been successful in reducing the cost + of garbage collection. Various complex heap arrangements and + tenuring policies have been proposed to increase the effectiveness + of generational techniques by reducing the cost and frequency of + scanning and copying. In contrast, we show that by using profile + information to make lifetime predictions, *pretenuring* can avoid + copying data altogether. In essence, this technique uses a + refinement of the generational hypothesis (most data die young) + with a locality principle concerning the age of data: most + allocations sites produce data that immediately dies, while a few + allocation sites consistently produce data that survives many + collections. + * .. _CL98: Trishul M. Chilimbi, James R. Larus. 1998. "`Using Generational Garbage Collection To Implement Cache-Conscious Data Placement `_". ACM. ISMM'98 pp. 37--48. - .. abstract: cl98.html + .. admonition:: Abstract Processor and memory technology trends show a continual increase in the cost of accessing main memory. Machine designers have tried @@ -858,7 +1055,7 @@ Bibliography William D Clinger & Lars T Hansen. 1997. "`Generational Garbage Collection and the Radioactive Decay Model `_". ACM. Proceedings of PLDI 1997. - .. abstract: ch97.html + .. admonition:: Abstract If a fixed exponentially decreasing probability distribution function is used to model every object's lifetime, then the age of @@ -882,7 +1079,7 @@ Bibliography Jacques Cohen. 1981. "Garbage collection of linked data structures". Computing Surveys. Vol. 13, no. 3. - .. abstract: cohen81.html + .. admonition:: Abstract A concise and unified view of the numerous existing algorithms for performing garbage collection of linked data structures is @@ -904,7 +1101,7 @@ Bibliography Dominique Colnet, Philippe Coucaud, Olivier Zendra. 1998. "`Compiler Support to Customize the Mark and Sweep Algorithm `_". ACM. ISMM'98 pp. 154--165. - .. abstract: ccz98.html + .. admonition:: Abstract Mark and sweep garbage collectors (GC) are classical but still very efficient automatic memory management systems. Although @@ -930,7 +1127,7 @@ Bibliography Jonathan E. Cook, Alexander L. Wolf, Benjamin Zorn. 1994. "`Partition Selection Policies in Object Database Garbage Collection `_". ACM. SIGMOD. International Conference on the Management of Data (SIGMOD'94), pp. 371--382. - .. abstract: cwz93.html + .. admonition:: Abstract The automatic reclamation of storage for unreferenced objects is very important in object databases. Existing language system @@ -954,11 +1151,31 @@ Bibliography Jonathan E. Cook, Artur Klauser, Alexander L. Wolf, Benjamin Zorn. 1996. "`Semi-automatic, Self-adaptive Control of Garbage Collection Rates in Object Databases `_". ACM, SIGMOD. International Conference on the Management of Data (SIGMOD'96), pp. 377--388. + .. admonition:: Abstract + + A fundamental problem in automating object database storage + reclamation is determining how often to perform garbage + collection. We show that the choice of collection rate can have a + significant impact on application performance and that the "best" + rate depends on the dynamic behavior of the application, tempered + by the particular performance goals of the user. We describe two + semi-automatic, self-adaptive policies for controlling collection + rate that we have developed to address the problem. Using + trace-driven simulations, we evaluate the performance of the + policies on a test database application that demonstrates two + distinct reclustering behaviors. Our results show that the + policies are effective at achieving user-specified levels of I/O + operations and database garbage percentage. We also investigate + the sensitivity of the policies over a range of object + connectivities. The evaluation demonstrates that semi-automatic, + self-adaptive policies are a practical means for flexibly + controlling garbage collection rate. + * .. _CNS92: Eric Cooper, Scott Nettles, Indira Subramanian. 1992. "Improving the Performance of SML Garbage Collection using Application-Specific Virtual Memory Management". ACM Conference on LISP and Functional Programming, pp. 43--52. - .. abstract: cns92.html + .. admonition:: Abstract We improved the performance of garbage collection in the Standard ML of New Jersey system by using the virtual memory facilities provided by @@ -974,19 +1191,19 @@ Bibliography Michael C. Daconta. 1995. *C++ Pointers and Dynamic Memory Management.* Wiley. ISBN 0-471-04998-0. - .. abstract: daconta95.html + .. admonition:: From the back cover - [from the back cover] Using techniques developed in the classroom - at America Online's Programmer's University, Michael Daconta - deftly pilots programmers through the intricacies of the two most - difficult aspects of C++ programming: pointers and dynamic memory - management. Written by a programmer for programmers, this - no-nonsense, nuts-and-bolts guide shows you how to fully exploit - advanced C++ programming features, such as creating class-specific - allocators, understanding references versus pointers, manipulating - multidimensional arrays with pointers, and how pointers and - dynamic memory are the core of object-oriented constructs like - inheritance, name-mangling, and virtual functions. + Using techniques developed in the classroom at America Online's + Programmer's University, Michael Daconta deftly pilots programmers + through the intricacies of the two most difficult aspects of C++ + programming: pointers and dynamic memory management. Written by a + programmer for programmers, this no-nonsense, nuts-and-bolts guide + shows you how to fully exploit advanced C++ programming features, + such as creating class-specific allocators, understanding + references versus pointers, manipulating multidimensional arrays + with pointers, and how pointers and dynamic memory are the core of + object-oriented constructs like inheritance, name-mangling, and + virtual functions. * .. _DAHL63: @@ -994,25 +1211,91 @@ Bibliography * .. _DENNING68: - P. J. Denning. 1968. "Thrashing: Its Causes and Prevention". Proceedings AFIPS,1968 Fall Joint Computer Conference, vol. 33, pp. 915--922. + P. J. Denning. 1968. "`Thrashing: Its Causes and Prevention `_". Proceedings AFIPS,1968 Fall Joint Computer Conference, vol. 33, pp. 915--922. + + .. admonition:: From the introduction + + A particularly troublesome phenomenon, thrashing, may seriously + interfere with the performance of paged memory systems, reducing + computing giants (Multics, IBM System 360, and others not + necessarily excepted) to computing dwarfs. The term thrashing + denotes excessive overhead and severe performance degradation or + collapse caused by too much paging. Thrashing inevitably turns a + shortage of memory space into a surplus of processor time. * .. _DENNING70: P. J. Denning. 1970. "`Virtual Memory `_". ACM. ACM Computing Surveys, vol. 2, no. 3, pp. 153--190, Sept. 1970. + .. admonition:: Abstract + + The need for automatic storage allocation arises from desires for + program modularity, machine independence, and resource sharing. + Virtual memory is an elegant way of achieving these objectives. In + a virtual memory, the addresses a program may use to identify + information are distinguished from the addresses the memory system + uses to identify physical storage sites, and program-generated + addresses are translated automatically to the corresponding + machine addresses. Two principal methods for implementing virtual + memory, segmentation and paging, are compared and contrasted. Many + contemporary implementations have experienced one or more of these + problems: poor utilization of storage, thrashing, and high costs + associated with loading information into memory. These and + subsidiary problems are studied from a theoretic view, and are + shown to be controllable by a proper combination of hardware and + memory management policies. + * .. _DS72: P. J. Denning, S. C. Schwartz. 1972. "`Properties of the Working-set Model `_". CACM. vol. 15, no. 3, pp. 191--198. + .. admonition:: Abstract + + A program's working set *W*\ (*t*, *T*) at time *t* is the set of + distinct pages among the *T* most recently referenced pages. + Relations between the average working-set size, the missing-page + rate, and the interreference-interval distribution may be derived + both from time-average definitions and from ensemble-average + (statistical) definitions. An efficient algorithm for estimating + these quantities is given. The relation to LRU (least recently + used) paging is characterized. The independent-reference model, in + which page references are statistically independent, is used to + assess the effects of interpage dependencies on working-set size + observations. Under general assumptions, working-set size is shown + to be normally distributed. + * .. _DETLEFS92: David L. Detlefs. 1992. "`Garbage collection and runtime typing as a C++ library `_". USENIX C++ Conference. + .. admonition:: From the introduction + + Automatic storage management, or *garbage collection*, is a + feature that can ease program development and enhance program + reliability. Many high-level languages other than C++ provide + garbage collection. This paper proposes the use of "smart pointer" + template classes as an interface for the use of garbage collection + in C++. Template classes and operator overloading are techniques + allowing language extension at the level of user code; I claim + that using these techniques to create smart pointer classes + provdes a syntax for manipulating garbage-collected storage safely + and conveniently. Further, the use of a smart-pointer template + class offers the possibility of implementing the collector at the + user-level, without requiring support from the compiler. If such a + compiler-independent implementation is possible with adequate + performance, then programmers can start to write code using + garbage collection without waiting for language and compiler + modifications. If the use of such a garbage collection interface + becomes widespread, then C++ compilation systems can be built to + specially support tht garbage collection interface, thereby + allowing the use of collection algorithms with enhanced + performance. + * .. _ZORN93: David L. Detlefs, Al Dosser, Benjamin Zorn. 1994. "`Memory Allocation Costs in Large C and C++ Programs `_". Software -- Practice and Experience. 24(6):527--542. - .. abstract: zorn93.html + .. admonition:: Abstract Dynamic storage allocation is an important part of a large class of computer programs written in C and C++. High-performance @@ -1033,15 +1316,44 @@ Bibliography L. Peter Deutsch, Daniel G. Bobrow. 1976. "`An Efficient, Incremental, Automatic Garbage Collector `_". CACM. vol. 19, no. 9, pp. 522--526. + .. admonition:: Abstract + + This paper describes a new way of solving the storage reclamation + problem for a system such as Lisp that allocates storage + automatically from a heap, and does not require the programmer to + give any indication that particular items are no longer useful or + accessible. A reference count scheme for reclaiming + non-self-referential structures, and a linearizing, compacting, + copying scheme to reorganize all storage at the users discretion + are proposed. The algorithms are designed to work well in systems + which use multiple levels of storage, and large virtual address + space. They depend on the fact that most cells are referenced + exactly once, and that reference counts need only be accurate when + storage is about to be reclaimed. A transaction file stores + changes to reference counts, and a multiple reference table stores + the count for items which are referenced more than once. + * .. _DLMSS76: E. W. Dijkstra, Leslie Lamport, A. J. Martin, C. S. Scholten, E. F. M. Steffens. 1976. "`On-the-fly Garbage Collection: An Exercise in Cooperation `_". Springer-Verlag. Lecture Notes in Computer Science, Vol. 46. + .. admonition:: Abstract + + As an example of cooperation between sequential processes with + very little mutual interference despite frequent manipulations of + a large shared data space, a technique is developed which allows + nearly all of the activity needed for garbage detection and + collection to be performed by an additional processor operating + con- currently with the processor devoted to the computation + proper. Exclusion and synchronization constraints have been kept + as weak as could be achieved; the severe complexities engendered + by doing so are illustrated. + * .. _DMH92: Amer Diwan, Richard L. Hudson, J. Eliot B. Moss. 1992. "`Compiler Support for Garbage Collection in a Statically Typed Language `_". ACM. Proceedings of the 5th ACM SIGPLAN conference on Programming language design and implementation, pp. 273--282. - .. abstract: dmh92.html + .. admonition:: Abstract We consider the problem of supporting compacting garbage collection in the presence of modern compiler optimizations. Since @@ -1064,7 +1376,7 @@ Bibliography Amer Diwan, David Tarditi, J. Eliot B. Moss. 1993. "`Memory Subsystem Performance of Programs with Intensive Heap Allocation `_". Carnegie Mellon University. CMU-CS-93-227. - .. abstract: dtm93.html + .. admonition:: Abstract Heap allocation with copying garbage collection is a general storage management technique for modern programming languages. It @@ -1089,7 +1401,7 @@ Bibliography Amer Diwan, David Tarditi, J. Eliot B. Moss. 1994. "`Memory Subsystem Performance of Programs Using Copying Garbage Collection `_". ACM. CMU-CS-93-210, also in POPL '94. - .. abstract: dtm93a.html + .. admonition:: Abstract Heap allocation with copying garbage collection is believed to have poor memory subsystem performance. We conducted a study of @@ -1103,7 +1415,7 @@ Bibliography Damien Doligez & Xavier Leroy. 1993. "`A concurrent, generational garbage collector for a multithreaded implementation of ML `_". ACM. POPL '93, 113--123. - .. abstract: doligez93.html + .. admonition:: Abstract This paper presents the design and implementation of a "quasi real-time" garbage collector for Concurrent Caml Light, an @@ -1117,7 +1429,7 @@ Bibliography Damien Doligez & Georges Gonthier. 1994. "`Portable, unobtrusive garbage collection for multiprocessor systems `_". ACM. POPL '94, 70--83. - .. abstract: doligez94.html + .. admonition:: Abstract We describe and prove the correctness of a new concurrent mark-and-sweep garbage collection algorithm. This algorithm @@ -1138,7 +1450,7 @@ Bibliography R. Kent Dybvig, Carl Bruggeman, David Eby. 1993. "`Guardians in a Generation-Based Garbage Collector `_". SIGPLAN. Proceedings of the ACM SIGPLAN '93 Conference on Programming Language Design and Implementation, June 1993. - .. abstract: dbe93.html + .. admonition:: Abstract This paper describes a new language feature that allows dynamically allocated objects to be saved from deallocation by an @@ -1155,15 +1467,49 @@ Bibliography Daniel R. Edelson. 1992. "`Smart pointers: They're smart, but they're not pointers `_". USENIX C++ Conference. + .. admonition:: From the introduction + + This paper shows hhow the behaviour of smart pointers diverges + from that of pointers in certain common C++ constructs. Given + this, we conclude that the C++ programming language does not + support seamless smart pointers: smart pointers cannot + transparently replace raw pointers in all ways except declaration + syntax. We show that this conclusion also applies to *accessors*. + * .. _EDELSON92: - Daniel R. Edelson. 1992. "Comparing Two Garbage Collectors for C++". University of California at Santa Cruz. Technical Report UCSC-CRL-93-20. + Daniel R. Edelson. 1992. "`Comparing Two Garbage Collectors for C++ `_". University of California at Santa Cruz. Technical Report UCSC-CRL-93-20. + + .. admonition:: Abstract + + Our research is concerned with compiler- independent, tag-free + garbage collection for the C++ programming language. This paper + presents a mark-and-sweep collector, and explains how it + ameliorates shortcomings of a previous copy collector. The new + collector, like the old, uses C++'s facilities for creating + abstract data types to define a *tracked reference* type, called + *roots*, at the level of the application program. A programmer + wishing to utilize the garbage collection service uses these roots + in place of normal, raw pointers. We present a detailed study of + the cost of using roots, as compared to both normal pointers and + reference counted pointers, in terms of instruction counts. We + examine the efficiency of a small C++ application using roots, + reference counting, manual reclamation, and conservative + collection. Coding the application to use garbage collection, and + analyzing the resulting efficiency, helped us identify a number of + memory leaks and inefficiencies in the original, manually + reclaimed version. We find that for this program, garbage + collection using roots is much more efficient than reference + counting, though less efficient than manual reclamation. It is + hard to directly compare our collector to the conservative + collector because of the differing efficiencies of their + respective memory allocators. * .. _EDWARDS: Daniel J. Edwards. n.d. "`Lisp II Garbage Collector `_". MIT. AI Memo 19 (AIM-19). - .. abstract: edwards.html + .. admonition:: Our summary (This short memo doesn't have an abstract. Basically, it describes the plan for the LISP II Relocating Garbage Collector. It has four @@ -1179,7 +1525,7 @@ Bibliography John R. Ellis, David L. Detlefs. 1993. "`Safe, Efficient Garbage Collection for C++ `_". Xerox PARC. - .. abstract: ellis93.html + .. admonition:: Abstract We propose adding safe, efficient garbage collection to C++, eliminating the possibility of storage-management bugs and making @@ -1192,7 +1538,7 @@ Bibliography Paulo Ferreira. 1996. "`Larchant: garbage collection in a cached distributed shared store with persistence by reachability `_". Université Paris VI. Thése de doctorat. - .. abstract: ferreira96.html + .. admonition:: Abstract The model of Larchant is that of a *Shared Address Space* (spanning every site in a network including secondary storage) @@ -1229,15 +1575,53 @@ Bibliography Paulo Ferreira & Marc Shapiro. 1998. "`Modelling a Distributed Cached Store for Garbage Collection `_". Springer-Verlag. Proceedings of 12th European Conference on Object-Oriented Programming, ECOOP98, LNCS 1445. + .. admonition:: Abstract + + Caching and persistence support efficient, convenient and + transparent distributed data sharing. The most natural model of + persistence is persistence by reachability, managed automatically + by a garbage collector (GC). We propose a very general model of + such a system (based on distributed shared memory) and a scalable, + asynchronous distributed GC algorithm. Within this model, we show + sufficient and widely applicable correctness conditions for the + interactions between applications, store, memory, coherence, and + GC. + + The GC runs as a set of processes (local to each participating + machine) communicating by asynchronous messages. Collection does + not interfere with applications by setting locks, polluting + caches, or causing I/O; this requirement raised some novel and + interesting challenges which we address in this article. The + algorithm is safe and live; it is not complete, i.e. it collects + some distributed cycles of garbage but not necessarily all. + * .. _FW76: Daniel P Friedman, David S. Wise. 1976. "`Garbage collecting a heap which includes a scatter table `_". *Information Processing Letters.* 5, 6 (December 1976): 161--164. + .. admonition:: Abstract + + A new algorithm is introduced for garbage collecting a heap which + contains shared data structures accessed from a scatter table. The + scheme provides for the purging of useless entries from the + scatter table with no traverslas beyond the two required by + classic collection schemes. For languages which use scatter tables + to sustain unique existence of complex structures, like natural + variables of SNOBOL, it indirectly allows liberal use of a single + scatter table by ensuring efficient deletion of useless entries. + Since the scatter table is completely restructured during the + course of execution, the hashing scheme itself is easily altered + during garbage collection whenever skewed loading of the scatter + table warrants abandonment of the old hashing. This procedure is + applicable to the maintenance of dynamic structures such as those + in information retrieval schemes or in languages like LISP and + SNOBOL. + * .. _FW77: Daniel P Friedman, David S. Wise. 1977. "`The One Bit Reference Count `_". *BIT.* (17)3: 351--359. - .. abstract: fw77.html + .. admonition:: Abstract Deutsch and Bobrow propose a storage reclamation scheme for a heap which is a hybrid of garbage collection and reference counting. @@ -1258,11 +1642,23 @@ Bibliography Daniel P Friedman, David S. Wise. 1979. "`Reference counting can manage the circular environments of mutual recursion `_". *Information Processing Letters.* 8, 1 (January 1979): 41--45. + .. admonition:: From the introduction + + In this note we advance reference counting as a storage management + technique viable for implementing recursive languages like ISWIM + or pure LISP with the ``labels`` construct for implementing mutual + recursion from SCHEME. ``Labels`` is derived from ``letrec`` and + displaces the ``label`` operator, a version of the paradoxical + Y-combinator. The key observation is that the requisite circular + structure (which ordinarily cripples reference counts) occurs only + within the language--rather than the user--structure, and that the + references into this structure are well-controlled. + * .. _GZH93: Dirk Grunwald, Benjamin Zorn, R. Henderson. 1993. "`Improving the Cache Locality of Memory Allocation `_". SIGPLAN. SIGPLAN '93, Conference on PLDI, June 1993, Albuquerque, New Mexico. - .. abstract: gzh93.html + .. admonition:: Abstract The allocation and disposal of memory is a ubiquitous operation in most programs. Rarely do programmers concern themselves with @@ -1289,7 +1685,7 @@ Bibliography Dirk Grunwald & Benjamin Zorn. 1993. "`CustoMalloc: Efficient Synthesized Memory Allocators `_". Software -- Practice and Experience. 23(8):851--869. - .. abstract: grun92.html + .. admonition:: Abstract The allocation and disposal of memory is a ubiquitous operation in most programs. Rarely do programmers concern themselves with @@ -1312,7 +1708,7 @@ Bibliography David Gudeman. 1993. "`Representing Type Information in Dynamically Typed Languages `_". University of Arizona at Tucson. Technical Report TR 93-27. - .. abstract: gudeman93.html + .. admonition:: Abstract This report is a discussion of various techniques for representing type information in dynamically typed languages, as implemented on @@ -1333,7 +1729,7 @@ Bibliography Timothy Harris. 1999. "`Early storage reclamation in a tracing garbage collector `_". ACM. ACM SIG-PLAN Notices 34:4, pp. 46--53. - .. abstract: harris99.html + .. admonition:: Abstract This article presents a technique for allowing the early recovery of storage space occupied by garbage data. The idea is similar to @@ -1347,7 +1743,7 @@ Bibliography Roger Henriksson. 1994. "Scheduling Real Time Garbage Collection". Department of Computer Science at Lund University. LU-CS-TR:94-129. - .. abstract: henrik94.html + .. admonition:: Abstract This paper presents a new model for scheduling the work of an incremental garbage collector in a system with hard real time @@ -1366,7 +1762,7 @@ Bibliography Roger Henriksson. 1996. "`Adaptive Scheduling of Incremental Copying Garbage Collection for Interactive Applications `_". NWPER96. - .. abstract: henrik96.html + .. admonition:: Abstract Incremental algorithms are often used to interleave the work of a garbage collector with the execution of an application program, @@ -1382,7 +1778,7 @@ Bibliography Roger Henriksson. 1998. "`Scheduling Garbage Collection in Embedded Systems `_". Department of Computer Science at Lund University. Ph.D. thesis. - .. abstract: henriksson98.html + .. admonition:: Abstract The complexity of systems for automatic control and other safety-critical applications grows rapidly. Computer software @@ -1431,23 +1827,78 @@ Bibliography Antony L. Hosking. 1991. "`Main memory management for persistence `_". ACM. Proceedings of the ACM OOPSLA'91 Workshop on Garbage Collection. + .. admonition:: Abstract + + Reachability-based persistence imposes new requirements for main + memory management in general, and garbage collection in + particular. After a brief introduction to the characteristics and + requirements of reachability-based persistence, we present the + design of a run-time storage manager for Persistent Smalltalk and + Persistent Modula-3, which allows the reclamation of storage from + both temporary objects and buffered persistent objects. + * .. _HMS92: Antony L. Hosking, J. Eliot B. Moss, Darko Stefanovic. 1992. "`A comparative performance evaluation of write barrier implementations `_". ACM. OOPSLA'92 Conference Proceedings, ACM SIGPLAN Notices 27(10), pp 92--109. + .. admonition:: Abstract + + Generational garbage collectors are able to achieve very small + pause times by concentrating on the youngest (most recently + allocated) objects when collecting, since objects have been + observed to die young in many systems. Generational collectors + must keep track of all pointers from older to younger generations, + by “monitoring” all stores into the heap. This *write barrier* has + been implemented in a number of ways, varying essentially in the + granularity of the information observed and stored. Here we + examine a range of write barrier implementations and evaluate + their relative performance within a generation scavenging garbage + collector for Smalltalk. + * .. _HH93: Antony L. Hosking, Richard L. Hudson. 1993. "`Remembered sets can also play cards `_". ACM. Proceedings of the ACM OOPSLA'93 Workshop on Memory Management and Garbage Collection. + .. admonition:: Abstract + + Remembered sets and dirty bits have been proposed as alternative + implementations of the write barrier for garbage collection. There + are advantages to both approaches. Dirty bits can be efficiently + maintained with minimal, bounded overhead per store operation, + while remembered sets concisely, and accurately record the + necessary information. Here we present evidence to show that + hybrids can combine the virtues of both schemes and offer + competitive performance. Moreover, we argue that a hybrid can + better avoid the devils that are the downfall of the separate + alternatives. + * .. _HM93: Antony L. Hosking, J. Eliot B. Moss. 1993. "`Protection traps and alternatives for memory management of an object-oriented language `_". ACM. Proceedings of the Fourteenth ACM Symposium on Operating Systems Principles, ACM Operating Systems Review 27(5), pp 106--119. + .. admonition:: Abstract + + Many operating systems allow user programs to specify the + protection level (inaccessible, read-only, read-write) of pages in + their virtual memory address space, and to handle any protection + violations that may occur. Such page-protection techniques have + been exploited by several user-level algorithms for applications + including generational garbage collection and persistent stores. + Unfortunately, modern hardware has made efficient handling of page + protection faults more difficult. Moreover, page-sized granularity + may not match the natural granularity of a given application. In + light of these problems, we reevaluate the usefulness of + page-protection primitives in such applications, by comparing the + performance of implementations that make use of the primitives + with others that do not. Our results show that for certain + applications software solutions outperform solutions that rely on + page-protection or other related virtual memory primitives. + * .. _HMDW91: Richard L. Hudson, J. Eliot B. Moss, Amer Diwan, Christopher F. Weight. 1991. "`A Language-Independent Garbage Collector Toolkit `_". University of Massachusetts at Amherst. COINS Technical Report 91--47. - .. abstract: hmdw91.html + .. admonition:: Abstract We describe a memory management toolkit for language implementors. It offers efficient and flexible generation scavenging garbage @@ -1465,7 +1916,7 @@ Bibliography Richard L. Hudson, J. Eliot B. Moss. 1992. "`Incremental Collection of Mature Objects `_". Springer-Verlag. LNCS #637 International Workshop on Memory Management, St. Malo, France, Sept. 1992, pp. 388--403. - .. abstract: hm92.html + .. admonition:: Abstract We present a garbage collection algorithm that extends generational scavenging to collect large older generations (mature @@ -1481,7 +1932,7 @@ Bibliography Richard L. Hudson, Ron Morrison, J. Eliot B. Moss, David S. Munro. 1997. "`Garbage Collecting the World: One Car at a Time `_". ACM. Proc. OOPSLA 97, pp. 162--175. - .. abstract: hmmm97.html + .. admonition:: Abstract A new garbage collection algorithm for distributed object systems, called DMOS (Distributed Mature Object Space), is presented. It is @@ -1493,15 +1944,11 @@ Bibliography incrementality, and scalability. Furthermore, the DMOS collector is non-blocking and does not use global tracing. -* .. _ISO90: - - "International Standard ISO/IEC 9899:1990 Programming languages — C". - * .. _JOHNSTONE97: Mark S. Johnstone. 1997. "`Non-Compacting Memory Allocation and Real-Time Garbage Collection `_". University of Texas at Austin. - .. abstract: johnstone97.html + .. admonition:: Abstract Dynamic memory use has been widely recognized to have profound effects on program performance, and has been the topic of many @@ -1548,7 +1995,7 @@ Bibliography Mark S. Johnstone, Paul R. Wilson. 1998. "`The Memory Fragmentation Problem: Solved? `_". ACM. ISMM'98 pp. 26--36. - .. abstract: jw98.html + .. admonition:: Abstract We show that for 8 real and varied C and C++ programs, several conventional dynamic storage allocators provide near-zero @@ -1569,11 +2016,26 @@ Bibliography Richard E. Jones. 1992. "`Tail recursion without space leaks `_". *Journal of Functional Programming.* 2(1):73--79. + .. admonition:: Abstract + + The G-machine is a compiled graph reduction machine for lazy + functional languages. The G-machine compiler contains many + optimisations to improve performance. One set of such + optimisations is designed to improve the performance of tail + recursive functions. Unfortunately the abstract machine is subject + to a space leak--objects are unnecessarily preserved by the + garbage collector. + + This paper analyses why a particular form of space leak occurs in + the G-machine, and presents some ideas for fixing this problem. + This phenomena in other abstract machines is also examined + briefly. + * .. _JL92: Richard E. Jones, Rafael Lins. 1992. "`Cyclic weighted reference counting without delay `_". Computing Laboratory, The University of Kent at Canterbury. Technical Report 28-92. - .. abstract: jl92.html + .. admonition:: Abstract Weighted Reference Counting is a low-communication distributed storage reclamation scheme for loosely-coupled multiprocessors. @@ -1590,23 +2052,22 @@ Bibliography Richard E. Jones, Rafael Lins. 1996. "`Garbage Collection: Algorithms for Automatic Dynamic Memory Management `_". Wiley. ISBN 0-471-94148-4. - .. abstract: jones96.html + .. admonition:: From the back cover - [from the back cover] The memory storage requirements of complex - programs are extremely difficult to manage correctly by hand. A - single error may lead to indeterminate and inexplicable program - crashes. Worse still, failures are often unrepeatable and may - surface only long after the program has been delivered to the - customer. The eradication of memory errors typically consumes a - substantial amount of development time. And yet the answer is - relatively easy -- garbage collection; removing the clutter of - memory management from module interfaces, which then frees the - programmer to concentrate on the problem at hand rather than - low-level book-keeping details. For this reason, most modern - object-oriented languages such as Smalltalk, Eiffel, Java and - Dylan, are supported by garbage collection. Garbage collecting - libraries are even available for such uncooperative languages as C - and C++. + The memory storage requirements of complex programs are extremely + difficult to manage correctly by hand. A single error may lead to + indeterminate and inexplicable program crashes. Worse still, + failures are often unrepeatable and may surface only long after + the program has been delivered to the customer. The eradication of + memory errors typically consumes a substantial amount of + development time. And yet the answer is relatively easy -- garbage + collection; removing the clutter of memory management from module + interfaces, which then frees the programmer to concentrate on the + problem at hand rather than low-level book-keeping details. For + this reason, most modern object-oriented languages such as + Smalltalk, Eiffel, Java and Dylan, are supported by garbage + collection. Garbage collecting libraries are even available for + such uncooperative languages as C and C++. This book considers how dynamic memory can be recycled automatically to guarantee error-free memory management. There is @@ -1631,20 +2092,19 @@ Bibliography Richard E. Jones. 1998. "`ISMM'98 International Symposium on Memory Management `_". ACM. ISBN 1-58113-114-3. - .. abstract: acm98.html + .. admonition:: From the Preface - (From the preface:) The International Symposium on Memory - Management is a forum for research in several related areas of - memory management, especially garbage collectors and dynamic - storage allocators. [...] The nineteen papers selected for - publication in this volume cover a remarkably broad range of - memory management topics from explicit malloc-style allocation to - automatic memory management, from cache-conscious data layout to - efficient management of distributed references, from conservative - to type-accurate garbage collection, for applications ranging from - user application to long-running servers, supporting languages as - different as C, C++, Modula-3, Java, Eiffel, Erlang, Scheme, ML, - Haskell and Prolog. + The International Symposium on Memory Management is a forum for + research in several related areas of memory management, especially + garbage collectors and dynamic storage allocators. [...] The + nineteen papers selected for publication in this volume cover a + remarkably broad range of memory management topics from explicit + malloc-style allocation to automatic memory management, from + cache-conscious data layout to efficient management of distributed + references, from conservative to type-accurate garbage collection, + for applications ranging from user application to long-running + servers, supporting languages as different as C, C++, Modula-3, + Java, Eiffel, Erlang, Scheme, ML, Haskell and Prolog. * .. _JONES12: @@ -1654,6 +2114,32 @@ Bibliography Ian Joyner. 1996. "`C++??: A Critique of C++ `_.". + .. admonition:: Abstract + + The C++?? Critique is an analysis of some of the flaws of C++. It + is by no means exhaustive, nor does it attempt to document every + little niggle with C++, rather concentrating on main themes. The + critique uses Java and Eiffel as comparisons to C++ to give a more + concrete feel to the criticisms, viewing conceptual differences + rather than syntactic ones as being more important. Some C++ + authors realising there are glaring deficiencies in C++ have + chosen to defend C++ by also being critical within their own work. + Most notable are Bjarne Stroustup's "Design and Evolution of C++," + and Scott Meyers' "Effective" and "More Effective C++." These warn + of many traps and pitfalls, but reach the curious conclusion that + since "good" C++ programmers are aware of these problems and know + how to avoid them, C++ is alright. + + The C++ critique makes many of the same criticisms, but comes to + the different conclusion that these pitfalls are not acceptable, + and should not be in a language used for modern large scale + software engineering. Clean design is more important than after + the fact warnings, and it is inconceivable that purchasers of end + user software would tolerate this tactic on the part of vendors. + The critique also takes a look at C, and concludes that many of + the features of C should be left out of modern languages, and that + C is a flawed base for a language. + * .. _KANEFSKY89: Bob Kanefsky. 1989. "`Recursive Memory Allocation `_". Bob Kanefsky. Songworm 3, p.?. @@ -1662,17 +2148,17 @@ Bibliography Jin-Soo Kim, Xiaohan Qin, Yarsun Hsu. 1998. "`Memory Characterization of a Parallel Data Mining Workload `_". IEEE. Proc. Workload Characterization: Methodology and Case Studies, pp. . - .. abstract: kqh98.html + .. admonition:: Abstract This paper studies a representative of an important class of emerging applications, a parallel data mining workload. The application, extracted from the IBM Intelligent Miner, identifies groups of records that are mathematically similar based on a neural network model called self-organizing map. We examine and - compare in details two implementations of the application: (1) - temporal locality or working set sizes; (2) spatial locality and - memory block utilization; (3) communication characteristics and - scalability; and (4) TLB performance. + compare in details two implementations of the application: + (1) temporal locality or working set sizes; (2) spatial locality + and memory block utilization; (3) communication characteristics + and scalability; and (4) TLB performance. First, we find that the working set hierarchy of the application is governed by two parameters, namely the size of an input record @@ -1691,11 +2177,34 @@ Bibliography Jin-Soo Kim & Yarsun Hsu. 2000. "Memory system behavior of Java programs: methodology and analysis". ACM. Proc. International conference on measurements and modeling of computer systems, pp. 264--274. + .. admonition:: Abstract + + This paper studies the memory system behavior of Java programs by + analyzing memory reference traces of several SPECjvm98 + applications running with a Just-In-Time (JIT) compiler. Trace + information is collected by an exception-based tracing tool called + JTRACE, without any instrumentation to the Java programs or the + JIT compiler.First, we find that the overall cache miss ratio is + increased due to garbage collection, which suffers from higher + cache misses compared to the application. We also note that going + beyond 2-way cache associativity improves the cache miss ratio + marginally. Second, we observe that Java programs generate a + substantial amount of short-lived objects. However, the size of + frequently-referenced long-lived objects is more important to the + cache performance, because it tends to determine the application's + working set size. Finally, we note that the default heap + configuration which starts from a small initial heap size is very + inefficient since it invokes a garbage collector frequently. + Although the direct costs of garbage collection decrease as we + increase the available heap size, there exists an optimal heap + size which minimizes the total execution time due to the + interaction with the virtual memory performance. + * .. _KOLODNER92: Elliot K. Kolodner. 1992. "Atomic Incremental Garbage Collection and Recovery for a Large Stable Heap". Laboratory for Computer Science at MIT. MIT-LCS-TR-534. - .. abstract: kolodner92.html + .. admonition:: Abstract A stable heap is a storage that is managed automatically using garbage collection, manipulated using atomic transactions, and @@ -1723,7 +2232,7 @@ Bibliography Per-Åke Larson & Murali Krishnan. 1998. "`Memory Allocation for Long-Running Server Applications `_". ACM. ISMM'98 pp. 176--185. - .. abstract: lk98.html + .. admonition:: Abstract Prior work on dynamic memory allocation has largely neglected long-running server applications, for example, web servers and @@ -1748,46 +2257,69 @@ Bibliography Henry Lieberman & Carl Hewitt. 1983. "`A real-time garbage collector based on the lifetimes of objects `_". ACM. 26(6):419--429. + .. admonition:: Abstract + + In previous heap storage systems, the cost of creating objects and + garbage collection is independent of the lifetime of the object. + Since objects with short lifetimes account for a large portion of + storage use, it is worth optimizing a garbage collector to reclaim + storage for these objects more quickly. The garbage collector + should spend proportionately less effort reclaiming objects with + longer lifetimes. We present a garbage collection algorithm that + (1) makes storage for short-lived objects cheaper than storage for + long-lived objects, (2) that operates in real-time--object + creation and access times are bounded, (3) increases locality of + reference, for better virtual memory performance, (4) works well + with multiple processors and a large address space. + * .. _MM59: - J. McCarthy, M. L. Minsky. 1959. "Artificial Intelligence, Quarterly Progress Report no. 53". Research Laboratory of Electronics at MIT. + J. McCarthy, M. L. Minsky. 1959. "`Artificial Intelligence, Quarterly Progress Report no. 53 `_". Research Laboratory of Electronics at MIT. * .. _MCCARTHY60: J. McCarthy. 1960. "`Recursive Functions of Symbolic Expressions and Their Computation by Machine `_". CACM. - .. abstract: mccarthy60.html + .. admonition:: Abstract - A programming system called LISP (for LISt Processor) has been - developed for the IBM 704 computer by the Artificial Intelligence - group at M.I.T. The system was designed to facilitate experiments - with a proposed system called the Advice Taker, whereby a machine - could be instructed to handle declarative as well as imperative - sentences and could exhibit "common sense" in carrying out its - instructions. The original proposal for the Advice Taker was made - in November 1958. The main requirement was a programming system - for manipulating expressions representing formalized declarative - and imperative sentences so that the Advice Taker could make - deductions. + A programming system called LISP (for LISt Processor) has been + developed for the IBM 704 computer by the Artificial Intelligence + group at M.I.T. The system was designed to facilitate experiments + with a proposed system called the Advice Taker, whereby a machine + could be instructed to handle declarative as well as imperative + sentences and could exhibit "common sense" in carrying out its + instructions. The original proposal for the Advice Taker was made + in November 1958. The main requirement was a programming system + for manipulating expressions representing formalized declarative + and imperative sentences so that the Advice Taker could make + deductions. + + In the course of its development the LISP system went through + several stages of simplification and eventually came to be based + on a scheme for representing the partial recursive functions of a + certain class of symbolic expressions. This representation is + independent of the IBM 704 computer, or of any other electronic + computer, and it now seems expedient to expound the system by + starting with the class of expressions called S-expressions and + the functions called S-functions. * .. _MCCARTHY79: - John McCarthy. 1979. "`History of Lisp `_". In *History of programming languages I*, pp. 173–185. ACM. + John McCarthy. 1979. "`History of Lisp `_". In *History of programming languages I*, pp. 173--185. ACM. * .. _PTM98: Veljko Milutinovic, Jelica Protic, Milo Tomasevic. 1997. "`Distributed shared memory: concepts and systems `_". IEEE Computer Society Press. ISBN 0-8186-7737-6. - .. abstract: ptm98.html + .. admonition:: From the publisher's catalog - [introduction from the catalog] Presents a survey of both - distributed shared memory (DSM) efforts and commercial DSM - systems. The book discusses relevant issues that make the concept - of DSM one of the most attractive approaches for building - large-scale, high-performance multiprocessor systems. Its text - provides a general introduction to the DSM field as well as a - broad survey of the basic DSM concepts, mechanisms, design issues, - and systems. + Presents a survey of both distributed shared memory (DSM) efforts + and commercial DSM systems. The book discusses relevant issues + that make the concept of DSM one of the most attractive approaches + for building large-scale, high-performance multiprocessor systems. + Its text provides a general introduction to the DSM field as well + as a broad survey of the basic DSM concepts, mechanisms, design + issues, and systems. Distributed Shared Memory concentrates on basic DSM algorithms, their enhancements, and their performance evaluation. In addition, @@ -1799,12 +2331,45 @@ Bibliography * .. _MINSKY63: - M. L. Minsky. 1963. "A LISP Garbage Collector Algorithm Using Serial Secondary Storage". MIT. Memorandum MAC-M-129, Artificial Intelligence Project, Memo 58 (revised). + M. L. Minsky. 1963. "`A LISP Garbage Collector Algorithm Using Serial Secondary Storage `_". MIT. Memorandum MAC-M-129, Artificial Intelligence Project, Memo 58 (revised). + + .. admonition:: Abstract + + This paper presents an algorithm for reclaiming unused free + storage memory cells is LISP. It depends on availability of a fast + secondary storage device, or a large block of available temporary + storage. For this price, we get 1. Packing of free-storage into a + solidly packed block. 2. Smooth packing of arbitrary linear blocks + and arrays. 3. The collector will handle arbitrarily complex + re-entrant list structure with no introduction of spurious copies. + 4. The algorithm is quite efficient; the marking pass visits words + at most twice and usually once, and the loading pass is linear. + 5. The system is easily modified to allow for increase in size of + already fixed consecutive blocks, provide one can afford to + initiate a collection pass or use a modified array while waiting + for such a pass to occur. * .. _MOON84: David Moon. 1984. "`Garbage Collection in a Large Lisp System `_". ACM. Symposium on Lisp and Functional Programming, August 1984. + .. admonition:: Abstract + + This paper discusses garbage collection techniques used in a + high-performance Lisp implementation with a large virtual memory, + the Symbolics 3600. Particular attention is paid to practical + issues and experience. In a large system problems of scale appear + and the most straightforward garbage-collection techniques do not + work well. Many of these problems involve the interaction of the + garbage collector with demand-paged virtual memory. Some of the + solutions adopted in the 3600 are presented, including incremental + copying garbage collection, approximately depth-first copying, + ephemeral objects, tagged architecture, and hardware assists. We + discuss techniques for improving the efficiency of garbage + collection by recognizing that objects in the Lisp world have a + variety of lifetimes. The importance of designing the architecture + and the hardware to facilitate garbage collection is stressed. + * .. _MOON85: David Moon. 1985. "Architecture of the Symbolics 3600". IEEE. 12th International Symposium on Computer Architecture, pp. 76--83. @@ -1825,11 +2390,30 @@ Bibliography Luc Moreau. 1998. "`Hierarchical Distributed Reference Counting `_". ACM. ISMM'98 pp. 57--67. + .. admonition:: Abstract + + Massively distributed computing is a challenging problem for + garbage collection algorithm designers as it raises the issue of + scalability. The high number of hosts involved in a computation + can require large tables for reference listing, whereas the lack + of information sharing between hosts in a same locality can entail + redundant GC traffic. In this paper, we argue that a conceptual + hierarchical organisation of massive distributed computations can + solve this problem. By conceptual hierarchical organisation, we + mean that processors are still able to communicate in a peer to + peer manner using their usual communication mechanism, but GC + messages will be routed as if processors were organised in + hierarchy. We present an extension of a distributed reference + counting algorithm that uses such a hierarchical organisation. It + allows us to bound table sizes by the number of hosts in a domain, + and it allows us to share GC information between hosts in a same + locality in order to reduce cross-network GC traffic. + * .. _MFH95: Greg Morrisett, Matthias Felleisen, Robert Harper. 1995. "`Abstract Models of Memory Management `_". Carnegie Mellon University. CMU-CS-FOX-95-01. - .. abstract: mfh95.html + .. admonition:: Abstract Most specifications of garbage collectors concentrate on the low-level algorithmic details of how to find and preserve @@ -1864,7 +2448,7 @@ Bibliography David S. Munro, Alfred Brown, Ron Morrison, J. Eliot B. Moss. 1999. "`Incremental Garbage Collection of a Persistent Object Store using PMOS `_". Morgan Kaufmann. in Advances in Persistent Object Systems, pp. 78--91. - .. abstract: mbmm99.html + .. admonition:: Abstract PMOS is an incremental garbage collector designed specifically to reclaim space in a persistent object store. It is complete in that @@ -1889,7 +2473,7 @@ Bibliography Scott Nettles, James O'Toole, David Pierce, Nickolas Haines. 1992. "`Replication-Based Incremental Copying Collection `_". IWMM'92. - .. abstract: noph92.html + .. admonition:: Abstract We introduce a new replication-based copying garbage collection technique. We have implemented one simple variation of this method @@ -1916,7 +2500,7 @@ Bibliography Scott Nettles. 1992. "`A Larch Specification of Copying Garbage Collection `_". Carnegie Mellon University. CMU-CS-92-219. - .. abstract: nettles92.html + .. admonition:: Abstract Garbage collection (GC) is an important part of many language implementations. One of the most important garbage collection @@ -1934,7 +2518,7 @@ Bibliography Scott Nettles & James O'Toole. 1993. "Implementing Orthogonal Persistence: A Simple Optimization Using Replicating Collection". USENIX. IWOOOS'93. - .. abstract: no93a.html + .. admonition:: Abstract Orthogonal persistence provides a safe and convenient model of object persistence. We have implemented a transaction system which @@ -1958,7 +2542,7 @@ Bibliography Scott Nettles & James O'Toole. 1993. "`Real-Time Replication Garbage Collection `_". ACM. PLDI'93. - .. abstract: no93.html + .. admonition:: Abstract We have implemented the first copying garbage collector that permits continuous unimpeded mutator access to the original @@ -1973,7 +2557,7 @@ Bibliography Norman R. Nielsen. 1977. "Dynamic Memory Allocation in Computer Simulation". ACM. CACM 20:11. - .. abstract: nielsen77.html + .. admonition:: Abstract This paper investigates the performance of 35 dynamic memory allocation algorithms when used to service simulation programs as @@ -1992,7 +2576,7 @@ Bibliography James O'Toole. 1990. "Garbage Collecting Locally". - .. abstract: otoole90.html + .. admonition:: Abstract Generational garbage collection is a simple technique for automatic partial memory reclamation. In this paper, I present the @@ -2013,7 +2597,7 @@ Bibliography James O'Toole & Scott Nettles. 1994. "`Concurrent Replicating Garbage Collection `_". ACM. LFP'94. - .. abstract: on94.html + .. admonition:: Abstract We have implemented a concurrent copying garbage collector that uses replicating garbage collection. In our design, the client can @@ -2031,7 +2615,7 @@ Bibliography Simon Peyton Jones, Norman Ramsey, Fermin Reig. 1999. "`C--: a portable assembly language that supports garbage collection `_". Springer-Verlag. International Conference on Principles and Practice of Declarative Programming 1999, LNCS 1702, pp. 1--28. - .. abstract: jrr99.html + .. admonition:: Abstract For a compiler writer, generating good machine code for a variety of platforms is hard work. One might try to reuse a retargetable @@ -2054,7 +2638,7 @@ Bibliography John S. Pieper. 1993. "Compiler Techniques for Managing Data Motion". Carnegie Mellon University. Technical report number CMU-CS-93-217. - .. abstract: pieper93.html + .. admonition:: Abstract Software caching, automatic algorithm blocking, and data overlays are different names for the same problem: compiler management of @@ -2109,7 +2693,7 @@ Bibliography Pekka P. Pirinen. 1998. "Barrier techniques for incremental tracing". ACM. ISMM'98 pp. 20--25. - .. abstract: pirinen98.html + .. admonition:: Abstract This paper presents a classification of barrier techniques for interleaving tracing with mutator operation during an incremental @@ -2126,7 +2710,7 @@ Bibliography Tony Printezis. 1996. "Disk Garbage Collection Strategies for Persistent Java". Proceedings of the First International Workshop on Persistence and Java. - .. abstract: printezis96.html + .. admonition:: Abstract This paper presents work currently in progress on Disk Garbage Collection issues for PJava, an orthogonally persistent version of @@ -2151,7 +2735,7 @@ Bibliography M. B. Reinhold. 1993. "`Cache Performance of Garbage Collected Programming Languages `_". Laboratory for Computer Science at MIT. MIT/LCS/TR-581. - .. abstract: reinhold93.html + .. admonition:: Abstract As processor speeds continue to improve relative to main-memory access times, cache performance is becoming an increasingly @@ -2195,7 +2779,7 @@ Bibliography Gustavo Rodriguez-Rivera & Vince Russo. 1997. "Non-intrusive Cloning Garbage Collection with Stock Operating System Support". Software -- Practice and Experience. 27:8. - .. abstract: rr97.html + .. admonition:: Abstract It is well accepted that automatic garbage collection simplifies programming, promotes modularity, and reduces development effort. @@ -2227,7 +2811,7 @@ Bibliography Niklas Röjemo. 1995. "Highlights from nhc -- a space-efficient Haskell compiler". Chalmers University of Technology. - .. abstract: rojemo95.html + .. admonition:: Abstract Self-compiling implementations of Haskell, i.e., those written in Haskell, have been and, except one, are still space consuming @@ -2261,11 +2845,28 @@ Bibliography Niklas Röjemo. 1995. "Generational garbage collection for lazy functional languages without temporary space leaks". Chalmers University of Technology. + .. admonition:: Abstract + + Generational garbage collection is an established method for + creating efficient garbage collectors. Even a simple + implementation where all nodes that survive one garbage collection + are *tenured*, i.e., moved to an old generation, works well in + strict languages. In lazy languages, however, such an + implementation can create severe *temporary space leaks*. The + temporary space leaks appear in programs that traverse large + lazily built data structures, e.g., a lazy list representing a + large file, where only a small part is needed at any time. A + simple generational garbage collector cannot reclaim the memory, + used by the lazily built list, at minor collections. The reason is + that at least one of the nodes in the list belongs to the old + generation, after the first minor collection, and will hold on to + the rest of the nodes in the list until the next major collection. + * .. _RR96: Niklas Röjemo & Colin Runciman. 1996. "Lag, drag, void and use -- heap profiling and space-efficient compilation revisited". ACM, SIGPLAN. ICFP'96, ACM SIGPLAN Notices 31:6, ISBN 0-89791-770-7, pp. 34--41. - .. abstract: rr96.html + .. admonition:: Abstract The context for this paper is functional computation by graph reduction. Our overall aim is more efficient use of memory. The @@ -2283,7 +2884,7 @@ Bibliography David J. Roth, David S. Wise. 1999. "`One-bit counts between unique and sticky `_". ACM. ISMM'98, pp. 49--56. - .. abstract: rw99.html + .. admonition:: Abstract Stoye's one-bit reference tagging scheme can be extended to local counts of two or more via two strategies. The first, suited to @@ -2303,13 +2904,37 @@ Bibliography * .. _ROVNER85: - Paul Rovner. 1985. "`On Adding Garbage Collection and Runtime Types to a Strongly-Typed, Statically-Checked, Concurrent Language `_". Xerox PARC. TR CSL-84-7. + Paul Rovner. 1985. "`On Adding Garbage Collection and Runtime Types to a Strongly-Typed, Statically-Checked, Concurrent Language `_". Xerox PARC. TR CSL-84-7. + + .. admonition:: Abstract + + Enough is known now about garbage collection, runtime types, + strong-typing, static-checking and concurrency that it is possible + to explore what happens when they are combined in a real + programming system. + + Storage management is one of a few central issues through which + one can get a good view of the design of an entire system. + Tensions between ease of integration and the need for protection; + between generality, simplicity, flexibility, extensibility and + efficiency are all manifest when assumptions and attitudes about + managing storage are studied. And deep understanding follows best + from the analysis of systems that people use to get real work + done. + + This paper is not for those who seek arguments pro or con about + the need for these features in programming systems; such issues + are for other papers. This one assumes these features to be good + and describes how they combine and interact in Cedar, a + programming language and environment designed to help programmers + build moderate-sized experimental systems for moderate numbers of + people to test and use. * .. _RUNCIMAN92: Colin Runciman & David Wakeling. 1992. "`Heap Profiling of Lazy Functional Programs `_". University of York. - .. abstract: runciman92.html + .. admonition:: Abstract We describe the design, implementation, and use of a new kind of profiling tool that yields valuable information about the memory @@ -2327,7 +2952,7 @@ Bibliography Colin Runciman & Niklas Röjemo. 1994. "`New dimensions in heap profiling `_". University of York. - .. abstract: rr94.html + .. admonition:: Abstract First-generation heap profilers for lazy functional languages have proved to be effective tools for locating some kinds of space @@ -2349,11 +2974,45 @@ Bibliography Colin Runciman & Niklas Röjemo. 1996. "Two-pass heap profiling: a matter of life and death". Department of Computer Science, University of York. + .. admonition:: Abstract + + A heap profile is a chart showing the contents of heap memory + throughout a computation. Contents are depicted abstractly by + showing how much space is occupied by memory cells in each of + several classes. A good heap profiler can use a variety of + attributes of memory cells to de-fine a classification. Effective + profiling usually involves a combination of attributes. The ideal + profiler gives full support for combination in two ways. First, a + section of the heap of interest to the programmer can be specified + by constraining the values of any combination of cell attributes. + Secondly, no matter what attributes are used to specify such a + section, a heap profile can be obtained for that section only, and + any other attribute can be used to define the classification. + + Achieving this ideal is not simple For some combinations of + attributes. A heap profile is derived by interpolation of a series + of censuses of heap contents at different stages. The obvious way + to obtain census data is to traverse the live heap at intervals + throughout the computation. This is fine for static attributes + (e.g. What type of value does this memory cell represent?), and + for dynamic attributes that can be determined for each cell by + examining the heap at any given moment (e.g. From which function + closures can this cell be reached?). But some attributes of cells + can only be determined retrospectively by post-mortem inspection + asa cell is overwritten or garbage-collected (e.g. Is this cell + ever used again?). Now we see the problem: if a profiler supports + both live and pose-mortem attributes, how can we implement the + ideal of unrestricted combinations? That is the problem me solve + in this paper. We give techniques for profiling a. heap section + specified in terms of both live and post-mortem attributes. We + show how to generate live-attribute profiles of a section of the + heal, specified using post-mortem attributes, and vice versa. + * .. _SG95: Jacob Seligmann & Steffen Grarup. 1995. "`Incremental Mature Garbage Collection Using the Train Algorithm `_". Springer-Verlag. ECOOP'95, Lecture Notes in Computer Science, Vol. 952, pp. 235--252, ISBN 3-540-60160-0. - .. abstract: sg95.html + .. admonition:: Abstract We present an implementation of the Train Algorithm, an incremental collection scheme for reclamation of mature garbage in @@ -2369,11 +3028,32 @@ Bibliography Manuel Serrano, Hans-J. Boehm. 2000. "`Understanding memory allocation of Scheme programs `_". ACM. Proceedings of International Conference on Functional Programming 2000. + .. admonition:: Abstract + + Memory is the performance bottleneck of modern architectures. + Keeping memory consumption as low as possible enables fast and + unobtrusive applications. But it is not easy to estimate the + memory use of programs implemented in functional languages, due to + both the complex translations of some high level constructs, and + the use of automatic memory managers. To help understand memory + allocation behavior of Scheme programs, we have designed two + complementary tools. The first one reports on frequency of + allocation, heap configurations and on memory reclamation. The + second tracks down memory leaks. We have applied these tools to + our Scheme compiler, the largest Scheme program we have been + developing. This has allowed us to drastically reduce the amount + of memory consumed during its bootstrap process, without requiring + much development time. Development tools will be neglected unless + they are both conveniently accessible and easy to use. In order to + avoid this pitfall, we have carefully designed the user interface + of these two tools. Their integration into a real programming + environment for Scheme is detailed in the paper. + * .. _SHAPIRO94: Marc Shapiro & Paulo Ferreira. 1994. "`Larchant-RDOSS: a distributed shared persistent memory and its garbage collector `_". INRIA. INRIA Rapport de Recherche no. 2399; Cornell Computer Science TR94-1466. - .. abstract: shapiro94.html + .. admonition:: Abstract Larchant-RDOSS is a distributed shared memory that persists on reliable storage across process lifetimes. Memory management is @@ -2403,7 +3083,7 @@ Bibliography Vivek Singhal, Sheetal V. Kakkad, Paul R. Wilson. 1992. "`Texas: An Efficient, Portable Persistent Store `_". University of Texas at Austin. - .. abstract: singhal92.html + .. admonition:: Abstract Texas is a persistent storage system for C++, providing high performance while emphasizing simplicity, modularity and @@ -2446,13 +3126,30 @@ Bibliography P. G. Sobalvarro. 1988. "`A Lifetime-based Garbage Collector for LISP Systems on General-Purpose Computers `_". MIT. AITR-1417. - .. abstract: sobalvarro88.html + .. admonition:: Abstract Garbage collector performance in LISP systems on custom hardware has been substantially improved by the adoption of lifetime-based garbage collection techniques. To date, however, successful lifetime-based garbage collectors have required special-purpose hardware, or at least privileged access to data structures maintained by the virtual memory system. I present here a lifetime-based garbage collector requiring no special-purpose hardware or virtual memory system support, and discuss its performance. * .. _STEELE75: - Guy L. Steele. 1975. "`Multiprocessing Compactifying Garbage Collection `_". CACM. 18:9 pp. 495--508. + Guy L. Steele. 1975. "Multiprocessing Compactifying Garbage Collection". CACM. 18:9 pp. 495--508. + + .. admonition:: Abstract + + Algorithms for a multiprocessing compactifying garbage collector + are presented and discussed. The simple case of two processors, + one performing LISP-like list operations and the other performing + garbage collection continuously, is thoroughly examined. The + necessary capabilities of each processor are defined, as well as + interprocessor communication and interlocks. Complete procedures + for garbage collection and for standard list processing primitives + are presented and thoroughly explained. Particular attention is + given to the problems of marking and relocating list cells while + another processor may be operating on them. The primary aim + throughout is to allow the list processor to run unimpeded while + the other processor reclaims list storage The more complex case + involving several list processors and one or more garbage + collection processors are also briefly discussed. * .. _STEELE76: @@ -2460,21 +3157,68 @@ Bibliography * .. _STEELE77: - Guy L. Steele. 1977. "Data Representation in PDP-10 MACLISP". MIT. AI Memo 421. + Guy L. Steele. 1977. "`Data Representation in PDP-10 MACLISP `_". MIT. AI Memo 420. + + .. admonition:: Abstract + + The internal representations of the various MacLISP data types are + presented and discussed. Certain implementation tradeoffs are + considered. The ultimate decisions on these tradeoffs are + discussed in the light of MacLISP's prime objective of being an + efficient high-level language for the implementation of large + systems such as MACSYMA. The basic strategy of garbage collection + is outlined, with reference to the specific representations + involved. Certain "clever tricks" are explained and justified. The + "address space crunch" is explained and some alternative solutions + explored. * .. _SLC99: - James M. Stichnoth, Guei-Yuan Lueh, Michal Cierniak. 1999. "`Support for Garbage Collection at Every Instruction in a Java Compiler `_". SIGPLAN. Proceedings of the 1999 ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI). SIGPLAN Notices 34(5). pp. 118--127. + James M. Stichnoth, Guei-Yuan Lueh, Michal Cierniak. 1999. "`Support for Garbage Collection at Every Instruction in a Java Compiler `_". SIGPLAN. Proceedings of the 1999 ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI). SIGPLAN Notices 34(5). pp. 118--127. + + .. admonition:: Abstract + + A high-performance implementation of a Java Virtual Machine + requires a compiler to translate Java bytecodes into native + instructions, as well as an advanced garbage collector (e.g., + copying or generational). When the Java heap is exhausted and the + garbage collector executes, the compiler must report to the + garbage collector all live object references contained in physical + registers and stack locations. Typical compilers only allow + certain instructions (e.g., call instructions and backward + branches) to be GC-safe; if GC happens at some other instruction, + the compiler may need to advance execution to the next GC-safe + point. Until now, no one has ever attempted to make every + compiler-generated instruction GC-safe, due to the perception that + recording this information would require too much space. This kind + of support could improve the GC performance in multithreaded + applications. We show how to use simple compression techniques to + reduce the size of the GC map to about 20% of the generated code + size, a result that is competitive with the best previously + published results. In addition, we extend the work of Agesen, + Detlefs, and Moss, regarding the so-called “JSR Problem” (the + single exception to Java’s type safety property), in a way that + eliminates the need for extra runtime overhead in the generated + code. * .. _SCN84: Will R Stoye, T J W Clarke, Arthur C Norman. 1984. "Some Practical Methods for Rapid Combinator Reduction". In LFP 1984, 159--166. + .. admonition:: Abstract + + The SKIM II processor is a microcoded hardware machine for the + rapid evaluation of functional languages. This paper gives details + of some of the more novel methods employed by SKIM II, and + resulting performance measurements. The authors conclude that + combinator reduction can still form the basis for the efficient + implementation of a functional language. + * .. _TD95: David Tarditi & Amer Diwan. 1995. "`Measuring the Cost of Storage Management `_". Carnegie Mellon University. CMU-CS-94-201. - .. abstract: td95.html + .. admonition:: Abstract We study the cost of storage management for garbage-collected programs compiled with the Standard ML of New Jersey compiler. We @@ -2487,7 +3231,7 @@ Bibliography Stephen Thomas, Richard E. Jones. 1994. "Garbage Collection for Shared Environment Closure Reducers". Computing Laboratory, The University of Kent at Canterbury. Technical Report 31-94. - .. abstract: tj94.html + .. admonition:: Abstract Shared environment closure reducers such as Fairbairn and Wray's TIM incur a comparatively low cost when creating a suspension, and @@ -2514,11 +3258,22 @@ Bibliography Stephen Thomas. 1995. "Garbage Collection in Shared-Environment Closure Reducers: Space-Efficient Depth First Copying using a Tailored Approach". *Information Processing Letters.* 56:1, pp. 1--7. + .. admonition:: Abstract + + Implementations of abstract machines such as the OP-TIM and the + PG-TIM need to use a tailored garbage collector which seems to + require an auxiliary stack,with a potential maximum size that is + directly proportional to the amount of live data in the heap. + However, it turns out that it is possible to build a recursive + copying collector that does not require additional space by + reusing already-scavenged space. This paper is a description of + this technique. + * .. _TT97: Mads Tofte & Jean-Pierre Talpin. 1997. "`Region-Based Memory Management `_". Information and Computation 132(2), pp. 109--176. - .. abstract: tt97.html + .. admonition:: Abstract This paper describes a memory management discipline for programs that perform dynamic memory allocation and de-allocation. At @@ -2547,11 +3302,22 @@ Bibliography Dave Ungar. 1984. "`Generation Scavenging: A Non-disruptive High Performance Storage Reclamation Algorithm `_". ACM, SIGSOFT, SIGPLAN. Practical Programming Environments Conference. + .. admonition:: Abstract + + Many interactive computing environments provide automatic storage + reclamation and virtual memory to ease the burden of managing + storage. Unfortunately, many storage reclamation algorithms impede + interaction with distracting pauses. *Generation Scavenging* is a + reclamation algorithm that has no noticeable pauses, eliminates + page faults for transient objects, compacts objects without + resorting to indirection, and reclaims circular structures, in one + third the time of traditional approaches. + * .. _UNGAR88: Dave Ungar & Frank Jackson. 1988. "`Tenuring Policies for Generation-Based Storage Reclamation `_". SIGPLAN. OOPSLA '88 Conference Proceedings, ACM SIGPLAN Notices, Vol. 23, No. 11, pp. 1--17. - .. abstract: ungar88.html + .. admonition:: Abstract One of the most promising automatic storage reclamation techniques, generation-based storage reclamation, suffers poor @@ -2571,7 +3337,7 @@ Bibliography Kiem-Phong Vo. 1996. "Vmalloc: A General and Efficient Memory Allocator". Software -- Practice and Experience. 26(3): 357--374 (1996). - .. abstract: vo96.html + .. admonition:: Abstract On C/Unix systems, the malloc interface is standard for dynamic memory allocation. Despite its popularity, malloc's shortcomings @@ -2598,11 +3364,24 @@ Bibliography Daniel C. Watson, David S. Wise. 1976. "Tuning Garwick's algorithm for repacking sequential storage". *BIT.* 16, 4 (December 1976): 442--450. + .. admonition:: Abstract + + Garwick's algorithm, for repacking LIFO lists stored in a + contiguous block of memory, bases the allocation of remaining + space upon both sharing and previous stack growth. A system + whereby the weight applied to each method can be adjusted + according to the current behaviour of the stacks is discussed. + + We also investigate the problem of determining during memory + repacking that the memory is used to saturation and the driving + program should therefore be aborted. The tuning parameters studied + here seem to offer no new grasp on this problem. + * .. _WLM92: Paul R. Wilson, Michael S. Lam, Thomas G. Moher. 1992. "Caching Considerations for Generational Garbage Collection". ACM. L&FP 92. - .. abstract: wlm92.html + .. admonition:: Abstract GC systems allocate and reuse memory cyclically; this imposes a cyclic pattern on memory accesses that has its own distinctive @@ -2633,7 +3412,7 @@ Bibliography Paul R. Wilson, Sheetal V. Kakkad. 1992. "`Pointer Swizzling at Page Fault Time `_". University of Texas at Austin. - .. abstract: wil92a.html + .. admonition:: Abstract Pointer swizzling at page fault time is a novel address translation mechanism that exploits conventional address @@ -2660,7 +3439,7 @@ Bibliography Paul R. Wilson. 1994. "`Uniprocessor Garbage Collection Techniques `_". University of Texas. - .. abstract: wil94.html + .. admonition:: Abstract We survey basic garbage collection algorithms, and variations such as incremental and generational collection; we then discuss @@ -2676,7 +3455,7 @@ Bibliography Paul R. Wilson, Mark S. Johnstone, Michael Neely, David Boles. 1995. "`Dynamic Storage Allocation: A Survey and Critical Review `_". University of Texas at Austin. - .. abstract: wil95.html + .. admonition:: Abstract Dynamic memory allocation has been a fundamental part of most computer systems since roughly 1960, and memory allocation is @@ -2700,23 +3479,69 @@ Bibliography * .. _WISE78: - David S. Wise. 1978. "`The double buddy system `_". Department of Computer Science at Indiana University. Technical Report 79. + David S. Wise. 1978. "`The double buddy system `_". Department of Computer Science at Indiana University. Technical Report 79. + + .. admonition:: Abstract + + A new buddy system is described in which the region of storage + being managed is partitioned into two sub-regions, each managed by + a fairly standard "binary" buddy system. Like the weighted buddy + systems of Shen and Peterson, the block sizes are of sizes 2\ + :superscript:`n+1` or 3·2\ :superscript:`n`, but unlike theirs + there is no extra overhead for typing information or for buddy + calculation, and an allocation which requires splitting an extant + available block only rarely creates a block smaller than the one + being allocated. Such smaller blocks are carved out only when the + boundary between the two subregions floats; the most interesting + property of this system is that the procedures for allocation and + deallocation are designed to keep blocks immediately adjacent to + the subregion boundary free, so that the boundary may be moved + within a range of unused space without disturbing blocks in use. + This option is attained with a minimum of extra computation beyond + that of a binary buddy system, and provides this scheme with a new + approach to the problem of external fragmentation. * .. _WISE79: - David S. Wise. 1979. "`Morris's garbage compaction algorithm restores reference counts `_". TOPLAS. 1, 1 (July l979): 115--120. + David S. Wise. 1979. "`Morris's garbage compaction algorithm restores reference counts `_". TOPLAS. 1, 1 (July 1979): 115--120. + + .. admonition:: Abstract + + The two-pass compaction algorithm of F.L. Morris, which follows + upon the mark phase in a garbage collector, may be modified to + recover reference counts for a hybrid storage management system. + By counting the executions of two loops in that algorithm where + upward and downward references, respectively, are forwarded to the + relocation address of one node, we can initialize a count of + active references and then update it but once. The reference count + may share space with the mark bit in each node, but it may not + share the additional space required in each pointer by Morris's + algorithm, space which remains unused outside the garbage + collector. * .. _WISE85: David S. Wise. 1985. "`Design for a multiprocessing heap with on-board reference counting `_". Springer-Verlag. In J.-P. Jouannaud (ed.), Functional Programming Languages and Computer Architecture, Lecture Notes in Computer Science 201: 289--304. + .. admonition:: Abstract + + A project to design a pair of memory chips with a modicum of + intelligence is described. Together, the two allow simple + fabrication of a small memory bank, a heap of binary (LISP-like) + nodes that offers the following features: 64-bit nodes; two + pointer fields per node up to 29 bits each; reference counts + implicitly maintained on writes; 2 bits per node for marking + (uncounted) circular references; 4 bits per node for + conditional-store testing at the memory; provision for + processor-driven, recounting garbage collection. + * .. _WISE92: .. _WISE93: David S. Wise. 1993. "`Stop-and-copy and one-bit reference counting `_". *Information Processing Letters.* 46, 5 (July 1993): 243--249. - .. abstract: wise92.html + .. admonition:: Abstract A stop-and-copy garbage collector updates one-bit reference counting with essentially no extra space and minimal memory cycles @@ -2734,15 +3559,50 @@ Bibliography David S. Wise, Joshua Walgenbach. 1996. "`Static and Dynamic Partitioning of Pointers as Links and Threads `_". SIGPLAN. Proc. 1996 ACM SIGPLAN Intl. Conf. on Functional Programming, SIGPLAN Not. 31, 6 (June 1996), pp. 42--49. + .. admonition:: Abstract + + Identifying some pointers as invisible threads, for the purposes + of storage management, is a generalization from several widely + used programming conventions, like threaded trees. The necessary + invariant is that nodes that are accessible (without threads) emit + threads only to other accessible nodes. Dynamic tagging or static + typing of threads ameliorates storage recycling both in functional + and imperative languages. + + We have seen the distinction between threads and links sharpen + both hardware- and software-supported storage management in + SCHEME, and also in C. Certainly, therefore, implementations of + languages that already have abstract management and concrete + typing, should detect and use this as a new static type. + * .. _WHHHO94: David S. Wise, Brian Heck, Caleb Hess, Willie Hunt, Eric Ost. 1997. "`Uniprocessor Performance of a Reference-Counting Hardware Heap `_". *LISP and Symbolic Computation.* 10, 2 (July 1997), pp. 159--181. + .. admonition:: Abstract + + A hardware self-managing heap memory (RCM) for languages like + LISP, SMALLTALK, and JAVA has been designed, built, tested and + benchmarked. On every pointer write from the processor, + reference-counting transactions are performed in real time within + this memory, and garbage cells are reused without processor + cycles. A processor allocates new nodes simply by reading from a + distinguished location in its address space. The memory hardware + also incorporates support for off-line, multiprocessing, + mark-sweep garbage collection. + + Performance statistics are presented from a partial implementation + of SCHEME over five different memory models and two garbage + collection strategies, from main memory (no access to RCM) to a + fully operational RCM installed on an external bus. The + performance of the RCM memory is more than competitive with main + memory. + * .. _WITHINGTON91: P. Tucker Withington. 1991. "`How Real is 'Real-Time' Garbage Collection? `_". ACM. OOPSLA/ECOOP '91 Workshop on Garbage Collection in Object-Oriented Systems. - .. abstract: withington91.html + .. admonition:: Abstract A group at Symbolics is developing a Lisp runtime kernel, derived from its Genera operating system, to support real-time control @@ -2765,7 +3625,7 @@ Bibliography G. May Yip. 1991. "`Incremental, Generational Mostly-Copying Garbage Collection in Uncooperative Environments `_". Digital Equipment Corporation. - .. abstract: yip91.html + .. admonition:: Abstract The thesis of this project is that incremental collection can be done feasibly and efficiently in an architecture and compiler @@ -2793,11 +3653,27 @@ Bibliography Taiichi Yuasa. 1990. "Real-Time Garbage Collection on General-Purpose Machines". Journal of Software and Systems. 11:3 pp. 181--198. + .. admonition:: Abstract + + An algorithm for real-time garbage collection is presented, proved + correct, and evaluated. This algorithm is intended for + list-processing systems on general-purpose machines, i.e., Von + Neumann style serial computers with a single processor. On these + machines, real-time garbage collection inevitably causes some + overhead on the overall execution of the list-processing system, + because some of the primitive list-processing operations must + check the status of garbage collection. By removing such overhead + from frequently used primitives such as pointer references (e.g., + Lisp car and cdr) and stack manipulations, the presented algorithm + reduces the execution overhead to a great extent. Although the + algorithm does not support compaction of the whole data space, it + efficiently supports partial compaction such as array relocation. + * .. _ZORN88: Benjamin Zorn & Paul Hilfinger. 1988. "`A Memory Allocation Profiler for C and Lisp Programs `_". USENIX. Proceedings for the Summer 1988 USENIX Conference, pp. 223--237. - .. abstract: zorn88.html + .. admonition:: Abstract This paper describes inprof, a tool used to study the memory allocation behavior of programs. mprof records the amount of @@ -2815,7 +3691,7 @@ Bibliography Benjamin Zorn. 1989. "`Comparative Performance Evaluation of Garbage Collection Algorithms `_". Computer Science Division (EECS) of University of California at Berkeley. Technical Report UCB/CSD 89/544 and PhD thesis. - .. abstract: zorn89.html + .. admonition:: Abstract This thesis shows that object-level, trace-driven simulation can facilitate evaluation of language runtime systems and reaches new @@ -2855,7 +3731,7 @@ Bibliography Benjamin Zorn. 1990. "Comparing Mark-and-sweep and Stop-and-copy Garbage Collection". ACM. Conference on Lisp and Functional Programming, pp. 87--98. - .. abstract: zorn90b.html + .. admonition:: Abstract Stop-and-copy garbage collection has been preferred to mark-and-sweep collection in the last decade because its @@ -2873,7 +3749,7 @@ Bibliography Benjamin Zorn. 1990. "`Barrier Methods for Garbage Collection `_". University of Colorado at Boulder. Technical Report CU-CS-494-90. - .. abstract: zorn90.html + .. admonition:: Abstract Garbage collection algorithms have been enhanced in recent years with two methods: generation-based collection and Baker @@ -2900,7 +3776,7 @@ Bibliography Benjamin Zorn. 1991. "`The Effect of Garbage Collection on Cache Performance `_". University of Colorado at Boulder. Technical Report CU-CS-528-91. - .. abstract: zorn91.html + .. admonition:: Abstract Cache performance is an important part of total performance in modern computer systems. This paper describes the use of @@ -2926,7 +3802,7 @@ Bibliography Benjamin Zorn & Dirk Grunwald. 1992. "`Empirical Measurements of Six Allocation-intensive C Programs `_". ACM, SIGPLAN. SIGPLAN notices, 27(12):71--80. - .. abstract: zorn92b.html + .. admonition:: Abstract Dynamic memory management is an important part of a large class of computer programs and high-performance algorithms for dynamic @@ -2950,7 +3826,7 @@ Bibliography Benjamin Zorn. 1993. "`The Measured Cost of Conservative Garbage Collection `_". Software -- Practice and Experience. 23(7):733--756. - .. abstract: zorn92.html + .. admonition:: Abstract Because dynamic memory management is an important part of a large class of computer programs, high-performance algorithms for @@ -2979,7 +3855,7 @@ Bibliography Benjamin Zorn & Dirk Grunwald. 1994. "`Evaluating Models of Memory Allocation `_". ACM. Transactions on Modeling and Computer Simulation 4(1):107--131. - .. abstract: zorn92a.html + .. admonition:: Abstract Because dynamic memory management is an important part of a large class of computer programs, high-performance algorithms for diff --git a/mps/manual/source/design/index.rst b/mps/manual/source/design/index.rst index 49d5b1cd85f..8ac8bb9e9c2 100644 --- a/mps/manual/source/design/index.rst +++ b/mps/manual/source/design/index.rst @@ -10,13 +10,16 @@ Design cbs config critical-path + failover freelist guide.hex.trans guide.impl.c.format interface-c keyword-arguments + land nailboard range ring sig + splay type diff --git a/mps/manual/source/design/old.rst b/mps/manual/source/design/old.rst index b002b14ef35..2aefac2a40c 100644 --- a/mps/manual/source/design/old.rst +++ b/mps/manual/source/design/old.rst @@ -53,7 +53,6 @@ Old design scan seg shield - splay sso1al strategy telemetry diff --git a/mps/manual/source/extensions/mps/designs.py b/mps/manual/source/extensions/mps/designs.py index 83eb78c7115..ceaee15a256 100644 --- a/mps/manual/source/extensions/mps/designs.py +++ b/mps/manual/source/extensions/mps/designs.py @@ -124,6 +124,15 @@ def convert_file(name, source, dest): with open(dest, 'wb') as out: out.write(s.encode('utf-8')) +def newer(src, target): + """Return True if src is newer (that is, modified more recently) than + target, False otherwise. + + """ + return (not os.path.isfile(target) + or os.path.getmtime(target) < os.path.getmtime(src) + or os.path.getmtime(target) < os.path.getmtime(__file__)) + # Mini-make def convert_updated(app): app.info(bold('converting MPS design documents')) @@ -131,11 +140,11 @@ def convert_updated(app): name = os.path.splitext(os.path.basename(design))[0] if name == 'index': continue converted = 'source/design/%s.rst' % name - if (not os.path.isfile(converted) - or os.path.getmtime(converted) < os.path.getmtime(design) - or os.path.getmtime(converted) < os.path.getmtime(__file__)): + if newer(design, converted): app.info('converting design %s' % name) convert_file(name, design, converted) for diagram in glob.iglob('../design/*.svg'): - shutil.copyfile(diagram, 'source/design/%s' % os.path.basename(diagram)) - + target = os.path.join('source/design/', os.path.basename(diagram)) + if newer(diagram, target): + shutil.copyfile(diagram, target) + diff --git a/mps/manual/source/glossary/a.rst b/mps/manual/source/glossary/a.rst index e7c6afe4d4f..ec4da5f86d2 100644 --- a/mps/manual/source/glossary/a.rst +++ b/mps/manual/source/glossary/a.rst @@ -202,7 +202,11 @@ Memory Management Glossary: A .. mps:specific:: An alignment is represented by the unsigned integral type - :c:type:`mps_align_t`. It must be a positive power of 2. + :c:type:`mps_align_t`. It must be a power of 2. The + alignment of objects allocated in a :term:`pool` may be + specified by passing the :c:macro:`MPS_KEY_ALIGN` + :term:`keyword argument` when calling + :c:func:`mps_pool_create_k`. alive @@ -476,6 +480,12 @@ Memory Management Glossary: A .. opposite:: :term:`manual memory management`. + .. mps:specific:: + + The MPS provides automatic memory management through + :term:`pool classes` such as :ref:`pool-amc`, + :ref:`pool-ams`, and :ref:`pool-awl`. + automatic storage duration In :term:`C`, :term:`objects` that are declared with diff --git a/mps/manual/source/glossary/c.rst b/mps/manual/source/glossary/c.rst index b2d8f2b1400..2449ce9f82a 100644 --- a/mps/manual/source/glossary/c.rst +++ b/mps/manual/source/glossary/c.rst @@ -131,7 +131,7 @@ Memory Management Glossary: C A cactus stack is a :term:`stack` with branches. When diagrammed, its shape resembles that of a `saguaro cactus - `_. + `_. In languages that support :term:`continuations`, :term:`activation records` can have :term:`indefinite extent`. @@ -615,6 +615,12 @@ Memory Management Glossary: C .. seealso:: :term:`broken heart`, :term:`forwarding pointer`, :term:`two-space collector`. + .. mps:specific:: + + The :ref:`pool-amc` pool class implements copying garbage + collection (more precisely, :term:`mostly-copying garbage + collection`). + core A historical synonym for :term:`main memory`, deriving from diff --git a/mps/manual/source/glossary/f.rst b/mps/manual/source/glossary/f.rst index 540cc048d46..eedbd00a9da 100644 --- a/mps/manual/source/glossary/f.rst +++ b/mps/manual/source/glossary/f.rst @@ -26,6 +26,11 @@ Memory Management Glossary: F .. similar:: :term:`in-band header`. + .. mps:specific:: + + :term:`Debugging pools` use fenceposts. See + :ref:`topic-debugging`. + fencepost error fence post error diff --git a/mps/manual/source/glossary/g.rst b/mps/manual/source/glossary/g.rst index 25feb894906..4dc74e66221 100644 --- a/mps/manual/source/glossary/g.rst +++ b/mps/manual/source/glossary/g.rst @@ -89,7 +89,7 @@ Memory Management Glossary: G This term is often used when referring to particular implementations or algorithms, for example, "the - Boehm-Demers-Weiser *collector*". + Boehm--Demers--Weiser *collector*". GB @@ -132,16 +132,16 @@ Memory Management Glossary: G .. mps:specific:: The :term:`client program` specifies the generational - structure of a :term:`pool` using a :term:`generation - chain`. See :ref:`topic-collection`. + structure of a :term:`pool` (or group of pools) using a + :term:`generation chain`. See :ref:`topic-collection`. generation chain .. mps:specific:: A data structure that specifies the structure of the - :term:`generations` in a :term:`pool`. See - :ref:`topic-collection`. + :term:`generations` in a :term:`pool` (or group of pools). + See :ref:`topic-collection`. generation scavenging @@ -174,6 +174,11 @@ Memory Management Glossary: G .. seealso:: :term:`remembered set`. + .. mps:specific:: + + The :ref:`pool-amc` and :ref:`pool-amcz` pool classes + support generational garbage collection. + generational hypothesis .. aka:: *infant mortality*. diff --git a/mps/manual/source/glossary/i.rst b/mps/manual/source/glossary/i.rst index 9ce2a3f9cea..b174241959c 100644 --- a/mps/manual/source/glossary/i.rst +++ b/mps/manual/source/glossary/i.rst @@ -133,6 +133,12 @@ Memory Management Glossary: I .. bibref:: :ref:`Appel et al. (1988) `, :ref:`Boehm et al. (1991) `. + .. mps:specific:: + + The MPS uses incremental collection, except for + collections started by calling + :c:func:`mps_arena_collect`. + incremental update Incremental-update algorithms for :term:`tracing `, diff --git a/mps/manual/source/glossary/index.rst b/mps/manual/source/glossary/index.rst index 91e022df5ad..40656261350 100644 --- a/mps/manual/source/glossary/index.rst +++ b/mps/manual/source/glossary/index.rst @@ -32,3 +32,594 @@ Memory Management Glossary v w z + +All +=== + +:term:`absolute address ` +:term:`activation frame ` +:term:`activation record` +:term:`activation stack ` +:term:`active ` +:term:`address` +:term:`address space` +:term:`address space layout randomization` +:term:`address translation cache ` +:term:`address-ordered first fit` +:term:`aging space` +:term:`algebraic data type` +:term:`alignment` +:term:`alive ` +:term:`allocate` +:term:`allocation frame` +:term:`allocation mechanism` +:term:`allocation pattern` +:term:`allocation point` +:term:`allocation point protocol` +:term:`allocation policy` +:term:`allocation strategy` +:term:`allocator` +:term:`ambiguous reference` +:term:`ambiguous root` +:term:`arena` +:term:`arena class` +:term:`ASLR
` +:term:`assertion` +:term:`asynchronous garbage collector` +:term:`ATC ` +:term:`atomic object ` +:term:`automatic memory management` +:term:`automatic storage duration` + +:term:`backing store` +:term:`barrier (1)` +:term:`barrier (2)` +:term:`barrier hit ` +:term:`base pointer` +:term:`best fit` +:term:`BIBOP` +:term:`big bag of pages ` +:term:`binary buddies` +:term:`bit array ` +:term:`bit table ` +:term:`bit vector ` +:term:`bitmap` +:term:`bitmapped fit` +:term:`bitmask` +:term:`bitset ` +:term:`black` +:term:`blacklisting` +:term:`black-listing` +:term:`block` +:term:`bounds error ` +:term:`boxed` +:term:`break-table` +:term:`brk` +:term:`broken heart` +:term:`bucket` +:term:`buddy system` +:term:`buffer` +:term:`bus error` +:term:`byte (1)` +:term:`byte (2)` +:term:`byte (3)` +:term:`byte (4)` + +:term:`C89 ` +:term:`C90` +:term:`C99` +:term:`cache (1)` +:term:`cache (2)` +:term:`cache memory ` +:term:`cache policy` +:term:`caching (3)` +:term:`cactus stack` +:term:`card` +:term:`card marking` +:term:`cell ` +:term:`Cheney collector` +:term:`Cheney scan ` +:term:`clamped state` +:term:`client arena` +:term:`client object` +:term:`client pointer` +:term:`client program ` +:term:`closure` +:term:`coalesce` +:term:`collect` +:term:`collection ` +:term:`collection cycle` +:term:`collector (1) ` +:term:`collector (2)` +:term:`color` +:term:`colour` +:term:`commit limit` +:term:`committed (1) ` +:term:`committed (2)` +:term:`compactifying ` +:term:`compaction` +:term:`composite object` +:term:`comprehensive` +:term:`concurrent garbage collection ` +:term:`condemned set` +:term:`connected` +:term:`cons (1)` +:term:`cons (2) ` +:term:`conservative garbage collection` +:term:`constant root` +:term:`constructor (1)` +:term:`constructor (2)` +:term:`continuation` +:term:`control stack` +:term:`cool` +:term:`copy method` +:term:`copying garbage collection` +:term:`core` +:term:`creation space` +:term:`critical path` +:term:`crossing map` +:term:`cyclic data structure` + +:term:`dangling pointer` +:term:`data stack` +:term:`dead` +:term:`deallocate ` +:term:`debugging pool` +:term:`deferred coalescing` +:term:`deferred reference counting` +:term:`dependent object` +:term:`derived pointer ` +:term:`derived type` +:term:`destructor (1)` +:term:`destructor (2)` +:term:`DGC ` +:term:`direct method` +:term:`dirty bit` +:term:`distributed garbage collection` +:term:`double buddies` +:term:`double free` +:term:`doubleword` +:term:`doubly weak hash table` +:term:`DRAM ` +:term:`dynamic allocation ` +:term:`dynamic extent` +:term:`dynamic memory` +:term:`dynamic RAM ` + +:term:`ecru ` +:term:`edge` +:term:`entry table (1)` +:term:`entry table (2)` +:term:`exact garbage collection` +:term:`exact reference` +:term:`exact root` +:term:`exact segregated fit` +:term:`execution stack ` +:term:`exit table` +:term:`extent ` +:term:`external fragmentation` + +:term:`fencepost` +:term:`fence post` +:term:`fencepost error` +:term:`fence post error` +:term:`Fibonacci buddies` +:term:`FIFO-ordered first fit` +:term:`file mapping ` +:term:`finalization` +:term:`finalized block` +:term:`first fit` +:term:`fix` +:term:`flip` +:term:`floating garbage` +:term:`foreign code` +:term:`format` +:term:`format method` +:term:`formatted object` +:term:`forward method` +:term:`forwarding marker` +:term:`forwarding object` +:term:`forwarding pointer` +:term:`fragmentation` +:term:`frame ` +:term:`free (1)` +:term:`free (2)` +:term:`free (3)` +:term:`free (4) ` +:term:`free block` +:term:`free block chain` +:term:`free list` +:term:`free store ` +:term:`freestore ` +:term:`from space` +:term:`fromspace` +:term:`function pointer` +:term:`function record ` + +:term:`garbage` +:term:`garbage collection` +:term:`garbage collector` +:term:`GB ` +:term:`GC ` +:term:`General Protection Fault` +:term:`generation` +:term:`generation chain` +:term:`generation scavenging ` +:term:`generational garbage collection` +:term:`generational hypothesis` +:term:`gigabyte` +:term:`good fit` +:term:`GPF ` +:term:`grain` +:term:`graph` +:term:`gray` +:term:`grey` +:term:`gray list` +:term:`grey list` + +:term:`handle` +:term:`header ` +:term:`heap` +:term:`heap allocation` +:term:`hit` +:term:`hit rate` +:term:`hot` +:term:`huge page` + +:term:`immediate data` +:term:`immune set` +:term:`immutable` +:term:`immutable object ` +:term:`in-band header` +:term:`in parameter` +:term:`in/out parameter` +:term:`incremental garbage collection` +:term:`incremental update` +:term:`indefinite extent` +:term:`indexed fit` +:term:`indirect method` +:term:`infant mortality ` +:term:`inline allocation (1)` +:term:`inline allocation (2)` +:term:`inter-generational pointer` +:term:`interior pointer` +:term:`internal fragmentation` +:term:`invalid page fault` +:term:`inverted page table` +:term:`inverted page-table` +:term:`is-forwarded method` + +:term:`kB ` +:term:`keyword argument` +:term:`kilobyte` + +:term:`large object area` +:term:`large page ` +:term:`leaf object` +:term:`leak ` +:term:`life ` +:term:`lifetime` +:term:`LIFO-ordered first fit` +:term:`limited-field reference count` +:term:`linear addressing` +:term:`live` +:term:`load` +:term:`locality of reference` +:term:`location ` +:term:`location dependency` +:term:`lock free` +:term:`logical address ` +:term:`longword ` + +:term:`machine word ` +:term:`main memory` +:term:`malloc` +:term:`manual memory management` +:term:`mapped` +:term:`mapping` +:term:`mark-compact` +:term:`mark-sweep` +:term:`mark-and-sweep` +:term:`marking` +:term:`MB ` +:term:`megabyte` +:term:`memoization ` +:term:`memory (1)` +:term:`memory (2)` +:term:`memory (3)
` +:term:`memory (4)` +:term:`memory bandwidth` +:term:`memory cache ` +:term:`memory hierarchy ` +:term:`memory leak` +:term:`memory location` +:term:`memory management` +:term:`Memory Management Unit ` +:term:`memory manager` +:term:`memory mapping` +:term:`memory protection ` +:term:`message` +:term:`message queue` +:term:`message type` +:term:`misaligned ` +:term:`miss` +:term:`miss rate` +:term:`mmap` +:term:`MMU` +:term:`mostly-copying garbage collection` +:term:`mostly-exact garbage collection ` +:term:`mostly-precise garbage collection ` +:term:`moving garbage collector` +:term:`moving memory manager` +:term:`mutable` +:term:`mutator` + +:term:`nailing ` +:term:`natural alignment` +:term:`nepotism` +:term:`next fit` +:term:`new space` +:term:`newspace ` +:term:`node` +:term:`non-moving garbage collector` +:term:`non-moving memory manager` +:term:`nursery generation ` +:term:`nursery space` + +:term:`object` +:term:`object format` +:term:`object pointer` +:term:`off-white` +:term:`old space ` +:term:`oldspace ` +:term:`one-bit reference count` +:term:`opaque type` +:term:`out parameter` +:term:`out-of-band header` +:term:`overcommit` +:term:`overwriting error` + +:term:`padding` +:term:`padding method` +:term:`padding object` +:term:`page` +:term:`page fault` +:term:`page marking` +:term:`page protection ` +:term:`page table` +:term:`paged in` +:term:`paged out` +:term:`paging` +:term:`palimpsest` +:term:`parallel garbage collection` +:term:`parked state` +:term:`perfect fit` +:term:`phantom reachable` +:term:`phantomly reachable` +:term:`phantom reference` +:term:`physical address` +:term:`physical address space` +:term:`physical memory (1)` +:term:`physical memory (2)` +:term:`physical storage ` +:term:`pig in the python` +:term:`pig in the snake ` +:term:`pinning` +:term:`placement policy ` +:term:`platform` +:term:`plinth` +:term:`pointer` +:term:`pool` +:term:`pool class` +:term:`precise garbage collection ` +:term:`precise reference ` +:term:`precise root ` +:term:`premature free` +:term:`premature promotion ` +:term:`premature tenuring` +:term:`primary storage
` +:term:`promotion` +:term:`protectable root` +:term:`protection` +:term:`protection exception ` +:term:`protection fault` +:term:`protection violation ` + +:term:`quadword` + +:term:`RAM` +:term:`random access memory ` +:term:`ramp allocation` +:term:`rank` +:term:`rash` +:term:`raw ` +:term:`reachable` +:term:`read barrier` +:term:`read fault` +:term:`read-only memory ` +:term:`real memory (1)` +:term:`real memory (2) ` +:term:`reclaim` +:term:`recycle` +:term:`reference` +:term:`reference counting` +:term:`reference object` +:term:`region inference` +:term:`register` +:term:`register set partitioning` +:term:`relocation` +:term:`remembered set` +:term:`remote reference` +:term:`replicating garbage collector` +:term:`reserved` +:term:`resident` +:term:`resident set` +:term:`result code` +:term:`resurrection` +:term:`ROM` +:term:`root` +:term:`root description` +:term:`root mode` +:term:`root set` + +:term:`sbrk` +:term:`scalar data type` +:term:`scan` +:term:`scan method` +:term:`scan state` +:term:`scavenging garbage collection ` +:term:`SDRAM` +:term:`segmentation violation` +:term:`segmented addressing` +:term:`segregated allocation cache` +:term:`segregated fit` +:term:`segregated free list` +:term:`segregated free-list` +:term:`semi-conservative garbage collection` +:term:`semi-space` +:term:`semi-space collector ` +:term:`sequential fit` +:term:`sequential store buffer` +:term:`shared memory` +:term:`simple object` +:term:`simple segregated storage` +:term:`size` +:term:`size class` +:term:`skip method` +:term:`smart pointer` +:term:`snap-out` +:term:`snapshot at the beginning` +:term:`soft reference` +:term:`softly reachable` +:term:`space leak ` +:term:`spare commit limit` +:term:`spare committed memory` +:term:`spaghetti stack ` +:term:`splat` +:term:`split` +:term:`SRAM ` +:term:`SSB ` +:term:`stack` +:term:`stack allocation` +:term:`stack frame` +:term:`stack record ` +:term:`static allocation` +:term:`static memory (1)` +:term:`static memory (2)` +:term:`static object` +:term:`static RAM ` +:term:`static storage duration` +:term:`stepper function` +:term:`sticky reference count ` +:term:`stop-and-copy collection` +:term:`storage ` +:term:`storage hierarchy` +:term:`storage level` +:term:`storage management ` +:term:`store (1)` +:term:`store (2) ` +:term:`stretchy vector` +:term:`strict segregated fit` +:term:`strong reference` +:term:`strong root` +:term:`strong tri-color invariant` +:term:`strong tri-colour invariant` +:term:`strong tricolor invariant` +:term:`strong tricolour invariant` +:term:`strongly reachable` +:term:`suballocator` +:term:`subgraph` +:term:`superpage ` +:term:`sure reference ` +:term:`swap space` +:term:`swapped in` +:term:`swapped out` +:term:`swapping` +:term:`sweeping` +:term:`synchronous garbage collector` + +:term:`tabling ` +:term:`tag` +:term:`tagged architecture` +:term:`tagged reference` +:term:`TB (1) ` +:term:`TB (2) ` +:term:`telemetry filter` +:term:`telemetry label` +:term:`telemetry stream` +:term:`tenuring ` +:term:`terabyte` +:term:`termination ` +:term:`thrash` +:term:`thread` +:term:`threatened set ` +:term:`TLB ` +:term:`to space` +:term:`tospace` +:term:`trace` +:term:`tracing garbage collection` +:term:`translation buffer` +:term:`translation lookaside buffer` +:term:`transparent alias` +:term:`transparent type` +:term:`transport` +:term:`transport snap-out ` +:term:`treadmill` +:term:`tri-color invariant` +:term:`tri-colour invariant` +:term:`tricolor invariant` +:term:`tricolour invariant` +:term:`tri-color marking` +:term:`tri-colour marking` +:term:`tricolor marking` +:term:`tricolour marking` +:term:`two-space collector` +:term:`two space collector` +:term:`type-accurate garbage collection ` +:term:`type punning` + +:term:`unaligned` +:term:`unboxed` +:term:`unclamped state` +:term:`undead` +:term:`unmapped` +:term:`unreachable` +:term:`unsure reference ` +:term:`unwrapped` +:term:`use after free ` + +:term:`value object` +:term:`variety` +:term:`vector data type` +:term:`virtual address` +:term:`virtual address space` +:term:`virtual memory` +:term:`virtual memory arena` +:term:`visitor function ` +:term:`VM (1) ` +:term:`VM (2)` + +:term:`weak-key hash table` +:term:`weak-value hash table` +:term:`weak hash table` +:term:`weak reference (1)` +:term:`weak reference (2)` +:term:`weak root` +:term:`weak tri-color invariant` +:term:`weak tri-colour invariant` +:term:`weak tricolor invariant` +:term:`weak tricolour invariant` +:term:`weakly reachable` +:term:`weighted buddies` +:term:`weighted reference counting` +:term:`white` +:term:`word` +:term:`working set` +:term:`worst fit` +:term:`wrapped` +:term:`wrapper` +:term:`write barrier` +:term:`write fault` + +:term:`ZCT ` +:term:`zero count table` diff --git a/mps/manual/source/glossary/l.rst b/mps/manual/source/glossary/l.rst index 5a143e55f69..3e4f0db4270 100644 --- a/mps/manual/source/glossary/l.rst +++ b/mps/manual/source/glossary/l.rst @@ -81,9 +81,14 @@ Memory Management Glossary: L If leaf objects can be identified, a :term:`garbage collector` can make certain optimizations: leaf objects do not have to be :term:`scanned ` for references nor - are :term:`barrier (1)` needed to detect + are :term:`barriers (1)` needed to detect and maintain references in the object. + .. mps:specific:: + + The :ref:`pool-amcz` and :ref:`pool-lo` pool classes are + designed for the storage of leaf objects. + leak .. see:: :term:`memory leak`. diff --git a/mps/manual/source/glossary/m.rst b/mps/manual/source/glossary/m.rst index 4562d30d7b6..db4d8b88a59 100644 --- a/mps/manual/source/glossary/m.rst +++ b/mps/manual/source/glossary/m.rst @@ -535,6 +535,11 @@ Memory Management Glossary: M .. bibref:: :ref:`Bartlett (1989) `, :ref:`Yip (1991) `. + .. mps:specific:: + + The :ref:`pool-amc` pool class implements mostly-copying + garbage collection. + mostly-exact garbage collection .. see:: :term:`semi-conservative garbage collection`. diff --git a/mps/manual/source/glossary/n.rst b/mps/manual/source/glossary/n.rst index 24ddcf66cea..67fbd65a371 100644 --- a/mps/manual/source/glossary/n.rst +++ b/mps/manual/source/glossary/n.rst @@ -117,4 +117,10 @@ Memory Management Glossary: N The size of the nursery space must be chosen carefully. Often it is related to the size of :term:`physical memory (1)`. + .. mps:specific:: + By default, a garbage-collected :term:`pool` allocates + into the first :term:`generation` in its :term:`generation + chain`, but this can be altered by setting the + :c:macro:`MPS_KEY_GEN` :term:`keyword argument` when + calling :c:func:`mps_pool_create_k`. diff --git a/mps/manual/source/glossary/p.rst b/mps/manual/source/glossary/p.rst index fc08d9c2abb..5fdba129d77 100644 --- a/mps/manual/source/glossary/p.rst +++ b/mps/manual/source/glossary/p.rst @@ -167,7 +167,7 @@ Memory Management Glossary: P mutator changing :term:`objects` while collection occurs. The problem is similar to that of :term:`incremental GC `, but harder. The solution - typically involves :term:`barrier (1)`. + typically involves :term:`barriers (1)`. .. similar:: :term:`incremental `. @@ -222,7 +222,7 @@ Memory Management Glossary: P .. link:: - `Class java.lang.ref.PhantomReference `_, `Reference Objects and Garbage Collection `_. + `Class java.lang.ref.PhantomReference `_, `Reference Objects and Garbage Collection `_. phantom reference @@ -239,7 +239,7 @@ Memory Management Glossary: P .. link:: - `Class java.lang.ref.PhantomReference `_, `Reference Objects and Garbage Collection `_. + `Class java.lang.ref.PhantomReference `_, `Reference Objects and Garbage Collection `_. physical address @@ -321,6 +321,14 @@ Memory Management Glossary: P .. seealso:: :term:`generational garbage collection`. + .. mps:specific:: + + A :term:`pool` can be configured to allocate into a + specific :term:`generation` in its :term:`generation + chain` by setting the :c:macro:`MPS_KEY_GEN` + :term:`keyword argument` when calling + :c:func:`mps_pool_create_k`. + pig in the snake .. see:: :term:`pig in the python`. diff --git a/mps/manual/source/glossary/r.rst b/mps/manual/source/glossary/r.rst index a521c1d7bd4..2c8a9ef70ad 100644 --- a/mps/manual/source/glossary/r.rst +++ b/mps/manual/source/glossary/r.rst @@ -93,7 +93,7 @@ Memory Management Glossary: R .. link:: - `Package java.lang.ref `_, `Reference Objects and Garbage Collection `_. + `Package java.lang.ref `_, `Reference Objects and Garbage Collection `_. read barrier @@ -317,7 +317,7 @@ Memory Management Glossary: R .. link:: - `Package java.lang.ref `_, `Reference Objects and Garbage Collection `_. + `Package java.lang.ref `_, `Reference Objects and Garbage Collection `_. .. bibref:: :ref:`Dybvig et al. (1993) `. @@ -471,6 +471,11 @@ Memory Management Glossary: R .. seealso:: :term:`mapping`, :term:`mmap`. + .. mps:specific:: + + The function :c:func:`mps_arena_reserved` returns the + total address space reserved by an arena. + resident In a :term:`cache (2)` system, that part of the cached storage diff --git a/mps/manual/source/glossary/s.rst b/mps/manual/source/glossary/s.rst index 41389cb2103..dc9355f2a0f 100644 --- a/mps/manual/source/glossary/s.rst +++ b/mps/manual/source/glossary/s.rst @@ -333,7 +333,7 @@ Memory Management Glossary: S By overloading certain operators it is possible for the class to present the illusion of being a pointer, so that - ``operator\*``, ``operator-\>``, etc. can be used as normal. + ``operator*``, ``operator->``, etc. can be used as normal. Reference counting allows the objects that are referred to using the smart pointer class to have their :term:`memory (1)` automatically :term:`reclaimed` when they are no longer @@ -429,7 +429,7 @@ Memory Management Glossary: S .. link:: - `Class java.lang.ref.SoftReference `_, `Reference Objects and Garbage Collection `_. + `Class java.lang.ref.SoftReference `_, `Reference Objects and Garbage Collection `_. softly reachable @@ -453,7 +453,7 @@ Memory Management Glossary: S .. link:: - `Class java.lang.ref.SoftReference `_, `Reference Objects and Garbage Collection `_. + `Class java.lang.ref.SoftReference `_, `Reference Objects and Garbage Collection `_. space leak @@ -785,6 +785,26 @@ Memory Management Glossary: S .. see:: :term:`memory (1)`. + stretchy vector + + A :term:`vector ` that may grow or shrink to + accommodate adding or removing elements. Named after the + ```` abstract class in Dylan. + + .. relevance:: + + In the presence of an :term:`asynchronous garbage + collector`, the vector and its size may need to be updated + atomically. + + .. link:: + + `Dylan Reference Manual: Collections `_. + + .. mps:specific:: + + See :ref:`guide-stretchy-vector`. + strict segregated fit A :term:`segregated fit` :term:`allocation mechanism` which @@ -806,7 +826,7 @@ Memory Management Glossary: S collection>`, a strong reference is a :term:`reference` that keeps the :term:`object` it refers to :term:`alive `. - A strong reference is the usual sort of reference; The term is + A strong reference is the usual sort of reference: the term is usually used to draw a contrast with :term:`weak reference (1)`. @@ -819,7 +839,7 @@ Memory Management Glossary: S A strong root is a :term:`root` such that all :term:`references` in it are :term:`strong references`. - A strong root is the usual sort of root. The term is usually + A strong root is the usual sort of root: the term is usually used to draw a contrast with :term:`weak root`. .. opposite:: :term:`weak root`. diff --git a/mps/manual/source/glossary/w.rst b/mps/manual/source/glossary/w.rst index 7d061294ce6..46d8d9edd06 100644 --- a/mps/manual/source/glossary/w.rst +++ b/mps/manual/source/glossary/w.rst @@ -70,7 +70,7 @@ Memory Management Glossary: W .. link:: - `Class java.lang.ref.WeakReference `_, `Reference Objects and Garbage Collection `_. + `Class java.lang.ref.WeakReference `_, `Reference Objects and Garbage Collection `_. weak root @@ -134,7 +134,7 @@ Memory Management Glossary: W .. link:: - `Class java.lang.ref.WeakReference `_, `Reference Objects and Garbage Collection `_. + `Class java.lang.ref.WeakReference `_, `Reference Objects and Garbage Collection `_. weighted buddies diff --git a/mps/manual/source/guide/index.rst b/mps/manual/source/guide/index.rst index abd9ef242ca..a7218dd2ba5 100644 --- a/mps/manual/source/guide/index.rst +++ b/mps/manual/source/guide/index.rst @@ -9,6 +9,7 @@ Guide overview build lang + vector debug perf advanced diff --git a/mps/manual/source/guide/vector.rst b/mps/manual/source/guide/vector.rst new file mode 100644 index 00000000000..8b9452ac1f6 --- /dev/null +++ b/mps/manual/source/guide/vector.rst @@ -0,0 +1,152 @@ +.. index:: + single: stretchy vectors + single: atomic updates + +.. _guide-stretchy-vector: + +The stretchy vector problem +============================ + +The :ref:`previous chapter ` pointed out that: + + Because the MPS is :term:`asynchronous `, it might be scanning, moving, or collecting, at any + point in time. + +The consequences of this can take a while to sink in, so this chapter +discusses a particular instance that catches people out: the *stretchy +vector* problem (named after the |stretchy-vector|_ abstract class in +Dylan). + +.. |stretchy-vector| replace:: ```` +.. _stretchy-vector: http://opendylan.org/books/drm/Collection_Classes#stretchy-vector + +A *stretchy vector* is a vector that can change length dynamically. +Such a vector is often implemented using two objects: an array, and a +header object that stores the length and a pointer to an array. +Stretching (or shrinking) such a vector involves five steps: + +1. allocate a new array; +2. copy elements from the old array to the new array; +3. clear unused elements in the new array (if stretching); +4. update the pointer to the array in the header; +5. update the length in the header. + +For example: + +.. code-block:: c + + typedef struct vector_s { + type_t type; /* TYPE_VECTOR */ + size_t length; /* number of elements */ + obj_t *array; /* array of elements */ + } vector_s, *vector_t; + + void resize_vector(vector_t vector, size_t new_length) { + obj_t *new_array = realloc(vector->array, new_length * sizeof(obj_t)); + if (new_array == NULL) + error("out of memory in resize_vector"); + if (vector->length < new_length) { + memset(&vector->array[vector->length], 0, + (new_length - vector->length) * sizeof(obj_t)); + } + vector->array = new_array; + vector->length = new_length; + } + +When adapting this code to the MPS, the following problems must be +solved: + +1. During step 2, the new array must be :term:`reachable` from the + roots, and :term:`scannable `. (If it's not reachable, then + it may be collected; if it's not scannable, then references it + contains will not be updated when they are moved by the collector.) + + This can solved by storing the new array in a :term:`root` until + the header has been updated. If the thread's stack has been + registered as a root by calling :c:func:`mps_root_create_reg` then + any local variable will do. + +2. References in the new array must not be scanned until they have been + copied or cleared. (Otherwise they will be invalid.) + + This can be solved by clearing the new array before calling + :c:func:`mps_commit`. + +3. The old array must be scanned at the old length (otherwise the scan + may run off the end of the old array when the vector grows), and + the new array must be scanned at the new length (otherwise the scan + may run off the end of the old array when the vector shrinks). + +4. The array object must be scannable without referring to the header + object. (Because the header object may have been protected by the + MPS: see :ref:`topic-format-cautions`.) + +Problems 3 and 4 can be solved by storing the length in the array. The +revised data structures and resizing code might look like this: + +.. code-block:: c + + typedef struct vector_s { + type_t type; /* TYPE_VECTOR */ + obj_t array; /* TYPE_ARRAY object */ + } vector_s, *vector_t; + + typedef struct array_s { + type_t type; /* TYPE_ARRAY */ + size_t length; /* number of elements */ + obj_t array[0]; /* array of elements */ + } array_s, *array_t; + + void resize_vector(vector_t vector, size_t new_length) { + size_t size = ALIGN_OBJ(offsetof(array_s, array) + new_length * sizeof(obj_t)); + mps_addr_t addr; + array_t array; + + do { + mps_res_t res = mps_reserve(&addr, ap, size); + if (res != MPS_RES_OK) error("out of memory in resize_vector"); + array = addr; + array->type = TYPE_ARRAY; + array->length = new_length; + memset(array->array, 0, new_length * sizeof(obj_t)); + /* Now the new array is scannable, and it is reachable via the + * local variable 'array', so it is safe to commit it. */ + } while(!mps_commit(ap, addr, size)); + + /* Copy elements after committing, so that the collector will + * update them if they move. */ + memcpy(array->array, vector->array->array, + min(vector->array->length, new_length) * sizeof(obj_t)); + vector->array = array; + } + +Similar difficulties can arise even when adapting code written for +other garbage collectors. For example, here's the function +|setarrayvector|_ from Lua_: + +.. |setarrayvector| replace:: ``setarrayvector()`` +.. _setarrayvector: http://www.lua.org/source/5.2/ltable.c.html#setarrayvector +.. _Lua: http://www.lua.org + +.. code-block:: c + + static void setarrayvector (lua_State *L, Table *t, int size) { + int i; + luaM_reallocvector(L, t->array, t->sizearray, size, TValue); + for (i=t->sizearray; iarray[i]); + t->sizearray = size; + } + +Lua's garbage collector is :term:`synchronous `, so it can be assumed that there cannot be a garbage +collection between the assignment to ``t->array`` (resulting from the +expansion of the |luaM_reallocvector|_ macro) and the assignment to +``t->sizearray``, and so the collector will always consistently see +either the old array or the new array, with the correct size. This +assumption will no longer be correct if this code is adapted to the +MPS. + +.. |luaM_reallocvector| replace:: ``luaM_reallocvector()`` +.. _luaM_reallocvector: http://www.lua.org/source/5.2/lmem.h.html#luaM_reallocvector diff --git a/mps/manual/source/index.rst b/mps/manual/source/index.rst index 161a13ad3b3..4edc69bbf60 100644 --- a/mps/manual/source/index.rst +++ b/mps/manual/source/index.rst @@ -1,7 +1,3 @@ -.. Memory Pool System documentation master file, created by - sphinx-quickstart on Tue Oct 9 11:21:17 2012. - - Memory Pool System ################## @@ -15,26 +11,26 @@ Memory Pool System design/old -Memory Management Reference -########################### - -.. toctree:: - :maxdepth: 2 - - mmref/index - mmref/bib - mmref/credit - - Appendices ########## .. toctree:: :maxdepth: 1 + bib glossary/index copyright contact release * :ref:`genindex` + + +.. toctree:: + :hidden: + + mmref/index + mmref-index + mmref/faq + mmref-copyright + mmref/credit diff --git a/mps/manual/source/mmref-copyright.rst b/mps/manual/source/mmref-copyright.rst new file mode 100644 index 00000000000..b2e95ecd3a7 --- /dev/null +++ b/mps/manual/source/mmref-copyright.rst @@ -0,0 +1,26 @@ +Copyright +********* + + +Use subject to copyright restrictions +===================================== + +The copyright in The Memory Management Reference is owned by +`Ravenbrook Limited`_. + +.. _Ravenbrook Limited: http://www.ravenbrook.com/ + +Permission to copy part or all of The Memory Management Reference for +personal or classroom use is granted without fee, provided that copies +are not made or distributed for profit or commercial advantage; that +the copyright notice, the title of the publication, and its date +appear; and that notice is given that copying is by permission of +Ravenbrook Limited. To copy otherwise, to republish, to post on +servers, or to redistribute to lists requires prior specific +permission. + + +Warranty disclaimer +=================== + +The Memory Management Reference is provided "as is" without warranty of any kind, express or implied, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement. diff --git a/mps/manual/source/mmref-index.rst b/mps/manual/source/mmref-index.rst new file mode 100644 index 00000000000..c645899bb49 --- /dev/null +++ b/mps/manual/source/mmref-index.rst @@ -0,0 +1,56 @@ +Home +**** + +Welcome to the **Memory Management Reference**! This is a resource for programmers and computer scientists interested in :term:`memory management` and :term:`garbage collection`. + + +.. admonition:: :ref:`glossary` + + A glossary of more than 500 memory management terms, from + :term:`absolute address` to :term:`zero count table`. + + .. image:: diagrams/treadmill.svg + :target: glossary_ + + .. _glossary: glossary/index.html#glossary + + +.. admonition:: :ref:`mmref-intro` + + Articles giving a beginner's overview of memory management. + + .. image:: diagrams/address.svg + :target: intro_ + + .. _intro: mmref/index.html#mmref-intro + + +.. admonition:: :ref:`bibliography` + + Books and research papers related to memory management. + + .. image:: diagrams/copying.svg + :target: bib_ + + .. _bib: bib.html#bibliography + + +.. admonition:: :ref:`mmref-faq` + + Frequently asked questions about memory management. + + .. image:: diagrams/snap-out.svg + :target: faq_ + + .. _faq: mmref/faq.html#mmref-faq + +The Memory Management Reference is maintained by `Ravenbrook +Limited`_. We also maintain the `Memory Pool System`_ (an open-source, +thread-safe, :term:`incremental ` +garbage collector), and we are happy to provide advanced memory +management solutions to language and application developers through +our `consulting service`_. + +.. _Ravenbrook Limited: http://www.ravenbrook.com/ +.. _consulting service: http://www.ravenbrook.com/services/mm/ +.. _Memory Pool System: http://www.ravenbrook.com/project/mps/ diff --git a/mps/manual/source/mmref/faq.rst b/mps/manual/source/mmref/faq.rst index c45ba810d64..594f1656b97 100644 --- a/mps/manual/source/mmref/faq.rst +++ b/mps/manual/source/mmref/faq.rst @@ -22,6 +22,7 @@ garbage collection>` for :term:`C` exist as add-on libraries. .. link:: + `Memory Pool System `_, `Boehm–Demers–Weiser collector `_. @@ -130,6 +131,7 @@ semi-conservative garbage collectors for C++. .. link:: + `Memory Pool System `_, `Boehm–Demers–Weiser collector `_. @@ -163,11 +165,11 @@ In :term:`C++`, it may be that class libraries expect you to call Failing this, if there is a genuine :term:`memory leak` in a class library for which you don't have the source, then the only thing you -can try is to add a :term:`garbage collector`. The Boehm–Demers–Weiser -collector will work with C++. +can try is to add a :term:`garbage collector`. .. link:: + `Memory Pool System `_, `Boehm–Demers–Weiser collector `_. @@ -400,7 +402,7 @@ Where can I find out more about garbage collection? Many modern languages have :term:`garbage collection` built in, and the language documentation should give details. For some other languages, garbage collection can be added, for example via the -Boehm–Demers–Weiser collector. +Memory Pool System, or the Boehm–Demers–Weiser collector. .. seealso:: :term:`garbage collection` @@ -408,6 +410,7 @@ Boehm–Demers–Weiser collector. .. link:: + `Memory Pool System `_, `Boehm–Demers–Weiser collector `_, `GC-LIST FAQ `_. @@ -415,14 +418,16 @@ Boehm–Demers–Weiser collector. Where can I get a garbage collector? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The Boehm–Demers–Weiser collector is suitable for C or C++. The best way to -get a garbage collector, however, is to program in a language that -provides garbage collection. +The Memory Pool System and the Boehm–Demers–Weiser collector are +suitable for C or C++. The best way to get a garbage collector, +however, is to program in a language that provides garbage collection +natively. .. seealso:: :term:`garbage collection` .. link:: + `Memory Pool System `_, `Boehm–Demers–Weiser collector `_. diff --git a/mps/manual/source/mmref/index.rst b/mps/manual/source/mmref/index.rst index eb6ef48257e..d87db74339d 100644 --- a/mps/manual/source/mmref/index.rst +++ b/mps/manual/source/mmref/index.rst @@ -1,3 +1,5 @@ +.. _mmref-intro: + Introduction to memory management ################################# @@ -9,5 +11,3 @@ Introduction to memory management alloc recycle lang - faq - diff --git a/mps/manual/source/mmref/lang.rst b/mps/manual/source/mmref/lang.rst index 31a22cc0717..247eb7c6c25 100644 --- a/mps/manual/source/mmref/lang.rst +++ b/mps/manual/source/mmref/lang.rst @@ -53,8 +53,9 @@ Memory management in various languages library functions for :term:`memory (2)` management in C, :term:`malloc` and :term:`free (2)`, have become almost synonymous with :term:`manual memory management`), although - with the Boehm–Demers–Weiser :term:`collector (1)`, it is now - possible to use :term:`garbage collection`. + with the Memory Pool System, or the Boehm–Demers–Weiser + collector, it is now possible to use :term:`garbage + collection`. The language is notorious for fostering memory management bugs, including: @@ -86,6 +87,7 @@ Memory management in various languages .. link:: + `Memory Pool System `_, `Boehm–Demers–Weiser collector `_, `C standardization `_, `comp.lang.c Frequently Asked Questions `_. @@ -148,11 +150,11 @@ Memory management in various languages The :term:`garbage collector` in the .NET Framework is configurable to run in soft real time, or in batch mode. - The Mono runtime comes with two collectors: the Boehm–Weiser - :term:`conservative collector `, and a :term:`generational ` :term:`copying collector `. + The Mono runtime comes with two collectors: the + Boehm–Demers–Weiser :term:`conservative collector + `, and a :term:`generational + ` :term:`copying collector + `. .. link:: @@ -173,9 +175,9 @@ Memory management in various languages abstraction level of C++ makes the bookkeeping required for :term:`manual memory management` even harder. Although the standard library provides only manual memory management, with - the Boehm–Demers–Weiser :term:`collector (1)`, it is now possible to - use :term:`garbage collection`. :term:`Smart pointers` are - another popular solution. + the Memory Pool System, or the Boehm–Demers–Weiser collector, + it is now possible to use :term:`garbage collection`. + :term:`Smart pointers` are another popular solution. The language is notorious for fostering memory management bugs, including: @@ -222,6 +224,8 @@ Memory management in various languages .. link:: + `Memory Pool System `_, + `Boehm–Demers–Weiser collector `_, `comp.lang.c++ FAQ `_, `C++ standardization `_. diff --git a/mps/manual/source/themes/mmref/layout.html b/mps/manual/source/themes/mmref/layout.html index 0597e1ca7ef..961baeda428 100644 --- a/mps/manual/source/themes/mmref/layout.html +++ b/mps/manual/source/themes/mmref/layout.html @@ -17,15 +17,14 @@ {% block content %}
-

Memory Management Reference

+

Memory Management Reference

- {%- if prev and '../' not in prev.link %} + {%- if prev and '/' not in prev.link and 'mmref-' not in prev.link %} « {{ prev.title }} | {%- endif %} {{ title }} - {%- if next and '../' not in next.link %} + {%- if next and '/' not in next.link and 'mmref-' not in next.link %} | {{ next.title }} » {%- endif %}
diff --git a/mps/manual/source/themes/mmref/static/metal.png b/mps/manual/source/themes/mmref/static/metal.png new file mode 100644 index 00000000000..2f9f1ad0847 Binary files /dev/null and b/mps/manual/source/themes/mmref/static/metal.png differ diff --git a/mps/manual/source/themes/mmref/static/mmref.css_t b/mps/manual/source/themes/mmref/static/mmref.css_t index cd77bc91aed..f16758a7391 100644 --- a/mps/manual/source/themes/mmref/static/mmref.css_t +++ b/mps/manual/source/themes/mmref/static/mmref.css_t @@ -2,7 +2,12 @@ @import url('scrolls.css'); -h2, h3, h4, h5, h6, dl.glossary dt { +sup { + vertical-align: top; + font-size: 80%; +} + +dl.glossary dt { font-family: {{ theme_headfont }}; } @@ -20,7 +25,7 @@ h1.heading { } h1.heading:hover { - background: #73626E; + background: {{ theme_headerhover }}; } h1.heading a { @@ -96,3 +101,61 @@ p.glossary-alphabet { font-weight: bold; text-align: center; } + + +div.admonition-ref-glossary, div.admonition-ref-bibliography, div.admonition-ref-mmref-intro, div.admonition-ref-mmref-faq { + width: 45%; + display: inline-block; + vertical-align: top; +} + +div.admonition-ref-glossary, div.admonition-ref-mmref-intro { + height:400px; +} + +div.admonition-ref-bibliography, div.admonition-ref-mmref-faq { + height:230px; +} + +div.admonition-ref-glossary, div.admonition-ref-bibliography { + margin-right: 1%; +} + +div.admonition-ref-mmref-intro, div.admonition-ref-mmref-faq { + margin-left: 1%; +} + +div.admonition a.image-reference img { + width: 90%; + margin-left: 5%; + margin-top: 5px; +} + +div#home h1 { + display: none; +} + +div#home h1 + p { + margin-top: 0; + padding-top: 15px; +} + +/* Format the glossary index in two columns. */ + +div#memory-management-glossary div#all { + -webkit-columns: 2; + -moz-columns: 2; + -o-columns: 2; + -ms-columns: 2; + columns: 2; + padding-top: 1em; +} + +div#memory-management-glossary div#all h2 { + display: none; +} + +div#memory-management-glossary div#all a.reference.internal:after { + content: "\A"; + white-space: pre; +} diff --git a/mps/manual/source/themes/mmref/static/watermark.png b/mps/manual/source/themes/mmref/static/watermark.png new file mode 100644 index 00000000000..5bca5d2008b Binary files /dev/null and b/mps/manual/source/themes/mmref/static/watermark.png differ diff --git a/mps/manual/source/themes/mmref/static/watermark.svg b/mps/manual/source/themes/mmref/static/watermark.svg new file mode 100644 index 00000000000..ca9159234e1 --- /dev/null +++ b/mps/manual/source/themes/mmref/static/watermark.svg @@ -0,0 +1,237 @@ + + + + + + + + + + image/svg+xml + + + + + + + + 2e2f 6d70 7369 2e63 0073 697a 6520 3e203000 6d70 735f 6172 656e 615f 6f20 213d204e 554c 4c00 6d70 735f 706f 6f6c 5f6f2021 3d20 4e55 4c4c 006d 7073 5f66 6d745f6f 2021 3d20 4e55 4c4c 006d 7073 5f666d74 5f41 2021 3d20 4e55 4c4c 006d 70735f66 6d74 5f42 2021 3d20 4e55 4c4c 006d7073 5f66 6d74 2021 3d20 4e55 4c4c 006d7073 5f66 6d74 5f66 6978 6564 2021 3d204e55 4c4c 0054 4553 5454 2846 6f72 6d61742c 2066 6f72 6d61 7429 0054 4553 54542850 6f6f 6c2c 2070 6f6f 6c29 0070 5f6f2021 3d20 4e55 4c4c 006d 7073 5f61 705f6f20 213d 204e 554c 4c00 6d70 735f 61702021 3d20 4e55 4c4c 0054 4553 5454 28427566 6665 722c 2062 7566 2900 5445 53545428 4275 6666 6572 2c20 4275 6666 65724f66 4150 286d 7073 5f61 7029 2900 6d70735f 6170 2d3e 696e 6974 203d 3d20 6d70735f 6170 2d3e 616c 6c6f 6300 7020 213d204e 554c 4c00 7020 3d3d 206d 7073 5f61702d 3e69 6e69 7400 2876 6f69 6420 2a292828 6368 6172 202a 296d 7073 5f61 702d3e69 6e69 7420 2b20 7369 7a65 2920 3d3d206d 7073 5f61 702d 3e61 6c6c 6f63 00667261 6d65 5f6f 2021 3d20 4e55 4c4c 0053697a 6549 7341 6c69 676e 6564 2873 697a652c 2042 7566 6665 7250 6f6f 6c28 62756629 2d3e 616c 6967 6e6d 656e 7429 006d7073 5f73 6163 5f6f 2021 3d20 4e55 4c4c0054 4553 5454 2853 4143 2c20 7361 63290054 4553 5454 2853 4143 2c20 5341 434f6645 7874 6572 6e61 6c53 4143 286d 7073 + + diff --git a/mps/manual/source/themes/mmref/theme.conf b/mps/manual/source/themes/mmref/theme.conf index 0977e252b47..e0ef30ece1b 100644 --- a/mps/manual/source/themes/mmref/theme.conf +++ b/mps/manual/source/themes/mmref/theme.conf @@ -1,18 +1,18 @@ -# Colour scheme: +# Colour scheme: [theme] inherit = scrolls stylesheet = mmref.css - [options] -headerbg = #B38184 +headerbg = transparent +headerhover = #81A8B8 subheadlinecolor = #000000 -linkcolor = #73626E -visitedlinkcolor = #73626E -admonitioncolor = #aaa +linkcolor = #5D7985 +visitedlinkcolor = #5D7985 +admonitioncolor = #A4BCC2 textcolor = #000000 -underlinecolor = #aaa +underlinecolor = #A4BCC2 bodyfont = 'Optima', sans-serif headfont = 'Verdana', sans-serif diff --git a/mps/manual/source/themes/mps/static/mps.css_t b/mps/manual/source/themes/mps/static/mps.css_t index 6b0e20d0eb4..5904c165580 100644 --- a/mps/manual/source/themes/mps/static/mps.css_t +++ b/mps/manual/source/themes/mps/static/mps.css_t @@ -188,7 +188,7 @@ p.glossary-alphabet { } sup { - vertical-align: 20%; + vertical-align: top; font-size: 80%; } @@ -220,3 +220,22 @@ li.toctree-l1, li.toctree-l2, li.toctree-l3 { padding-top: 0 !important; } +/* Format the glossary index in two columns. */ + +div#memory-management-glossary div#all { + -webkit-columns: 2; + -moz-columns: 2; + -o-columns: 2; + -ms-columns: 2; + columns: 2; + padding-top: 1em; +} + +div#memory-management-glossary div#all h2 { + display: none; +} + +div#memory-management-glossary div#all a.reference.internal:after { + content: "\A"; + white-space: pre; +} diff --git a/mps/manual/source/topic/finalization.rst b/mps/manual/source/topic/finalization.rst index 745feefed16..5b65d9945dd 100644 --- a/mps/manual/source/topic/finalization.rst +++ b/mps/manual/source/topic/finalization.rst @@ -51,7 +51,7 @@ the block was allocated. to do the finalization. In such an implementation, the client program's finalization code may end up running concurrently with other code that accesses the underlying resource, and so access to - the resource need to be guarded with a lock, but then an unlucky + the resource needs to be guarded with a lock, but then an unlucky scheduling of finalization can result in deadlock. See :ref:`Boehm (2002) ` for a detailed discussion of this issue. @@ -170,8 +170,9 @@ Cautions #. The MPS does not finalize objects in the context of :c:func:`mps_arena_destroy` or :c:func:`mps_pool_destroy`. - :c:func:`mps_pool_destroy` should therefore not be invoked on pools - containing objects registered for finalization. + Moreover, if you have pools containing objects registered for + finalization, you must destroy these pools by following the “safe + tear-down” procedure described under :c:func:`mps_pool_destroy`. .. note:: @@ -189,11 +190,6 @@ Cautions .. note:: - You can safely destroy pools containing objects registered for - finalization if you follow the "safe tear-down" procedure - described under :c:func:`mps_pool_destroy`, but the objects do - not get finalized. - The only reliable way to ensure that all finalizable objects are finalized is to maintain a table of :term:`weak references (1)` to all such objects. The weak references don't diff --git a/mps/manual/source/topic/interface.rst b/mps/manual/source/topic/interface.rst index a939ddf302b..54637557f60 100644 --- a/mps/manual/source/topic/interface.rst +++ b/mps/manual/source/topic/interface.rst @@ -194,7 +194,7 @@ out parameter, like this:: res = mps_alloc((mps_addr_t *)&fp, pool, sizeof(struct foo)); This is known as :term:`type punning`, and its behaviour is not -defined in ANSI/ISO Standard C. See :ref:`ISO/IEC 9899:1990 ` +defined in ANSI/ISO Standard C. See :ref:`ISO/IEC 9899:1990 ` §6.3.2.3, which defines the conversion of a pointer from one type to another: the behaviour of this cast is not covered by any of the cases in the standard. @@ -209,7 +209,7 @@ Instead, we recommend this approach:: This has defined behaviour because conversion from ``void *`` to any other :term:`object pointer` type is defined by :ref:`ISO/IEC -9899:1990 ` §6.3.2.3.1. +9899:1990 ` §6.3.2.3.1. .. index:: @@ -219,7 +219,7 @@ Macros ------ #. For function-like macros, the MPS follows the same convention as - the Standard C library. To quote :ref:`ISO/IEC 9899:1990 ` + the Standard C library. To quote :ref:`ISO/IEC 9899:1990 ` §7.1.7: Any function declared in a header may additionally be diff --git a/mps/manual/source/topic/plinth.rst b/mps/manual/source/topic/plinth.rst index a7e94d21a0b..daba2ad62de 100644 --- a/mps/manual/source/topic/plinth.rst +++ b/mps/manual/source/topic/plinth.rst @@ -296,7 +296,7 @@ Library module This function is intended to have the same semantics as the :c:func:`fputc` function of the ANSI C Standard (:ref:`ISO/IEC - 9899:1990 ` §7.11.7.3). + 9899:1990 ` §7.11.7.3). .. note:: @@ -314,7 +314,7 @@ Library module This function is intended to have the same semantics as the :c:func:`fputs` function of the ANSI C Standard (:ref:`ISO/IEC - 9899:1990 ` §7.11.7.4). + 9899:1990 ` §7.11.7.4). Return a non-negative integer if successful, or :c:func:`mps_lib_get_EOF` if not. @@ -383,7 +383,7 @@ Library module This function is intended to have the same semantics as the :c:func:`memcmp` function of the ANSI C Standard (:ref:`ISO/IEC - 9899:1990 ` §7.11.4.1). + 9899:1990 ` §7.11.4.1). .. note:: @@ -406,7 +406,7 @@ Library module This function is intended to have the same semantics as the :c:func:`memcpy` function of the ANSI C Standard (:ref:`ISO/IEC - 9899:1990 ` §7.11.2.1). + 9899:1990 ` §7.11.2.1). The MPS never passes overlapping blocks to :c:func:`mps_lib_memcpy`. @@ -432,7 +432,7 @@ Library module This function is intended to have the same semantics as the :c:func:`memset` function of the ANSI C Standard (:ref:`ISO/IEC - 9899:1990 ` §7.11.6.1). + 9899:1990 ` §7.11.6.1). .. note:: diff --git a/mps/tool/branch b/mps/tool/branch index bb54f0d4527..981735d4360 100755 --- a/mps/tool/branch +++ b/mps/tool/branch @@ -1,11 +1,10 @@ #!/usr/bin/env python # -# Ravenbrook -# -# # BRANCH -- CREATE VERSION OR TASK BRANCH -# # Gareth Rees, Ravenbrook Limited, 2014-03-18 +# +# $Id$ +# Copyright (c) 2014 Ravenbrook Limited. See end of file for license. # # # 1. INTRODUCTION diff --git a/mps/tool/release b/mps/tool/release index 6daf82bed1c..d47fc36e788 100755 --- a/mps/tool/release +++ b/mps/tool/release @@ -1,11 +1,10 @@ #!/usr/bin/env python # -# Ravenbrook -# -# # RELEASE -- MAKE A RELEASE -# # Gareth Rees, Ravenbrook Limited, 2014-03-18 +# +# $Id$ +# Copyright (c) 2014 Ravenbrook Limited. See end of file for license. # # # 1. INTRODUCTION diff --git a/mps/tool/testcases.txt b/mps/tool/testcases.txt index 3f8e9c7b70d..0b45b8cc548 100644 --- a/mps/tool/testcases.txt +++ b/mps/tool/testcases.txt @@ -18,11 +18,11 @@ bttest =N interactive djbench =N benchmark exposet0 =P expt825 -fbmtest finalcv =P finaltest =P fotest gcbench =N benchmark +landtest locbwcss lockcov lockut =T diff --git a/mps/tool/testcoverage b/mps/tool/testcoverage index cf4c62ae703..56ee5789bbf 100755 --- a/mps/tool/testcoverage +++ b/mps/tool/testcoverage @@ -1,11 +1,10 @@ #!/bin/sh # -# Ravenbrook -# -# # TESTCOVERAGE -- TEST COVERAGE REPORT FOR THE MPS -# # Gareth Rees, Ravenbrook Limited, 2014-03-21 +# +# $Id$ +# Copyright (c) 2014 Ravenbrook Limited. See end of file for license. # # # 1. INTRODUCTION diff --git a/mps/tool/testemscripten b/mps/tool/testemscripten index 4639e9e69a4..b4c565440db 100755 --- a/mps/tool/testemscripten +++ b/mps/tool/testemscripten @@ -1,11 +1,10 @@ #!/bin/sh # -# Ravenbrook -# -# # TESTEMSCRIPTEN -- TEST THE MPS WITH EMSCRIPTEN -# # Gareth Rees, Ravenbrook Limited, 2014-04-17 +# +# $Id$ +# Copyright (c) 2014 Ravenbrook Limited. See end of file for license. # # # 1. INTRODUCTION diff --git a/mps/tool/testopendylan b/mps/tool/testopendylan index 0c185ff2fd0..4bd1488261c 100755 --- a/mps/tool/testopendylan +++ b/mps/tool/testopendylan @@ -1,11 +1,10 @@ #!/bin/sh # -# Ravenbrook -# -# # TESTOPENDYLAN -- TEST THE MPS WITH OPENDYLAN -# # Gareth Rees, Ravenbrook Limited, 2014-03-20 +# +# $Id$ +# Copyright (c) 2014 Ravenbrook Limited. See end of file for license. # # # 1. INTRODUCTION